17:01:37 <spot> #startmeeting Fedora Packaging Committee
17:01:37 <zodbot> Meeting started Wed Feb 15 17:01:37 2012 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:01:40 <spot> #meetingname fpc
17:01:40 <zodbot> The meeting name has been set to 'fpc'
17:01:45 * spot just got out of one meeting
17:01:57 <tibbs|h> Guys, the city inspector is here to sign off on the permit for the air conditioner I recently had installed.
17:02:10 <tibbs|h> I have to step away for a bit but I'll be back as soon as I can get down from the attic.
17:05:16 <spot> #topic Roll Call
17:06:12 * abadger1999 here
17:07:04 * limburgher here
17:07:09 * spot is here and mostly ready
17:07:35 * racor here, but will likely have to quit early
17:07:38 * geppetto is around
17:08:46 <spot> okay, i see +5, tibbs will likely be back at some point as well
17:09:23 <spot> i'm skipping 137 for now, since we wanted rdieter's input there
17:09:51 <spot> #topic Remove libexecdir - https://fedorahosted.org/fpc/ticket/139
17:10:22 <spot> well, its a bit more nuanced than that
17:10:37 <abadger1999> Yeah, seems to propose two changes:
17:10:50 <abadger1999> s!%{_libdir}!/usr/lib!
17:11:00 <abadger1999> and remove %{_libexecdir}
17:11:38 <tibbs|h> Ugh.
17:11:53 <tibbs|h> OK, I'm semi-back.
17:12:29 <abadger1999> I'm currently would be -1 on both... no new arguments for %{_libexecdir} and /usr/lib vs %{_libdir} is... troublesome.
17:13:33 <abadger1999> The primary use case we had for using %{_libdir}/SUBDIR was so that packages that already placed arch-dependent data there could reuse it... if they could come up with a brand new place, %{_libexecdir} works fine.
17:13:51 <abadger1999> Using /usr/lib instead defeats that purpose.
17:14:29 <spot> I agree. -1 on both. my reading of the FHS doesn't require that /usr/lib be used (or forbid /usr/lib64 from being used).
17:14:52 <spot> In fact, the FHS says "/usr/lib<qual> performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/lib<qual>/sendmail and /usr/lib<qual>/X11 are not required."
17:15:02 <spot> emphasis on "the same role"
17:15:44 <limburgher> That's what I got from it as well.
17:16:10 <racor> -1, spot and abadger1999 summarized it nicely.
17:16:23 <geppetto> I can see the desire to use /usr/lib for non-arch. stuff … and a few things already do that. And libexec is kinda confusing on how it's different.
17:16:25 <limburgher> -1
17:16:55 <spot> i see -4 on both items in ticket 139
17:17:02 * abadger1999 notes that the ticket talks about LSB rather than FHS but we've never made conformance to LSB a Fedora goal
17:17:06 <geppetto> But I don't see a good alternative, in general and/or in this ticket.
17:17:50 <geppetto> Also I'm very leary of the "promotion" of cross distro. stuff, with respect to this, where Debian/etc. are way out in crazy land with their 64 bit stuff.
17:18:19 * geppetto shrugs … -1 for both, but I'm maybe more sympathetic than others :)
17:18:37 <spot> tibbs|h, i think you're the missing voter
17:18:57 * spot realizes tibbs|h  may not be fully back yet
17:19:26 <spot> #action Both items in #139 rejected (+1:0, 0:0, -1:5)
17:19:59 <spot> #topic Clarification for rootfs vs /usr split and libraries needed for F17+ - https://fedorahosted.org/fpc/ticket/140
17:20:15 <spot> i actually thought this was an easyfix when i saw it on the list
17:20:21 <spot> so i went ahead and took it out
17:20:44 <geppetto> Given that /bin == /usr/bin … does it actually matter where they get installed?
17:21:02 <geppetto> Changing this while EPEL still has older distros. just seems like it'll be confusing for no reason.
17:21:06 <spot> geppetto: hence why i removed it
17:21:23 <spot> keep in mind that EPEL 5 is about EOL IIRC
17:21:34 <geppetto> uh huh
17:21:35 <limburgher> EPEL 4 you mean?
17:21:37 <racor> spot: EPEL4
17:21:41 <spot> sorry, EPEL4
17:21:56 * geppetto nods … yeh, EPEL-4 … so just need to wait for two more to die :)
17:22:00 <spot> so, is this as simple as adding it to the EPEL guidelines?
17:22:12 <spot> or do we need to keep it in the main guidelines for any reason?
17:22:24 <abadger1999> spot: well... need to wait until f16 dies as well.
17:22:26 <geppetto> I just don't see what harm it does in the main guidlines.
17:22:49 <geppetto> It's not like it's bad to follow it … it just doesn't matter if you don't anymore.
17:23:03 <geppetto> Or … it won't matter, for F17+
17:23:17 * spot hits the undo button on that removal
17:23:47 <spot> perhaps we can add an admon|note there to indicate irrelevancy in F17+ ?
17:23:51 <abadger1999> Yep.
17:24:01 <geppetto> Sure
17:24:22 <abadger1999> That would be typical -- then when F17 is the oldest relevant Fedora, it becomes just a clarification to move it to the EPEL guidelines.
17:24:37 * geppetto nods
17:24:39 * abadger1999 doesn't even know where this text is at present :-)
17:25:54 <spot> "admon/note||This section is only relevant on versions of Fedora older than 17 and EPEL."
17:26:07 <abadger1999> http://fedoraproject.org/wiki/Packaging:Guidelines#Binaries_in_.2Fbin_and_.2Fsbin
17:26:08 <spot> do we need to say more than that?
17:26:15 <abadger1999> +1
17:26:36 <geppetto> I don't think we do.
17:26:39 <geppetto> +1
17:26:40 <spot> +1 from me
17:26:43 <limburgher> +1
17:27:42 * spot sees +4 on the item
17:28:37 <spot> racor or tibbs|h, we need a vote from you
17:30:04 * spot drops a pin
17:31:05 * geppetto hears the pin drop
17:31:59 * spot sighs
17:32:58 * limburgher steps on pin, barefoot
17:33:02 <abadger1999> Update ticket with guideline and present vote.  Vote in ticket.
17:33:06 * abadger1999 will do that now
17:36:34 <abadger1999> Ticket updated.
17:37:09 <spot> i'm sorry. to add insult to injury, gnome-shell just crashed on me
17:37:32 <geppetto> Do we want to talk about 141, or just wait until next week?
17:37:35 <abadger1999> spot: Maybe there's a crash-shell cron job and that's where tibbs|h and racor went too.
17:37:56 <spot> did we get the fifth vote?
17:38:07 <abadger1999> spot: We did not.
17:38:09 <geppetto> spot: no, but abadger1999 updated the ticket
17:38:32 <abadger1999> spot: I updated ticket to show the present vote and request FPC members vote in ticket to get the one last required vote.
17:38:34 <spot> okay.
17:38:45 <spot> so, technically, i do not believe we have quorum at this point.
17:38:47 <spot> we can continue from a "looking at things" perspective on the other two tickets on the agenda (ruby and SC)
17:38:49 <spot> abadger1999: i see that now, thanks.
17:39:07 <limburgher> And I have another item for discussion when we get to that point.
17:39:18 <spot> so, while I'm happy to discuss 141 (or 134), i'd rather do so when we have quorum
17:39:24 <abadger1999> geppetto: Probabyl next week on this: https://fedoraproject.org/wiki/SoftwareCollections  but the big disclaimer at the top does reassure me somewhat.
17:39:32 <geppetto> yeh, I don't think either need to be discussed this week
17:39:41 <spot> abadger1999: please note, i added the disclaimer, they did not.
17:39:45 <abadger1999> ohh...
17:39:53 <geppetto> lol
17:40:02 <spot> they were going to slip this around the FPC and just tell people to use it
17:40:04 <limburgher> Er.
17:40:19 <abadger1999> Well, then.  If they're asking for Guidelines status, I think that's a whole 'nuther ballgame :-)
17:40:25 <spot> it is only after i emailed people at Red Hat and asked them to stop that and just propose it as a draft that they did so
17:41:40 <abadger1999> If we're going to consider it for the guidelines without the disclaimer, I definitely need to read it this week before I can think about it.
17:41:43 <spot> so, i propose we table 134, 137, and 141 until we have quorum
17:41:53 <spot> yeah, we should consider it without the disclaimer
17:41:54 <geppetto> +1
17:42:12 <limburgher> Agreed.
17:43:01 <abadger1999> For 134: I would like to know if those that are here think I should continue to pursue the issues/strategy I've brought up.
17:43:09 <tibbs|h> Sorry, I'll vote in the ticket.
17:43:15 <abadger1999> Here's my draft with the extraneous bits taken out: https://fedoraproject.org/wiki/User:Toshio/RubyPackagingDraft
17:43:17 <tibbs|h> Inconvenient timing for all this.
17:43:51 <geppetto> tibbs|h: I think spot is still here, can just +1 now for the /bin thing … and then meet next week.
17:43:52 <spot> well, tibbs is back so we have quorum again (barely)
17:44:14 <spot> tibbs|h: please vote somewhere. :)
17:46:28 <spot> abadger1999: ruby gives me migraines
17:46:35 <abadger1999> Re: ruby.  There's a few things.  I'll take them easier to harder.
17:46:39 <spot> abadger1999: and my hat is off to you for trying to deal with it
17:46:50 <limburgher> spot: Seconded.
17:46:59 <abadger1999> /usr/share/rubygems /usr/share/gem and all that.
17:47:15 <abadger1999> So the /usr/share/rubygems thing seems to be entirely our choosing, not upstreams.
17:48:03 <abadger1999> I've ben working on them moving it to vendorlib and making vendorlib be shared if they really want to share the rubygems module between interpreters.
17:48:43 <abadger1999> They don't really want to see vendorlib be shared but seem to be open to the idea of putting rubygems into the per-interpreter directory.
17:49:10 <abadger1999> which would free up /usr/share/rubygems if we want to then ask that that be used as the toplevel no-arch-gems directory.
17:49:26 <abadger1999> That sound good?
17:49:55 <spot> i suppose. honestly, that is rather low on my concerns with this effort.
17:50:09 <abadger1999> <nod>  It's also the easiest resolution :-)
17:50:20 <abadger1999> Next one is revamping the requires.
17:50:27 <tibbs|h> Yeah, at this point avoiding gems/gems seems a trivial issue, but on the other hand if we can get it resolved then all the better.
17:50:55 <abadger1999> When lutter wrote and we approved the guidelines, you needed two different ruby syntax to load a plain ruby library vs a gem.
17:51:14 <abadger1999> (this is also why we wanted gem packages to be packaged as both gem and non-gem)
17:51:48 <abadger1999> Since that's no longer the case if your code is doing a "require 'rubygem' " I've simplified the Requires situation.
17:52:25 <spot> that section seems okay to me
17:52:26 <abadger1999> I think the disagreements are mostly about not understanding the proposed changes -- if anyone sees a problem that I'm not, please speak up now and I'll change that or drop that :-)
17:52:58 <spot> perhaps the addition of a "If you're not sure, just use "Requires: ruby(rubylibrary)"
17:53:42 * SmootherFrOgZ is around beside a dayjob meeting (sorry!)
17:53:44 <spot> or maybe just a one line answer with a longer "details" section below it
17:53:50 <spot> SmootherFrOgZ: it happens.
17:54:09 * spot has a hard stop in 5 minutes as is
17:54:09 <abadger1999> spot: <nod>  I can do that.
17:54:18 <abadger1999> Maybe asking the rubysig if that should be the default.
17:54:23 <abadger1999> Lastly is the build changes.  When we wrote the guidelines with lutter, it seemed like there was no way to break it into the typical %prep %build %install phases.
17:54:31 <abadger1999> That's no longer the case.
17:55:02 <abadger1999> However, the ruby sig has had it easy all these years; making the guidelines and rpm packaging conform to the standards of the ruby world rather than the other way around.
17:55:04 <spot> so, i like the build changes, because they map up well with the rpm model, but i can also see how it is making their packaging notably more complex
17:55:15 <abadger1999> I don't htink it does make it more complex.
17:55:28 <spot> well, just from a loc perspective
17:55:30 <abadger1999> (I stated before the meeting that in the best case, it's three extra lines)
17:55:49 <spot> there was nothing in %build at all before in the common case
17:56:13 <abadger1999> spot: Yes, but that's just one of the extra lines and the rest is shifted from the %prep section.
17:56:24 <abadger1999> Since we no longer need to build the package in the %prep section.
17:56:57 <spot> abadger1999: i think we'll want to hear the technical objections on your proposed approach from the ruby sig
17:57:03 <spot> but i like it.
17:57:37 <abadger1999> Okay, I'll ocntinue working this strategy until they come up with better examples of issues that I can examine.
17:57:47 <limburgher> Awesome.  Thank you .
17:57:47 <spot> okay, before i have to run
17:57:52 <spot> #topic Open Floor
17:57:56 * abadger1999 done
17:58:01 <spot> I'm not going to be around for this meeting next week
17:58:16 <spot> so we can either push out two weeks
17:58:21 <abadger1999> oh... that brings one thing up -- Ruby-1.9.3 F17 feature depends on the guidelines change.
17:58:25 <spot> or we can try for quorum without me
17:58:46 <limburgher> I vote push out, all I have is https://fedorahosted.org/fesco/ticket/799 and it can sit.
17:59:00 * geppetto nods … I don't see a problem with it
17:59:04 <spot> abadger1999: can the ruby item wait two weeks?
17:59:11 <spot> or does it risk feature reject?
17:59:18 <abadger1999> I'll talk with nirik about it -- we're already past alpha...
17:59:26 <abadger1999> So it may risk feature reject.
17:59:27 <spot> okay, we can probably vote on it via trac
17:59:40 <spot> just add a comment to the ticket when the draft is ready for a vote
17:59:45 <spot> (please)
17:59:46 <abadger1999> but they're already risking feature reject (things like puppet aren't rebuilt for the new ruby yet)
18:00:00 <abadger1999> so... it's just one more straw.
18:00:03 <abadger1999> Will do.
18:00:08 <limburgher> abadger1999: Oh.  That. Pfft. :)
18:00:17 <spot> okay, so we'll cancel next week and reconvene again in two weeks
18:00:30 * geppetto nods
18:00:30 <abadger1999> limburgher: Right.  Past Alpha?  Who cares? ;-)
18:00:35 <spot> please read the draft in #141 and give it some thought.
18:01:06 * spot knows how he feels, but i want people to make up their own mind on the topic.
18:01:29 <spot> okay, i think that's it. thanks everyone, see you in two weeks.
18:01:32 <spot> #endmeeting