16:06:21 <spot> #startmeeting Fedora Packaging Committee
16:06:21 <zodbot> Meeting started Wed Nov  7 16:06:21 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:06:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:06:26 <spot> #meetingname fpc
16:06:26 <zodbot> The meeting name has been set to 'fpc'
16:06:38 <spot> sorry folks, long night last night + daylight savings
16:06:43 <spot> #topic Roll Call
16:07:38 * racor is here
16:08:40 <spot> abadger1999, limburgher, rdieter, SmootherFrOgZ, tibbs: ping?
16:08:49 * abadger1999 here
16:08:49 <limburgher> Hi!
16:09:05 <rdieter> hola
16:09:59 <tibbs> Ugh.
16:10:43 <limburgher> We just need Richard Simmons and we'll have the enthusiasm scale covered.
16:11:04 <tibbs> Sorry, been messing with windows all morning.  It's soured my mood.
16:11:11 <pingou> aloha
16:11:37 <spot> okay. lets start this show.
16:11:55 <spot> #topic Bundled lib exception request for libtidy bundled with sigil - https://fedorahosted.org/fpc/ticket/219
16:13:39 <spot> today is a bundling day, try not to get too excited. ;)
16:13:44 <limburgher> <dies>
16:13:52 <tibbs> Looks like I started off on the right foot, then.
16:13:58 <limburgher> :)
16:14:05 <spot> so, in this case (libtidy is dead upstream, Sigil upstream willing to maintain their Sigil specific fork)
16:14:05 <limburgher> Looks like we still need info on this one, no?
16:14:46 <spot> unless we're waiting to see if they'll use tidy-html5, this seems like a logical exception case to me.
16:15:31 <limburgher> I can't think they would, but they've not said.
16:15:37 <tibbs> I don't understand what is meant by the last comment there.
16:16:26 <spot> tibbs: not sure i do either, but i don't think it matters. the information in the original ticket seems sufficient enough for me to be +1 on bundling exception here.
16:16:27 <rdieter> tibbs: probably means some questions we may have about the motives behind the modifications may go unanswered (the original author being unavailable)
16:17:02 <tibbs> I just saw some implication that the last guy who understood the bundled code is gone.
16:17:22 <rdieter> tibbs: that was my impression
16:17:23 <abadger1999> yeah
16:17:37 <tibbs> Which would be a bad thing, but I could just be reading it wrong.
16:17:42 <limburgher> It would.
16:17:47 <abadger1999> which makes 1) maintaining separately harder 2) maintaining at all harder.
16:18:39 <spot> isn't that upstream's issue more than Fedora's? I mean, they're dependent on this functionality, right?
16:18:39 <abadger1999> 2 trumps 1 for me... the comment makes me less likely to vote for an exception.
16:19:02 <abadger1999> spot: the package doesn't need to be part of Fedora in its present state though.
16:19:24 <abadger1999> because we'll be on the hook for fixing security issues whether or not upstream is able to help out with that.
16:20:32 <spot> yeah, i hear that, but i still think I'm +1 here. the upstream pulled out all the other bundling and this is modified for their usecase specifically.
16:21:00 <limburgher> How responsive are they on security issues on this code, or is there any history there to evaluate?
16:21:10 <spot> arguing that we don't think they can maintain their own derived work of libtiny seems... a bit too elitist for me.
16:21:23 <spot> s/tiny/tidy
16:22:12 <spot> if the tidy upstream was alive and kicking, maybe it would be more concerning, but they're not.
16:22:17 * rdieter agrees with spot, consider me +1
16:22:31 <tibbs> I don't really have a problem with this bundling; just trying to comprehend what the purpose of tacking on that comment was.
16:23:54 * SmootherFrOgZ here
16:24:16 <spot> okay, i see +2 on this bundling request. any one else want to vote on the record? or have other points to raise?
16:24:27 <tibbs> +1
16:24:27 <limburgher> +1
16:24:27 <abadger1999> -1, I would rather have the changes turned into a new fork or merged with an existing fork  (or explanation of why that won't work made).
16:24:54 * SmootherFrOgZ has to read first
16:25:42 <abadger1999> SmootherFrOgZ, racor: A +1 from either of you should get this to accepted status.
16:25:46 <spot> we're sitting at +1:4, 0:0, -1:1, with racor and SmootherFrOgZ not yet voted.
16:26:38 <spot> abadger1999: fwiw, im not at all opposed to asking the Sigil upstream to strongly consider maintaining their fork of libtidy as an independent component
16:27:03 <abadger1999> spot: <nod>  I wouldn't be opposed to voting +1 after that option has been explored.
16:27:04 <tibbs> That's always a good thing, I'd think.
16:27:33 <abadger1999> I just don't want to vote plus one before that has appened.
16:27:40 <SmootherFrOgZ> k. what would it take to get that into a fork or merged with existing?
16:27:56 <abadger1999> The current diff isn't large.
16:28:08 * abadger1999 looked at it wen we considered this last.
16:28:12 <spot> abadger1999: yep. i see that. :) I just think if they said "no, we're not going to do that", we'd still come back and grant the bundling exception.
16:28:21 <abadger1999> But the epub specific changes probably would need a little more work.
16:28:25 <spot> so the net outcome is no different.
16:28:41 <racor> +1 (Sorry was distracted)
16:28:50 <abadger1999> because they would need to be controllable via a flag.
16:29:07 <spot> SmootherFrOgZ: we're now at +5, if you would like to vote for the record, go ahead.
16:29:31 <abadger1999> function(epub=True):  do epub changes.  function(epub=False): do not do epub changes
16:29:56 <SmootherFrOgZ> spot: ha, so if it not pass, we may have this request again if upstream won't give it some love
16:30:00 <SmootherFrOgZ> hrm...
16:30:15 <spot> SmootherFrOgZ: no, +5 means it has passed. :)
16:30:28 <spot> SmootherFrOgZ: if you want to vote for the public record, you can.
16:30:37 <abadger1999> <nod>  Many times  upstreams won't do unbundling work unless tey have an incentive though.... for that matter, a number of times package maintainers won't bother upstream about bundling unless they have a similar incentive.
16:30:40 <SmootherFrOgZ> ha so then, I would be in favor of abadger1999 's comment and -1
16:31:06 <spot> #action Bundling exception approved (+1:5, 0:0, -1:2). FPC will also ask packager to ask Sigil upstream to strongly consider maintaining their fork of libtidy as an independent component.
16:31:53 <spot> Okay, on to the next one
16:32:11 <spot> #topic Bundling exception request: numptyphysics and Box2D - https://fedorahosted.org/fpc/ticket/221
16:32:24 <limburgher> Abstaining, as it's mine, but can answer questions.
16:32:50 <spot> i've seen this argument before, game physics being very very picky
16:32:55 <limburgher> Right.
16:33:03 <spot> i was maintaining two physfs versions for a while as a result
16:33:20 <tibbs> Do what was wrong with the compat-foo solution?
16:33:23 <limburgher> Ick. *cough*irrlicht*cough*
16:33:26 <spot> the obvious question that comes to mind is: is the box2d forked?
16:33:35 <spot> if not, why not maintain it as a compat package?
16:33:58 <tibbs> Seems like that would be the most expedient solution in any case.
16:34:05 * spot nods
16:34:06 <limburgher> My guess is yes, since I can't figure out what version it is.
16:35:10 <abadger1999> Well -- no new Box2D release for over a year so it seems this is no longer a moving target?
16:35:32 <limburgher> One would think.
16:35:42 <abadger1999> http://code.google.com/p/box2d/downloads/list
16:35:44 <spot> maybe propose a set of patches to bring it to the current box2d?
16:35:59 <limburgher> I've not been able to create that.
16:36:07 <spot> also, it claims to be Box2D 2.0.1
16:36:18 <limburgher> Oh, does it?  I missed that, thanks.
16:36:33 <limburgher> We have 2.2.1.
16:36:47 <limburgher> Maybe I can try the compat option.
16:37:13 <SmootherFrOgZ> spot: +1 for the patches request
16:37:34 * SmootherFrOgZ hopes upstream still is insteresting as said in email
16:38:02 <spot> a very quick diff shows one forked change
16:38:05 <spot> -const int32 b2_maxProxies = 512;				// this must be a power of two
16:38:05 <spot> +const int32 b2_maxProxies = 512*4;				// this must be a power of two
16:38:42 <limburgher> That's not so bad.  I'll definately try compat and close this ticket if it works.
16:39:24 <spot> okay, lets table this for a while then
16:39:47 <spot> #action tabling issue, pending compat package workaround
16:40:04 <spot> #topic Permission to build supercollider with bundled libraries - https://fedorahosted.org/fpc/ticket/225
16:40:38 <spot> There is a proposal in the ticket from abadger1999:
16:40:40 <spot> Proposal: Allow bundling of lockfree and atomic through F20. If the libraries aren't in upstream boost that we ship in F21, package the two libraries into their own (sub)packages and link against those for F21.
16:40:51 <spot> I'm +1 on that.
16:41:06 <limburgher> +1
16:41:35 <SmootherFrOgZ> +!
16:41:37 <SmootherFrOgZ> +1
16:41:45 <abadger1999> +1
16:42:13 <tibbs> I believe that's reasonable.  +1.
16:42:41 <rdieter> +1
16:43:13 <spot> racor: if you'd like to vote on the record, we'll wait a moment.
16:43:39 <racor> +1, was reading the proposal
16:44:23 <spot> #action Allow bundling of lockfree and atomic through F20. If the libraries aren't in upstream boost that we ship in F21, package the two libraries into their own (sub)packages and link against those for F21. (+1:7, 0:0, -1:0)
16:45:02 <spot> #topic Bundling exception request for byteman - https://fedorahosted.org/fpc/ticket/226
16:45:46 <spot> now, i admit to not understanding this entirely, but it is bundling itself?
16:46:28 <spot> Or is it bundling other things?
16:46:40 <tibbs> This doesn't appear to provide much of the requested information at all.
16:46:54 <geppetto> uh … I guess I'm off by an hour.
16:46:56 <geppetto> Sorry.
16:46:58 <limburgher> I'm not clear why this can't have another package for this stuff and BR it.
16:47:17 <spot> yeah, i'll ask for more info and we'll revisit later
16:47:43 <tibbs> So the last paragraph seems to be the relevant bit.
16:48:28 <tibbs> It needs to include "transformed" versions of all of its dependencies so those libraries don't conflict with the libraries that may be used by the software that is being instrumented.
16:49:04 <abadger1999> yeah -- I think they're asking to bundle ASMlibrary (as it's currently the only dependency)
16:49:24 * spot asked "Could the ASMlibrary package generate a special "transformed" version as part of its normal build process that byteman could Require (and use)? "
16:49:25 <abadger1999> tey'd probably like a generic exception to bundle other libraries later too.
16:49:34 <abadger1999> <nod>
16:49:46 <tibbs> I think ASM is just the only library listed.
16:49:56 <tibbs> In any case, the request is incomplete.
16:50:01 <spot> that seems more scalable than bundling (and way more scalable than an open bundling exception).
16:50:06 <spot> we'll revisit when we know more.
16:50:14 <abadger1999> Or even -- knowing if they were bundling the source but it could be transformed automatically at build time.
16:50:33 <spot> #topic Kadu - libiris bundled - https://fedorahosted.org/fpc/ticket/230
16:50:33 <abadger1999> (and updating that bundled source was then easy)
16:51:47 <tibbs> I'm not sure iris could properly be considered a copylib.
16:51:50 <spot> So, we have Kadu, who found issues with libiris, tried to send patches, got no response.
16:51:59 <spot> Ended up forking libiris.
16:52:05 * abadger1999 would push the upstream to take over upstream maintainance of iris
16:52:13 <abadger1999> or making a public fork.
16:52:28 <rdieter> having tried to contact iris upstream, it's a royal pain.
16:52:35 <rdieter> brb, phone
16:52:36 <spot> abadger1999: they have one
16:52:39 <spot> abadger1999: http://gitorious.org/kadu/libiris
16:52:52 <limburgher> So. . .package that?
16:53:06 <tibbs> This isn't the only forked version of iris, is it?
16:53:17 <tibbs> I seem to recall various issues with that library in the past.
16:53:18 <abadger1999> limburgher: +1
16:53:19 <spot> i'm sure it isn't, given what i've heard about iris.
16:53:48 <spot> but yeah, i think packaging libiris-kadu (hey, i just named it) and having kadu link to that is the best solution here.
16:53:57 <rdieter> forks/bundles that I'm aware of include: psi, psi++ (review blocked on bundling), kdenetwork/kopete (on my plate)
16:54:06 <tibbs> One wonders if all of the forkers could just converge on something else.
16:54:18 <limburgher> tibbs: Or this.
16:54:53 <rdieter> psi++ devs are the real upstream, just working with them is hard, they only do development on jabber groupchat, at odd hours (for me), mostly in russian
16:55:06 <spot> Proposal: Ask Kadu packager to package and use the kadu fork of libiris (in a way that does not conflict with the existing libiris package).
16:55:13 <rdieter> spot: +1
16:55:16 <tibbs> spot: +1
16:55:22 <limburgher> +1
16:55:24 <abadger1999> +1
16:55:24 <spot> +1
16:55:30 <racor> +1
16:55:34 <geppetto> spot: So you want him to package it as libkaduiris?
16:55:45 <spot> geppetto: or libiris-kadu or whatever.
16:55:45 <SmootherFrOgZ> +1
16:56:20 <geppetto> meh. +1
16:56:24 <spot> #action Ask Kadu packager to package and use the kadu fork of libiris (in a way that does not conflict with the existing libiris package). (+1:8, 0:0, -1:0)
16:58:11 <spot> okay, i think thats all the outstanding bundling tickets
16:58:30 <spot> #topic Open Floor
16:58:55 <tibbs> With two minutes to spare....
16:59:12 <spot> just a reminder, we meet at 1600 UTC.
16:59:54 <spot> which is now an hour earlier depending on your daylight savings time setting.
17:00:21 <spot> if there are no other issues in the next, oh, two minutes, i'll close out the meeting.
17:00:36 * abadger1999 just notes tis is te oter open iris ticket: https://fedorahosted.org/fpc/ticket/137
17:02:24 <rdieter> i suppose we ought to propose the same solution there
17:02:47 <spot> okay, i'll do that
17:08:01 <tibbs> I guess we're all done, then?
17:08:07 <limburgher> I think so.
17:08:22 <rdieter> er, by "same" solution, I guess I really meant similar, and suggest something like libisis-psi++
17:08:25 <rdieter> spot: ^^
17:08:53 <rdieter> psi++ is the real libiris developmental upstream
17:09:04 <tibbs> Well, if they could work together somehow....
17:09:23 <tibbs> Or is that the upstream that is difficult to communicate with?
17:09:33 <rdieter> difficult yes.
17:09:40 <rdieter> [11/07/12 10:54] <rdieter> psi++ devs are the real upstream, just working with them is hard, they only do development on jabber groupchat, at odd hours (for me), mostly in russian
17:10:02 <tibbs> I'm losing track of just which libiris is which.
17:10:37 <rdieter> psi++ is the development branch, psi uses the stable/released branch
17:11:58 <tibbs> It's always annoying when upstreams do that kind of thing.
17:12:02 <rdieter> very
17:12:30 <rdieter> psi currently can't unbundle because it seems to use private headers/interfaces
17:12:59 <rdieter> ideally, libiris would be a subpkg from psi (I may help work on that someday)
17:13:29 <rdieter> anyway, we're overtime and digressing a small bit, I'm ok with ending things here
17:13:34 <spot> rdieter: i'm going to leave it up to you then. if you maintain the psi fork, thats fine.
17:13:48 <spot> and with that, i'm going back into the bowels of steam.
17:13:51 <spot> thanks everyone.
17:13:54 <spot> #endmeeting