17:02:26 #startmeeting fpc 17:02:26 Meeting started Thu Mar 13 17:02:26 2014 UTC. The chair is abadger1999. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:26 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:32 #topic Roll Call 17:02:37 * geppetto is here 17:02:40 Who's here now? 17:02:54 I'm still around. Not sure for how long, though. 17:03:12 * RemiFedora here 17:03:28 spot, limburgher, Smoother1rOgZ: any of ya'll here? 17:03:28 I'm here to try to get the remaining votes for #392 17:04:00 #chair geppetto tibbs|w RemiFedora racor 17:04:00 Current chairs: RemiFedora abadger1999 geppetto racor tibbs|w 17:04:22 sagitter is here for #391 17:04:36 Just enough for quorum. 17:04:42 * Rathann here 17:05:00 * limburgher is 17:05:12 #chair Rathann limburgher 17:05:12 Current chairs: Rathann RemiFedora abadger1999 geppetto limburgher racor tibbs|w 17:05:30 #topic #339 software collections in Fedora 17:05:34 https://fedorahosted.org/fpc/ticket/339 17:05:54 Something I thought was resolved came back to haunt me this week. 17:06:00 https://bugzilla.redhat.com/show_bug.cgi?id=1066665 17:06:56 I thought Jan and I were agreed that we'd use /etc/opt and /var/opt in fedora's scl-utils but mmaslano said that wasn't the plan this week... I'm still trying to figure out what's going on there. 17:07:02 (for #392, +1 from me, so could quich set it as approved) 17:07:08 17:07:13 #topic #382 Go Packaging Guidelines Draft 17:07:19 https://fedorahosted.org/fpc/ticket/382 17:07:40 mattdm: If you're around, we can talk about the go packaging draft 17:08:06 If you aren't I'll move on (and we can come back to it if our meeting is still going when you come back). 17:08:12 abadger1999 functionally, not around 17:08:18 (sorry) 17:08:20 mattdm: roger that. 17:08:32 #topic #385 workarounds for rpm symlink <-> directory issue 17:08:34 I asked vbatts if he can help pick up the slack and he said he will try to make some time 17:08:37 https://fedorahosted.org/fpc/ticket/385 17:09:24 mattdm: okay -- There's some (hopefully easy) things to address in the last comment on the ticket. then we have to re-tackle the static linking/dependency questions. 17:09:33 So for 385. 17:09:38 yep, just need to vote probably. 17:10:22 sriptlets updated, wording changes... 17:11:15 +1 on 385 17:11:17 I think this is roughly the diff to what we last voted on: https://fedoraproject.org/w/index.php?title=User%3APatches%2FPackagingDrafts%2FSymlink_Workarounds&diff=371871&oldid=370736 17:11:17 I think this is fine. 17:12:32 Looking over the warning about not using this for things in /etc, though, I have to wonder. I kind of thought the majority of cases where this is needed are in /etc. 17:13:20 Bundled PHP libs. 17:13:43 or javascript or ... 17:13:51 limburgher, for unbundled php libs, you don't nees symlink... just a proper autoloader 17:13:54 I have seen things in /usr as well. But yeah -- this does leave /etc out in the cold. 17:14:45 maybe we approve this and then when someone runs into a /etc/ case they can work on a change to balance the dangers with the ability to handle /etc? 17:14:50 I thought most use cases were for /usr 17:15:08 Didn't mean to digress. +1 in any case. 17:15:11 +1 17:15:38 But, yeh, we could reword the warning to say something about how/why it's a problem. 17:15:41 +1 (even if not a big fan of using lua) 17:16:09 +1, I don't like it, nevertheless better than nothing 17:16:28 +1 from me as well 17:16:30 +1 17:16:58 #info workaround for rpm symlink <-> directory issues approved (+1:7, 0:0, -1:0) 17:17:15 #topic #391 Exception for bundled libraries in icecat 17:17:19 https://fedorahosted.org/fpc/ticket/391 17:18:34 abadger1999: you know if the new icecat changes stuff? 17:18:43 Not sure where we are here -- I'l ping the ticket for an update by the reporter. 17:18:49 * geppetto nods 17:18:55 #topic #396 Reserve static UID/GID for OpenStack ironic daemon 17:19:01 https://fedorahosted.org/fpc/ticket/396 17:19:22 No information from the reporter. 17:19:36 if you look at bug 517856, you'll see I added a long list of libraries/projects bundled in firefox/xulrunner 17:19:42 It could be that the reporter just asked for a static uid because other software they're used to did. 17:21:57 yeah, no justification why it needs a static uid/gid 17:22:02 Rathann: k. I'll note that list in the ticket. 17:22:19 I'll ping the ticket and say we'll close the request if we don't hear back. 17:22:37 #topic #397 Please, choose an ID number for a new group called "input" 17:22:41 https://fedorahosted.org/fpc/ticket/397 17:23:31 Seems a bit generic. 17:24:43 yeh, I don't see a reason to do anything but -1 this atm 17:24:45 My reading of the last comment is that no static gid is needed at this time. 17:24:54 yeh 17:25:30 not sure if we can do that at a later time though... 17:25:54 sites would already have a gid allocated to the input group if we let it be dynamic for now. 17:27:39 abadger1999: I don't see why this should matter. 17:29:07 anyhow. 17:30:10 There's not a link to the blog posts jcapik is refering to or the test that he was trying to run. 17:30:15 So I'm -1 at the moment. 17:30:24 I am too, I just don't see the need. 17:30:55 But I'm also willing to ask for more information if he feels like trying to give us more information about how the sharing or gids across systems is supposed to work for fifos. 17:31:19 * abadger1999 sees three -1s 17:32:15 If no one else votes, I'll just ask for the extra information and we'll come back to finish voting next time. 17:32:28 #topic #398 Tilde in version 17:32:30 It just seems like something that's by definition 99% system-local. 17:32:40 * Rathann is 0 on #397, NEEDINFO :) 17:32:45 https://fedorahosted.org/fpc/ticket/398 17:33:35 geppetto: So I'm guessing the question is: 17:34:21 If I have an autoprovide of foo-1.0-0.1.rc1 what autorequires would be satisfied by it? 17:34:28 There's a question for 398? 17:34:40 and does autoprovides parse that as NVR 17:35:00 n=foo, v=1.0 r=0.1.rc1 … how else could it? 17:35:15 geppetto: vondruch had a quesetion about what he should do in the rubygem autodep script 17:36:15 yeh, I'm not really sure what he's asking 17:36:45 I think he's saying. autoprovides (using our nvr scheme, not tilde) would be: 17:36:52 I wonder what's the problem with putting the rc1 part in release 17:37:08 rubygem(foo) = 1.0-0.1.rc1 17:37:23 how is 4.1.0~rc1-1 4.1.0~rc1-2 … different from 4.1.0-0.rc1.1 4.1.0-0.rc1.2 etc. 17:37:50 geppetto: actually it should be -0.1.rc1 -0.2.rc1 etc. 17:37:52 Can correct autorequires also be constructed for that? 17:37:58 Rathann: fair enough 17:38:08 that's his question. 17:38:39 His thinking is probably that 1.0-0.1.rc1 is too strict. 17:38:40 They are very similar … depending on what range he wants, it's possible 17:38:49 whereas 1.0 is too lenient 17:39:33 Yeh, so one thing he can do with the tilda version is: Requires: foo = 4.1.0~rc1 17:40:25 and it'll be older than foo = 4.1.0 in rpmvercmp, yes 17:40:27 We can't really do that by changing the release 17:40:50 why is only the version field being considered? 17:40:55 Rathann: Well it'll be true for all pre-release, and != the version of the real release 17:41:08 In theory he could do a doulbe require of: 17:41:25 Require: foo >= 4.1.0-0 17:41:30 Require: foo < 4.1.0-1 17:41:47 But, that's generally not considered a good idea 17:42:30 abadger1999: what was the last line you saw? 17:42:31 sorry, I was disconnected. 17:42:40 [10:41:48] But, that's generally not considered a good idea 17:42:48 ahh, you got everything then 17:42:56 I'm -1 until Vit explains why current nevr convention is insufficient 17:43:16 benefit I see with ~ is "Version" used to stored all upstream, and Relaease only packaging (and having RC1, which is upstream, in Release can be see as strange) 17:43:30 geppetto: Is there a technical reason that the double requires is bad? 17:43:52 why do you want to require a prerelease anyway? 17:43:59 (but not a release) 17:44:09 abadger1999: because technically the depsolver can decide to do crazy things like pick two packages to solve each 17:44:20 abadger1999: Eg. installed 4.0.0 and 4.2.0 17:45:11 * abadger1999 also notes that the autoreq/provs don't handle the post-release alpha case correctly. 17:45:26 this is esp. problematic with virtual provides, but multilib makes it fun for other cases too 17:45:45 but I suppose that'll come up in the revised ruby guidelines (where he has verbiage that says to filter the requires and provides for cases like that) 17:47:49 Rathann: I can see cases where an upstream author might decide to require a prerelease. 17:47:59 but I'm not sure it is "correct" 17:50:01 it would be that hte upstream developed against foo-1.0a1 and then foo-1.0a3 changed the api. 17:50:17 upstream has not yet ported to the new api. 17:50:31 and then 1.0 changed api again? 17:50:39 Rathann: yeah, it could have. 17:50:47 not nice of them ;) 17:51:02 yeah -- but the prevous ones were alpha releases :-) 17:51:08 so it's legal. 17:51:09 but anyway, why can they not require full nevr? 17:51:12 in spec 17:51:27 well ... vit's case is that he's developing a dependency generator. 17:51:47 so he's having to capture this information programatically and automatically. 17:51:48 I think you can requires foo = 1.2~beta 17:51:54 yeh, we should prbably just ask him what he's currently doing and why it doesn't work? 17:52:11 and then release can change 17:52:33 I'm +1 to the proposal 17:52:42 RemiFedora: Right, but it seems likely that Require: foo = 1.2 would also work for 99%+ of cases. 17:53:36 I think it's cleaner if you are able to say Version = Upstream, Release = Packaging version 17:53:50 yeah -- and if there's always going to be some cases where you have to filter the autoreqs and do it manually anyway... perhaps the difference between 99% and 99.2% isn't big enough. 17:54:36 * abadger1999 thinks he's gone from -1 to 0 on this issue so far. 17:55:05 we do have some people here to discuss specific guidelines they were interested in. 17:55:18 Perhaps we should table this, ask for more info in the ticket. 17:55:22 if it makes life easier for many folks, I might consider swinging to +1, but so far the case is not convincing 17:56:11 Alright -- I'll ask for some solid examples in what he's doing. 17:56:42 and an estimate of just how often Requires: foo= 1.2 wouldn't be sufficient. 17:56:50 we'll revisit next week. 17:56:58 #topic #399 request for bundled library exception - clustal omega 17:57:04 https://fedorahosted.org/fpc/ticket/399 17:57:11 I am still leaning towards -1. In particular I am missing a precise definition of '~' 17:57:41 We have three +1's to allow bundling here (as it is a fork of squid rather than bundling) 17:58:10 spot, Rathann, RemiFedora, limburgher, racor, SmootherFr0gZ : You are the remaining voters. 17:58:22 +1 17:58:41 I'm going to have to leave in just a couple of minutes; sorry. 17:58:50 actually... I guess the justification wasn't a fork. 17:58:56 Proposal: "clustal omega has a forked copy of squid​http://selab.janelia.org/software.html. Since squid was last updated in 2002, is a copylib, *and* clustal omega is the only user in Fedora, there is currently no benefit to a separate library. Permission to bundle has been granted unless some of those criteria change." 17:59:00 +1, I suppose. 17:59:15 Okay, those two +1's make 5 17:59:37 #info Clustal omega allowed to bundle squid: (+1:5, 0:0, -1:0) 17:59:51 +1 from me too 17:59:56 #undo 17:59:56 Removing item from minutes: INFO by abadger1999 at 17:59:37 : Clustal omega allowed to bundle squid: (+1:5, 0:0, -1:0) 17:59:57 0 ... I fail to understand why they did not fully fork and replace "upstream squid" 18:00:04 #info Clustal omega allowed to bundle squid: (+1:6, 0:1, -1:0) 18:00:07 ok, I have to leave now 18:00:41 .. so do I ;) 18:00:51 #topic 392: bundling expception for greenmail 18:00:58 RemiFedora voted +1 earlier to this. 18:01:02 bye 18:01:09 That makes 5 18:01:16 anyone else want to vote for the record? 18:01:52 #info greenmail's use of james considered a fork (+1:5, 0:0, -1:0) 18:02:29 Thanks everyone! 18:02:35 #topic 391 Exception for bundled libraries in icecat 18:02:52 sagitter: Sorry -- I didn't see that you were here to discuss this one. 18:03:20 sagitter: there was a new release... what is the current status? 18:03:25 * abadger1999 suspects not much changed. 18:04:47 okay, perhaps sagitter was not able to stick around. 18:05:20 * abadger1999 tries to pick some easy ones from the new business list. 18:05:28 #topic #406 How to handle Doxygen documentation with new jQuery no-bundling rules? 18:05:32 https://fedorahosted.org/fpc/ticket/406 18:05:51 jamielinux and patches have been working on packaging jquery. 18:06:03 jamielinux estimates a few months work remains in this ticket. 18:06:21 I'd like to propose a temporary bundling exception for jquery to let that happen 18:06:29 +1 18:06:45 Proposal: Packages may bundle jquery through F21. They need to unbundle in F22. 18:06:53 abadger1999, sorry for delay, new release has not been released yet 18:06:55 especially as web-asset is still unusable, so we can't apply Guidelines 18:06:56 +1 18:07:04 +1 18:07:05 +1 18:07:33 (sorry, have vote twice) 18:07:36 RemiFedora: If there's additional problems with web-assets (besides jsut lacking jquery) be sure to mention that as well. We'll need someone to fix that :-) 18:07:46 We're at +3. 18:07:57 abadger1999, patch sent months ago... still ne httpd stuff 18:08:24 +1 (406) 18:09:06 RemiFedora: k. If there's a bugzilla open with that, I can try contacting jamielinux and patches about it. 18:09:27 I will open one 18:09:35 RemiFedora: Cool. thanks. 18:10:10 tibbs|w, if youre still here, limburgher_, Smoother1rOgZ, spot: voting on a temporary bundling exception for jquery. 18:10:39 err.. limburgher_sorry.... I see you've already voted ;-) 18:10:57 I'm in Chicago, I'd be happy to vote again. ;) 18:11:43 #info Temporary bundling of jquery through F21 (Packages need to unbundle for F22) is at (+1:4, 0:0, -1:0) voting to continue in ticket. 18:11:58 sagitter: So for icecat -- should we just wait then? 18:12:48 sagitter: or is it not likely to be resolved so we should explore another option? 18:13:32 yes, we can wait to see if something is changed about those libraries 18:13:58 Okay. 18:14:21 sagitter: You also saw rathann's note that firefox, at least, bundles a bunch of other libraries? 18:14:46 https://bugzilla.redhat.com/show_bug.cgi?id=517856#c15 18:14:58 Not sure if icecat is bundling all of those as well. 18:15:38 I guess we'll continue to explore.... 18:15:47 yes, I see. But Firefox is packaged with bundled file for Fedora. Why? 18:16:18 sagitter: I believe there's two pieces to an answer to that: 18:16:25 well, maybe three 18:16:32 (1) It wasn't caught at initial review 18:17:02 (2) over time firefox upstream has had more bundled libraries and the firefox maintainers haven't been vigilant about asking us to approve or disapprove them. 18:18:25 (3) firefox upstream won't let us patch things in our distro unless we remove the trademarks. 18:18:46 So they are a (big) problem now 18:19:38 yeah. 18:20:38 okay, I'll try to examine in depth this issue in Icecat 18:21:10 sgallagh: Thanks... and if you ifnd it's just as huge in icecat... FPC can vote on other things that may or may not be fruitfull. 18:21:29 (for instance, allowing icecat to bundle the same things as we'd allow firefox to bundle). 18:21:57 which might be problematic for firefox... I'm not sure if we'd allow them to bundle all the things that they currently do. 18:22:21 #topic #404 Update python packaging guidelines 18:22:26 https://fedorahosted.org/fpc/ticket/404 18:22:34 here's the diff https://fedoraproject.org/w/index.php?title=User%3ATill%2FPython_Packaging&diff=372315&oldid=372311 18:23:00 It looks to me like cleanups of %__python to %__python2 18:23:28 and a rewording of the pygtk2 numpy note since there's been no progress in upstream gnome about that. 18:23:37 +1 18:24:03 +1 as well. 18:24:07 yeh, kind of trivial 18:24:09 +1 18:24:42 RemiFedora: You're still here we can vote on these easy-ish ones and then take them to the ticket for the remaining vote. 18:24:47 +1 18:25:33 #info Python updates prposal from tyll (+1:4, 0:0, -1:0) Will look for the remaining vote in ticket. 18:25:37 #topic #402 Promote /usr/lib/rpm/macros.d over /etc/rpm 18:25:45 https://fedorahosted.org/fpc/ticket/402 18:26:07 This also seems like a simple and good change. 18:26:19 Indeed. 18:26:20 +1 18:26:34 I also wondered if there were other places in the guidelines that might need to be adjusted (I know the scl draft will need to be). 18:26:36 +1 18:26:48 +1 18:28:18 +1 18:29:11 #info Update rpm macros directory (+1:4, 0:0, -1:0) Will seek additional votes in the ticket. 18:30:29 #topic 403 Resolve conflict between libeio and eio (enlightenment library) 18:31:06 passenger is asking for permission to bundle libeio instead of resolving the naming conflict between libeio and and enlightenment library of hte same name. 18:31:22 I'm -1 for the bundling request. 18:31:33 Notice than Eio currently obsoletes libeio (and very badly) 18:32:05 Passenger's upstream made a statement: https://fedorahosted.org/fpc/ticket/403#comment:7 18:32:10 This is the sort of thing that we have to get upstreams to deal with and bundling won't help. Sometimes people should do a google search before they pick a name for something. 18:32:11 -1 18:32:20 which seems to be that they would like to fit into a copylib exception. 18:32:38 But there doesn't seem to be any extenuating circumstances here that we've used as precedent before 18:32:46 (same upstream, dead upstream, etc) 18:33:27 I'm for just biting hte bullet and forcing the use of a different name. 18:34:33 Yeh, we can say that one of the libraries needs to be named differently, but the APIs within can obviously remain the same 18:34:44 libenlightenment_eio or whatever. 18:35:08 libEio 18:35:13 (as Eio.h) 18:35:31 I don't think we want libeio and libEio … do we? 18:36:35 I'd rather have libenlightenemnt_eio :-) But given their relative usages, 18:36:41 probably libeio is what we'd rename. 18:37:06 I don't understand how libeio version was managed in F<=19 18:39:18 ok, found, there is no "upstream" tarball, but CVS sticky tag 18:41:28 So we have two explicit -1's to bundling here and I think RemiFedora and geppetto also agree that renaming is better. 18:41:46 yeh, -1 to bundling 18:42:25 Also I'm not sure that libeio loses 18:43:08 #info Allow passenger to bundle libeio (+1:0, 0:0, -1:3). Going to say this is unlikely to pass in ticket; we should look at renaming. 18:43:35 geppetto: sure -- if you have an argument for that it would be good to put it out there and then involve both the libeio and enlightenment maintainers. 18:45:59 I'll get the enlightenment library maintainer cc'd on the ticket. 18:46:08 abadger1999: Just that I'm not convinced that being slightly more popular means you should get to dictate what you want. 18:46:30 geppetto: Yeah -- we have several metrics listed in the Conflicts page. 18:48:29 popularity, how long you've used the name, whether there's programs being invoked that use the name... 18:48:47 * abadger1999 tried to find the list just now but it isn't in one single place like he thought 18:48:53 * RemiFedora dislike the "we drop libeio from fedora, to not have to manage the conflict with the new eio package" 18:50:33 I have a hard-stop in a few minutes 18:53:50 k 18:53:54 We should end the meeting. 18:54:10 #endmeeting