16:00:12 <spot> #startmeeting Fedora Packaging Committee 16:00:12 <zodbot> Meeting started Wed Sep 1 16:00:12 2010 UTC. The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:31 * limburgher as arrived 16:00:36 <spot> #item Roll Call 16:00:47 <spot> #topic Roll Call 16:01:13 * limburgher still hangin' on 16:01:27 <tibbs|h> I'm here. 16:01:40 <spot> abadger1999, rdieter, SmootherFrOgZ: ping 16:01:50 <rdieter> pong 16:01:52 <spot> racor: i assume you're also here, right? 16:01:53 * abadger1999 here 16:01:54 <racor> pong 16:02:10 <spot> okay, thats 6 of us 16:02:25 <tibbs|h> Sorry about last week. 16:02:31 <spot> tibbs|h: no worries. 16:02:39 <rdieter> tibbs|h: feeling better? 16:02:42 <spot> #topic https://fedorahosted.org/fpc/ticket/7 - D Packaging Draft 16:02:47 <spot> https://fedoraproject.org/wiki/D%2Bpackaging%2Bguideline%2Bdraft 16:02:48 <limburgher> pix? 16:03:00 <spot> I took some time to rework and simplify this draft 16:03:00 <tibbs|h> rdieter: Yes, a tooth had died and needed a root canal. Still in antibiotics. 16:03:06 <spot> tibbs|h: ouch. 16:03:37 <spot> and i see one minor bug 16:03:39 <spot> one sec 16:04:31 <spot> okay. minor bug fixed. 16:04:46 <spot> (some of the %install invocations were missing %{buildroot}) 16:05:26 <spot> ugh, one more bug (missing static provides in template) 16:05:34 <spot> wait, there it is. 16:05:36 <spot> sorry. :) 16:06:02 <spot> okay, does anyone have any comments on the updated draft here? 16:06:10 <tibbs|h> Seems clean enough. 16:06:13 <rdieter> worksforme , we'll see how well it works in practice soon enough (I assume) 16:06:31 <limburgher> Yeah, I see nothing obviously dangerous. The pudding, and all. 16:06:34 <tibbs|h> Is the case that there won't be a main package sufficiently common that the only template we have should represent that case? 16:06:50 <abadger1999> spot: Does %configure take care of adding the opt flags? 16:07:23 <spot> abadger1999: i have no idea. 16:07:24 <tibbs|h> Hmm, yeah, how does _d_optflags get passed to the compiler? 16:08:00 <tibbs|h> Is there a sample package that implements something close to these guidelines? 16:08:06 <tibbs|h> It would be nice to have something to actually build. 16:08:31 <spot> tibbs|h: yeah, that is a valid point. 16:08:50 <spot> i'll follow up with the ticket submitter on that issue and have it clarified for next week. 16:08:59 <limburgher> Is there anything to submit to rpmlint? 16:09:15 <tibbs|h> I mean, we can do guidelines in a vacuum, but it makes us seem a bit less foolish if we know they actually work. 16:09:16 <rdieter> good point, rpmlint may go nuts 16:09:18 <rdieter> as is 16:09:42 <tibbs|h> I guess it will still complain about lack of buildroot and such. 16:09:53 <tibbs|h> One day that may get fixed. 16:10:12 <limburgher> I've have to think the submitter would have something, and not submit this in a vacuum. 16:10:28 <spot> i think he does, this is part of his "D" feature for f14 16:10:36 <tibbs|h> I'd hope so too, but remember that this was significantly cleaned up from the original submission. 16:10:51 <tibbs|h> We should at least be able to make sure that a package so adjusted still actually builds. 16:11:15 <spot> i agree 16:11:23 <limburgher> yes. 16:11:40 <tibbs|h> We should probably ask for a sample working package with any new guideline submission. 16:11:55 <tibbs|h> Although the chicken and egg thing is problematic. 16:12:40 <spot> #action Spot will follow up with Jonathan Mercier about d_optflags, example package for testing. 16:12:59 <spot> #topic https://fedorahosted.org/fpc/ticket/8 - Bundled libraries guidelines 16:13:13 <spot> abadger1999 updated this draft since our last meeting. 16:14:14 <spot> i'm personally happy with it. 16:14:42 <spot> https://fedoraproject.org/wiki/Bundled_Library_Packaging_Draft 16:14:53 <spot> (thats the link, in case trac didn't make it obvious) 16:15:22 <rdieter> happy here too 16:15:52 <tibbs|h> What is the purpose of the bundled(foo) provide? 16:16:00 <tibbs|h> Just to make it obvious? 16:16:15 <abadger1999> To be able to query something and find out what's bundling a library. 16:16:44 <limburgher> that's awesome. 16:16:54 <abadger1999> For instance, if zlib has a security update, we can to repoquery --whatprovides bundled(zlib) and find out what else needs to be updated. 16:16:59 <tibbs|h> Yeah, makes sense. 16:17:05 <limburgher> So if we find a package bundling, we put that in the spec, and it can come out when fixed? 16:17:33 <spot> limburgher: assuming the exception is approved, of course. 16:17:40 <tibbs|h> Or if we see a bugfix in one library, we can at least figure out easily what else might be bundling it. 16:17:50 <abadger1999> Right 16:17:54 <tibbs|h> Same as foo-static, I guess. 16:17:59 <limburgher> spot: no, i meant when the package switches to a system lib. 16:18:01 <spot> I should apply this to chromium, it would be amusing. ;) 16:18:10 <tibbs|h> "FESCo" should be consistently capitalized, I guess. 16:18:37 <rdieter> bundled(*) 16:18:53 <limburgher> spot: we'd leave it there for an exception. 16:19:00 <racor> Shouldn't bundled() be arch'ed? 16:19:02 <spot> limburgher: gotcha, i agree. 16:19:24 <limburgher> and the only place the exeception is notes is the wiki? 16:19:28 <spot> racor: its a virtual provide for tracking purposes and it cannot be used to meet a Requires. 16:19:31 <tibbs|h> Do we need the "packages granted exceptions" section at all? 16:19:41 <spot> racor: what benefit does adding the arch provide? 16:19:59 <limburgher> how would we annotate the spec regarding exception status? 16:20:10 <racor> spot: won't it clash on prov/requ queries? I am simply not sure about it. 16:20:20 <rdieter> I guess there could be a wierd case of something being bundled only on certain arch's, but eww... 16:20:26 <spot> racor: i don't think it will clash. 16:20:28 <abadger1999> tibbs|h: I'd like to have it somewhere -- but that could easily be outside of packaging guidelines (so fesco could update it themselves) 16:20:34 <limburgher> rdieter: dude, I'm eating. 16:20:50 <spot> racor: nothing will ever Requires it, and multiple packages can already Provide the same provide. 16:21:08 <abadger1999> tibbs|h: The advantage of having it in the packaging guidelines is I can bother FESCo to provide rationale when they issue an exception. 16:21:09 <spot> the mta virtual provides are evidence of this 16:21:53 <abadger1999> rdieter: I think that we really are interested in the srpm so I don't think that's an issue. 16:22:09 <rdieter> abadger1999: totally agree. :) 16:22:32 <racor> spot: OK, we'll see if this works. 16:22:37 <tibbs|h> Honestly I think it would be good for packages to note in specfile comments that an exception was granted, linking to the relevant fesco ticket or whatever. 16:22:56 <abadger1999> That would work too. 16:22:57 <tibbs|h> Since otherwise you look at a package and can't really tell if what it's doing is OK or not. 16:23:00 <limburgher> agreed 16:23:02 <spot> tibbs|h: i'm okay with that addition 16:23:03 <abadger1999> (rather than the list in the wiki) 16:23:10 <spot> abadger1999: in addition to. 16:23:18 <limburgher> spot: yes. 16:23:23 <abadger1999> Okay. I'm okay with more documentation :-) 16:23:34 <tibbs|h> I mean, honestly, anything weird done in a spec deserves a comment. 16:24:03 <racor> for my taste the "exception intro/preamble" doesn't sound strong enough. 16:24:39 <tibbs|h> The "Exceptions are granted on a case-by-case basis by FESCo with input from FPC. You can look in the following section for help on making a case for why an exception should be granted." bit? 16:24:56 <racor> we should emphasize at exceptions real are _exceptions_ and should be expected not to be granted. 16:25:12 <spot> sadly, the technology to beat people with a newspaper over the internet does not yet exist. ;) 16:26:16 <abadger1999> racor: Thoughts on making that more emphasized? 16:26:27 * abadger1999 is for emphasizing if possible. 16:26:29 <spot> I think in this case, it is important to get these changes enacted, and we can revisit the wording if it proves to be too poorly threatening. 16:26:46 <rdieter> agreed 16:26:57 <limburgher> we can always fall back on the Fedora Orbital Laser. 16:27:24 * abadger1999 has added the comment in spec file section to the "Requirements if you bundle" section 16:27:59 <tibbs|h> Thanks. 16:28:17 <spot> okay, so i propose we vote on the draft. 16:28:29 <limburgher> +1 16:28:34 <abadger1999> +1 16:28:36 <tibbs|h> I'm fine with this as is. I agree that maybe a bit more disincentive to request exceptions would be good, but maybe the difficulty of the process is enough. 16:28:37 <spot> +1 16:28:39 <tibbs|h> +1 16:28:40 <rdieter> +1 16:28:44 <racor> +1 16:29:09 <spot> #action Bundled library guidelines draft is approved (6 +1, no 0, no -1) 16:29:16 <spot> #topic Open Floor 16:29:19 <tibbs|h> I guess if FESCo is continually hammered with bundling requests then they can ask us to toughen the language up a bit. 16:29:23 <spot> that's all the trac items. 16:29:48 <tibbs|h> Is there anything that we'd discussed previously but never written up? 16:30:13 <spot> tibbs|h: no, but i do remember one item that has come up in the past that is probably worth discussing. 16:30:15 <tibbs|h> What ever happened to the static library PIC stuff? 16:30:33 <spot> tibbs|h: dunno, i'll look into it and open a trac ticket if needed. 16:30:35 <abadger1999> There are some items on the old page as well (Java update, perl update) 16:30:46 <tibbs|h> Java sort of turned into a mess. 16:30:48 <abadger1999> Ajax was working on the static library picness. 16:31:06 <tibbs|h> I was trying to get folks to give input, but then someone else came along and said that they had rewritten the whole guideline. 16:31:14 <spot> #topic Should FESCo need to ratify FPC approvals? 16:31:19 <tibbs|h> In the end I don't think any updated Java stuff was ever submitted. 16:31:30 <spot> I know this has come up before, I would like to discuss it and come to a conclusion. 16:31:45 <tibbs|h> I'm fine with only passing stuff to FESCo that's either controversial or would require extra work from folks. 16:32:05 <tibbs|h> We already have the "just fix broken stuff" concept. 16:32:34 * spot is not so arrogant as to assume that I can see all the reprocussions of our decisions. I'm of the opinion that as long as we give FESCo plenty of time to review approved drafts, it is a minimal time cost for them to review our approvals. 16:32:49 <spot> They have caught issues in our approved drafts before, albeit, rarely. 16:32:53 <abadger1999> The time cost is also for packagers though. 16:33:10 <tibbs|h> Especially with FESCo now meeting on Tuesday. 16:33:20 <tibbs|h> Friday was only two days; now it's a week. 16:33:26 <abadger1999> who have to wait first on our lengthy process, then fesco approval, and then for us to get back around to remembering to push the changes live. 16:34:05 <abadger1999> whereas if we just pushed the changes live right after our vote it would be less likely to get held up due to other things coming up. 16:34:10 <limburgher> can they do it asynchronously, via our trac? could be faster than requiring a meeting. Say, 3 FESCO members approve and it goes? 16:34:11 <rdieter> torn I guess, I still would personally just get stuff in sooner rather than later, and give FESCo veto power, rather than wait for explicit ACK'ing 16:34:36 <abadger1999> yeah -- fesco already has veto power over anything (not just new stuff). 16:35:05 <spot> rdieter: my concern with that approach is that A) FESCo won't practically look at anything it doesn't have to B) If it did veto at some point, lets say, 1 month after writeup, we'd have much more packager pain than a week delay. 16:36:01 <tibbs|h> Bottom line is that I'm all for cutting out more bureaucracy. Most of our stuff is going to be rubber stamped. I think we should be reasonably good at judging when something is controversial. 16:36:09 <rdieter> that's quite a rare case, I'd hope 16:36:11 <abadger1999> OTOH, they don't all look at the guidelines now... 16:36:31 * spot is willing to try dropping FESCo out of the approval loop 16:36:33 <tibbs|h> I recall that the only times FESCo hasn't rubber stamped something, we were pretty sure that it would be contentious. 16:36:44 <spot> Okay, so let me propose this: 16:37:38 <spot> The FPC will no longer require FESCo ratification of approved drafts/changes, however, any FPC member who feels an approved draft/change would benefit from explicit FESCo review and ratification may request it. 16:38:08 <spot> Does that seem sensible? 16:38:26 <tibbs|h> Sure. 16:39:02 <spot> Okay, lets put it to a vote. 16:39:03 <tibbs|h> I've thought about a public comment period for guidelines so anyone (FESCo or not) could give input, but I fear what that would do to an already long process. 16:39:32 <tibbs|h> And in any case I don't recall; is FESCo asking us whether we can cut them out of the loop? 16:39:41 <spot> tibbs|h: i'm pretty sure they did ask that. 16:40:01 <tibbs|h> I know it's come up as a discussion topic but I don't remember if they formally asked us to decide what we wanted to do. 16:40:11 <abadger1999> +1 16:40:12 <spot> to be fair, when this committee was formed, i decided that FESCo needed to ratify my decisions (when I was the FPC) 16:40:15 <tibbs|h> Not that they have to send a notarized letter or anything. 16:40:19 <spot> it evolved from that 16:40:23 <limburgher> +1 16:40:27 <abadger1999> <nod> 16:40:43 <spot> +1 from me 16:40:51 <tibbs|h> +1 let's at least try it. 16:40:58 <limburgher> I like that it just takes one of us to flag FESCO, but if we're unanimous(which is frequently a good sign) we just go and do. 16:41:40 <spot> rdieter, racor ? 16:41:56 <rdieter> +1 16:42:34 <spot> well, thats +5, so it passes. 16:42:55 <spot> #action The FPC will no longer require FESCo ratification of approved drafts/changes, however, any FPC member who feels an approved draft/change would benefit from explicit FESCo review and ratification may request it. (5 +1, no 0, no -1). 16:43:33 <spot> With that now in place, if anyone feels the bundled library draft needs FESCo ratification, please respond 1. If not, respond 0. 16:43:44 <spot> (we won't do this all the time, i just want it to be crystal clear here.) 16:43:50 <spot> 0 16:43:58 <racor> spot: +1 (sorry, was distracted on the phone) 16:44:05 <spot> racor: thanks. :) 16:44:07 <tibbs|h> +1 16:44:25 <tibbs|h> Well, they requested it from us, didn't they? 16:44:33 <spot> #action Tibbs has requested FESCo ratification on the Bundled Library Draft approval. 16:44:41 <tibbs|h> I mean, shouldn't it logically go back to them? 16:44:44 <spot> tibbs|h: sure. :) 16:45:04 <limburgher> 1 16:45:24 <spot> #topic Open Floor 16:46:41 <tibbs|h> Re static library PIC stuff. 16:46:50 <spot> abadger1999: i believe you were going to update the wiki about using trac instead of the old process? 16:47:09 <tibbs|h> Discussion several months ago led me to take the draft ajax provided and turn it into https://fedoraproject.org/wiki/User:Tibbs/Static_Library_PICness_Guidelines 16:47:18 <abadger1999> spot: ah yeah -- will do that right after the meeting. 16:47:56 <tibbs|h> But I'm somewhat hampered by the fact that nobody seems to know a way to determine whether something is compiled PIC other than looking at the compiler flags when it was built. 16:47:57 <spot> abadger1999: you can probably drop the FESCo step (or make it explicitly optional) at the same time 16:48:07 <abadger1999> Will do 16:50:25 <spot> tibbs|h: yeah. 16:50:29 <abadger1999> Yeah, that's not good -- checking PICness should be an rpmlint type check. 16:50:32 * spot thinks that there must be some way 16:50:47 <tibbs|h> Disassemble the code, maybe. 16:51:33 <limburgher> eew. 16:52:16 <limburgher> could something be compiled against it, and then check that way at runtime? 16:52:37 <limburgher> warning: possibly speaking from posterior. 16:53:22 <tibbs|h> This draft also brings up the question of what to do with long justification sections. 16:53:47 * spot has no problem with justification sections going on their own page. 16:53:56 <tibbs|h> Basically, the guideline is one sentence. The rest is "how does a reviewer check it" and "why". 16:53:59 <spot> heck, with mediawiki, the whole thing could go on one page 16:54:11 <spot> then one section could be embedded into the guidelines 16:54:16 <tibbs|h> Yes. 16:54:31 <tibbs|h> But... I always experience pain when dealing with the wiki. 16:54:55 <tibbs|h> If someone wants to work out a template for that kind of thing, we may want to try it out. 16:55:12 <tibbs|h> Anything that shortens the main document is good. 16:55:20 <spot> so, aside from the "how do we check for PIC" issue, i have to ask if there are any cases where a static library would need to be explicitly non-PIC 16:55:44 <tibbs|h> I think the only reason anyone's mentioned is performance. 16:56:23 * rdieter doesn't buy that much, esp without benchmarks to back it up 16:56:35 <tibbs|h> Indeed. 16:56:46 <tibbs|h> It's an "-O99" kind of thing in most cases. 16:56:55 <rdieter> <nod> 16:56:59 <tibbs|h> On register-starved machines, though, you should be able to measure a few percent. 16:57:30 <rdieter> sure, irony is that it's the register-starved machines that need -fPIC the most, no? 16:57:39 <spot> so, I think we do need some way of identifying whether a static library is PIC or not, rpmlint would seem to be the obvious place to check, but barring that, a manual check for the docs will help people. 16:57:59 <tibbs|h> It is quite possible that there's no reasonable way to tell. 16:58:03 <spot> i'm not sure if it is worth delaying this guideline change for it or not. 16:58:15 <tibbs|h> I'm not even sure who would know; maybe the compiler folks. 16:58:18 <spot> tibbs|h: i can ask some folks and find out. 16:58:55 <limburgher> if you can't test for it, how do you gauge compliance, and if you can't do that, what good is the guideline? 16:59:12 <spot> this issue is now https://fedorahosted.org/fpc/ticket/9 16:59:27 <tibbs|h> Too slow clicking submit. 17:00:04 <spot> we'll revisit this next week. 17:00:13 <spot> any other issues? (we are at the hour mark) 17:01:16 <tibbs|h> None from me. 17:01:37 <spot> okay then, thanks everyone! 17:01:41 <spot> #endmeeting