16:01:10 <geppetto> #startmeeting fpc
16:01:10 <zodbot> Meeting started Thu Mar 24 16:01:10 2016 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:10 <zodbot> The meeting name has been set to 'fpc'
16:01:10 <geppetto> #meetingname fpc
16:01:11 <zodbot> The meeting name has been set to 'fpc'
16:01:11 <geppetto> #topic Roll Call
16:01:23 <geppetto> /msg fedbot say #fedora-devel FPC meeting starting now in #fedora-meeting-1
16:01:32 <geppetto> #chair tibbs|w
16:01:32 <zodbot> Current chairs: geppetto tibbs|w
16:02:00 <geppetto> Yeh, I got back from vacation today … so brothers in arms. :(
16:03:42 <geppetto> #chair racor
16:03:42 <zodbot> Current chairs: geppetto racor tibbs|w
16:04:08 <orionp> hello
16:04:12 <geppetto> #chair orionp
16:04:12 <zodbot> Current chairs: geppetto orionp racor tibbs|w
16:04:13 <mbooth> Hi
16:04:15 <geppetto> Oh, hi :)
16:04:18 <geppetto> #chair mbooth
16:04:18 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs|w
16:04:34 <geppetto> Well that's 5 … so that's good
16:04:50 <geppetto> I'll give it another couple of minutes to see if we get more, then start
16:05:44 <geppetto> #topic Schedule
16:05:53 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/BZTIWJIHZNFC4V6ZNZ2ZPY4T7QMBFWVS/
16:06:07 <geppetto> #topic #604 Python filtering
16:06:14 <geppetto> .fpc 604
16:06:16 <zodbot> geppetto: #604 (Python filtering) – fpc - https://fedorahosted.org/fpc/ticket/604
16:06:30 <geppetto> this seemed fine to me
16:06:39 <geppetto> tibbs|w: Anything more to add?
16:07:19 <orionp> +1 here
16:07:30 <mbooth> Sounds sensible, +1
16:07:47 <tibbs|w> I don't think so.  Basically, this is just elimination of noise with macros.
16:08:07 <tibbs|w> I've never been sure of why we have a nice macro for Perl and not for other things.
16:08:18 <tibbs|w> Also, I've never understood why these filters aren't just set by default.
16:08:52 <tibbs|w> But that's another topic, I guess.
16:09:05 * geppetto nods
16:09:18 <geppetto> Well that's +4 … racor you want to vote?
16:09:20 <tibbs|w> +1 from me in case it wasn't obvious.
16:09:58 <racor> geppetto: Sorry, I haven't paid attention ...
16:10:17 <tibbs|w> I just don't want to take unilateral action on this kind of thing.  And I do think that FPC should move into the realm of creating and maintaining some central RPM macros instead of just doing guidelines.
16:10:40 <geppetto> Yeh, seemed reasonable
16:10:49 <tibbs|w> racor: The issue is simply adding a default filter for Python like Perl has.
16:10:56 <racor> +1
16:11:48 <geppetto> #action Python filtering macros (+1:5, 0:0, -1:0)
16:11:57 <tibbs|w> racor: There's a related question (not being voted on) as to why the Perl filter isn't applied by default.  If you have an opinion on that, I'd love to hear it.
16:13:56 <racor> tibbs|w: Good question. I don't have an answer at hand and would have to think about it.
16:14:20 <geppetto> #topic #606 Outdated info about scriptlet exit statuses
16:14:25 <geppetto> .fpc 606
16:14:26 <zodbot> geppetto: #606 (Outdated info about scriptlet exit statuses) – fpc - https://fedorahosted.org/fpc/ticket/606
16:14:49 <tibbs|w> racor: It's not urgent or even under consideration today; I just thought it was an interesting question.
16:15:19 <tibbs|w> It's good that RPM handles this better now, but I'd really like an answer to my question.
16:15:39 <racor> May-be we/you should ask on the perl-devel@ list?
16:16:15 <tibbs|w> racor: Yeah, just haven't had the time.  If I can remember, I'll do that though I don't know if anyone would see it in the torrent of bugzilla ticket spam that goes there.
16:16:34 <racor> tibbs|w: ;)
16:16:55 <tibbs|w> Sorry, in res 606: It's good that RPM handles scriptlet exits better now, but I'd really like an answer to my question.
16:17:05 <tibbs|w> It wasn't at all clear what I was talking about there.
16:17:26 <tibbs|w> Too much multitasking.
16:18:30 <tibbs|w> But basically, in re 606, I'm pretty sure we can change all of that for Fedora but it would at least be nice to know what the EPEL guidelines would need to say, as breakage here can get weird.
16:18:34 <geppetto> I would be happy to replace the entire paragraph with " some really exceptional cases (if any), we want all scriptlets to exit with the zero exit status. "
16:18:55 <geppetto> Bah, bad selection … with: "Except in some really exceptional cases (if any), we want all scriptlets to exit with the zero exit status. "
16:19:25 <orionp> yeah, that seems good
16:19:29 <tibbs|w> Has anyone run the spec he included to see what RPM and DNF actually do with scriptlet failures?
16:19:34 <orionp> Don't confuse people with too much information
16:19:39 <tibbs|w> As in, how does it get logged?
16:20:02 <geppetto> Not me
16:20:42 <tibbs|w> Also, I note that a lot of that page isn't even packaging guidelines.  It's just documentation.
16:20:44 <orionp> I've generally seen something like  package %preun scriptlet failed in my yum-cron output - not using dnf/fedora much these days
16:22:28 <tibbs|w> I think it just logs it but the transaction doesn't fail.
16:22:39 <orionp> right
16:23:52 <geppetto> Well on yum the transaction doesn't fail … but the package does.
16:23:57 <geppetto> In some cases.
16:24:17 <mbooth> Is the treatment of scriptlet exit codes documented by rpm upstream?
16:24:20 <geppetto> So you get a "errored" transaction that did some things, but not everything.
16:24:23 <tibbs|w> Which is kind of why I wonder why we can't just keep it the way it is.
16:24:31 <mbooth> (Or dnf upstream?)
16:24:36 <geppetto> It's never a good result.
16:25:11 <geppetto> I doubt dnf documents it
16:25:32 <mbooth> Actually I'll ask on the ticket -- I'd rather link to canonical sources of information
16:25:53 <mbooth> Than littering the guidelines with what tibbs|w rightly says is documentation
16:26:06 <tibbs|w> I had started a bit of cleanup on that page.
16:26:12 <tibbs|w> I'm sure you'll noticed that it was renamed.
16:27:07 <geppetto> Are you sure ?:)
16:27:11 <tibbs|w> If there's real documentation, I'd prefer to link to it and remove at least the Syntax and Scriptlet Ordering sections after lifting any actual guidelines out of them
16:27:16 <tibbs|w> OK, well, maybe not.
16:27:29 * geppetto nods … seems fine.
16:27:32 <tibbs|w> I even went through and fixed a bunch of double and triple redirects in the wiki.
16:27:47 <geppetto> Cool
16:27:51 <tibbs|w> Because there was a moment about a month ago when I had time.
16:28:33 <mbooth> Added comment
16:30:15 <tibbs|w> Would it be better to just recommend that scriptlets have zero exit status even though it isn't strictly required?
16:30:49 <tibbs|w> I don't think the current state hurts anything, though we of course shouldn't say that RPM requires it when it doesn't.
16:30:50 <Rathann> oh
16:30:52 <Rathann> hi
16:30:54 <orionp> That would be my suggestion
16:31:00 <tibbs|w> Howdy.
16:31:07 <geppetto> Yeh, that's what I said … I think :) … basically even though it does things, basically everything goes wrong with a non-zero exit status.
16:31:16 <orionp> Don't confuse people with details, just say - no output - always zero exit
16:31:21 <geppetto> So just don't do it.
16:31:23 <tibbs|w> orionp: I agree.
16:31:30 <racor> tibbs|w: why, what for?
16:31:33 <geppetto> #chair Rathann
16:31:33 <zodbot> Current chairs: Rathann geppetto mbooth orionp racor tibbs|w
16:31:38 <tibbs|w> racor: Simplicity, I guess.
16:31:51 <tibbs|w> Otherwise we have to document the cases where it's necessary separately.
16:31:55 <racor> tibbs|w: Playing down issues?
16:32:49 <tibbs|w> Basically.  Unless someone knows exactly what RPM and DNF do in every instance and we can guarantee that it's OK to tell people to drop the mysterious colons from their scriptlets.
16:33:34 <tibbs|w> Even better would be to macroize all of the scriptlets which are still necessary once we get triggers implemented, and not have to worry about it for the vast majority of packages.
16:33:59 * geppetto nods
16:36:03 <geppetto> So do we want to vote on anything?
16:37:33 <tibbs|w> I think we need some answers and a draft.
16:37:43 <tibbs|w> Bad emergency just came up.  I may be in and out.
16:37:52 <geppetto> ok
16:38:30 <geppetto> #action Need answers and a draft, likely removing rpm/etc. documentation from guidlines
16:38:43 <geppetto> #topic #608 New dynamic macro in ExclusiveArch for Pascal
16:38:48 <geppetto> .fpc 608
16:38:48 <tibbs|w> I can't promise to cook up a draft.
16:38:50 <zodbot> geppetto: #608 (New dynamic macro in ExclusiveArch for Pascal) – fpc - https://fedorahosted.org/fpc/ticket/608
16:39:02 <geppetto> Yeh, that's fine … I didn't put the action on you
16:39:11 <geppetto> maybe scop will do it
16:39:23 <tibbs|w> tibbs|w: I know, I just figured I would mention it.  So much going on now.
16:40:04 <tibbs|w> in re 608, I'm still not convinced about the proliferation of little macro packages that all get pulled into the buildroot, but I don't think it's a real issue.
16:40:24 <tibbs|w> So all he needs to do is get his package in and then we can tweak redhat-rpm-config to pull it in.
16:40:52 * geppetto nods … we are all fine with the macro idea/plan ?
16:41:07 <tibbs|w> It's no different than the other macros of the type.
16:41:12 * geppetto nods
16:41:22 <mbooth> Sure
16:41:32 <Rathann> +1, though I'd prefer for them to be folded into redhat-rpm-config
16:41:45 <tibbs|w> Having consistent guidelines relating to such macros, and macro packages in general, would be nice, I guess.
16:41:52 <Rathann> also, why isn't it called fedora-rpm-config, or, rpm-config-fedora?
16:42:01 <tibbs|w> Rathann: History, I guess.
16:42:04 <Rathann> hehe
16:42:07 <Rathann> as always
16:42:27 <mbooth> Rathann: I dunno, separate package allows eco-system maintainers to "do the work" :-)
16:42:35 <mbooth> Rather than us
16:42:52 <tibbs|w> mbooth: True, but then we get into the question of how much FPC wants to get into this.
16:42:55 <Rathann> but how often do changes happen? once per Fedora release?
16:43:05 <tibbs|w> Rathann: Changes to what?
16:43:08 <Rathann> to the macros
16:43:18 <tibbs|w> Rathann: a few times per release, in general.
16:43:54 <tibbs|w> I'll tweak something occasionally.
16:43:56 <Rathann> hm
16:44:23 <mbooth> Java SIG tweak mvn_* macros occasionally too, it would be a ball-ache to go through FPC every time
16:44:37 <tibbs|w> I don't think we'd say that things need to go through FPC.
16:44:57 <Rathann> exactly
16:45:23 <tibbs|w> I just think it's kind of dumb to add a whole new macro package and dependency for, what, 20 characters of macro that will probably never change.
16:45:33 <tibbs|w> But I don't care enough.
16:45:48 <orionp> The srpm macros are special/limited -  I still lean towards delegation though
16:45:51 <geppetto> yeh, but on the other side having 1 package with 666 maintainers isn't great either
16:46:27 <orionp> There can be issues where say fpc gains an arch in a specific release
16:46:35 <tibbs|w> The point is that such macros must be in the buildroot, and probably the smartest way to do that.
16:46:36 <tibbs|w> Also, I'm lagging.
16:47:07 <tibbs|w> geppetto: Right, which is why I'd at least like FPC to watch over the situation.
16:47:41 * geppetto nods
16:47:50 <tibbs|w> In any case, we can't move forward here until he either has the macro package in place (in which case I'll add the dep to redhat-rpm-config)
16:48:01 <tibbs|w> or he tells us what the actual macro definition is.
16:48:14 * geppetto nods
16:48:20 <tibbs|w> So that I can add it to redhat-rpm-config.
16:49:11 <geppetto> #action mattia Add package and tell FPC what redhat-rpm-config should depend on, or speak to tibbs about adding macro directly.
16:49:54 <geppetto> #topic #611 	Koji and weak dependencies
16:49:57 <geppetto> .fpc 611
16:49:58 <zodbot> geppetto: #611 (Koji and weak dependencies) – fpc - https://fedorahosted.org/fpc/ticket/611
16:50:21 <dgilmore> hola amigos
16:50:41 <geppetto> Hey
16:50:49 <geppetto> Are there any reasons to not want this?
16:51:00 <tibbs|w> geppetto: You might remember you and I talked about this during open floor of the last meeting in January.
16:51:21 <geppetto> That was a long time ago
16:51:22 <tibbs|w> Where "this" is having koji not install weak deps.
16:51:24 <geppetto> many sleeps
16:51:31 <dgilmore> turning on weak deps would mean anything that could possibly be installed will be
16:51:40 * geppetto nods
16:51:45 <tibbs|w> I think that koji should _not_ install weak deps.
16:51:55 <tibbs|w> If you need something to build, you should have a build dep on it.
16:51:58 <dgilmore> but dnf does different things on different arches
16:52:03 <gholms> The proposal is to not include them.
16:52:26 <geppetto> I'm mostly happy with either way, as long as it's consistent
16:52:27 <dgilmore> requiring people to explictly require everything they need to build against is clearer
16:52:38 <tibbs|w> If you just need Perl and don't care what comes in with Perl then depend on Perl.  If you care about exactly what Perl brings in, you should depend upon it.
16:52:47 <tibbs|w> dgilmore: And that's actually what the guidelines say currently.
16:53:32 * geppetto nods … I assume the counter is more like "I build fine with just perl, but can use XYZ if it's available"
16:53:40 <dgilmore> tibbs|w: what will happen is that some things will start to fail to build. they did not realise all tehir deps
16:53:44 <geppetto> I'm happy to say everyone should just depend on XYZ at that point
16:53:51 <dgilmore> or were relying on other packages to pull them in
16:54:18 <dgilmore> geppetto: yeah.
16:54:33 <tibbs|w> I think not installing weak dependencies is the best way to make sure people aren't surprised.
16:54:45 <dgilmore> we have had some issues where on a secondary there is a broken dep causing dnf to skip installing it and packages get built differently
16:54:58 <tibbs|w> Just got disconnected.
16:55:09 <tibbs|w> Las thing I saw was [11:54] <dgilmore> geppetto: yeah.
16:55:24 <dgilmore> we have had some issues where on a secondary there is a broken dep causing dnf to skip installing it and packages get built differently
16:55:33 <dgilmore> tibbs|w: that was all that came after
16:55:50 <racor> dgilmore: this should not happen.
16:55:52 <tibbs|w> But basically, if things fail because you don't specify your deps, then.... that's kind of your fault.
16:55:59 * geppetto nods … that seems like a reasonable reason to make it never do them
16:56:30 <tibbs|w> Yes, if we change what koji does now, then there might be a little bit of breakage.  I can't imagine it's difficult to fix it.
16:56:31 <dgilmore> racor: lots of things that should not happen do happen
16:56:49 <dgilmore> tibbs|w: the breakage will be adding BuildRequires
16:57:00 <tibbs|w> Right.  That's not bad at all, is it?
16:57:09 <tibbs|w> I can't imagine more than a few packages will care.
16:57:15 <dgilmore> I can see cases both ways and do not have a strong opinion how it should be done
16:57:23 <dgilmore> I would just like it to be clear
16:57:23 <tibbs|w> Currently the primary arches don't install weak deps, right?
16:57:28 <tibbs|w> It's just some of the secondaries?
16:57:54 <dgilmore> the ruby stack is teh biggest thing I know that will have issues
16:58:00 <dgilmore> because they did weird things
16:58:19 <dgilmore> tibbs|w: currently the primary arches install weak deps
16:58:30 <dgilmore> but some of teh secondaries it seems do not
16:58:38 <geppetto> I think the fact that problems == don't install, with weak deps. is a strong reason to not have them in builds … we don't want builds changing because of errors … just failures.
16:58:46 <tibbs|w> Ah, so backwards from what I thought.
16:58:57 <mbooth> eh, there is already breakage in the ruby stack: https://apps.fedoraproject.org/koschei/groups/ruby-rails
16:59:17 <dgilmore> mbooth: the ruby stack did weird things
16:59:22 <dgilmore> and has breakage
16:59:34 <mbooth> I am for not installing weak deps
16:59:39 <dgilmore> all in teh name of letting /usr/bin/ruby be ruby of jruby
16:59:49 <tibbs|w> Oh, yeah, and if/when this changes, koschei will tell everyone anyway.  Unless the packages don't use it, in which case that's kind fo their fault.
16:59:52 <dgilmore> ruby or jruby
17:00:09 <tibbs|w> I think Ruby... will just have to figure out how to survive.
17:00:22 <geppetto> :)
17:00:28 <tibbs|w> If their setup depends on something that fragile, they need to do a rethink.
17:00:33 <dgilmore> tibbs|w: the ruby folks are pushing for the change
17:00:36 <tibbs|w> So, I'm +1 to not installing weak deps.
17:00:47 <Rathann> +1 to disabling weak deps in koji
17:00:54 <mbooth> +1, same
17:00:55 <geppetto> +1 to disable them
17:00:56 <tibbs|w> dgilmore: Ah, so they'll actually be happier here.
17:01:09 <dgilmore> tibbs|w: maybe until they get to fix the breakages
17:01:11 <racor> +1
17:01:36 <geppetto> orionp: vote?
17:01:50 <orionp> +1
17:02:22 <geppetto> #action Disable weak deps. in koji builds (+1:6, 0:0, -1:0)
17:02:32 <dgilmore> thanks guys
17:02:33 <geppetto> We should probably tweak mock builds too
17:02:50 <geppetto> #info mock should probably do the same.
17:02:53 <tibbs|w> dgilmore: Which change were they pushing for?
17:03:19 <dgilmore> tibbs|w: they wanted weakdeps to not be installed as the minimal buildroot is bigger
17:03:36 <tibbs|w> Then I guess they're getting what they want.
17:03:48 <tibbs|w> I'm not sure what's involved in getting mock to do this, though.
17:04:20 <dgilmore> tibbs|w: it actually has it configured that way already
17:04:23 <geppetto> I think there's a way to set config. options for yum/dnf in mock … so just setting them "do not install weak deps" option
17:04:30 <geppetto> dgilmore: Ahh, cool.
17:04:32 <dgilmore> someone filed a ticket so the mock guys just went and did it
17:04:34 <tibbs|w> mock currently has config_opts['yum.conf'] setting install_weak_deps=0.
17:04:48 <dgilmore> without bothing to communicate or see what was right
17:04:54 <tibbs|w> I'm assuming that the yum.conf option actually applies to dnf.
17:05:06 <geppetto> I hope so, because that does nothing in yum
17:06:14 <geppetto> #topic Open Floor
17:06:23 <geppetto> Anything anyone wants to bring up?
17:06:35 <tibbs|w> dgilmore: Sorry for forgetting to file that ticket back in January when I should have.
17:06:53 <dgilmore> tibbs|w: no problem
17:07:13 <tibbs|w> What about 609?
17:07:13 <dgilmore> tibbs|w: yeah yum.conf applies to dnf
17:07:29 <mbooth> geppetto: Nothing from me, have a good easter weekend everyone
17:07:43 <tibbs|w> .fpc 609
17:07:45 <zodbot> tibbs|w: #609 (Revise Conflicts guidelines now that we have weak deps?) – fpc - https://fedorahosted.org/fpc/ticket/609
17:08:04 <tibbs|w> https://fedoraproject.org/wiki/Packaging:Conflicts#Optional_Functionality
17:08:20 <tibbs|w> Don't weak or boolean deps cover that case now?
17:08:26 <orionp> FYI I have to go soon...
17:08:43 <geppetto> No
17:09:11 <geppetto> At least … it would be a bit weird to see:
17:09:14 <geppetto> Requires: foo
17:09:15 <tibbs|w> Hmm, OK.
17:09:19 <geppetto> WeakRequires: foo > 2
17:09:26 <tibbs|w> I mean, the Conflicts there is clear.
17:09:45 <tibbs|w> "If this package is installed, it must be at least version N".
17:09:51 <geppetto> yeh
17:10:14 <tibbs|w> I just didn't know if there was another way to specify that with the new functionality.
17:10:45 <geppetto> What I posted above … but I'm not sure it's better
17:11:10 <tibbs|w> Better not to worry about this, then.  I'll close the ticket.
17:11:20 <geppetto> Well, it doesn't do exactly that … but a similar thing "Any version of FOO is fine, but for extra functionality FOO > 2"
17:11:41 <tibbs|w> Has anything gotten better with file triggers?
17:11:47 <geppetto> But I think that'll be more confusing than anything
17:11:59 <tibbs|w> I know the script guidelines need to be modified to indicate which aren't required in what Fedora version.
17:12:10 <tibbs|w> scriptlet guidelines.
17:12:21 <geppetto> AFAIK no … but I haven't looked in a couple of weeks, due to holidays.
17:13:59 <tibbs|w> If anyone has a list, I'll try go have a look.
17:14:13 <geppetto> list?
17:14:15 <tibbs|w> Actually I should just be able to grep them out of the current spec archive.  So happy we have that now.
17:14:21 <tibbs|w> List of the existing triggers.
17:14:24 <geppetto> Ahh
17:14:39 <geppetto> Yeh, that's what I did to get my lists
17:14:46 <tibbs|w> I'll just do the same.
17:15:10 * geppetto nods … there are like 4 different spellings … but was still easy enough to grep
17:16:10 <tibbs|w> If we can just get texlive, R and glibc to implement triggers, a lot of stuff would just go away.
17:16:22 * geppetto nods
17:16:25 <tibbs|w> I figured glibc would be one of the first packages to get them.
17:16:39 <geppetto> you would be wrong ;)
17:16:42 <tibbs|w> But maybe it has the highest potential for screwing something up.
17:17:03 <geppetto> Yeh, although ldconfig is also the least likely to go wrong
17:17:28 <tibbs|w> True, and also I don't think things actually break if it doesn't get run.
17:18:06 <tibbs|w> One question was always about what happens when you have one package installing a library that another package will need for its scriptlets, but ldconfig doesn't run until the end of the transaction.
17:18:22 <tibbs|w> I don't think anything actually breaks in that situation.  It's just a little bit slower.
17:18:54 * geppetto nods
17:21:25 <geppetto> #info No pressing need to use weak deps. to replace conflict usage.
17:21:27 <tibbs|w> I could be wrong, of course.
17:21:43 <geppetto> That was my understanding as well
17:21:50 <geppetto> ldconfig == optimization
17:22:06 <tibbs|w> Worth a ticket against glibc, you think?
17:22:48 <geppetto> If you want. I was waiting until the bugzillas got fixed, and then try to do them for all the ones I/we could think of
17:22:52 <tibbs|w> And did anyone have a change to think about 610 at all?
17:23:00 <tibbs|w> .fpc 610
17:23:02 <zodbot> tibbs|w: #610 (Packaging guidelines: Check upstream tarball signatures) – fpc - https://fedorahosted.org/fpc/ticket/610
17:23:14 <tibbs|w> We had it set as meeting, but it's pretty recent.
17:23:27 <tibbs|w> We're also way over an hour, but that's not surprising given that we're kind of catching up.
17:23:44 <geppetto> Where do we get the keyfile from?
17:23:56 <Rathann> yeah, I'm +1 to the general idea, but I haven't gone through all the details yet
17:23:58 <tibbs|w> Right.
17:24:09 <tibbs|w> The package admin gets it from the keyserver manually.
17:25:07 <tibbs|w> I also do not think that %prep should completely fail to unpack the tarball if GPG fails.
17:25:12 <geppetto> And updates it manually?
17:25:17 <tibbs|w> I think so.
17:25:43 <tibbs|w> I do, however, think that maybe we should see if we can make %autosetup do this magically.
17:25:55 <geppetto> Yeh … I don't think this belongs inside the build infrastructure at all
17:26:00 <tibbs|w> With a flag that takes the sources to check.
17:26:32 <tibbs|w> I think it's a good idea to put this somewhere in the package.
17:26:52 <tibbs|w> I just think it should either be done by %autosetup or come after the %autosetup call in %prep.
17:26:58 * geppetto shrugs … I mean we only get the package from upstream once.
17:27:02 <tibbs|w> I really don't like %prep doing _too much_.
17:27:52 <geppetto> I guess having a feature in fedpkg that downloads a new upstream plus a signature, and checks it against an (old) key would be cool.
17:27:54 <tibbs|w> I guess it provides a way to verify that what's in our lookaside is the right thing.
17:28:10 <geppetto> I'm 100% against it happening in %prep
17:28:18 <tibbs|w> You'd have to compromise both the lookaside (for the tarball) and the git repo (for the key).
17:28:57 <tibbs|w> If you're strongly against it then I guess you should make some comments.
17:29:00 <tibbs|w> in that ticket.
17:29:17 <geppetto> Yeh, I guess
17:29:22 <tibbs|w> I may have fun and see if I can make %autosetup do it.
17:29:42 <tibbs|w> If we end up not using it then no big deal.
17:29:45 <geppetto> :)
17:29:54 <tibbs|w> There's also a thread on devel@ about this.
17:30:16 * geppetto nods … I could be convinced that it's downside is almost 0, so any gain is worth it
17:30:33 <tibbs|w> Well, what is the downside currently?
17:30:35 <geppetto> But it just feels like a waste of time, and the wrong place, at build time.
17:30:37 <tibbs|w> As you see it.
17:30:47 <tibbs|w> And what would be the proper place?
17:31:00 <tibbs|w> I know that it doesn't help you at all if you just got an srpm from somewhere.
17:31:08 <geppetto> proper place would be when we are getting the contect for the look aside cache
17:31:16 <geppetto> content, too
17:31:18 <tibbs|w> So in spectool?
17:31:31 <tibbs|w> That was actually proposed, but spectool turned into a complete debacle.
17:31:40 <geppetto> Well, something like "fedpkg new-upstream BLAH..."
17:32:02 <tibbs|w> Getting things into fedpkg is even harder than getting them into the three different spectools.
17:32:10 <geppetto> :)
17:32:42 <geppetto> Which is sad … it seems like it should be really easy to get stuff into fedpkg :(
17:32:53 <tibbs|w> There's something weird about how fedpkg is developed.
17:33:17 <tibbs|w> At fudcon I was basically warned off of trying to do anything with it.  It  was suggested that I just write separate tools.
17:33:52 <tibbs|w> It's just a wrapper around some other library which is used internally by Red Hat and so can't really change without all of Red Hat's internal process.
17:33:55 <tibbs|w> Or something like that.
17:34:24 <geppetto> Sigh
17:34:33 <tibbs|w> I could be wrong, and it's been a while.
17:34:47 <geppetto> You probably aren't
17:34:58 <tibbs|w> But implementing a separate tool makes it possible to integrate into fedpkg later, assuming you write your tool in python.
17:35:24 <geppetto> Maybe https://release-monitoring.org/ ?
17:35:26 <tibbs|w> And probably not python3, either.
17:35:43 <tibbs|w> Hmm, anitya checking gpg keys.  Not sure about that.
17:35:50 <tibbs|w> new-hotness, maybe.
17:36:00 <geppetto> yeh
17:36:09 <tibbs|w> We can ask.
17:36:23 <geppetto> Would be cool to get a fedmsg notification that new FOO failed to GPG check ;)
17:36:45 <tibbs|w> I can file an RFE.  The worst they can do is close it.
17:36:53 * geppetto nods
17:37:28 <geppetto> Seems like it'd be perfect … just need to feed the allowable GPG keys into it, and then have them automatically checked.
17:37:54 <geppetto> Although weirdly, it seems to know the upstream versions but doesn't link to the upstream data.
17:38:35 <geppetto> Man, none of the data is clickable
17:38:39 * geppetto sighs
17:38:45 <geppetto> RFE can't hurt anyway
17:38:46 <tibbs|w> Yeah, that I've never completely understood.
17:39:49 <tibbs|w> Well, 12:40 here and I need to go put out fires.
17:40:07 <geppetto> ok, I'll close as it's just been us two talking for a few minutes now :)
17:40:28 <geppetto> #endmeeting