fedora-meeting
LOGS
16:01:27 <spot> #startmeeting Fedora Packaging Committee
16:01:27 <zodbot> Meeting started Wed Sep  8 16:01:27 2010 UTC.  The chair is spot. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:47 <spot> #topic Roll Call
16:01:56 <limburgher> cambot
16:02:00 <tibbs|h> Howdy.
16:02:01 <racor> here
16:02:04 <limburgher> er, i mean
16:02:06 * limburgher here
16:02:24 * abadger1999 here
16:02:38 <limburgher> Disclaimer: nightmarishly busy, replies may lag a bit.
16:02:48 <spot> SmootherFrOgZ, rdieter: ping
16:03:35 <tibbs|h> Disclaimer: less than ten hours of sleep in the last four days.  Replies may include bizarre hallucinations.
16:03:45 <spot> awesome.
16:03:57 <spot> okay, so we do have quorum.
16:04:14 <spot> #action 5 of 8 present, we have quorum.
16:04:26 <rdieter> here
16:04:34 <spot> #topic D Guidelines - https://fedorahosted.org/fpc/ticket/7
16:04:52 <spot> I have not heard back from Jonathan Mercier about how %{d_optflags} are used.
16:05:28 <tibbs|h> If we have that question, anyone else who submits packages will have the same question.
16:05:29 <rdieter> not sure it's worth blocking on that. ?  doesn't seem critical.
16:05:57 <rdieter> (though it should be clarified and guidelines updated accordingly when that info is available)
16:06:26 <tibbs|h> Well, as currently written the guidelines are contradictory.
16:06:40 <rdieter> oh. doh
16:06:41 <tibbs|h> "must use _d_optflags"
16:06:51 <tibbs|h> but then no mention of _d_optflags anywhere else, including the template.
16:06:58 <spot> tibbs|h: yeah, i think we need to get that cleared up before we can move forward.
16:07:10 * spot will send another email and we'll revisit next week (hopefully)
16:07:21 <tibbs|h> Maybe it's built in like R or pyhon or whatever, where the compiler knows what to use.
16:07:37 <tibbs|h> But honestly I've no  idea how to even find that out.
16:07:45 * spot nods
16:07:52 <spot> okay, lets move on
16:07:55 <racor> When I checked last week, _d_libdir was still in /etc/rpm/macros.*
16:08:15 <limburgher> Agreed.  If belatedly so.
16:08:17 <spot> racor: ah, good point. I'll ask him about removing that as well.
16:08:47 <spot> #topic Static Library PIC - https://fedorahosted.org/fpc/ticket/9
16:09:40 <spot> tibbs|h: i'm guessing you haven't had a chance to update it with the info i found out about PIC and textrels
16:10:22 <tibbs|h> I have not; I'm not really sure how to answer the other questions posed in the ticket.
16:11:04 <spot> tibbs|h: perhaps mentioning the cases that Rathann mentions explicitly as valid justifications for an exception request.
16:11:24 <tibbs|h> Part of the problem is that I don't buy it.
16:11:58 <spot> well, we can choose to ignore it. :) Ultimately, FESCo will make the call on any exceptions
16:12:01 <tibbs|h> I mean, we could say that folks should be prepared to provide benchmarks illustrating the performance difference.
16:12:09 <racor> tibbs: Neither do I. I am more concerned about some hard-coded non-PIC asm lurking around somewhere.
16:12:32 <spot> racor: *nod*
16:12:48 <tibbs|h> And the eu-findtextrel stuff won't help with that, either.
16:12:56 <spot> tibbs|h: actually, it will.
16:13:06 <spot> tibbs|h: it will show those as textrels
16:13:31 <tibbs|h> Hmm.
16:13:46 <tibbs|h> I guess it's a theoretical discussion anyway without an actual example of something bad.
16:13:50 <spot> which is why you can build such code with -fPIC and still end up with textrels
16:14:18 <tibbs|h> So the prohibition is against textrels, and building PIC is a consequence.
16:14:24 <spot> tibbs|h: yes.
16:14:32 <tibbs|h> Then I'll rephrase the whole thing.
16:14:41 <spot> tibbs|h: that would be my suggestion
16:14:52 <tibbs|h> I guess rpmlint can find textrels pretty easily if someone writes the code.
16:14:58 <spot> so, lets table this one until next week (or when tibbs|h has time).
16:15:13 <spot> tibbs|h: rpmlint would dep on gcc, not sure i want that.
16:15:23 <spot> or, rather, ld.
16:15:47 <tibbs|h> Is that actually a problem?  Who's building static libraries but won't have ld installed?
16:16:04 <spot> yeah, but then everyone using rpmlint will need binutils
16:16:17 <limburgher> Is that a problem?
16:16:21 <spot> i suppose not.
16:16:24 <tibbs|h> It already requires binutils.
16:16:32 <spot> okay, then its a non-issue. :)
16:17:16 <spot> i'm writing it on my "todo" list. anyone else who has more time than me, feel free to do it.
16:17:32 <spot> Moving onward...
16:17:49 <spot> #topic Naming Guideline for Mozilla Firefox addons
16:17:53 <spot> https://fedorahosted.org/fpc/ticket/10
16:18:10 <spot> the proposal is pretty simple, "Addons for Mozilla-Firefox must be named according to this format: mozilla-$NAME."
16:18:33 <spot> however, there seems to be some disagreement in the comments to that ticket
16:18:42 <tibbs|h> Well, someone proposed something more complicated.
16:19:09 <rdieter> because there's both plugins and addons ?
16:19:12 <tibbs|h> If we expect that plugin names will conflict with extension names then I guess that makes sense.
16:19:23 <tibbs|h> But otherwise I don't see the point.
16:19:26 <spot> do we really think it is likely that there will be a plugin/extension namespace conflict?
16:19:37 * spot doubts that significantly
16:19:39 <limburgher> I doubt it.
16:19:51 <tibbs|h> There aren't really that many plugins, are there?
16:19:53 <mcepl> are there that many plugins? (flash, java, ...?)
16:20:13 <mcepl> silverlight ... yes :(
16:20:14 <rdieter> nod, just deal with conflicts (if there are any) when/if that happens
16:20:16 <limburgher> Hypothetical:  If someone made Plugin FooBlaster and Add-On FooBlaster, could Firefox install and use both?
16:20:30 <spot> i'm inclined to approve the simple naming proposal and revisit it if there is a real conflict.
16:20:35 <tibbs|h> +1
16:20:36 <rdieter> spot: +1
16:20:53 <spot> Okay, lets do a formal vote then:
16:20:54 <spot> +1
16:20:56 <racor> +1
16:20:57 <rdieter> +1
16:21:02 <tibbs|h> +1
16:21:37 <limburgher> +1
16:21:42 <spot> abadger1999?
16:22:37 <abadger1999> Does anyone understand tomspur's objection?
16:23:12 <tibbs|h> I thought he was agreeing, not objecting.
16:23:24 <spot> tibbs|h: that was my understanding as well
16:23:27 <limburgher> Was there an older edit that said firefox-$name?
16:23:40 <abadger1999> I guess... that could also be an answer :-)
16:23:59 <tibbs|h> Maybe he's suggesting that "Mozilla Firefox" in the current draft be changed to something less specific.
16:24:31 <abadger1999> <nod>
16:24:35 <spot> I think dropping "Firefox" makes sense there, and replacing it with "Applications"
16:24:36 <abadger1999> Okay, that makes sense.
16:24:40 <tibbs|h> But that then gets into what "mozilla product" means, and whether thunderbird qualifies, and such.
16:25:00 <mcepl> well, I thought it was obvious that this includes TB addons as well. Doesn't it?
16:25:10 <mcepl> (not mentioning Seamonkey)
16:25:22 <abadger1999> I think a few extensions either work with TB as well or have the same name for TB.
16:25:27 <limburgher> It should.
16:25:40 <spot> i think its fine for it to be catchall. we can deal with any exceptions as necessary.
16:25:45 <tibbs|h> Sure.
16:25:55 <abadger1999> +1
16:25:56 * limburgher muses about using Lightning with Sunbird
16:26:15 <spot> #action Mozilla Naming Draft is approved (6 +1, no 0, no -1)
16:26:49 <spot> #topic Guidelines about how not to use $RPM_SOURCE_DIR / %{_sourcedir} - https://fedorahosted.org/fpc/ticket/12
16:27:23 <spot> Please note that I did not explicitly forbid use of $RPM_SOURCE_DIR or %{_sourcedir} in this draft.
16:27:32 <spot> What I wrote was: "Packages which use files itemized as Source# files, must refer to those files by their Source# macro name, and must not use $RPM_SOURCE_DIR or %{sourcedir} to refer to those files. "
16:28:53 <tibbs|h> Having used sourcedir in a spec before, I found it useful but I can see why we might want to ban it.
16:29:28 <limburgher> I'd never heard of it.
16:29:53 <spot> limburgher: it isn't terribly common, but it came up on a review recently
16:30:22 <limburgher> spot: <spock>Fascinating.</spock>
16:30:56 <spot> and since there are some packagers who cannot rely on common sense, instead preferring to follow the strict letter of the guidelines, i drafted this.
16:31:25 <tibbs|h> Thinking about it more, I'm happy to go with this and then if someone comes up with an actual valid objection then we can revise.
16:31:43 <spot> tibbs|h: works for me.
16:31:51 <limburgher> <nods>
16:31:59 <tibbs|h> One thing you lose is the ability to glob sources.  Theoretically you can use lua for that, but I've never been able to make it work.
16:32:32 <spot> tibbs|h: there is some danger in globbing sources, in that it will pick up and use local files, which do not then end up in the SRPM
16:32:45 <tibbs|h> Yes, but we build everything in mock.
16:33:11 <spot> tibbs|h: yes, but it causes the "my package builds locally, but not in Fedora?!?!?" problem
16:33:17 <tibbs|h> I mean, you can leave out buildrequires and still have local builds work.
16:33:32 <tibbs|h> Same problem, same answer: the package is still broken.
16:33:53 <spot> yep. and the guidelines exist to help people make good packages from the start that work both locally and in mock/koji
16:33:55 <tibbs|h> And the issue under discussion is far rarer than the issue of missing buildrequires.
16:34:34 <spot> I think the door is left open here for someone to come back with a valid exception case.
16:34:44 <spot> I'm more than willing to revisit this should it become necessary.
16:34:54 <limburgher> I expect that an SRPM I grab, once I install the BRs, will build.  Period.  Thus globbing seems dangerous, without a way to search the lookaside cache, Source tags, etc, at review time.
16:35:53 <spot> Okay, assuming there are no other concerns, lets vote on this one:
16:36:00 <spot> +1
16:36:01 <tibbs|h> +1
16:36:01 <rdieter> +1
16:36:06 <abadger1999> +1
16:36:27 <limburgher> +1
16:36:33 <racor> +1
16:36:59 <spot> #action How not to use $RPM_SOURCE_DIR / %{_sourcedir} draft approved (6 +1, no 0, no -1)
16:37:09 <spot> #topic Open Seat
16:37:21 <spot> We received a LOT of interested people for our open seat
16:37:32 <tibbs|h> That's encouraging.
16:37:40 <spot> which is both nice and frightening (are there that many crazy people?)
16:38:06 <spot> As before, I'm going to send a summary report to the FPC members, and take opinions before moving forward with a choice.
16:38:07 <abadger1999> They just don't know what they're in for :-)
16:38:13 <spot> watch your inbox for that
16:38:17 <abadger1999> Sounds good.
16:38:27 <dgilmore> there is a seat open on the FPC?
16:38:31 <spot> dgilmore: yes.
16:38:35 * dgilmore might be interested
16:38:41 <spot> if anyone is interested, emailing me would be good. :)
16:38:42 <skvidal> dgilmore: I think you were in toronto when it was announced
16:38:56 <dgilmore> skvidal: ahh ok i missed it
16:39:00 <spot> #topic Open Floor
16:39:11 <spot> okay, the floor is open for any additional topics as we have now cleared our agenda
16:39:13 <abadger1999> systemd
16:39:26 <spot> abadger1999: is there a ticket or a draft for systemd?
16:39:35 <abadger1999> Nope but it's up for being the default in F14.
16:39:52 <spot> abadger1999: perhaps lennart would be willing to draft something for us?
16:40:18 <abadger1999> spot: Well -- If you could ask him, that would be good -- last time I asked, only notting replied.
16:40:28 * spot wrote the last set of guidelines for initscripts, and i am not eager to do it again...
16:40:37 <spot> abadger1999: okay, i will ask him.
16:41:11 <abadger1999> A couple things about guidelines for that:
16:41:30 <abadger1999> 1) Do we stil want to enforce -- installing a package must not enable the service?
16:41:57 <dgilmore> abadger1999: yes
16:42:17 <abadger1999> 2) How much do we want to go into writing systemd unit files (equivalent of init scripts)?  Seeing as most packages won't have unit files and that's always been quasi realm of the packager... seems like we should have some of that.
16:42:43 <abadger1999> Re: #1, there are, for instance, bugs like this: https://bugzilla.redhat.com/show_bug.cgi?id=631271
16:42:51 * SmootherFrOgZ is here
16:43:22 <abadger1999> Which I think bear on this but I haven't gotten to the place where I can test what has happened already to cause that to occur.
16:44:18 <dgilmore> abadger1999: systemd needs to honour chkconfig
16:44:31 <dgilmore> and not start services automatically if they are disabled
16:45:13 <spot> this is a little different, it looks like the service was not started automatically on boot, but rather, when another enabled service started, it activated the other service because it was not disabled by default.
16:45:24 <spot> (within the virt config)
16:45:39 <spot> definitely worth thinking through.
16:46:29 <spot> okay, any other items?
16:46:59 <abadger1999> Yeah.  Note that whether systemd is to be default for F14 is a ticket for next week's FESCo.
16:47:28 * spot nods
16:47:33 <abadger1999> I don't know if that puts time pressure on us to figure this out before then or if it means there's no time pressure until after then :-)
16:47:34 <nirik> abadger1999: not next weeks... it needs to be decided in the next day or so.
16:47:41 <abadger1999> O really?
16:47:46 <abadger1999> :-(
16:48:01 <tibbs|h> What a mess.
16:48:01 <spot> i don't think that decision should block on the FPC
16:48:03 <nirik> well rel-eng is supposed to start doing TC's for beta tomorrow.
16:48:12 <nirik> it would be good to decide before then.
16:50:08 * abadger1999 agrees with spot about not blocking on FPC... but we need guidelines so packagers can port their scripts for the Fedora version that has this....
16:50:32 <abadger1999> nirik: Maybe FESCo can take on the Guideline draft work?
16:50:51 <nirik> in what sense?
16:50:53 <abadger1999> nirik: If they decide to approve systemd as the default for F14?
16:51:55 <nirik> well, my understanding was that for f14 at least, our advise for people about systemd unit files was the same as we were doing for upstart: ie, don't do it. Ship your sysvinit file for now.
16:52:40 <abadger1999> nirik: Well.... we do have guidelines currently that require sysVinit scripts.
16:52:57 <abadger1999> So if some of the core systems are only shipping unit files, that, at least, changes.
16:53:41 <nirik> yeah, I suppose so... I would say they should ship both for now.
16:54:01 <abadger1999> nirik: And then, if we're shipping some services that work with unit files only, we need to make sure that they and the Guidelines are in harmony
16:54:33 <nim-nim> nirik: the problem with systemd guidelines is not f14, it's having them soon enough in the (already open) f15 cycles so people do not discover unit packaging at f15 alpha time
16:54:50 * nirik never said not to have guidelines.
16:54:50 <abadger1999> about things like not starting if they haven't been specifically enabled (with some exception for "core services" with some definition of core services).
16:55:02 <nirik> I think we should. It would be great. Make it so. ;)
16:55:35 * spot notes that the guidelines currently require sysvinit scripts for services that start at boot
16:55:44 <spot> it doesn't forbid unit scripts to also be shipped
16:55:49 <abadger1999> Correct.
16:55:59 <abadger1999> spot: Although... we have an interesting corner case here
16:56:41 <abadger1999> spot: if there's both a unit file and a systemvinit script, do the guidlines imply that the default init system must run the systemvinit script?
16:57:03 <spot> abadger1999: eh, i wouldn't go that far.
16:57:18 <abadger1999> Then what's the point of shipping the systemvinit script?
16:57:51 <nirik> abadger1999: if you want to go back to upstart?
16:57:52 <abadger1999> I think we should make it clear that that's not the expectation... at which point I wonder why we require a systemvinit script.
16:57:55 <spot> the problem is that we're trying to interpret guidelines that were written for a different purpose.
16:58:13 <spot> systemd is unique enough that i think everyone agrees that the guidelines need to be updated to reflect them
16:58:23 <abadger1999> nirik: But didn't we say that we weren't making that configurable?  Or am I misinterpreting some of the discussion?
16:58:32 <abadger1999> +1
16:59:00 * abadger1999 even wrote that as a requirement on the feature page -- but it must have been ignored if the feature page now says 100%
16:59:20 <spot> so, I think the FPC should wait until either A) the decision is made as to whether systemd will be the default in F14 (if so, we will need to make minor changes to reflect that)
16:59:32 <spot> or B) a draft is submitted for consideration
16:59:53 <nirik> abadger1999: which ? going back to upstart?
17:00:09 <abadger1999> nirik: requirement for having packaging guidelines.
17:00:52 <nirik> ah. dunno. I think we should have at the very least some guidelines changes for f14 to tell maintainers what to do... no guidance would be bad.
17:00:54 * SmootherFrOgZ is ok for B
17:01:50 <abadger1999> nirik: last item under dependencies: https://fedoraproject.org/wiki/Features/systemd#Dependencies
17:04:12 <abadger1999> nirik, spot: Anyhow.... let's go with this... FESCo decides whether systemd will be default for F14.  If it is, then one of the FESCo members knowledgable about systemd works with us to write a draft.
17:04:18 <nirik> abadger1999: yeah, something should be in place, I agree.
17:04:50 <spot> abadger1999: seems reasonable
17:05:02 <spot> at this point, we're at ~65 minutes
17:05:13 <spot> if there are no objections in the next minute, i'm going to end the meeting.
17:05:39 <SmootherFrOgZ> nope, we can go ahead on the trac
17:06:39 <spot> #endmeeting