[09:52] <fabbione> dilinger: ehhe
[09:52] <pitti> Hi dilinger 
[09:52] <dilinger> hi :)
[09:52] <zyga> pitti: hello :)
[09:54] <lamont> hi fabbione 
[09:54] <fabbione> hi lamont 
[09:55] <fabbione> -5 minutes
[09:55] <fabbione> plenty of time :)
[09:56] <zul> hey dilinger 
[09:56] <lamont> heh.
[09:56] <lamont> T-Bone: perms fixed
[09:57] <T-Bone> lamont: thx 
[09:57] <T-Bone> lamont: figures are getting nicer ;)
[09:59] <zul> blah..
[09:59] <fabbione> ok
[09:59] <fabbione> it's 20:00 UTC
[09:59] <fabbione> let's get started
[10:00] <fabbione> everybody is welcome to partecipate
[10:00] <fabbione> but please stay on-topic
[10:00] <fabbione> the first item on the agenda is:
[10:00] <fabbione> "Any remaining post-release-candidate panic items before hoary?"
[10:00] <fabbione> we are clearly full freeze.
[10:01] <fabbione> and we have one critical bug
[10:01] <fabbione> but nobody has been able to debug/fix it
[10:01] <fabbione> so i guess hoary will have to live with it
[10:01] <zul> which bug is this?
[10:01] <pitti> you mean CAN-2004-0173?
[10:01] <fabbione> zul: it's assigned to me. the one about i386 not booting.
[10:01] <zul> ah ok
[10:02] <fabbione> pitti: no i am coming to that one
[10:02] <pitti> okay, because it's mostly academic
[10:02] <fabbione> so the only thing left to do from now until the 6th (last possible date for uploads) is security
[10:02] <fabbione> pitti did a very neat job here:
[10:02] <fabbione> http://people.ubuntu.com/~pitti/ubuntu-cve.html
[10:03] <fabbione> out of that list there 2/3 security fixes that would be nice to have, but they are not mandatory for hoary
[10:03] <fabbione> + CAN-2005-1073
[10:03] <fabbione> pitti: want to explain to the rest of the team?
[10:03] <Amaranth> CAN-2004-0173 seems to have something to do with Apache and cygwin?
[10:03] <pitti> no
[10:04] <pitti> it's a mostly academic bug
[10:04] <pitti> about reading setuid files which are actually only executable
[10:04] <pitti> we thought that we fixed it ages ago, but unfortunately it's not
[10:04] <pitti> no patch so far, so we have to wait
[10:04] <fabbione> adn this is common mistake across all distros
[10:04] <fabbione> so it's not only us affected by this problem
[10:04] <pitti> yeah, all of them just took the upstream patch
[10:05] <smurfix> Nobody actually verified whether the patch works?
[10:05] <pitti> but since we don't ship any executable-only binaries, and Debian Policy mandates readability anyway,
[10:05] <fabbione> smurfix: it doesn't
[10:05] <pitti> smurfix: there is no patch
[10:05] <pitti> suid binaries from packages are not affected anyway
[10:05] <pitti> I will notify you if I have anything new about this issue
[10:06] <smurfix> Your statements are mutually exclusive, but OK ;-)
[10:06] <pitti> smurfix: ?
[10:06] <Amaranth> Do you have a URL to where this is descrived?
[10:06] <Amaranth> err, described
[10:06] <fabbione> smurfix: what we believed it was a fix, didn't work
[10:06] <pitti> smurfix: I mean, we only ship them with read+executable
[10:06] <pitti> smurfix: we don't ship any only-executable binaries (which are a pretty stupid idea anyway)
[10:07] <pitti> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1073
[10:07] <smurfix> pitti: Yeah, I know, sorry -- I meant: if there's no patch, then this nonexistent patch can't work-or-not-work
[10:07] <fabbione> ok somebody needs to go again through pitti's list to double check we did not miss known fixes
[10:07] <fabbione> who voluteers for that?
[10:07] <Amaranth> oh, 1073. you said 0173 the first time
[10:08] <fabbione> pitti: ok, that's your.
[10:08] <pitti> Amaranth: sorry, 1073, right
[10:08] <pitti> fabbione: I need to reprocess this list anyway
[10:08] <fabbione> pitti: ok perfect.
[10:08] <fabbione> since we are talking about security now
[10:08] <pitti> fabbione: tomorrow's run will clean it up further, then I look over it again
[10:08] <fabbione> pitti, do you want to define any specific procedure for hoary-security kernel uploads??
[10:09] <Amaranth> pitti: So it's only a problem if you have an executable binary that isn't readable?
[10:09] <fabbione> Amaranth: correct
[10:09] <pitti> Amaranth: yeah, the vuln allows you to read it anyway
[10:09] <pitti> I'd like to have one person I can bother with undisclosed stuff
[10:09] <zul> Amaranth: safer than sorry
[10:10] <pitti> fabbione: that would be you, or lamont if you are not available?
[10:10] <pitti> other than that I'd like to keep the current practice
[10:10] <fabbione> pitti: i think we should be at least 2 and i agree for me
[10:10] <lamont> pitti: I'm available
[10:10] <fabbione> lamont: ?
[10:10] <pitti> I collect information and manage the status and advisories, and you/lamont build the packages
[10:10] <pitti> and upload them
[10:10] <pitti> is that okay for you?
[10:11] <fabbione> pitti: due to the new building system. we need to follow certain procedures too
[10:11] <fabbione> pitti: yes.
[10:11] <pitti> in particular?
[10:11] <fabbione> it is ok for me
[10:11] <fabbione> pitti: we need to test/build the kernel all arches before each upload
[10:11] <fabbione> to verify the ABI integrity
[10:11] <pitti> I'd like to introduce a basic testing pattern before an upload happens
[10:11] <fabbione> if the ABI breaks due to a fix
[10:11] <pitti> ABI> that's great
[10:11] <fabbione> we will need to do more than just one upload
[10:12] <lamont> fabbione: either we don't check in the embargoed source changes, or we need an embargoed baz repository (either is doable)
[10:12] <fabbione> lamont: i used an embargoed repo for that
[10:12] <fabbione> lamont: i simply don't commit the changes to the repo
[10:12] <fabbione> and use my local one for test/build
[10:13] <pitti> I think we need to define some testing policy
[10:13] <fabbione> mdz, pitti: did we ever agree on how to handle an ABI change for a security fix?
[10:13] <pitti> yes, I think so
[10:13] <zul> i think the embargoed baz repository is good because if either lamont or fabbione than one of you can get a security fix if its critical
[10:13] <fabbione> pitti: sure. what are your reccomendations?
[10:13] <pitti> the crucial point is that we pre-add the next ABI number
[10:13] <pitti> so that the l-r-m build can see the new kernel in the queue
[10:14] <fabbione> pitti: the previous actually :)
[10:14] <pitti> previous?
[10:14] <dilinger> you guys have the same ABI d-i problems that debian does for security fixes, right?
[10:14] <lamont> zul: embargoed repository is trivial for fabbione and I to set up...
[10:14] <lamont> just requires ssh access to the same machine somewhere
[10:14] <fabbione> dilinger: yes. that's something we need to discuss at UDU
[10:14] <pitti> l-r-m must be built against the new kernel, but that isn't in the archive yet
[10:14] <jbailey_> fabbione: Isn't it less ugly since we generate the udeb's for the kernel packages directly?
[10:14] <pitti> but the buildd can use the pending queue
[10:15] <fabbione> jbailey_: yes, but we still need a lot of work for an ABI change
[10:15] <jani> fabbione which is the 386 not booting critical bug?
[10:15] <dilinger> fabbione: ok.  i figured it was the case, but i wasn't positive.
[10:15] <fabbione> jani: i don't have it handy.. it has been downgraded to Major, but still pretty sever
[10:16] <jani> ok I'll search bugzilla
[10:16] <fabbione> pitti: i am not really afraid of the build sequence problem
[10:16] <fabbione> i am more concern to understand
[10:16] <pitti> fabbione: that's mostly an elmo-ish problem
[10:16] <fabbione> linux-source -> hoary-security
[10:16] <fabbione> l-r-m -> ?
[10:16] <fabbione> linux-meta -> ?
[10:16] <fabbione> d-i -> ?
[10:17] <lamont> fabbione: the key is that nothing be NEW during the process
[10:17] <fabbione> + we have all the seeding problems, but at this point i am not 100% sure how they are handled by elmo when it goes to security
[10:17] <pitti> it's still hoary-security
[10:17] <pitti> fabbione: the buildd sorts out main/restricted/universe etc.
[10:17] <fabbione> lamont: the problem is if a security fix breaks the ABI
[10:17] <pitti> fabbione: erm, s/buildd/katie/
[10:18] <fabbione> lamont: we have seen it in warty and we can expect it for hoary
[10:18] <fabbione> lamont: the issue is how do we want to handle all the syncage of the other packages
[10:18] <lamont> fabbione: right.  and the solution is to make sure that nothing is NEW when we roll the ABI.  then there's the question of what to do with the outdated abi version...
[10:18] <fabbione> the outdated cannot be removed
[10:18] <pitti> for Warty, elmo pre-added the next 10 ABI versions
[10:18] <pitti> we should do the same for Hoary
[10:19] <fabbione> make sense
[10:19] <pitti> maybe the new kernel version should conflict with the old ABI number?
[10:19] <fabbione> + we can add a bit of extracare in not releasing an ABI change for each fix, but try to queue tehm a bit
[10:19] <pitti> to force removal of the old package, is that what you mean?
[10:19] <fabbione> pitti: there is no point in that. they are 2 different packages and lands in 2 different dirs
[10:20] <lamont> fabbione: but effectively it means that say, there's a security vul in linux-image-2.6.10-5-686 that will never be fixed. (because that's in 2.6.10-6)
[10:20] <pitti> that's what I mean with the conflict and replace
[10:20] <pitti> so the user won't keep an outdated kernel version around
[10:21] <fabbione> it's dangerous to do that
[10:21] <Mithrandir> I suck, I forgot about the meeting. :(
[10:21] <fabbione> i mean it's the counter side of the coin
[10:21] <pitti> yeah, I just wanted to know whether this is the problem you talked about
[10:21] <fabbione> we might end up in removing the running kernel
[10:21] <fabbione> that is really BAD!
[10:21] <pitti> oh, right
[10:21] <pitti> okay, let's forget about this proposal
[10:22] <fabbione> we need to keep the following practise and improve for breezy
[10:22] <fabbione> pitti: is there anything else you want us to be ready for security related issues?
[10:22] <fabbione> just to sum up:
[10:22] <Mithrandir> fabbione: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-current.html seems fairly useless ATM; is there a log somewhere?
[10:22] <fabbione> 1) lamont, fabbione: contact points
[10:22] <fabbione> 2) pitti sends the patches
[10:23] <fabbione> 3) 1) gets them, apply/test and upload
[10:23] <fabbione> Mithrandir: the log is uploaded every hour
[10:23] <pitti> re 3) we should coordinate and ack an upload to each other
[10:23] <lamont> Mithrandir: will spew in private window
[10:23] <pitti> fabbione: otherwise that's fine
[10:23] <fabbione> pitti: ok.
[10:24] <fabbione> lamont: does it work for you?
[10:24] <Mithrandir> lamont: yes please.
[10:24] <lamont> fabbione: sounds good
[10:24] <fabbione> ok
[10:24] <zul> what if both of you arent available 
[10:24] <fabbione> is there anything else we need to look into before hoary is out?
[10:24] <pitti> then we are doomed :-)
[10:24] <zul> ok cool :)
[10:24] <Amaranth> what if pitti isn't available? :)
[10:24] <fabbione> zul: pitti will be our backup with the support of the rest of the team :-)
[10:25] <zul> ok just playing devil's advocat
[10:25] <Mithrandir> has there been any discussions surrounding the problem when resuming and the kernel versions don't match?
[10:25] <fabbione> Amaranth: if pitti is unavaliable we are all r00t3d
[10:25] <pitti> I know how to build a kernel and how to do patches
[10:25] <pitti> but you guys have far more experience with it
[10:25] <pitti> so I only want to do this if it's really necessary
[10:25] <fabbione> pitti: in case both lamont and i will be unavailable you can coordinate with zul and dilinger
[10:25] <pitti> hmm, I plan to go to vacation one week before UDU
[10:25] <pitti> no security from my side then
[10:26] <pitti> fabbione: ack
[10:26] <fabbione> since they both know the building system 
[10:26] <pitti> if I'm not available, then mdz is the logical fallback
[10:26] <fabbione> ok
[10:26] <pitti> mdz is on vendor-sec
[10:26] <fabbione> we are covered for security
[10:26] <pitti> ack
[10:26] <fabbione> pitti: ack that
[10:26] <fabbione> i think we can thanks pitti for the security part
[10:26] <fabbione> pitti: you are free from us :)
[10:26] <fabbione> and thanks for coming
[10:27] <pitti> and fabbione for his excellent hoary work!
[10:27] <pitti> no worries :-)
[10:27] <pitti> fabbione: my gf lays beside me and sleeps...
[10:27] <T-Bone> pitti: lucky man ;)
[10:27] <fabbione> pitti: eh my wife does too already 
[10:27] <fabbione> ok
[10:27] <fabbione> #
[10:27] <fabbione> Breezy plan
[10:27] <pitti> bye folks
[10:27] <fabbione> cya pitti
[10:28] <fabbione> it's up to us how long we want to talk about this
[10:28] <fabbione> we have a very long planned BOF @ UDU
[10:29] <fabbione> is there anybody that wants to discuss any particular topic on the list?
[10:29] <fabbione> https://www.ubuntulinux.org/wiki/UbuntuDownUnderBOFs <-
[10:29] <zul> hold on a sec..its slow
[10:29] <fabbione> sure
[10:30] <zul> oh yes...bk snapshot
[10:30] <fabbione> zul: go ahead
[10:30] <zul> so the way i have a look at it is that you have a bk snapshot and a stable image correct?
[10:30] <fabbione> correct
[10:31] <fabbione> something we tried with 2.6.11 but didn't really work due to time (mainly)
[10:31] <zul> so the bk snapshot is going to be apart of main or universe?
[10:31] <fabbione> universe
[10:31] <zul> motu is not going to like that ;)
[10:31] <fabbione> we really do not want to support bk snapshots
[10:31] <T-Bone> fabbione: what's the point of a packaged bk snapshot?
[10:31] <fabbione> motu will have almost nothing to do with it
[10:31] <fabbione> we need to find a way to build them automatically
[10:32] <fabbione> almost on a daily base
[10:32] <fabbione> T-Bone: testing, before backporting fixes
[10:32] <T-Bone> fabbione: my understanding is that such snapshots would do nothing but hog builders CPU
[10:32] <Mithrandir> we have enough buildd power, so I wouldn't be too worried about that
[10:32] <fabbione> T-Bone: most of the time we hear: "this is fixed in bk". 
[10:32] <fabbione> so ok.. install that kernel and let us know
[10:32] <T-Bone> fabbione: bk snapshots don't represent anything correlating to a "release" or some "known state" of any kind, if i'm right
[10:32] <zul> fabbione: well then you cant call it something like 2.6.12-rc whatever you are going to have to call it different because users are going to try it
[10:33] <fabbione> zul: i was considering linux-source-bleeding-edge
[10:33] <fabbione> or something like that
[10:33] <T-Bone> -rc kernels seem much more meaningful to me
[10:33] <fabbione> it doesn't need to respect ABI or anything
[10:33] <fabbione> just be tehere
[10:34] <zul> and if the users try it? say in the bug report that its not supported?
[10:34] <fabbione> T-Bone: bk is like any other revision control system around. it has tags and so on.. we just want to have HEAD
[10:34] <T-Bone> they have known changelogs, represent a known state point, etc
[10:34] <T-Bone> fabbione: my point is just that -bk may actually not build more than 20% of the flavours in some case (all archs included)
[10:34] <fabbione> zul: we need to ask the users to use a bk kernel on debugging request to verify that a certain bug is fixed upstream or not
[10:35] <fabbione> we don't want a user to run it as normal kernel
[10:35] <T-Bone> fabbione: ie, -bk might be *known to be broken*
[10:35] <fabbione> that's why it would be in universe
[10:35] <zul> got it but some users will is my point
[10:35] <fabbione> T-Bone: yes i am aware of that.
[10:35] <lamont> just call it 2.6.11-broken
[10:35] <T-Bone> fabbione: as zul said. Something like this shouldn't go in the archive, imho
[10:35] <fabbione> zul: that's their problem...
[10:35] <fabbione> no i am serious..
[10:36] <zul> no i agree 
[10:36] <dilinger> T-Bone: that would be a good thing
[10:36] <T-Bone> fabbione: if that's for our own testing usage, we can have it in some other archive, can't we?
[10:36] <T-Bone> dilinger: what?
[10:36] <fabbione> if we add a proper description and it is in universe
[10:36] <dilinger> T-Bone: it would be an easy way for people working on archs to see that they need to be feeding linus fixes
[10:36] <T-Bone> dilinger: true, but that's not our purpose, as i see it
[10:36] <dilinger> versus grabbing the latest 2.6.x and realizing, hey, it doesn't build on my arch
[10:36] <fabbione> T-Bone: it can be as side-effect
[10:36] <T-Bone> dilinger: besides, most of the time, that kind of patches are already on their way to linus when the bk snapshot is taken
[10:37] <dilinger> T-Bone: then it gives them incentive to ensure linus applies it :)
[10:37] <zul> fabbione: i agree just make sure the description says something like NOT FOR REGULAR DAY USE or something
[10:37] <T-Bone> dilinger: heh. Or gives linus incentive to drop them because he's sent several times the same patch? ;o)
[10:37] <fabbione> zul: that is kinda what i meant
[10:37] <zul> fabbione: gotcha
[10:38] <dilinger> T-Bone: something like that.  linus loves being patchbombed, maybe the porters can write a script to email linus patches twice a day ;)
[10:38] <T-Bone> fabbione, zul: what about adding some kind of preinst script that would default to "not install" asking the user whether he is 1) really sure he wants to do that or 2) really stupid? :}
[10:38] <T-Bone> dilinger: that script exist :)
[10:38] <T-Bone> dilinger: ask willy ;)
[10:38] <zul> T-Bone: that would be fine for me at least description is fine though
[10:38] <fabbione> T-Bone: whatever you have in your mind is fine, just send me the patches :)
[10:39] <T-Bone> zul: most users don't read package description when they look for a specific package
[10:39] <T-Bone> fabbione: hehe :)
[10:39] <dilinger> T-Bone: i'm not sure if it's clear, but i would recommend it only does it on fresh installs
[10:39] <T-Bone> dilinger: true
[10:39] <dilinger> T-Bone: if upgrading a bleeding edge kernel, it shouldn't prompt the user
[10:39] <zul> just send a shock when they install it :)
[10:39] <T-Bone> dilinger: got that
[10:40] <fabbione> ok so i think we all agree that having a bk snapshot around is good
[10:40] <zul> i guess we'll see how it goes :)
[10:40] <fabbione> the main issue is having it "naked" or "full-feature"
[10:40] <T-Bone> i didn't say i think it's good, but I understand the points that have been raised pro such a package :)
[10:41] <zul> i would say the same features we have on our own kernels
[10:41] <T-Bone> my personnal feeling would have been to use -rc kernels
[10:41] <fabbione> zul: most of the patches will start not to apply to a bk snapshot
[10:41] <dilinger> fabbione: the obvious benefit of full-feature is that we can see when rarely-used drivers break.  of course, that'll increase FTBFSs
[10:41] <fabbione> or not to compile
[10:42] <fabbione> dilinger: exactly, and maintaince of these patches in a bk snapshot env is extremely time consuming
[10:42] <zul> fabbione: i mean the same options that we have minus third party drivers
[10:42] <zul> ie ipw2200 et al
[10:42] <fabbione> zul: dilinger has a point
[10:42] <T-Bone> fabbione: and pointless, since a snapshot is "moving" by essence
[10:42] <fabbione> T-Bone: it's not pointless
[10:43] <fabbione> since at a certain point that bk snapshot will be released as 2.6.X
[10:43] <fabbione> and you have the patches already rediffed for it
[10:43] <T-Bone> fabbione: not absolutely piontless, i understand that, since you prepare what will be needed for the next release,
[10:43] <fabbione> in a RCS
[10:43] <fabbione> right now preparing a new upstream release takes me approx 2 days of work
[10:43] <fabbione> 1 to scream the patches
[10:43] <T-Bone> still, you'll probably end up doing several time the same work on a given patch because the system it applies to has changed in various ways between snapshot, before stabiliziing
[10:43] <fabbione> 2 to make it build on 3 arches
[10:44] <T-Bone> hence my opinion that we should use -rc
[10:44] <T-Bone> fabbione: ^^^
[10:44] <fabbione> yes i understand
[10:44] <fabbione> ok since we have several options, we will need to evaluate which one works better
[10:45] <T-Bone> fabbione: what you plan to do would (imho) be best achieved using -rc kernels
[10:45] <zul> or if you want to release a snapshot monitor lkml for one or 2 days and then move to a new snapshot
[10:45] <fabbione> we can also have bk on a weekly base
[10:45] <T-Bone> fabbione: i'm saying that to spare you the overhead of dealing with moving -bk, mind you.
[10:46] <fabbione> it doesn't need to be daily
[10:46] <T-Bone> fabbione: i think that your goal is smoother and faster kernel transitions. Using -bk *might* end up to the exact opposite
[10:46] <dilinger> i think bk on a weekly basis is a nice compromise
[10:46] <zul> i agree
[10:46] <T-Bone> this would probably be better, but this wouldn't solve the issues i've raised
[10:47] <smurfix> I think so too. Minimally we should do -rc
[10:47] <T-Bone> given that you might *fall* on that particular -bk snapshot that will be completely reverted/changed/corrected 2h later
[10:47] <fabbione> T-Bone: that can happen always
[10:47] <T-Bone> given fabbione's needs, -rc seem to fit the prerequisites better
[10:48] <dilinger> T-Bone: if the subsystem that a patch applies to is being reworked, and you know the patch is just going to fail to apply again, there should probably be a way to temporarily disable the patch, or something like that
[10:48] <T-Bone> (that's the analyst speaking ;)
[10:48] <fabbione> given fabbione's needs <- kernel team
[10:48] <T-Bone> dilinger: there is. It just increase the work on the kernel (tracking down the faulty patch, trigger a build again, and a build *takes time*)
[10:48] <zul> well if the workload is a problem then split it up
[10:48] <fabbione> it's not only me
[10:49] <T-Bone> fabbione: 2.4.11? That was ages ago. Things have (hopefully) changed a bit :)
[10:49] <T-Bone> fabbione: i understand, and i also speak in the interest of the team (or so i hope) :)
[10:49] <fabbione> T-Bone: stuff like that still happens... see 2.4.15 ? from Marcello?
[10:49] <fabbione> anyway
[10:49] <T-Bone> 2.4.15?
[10:50] <zul> er...a bit offtopic
[10:50] <fabbione> we need some kind of snapshotting...
[10:50] <T-Bone> seems mostly irrelevant to me
[10:50] <T-Bone> right. My 2 cents is "use -rc". 'nuff said ;)
[10:50] <fabbione> who would like to start looking at it?
[10:51] <fabbione> even just a simple analysis of pro and cons
[10:51] <fabbione> that we will bring up @ UDU again
[10:52] <dilinger> well, even using -rc would be beneficial to just waiting for the next 2.6.x.  so, my vote is for either a weekly bk or rc (and it might be worthwhile to try one or the other and see how much work it actually ends up being)
[10:52] <fabbione> zul: ok, it's your
[10:52] <fabbione> rc happens too slowly imho to be used for this kind of test
[10:52] <zul> one more from the wiki :)
[10:53] <fabbione> nothing ensures that we will get an rc in the 3 months of breezy development
[10:53] <fabbione> zul: ok.. go ahead (again)
[10:53] <T-Bone> fabbione: question is "do we need to go faster than -rc to speed up our own transition?"
[10:53] <zul>  Broader time-based community kernel tree
[10:53] <zul> ??
[10:53] <fabbione> T-Bone: we need to be faster than rc in backporting bug fixes.
[10:54] <T-Bone> fair enough
[10:54] <fabbione> zul: i think mdz added that one
[10:54] <zul> ah ok..
[10:54] <fabbione> let's ask him
[10:54] <mdz> that's a sabdfl thing
[10:54] <fabbione> oh
[10:54] <fabbione> do you know what he means exactly?
[10:55] <dilinger> maybe he means something like -as?  or more in line w/ ubuntu, fixes + acpi +..?
[10:55] <fabbione> i think sabdfl is not around
[10:55] <fabbione> zul: sorry, but i don't have a clear answer for that
[10:56] <zul> fabbione: no probs...ill shut up now with the wiki stuff :)
[10:56] <fabbione> ok last call for item 2) in the agenda
[10:56] <fabbione> anybody else wants to discuss any of the points in the wiki?
[10:56] <T-Bone> Build fewer flavours
[10:56] <zul> other than me
[10:57] <fabbione> all that stuff will mostlikely be part of breezy
[10:57] <fabbione> T-Bone: go ahead
[10:57] <fabbione> (mdz is here.. so he can answer that ;))
[10:57] <T-Bone> hehe, well, what's the idea behind that point?
[10:58] <T-Bone> i mean, what kind of "flavours" would be candidate for removal?
[10:58] <mdz> I'm in another meeting right now, so please ask direct questions if you need answers
[10:58] <lamont> T-Bone: if 686-smp is not significantly slower than 686, why build both?
[10:58] <lamont> for example.
[10:59] <T-Bone> lamont: ok, so that's a "smp vs up" thing?
[10:59] <fabbione> T-Bone: not only
[10:59] <fabbione> if 686 can boot k7.. why do we build k7?
[10:59] <fabbione> it's a global cleanup of flavours
[11:00] <T-Bone> my point is basically that 1) it's a good thing not to have too many flavours but 2) it's a good thing to have a kernel matching the user's architecture as best as possible, since kernel is a CPU sensitive thing
[11:00] <T-Bone> giving a precise example:
[11:00] <T-Bone> all pmacs can run ppc601 code,
[11:00] <T-Bone> but not running an altivec enabled kernel on an altivec machine is quite a loss
[11:01] <fabbione> T-Bone: the point is more like: what happen if i enable altivec on a non-altivec machine?
[11:01] <T-Bone> it doesn't work
[11:01] <T-Bone> err
[11:01] <fabbione> perfect, than you need 2 flavours
[11:02] <T-Bone> no it does
[11:02] <T-Bone> my example was bad
[11:02] <fabbione> than one flavour is enough
[11:02] <jbailey_> You should get SIGILLs for altivec on a non-capable machine.
[11:02] <lamont> T-Bone: where an ABX comparison says there's a clear benefit, you build two flavors.  Where it doesn't, and still works on both, you don't
[11:02] <T-Bone> ok
[11:03] <T-Bone> that's fine by me, let's drop that now, it can be clarified later,
[11:03] <fabbione> ok
[11:03] <lamont> ABX: I give you A and B and some unknown.  Tell me which it is.
[11:03] <T-Bone> but in regard to what was said (fewer flavours):
[11:03] <T-Bone> Add a -dbg flavour? or enanche the kernel debugging.
[11:03] <T-Bone> that doesn't seem to make much sense to me
[11:03] <fabbione> T-Bone: -dbg is not a flavour
[11:03] <T-Bone> ?
[11:03] <T-Bone> lamont: hehe ;)
[11:03] <fabbione> flavours are 386, 686, k7 and so on
[11:04] <fabbione> each of them adds a config and complexity for the user
[11:04] <fabbione> a -debug is probably less confusing than 383/686
[11:04] <T-Bone> i disagree
[11:04] <T-Bone> some users are confused by -smp
[11:04] <lamont> esp since 386 doesn't run on 386 machines, I expect. :-)
[11:05] <fabbione> lamont: nope.. minimum is 486
[11:05] <T-Bone> fabbione: what would be the point of a -dbg kernel?
[11:05] <lamont> T-Bone: debugging, of course.
[11:05] <T-Bone> fabbione: asking the user to install it in case of a problem?
[11:06] <fabbione> T-Bone: the answer is embedded in the question
[11:06] <fabbione> T-Bone: exactly
[11:06] <T-Bone> fabbione: i *mean* the question
[11:06] <T-Bone> ok
[11:06] <T-Bone> makes sense
[11:06] <T-Bone> i'm done with questions
[11:06] <fabbione> there are tons of debugging features we do not build
[11:06] <zul> im for less flavours
[11:06] <dilinger> how many users are actually going to make use of -dbh?
[11:06] <dilinger> er, -dbg
[11:06] <fabbione> simply because they slowdown the machine to death
[11:07] <T-Bone> dilinger: none unless we ask them
[11:07] <dilinger> right
[11:07] <T-Bone> besides, none of those using it will be able to decypher the debug output
[11:07] <fabbione> dilinger: these packages will still land in universe
[11:07] <dilinger> so, why not have debugging enabled on everything in the -bk or -rc kernels?
[11:07] <T-Bone> that has to be kept in mind
[11:07] <dilinger> if a user has a problem, ask them to try a -bk kernel
[11:07] <dilinger> if it still happens, you'll have lots of debugging info from that
[11:07] <fabbione> dilinger: right...
[11:07] <lamont> is this really the time to be having the BOF?
[11:08] <T-Bone> that doesn't work for QA releases
[11:08] <lamont> or just to be adding things to the list for the BOF?
[11:08] <fabbione> lamont: it's just discussing a few points that people feel more sensible about
[11:08] <fabbione> since not all the team will be at UDU
[11:08] <T-Bone> lamont: as fabbione just said :)
[11:08] <lamont> ok.
[11:09] <lamont> just wanted to throw that process-check in there
[11:09] <fabbione> oky doky
[11:09] <T-Bone> my objection to what dilinger said is that if the -dbg kernel is to be used on stable releases, it needs to be the same version as the one in the release
[11:09] <fabbione> is there any other item that we should discuss here?
[11:09] <Mithrandir> I have two small things which would be very useful for breezy:  a linux-source meta-package which tracks the latest kernel-source in main.  The other is integration with the notifier so the user will be told that "you need to reboot, else resume after suspend won't work and you really, really want to reboot now"
[11:10] <lamont> obviously, we should start a discussion on kernel-team about various of the items, with summaries going back to the wiki page, so that we can finish the BOF in < 10 hours at UDU
[11:10] <T-Bone> lamont: definitely
[11:10] <Mithrandir> especially the latter is _painful_ for laptops where you suspend to disk. :)
[11:10] <fabbione> lamont: that's exactly what i was going to ask you to do :)
[11:10] <fabbione> lamont:ehehe
[11:10] <jbailey_> fabbione: At some point we should figure out if initramfs generation should be integrated with kernel builds.
[11:11] <fabbione> lamont
[11:11] <fabbione> .i did send the email to kernel-team
[11:11] <lamont> fabbione: works for me
[11:11] <fabbione> no replies
[11:11] <fabbione> that was a few days back
[11:11] <fabbione> so my believe is that 1) nobody gives cares 2) nobody is subbed to kernel-team
[11:11] <zul> yeah i been going through the list..just havent responded yet
[11:11] <lamont> fabbione: or still burried
[11:11] <fabbione> jbailey_: patches are always welcome :)
[11:12] <T-Bone> fabbione: i guess i missed it
[11:12] <lamont> probably makes sense to fragment the list into bite-sized pieces and being spamomaticide
[11:12] <fabbione> T-Bone: i tend to agree with you. -dbg should match the stable release
[11:12] <jbailey_> fabbione: No, the question is whether it should happen that way.  I already have patches to make it work. =)
[11:12] <fabbione> but i also understand dilinger point
[11:13] <T-Bone> so do i
[11:13] <fabbione> jbailey_: i think we can discuss it on kernel-team ml
[11:13] <jbailey_> fabbione: 'kay.
[11:13] <T-Bone> s/;o(/;o)/
[11:13] <dilinger> fabbione: has no one sent mail to k-t in the past few days?
[11:13] <fabbione> jbailey_: i don't know enough about it to be able to open a full discuss now
[11:14] <fabbione> dilinger: the last mail was from lamont
[11:14] <dilinger> the gmane list still hasn't been created, despite the email i got on sunday or so saying it would be created as soon as a message was sent to the lis
[11:14] <dilinger> t
[11:14] <dilinger> fabbione: when was that
[11:14] <fabbione> call for this meeting
[11:14] <fabbione> 23-03
[11:14] <dilinger> ok, it was definitely after that.  someone should send something ;)
[11:15] <fabbione> it looks to me we all agree we need some kind of -dbg flavour, one way or another integrated in -bk or -dbg
[11:15] <fabbione> anything else from point 2)?
[11:15] <fabbione> 3
[11:15] <fabbione> 2
[11:15] <fabbione> 1
[11:15] <fabbione> ok
[11:15] <fabbione> point 2 is closed :)
[11:16] <T-Bone> :)
[11:16] <fabbione> is there any other business that we should discuss today?
[11:16] <fabbione> (note: my wife is already snoring.. so i have all night)
[11:17] <T-Bone> lol
[11:17] <Simira> fabbione: hey, I'm home alone and lonely! Be done!
[11:17] <fabbione> Mithrandir: yes i got them :)
[11:17] <Mithrandir> fabbione: ok, so just accepted without further comment, then?
[11:18] <fabbione> i agree on the linux-source meta package. that is easy 
[11:18] <fabbione> Mithrandir: if you have some kind of solution for the second point about throwing up warnings, perhaps it can be integrated with t-bone idea of yelling at the user, when installing -bk packages
[11:18] <Mithrandir> the latter should be fairly easy too, but might need some changes in the notification tool so you have a way for it to only be displayed if "this will be the next default kernel and doesn't match the running kernel".
[11:19] <zul> debconf message or something 
[11:19] <fabbione> Mithrandir: that sounds more an ABI change notification
[11:19] <fabbione> screw debconf to death
[11:19] <Mithrandir> zul: no, not debconf, 
[11:19] <fabbione> no debconf will ever enter in the kernel package
[11:19] <Mithrandir> http://www.ubuntulinux.org/wiki/InteractiveUpgradeHooks
[11:19] <lamont> Mithrandir: that notification stuff
[11:20] <Mithrandir> that can do it, but it might need some changes.
[11:20] <lamont> Mithrandir: yeah - taht
[11:20] <dilinger> fabbione: heh, isn't manoj planning on adding debconf to kernel-package?
[11:20] <T-Bone> he's mad
[11:20] <T-Bone> he needs fixture ;}
[11:20] <fabbione> dilinger: at that point i will just write my own kernel-package :)
[11:20] <Mithrandir> an "be annoying" option; I tend to not see notification icon and a command which should be run to see whether the notification should be displayed.
[11:21] <zul> Mithrandir: electric shocks :0
[11:21] <fabbione> zul ++
[11:21] <Mithrandir> zul: that's a bit extreme. ;)
[11:21] <zul> nah..:)
[11:22] <zul> next..
[11:23] <fabbione> ok
[11:23] <fabbione> it seems nobody have any other business
[11:23] <fabbione> lamont: are you going to send a mail to kernel-team?
[11:24] <zul> wait...one more...after breezy is released what is going to happen to all of those open bugs?
[11:24] <T-Bone> zul: they will all be magically closed ;)
[11:24] <fabbione> zul: we will need to keep checking them
[11:24] <fabbione> like we do now
[11:24] <lamont> fabbione: sure - I'll split the list from the wiki up into bite sized pieces and play spaminator
[11:24] <zul> ok got it
[11:24] <fabbione> lamont: ok
[11:25] <fabbione> anything more?
[11:25] <fabbione> 3
[11:25] <fabbione> 1
[11:25] <fabbione> ok
[11:25] <fabbione> meeting is closed
[11:25] <lamont> fabbione: you forgot 2
[11:25] <fabbione> thanks everybody
[11:25] <fabbione> lamont: i know :)
[11:25] <zul> lamont: it was hex ;)
[11:25] <fabbione> it was to type faster
[11:26] <fabbione> cya everybody and have a good<whatever_is_in_your_tz>
[11:26] <T-Bone> thx, cya
[11:26] <jbailey_> =)
[11:26] <zul> wohoo...i can go home...sortof