fpc
LOGS
16:00:12 <geppetto> #startmeeting fpc
16:00:12 <zodbot> Meeting started Thu Sep 14 16:00:12 2017 UTC.  The chair is geppetto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:12 <zodbot> The meeting name has been set to 'fpc'
16:00:12 <geppetto> #meetingname fpc
16:00:12 <geppetto> #topic Roll Call
16:00:12 <zodbot> The meeting name has been set to 'fpc'
16:00:38 <mbooth> yo
16:00:44 <tibbs> Howdy.
16:00:49 <geppetto> #chair tibbs
16:00:49 <zodbot> Current chairs: geppetto tibbs
16:00:52 <geppetto> #chair mbooth
16:00:52 <zodbot> Current chairs: geppetto mbooth tibbs
16:00:56 <geppetto> Hey
16:01:01 <tibbs> Sorry, have been trying to debug nfs hangs this morning.
16:01:07 <geppetto> no problem
16:01:24 <geppetto> I feel like we should all buy you a drink ;)
16:01:38 <geppetto> You doing git disect?
16:03:16 <geppetto> #chair racor
16:03:16 <zodbot> Current chairs: geppetto mbooth racor tibbs
16:04:35 <ignatenkobrain> .hello2
16:04:36 <zodbot> ignatenkobrain: ignatenkobrain 'Igor Gnatenko' <ignatenko@redhat.com>
16:04:53 <geppetto> Hey
16:05:10 <geppetto> ignatenkobrain: You done a dnf build in dist-git today ?:)
16:05:51 <orionp> barely here, very busy with work these days...
16:05:58 <geppetto> #chair orionp
16:05:58 <zodbot> Current chairs: geppetto mbooth orionp racor tibbs
16:06:07 <orionp> (and has the same nfs problems as tibbs)
16:06:12 <tibbs> geppetto: It's a gssproxy/rpc.gssd problem.  Do kerberos.  orionp probably cares a lot.
16:06:21 <geppetto> Well you do make 5 … want to go on or wait a few more mins. for a 6th?
16:07:06 <ignatenkobrain> geppetto: not really, why?
16:07:39 <ignatenkobrain> geppetto: I do some builds from the beach, but try to not touch work-related stuff like dnf ;)
16:08:40 <geppetto> ignatenkobrain: Ok, not attending FPC meetings is fine too :)
16:09:27 <ignatenkobrain> I'm burning, so got into the room with air conditioning 🙂and just listening here ;)
16:10:04 <geppetto> #tpoic Schedule
16:10:09 <geppetto> #topic Schedule
16:10:11 <geppetto> https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/message/IA5YL2OHNKU2SDZAQ36O5INISWQWDJ35/
16:10:20 <geppetto> #topic #704 wiki/Packaging:AppData is outdated
16:10:24 <geppetto> .fpc 704
16:10:24 * limburgher was in the wrong room
16:10:25 <zodbot> geppetto: Issue #704: wiki/Packaging:AppData is outdated - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/704
16:10:33 <geppetto> #chair limburgher
16:10:33 <zodbot> Current chairs: geppetto limburgher mbooth orionp racor tibbs
16:11:40 <ignatenkobrain> my opinion on this that we should not disallow /usr/share/appdata, but make /usr/share/metainfo as SHOULD and /usr/share/appdata as COULD
16:11:42 <ignatenkobrain> or something like this
16:11:56 <ignatenkobrain> RPM provides generator works with both locations
16:12:37 <geppetto> is there any reason for people to continue using the old path?
16:13:39 <mbooth> well, upstream considers that path "legacy": https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html
16:13:48 <limburgher> Maybe just a SHOULD and a Legacy
16:13:50 <limburgher> Jinx
16:14:19 <mbooth> " For new software components, it is advised not to use this directory. "
16:15:12 <geppetto> Yeh, I'm just trying to work out if there's a reason we shouldn't just say MUST … it's not like we shoot people for breaking the rules, or not obeying the new rules fast enough
16:15:30 <geppetto> If there's an ok reason to use the old path I'm happy to have it be SHOuLD instead
16:16:22 <geppetto> otherwise +1 on the draft.
16:16:23 <tibbs> Is there any issue with compatibility across current Fedora releases?
16:17:01 <geppetto> My understanding is upstream changed a bit ago, and Fedora is catching up … so I'd assume only with CentOS-7
16:17:53 <geppetto> Anyone else want to vote? mboot did in the ticket, I assume nothing changed
16:18:11 <limburgher> +1
16:18:24 <mbooth> geppetto: Yeah, no change from me
16:19:25 <tibbs> My only concern is that if we do MUST then we get more EL7-specific ifdefs.
16:20:10 <tibbs> But the draft is SHOULD, so I guess there's no issue.
16:20:23 <tibbs> Or am I misreading?
16:22:01 <geppetto> I don't see either
16:22:05 <geppetto> on the draft
16:22:10 <geppetto> it just gives the single path name
16:22:37 <geppetto> Ahh, right at th etop … it says should
16:22:47 <geppetto> ¯\_(ツ)_/¯
16:23:00 <tibbs> +1
16:23:22 <tibbs> Sorry, two different people in the office plus this NFS thing still going on.
16:23:36 <racor> +1
16:23:53 <geppetto> Ok that's 5 … orionp want to vote?
16:23:59 <orionp> +1
16:24:07 <geppetto> #action  #704 wiki/Packaging:AppData is outdated (+1:6, 0:0, -1:0)
16:24:18 <geppetto> #topic #708 Allocating a static uid and gid for openvswitch
16:24:20 <geppetto> .fpc 708
16:24:22 <zodbot> geppetto: Issue #708: Allocating a static uid and gid for openvswitch - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/708
16:24:37 <vondruch> hi
16:25:07 <limburgher> Still waiting for info on this one?
16:25:18 <geppetto> Why do the userids have to match outside and inside the VM?
16:25:44 <tibbs> I don't know.
16:26:13 <limburgher> I'm skeptical; often people say that and mean username.
16:26:19 <tibbs> That was my guess as to why it might be needed, but no response from them means that it's still just a guess.
16:26:19 <geppetto> I'm going to assume dynamic is fine
16:26:49 <geppetto> #topic #710 Ruby packaging guidelines update
16:26:53 <geppetto> .fpc 710
16:26:54 <zodbot> geppetto: Issue #710: Ruby packaging guidelines update - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/710
16:28:24 <limburgher> Unless I'm missing something, this looks reasonable.
16:29:11 <geppetto> yeh, looks like basically cleanups
16:29:27 <geppetto> I've never used ruby or packaged it … but I'm fine with it. +1
16:29:53 <vondruch> the changes should make the .spec file cleaner
16:30:01 * geppetto nods
16:30:24 <vondruch> and the RPM improvements should allow to avoid collisions between generated .gemspec and possibly available upstream .gemspec file
16:30:31 <mbooth> Hmm, and shorter guidelines too, yay :-)
16:31:19 <tibbs> Yes, this helps clean things up a bit.
16:31:35 <tibbs> But.... no released version of Fedora has RPM  4.14, so....
16:32:07 <vondruch> there might be one related breaking change in rubygems macros, but it should be just a few packages to fix
16:32:21 <vondruch> tibbs: this should be F27+
16:32:33 <geppetto> vondruch: Does this work everywhere?
16:32:34 <geppetto> Ahh
16:32:50 <vondruch> tibbs: and there was alway reference to de older guidelines on top of the page
16:33:16 <tibbs> I'm just reading the diff.
16:33:22 <vondruch> geppetto: the older guidelines still works everywhere ... the new works just F27+
16:33:47 <vondruch> but I hope you won't postpone the decission just based on this ....
16:33:55 <tibbs> But wouldn't we want to now refer to what's now the current guidelines?
16:34:05 <vondruch> tibbs: yes!
16:34:21 <vondruch> https://fedoraproject.org/wiki/Packaging:Ruby
16:34:22 <tibbs> How we have three different sets of guidelines.
16:34:29 <tibbs> "Now".
16:34:36 <vondruch> there is "Different Guidelines for Fedora 19/20 and EPEL6/7"
16:34:38 <vondruch> on top
16:34:53 <tibbs> And now we would have to have three.
16:35:02 <vondruch> it should be modified to "Different Guidelines for Fedora up to including 26 and EPEL6/7
16:35:04 <tibbs> That's getting a bit unpleasant.
16:35:45 <vondruch> tibbs: ok, there might be note that the old still works ... but new are preffered
16:36:03 <geppetto> Can you not get the macros/rpm changes added to F26?
16:36:25 <tibbs> Not sure that's entirely possible.
16:36:30 <geppetto> Publishing new guidlines now that break on F26 seems like a bad idea.
16:36:34 <tibbs> I think it's more than just new macros.
16:36:41 <vondruch> geppetto: eh ... that is the thing that EPEL7 now supports most of the macros
16:37:00 <geppetto> tibbs: there's the rpm unpacking … and I gthink that's it
16:37:02 <vondruch> geppetto: so the box on the top is not precise anymore
16:37:30 <vondruch> I can't do nothing about the RPM unpackging, since that is RPM stuff
16:37:49 <geppetto> #info These guidlines only work on F27+
16:37:52 <vondruch> and that is how it is ... older fedoras/rhels get old ....
16:38:01 <geppetto> vondruch: You can ping rpm maintainers and ask them to backport to F26
16:38:15 <tibbs> What we should do is stop referring to a version from the wiki history, and instead either list the differences in the main document, or refer to a separate document that details just the differences.
16:38:38 <vondruch> geppetto: eh :) I got promise like two years ago to get it in Fedora and it is finally there
16:38:48 * geppetto nods
16:39:04 <tibbs> Right now is that it's completely unclear to me what actually works where.
16:39:08 <geppetto> Just that I thought this would be a quick ticket … but now it's less simple :(
16:39:08 <vondruch> tibbs: I don't think it makes the matter easier
16:39:19 <tibbs> Maybe not for you since you know what the differences are.
16:39:36 <tibbs> But for someone who doesn't, the situation would be pretty bad.
16:39:56 <tibbs> "Read throgh these three long pages and figure out for yourself what needs to change to accommodate different distro versions."
16:40:21 <vondruch> tibbs: well, gem2rpm does the right thing for specific versions ...
16:40:27 <geppetto> vondruch: Can you try to get stuff in F26, or fixup the policy so that someone packaging something for F26 won't do the wrong thing? Or just wait a few weeks?
16:41:02 <geppetto> I'm kinda fine with having this as is when F27 is GA
16:41:06 <tibbs> I don't object to mentioning that "in F27+, you can do this instead" or "For <= F26, you must do this instead".
16:41:28 <tibbs> But just saying "for actual current Fedora releases, read this other thing" isn't particularly friendly.
16:41:58 <vondruch> geppetto: ok, if I modify the guidelines for F26 to simulate what the %setup macro allows us to do now
16:42:07 <vondruch> geppetto: and note the difference
16:42:28 <vondruch> geppetto: then 1) it will get confusing, since most of the packages in F26 wont be updated anyway
16:42:47 <vondruch> geppetto: and people packaging new stuff for F27+ will be confused again
16:43:09 <vondruch> geppetto: but if that is the way to go, I'll change it although I'm not seeing point in it
16:43:30 <vondruch> geppetto: everything else should work on F25+ just fine
16:44:42 <vondruch> geppetto: except the %setup macro, this is more to align the guidelines with current reality then anything else
16:46:13 <geppetto> vondruch: Ok, if everyone else works on F25+ I'd say just have two sections for the setup bit … and we can delete the old one later
16:46:41 <geppetto> #action vondruch Will change guideline to apply to F25+, via. split setup section.
16:46:48 <geppetto> #topic #713 Forward-looking conditionals by default
16:46:49 <vondruch> ok
16:46:52 <geppetto> .fpc 713
16:46:53 <zodbot> geppetto: Issue #713: Forward-looking conditionals by default - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/713
16:47:06 <vondruch> will work on that l ;)
16:47:09 <vondruch> thx
16:47:24 <limburgher> I don't see a new draft.
16:47:30 <geppetto> Hmm, nothing to do here … igor should enjoy time off :)
16:47:32 <geppetto> #topic #714 let's kill file deps!
16:47:35 <geppetto> .fpc 714
16:47:37 <zodbot> geppetto: Issue #714: let's kill file deps! - packaging-committee - Pagure - https://pagure.io/packaging-committee/issue/714
16:50:16 <tibbs> I guess I understand the point of this, and honestly it wouldn't require changes to very many packages (as detailed in the ticket itself).
16:51:11 <tibbs> But it would basically have no effect because the changes required to dnf to make it not download the extra metadata may not even be reasonably possible.
16:52:06 <geppetto> I'm happy to +1 banning filedeps outside of the bin optimisation
16:52:16 <geppetto> But I'm sceptical it will do anything
16:52:32 <geppetto> without some kind of automatic build failure QA thing
16:53:01 <tibbs> We kind of used to have that.
16:53:58 <tibbs> Now we just have " Whenever possible you SHOULD avoid file and directory dependencies as they slow down dependency resolution and require the package manager to download file lists in addition to to regular dependency information."
16:54:19 <tibbs> Which, sadly, isn't even true because dnf dropped that optimization rather early in its lifetime.
16:54:53 <racor> I am totally opposed to this proposal
16:55:35 <tibbs> I think the problem with dnf is that we really would have to outright ban much of the file dependencies in order for that optimization to be possible.
16:55:45 <racor> It's utter nonsense
16:55:50 <geppetto> racor: Of just banning arbitrary filedeps … still allowing /usr/bin/foo though?
16:56:01 <racor> yes
16:56:30 <racor> /usr/bin/foo can be provided by different packages
16:56:41 <geppetto> tibbs: That's only true if you always upgrade everything
16:56:42 <racor> more so /usr/share/*
16:56:58 <geppetto> tibbs: If you upgrade specific things the optimization helps a lot more
16:57:27 <tibbs> I think it's simply not feasible with the way dnf is designed for it to realize that it has a file dependency outside of the metadata it has and fix that by downloading more metadata.
16:57:40 <geppetto> racor: So you want to make the packaging UI even worse than it is now for no appreciable gain?
16:57:56 <geppetto> I mean we've had virtual requires for well over a decade, for a reason
16:58:05 <geppetto> virtual provides and requires.
16:58:07 <racor> more abstract: there is a strict <package> -> <file> mapping
16:58:19 <tibbs> Well, the idea is that if you use a file dependency then you can just specify the thing you want and not have to worry about what package it might be in today.
16:58:39 <racor> but there is *NO* strict <file> ->  <package> mapping
16:58:40 <geppetto> tibbs: that's for the DNF people to fix, or give up.
16:58:45 <tibbs> But honestly I think the instances of things moving around like that are sufficiently rare that it's not a big deal.
16:59:04 <racor> => the rationale this proposal is based on, is flawed
16:59:05 <tibbs> geppetto: But the problem is... why would we do this at all if the dnf devs will never fix it?
16:59:14 <limburgher> tibbs: THIS
16:59:15 <sgallagh> tibbs: Except when, say, we switch from Python2->Python3 for things
16:59:49 <tibbs> We lose the feature which can be useful to prevent some ifdefs in some cases (which to me isn't a huge deal, but it is nonzero).
16:59:50 <sgallagh> Or when we switched from python-foo to python2-foo (that caused problems for my shared EPEL packages, let me tell you)
16:59:54 <tibbs> We get, well, absolutely nothing.
17:00:11 <geppetto> sgallagh: virtual provides should have solved that … and the file paths changed anyway
17:00:33 <tibbs> The problem is that you can't just add virtual provides to RHEL7.
17:01:11 <geppetto> #info There is little chance that we as FPC can just ban file deps. outright, so that leaves fixing the major problems with them.
17:01:13 <tibbs> But you're right that the paths change anyway such that, really, the python-X python2-X situation isn't a great example.
17:01:56 <geppetto> #info DNF currently doesn't implement the yum optimization, so our current wording of asking people to avoid non-main file deps. does little and increasing the severity of that wording will do nothing.
17:02:41 <tibbs> Someone should certainly look more closely to the current uses of file deps to understand why they exist.
17:02:54 <tibbs> Some of them might have no reasonable basis at all.
17:03:09 <geppetto> #action mattdm So speak to the DNF team and see if they can fix the optimisation compatibility, or maybe FESCO to have a flamewar about killing filedeps entirely.
17:04:01 <tibbs> I believe two current dnf devs have already commented on that ticket.
17:04:10 <geppetto> Ok, it's been over an hour … do we want to do 715 or wait until next week?
17:04:15 <tibbs> But maybe I'm misunderstanding who is a dnf dev at this point.
17:04:50 <tibbs> 715 isn't urgent; it's more of topic for discussion.
17:05:52 <geppetto> #topic Open Floor
17:06:03 <geppetto> Ok, anyone want to shout about anything before lunch?
17:07:16 <tibbs> Not me.
17:10:38 <geppetto> Ok, thanks for coming everyone
17:10:41 <geppetto> #endmeeting