17:03:44 #startmeeting Fedora Packaging Committee 17:03:44 Meeting started Thu Feb 27 17:03:44 2014 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:03:44 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:03:47 #meetingname fpc 17:03:47 The meeting name has been set to 'fpc' 17:04:08 Howdy. 17:04:27 Greetings 17:04:29 #chair abadger1999 Rathann geppetto tibbs|w SmootherFrOgZ 17:04:30 Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto spot tibbs|w 17:05:01 * SmootherFrOgZ waves 17:05:11 yippie ki yay? 17:05:51 i count 6, assuming Rathann is actually here. :) 17:06:37 I am 17:06:38 even if not, that's quorum. lets start running the agenda 17:06:57 #topic Software collections in Fedora (https://fedorahosted.org/fpc/ticket/339) 17:06:58 #chair limburgher 17:06:59 Current chairs: Rathann SmootherFrOgZ abadger1999 geppetto limburgher spot tibbs|w 17:07:17 I have a working python2.4 SCL in http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/ 17:07:19 anything to do on this one right now? 17:07:35 Been working with Jan Zeleny to iron out the questions and problems I encountered with those. 17:07:43 Updating the draft as we fix them. 17:07:47 Nothing to vote on this week. 17:07:50 EOF 17:07:57 Do we still need a LANANANANANANANANANA registration? 17:08:04 spot: ah -- yes we do. 17:08:24 I think marcela was looking for that at one point, do i need to handle it? 17:08:46 * spot needs to go afk for a few minutes... brb 17:08:52 We'll probably want something that we can use in package names (like fdr) and maybe something longer for the filesystem (like fedoraproject). 17:09:07 spot: mmaslano hasn't mentioned anyhting to me about registering the names. 17:09:16 I'll email her with you on the CC. 17:11:54 * limburgher here, in space cadet mode. 17:12:32 back 17:13:06 #topic Go Packaging Draft - https://fedorahosted.org/fpc/ticket/382 17:13:33 It looks like there was a post from abadger1999 on this today-ish tossing it back to them for changes 17:13:49 17:13:56 so, we'll wait for changes. :) 17:14:03 :) 17:14:10 mattdm was going to read the logs from the meeting but I didn't see an update so I tossed the info into the ticket. 17:14:18 #topic workarounds for rpm symlink <-> directory issue - https://fedorahosted.org/fpc/ticket/385 17:14:58 it looks like there were some draft changes to reflect panu's comments 17:15:00 Is all that remains to decide to use .rpmsave or whatever? 17:15:05 https://fedoraproject.org/w/index.php?title=User:Patches/PackagingDrafts/Symlink_Workarounds&diff=370735&oldid=370560 17:15:50 I'm happy with .rpmsave; I don't think it implies anything other than that rpm has moved something out of the way. 17:15:57 Agreed. 17:15:58 I really like the %ghost trick, though. 17:16:04 * spot nods 17:16:23 Current draft is here: https://fedoraproject.org/wiki/User:Patches/PackagingDrafts/Symlink_Workarounds 17:16:28 I guess we have no problems with predictable filenames in user-writable locations. 17:16:55 Only remaining question is what happens if the .rpmsave directory already exists. 17:17:31 Isn't that tested for? 17:17:41 Oh, it's not. It could be. 17:17:45 Doesn't appear to be. 17:18:18 I guess if it exists and is a directory, we don't have a problem. 17:18:30 we don't? 17:18:39 one potential point of confusion is that someone may think they need to put paths in angle brackets <> 17:18:46 because of -p 17:18:47 Wouldn't os.rename put the thing we're moving inside of the existing directory, then? 17:18:58 * RemiFedora is here (late again) 17:19:00 Rathann: Good point. 17:19:17 Rathann: Can change into /path/to/dir/ 17:19:43 Yeah, anything to avoid using angle brackets, since that is confusing if you don't have the context. 17:20:05 geppetto: that should be fine 17:20:08 tibbs: Kind of, assuming it's on the same mount point and there is no dir. of that name inside … but it seems kind of bad anyway 17:20:27 geppetto: Yeah, I just don't know if it's something we should worry about. 17:20:31 tibbs: On the other hand I'm not sure what to do … rm -rf .rpmsave first doesn't seem that awesome 17:20:38 And it's not like we can fail at this point. 17:20:44 And you can't call out to rm. 17:21:02 Ahh, yeh, pretrans 17:21:09 is it worth of a "printf" equivalent? 17:21:25 something like ".rpmsave exists? omgwtfbbq!" 17:21:33 Yeh, at least 17:21:48 * spot calls "not it" on learning how to do that in lua 17:21:54 Could just rename any existing one to some random suffix, I guess. 17:21:56 I guess we could try mkdtmp() + ".rpmsave" at that point 17:22:01 Yes. 17:22:06 We could call out to rm -rf but yeah, it doesn't seem that awesome. 17:22:13 abadger1999: pretrans 17:22:15 * Rathann reminds that rpm scriptlet output might not be read by anyone if there's no terminal 17:22:23 Rathann: true 17:22:28 Yes, there's nothing we can really do here. 17:22:30 Rathann: That's what yum history is for :) 17:22:42 geppetto: But -- the case where we call rm -rf is only taken when the system is already installed. 17:22:48 right 17:22:53 So, we either corner case it with a mkdtmp name, or we just ignore it and roll on 17:22:58 I would suggest that if we have to consider this we rename to something random. 17:23:06 abadger1999: Bah, you are correct … too much magic :) 17:23:07 * nirik notes lua does have a 'unlink' (ie, rm) 17:23:20 It will only happen if this needs to somehow happen twice with one package. 17:23:23 -- unlink is just not recursive. 17:23:26 nirik: it doesn't have rm -rf though 17:23:38 ok 17:23:54 tibbs|w: Sure, like sha512 of the epoch? 17:24:02 Rather time since epoch 17:24:09 I thought we had mkdtmp(). 17:24:23 does it perhaps make more sense to do the pseudocode equivalent of "if .rpmsave found, then rename old .rpmsave to .rpmsave-tmp8675309 first." 17:24:41 possibly using the original datestamp of the existant file? 17:24:53 (presumably that is very unlikely to be the same) 17:25:01 Not sure which is better to keep in the "known" location 17:25:01 I think whatever is simplest which avoids any potential catastrophe. 17:25:15 And, honestly, I'm willing to pass this ignoring the issue for now, and then modify later. 17:25:18 * spot would argue the _latest_ is most likely what is wanted in known 17:25:19 okay, we will have to do something if the dir already exists, lua's os.rename() fails (silently?) if the directory already exists. 17:25:36 Because of the %ghost thing it might be better to rename the old one, as then it won't get removed on package uninstall 17:25:48 spot: +1 17:26:19 anyone feel like writing some lua? *ducks* 17:26:34 * abadger1999 volunteers to fall down the rabbit hole 17:26:52 If I knew how.... I'm sure this is pretty simple if you know the language and limited library calls you can make in this situation. 17:26:57 abadger1999: good for you. hope you've got a helmet. :) 17:27:08 :-) 17:27:15 hah 17:27:18 so, we'll table that until we get that corner case addressed. 17:27:33 Moving on. 17:27:47 #topic Recommend %autosetup over %setup - https://fedorahosted.org/fpc/ticket/388 17:29:35 The draft text on this one is weak. it basically says "everything^W%autosetup is awesome! use it!" 17:30:09 * spot would prefer to see wording that covers why it is preferred, and any caveats (like the need for additional BR in the VCS cases) 17:30:17 Yes, I agree, but there's a good question in there. 17:30:20 spot: +1 17:30:27 * RemiFedora nodws 17:30:41 spot: agreed 17:31:01 and if i'm reading panu's comment correctly, we probably want to discourage use of -S VCS as it interferes with each packager making their own choice. 17:32:24 abadger1999: well, i think discourage might not be the right word 17:32:40 if all the patches are git format, -S git is fine 17:32:48 In any case more info is needed. 17:32:57 http://www.rpm.org/wiki/PackagerDocs/Autosetup has the meat 17:33:38 I guess we could mention it as an alternative to %setup so that people are aware, but include Panu's reply from the ticket 17:35:32 Folks, I'm lagging. 17:35:41 spot: I think panu is saying more than that... if the spec file has %autosetup -S bzr but someone else is working on the package, they might want to use git for their work. 17:36:28 "-S VCS should probably be considered a special case to be used only when the package actually relies on that specific VCS - ie fails to build correctly (incompatible patch format or whatever" 17:36:38 "As an alternative, %autosetup exists in current versions of Fedora (RPM 4.11+) and will apply all defined Patch# items in the spec automatically. It is also capable of handling VCS formatted patch files, but this will require additional BuildRequires, and assumes that _all_ patch files in the spec are formatted for that single VCS type. For this reason, we generally do not recommend that you specify a VCS with %autosetup. For more details on proper use 17:36:38 of %autosetup, see http://www.rpm.org/wiki/PackagerDocs/Autosetup" 17:37:15 s/apply all/(in addition to the normal %setup tasks), will apply all/ 17:38:04 sounds ok to me 17:39:05 +1 from me 17:39:09 I don't think the VCS postion of that sounds right... I mean, we wouldn't want binary patch formats that are specific to the VCS to be in the spec file, right? 17:39:19 err.. in hte rpm package. 17:39:34 s/generally// 17:39:40 -S git seems usefull to apply git patch, especially binary one => but I agree this is a corner case, and I agree with "we generally do not recommend..." 17:39:45 abadger1999: i'm at least aware of some git specific format files being used today 17:39:58 So just "For this reason, we do not … " 17:40:03 +1 17:40:05 spot: are they readable as a patch as well? 17:40:12 abadger1999: i _think_ so 17:40:30 +1 17:40:32 +1 17:40:43 abadger1999, some fit patch apply "partially" with old patch command, and fails with "recent" patch version 17:40:45 abadger1999: patch can take git patches as input … but git itself does more checking 17:40:50 s/fit/bin/ 17:41:26 i see +4 on this mini-draft 17:41:34 (with s/generally// 17:42:00 +1 (if not yet count as +1) 17:42:12 +1 17:42:17 +1 from me 17:42:37 +0 17:42:45 abadger1999: why the +0? 17:43:18 since it doesn't need me to pass and I still don't really like the VCS portion... but since it'll pass now I can work on an updateto that if I get some free time later. 17:43:29 wfm 17:43:54 #action spot's mini-draft approved (+1:7, 0:1, -1:0) 17:45:32 #topic Exception for bundled libs in icecat - https://fedorahosted.org/fpc/ticket/391 17:46:15 fwiw, since firefox has a blanket exception for bundling, i'm inclined to apply that to icecat as well. 17:46:27 I don't think we can be unfair about it, indeed. 17:46:36 so +1 17:47:07 firefox has a blanket bundling exception? 17:47:15 abadger1999: fesco did that 17:47:20 It sort of predates us. 17:48:08 https://fedorahosted.org/fesco/ticket/472#comment:16 17:48:18 Was there another ticket after that? 17:49:42 i swear there was 17:49:45 firefox even bundles xulrunner... 17:49:48 * spot is trying to find it 17:52:08 * spot can't find it 17:52:34 +1 if it comes to that, but I have a hard stop in 5 minutes. 17:52:38 but, i think the issues should be identical between firefox and icecat 17:52:50 heh, and libvpx is now unbundled from firefox too. 17:53:01 namely: libvorbis, libogg, opus, libtheora, libpng 17:53:07 +1 for the same exceptions as firefox 17:53:26 why can't we just make them work with the lib. maintainers in Fedora 17:53:33 I'm not sure. Wouldn't one of hte reasons we'd want an icecat is so we can do things like unbundle if mozilla won't let us do that and keep the trademark? 17:54:08 Rathann: AFAICT, currently, firefox doesn't have any active exceptions 17:54:26 oh, in that case -1 17:54:30 :) 17:54:40 * Rathann checks 17:54:44 abadger1999, even for Xulrunner ? 17:54:47 I'm going to go with -1 17:54:56 Rathann: Which is not to say that it isn't bundling... just that it wasn't granted an exception to bundle. 17:54:57 Hmmm. 17:54:57 (which sounds terrible to me...) 17:55:10 ie: they're violating guidelines as well. 17:55:12 right, nothing listed in our exception list 17:56:01 * spot suspects strongly that fesco would approve a bundling exception for these items in firefox|icecat 17:56:31 so let the fesco approves this 17:56:37 especially given that there seems to be some upstream movement towards it: https://bugzilla.mozilla.org/show_bug.cgi?id=517422 17:56:45 (unbundling, that is) 17:57:05 well if icecat is not restrained by (TM) issues then it can apply non-upstreamed patches to unbundle 17:57:26 I'm +1 to temporary exception for whatever can't be unbundled without breaking functionality 17:57:55 Rathann: i'm inclined to agree with that, but it sidesteps the problem of knowning that firefox is in violation. 17:57:58 I read that bug and it's good to see this kind of movement upstream 17:58:53 * Rathann checks if there's a bug against firefox about bundled libs 17:59:27 * spot would propose instead that we just except the known items that are either have non-upstreamed patches (libtheora, libsoundtouch, libpng), or have not yet been unbundled but will hopefully soon be (libogg, libvorbis, opus). 17:59:33 firefox also bundles cairo and libcms2 (iirc) 17:59:37 I'd vote for a temporary exception. Maybe with fedora.next, firefox goes into the playground repository and icecat becomes our default browser :-/ 18:01:14 there is: https://bugzilla.redhat.com/show_bug.cgi?id=517856 18:02:17 * spot has another phone meeting that just started 18:02:23 Greetings folks, I've been waiting for a time to jump in. But I was reviewing https://fedorahosted.org/fpc/ticket/369, and was confused. To me it sounds like a copyLib, but it's not a copyLib .?.? 18:02:30 And I pretty much have a hard stop about now. 18:03:15 #proposal - Temporary bundling exception for media libraries in firefox|icecat 18:03:27 +1, but for how long? 18:03:31 https://bugzilla.redhat.com/show_bug.cgi?id=1049889 => no comment 18:03:52 spot: does it matter for firefox if I vote -1 ? 18:03:56 tstclair: I can talk to you outside the meeting... I tried to explain it in https://fedorahosted.org/fpc/ticket/369#comment:10 18:04:17 geppetto: i have no idea. 18:04:25 abadger1999, ack. 18:04:28 Like others I'm reticent to ban icecat from doing something that we know firefox is doing, and can't stop 18:04:45 * RemiFedora agrees with gepetto 18:04:55 But my gut reaction to all of this is -1 for everyone, and fix your stuff 18:06:11 So I guess I want to say, -1 for firefox bundling media libs. … +1 for letting icecat bundle anything firefox does 18:06:14 i think there is no clear path forward here right now 18:06:21 so... lets table this until next week 18:06:44 * spot has to go now too... anyone want to take over or should we end here? 18:07:37 I'm interested in getting some feedback on https://fedorahosted.org/fpc/ticket/395 if possible, but can take it off-line 18:07:38 geppetto: I agree with the sentiment. 18:07:58 spot: k. I can take over until we run out of quorum. 18:08:16 abadger1999: thanks. i'll stick around here with half-attention while i'm on the phone 18:09:10 #info icecat bundling tabled for this week as there's both questions of what we should be doing and fairness wrt firefox. 18:09:28 #topic #393 New Packaging Guidelines: Drupal 7 18:09:34 https://fedorahosted.org/fpc/ticket/393 18:13:09 Folks, I'm sorry but I really do have to go. 18:13:20 I'll read the logs and add what I can after I get back. 18:13:25 tibbs: no problem 18:13:27 seems like "Every package SHOULD require "drupal7()" virtual resources instead of "drupal7-" packages." needs to be a MUST (when the virtual provide exists). 18:14:16 I wasn't sure about that, seemed likely to me too though 18:14:30 I think this is the diff: https://fedoraproject.org/w/index.php?title=User:Siwinski/Draft:Packaging:Drupal7&diff=370114&oldid=341905 18:15:15 They also changed the drupal-rpmbuild version require to be "should" from "needs to" 18:16:40 geppetto: i dont see that in the revision i'm looking at 18:17:58 spot: https://fedoraproject.org/wiki/User:Siwinski/Draft:Packaging:Drupal7#Requiring_a_Minimum_PHP_Version 18:18:17 spot: The warning there used to say "this needs to be added to the … " 18:18:46 php version, not drupal-rpmbuild version 18:19:01 thats the min php version, not the drupal-rpmbuild require 18:19:08 yeh 18:19:20 I just type random things to confuse everyone :-o 18:19:59 * spot knows nothing about drupal, really 18:20:17 so, outside of changing that SHOULD to a MUST (when provides exist), it looks okay to me 18:20:42 yeh, at least should get some confirmation of why that's a should and not a must 18:21:00 the "discussion" link they provided was distinctly lacking in any discussion IMO :) 18:21:03 I think this is explained in the ticket 18:21:13 yes, but the explanation is wrong 18:21:30 RemiFedora: tangent -- heh, so these autoprovides/requires would break in scls :-/ 18:21:39 current packages not following new guideline is not a reason not to use MUST 18:21:56 abadger1999, troll detected ! 18:22:02 yeh, they even say: we could change that to a "MUST if the virtual provide exists" 18:22:17 I'd move the macros and scriptlets section up so that people know what the file paths are when they read the file placement section. 18:22:18 So, what spot said. 18:22:19 and MUST file a bug if not exists ;) 18:22:30 RemiFedora: Who's that tromping over my bridge? 18:22:37 ;-) 18:22:40 I think MUST (if the virtual provide exists) is sensible there, possibly even just "MUST" with the understanding that they should get their fixes in. 18:23:16 18:23:20 +1 to the latter. 18:23:56 me to 18:24:25 +1 from me 18:24:30 sure 18:24:34 +1 18:25:54 +1 18:25:59 and I have to go now 18:26:17 +1 18:26:19 Rathann: Good bye! 18:26:26 bye guys 18:26:41 * RemiFedora have a hard stop in 15' 18:27:45 #info Drupal7 guidelines approved with the virtual provides requirement changed to MUST (+1:5, 0:0, -1:0) 18:28:31 +1 from me, fwiw 18:28:46 #undo 18:28:46 Removing item from minutes: INFO by abadger1999 at 18:27:45 : Drupal7 guidelines approved with the virtual provides requirement changed to MUST (+1:5, 0:0, -1:0) 18:28:49 #info Drupal7 guidelines approved with the virtual provides requirement changed to MUST (+1:6, 0:0, -1:0) 18:28:51 #topic #394 Outdated guideline about Requires(foo,bar) syntax 18:28:59 https://fedorahosted.org/fpc/ticket/394 18:29:32 The syntax is okay everywhere but EL5. 18:30:12 Proposal: Remove the section from the Guidelines and add them to the epel guidelines for EL5 18:30:15 +1 18:30:19 +1 18:30:23 +1 18:30:33 +1 18:30:54 +1 18:31:21 #info Remove the Scriptlets requirements section from the Guidelines and add them to the epel guidelines for EL5 (+1:5, 0:0, -1:0) 18:31:53 #topic #395 Mono guidelines include hard-coded library paths 18:31:58 https://fedorahosted.org/fpc/ticket/395 18:32:40 willb: we've gotten to the mono ticket 18:33:07 thanks 18:33:34 So the issue is that the Mono guidelines specify hard-coded paths, which is ugly and makes rpmlint sad 18:33:58 18:34:07 * spot is +1 on %{monodir}:/usr/lib/mono and %{monogacdir}:%{monodir}/gac 18:34:09 Maybe _monodir and _monogacdir 18:34:23 i'm not sure if that will trick rpmlint or not 18:34:32 Do those need to start with %{_prefix} rather than hardcoded "/usr" ? 18:34:44 abadger1999: yeah, probably. 18:34:57 wfm 18:35:07 sorry, should have said "will evaluate to" rather than "defined as" :-) 18:35:49 abadger1999, notice than unexpanded macro will also breaks SCL ;) ;) ;) 18:35:50 most of the "foodir" defines are "_foodir" 18:35:50 +1 with those changes (prepend with an underscore and use %{_prefix} ) 18:36:06 so +1 to _monodir and _monogacdir 18:36:10 +1 18:36:17 +1 18:36:19 +1 18:36:24 RemiFedora: yeah, I notice a lot of things like that these days ;-) 18:37:20 #info Mono path macros approved with the folowing changes: prepend with an underscore and use %{_prefix} (+1:5, 0:0, -1:0) 18:37:34 #topic #396 Reserve static UID/GID for OpenStack ironic daemon 18:37:37 thanks all 18:37:39 https://fedorahosted.org/fpc/ticket/396 18:38:04 Unless someone else knows something about "ironic" this one isn't ready. 18:38:13 There's no information about why a static uid is needed. 18:38:53 * abadger1999 moves on 18:39:01 #topic #397 Please, choose an ID number for a new group called "input" 18:39:07 https://fedorahosted.org/fpc/ticket/397 18:39:20 seems uselessly generic, but eh. 18:39:44 This one's also for a static gid but it's different than the others we've seen recently. 18:41:26 if I'm reading this right, they want to add this for similar reasons as we have dev, disk, etc 18:41:58 * abadger1999 sees a lack of those accounts in his F20 passwd file and wonders a bit what happened there. 18:42:56 they're only groups 18:42:57 not users 18:43:18 through group ownership, it permits access to device types 18:43:32 e.g. video group access permits playback 18:43:52 [spot@localhost Downloads]$ ls -l /dev/ |grep video 18:43:52 crw-rw----. 1 root video 29, 0 Feb 26 13:24 fb0 18:43:52 crw-rw----+ 1 root video 81, 0 Feb 26 13:24 video0 18:44:16 * spot presumes "input" would be used for all HID devices 18:44:17 ah yeah 18:44:55 which seems... dumb to me, because that's a bug waiting to happen when some user doesn't end up added to the input group and can't... type. 18:45:11 but hey, what do i know. :D 18:45:30 yeah.. 18:45:55 I'm kind of surprised we don't already have that group 18:46:01 I think they're asking for a hard static allocation rather than a soft static allocation... 18:46:05 seems the same as cdrom or whatever 18:46:22 I suppose I'm +1 here 18:46:31 * spot needs to go get lunch before i pass out, thanks everyone 18:46:38 yeh, dito. 18:46:45 I also don't think we can satisfy their requirements: "You can simply pick the first free ID from a safe range where no possible collision with other distributions can be expected." 18:46:51 There's no such range available. 18:47:11 spot: thanks. 18:47:21 I'm confused about why they need it to be static 18:48:27 Yeah -- is it just for device files? That seems like it would be per-machine in all cases. 18:48:39 yeh 18:48:55 I'll ask these quesitons in the ticket. 18:49:10 ok, cool 18:49:16 now food :) 18:49:38 food! 18:50:19 #topic Open floor 18:50:30 If anyone has something to bring up, speak now. 18:50:41 I'll close in 60s 18:52:30 #endmeeting