15:00:10 <spot> #startmeeting Fedora Packaging Committee
15:00:10 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:14 <spot> #meetingname fpc
15:00:14 <zodbot> The meeting name has been set to 'fpc'
15:00:20 <spot> #topic Roll Call
15:00:25 * abadger1999 here
15:00:39 * geppetto is here
15:00:41 * spot is here too! :)
15:00:45 <geppetto> :)
15:01:32 * j_dulaney is going to lurk
15:03:36 <spot> rdieter, tibbs|h, SmootherFrOgZ: ping ?
15:03:50 <rdieter> here (1/2)
15:05:02 <spot> racor makes five, but we'll wait a few minutes and see if anyone else appears
15:07:14 <abadger1999> Looks like remi is saying the php bndles libzip exception request is also ready: https://fedorahosted.org/fpc/ticket/62
15:08:10 <spot> okay, so maybe we can talk about that one first
15:08:47 <spot> #topic PHP libzip bundling exception request - https://fedorahosted.org/fpc/ticket/62
15:09:46 <spot> 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 <abadger1999> <nod>
15:10:26 <spot> and the bug requesting that they unbundle libzip is 5 years old
15:10:52 <spot> but i do believe remi when he says that the work to port the changes to modern libzip is non-trivial
15:11:23 <abadger1999> 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 <spot> there were CVEs against 0.9* too
15:12:20 <abadger1999> 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 <spot> i have no idea if PHP is vulnerable or not
15:12:52 <geppetto> probably safe to say, yes
15:13:21 <geppetto> 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 <spot> geppetto: pretty much.
15:13:44 * geppetto is tempted to just vote +1 any PHP users/developers get what they deserve
15:14:08 <spot> 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 <abadger1999> https://bugzilla.redhat.com/show_bug.cgi?id=688735
15:15:01 <abadger1999> 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 <geppetto> 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 <spot> geppetto: yeah.
15:15:32 <spot> So, as distasteful as I find this, I'm +1 to the bundling exception.
15:15:39 <geppetto> +1
15:16:09 <rdieter> +1
15:17:19 <abadger1999> -1
15:17:47 <spot> 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 <abadger1999> spot: Just like rsync, if someone patches it, then php in Fedora has to take the patch.
15:18:23 <racor> 0, it should be analyzed how much effort porting php to upstream libzip would be.
15:18:27 <spot> abadger1999: yes, but remi tried to patch it and was not successful
15:18:46 <abadger1999> With lack of patch we aren't forcing maintainers to do it.
15:19:05 <spot> 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 <racor> what do other distros do?
15:20:12 <spot> 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 <abadger1999> 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 <abadger1999> That doesn't seem to have been done here.
15:22:30 <spot> i understand the sentiment
15:22:57 <spot> 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 <spot> especially when they've stated that they already tried and failed
15:23:49 <spot> combined with the fact that upstream PHP is entirely uninterested in using a system copy of libzip
15:24:13 <spot> (which, if true, why would they be interested in porting their libzip changes across a major revision difference of libzip)
15:24:43 <tibbs|h> Oh, are we back on at this time?
15:24:47 <tibbs|h> Well, crap.
15:25:09 <spot> 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 <abadger1999> 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 <abadger1999> (Where we == board)
15:25:24 <abadger1999> in that sentence
15:25:25 <spot> If the action is "do nothing, let php continue", why are we even bothering? :)
15:25:50 <abadger1999> spot: Why did we bother rejecting rsync?
15:25:53 <abadger1999> :)
15:26:08 <spot> abadger1999: didn't fesco do that?
15:26:12 <j_dulaney> How hard would it be to fix the issue with libzip within the Fedora code base?
15:26:48 <abadger1999> j_dulaney: remi tried and failed but we don't know more details.
15:27:12 <spot> okay, i'll look at porting their changes
15:27:18 <spot> and we'll table this until next week
15:27:18 <j_dulaney> abadger1999:  Righteo
15:27:22 <kalev> can I comment on this?
15:27:24 <geppetto> abadger1999: to be fair, the rsync thing was a "without this it's not as fast"
15:27:53 <abadger1999> geppetto: IIRC, I think the argument was wire-level changes.
15:27:59 <abadger1999> geppetto: Not, speed.
15:28:04 <abadger1999> kalev: Go ahead.
15:28:11 <kalev> Fedora still has libzip 0.9.3, which, I believe, should be roughly the same that php uses
15:28:39 <kalev> 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 <kalev> it's hard to do two things at a time.
15:28:52 <Rathann> hi folks, sorry for being late
15:29:08 <Rathann> got caught up in making dinner
15:29:10 <Rathann> ;)
15:29:15 <kalev> 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 <spot> 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 <kalev> 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 <spot> okay, moving on.
15:31:09 <spot> #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 <spot> This is a change to the Java Guidelines that basically simplifies the handling of the maven_depmaps
15:32:08 <spot> The changes look reasonable to me, but I'll let people read and consider.
15:32:17 <tibbs|h> I had reviewed these earlier and they don't appear to have changed since then.
15:32:45 <tibbs|h> +1 from me.
15:32:51 <spot> +1 from me
15:33:50 <tibbs|h> 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 <spot> tibbs|h: yeah, but believe it or not, it is making more sense to me. :)
15:34:14 <Rathann> so, jpackage-utils are no longer required in post and postun?
15:34:20 <geppetto> Did they change the name of a macro?
15:34:28 <spot> Rathann: because the post/postun invocations are gone
15:34:37 <Rathann> ok
15:34:44 <spot> geppetto: they made a new macro to replace the old ones
15:34:58 <geppetto> ok
15:35:15 <geppetto> And I assume they aren't deleting the old one anytime soon?
15:35:26 <Rathann> looks good to me
15:35:33 <tibbs|h> All of the macros are documented in the revised document.
15:35:40 <spot> geppetto: one would assume that is why the naming is unique. :)
15:35:58 <geppetto> :)
15:36:00 <geppetto> +1
15:36:03 <Rathann> +1 from me and I'm afk for a few mins
15:36:09 <tibbs|h> Hmm, sorry, that's %$add_maven_depmap, not %add_to_maven_depmap.
15:36:19 <tibbs|h> modulo my typos.
15:36:58 <abadger1999> +1
15:37:14 <tibbs|h> 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 <spot> vote is at +5, racor or rdieter, feel free to chime in.
15:37:22 <spot> tibbs|h: *nod*
15:37:25 <rdieter> +1
15:37:41 <abadger1999> 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 <tibbs|h> One problem with that is that they can change.
15:38:16 <abadger1999> Not inline as the macros are there to make things simpler.
15:38:22 <tibbs|h> Or was the intent to force any change in those macros to go through us?
15:38:29 <abadger1999> But somewhere so that people can see what they're doing step by step.
15:38:40 <abadger1999> 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 <racor> 0, this is above my head and makes me shiver
15:39:23 <spot> #action Java Guideline Changes approved (+1:6, 0:1, -1:0)
15:39:44 <abadger1999> 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 <abadger1999> 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 <geppetto> 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 <spot> #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 <spot> j_dulaney: go ahead
15:43:23 <j_dulaney> I saw Automake is to be orphaned.  I'm thinking I could take that
15:43:34 <j_dulaney> But, I'm not a packager
15:43:55 <j_dulaney> not yet, anyway
15:43:59 <spot> j_dulaney: fesco has a procedure for new packagers to take on orphaned packages
15:44:19 <j_dulaney> Righteo
15:44:23 * j_dulaney looks into it
15:46:05 <spot> err, actually
15:46:13 <spot> i don't think that specific case is documented
15:46:19 <spot> but either way, that is a fesco issue
15:46:29 <spot> 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 <spot> http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
15:46:54 <spot> racor: why would they want to maintain legacy versions of autotool?
15:47:03 * spot doubts most people are that masochistic.
15:47:33 <racor> spot: the legacy versions are 0 effort
15:47:46 <spot> this isn't automake, iirc, its automake14, automake15
15:47:54 <spot> racor: until they hit bugs.
15:48:35 <racor> 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 <racor> s/says/stay/
15:48:57 <racor> spot: ACK
15:49:33 * j_dulaney thinks it could be a good foot in the door type of thing
15:49:47 <spot> so i'd personally rather see the RH autotool guy to work on porting those packages to current autotools. :)
15:49:59 <spot> but i don't get to make those calls.
15:50:02 <tibbs|h> Honestly I'd think it would be a pretty bad way to start out packaging.
15:50:17 <spot> j_dulaney: i think it might be easier to package something you have an interest in.
15:50:29 <tibbs|h> But if you're really good at autotools, I guess we could use more people like that.
15:50:31 <spot> (assuming that you're not interested in legacy autotools)
15:51:20 <j_dulaney> Well, sort of
15:52:08 <spot> If there are no other topics, I'm going to close out the meeting
15:52:32 <spot> Thanks everyone
15:52:34 <spot> #endmeeting