bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* f13 is here
nirik is here, going to go grab coffee.
c4chris is here, hi folks
jeremy is here (mostly at least)
* bpepple barely got here. Had to flee to a coffee shop, since the homestead is without power.
* tibbs here
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
bpeppleHi, everyone!
f13spot will not be making it
(think he's getting a new sun box)
tibbsHe needs more sun.
nirikwarren is also gone (dr appt)
* bpepple will wait another minute or so to see if anyone else shows up.
bpeppleok, let's get started.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-August/msg00567.html
bpeppleAnyone have any problems with the FPC's emac proposal?
nirikwas this just changes to the existing guidelines? I thought we already had some for emacs.
oh, I guess it was just a draft before.
tibbsSorry for being late with the summary; the campus network took a dump when all the students came back.
Yes, the emacs stuff has been in draft stage for ages.
bpepplenp tibbs, stuff happens.
tibbsIt was blocked on changes to the existing emacs packages which have now gone through.
nirik+1 from me. Might need existing packages to update to come into compliance...
jeremyfine by me
* bpepple is fine with it also.
bpeppleok, I don't see any objections, so I think we can move on.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package builds should fail on empty debuginfo packages - spot
bpeppleI figured I would move this up on the schedule, since it seems like a no-brainer to me.
nirik+1, sounds good to me.
bpepple+1 here also.
nirikwe might ask mdomsch to do a quick 'find . -name '*.debuginfo' -size 0' and see how many packages this might affect, but if we make it fail they will find out soon enough.
caillon_hm, the other me has seem to lost connection in case someone was trying to reach me
f13caillon_: we're on the topic of making zero size debuginfo files fail the build.
bpepplecaillon_, no problem we're just voting on a proposal for package builds should fail on empty debuginfo packages.
nirikI assume we also mean "for all branches" ?
tibbsI doubt anyone would turn this on for FC6 at this point.
f13this would be devel/ going forward
c4chrisdevel sounds saner
bpepplef13: agreed.
caillon_yeah, changing tools behavior in released branches doesn't make sense
nirikyeah, true... devel+ makes sense.
d'oh stupid keyboard!
bpeppleI see six '+1' on this so far.
c4chrisI think spot wanted it
f13yeah, he did.
caillon__f13: was there a link to more info?
bpepplec4chris: yeah, your right.  I think we can safely assume he was a '+1'.
f13caillon__: I don't think so, there isn't a wiki proposal, but the basic idea is that 0 size debuginfo files are worthless, and if yo'ure creating such a thing either there is a bug in your package, or you should turn off debuginfo packages for our package.
bpepplecaillon__: any other questions, or should we move on?
caillon__yeah that seems sane, but i wonder how we'd even produce 0 size debug packages
caillon__is it really a packaging problem or a problem in the buildsys?
nirikit can happen if permissions are wrong on binaries, or the build strips the binaries, or several other reasons.
caillon__or build stack, e.g. strip, etc
drago01caillon__: binarys strippend @ install
caillon__okay.  if it can happen by dumb packaging, then +1 for me, too
jeremycaillon__: usually a packaging problem (or upstream makefile problem)
bpeppleanything else, or should we move on?
caillonmove on
bpeppletopic FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13
I don't see dwmw2, so f13 you want to take this?
seems f13 stepped away.
nirikperhaps we should table this another week... I think drjeff has a dkms thing too, which would probibly be related...
bpeppleI would like to see this proposal sent to the mailing list anyhow, so we can get some feedback.
c4chrisdid anyone hear an opinion from davej or chuck ?
bpepplec4chris: I believe we had from chuck, but I'm not sure about davej.
drago01can we be more verbose than "should"
tibbsEarlier discussion about letting folks into the kernel package wasn't terribly positve, I think.
c4chrisdrago01: which "should"
bpeppletibbs: you mean from the kernel devels? or from the community?
drago01damn... can't reach the site right now
tibbsFrom davej, but that's just my poor recollection.
f13I'm here.
|DrJef|nirik, you mean in here?
bpepplef13: no worries.
drago01can someone reach this page?
c4chrisI could a minute ago
drago01works again
bpeppledrago01: yeah, just pulled it up.
nirik|DrJef|: yes. Can you perhaps talk with dwmw2 and f13 about how your dkms proposal would work with their kmod proposal?
f13davej/cebbert are going to be rather strict about what goes in, a very heavy "should" be on it's way upstream.
--- nirik has changed the topic to: FESCO-Meeting -- MISC -- obsoleting kmod proposal: http://fedoraproject.org/wiki/DavidWoodhouse/KmodProposal - dwmw2, f13
|DrJef|nirik, is dwmw2's remove kmod proposal somewhere?
drago01c4chris: was talking about this "...and it _should_ be only drivers which are acceptable upstream and are shortly to be merged"
|DrJef|here's my dkms payload proposal http://fedoraproject.org/wiki/JefSpaleta/DKMSProposal?highlight=%28JefSpaleta%29
c4chrisdrago01: k, thx
nirikI vote we table this here, and let |DrJef| talk with dwmw2 and then have them both post to the devel list and then we can look at what we need to decide next week?
f13|DrJef|: see topic.
|DrJef|nirik, this was written as a followup to a a list thread where jwb_gone asked me to write an actual proposal
caillonif we start rejecting kernel modules based on quality, why aren't we doing this for other packages?
|DrJef|caillon, the argument is... kernel modules need to be mainlined..
c4chriscaillon: a non-working kernel is a bit more troublesome than a non-working app
|DrJef|caillon, as the mainline kernel is the established upstream
f13caillon: we've /always/ had the opportunity to reject kernel modules.  It used to fall on FESCo to vette them.
caillon|DrJef|: is that a fedora rule?
tibbsWe could theoretically run into the same issues with, say, openoffice plugins or something.
caillonor firefox extensions
|DrJef|caillon, there is a strong desire to see them mainlined
caillonor a multitude of things
tibbsIf said plugins broke with each minor openoffice update and had the potential to make openoffice itself break horribly in an undebuggable manner.
caillon|DrJef|: I'm not arguing that, I agree we want things mainlined.  but is it something that we should be actively enforcing?
|DrJef|caillon, i think dkms payloads provide a middle ground, to encourage mainlining
caillonif someone wants to package it separately, and can meet the packaging guidelines, should we reject them?
if so (and i think we do) we need to start thinking about making a policy for what types of things we can reject
|DrJef|caillon, hence my proposal to allow source only noarch packages for kernel modules for dkms to rebuild locally
drago01I don't want to bring this up again but what if a module does work fine but upstream don't want to merge it for whatever reason
|DrJef|drago01, works fine..now
|DrJef|drago01, there's a high maintainence burden for kernel modules that fail to work..on the next kernel rev
f13drago01: it's up to the kernel maintainer to decide.
caillonthere's an equally high burden for apps that depend on firefox right now
f13we're never going to have policy that will cover each and every situation.
drago01f13: ok fair enough
|DrJef|caillon, apps are not hardware access
dgilmore|DrJef|: though there is alot of pain in firefox updates
|DrJef|dgilmore, i dont disagree
f13there is some past precidence with this too, compat-python24
|DrJef|dgilmore, but firefox based apps... not working doesn't have the same level of recovery pain
f13I'm somewhat OK with allowing the maintainer of a package to have some say over what addons for said package are allowed in the distro
dgilmore|DrJef|: no  its not as critical
caillonf13: then we need to propose and ratify _that_
|DrJef|caillon, no more gecko dependant apps :->
* bpepple thinks we're getting off-topic.
c4chriscan we maybe start with the kernel case, then widen it to addons ?
dgilmoref13: i think we need to have better communication channels for dependent packages
caillonc4chris: I think the kernel case is an addon case.  it's just the most critical case.
drago01we need some kind of automatic dep rebuilds
f13yeah, I'm not trying to fix the world, I'm just trying to fix the kernel.
c4chriscaillon: sure, but it seems simpler to start there
caillonc4chris: not if we end up changing what we do for the kernel
in the course of other things
|DrJef|f13, i think dkms source-only  noarch packages for addon modules solves some issues
mdomschfyi, of the packages successfully building on i386, none have zero-sized -debuginfo
f13except that it introduces a secondary package database.
bpepplemdomsch: cool.  thanks.
f13and all the fun associated.
caillon(note that I do think we should do this, just arguing that we need a more generic policy here.  i'm not a fan of package specific policies)
|DrJef|f13, ?
f13|DrJef|: jeremy knows more.
|DrJef|f13, why do you have to track a second database?
mdomschthe complaint is that 'rpm -qa' doesn't tell you everything, you have to 'dkms status'
f13caillon: consider it amending the current package specific policy while we work on a more global policy.
mdomschto know what's really in /lib/modules/
|DrJef|mdomsch, dear god
mdomschthat's been jeremy's beef since day 1
|DrJef|mdomsch, can't dkms roll local rpm packages and update the rpmdb?
mdomschwell, they'll file-conflict
drago01but its better than having users install them from sources (not tracked at all)
caillonf13: fair enough.  but let's get it on the table then to fix up right.
|DrJef|mdomsch, jeremy's beef.. or people actually using dkms's beef?
dgilmore|DrJef|: it doesnt solve the case where the dkms module is for the systems  storage
abadger1999FWIW, I don't like the kernel module exclusion on its theoretical basis, only on its practical value.  So I'd lobby against expanding it to a general rule.
caillonfor a different week if not now
mdomschI've not heard a user complain
|DrJef|mdomsch, well then....
mdomschand we put into the Red Hat 'sysinfo' tool to call dkms status, so their tech support knows
* nirik thinks both these proposals need more cooking on the lists... we arent going to solve everything here on them and get to voting on anything I don't think.
|DrJef|mdomsch, why does jeremy feel he needs to track what dkms knows?
* c4chris thinks... what nirik said :)
f13 pokes jeremy for input
mdomschdgilmore, dkms can deal with storage if I get the kernel package hooks in, so when a new kernel package is installed, dkms can get invoked automatically
which, I point out, Ubuntu/Debian are now doing
* mdomsch dons asbestos underware
|DrJef|mdomsch, that's just in the post install scriptlet action in the kernel package right?
|DrJef|mdomsch, like inside the script that ends up calling mkinitrd
|DrJef|mdomsch, minor
or somesuch
mdomschwell, I've asked for that for 5 years, and keep getting ignored/rejected, so, minor yes, but execution, no
f13coudln't you do the same with %triggerin ?
dgilmoremdomsch: cool that would be my only concern
mdomschf13, no, %triggerin doesn't tell me what version of the new package is being installed
or uninstalled
f13ah hah.
mdomschand, triggers are evil (per ewt and LSB)
* f13 mutters something about how kernel modules are a pain in the ass to do packaging work on.
mdomschanyhow, that's all detail, is that what's holding up these proposals?
|DrJef|f13, from a packaging standpoint.. enabling dkms pretty much equivalent to dealing with mkinitrd isnt it?
bpeppleok, we've got a little less than 20 minutes left, and should probably move on.  |DrJef| could you get with dwmw2 & f13, and work on a proposal.
|DrJef|bpepple, i'll attempt it
f13|DrJef|: not really.
bpepple|DrJef|: cool, thanks.
bpepplemoving on then......
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- initscripts LSB compliant - howto ? from Hans - all
tibbsOh yes please.
f13is there anybody here that can talk intelligently about it?
nirikwho was it that filed all those bugs?
* nirik goes to look.
tibbsHarald Hoyer, wasn't it?
bpeppletibbs: I think you're right.
tibbsIt was; bugzilla's just being slow.
nirikI think we should ping him again and try and get answers?
Really that should be something that gets through the packaging folks, right?
bpepplenirik: yeah.
tibbsIt should have gone that route, yes.
But he took it upon himself to file a ticket against any package with an initscript.
nirikso, we should ignore those bugs for now, and ask Harald to submit a real draft ?
bpepplemaybe we could get Harold to show up at the next packaging meeting.
tibbsI've tried to follow the instructions and have ended up more confused than before.
dgilmorebpepple: that would be a good idea
tibbsSo in the end I can only hope that what I'm using doesn't break anything.
f13the #1 ultimate thing to keep in mind
do /not/ make any changes that would lead to you requiring redhat-lsb
nirikwell, I think he needs a formal proposed guideline doc in the wiki to submit to packaging, and they can ask him to clarify it until it looks acceptable.
dgilmoref13: indeed redhat-lsb  is so wrong in many situations
tibbsHopefully just changes to the comment block at the top are OK.
bpeppleDoes someone from the packaging committee want to contact Harold?  Otherwise, I will.
nirikand answering the 'Unanswered questions' section.
wwoodsf13: requiring redhat-lsb Considered Harmful?
jeremywwoods: yes
f13wwoods: extremely.
jeremywwoods: bloats the install quite a bit
wwoodsgood to know.
bpeppleOk, we should probably move on.  I'll contact Harold, and see if he can go to the next packaging committee meeting.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Review of new features status http://fedoraproject.org/wiki/Releases/8/FeatureList- poelcat, jwb
abadger1999bpepple: Have him write a draft under PackagingDrafts/<something>  and post it to fedora-packaging for feedback as well.
bpepplepoelcat & jwb wanted to review the status of some of the new features, but it seems neither of them are here. :(
abadger1999: will do.
abadger1999Thanks :-)
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleok, anything else people want to discuss?
nirikFYI, I looked in bodhi the other day... we have:
jeremyI want to talk about a specific feature -- presto
nirik102 updates in 'pending' older than 2 weeks.
50 in 'testing' older than 2 weeks.
f13lets give jeremy the floor
bpepplef13: agreed.
bpepplejeremy: ?
jeremyso it doesn't look like the buildsys side is going to get done in time for the feature freeze
so definitely pulling having presto enabled and installed by default from the table for f8
but I do want to continue to move forward with hopefully getting the buildsys side done and even getting the -updates repo presto-enabled if we can for f8
wwoodsbuildsys is the only blocker?
f13allow it to be opt-in for F8 users, and default for rawhide?
jeremyf13: basically, yeah
f13sounds good to me.
jeremywwoods: buildsys and then the follow-ups of testing, etc
(plus some tool side to pull out of the buildsys I guess, but that's the simple side)
bpepplejeremy: sounds reasonable to me.
jeremyokay.  so then what do we do with the feature page?  just move it to proposed since it's not really an f8 feature?
c4chriswe can gloat about it for F9
* nirik thinks thats fine...too bad it won't be in sooner tho. ;(
bpepplejeremy: yeah, I think moving it to proposed makes sense.
c4chris: agreed.
jeremynirik: yeah.  just time ran out due to some more pressing issues for the buildsys side :(
bpepplejeremy: anything else on Presto?
jeremynope, that was it
bpepplejeremy: cool.
any other items before calling it quits?
poelcatbpepple: i'm back
* c4chris has nothing
bpepplepoelcat: just getting ready to wrap up the meeting. :(
poelcatbpepple: okay
poelcatit was more jwb's item than mine
wasn't sure if FESCo wanted to do anything to encourage feature owner feedback for features that aren't done
i've pinged peope as much as I can
bpepplepoelcat: yeah, we should probably poke people a bit.
nirikso, did we want to revisit expiring or auto-pushing updates after 2 weeks? I guess we can next week...
bpepplenirik: let's add it to the schedule for next week.
since we're out of time.
nirikbpepple: ok.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!