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