16:00:34 <geppetto> #startmeeting fpc
16:00:34 <zodbot> Meeting started Thu Oct 26 16:00:34 2017 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:34 <zodbot> The meeting name has been set to 'fpc'
16:00:34 <geppetto> #meetingname fpc
16:00:34 <zodbot> The meeting name has been set to 'fpc'
16:00:34 <geppetto> #topic Roll Call
16:00:41 <mbooth> Yo
16:00:47 <tibbs> Howdy.
16:00:49 <geppetto> #chair mbooth
16:00:49 <zodbot> Current chairs: geppetto mbooth
16:00:52 <ignatenkobrain> .hello2
16:00:52 <tibbs> I'm finally back in tow.
16:00:52 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:00:53 <geppetto> #chair tibbs
16:00:53 <zodbot> Current chairs: geppetto mbooth tibbs
16:01:02 <Rathann> hi
16:01:10 <geppetto> #chair Rathann
16:01:10 <zodbot> Current chairs: Rathann geppetto mbooth tibbs
16:01:17 <tomspur> Hi
16:01:27 <geppetto> #chair tomspur
16:01:27 <zodbot> Current chairs: Rathann geppetto mbooth tibbs tomspur
16:06:26 <ignatenkobrain> silence ;)
16:07:08 <Rathann> geppetto: we've got quorum, so we can start
16:07:13 <geppetto> Lots of replies quickly … was waiting a few mins. for others
16:07:16 <geppetto> Yeh
16:07:43 <geppetto> #topic Schedule
16:07:45 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/2VLV4EIQWMZUDDDQWX7BCD2XMWJD4Q3T/
16:08:09 <ignatenkobrain> if you don't mind I would ask to start with my topics since I have to leave in 30-35 mins
16:08:19 <geppetto> Note that ignatenkobrain had some new tickets he wanted to talk about.
16:09:10 <geppetto> #topic #720 Easy way of changing/removing shebangs
16:09:15 <geppetto> .fpc 720
16:09:18 <zodbot> geppetto: Issue #720: Easy way of changing/removing shebangs - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/720
16:11:14 <geppetto> Anyone have opinions?
16:11:59 <geppetto> It's not a real draft … but I'm mostly fine with it. chshebang seems a little too non-obvious, but I'm not sure I care enough
16:11:59 <Rathann> vondruch had some valid points
16:12:11 <Rathann> but I'm +1 to the idea in general
16:12:16 * geppetto nods
16:12:16 <tomspur> How would you actually use the macro? The tree line documentation is not very helpful to me
16:12:21 <tomspur> +1 for the general idea tho
16:12:32 <ignatenkobrain> tomspur: %chshebang -d foo.py bar.py to remove shebang
16:13:01 <geppetto> Do we need -d ?
16:13:10 <ignatenkobrain> -d == --delete =)
16:13:25 <geppetto> yeh, I mean do people need to delete the shebang line?
16:13:36 <Rathann> what does -d do and why do we need it at all?
16:13:44 <ignatenkobrain> geppetto: yes, /usr/bin/env in %{pythonX_sitelib}
16:13:48 <geppetto> is it to stop some rpm auto prov/req thing?
16:13:56 <Rathann> I thought we only needed replacement with the proper shebang
16:13:59 <ignatenkobrain> geppetto: yes
16:14:04 <geppetto> Oh, I figured those would be changed to /usr/bin/python3
16:14:10 <ignatenkobrain> %chrpath -r %{__python3} foo.py will insert /usr/bin/python3 to the foo.py
16:14:14 <ignatenkobrain> instead of existing one
16:14:26 <Rathann> making things non-executable is enough to stop them from being scanned
16:14:30 <Rathann> so why?
16:14:32 <ignatenkobrain> geppetto: not really, those scripts should not have shebang at all
16:14:41 <geppetto> Ok
16:15:14 <ignatenkobrain> anyway, there are some cases where you want to drop shebang
16:15:39 <tomspur> Would it be possible to add also a filter, so, e.g. remove only /usr/bin/env shebangs, but not the rest?
16:16:53 <geppetto> That's like if  -l == foo ; then -d … right?
16:17:21 <ignatenkobrain> geppetto: rather -l + some sed to remove env part
16:17:22 <geppetto> A real draft change could maybe have an example with that in
16:17:33 <geppetto> Ugh
16:17:48 <tomspur> and similar for -r<path> to replace a specific shebang
16:18:02 <ignatenkobrain> -l is to print, -r is to replace and -d is to delete
16:18:15 <geppetto> #info Everyone seems happy with the general idea.
16:18:23 <ignatenkobrain> probably we want to add -f/--fixup which would drop /env/ part
16:18:40 <geppetto> #action ignatenkobrain A real draft we can vote on would be cool, including an example or two
16:18:50 <ignatenkobrain> ack
16:19:28 <geppetto> Anything else anyone wants to say?
16:20:03 <Rathann> nope
16:20:22 <geppetto> #topic #559 Ban use of rich dependencies
16:20:25 <geppetto> .fpc 559
16:20:28 <zodbot> geppetto: Issue #559: Ban use of rich dependencies - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/559
16:20:39 <geppetto> This really needed a new ticket and not to zombie the old one. *sigh*
16:20:46 <tibbs> Sorry, I keep getting called away.
16:20:54 <geppetto> tibbs: no problem
16:21:08 <tibbs> I need to add my thoughts to 720 but I do quite agree with the concept.
16:21:21 <geppetto> So, I assume the issue here is you want to undo this and allow rich deps. now?
16:21:43 <geppetto> But didn't we already do that, at least in some limited way?
16:21:44 <ignatenkobrain> geppetto: exactly
16:22:09 <ignatenkobrain> we did, but only for Supplements/Enhances (reverse weakd eps)
16:22:15 <tibbs> We allowed certain rich deps.  We are just waiting for releng to tell us that they actually work before allowing them everywhere.
16:22:22 <ignatenkobrain> it works perfectly in rawhide and now it works perfectly when packages go through the bodhi
16:22:28 <ignatenkobrain> so now we can finally remove this restriction
16:22:38 <ignatenkobrain> tibbs: and releng did this
16:22:42 <geppetto> Ok, so you want to just let anyone put any rich deps. into packages now?
16:22:45 <ignatenkobrain> check the ticket =)
16:23:00 <ignatenkobrain> +
16:23:02 <ignatenkobrain> yeah
16:23:03 <tibbs> Yes, just yesterday. I've only be back in the country for a day and haven't been able to read everything.
16:23:16 <tibbs> So I don't think we even need a vote on this.  If they work, we're good.
16:23:22 <ignatenkobrain> tibbs: sure, that's fine ;)
16:23:24 <tibbs> This also unblocks the rust guidelines.
16:23:33 <ignatenkobrain> yeah, and this is the next my topic ;)
16:23:39 <geppetto> I mean we should probably vote, given we voted before to clock them.
16:24:01 <geppetto> Proposal: Allow rich deps. now infra. can handle them.
16:24:04 <geppetto> +1
16:24:06 <tibbs> Well, we voted to block them until such time as the ban was no longer needed.
16:24:08 <tibbs> But sure, +1.
16:24:11 <tomspur> +1
16:24:12 <Rathann> +1
16:24:21 <mbooth> +1
16:24:37 <geppetto> #action Allow rich deps. now infra. can handle them (+1:5, 0:0, -1:0)
16:24:38 <tibbs> Also, do we know whether this is limited to any specific Fedora release(s)?
16:24:39 <geppetto> Ok, done.
16:24:56 <geppetto> #topic #705 Rust Packaging Guidelines
16:24:59 <geppetto> .fpc 705
16:24:59 <ignatenkobrain> tibbs: as far as I know, not. DNF is default since F25 so it is safe to put it even there
16:25:03 <zodbot> geppetto: Issue #705: Rust Packaging Guidelines - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/705
16:25:14 <geppetto> epel 7 would be bad
16:25:22 <ignatenkobrain> bodhi uses pungi everywhere now, so from infra PoV is fine
16:25:25 <ignatenkobrain> geppetto: good point, youare right
16:25:25 <geppetto> but fedora is fine.
16:25:38 <tibbs> EPEL guidelines can get a note about it, I guess.
16:25:53 * ignatenkobrain is not really thinking about EPEL when doing things
16:26:00 <ignatenkobrain> tibbs: +1
16:26:09 <Rathann> 705 was approved, but blocked on rich deps ban drop
16:26:22 <geppetto> Yeh, nothing to actual do
16:26:28 <ignatenkobrain> just wanted to say this =)
16:26:35 <tibbs> Yes, 705 is good to go and I'll just write it up and announce it when I do the other thing.
16:26:36 <geppetto> #info Just a note that this is unblocked now as rich deps. are fine in infra.
16:26:40 <gholms> #idea Add a note about rich deps to the EPEL guidelines
16:26:45 <ignatenkobrain> geppetto: someone should move page under Packaging: and add link to main guidelines page
16:27:00 <geppetto> Yeh, it's in writeup
16:27:05 <tibbs> Yes, that will be me.
16:27:21 <tibbs> I have some time set aside this evening.  At least that's the plan.
16:27:33 <ignatenkobrain> tibbs: you do so much this paperwork =)
16:27:53 <tibbs> Sadly I'm quite behind.  But this gives me a really good reason to go in and take care of some of it.
16:28:34 <geppetto> #topic #715 Separately building package documentation
16:28:37 <geppetto> .fpc 715
16:28:38 <zodbot> geppetto: Issue #715: Separately building package documentation - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/715
16:28:55 <geppetto> So the info. from people that have done it seems to be "eh, not a big deal"
16:29:18 <ignatenkobrain> thank y'all, gotta run. Have good rest of the meeting and day/night!
16:30:21 <Rathann> take care, ignatenkobrain
16:30:33 <geppetto> ignatenkobrain: thanks
16:30:54 <geppetto> On the other hand I know python did this for a long time (might still do so)
16:31:01 <tibbs> No matter how often I say that this isn't about bootstrapping, people talk about bootstrapping.
16:31:15 <tibbs> It's not about bootstrapping.
16:31:16 <geppetto> And I don't see any reason to frown on it … just not sure how much we want to push it.
16:31:31 <geppetto> :-o
16:31:35 <tibbs> There's a difference between pushing something and offering guidance, though.
16:31:46 * geppetto nods
16:32:08 <tibbs> I think the modularity people would want to push it, though.
16:32:15 <geppetto> So you think we should say that if there are any docs. related deps. you should do two packages?
16:32:17 <Rathann> I have nothing against it, as long as it's understood that the docs should be kept in sync with the main pkg
16:32:44 <geppetto> tibbs: eventually, some modules might want to push down on their rpms yeh
16:32:58 <tibbs> Our guidelines currently have nothing against it, either, so we can certainly just ignore it and let people do it organically.[
16:33:27 * geppetto nods … I'm happy to look at some wording prodding people in the right direction, if you can think of anything?
16:33:45 <tibbs> I don't think that we would want to force some kind of splitting just because doc building has additional dependencies.
16:33:47 <Rathann> "If building documentation requires many additional dependencies then you may choose to create a separate src.rpm package just for building documentation independently."
16:34:08 <Rathann> or something like that
16:34:11 * geppetto nods
16:34:13 <Rathann> added to https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation
16:34:45 <tomspur> Offering this as a guideline seems fine. I hope this will never become a "you should do it this way for all docs packages"
16:34:46 <tibbs> I would think we'd need some statement about keeping things syncronized.
16:34:59 <tibbs> It would be insane to do it for all docs packages.
16:35:33 <tibbs> But some of these utilities go from needing gcc and glibc-devel to needing about 2000 packages just because of documentation.
16:36:10 * geppetto nods
16:36:18 <Rathann> https://pagure.io/packaging-committee/issue/715#comment-467458 speaks about test suites, but test suites don't produce any artifacts, so bootstrapping guidelines apply here
16:36:45 <tomspur> +1
16:38:05 <tibbs> The entire idea was to concentrate on documentation only, and not to mention test suites.
16:38:17 <Rathann> right
16:38:24 <tibbs> That ticket was doomed to be derailed, I guess.
16:38:59 <tibbs> Anyway, I like what Rathann wrote, but it does need something about "MUST keep synchronized".  The problem is in how to word that.
16:39:41 <geppetto> yeh, and there's no good way to make sure that happens.
16:40:22 <Rathann> "Please note that you must keep the documentation-only package synchronized with the main package in that case."
16:40:32 * geppetto nods
16:41:11 <tibbs> But since the documentation often does not change between package changed, "synchronized" is fuzzy.
16:41:27 <Rathann> for example, by adding a strict version dependency in foo-doc.spec - Requires: foo = %{version}
16:41:56 <tibbs> I don't think a version dependency is necessary, or even desired, really.
16:42:11 <Rathann> that's a valid point, yes
16:42:18 <tibbs> You should be able to install a documentation package and look at it without needing the software, at least in most cases.
16:42:35 <Rathann> ok, scratch that, then
16:42:41 <tibbs> If it's in some weird format and you need the program itself to browse the documentation, that would make sense.
16:43:00 <gholms> "Conflicts: foo != %{version}"?
16:43:21 <tibbs> "The separately packaged documentation MUST always correspond to the packaged software."
16:43:46 <tibbs> Or something like that.  The idea is that the docs you package must actually document the version of the software you package.
16:44:12 <tibbs> But if a package goes from foo-1.2.3 to foo-1.2.4 with no doc changes, then it would be perfectly fine to not touch the documentation package.
16:45:05 <Rathann> I like tibbs' idea
16:45:27 <tibbs> Anyway, let me write some stuff in the ticket and we can talk about it later.  It's certainly not urgent.
16:46:29 <Rathann> sure
16:50:08 <mbooth> So is there a known set of packages for which this would be useful for the modularity effort?
16:51:07 <tibbs> The modularity people have a list, I think.
16:53:31 <tibbs> contyk is at least in the channel; he's who gave the talk at Flock where we talked about this.
16:54:05 * contyk blinks
16:54:20 <contyk> sorry, wasn't watching this meeting; what's the topic?
16:54:41 <contyk> ah, documentation
16:54:48 <tibbs> contyk: Do you recall that we talked at flock about splitting out documentation to separate packages to reduce the modularity self-hosting set?
16:54:54 <contyk> no, that was asamalik, not me, although it's an interesting topic
16:55:05 <tibbs> I swear we talked in the hall about it.
16:55:05 <contyk> tibbs: I do, yes
16:55:18 <contyk> tibbs: we did but it wasn't me who gave the talk :)
16:55:49 <tibbs> I've sort of forgotten the talk but I remember our conversation.
16:56:17 <tibbs> In any case, I recall that you had some list of which packages have these enormous deplists just for building documentation.
16:56:30 <tibbs> If you do then it would be nice to have that handy.
16:56:33 <geppetto> Well adam is back tomorrow
16:56:59 <contyk> we don't have a list like that, we do have lists of packages that we pull into the selfhosting buildroot and we can generate dependency graphs for those, however
16:58:01 * geppetto nods
16:58:19 <contyk> typically packages that need sphinx to build their documentation have a recursive build dependency chain much larger than they could
16:58:20 <tibbs> I recall that the bulk of the self-hosting set is needed just to build texinfo docs.
16:58:40 <contyk> texinfo might be another example indeed
16:59:06 <contyk> but I really cannot point you at a specific list of packages that cause the most grief; I don't even have criteria for that :)
16:59:17 * jkurik just would like to inform - there is going to be go/no-go meeting in 1 minute on this channel :-)
16:59:32 <geppetto> jkurik: Yeh
16:59:36 <tibbs> We usually have this channel reserved for two hours.
16:59:37 <geppetto> #topic Open Floor
16:59:52 <geppetto> tibbs: Since we moved to alternate days on weeks we only did 1 hour
16:59:57 <tibbs> Ah, OK.
17:00:06 <geppetto> I think we are done anyway
17:00:09 <tibbs> Anyway, I have plenty on my plate so I'm happy to stop now.
17:00:15 * geppetto nods
17:00:28 <geppetto> #endmeeting