From Fedora Project Wiki

2007 March 15 FESCo Meeting



  • Brian Pepple (bpepple)
  • Jason Tibbitts (tibbs)
  • Christian Iseli (ch4chris)
  • Rex Dieter (rdieter)
  • Toshio Kuratomi (abadger1999)
  • Kevin Fenzi (nirik)
  • Dennis Gilmore (dgilmore)
  • Jesse Keating (f13)
  • Warren Togami (warren)
  • Tom Callaway (spot)
  • Josh Boyer (jwb)
  • Bill Nottingham (notting)


  • Jeremy Katz (jeremy)


Core Review Process

  • The Merge Review is only a cleanup sweep, and the cleanup changes need to end at Test4. The merge will happens whether or not they are approved in a Merge Review. The cleanup will continue after F7.

Packaging Committee Report


--- bpepple has changed the topic to: /topic FESCo meeting -- Meeting rules at -- Init process
<jwb> i'm here
<tibbs> I'm here as well.
<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
<f13> I'm here.
<jwb> i'm here
<rdieter> here
<abadger1999> howdy
* cweyl takes a rabble seat
nirik is here.
<bpepple> hi everybody.
Let's start slowly and see if the other show up.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation
<bpepple> nirik: have you had a chance to add anything on the wiki for this?
<nirik> I haven't... :( There was a post on someone who setup a tasktracker type thing with all the info on it... is that what we were looking for?
<tibbs> I guess we need to talk about the PPC64 builds as well.
<jwb> nirik, personally, i don't think so
* dgilmore is here
<jwb> nirik, that is going to get out of date too quickly to really be of use unless someone is policing it full time
<bpepple> nirik: I'm not really sure, I haven't had time to look a it.
<dgilmore> bpepple: so im going to add ppc64 to the extras buildsys
<nirik> yeah, I got sick and swamped at work and haven't had much time to look at it... what were we looking for here? Milestones for a regular development release?
* mmcgrath notes poelcat may be willing to do that.  He's expressed interest in project management.
* c4chris will be here in a few minutes...
<bpepple> nirik: something like that.
<jwb> mmcgrath, project management means you have control over things.  he doesn't.  he'd more likely just be doing project tracking
<f13> dgilmore: do you think it is possible to rebuild what has already been built to pick up the ppc64 package, or will there have to be a mass rebuild?
<nirik> poelcat did say "I am willing to be that person."
<mmcgrath> s/management/coordination/
<dgilmore> f13: its possible to build same versions for everything that does build
f13: there is some cicular deps in there
<jwb> i'd like to avoid a mass rebuild if we can
<dgilmore> circular
<nirik> yeah, I guess the important part is for people to all know when things have to be done... like all broken deps must be fixed, etc.
<f13> yeah, I don't like the idea of having one arches packages built with potentially different things in the buildroot than the rest of the package though.
<bpepple> nirik: right, I think that's what we're looking for.
<f13> jwb: we may have to :/
<dgilmore> so hopefully its just a minor rebuild
<jwb> f13, dgilmore: can we just have a small committee to it?
rather than have all the developers
<f13> dgilmore: no mass rebuilds are 'minor' :/
<nirik> bpepple: yeah, I can look more this weekend now that I am feeling better...
<bpepple> nirik: I should have some time this weekend to help also.
<nirik> cool.
<f13> jwb: should be able to, would probably need to enforce some sort of outage so that random maintainer doesn't step on the rebuilder's toes.
<poelcat> jwb: a good project manager does not "control things"
<notting> are we going to do bump + rebuild?
or just rebuild on the side?
<dgilmore> f13: its minor in that somethings (hopefully most) wont need any attention at all
<f13> notting: unless you have a better idea (:
<tibbs> I'm willing to work on getting things to build if we can work around the ACLs .
<jwb> poelcat, you would be the first i've experienced to not do that :)
<notting> do we have a dep-sorted list?
<jwb> poelcat, and my statement wasn't meant to be insulting.  sorry if you took it as so
<tibbs> I suspect anything that excludes ppc or x86_64 will need to exclude ppc64 as well.
<notting> tibbs: probably just ppc
<f13> dgilmore: mattd's extras rebuild list should prove as a data point ofr what will fail.
<tibbs> notting: 64 bit issues?
<dgilmore> notting: i think what ill do is create a target just for this  build what we have currently
when thats done merge it in and fix and rebuild the rest
f13: i dobut it will help much
<notting> tibbs: hard to tell whether it's 64-bit issues or !x86_64 issues
<dgilmore> notting: we dont have that list yet
<f13> dgilmore: it'll tell us what things are currently not going to rebuild cleanly
<poelcat> jwb: np; a good project manager tracks and coordinates keeps info current so people can make good decisions; maybe a better term would be program manager
<f13> dgilmore: since what is _in_ the buildroot now has changed from when a lot of the Extras packages were built.
<dgilmore> f13: sure it will be a guide
<notting> dgilmore: probably need that to avoid doing things twice
<f13> so, a mass rebuild, a new build system, and merged scm.  Oh and a freeze next week.  Heeee!
<dgilmore> anything noarch wont need building
notting: yeah
<bpepple> ok, anything else in regard to the ppc64?
<dgilmore> bpepple: not really
<jwb> so dgilmore is going to rebuild it all for now?
<f13> needs more planning
<poelcat> jwb: w/ taskjuggler keeping that schedule current would not be that hard and I might be able to get company time to do it
<jwb> poelcat, if you'd like to do that, go for it.  i have no objections.
<dgilmore> jwb: needs more planning but probably for a large part part ill look after it
<bpepple> ok, we can probably move on then.
<jwb> dgilmore, if you need help ping me and/or dwmw2.  we can look into some of the build issues
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren
<bpepple> warren: Is there anything else we need to discuss regarding the merge?
<f13> warren: are you still alive?
<warren> f13, not sure if I'm alive
<tibbs> IRC from the beyond....
<warren> bpepple, the review process is almost irrelevant now
<warren> meaning...
Merge Review is only a cleanup sweep.
The cleanup changes need to end at Test4.
Merge happens whether or not they are approved in a Merge Review.
Cleanup continues after F7.
<bpepple> warren: ok, I note that in my summary.
<warren> I'll make a big announcement on this point specifically today.
<rdieter> when is the merging then?
<f13> soon
<warren> rdieter, merge doesn't block on reviews, but rather infrastructure and policies being ready.
<f13> rdieter: once koji goes live, which might be right after Test3
well, koji going live and merging are sort of both at the same time kind of thing
<nirik> we should keep being able to do reviews now tho right? don't tell people to stop?
<f13> correct
<bpepple> warren: btw, should we keep this item on the schedule? Or do you want it removed?
<rdieter> might?  ok, I can wait for details, but I'd really like to be able to get to work on kde packages.
<f13> and technically they can continue after Test4, but no changes from the review will be built after TEst4
* c4chris is here now
<warren> bpepple, wouldn't hurt to keep it there.
<jwb> f13, do we have koji test systems up?
<bpepple> warren: ok.
<f13> rdieter: If I knew exactly when Koji would be ready, I could give you a time.
jwb: yes.
* spot is here, a little late
<warren> nirik, right, reviews keep going until a deadline.
<f13> jwb:
<jwb> f13, need testers?
<f13> jwb: not atm, we're able to find enough problems with just me and mikeb and dgilmore
<warren> f13, koji auth allows cert (not just kerberos) now?
<f13> jwb: we will soon.
warren: that isn't complete yet.
<warren> ah
<f13> warren: currently we're testing with username/pass since htat was already in koji
<jwb> f13, ok.  i think we can find a few folks to help test when needed.  ping me
<f13> jwb: will do.
rdieter: there is a question about whether or not to allow package changes for deps in Extras after koji goes live, unless we move the feature freeze once again.
rdieter: since I don't believe koji+merge can happen in the next week since the freeze is a week from today
rdieter: see the thread on maintainers-list
<rdieter> f13: sounds like a chicken-n-egg problem for kde-spin.  if we can't make mods until merged...
<f13> rdieter: I know.  It really sucks.
* rdieter nods.
<c4chris> btw, while on the review topic: Mike has now setup a review status page on fp.o:
<f13> please provide input on maintainers-list
* notting doesn't see a problem, as long as the rebuilds get done soon
<bpepple> Ok, unless there is anything else, we can probably move on....
<c4chris> nirik, did you get the canned queries done?
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes - c4chris
<nirik> I have some queries that work, but not sure how to make them 'canned'... off my wiki page are links:
<c4chris> no progress on cvs-import...
nirik, k
<bpepple> c4chris: No problem.
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs
<nirik> we have "touched" about 21% of the core merge reviews.
<tibbs> Everyone saw the summary sent to fedora-maintainers, I take it.
<bpepple> tibbs: yes.
<c4chris> tibbs, yes
<tibbs> So there are two issues up for FESCO discussion:
<jwb> tibbs, yes thanks
This defines when the various phases of an rpm build can touch the various directories like the build root.
Basically, the buildroot shouldn't be written to during prep, build or check.
<nirik> seems reasonable. Does rpmlint warn about any of those? can it be made to?
<tibbs> It warns about "buildroot-usage" in some cases.
<jwb> side question: do we ever audit existing packages for adherence to these guidelines?
<nirik> ok, seems fine to me. +1
<f13> jwb: not officially.
<tibbs> jwb: There's the whole merge review, of course.
<jwb> tibbs, i mean existing already reviewed packages.
<tibbs> Other than that, we haven't but perhaps in the future we could consider it.
<jwb> ok
<nirik> jwb: in some far distant time we might have manpower to do checks on existing packages... or flag them for review if they have problems, etc...
<bpepple> jwb: No.
<tibbs> There's just so much to review right now.
<jwb> yes, i know
<bpepple> tibbs: +1
<dgilmore> its ok with me +1
<tibbs> BTW, the rpmlint complaint is "rpm-buildroot-usage":
<c4chris> +1
<tibbs> $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it
will break short circuiting.
<jwb> +1
<bpepple> +1 here also.
<notting> speaking of which, i have a volunteer willing to write a reviewing-for-dummies to train an army to do the 'easy' part of reviews
<f13> +1
<notting> +1
<jwb> notting, that would be excellent
<tibbs> OK, if anyone has further comments on that proposal, please let fedora-maintainers kjnow before next Tuesday.
<jwb> notting, who?
<c4chris> notting, sounds cool :-)
<tibbs> The other proposal:
Disallowing %config files under /usr:
<dgilmore> +1 from me
<bpepple> +1
<nirik> wait... that was already ratified wasn't it?
<jwb> do we have an idea if anything is going to break?
<abadger1999> nirik: I think you're remembering initscripts will not be %config
<c4chris> +1
<spot> tibbs: that was already ratified i think
<jwb> i ask because this seems like a guideline that wouldn't have been made without somebody already using %config in /usr...
<tibbs> Crap, I'm pasting from the wrong section.
<spot> the other item should have been:
Is the real proposal.  My fault.
* jwb obviously missed last week's meeting
<c4chris> argh buildroot again ?
<tibbs> Yes, and there's more to come.
<spot> c4chris: just that you need to nuke it at the beginning of %install
(for now)
<nirik> BuildRootHandling +1 from me.
<jwb> +1
<c4chris> spot, oh, I thought that was already the case
<tibbs> This has been the de-facto thing to do for a long time now.
<bpepple> +1  here also.
<f13> +1
<c4chris> +1
<tibbs> But it's not in the guidelines, just in rpmlint.
<jwb> *crickets*
<bpepple> tibbs: anything else?
<tibbs> Nope, that's it.
Again, please send any comments to fedora-maintainers.
<bpepple> tibbs: great, thanks.
moving on....
--- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm
<bpepple> I left this on the schedule, though I think this probably needs to be discussed on the mailing lists.
<nirik> I don't think there has been any good flashes of brillance on that so far...
<warren> Has notting or jeremy chimed in an opinion on that?
* c4chris doesn' like it too much.  I like my mess to stay where I left it...
<f13> warren: jeremy is on vacation.
<notting> warren: bad idea. have a repo-upgrade plugin that warns you of dead things
<c4chris> notting, yea, I'd like that much better
<warren> repo-upgrade plugin could know about specific E-N-V-R instead of having huge lists that slow down transactions and never die?
<nirik> it would be nice to have some way to inform end users: "hey, this thing is orphaned, and not supported, use at your own risk"... but I have no idea how to do that cleanly.
<warren> Is the goal of garbage-collector for updates within a regular distro
or upgrades between distros?
<f13> between IIRC
the fear is that an orphaned package will lead to broken deps
<warren> a repo-upgrade plugin could also handle "backwards" N-V-R cases in rawhide.
repo-upgrade plugin would be disabled by default, except rawhide and one-time "between" upgrade users could use it at their own risk?
That way long lists of Obsoletes don't pollute regular fedora users, slowing things down
<c4chris> warren, sounds fine
<nirik> possibly... will be interesting to see how fc6->fc7 yum upgrades work. fc5->fc6 was very painless...
<warren> "a repo-upgrade plugin could also handle "backwards" N-V-R cases in rawhide."  makes an entire class of testers more happy, while giving us more flexibility in rawhide.
<nirik> how would it know that a N-V-R went backwards?
<warren> nirik, repo-upgrade plugin could have a list of specific N-V-R's that were bad and should lose to whatever is newest in the repo.
Not exactly sure, might be a bad idea.
<nirik> seems like that could be both a maint nightmare to keep up to date, and something that would make people think it's ok to do that kind of thing all the time in rawhide. ;(
<f13> bottom line here I think a garbage collection package is a bad idea.
<abadger1999> nirik: davej posted that fc6->f7 would cause issues.
<f13> Vote to remove this from schedule as a bad idea?
<abadger1999> Have to be careful with the new kernel+mkinitrd.
<f13> abadger1999: that was more for kernel changes than package oopses.
<jwb> abadger1999, he posted that yes.  it didn't though
<abadger1999> f13: +1
<nirik> abadger1999: when? with the s/hda/sda/ ?
<tibbs> f13: +1
<bpepple> f13: +1
<notting> f13: +1
<jwb> abadger1999, it's highly dependent on the hw too
<f13> +1 to myself.
<nirik> f13: +1
<c4chris> +1
<jwb> +1
<abadger1999> jwb: Ah.  k.
<warren> garbage collection isn't for normal users.
<bpepple> Ok, I'll remove it from the schedule.
<notting> warren: fedora sanitation engineers?
<warren> I think the idea has mostly bad implementations possible, but it has merit, just don't know exactly how.
+1 to remove it from the schedule for now
<bpepple> ok, let's move on...
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<bpepple> Anything people want to discuss?
<f13> doom
<c4chris> will the meeting stay at 5 UTC?
(just curious)
<notting> c4chris: you mean '1PM US eastern, whatever that converts to?'
<nirik> should we start expecting some more review response from redhat folks now that RHEL5 is out the door?
<notting> i hope so
<c4chris> notting, yea, I think I mean that (and I hate DST)...
<bpepple> c4chris: I'm for leaving our meeting at the regular time, once we sync back up with europe.
<c4chris> bpepple, and that's 1PM US eastern I take it ?
<bpepple> c4chris: correct.
<c4chris> k
<f13> the time we just met in, leave it at that for how long?
<jwb> until most people can't make it and we have to switch?
<bpepple> The 1PM eastern seem to work for most people doesn't it?
<c4chris> or someone yells loud enough :-)
<bpepple> c4chris: agreed.
<abadger1999> Works for me.
<f13> lets get this straight.
<nirik> warren: were you going to get someone to mass change the blocker bugs over to flags? or did we decide to not do that?
<f13> We just had a meeting, and the time which started this meeting will not change for the forseeable future?
<c4chris> f13, yes
<bpepple> f13: correct.
<jwb> right
<f13> except when US does DST, and then we adjust accordingly?
<nirik> 17:00 UTC.
<jwb> f13, it's always at 13:00 EST
<c4chris> f13, yes, we shhot for 1PM US Eastern
<f13> jwb: er..  EST vs EDT?
aren't timezones fun?  (:
<abadger1999> E.T
<jwb> 13:00 in the state f13 presently resides in
<c4chris> argh
<f13> heh
<jwb> abadger1999, right
* c4chris needs to kick something
<jwb> c4chris, me too
<f13> 1700UTC for now, 1800UTC during US Daylight Savings.
<jwb> right
<nirik> but we are in US daylight savings time now. ;)
<bpepple> ok, everyone on the same page?
<jwb> btw, if it moves to any other time, i'd likely be screwed.  i have trouble making it at this time some weeks
<bpepple> Anything else people want to discuss?
<abadger1999> FYI -- I finished the initial front end to the package db last night
<bpepple> otherwise we can start to wrap things up.
abadger1999: cool.
<c4chris> wrap++
abadger1999, cool
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
<f13> well
there are some need to do items for koji still
<bpepple> -- MARK -- Meeting End
<f13> see
basically some questions around rollout.
<warren> nirik, the plan is still to change it
<c4chris> f13, what's the runroot thing?
<nirik> warren: cool.
is there going to be any koji/packagedb interaction? or do they have seperate db's for the info that overlaps?
<c4chris> f13, can the fakeroot package help ?
<abadger1999> nirik: Separate db's for F7.
<f13> c4chris: runroot is the ability to go like "koji runroot --packages="pungi" dist-fc7 "/usr/bin/pungi -c /etc/pungi.conf"
<abadger1999> We want to merge things by F8 but there's not enough time to get them both running and get them integrated between now and F7.
<f13> c4chris: it would take the packages, toss them into the mock chroot along with the buildsys-build group, and run the given command.
c4chris: basically a way to get to mock -r <config> chroot "command"
c4chris: it would run the command on all the arches that exists for dist-fc7
c4chris: but this is a low priority, usually the only thing that needs this is the compose tool and I can do manual chroots for now.
<abadger1999> I think we'll be able to merge the databases relatively easily at that time.  What we do with the UI is a little more open in my mind.
<c4chris> f13, k
<abadger1999> Maybe we'll split the UI to have a developer section which allows editing of packagedb information and interacting with the buildsystem and an enduser site that focuses on read-only views of the packages.
<f13> abadger1999: not a bad idea.
<abadger1999> Maybe it'll all be integrated.  Not really sure yet.
<nirik> even end-user doesn't have to be read-only... could add ratings, comments, quick file bugs against package, etc. ;)
<f13> love it / hate it
<c4chris> would be pretty nice
<abadger1999> nirik: Good ideas.  Add them to  ;-)
<c4chris> nice chatting with you :-)  Later folks
<nirik> abadger1999: ok.
<bpepple> c4chris: later.
<abadger1999> f13: I need to get a hosted account for the packagedb sometime soon -- I'm still using bazaar but I have a feeling I'm going to start tracking bugs :-)
c4chris: see ya.