16:00:04 <spot> #startmeeting Fedora Packaging Committee
16:00:04 <zodbot> Meeting started Wed Nov  9 16:00:04 2011 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:06 <spot> #meetingname fpc
16:00:06 <zodbot> The meeting name has been set to 'fpc'
16:00:12 <spot> hmm
16:00:14 <spot> i wonder if i am talking to myself here.
16:00:16 <spot> ah, there it goes
16:00:20 <spot> #topic Roll Call
16:00:25 <tibbs|h> Howdy.
16:00:28 <limburgher> gabba
16:01:29 * racor is here, did meeting time change?
16:01:39 <spot> racor: no, 1600 UTC as usual
16:01:44 <tibbs|h> It appears to be at the same time as always.
16:01:51 <racor> spot: it was 15:00 UTC
16:02:14 <racor> 16:00 UTC, means it has shifted
16:03:07 * geppetto is here
16:06:23 * spot grumbles as the network connection on his irc bounce goes up and down
16:06:42 <spot> i counted 5 members present
16:06:49 <spot> before my network dropped me off
16:06:59 <spot> so, lets get started
16:07:11 * abadger1999 here
16:07:33 <spot> #topic Add /opt and /usr/local to the section on /srv - https://fedorahosted.org/fpc/ticket/115
16:07:56 * geppetto is here
16:08:30 <spot> This one should be pretty straightforward. I propose that we add /opt and /usr/local to the existing section on /srv, with the same guideline restrictions (basically, no package should put files there).
16:08:52 * abadger1999 still +1 to it.
16:08:52 <tibbs|h> I'm fine with this.
16:09:10 <tibbs|h> I always enforced that in review anyway.
16:09:10 * spot is +1
16:09:22 <geppetto> spot: I know the stacks things is looking to use /opt atm. … and they _really_ don't seem to want to "integrate" … so do you want them to use something else, or just to have a giant flamewar and maybe revert when they want to put stack packages in Fedora?
16:09:34 <limburgher> +1
16:09:42 <geppetto> I'm fine to +1 … just trying to make sure you can see the future too
16:10:13 <limburgher> geppetto:  Why do they want to use /opt?
16:10:17 <spot> geppetto: i tried very hard to come up with some sort of technical reasoning for using /opt, and the best I could come up with was so flimsy, it fell over when the wind blew.
16:10:35 <Southern_Gentlem> !
16:10:43 * abadger1999 hasn't seen the stacks dialgoue... must be living under a rock.
16:10:56 <abadger1999> Southern_Gentlem: you can just speak in the FPC meeting.
16:11:07 <geppetto> My understanding is that they want all the code "separate" … more like the windows model … so you can "easily" have N different versions
16:11:12 <spot> abadger1999: the full stack proposal is not... clear.
16:11:20 <Southern_Gentlem> i use /opt for installing stuff out of repo so no nothing in the repos should ever use /opt
16:11:21 <spot> abadger1999: and it is not publicly disclosed at this point
16:11:27 <spot> Southern_Gentlem: *nod*
16:11:31 <geppetto> So /opt isn't the requirement … not putting stuff in / is the "requirement"
16:11:52 <spot> geppetto: its a flawed "requirement", imho.
16:12:28 <spot> but in the context of Fedora, I just wanted to be sure we were clarifying these namespaces. /usr/local came up in the perl package recently.
16:12:33 <geppetto> I'm not going to argue with that … but just making sure you know they'll be a giant argument in the next 6 months or so
16:12:47 <geppetto> As I don't see them moving to putting stuff in /
16:12:51 <spot> geppetto: its already a giant argument.
16:13:06 <geppetto> Ok … +1
16:13:32 <tibbs|h> In case it wasn't obvious from my earlier comment, +1 from me.
16:13:55 <spot> i see +5 on the table, no votes from racor yet
16:14:08 <racor> +1
16:14:34 <spot> #action Add /opt and /usr/local to the section on /srv (+1:6, 0:0, -1:0)
16:14:40 <limburgher> You can make parallel-installable RPMs without touching /opt.
16:14:46 <spot> limburgher: indeed you can.
16:14:58 <SmootherFrOgZ> +1 from me (just get back)
16:15:05 <limburgher> spot:  I did a few at work just this week. :)
16:15:22 * spot notes that we have examples of this in EPEL and Fedora right now
16:15:29 <spot> but anyways, lets move on
16:15:48 <spot> #topic Copylib exception for OkJson - https://fedorahosted.org/fpc/ticket/113
16:16:14 <spot> This is a fun one, where upstream for OkJson says 'this library is intended to be "vendored"'
16:16:21 <limburgher> Barf.
16:16:28 * spot is not a ruby expert by any definition
16:16:52 <spot> but it seems like we should still be able to package it separately and just delete the bundled copies everywhere
16:16:59 <spot> unless there is widespread forking
16:17:17 <limburgher> Which is possible but I'm hoping not.
16:17:56 <limburgher> Do we have documented cases of forked versions of this lib in Fedora packages?
16:17:57 <spot> anyone here know ruby?
16:18:19 <abadger1999> The bug report for multi_json says it is patched.
16:18:21 <tibbs|h> Upstream's reasoning seems to be "this method helps you avoid an external dependency."
16:18:35 <limburgher> <headdesk>
16:18:53 <abadger1999> I don't think that upstream is that smart about this, but it seems like it may meet our definition of a copylib.
16:18:54 <tibbs|h> But they also say that you need to re-namespace it in order to avoid conflicting with other projects that might have "vendored" it.
16:19:07 <tibbs|h> Which implies that simply symlinking it around isn't going to work.
16:19:21 <pjones> it also implies a terrible view on how to use libraries in general.
16:19:25 <limburgher> tibbs|h: I'm not sure I buy that.
16:19:44 <spot> this is 490 lines of code
16:20:23 <spot> as distasteful as i find it, i think it meets the copylib criteria
16:20:30 <spot> and the risks are minimal in permitting it
16:20:54 <tibbs|h> It appears to be already bundled in rubygem-heroku.
16:20:56 <limburgher> How big is this projects patch?
16:21:09 <limburgher> is the -heroku version patched?
16:21:20 <tibbs|h> /usr/lib/ruby/gems/1.8/gems/heroku-2.0.4/lib/vendor/okjson.rb
16:21:59 <abadger1999> multi_json patch description: "Also, I have made some adjustments to ok_json to fallback to to_hash, similar to how the Json gem and Yajl work, making it more compatible with custom objects."
16:22:40 <tibbs|h> It does not appear to be the same code that's in upstream git.
16:22:47 <abadger1999> From that descripion I'm betting it's ~3 lines of code in 1 to2 places in the library.
16:23:04 <tibbs|h> Since the thing seems to be unversioned as well, welcome to the fun.
16:23:09 <limburgher> tibbs|h: As is, maybe an other version they forked?
16:23:15 <limburgher> Eeeeww.
16:23:24 <abadger1999> yeah -- probably it got refactored upstream and the vendored version is old.
16:23:32 <abadger1999> but -- who knows! :-)
16:24:01 <spot> there are some diffs
16:24:11 <spot> the whitespacing makes it hard to see quickly
16:24:17 <limburgher> I suppose it's a valid copylib, but the whole thing makes me itchy.
16:24:20 <spot> but they're definitely making changes
16:24:34 <tibbs|h> It appears to be modified to deal with parse errors differently.
16:24:42 <tibbs|h> But, yeah, fail.
16:25:00 <spot> Proposal: Begrudgingly permit copylib for ok_json.rb
16:25:03 <spot> +1
16:25:04 <limburgher> Gross.
16:25:12 <limburgher> +1 </purell>
16:25:27 <tibbs|h> +1 I guess. Don't really know what other choice we have.
16:26:31 <abadger1999> +1
16:26:41 <tibbs|h> Interestingly, rubygem-heroku is owned by the same person who submitted this request.
16:26:54 <tibbs|h> I guess it just got missed during review.
16:27:08 <spot> tibbs|h: easy enough to miss it the first time it appears
16:27:21 <racor> I can't deny to think, we are producing a precedence for "if upstream says no to unbundling, we give in and bundle", without upstream giving sufficient rationales.
16:27:23 <limburgher> Yeah.
16:27:45 <limburgher> racor:  I know, and I'd rather not do that.
16:28:06 <spot> racor: i hear you, but i think we have to choose our battles too, this is < 500 of trivial code, roughly on par with MD5 implementations
16:28:31 <limburgher> racor: But we don't have a guideline that says "No bizarre unversioned wads of code", either.
16:29:02 * spot notes that the count is at +4, no votes from racor, SmootherFrOgZ, or geppetto
16:29:24 <abadger1999> So what we have in the copylibs section of the guidelines does fit this.
16:29:44 <SmootherFrOgZ> ok, so let's +1 for that one
16:29:54 <abadger1999> but we do give ourselves leeway here since we've never been comfortable with the potential broadnes of the copylib exception.
16:30:09 <spot> vote is at +5, if racor or geppetto want to vote, they can do so for the record.
16:30:21 <racor> ... am undecided, hovering between "+1'in off this neglible detail" and "-1'ing for fundamental reasons"
16:30:43 <limburgher> racor: nods
16:30:57 <geppetto> +1
16:31:13 <geppetto> I don't really like it … but then I don't really like ruby :)
16:31:19 <racor> 0, geppetto opened the back door ;)
16:31:27 <spot> okay.
16:31:34 <limburgher> :)
16:31:44 <spot> #action Copylib approved (reluctantly) (+1:6, 0:1, -1:0)
16:31:53 <spot> #topic Open Floor
16:32:11 <tibbs|h> Has anyone filed anything about the UID allocation stuff?
16:32:30 <tibbs|h> As far as I can tell, there's some Red Hat internal group that's doing UID allocation since we have more space now.
16:32:51 * spot hasn't seen anything filed
16:33:07 <tibbs|h> I though we were all happy with just doing random on-demand allocation like we've been doing.
16:33:23 <tibbs|h> But it seems that there's a group that doesn't agree, but hasn't actually talked to anyone about it.
16:33:24 <spot> tibbs|h: where are you seeing explicit UID alloc?
16:33:31 <tibbs|h> I have some old IRC logs about it.
16:34:03 <tibbs|h> Looks like it was mitr.
16:34:18 <geppetto> I thought the point of the new user UID move was so that the "random UID on install" thing could be much bigger?
16:34:25 <spot> tibbs|h: best i can say is to file bugs.
16:34:40 <tibbs|h> Let me cut-n-paste some stuff.
16:34:40 <abadger1999> static uid allocation is the peak oil problem of our distribution.
16:35:00 <abadger1999> geppetto: no, they said that they were increasing both random and static.
16:35:25 <abadger1999> geppetto: b/c for a long time (but not since the dawn of Fedora) the random uid's have gone from the top of the range to the bottom.
16:35:29 <spot> i almost thing any changes to the static UID list belong to fesco
16:35:31 <tibbs|h> It's a bunch of commits to setup with static UIDs for packages.
16:35:33 <spot> s/thing/think
16:35:42 <tibbs|h> And there's actually an internal Red Hat procedure for allocating them.
16:35:50 <abadger1999> yeah -- internal rh should not be the iana of this.
16:36:17 <tibbs|h> See commits at http://git.fedorahosted.org/git/?p=setup.git
16:36:34 <geppetto> yeh, I'd be surprised if that was the case … more likely it's just "notting" or something
16:36:40 <spot> geppetto: *nod*
16:36:57 <spot> i think it would be worthwhile to bring this up with fesco
16:37:01 <tibbs|h> See also https://bugzilla.redhat.com/show_bug.cgi?id=715266
16:37:28 <spot> even if they just grandfather in the existing changes and then establish a procedure for making new static UID reservations
16:37:38 * geppetto nods
16:38:00 <spot> i think rhel should be inheriting this, not the other way around
16:38:11 <abadger1999> geppetto: maybe it should be notting but someone else has been doing it.  I recall the same conversations as tibbs.
16:38:20 * abadger1999 thinks some of it hit the devel mailing list too
16:38:28 <tibbs|h> Well, that was my thought, but they just went ahead and did it and didn't feel the need to talk to anyone about it.
16:38:43 <tibbs|h> I've been meaning to bring it up for weeks now but kept forgetting.
16:39:06 <abadger1999> Yeah.  +1 to file with fesco, do this in an organized manner.
16:39:33 <tibbs|h> But the intent seemed to me to go back to static UIDs for everything, because it allows consistency between audit logs from different machines.
16:39:36 <tibbs|h> Or something like that.
16:39:45 <limburgher> spot: +1
16:39:46 * geppetto nods … worst case we'll display our ignorance and FESCO will tell us what was decided :)
16:40:58 <spot> okay, if there are no other topics in the next 3 minutes, i'll close this out
16:41:58 <limburgher> Nothing here.
16:42:02 <tibbs|h> Nothing from me.
16:42:05 <spot> Reminder: Next week, we'll be back at our normal time of 1500 UTC.
16:42:27 <limburgher> Cool.
16:42:33 <abadger1999> Do we have an issue at 16:00?
16:42:49 <tibbs|h> I guess I was pretty confused; I thought it had always been 16:00.
16:42:53 <spot> abadger1999: i believe racor did, iirc
16:42:56 <abadger1999> k
16:43:17 * spot checked the wiki page and it says 1500, so unless someone is messing with my brain, it should have been 1500
16:43:29 <abadger1999> 15:00 would be 7:00AM for me which gets a bit early.
16:43:38 <tibbs|h> Maybe we should, you know, write down what we do on time changes.
16:43:46 <limburgher> tibbs|h: Heresy!
16:43:51 <SmootherFrOgZ> tibbs|h: I sent an email about that
16:43:57 <spot> we can do another "whenisbest" pass, but i doubt it will change much.
16:44:54 <abadger1999> yeah, let's do that.
16:45:27 <limburgher> k
16:50:00 * SmootherFrOgZ thinks spot forget to endmeeting
16:50:32 <tibbs|h> #endmeeting
16:50:42 <tibbs|h> Worth a try.
16:51:08 <abadger1999> he'd have to have #chair 'ed you first
16:51:48 <nirik> .addchair #fedora-meeting freenode tibbs
16:51:48 <zodbot> nirik: Chair added: tibbs on (#fedora-meeting, freenode).
16:51:59 <tibbs|h> #endmeeting
16:52:12 <nirik> huh. That should have worked.
16:52:18 <limburgher> sudo #endmeeting
16:52:19 <spot> #endmeeting