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