15:00:10 #startmeeting Fedora Packaging Committee 15:00:10 Meeting started Wed Jul 13 15:00:10 2011 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:10 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:14 #meetingname fpc 15:00:14 The meeting name has been set to 'fpc' 15:00:20 #topic Roll Call 15:00:25 * abadger1999 here 15:00:39 * geppetto is here 15:00:41 * spot is here too! :) 15:00:45 :) 15:01:32 * j_dulaney is going to lurk 15:03:36 rdieter, tibbs|h, SmootherFrOgZ: ping ? 15:03:50 here (1/2) 15:05:02 racor makes five, but we'll wait a few minutes and see if anyone else appears 15:07:14 Looks like remi is saying the php bndles libzip exception request is also ready: https://fedorahosted.org/fpc/ticket/62 15:08:10 okay, so maybe we can talk about that one first 15:08:47 #topic PHP libzip bundling exception request - https://fedorahosted.org/fpc/ticket/62 15:09:46 I admit to not being terribly thrilled about trusting the PHP team to handle security fixes on an incompatible old library fork. :P 15:10:20 15:10:26 and the bug requesting that they unbundle libzip is 5 years old 15:10:52 but i do believe remi when he says that the work to port the changes to modern libzip is non-trivial 15:11:23 also, the 0.10 version had a CVE fix that analysis says does not affect php... but still... no move on php's part to update. 15:12:05 there were CVEs against 0.9* too 15:12:20 Could read that either as "We dodged that bullet, we can be irresponsible for longer!" or "We know our code well -- that bug doesn't affect us so we won't bother fixing it." 15:12:22 i have no idea if PHP is vulnerable or not 15:12:52 probably safe to say, yes 15:13:21 PHP has been bundling this for 5 years, right? … and there are no other options than either dropping PHP or allowing the bundling? 15:13:37 geppetto: pretty much. 15:13:44 * geppetto is tempted to just vote +1 any PHP users/developers get what they deserve 15:14:08 i suppose we could require their libzip to be forked into its own package, but that doesn't seem to provide much benefit 15:14:14 https://bugzilla.redhat.com/show_bug.cgi?id=688735 15:15:01 bressers analysis for the one CVE I can find is that libzip is vulnerable but not php's particular use of libzip. 15:15:02 yeh … I thought of that … but the pro. for that seems pretty suspicious "Now non-PHP developers can experience the awesomeness of PHP, using libzip-php 15:15:21 geppetto: yeah. 15:15:32 So, as distasteful as I find this, I'm +1 to the bundling exception. 15:15:39 +1 15:16:09 +1 15:17:19 -1 15:17:47 abadger1999: okay, what is the proposed resolution here? removing PHP? 15:17:50 * abadger1999 sorry -- can only half think about FPC at the moment... but inclined towards -1 from reading the ticket this morning. 15:18:08 spot: Just like rsync, if someone patches it, then php in Fedora has to take the patch. 15:18:23 0, it should be analyzed how much effort porting php to upstream libzip would be. 15:18:27 abadger1999: yes, but remi tried to patch it and was not successful 15:18:46 With lack of patch we aren't forcing maintainers to do it. 15:19:05 it seemed clear to me from remi's analysis that php was dependent on the altered behavior in the php bundled libzip 15:19:55 what do other distros do? 15:20:12 abadger1999: so, you're saying that we're denying the exception on the grounds that someone else might someday make a patch and we should use it? 15:20:27 spot: But other bundling situations we've asked -- why haven't the changes been upstreamed/You must attempt to upstream the changes. 15:20:33 That doesn't seem to have been done here. 15:22:30 i understand the sentiment 15:22:57 but i am uncomfortable telling a maintainer that they need to try to port changes across a major revision difference in an upstream library 15:23:09 especially when they've stated that they already tried and failed 15:23:49 combined with the fact that upstream PHP is entirely uninterested in using a system copy of libzip 15:24:13 (which, if true, why would they be interested in porting their libzip changes across a major revision difference of libzip) 15:24:43 Oh, are we back on at this time? 15:24:47 Well, crap. 15:25:09 So, i think if we're going to reject this bundling request, we need to have some sort of action as a result. 15:25:11 tibbs|h: yep, I told the Board that we'd need to figure out a new time... currently trying o do that in the board meeting channel 15:25:19 (Where we == board) 15:25:24 in that sentence 15:25:25 If the action is "do nothing, let php continue", why are we even bothering? :) 15:25:50 spot: Why did we bother rejecting rsync? 15:25:53 :) 15:26:08 abadger1999: didn't fesco do that? 15:26:12 How hard would it be to fix the issue with libzip within the Fedora code base? 15:26:48 j_dulaney: remi tried and failed but we don't know more details. 15:27:12 okay, i'll look at porting their changes 15:27:18 and we'll table this until next week 15:27:18 abadger1999: Righteo 15:27:22 can I comment on this? 15:27:24 abadger1999: to be fair, the rsync thing was a "without this it's not as fast" 15:27:53 geppetto: IIRC, I think the argument was wire-level changes. 15:27:59 geppetto: Not, speed. 15:28:04 kalev: Go ahead. 15:28:11 Fedora still has libzip 0.9.3, which, I believe, should be roughly the same that php uses 15:28:39 so if remi or someone else wants to port php to use system libzip, first step should be to port to libzip 0.9.3 15:28:48 it's hard to do two things at a time. 15:28:52 hi folks, sorry for being late 15:29:08 got caught up in making dinner 15:29:10 ;) 15:29:15 also, it might be a good idea to approach php upstream and ask if they now (5? years later) would be interested in taking such a patch 15:29:21 kalev: yeah, that is understood, but since upstream is at 0.10.0, that work won't last very long, and upstream probably isn't interested. 15:30:00 * spot will look into this, and we'll revisit it next week 15:30:14 a resolution today might be to ask remi to a) investigate porting to system 0.9.3, b) ask remi to talk to php upstream and the other distro packager who offered to make the patch 15:30:49 okay, moving on. 15:31:09 #topic New Java Guidelines - https://fedorahosted.org/fpc/ticket/97 - https://fedoraproject.org/w/index.php?title=User%3AAkurtakov%2FJavaPackagingDraftUpdate&action=historysubmit&diff=243840&oldid=243244 15:31:40 This is a change to the Java Guidelines that basically simplifies the handling of the maven_depmaps 15:32:08 The changes look reasonable to me, but I'll let people read and consider. 15:32:17 I had reviewed these earlier and they don't appear to have changed since then. 15:32:45 +1 from me. 15:32:51 +1 from me 15:33:50 I'll admit that Java packaging is getting even further away from what I used to understand, but at least the spec files appear to be getting simpler. 15:34:11 tibbs|h: yeah, but believe it or not, it is making more sense to me. :) 15:34:14 so, jpackage-utils are no longer required in post and postun? 15:34:20 Did they change the name of a macro? 15:34:28 Rathann: because the post/postun invocations are gone 15:34:37 ok 15:34:44 geppetto: they made a new macro to replace the old ones 15:34:58 ok 15:35:15 And I assume they aren't deleting the old one anytime soon? 15:35:26 looks good to me 15:35:33 All of the macros are documented in the revised document. 15:35:40 geppetto: one would assume that is why the naming is unique. :) 15:35:58 :) 15:36:00 +1 15:36:03 +1 from me and I'm afk for a few mins 15:36:09 Hmm, sorry, that's %$add_maven_depmap, not %add_to_maven_depmap. 15:36:19 modulo my typos. 15:36:58 +1 15:37:14 But we can be pretty sure that if they were intending to remove the old macro, they'd also be willing to do the work to fix up packages. The Java SIG is pretty well organized. 15:37:18 vote is at +5, racor or rdieter, feel free to chime in. 15:37:22 tibbs|h: *nod* 15:37:25 +1 15:37:41 Something of a generic style note -- I think it would be good to have non-standard-rpm macros expanded in the wiki/packaging guidelines somewhere. 15:38:07 One problem with that is that they can change. 15:38:16 Not inline as the macros are there to make things simpler. 15:38:22 Or was the intent to force any change in those macros to go through us? 15:38:29 But somewhere so that people can see what they're doing step by step. 15:38:40 Hmm... that's another good question. 15:38:46 * spot could see some documentation about how to determine the value of a macro 15:38:47 0, this is above my head and makes me shiver 15:39:23 #action Java Guideline Changes approved (+1:6, 0:1, -1:0) 15:39:44 If the macros can change without our approval... does that undercut the review of guideline changes that we're supposed to be doing? 15:40:01 Or is it proper streamlining of the procss for everyone? 15:40:19 * spot doubts that is a realistic concern, to be honest. we haven't had that problem to date, i'd rather not worry about it until it becomes one. 15:40:30 As long as the changes are compatible, it's fine 15:40:58 * spot has adjusted the R macros several times to reflect the changing R env, while retaining the function of the macro 15:41:46 #topic Open Floor 15:42:27 * spot will leave the floor open until say, 1546. 15:42:41 * j_dulaney raises his hand 15:42:51 j_dulaney: go ahead 15:43:23 I saw Automake is to be orphaned. I'm thinking I could take that 15:43:34 But, I'm not a packager 15:43:55 not yet, anyway 15:43:59 j_dulaney: fesco has a procedure for new packagers to take on orphaned packages 15:44:19 Righteo 15:44:23 * j_dulaney looks into it 15:46:05 err, actually 15:46:13 i don't think that specific case is documented 15:46:19 but either way, that is a fesco issue 15:46:29 if you can find a sponsor, i suspect it won't be an issue 15:46:38 * racor wonders why the RH-employed upstream autotool maintainer isn't involved into maintaining the autotools in Fedora. 15:46:42 http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group 15:46:54 racor: why would they want to maintain legacy versions of autotool? 15:47:03 * spot doubts most people are that masochistic. 15:47:33 spot: the legacy versions are 0 effort 15:47:46 this isn't automake, iirc, its automake14, automake15 15:47:54 racor: until they hit bugs. 15:48:35 spot: only if they hit serious breakdowns. Otherwise, they need to says bugward compatible . 15:48:41 * spot is always frightened when he sees a package that depends on a specific legacy version of autotools 15:48:47 s/says/stay/ 15:48:57 spot: ACK 15:49:33 * j_dulaney thinks it could be a good foot in the door type of thing 15:49:47 so i'd personally rather see the RH autotool guy to work on porting those packages to current autotools. :) 15:49:59 but i don't get to make those calls. 15:50:02 Honestly I'd think it would be a pretty bad way to start out packaging. 15:50:17 j_dulaney: i think it might be easier to package something you have an interest in. 15:50:29 But if you're really good at autotools, I guess we could use more people like that. 15:50:31 (assuming that you're not interested in legacy autotools) 15:51:20 Well, sort of 15:52:08 If there are no other topics, I'm going to close out the meeting 15:52:32 Thanks everyone 15:52:34 #endmeeting