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