=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== dholbach [~daniel@td9091a97.pool.terralink.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== Zotnix [martin@ool-4357361a.dyn.optonline.net] has joined #ubuntu-meeting
=== Zotnix [martin@ool-4357361a.dyn.optonline.net] has left #ubuntu-meeting ["Leaving"]
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has left #ubuntu-meeting []
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== ogra [~ogra@p5089C623.dip.t-dialin.net] has joined #ubuntu-meeting
=== Kamion [~cjwatson@host81-153-126-219.range81-153.btcentralplus.com] has joined #ubuntu-meeting
=== Riddell [~jr@muse.19inch.net] has joined #ubuntu-meeting
=== crimsun [~crimsun@crimsun.silver.supporter.pdpc] has joined #ubuntu-meeting
=== boglot [~logbot@gw.workaround.org] has joined #ubuntu-meeting
=== lamont [~lamont@mix.mmjgroup.com] has joined #ubuntu-meeting
=== dilinger [dilinger@mouth.voxel.net] has joined #ubuntu-meeting
=== ajmitch_ [~ajmitch@port163-60.ubs.maxnet.co.nz] has joined #ubuntu-meeting
=== sabdfl [~mark@host217-37-231-22.in-addr.btopenworld.com] has joined #ubuntu-meeting
=== ajmitch [~ajmitch@port163-60.ubs.maxnet.co.nz] has joined #ubuntu-meeting
=== smurfix [~smurf@smurfix.developer.debian] has joined #ubuntu-meeting
=== Treenaks [martijn@facecrime.net] has joined #ubuntu-meeting
=== haggai [~halls@] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== doko [~doko___@dsl-082-082-198-154.arcor-ip.net] has joined #ubuntu-meeting
=== KragenSitaker [~kragen@66-193-87-113.gen.twtelecom.net] has joined #ubuntu-meeting
=== \sh [~sh@server3.servereyes.de] has joined #ubuntu-meeting
=== asw [~asw@node-423a728a.bos.onnet.us.uu.net] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== doko [~doko___@dsl-084-059-051-040.arcor-ip.net] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has left #ubuntu-meeting []
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has left #ubuntu-meeting []
=== dholbach [~daniel@td9091a97.pool.terralink.de] has joined #ubuntu-meeting
=== jani [~jani@iv.ro] has joined #ubuntu-meeting
=== jani [~jani@iv.ro] has left #ubuntu-meeting []
=== azeem_ [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== Simira [~simira@56.80-202-210.nextgentel.com] has joined #ubuntu-meeting
=== zul [~chuck@] has joined #ubuntu-meeting
=== Simira [~simira@56.80-202-210.nextgentel.com] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has joined #ubuntu-meeting
=== pitti [~martin@box79162.elkhouse.de] has left #ubuntu-meeting []
=== azeem_ [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== koke [~koke@rm-001-26.serve.com] has joined #ubuntu-meeting
=== koke [~koke@rm-001-26.serve.com] has left #ubuntu-meeting ["Abandonando"]
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-meeting
=== azeem_ [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== jalrnc [~joao@ip68-0-220-224.ri.ri.cox.net] has joined #ubuntu-meeting
=== jalrnc [~joao@ip68-0-220-224.ri.ri.cox.net] has left #ubuntu-meeting []
=== T-Bone [varenet@T-Bone.developer.debian] has joined #ubuntu-meeting
=== amu_ [~amu@dump.mediaways.net] has joined #ubuntu-meeting
=== pitti [~pitti@box79162.elkhouse.de] has joined #ubuntu-meeting
=== zul [~chuck@] has joined #ubuntu-meeting
=== maskie [~maskie@196-30-109-43.uudial.uunet.co.za] has joined #ubuntu-meeting
=== azeem_ [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting
=== Seveas [~seveas@seveas.demon.nl] has joined #ubuntu-meeting
=== Alessio [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
=== zul [~chuck@] has joined #ubuntu-meeting
=== mdz [~mdz@ca-studio-bsr1o-251.vnnyca.adelphia.net] has joined #ubuntu-meeting
=== dilinger gets home from the airport just in time
=== zyga [~zyga@87-mia-9.acn.waw.pl] has joined #ubuntu-meeting
fabbionedilinger: ehhe09:52
pittiHi dilinger 09:52
dilingerhi :)09:52
zygapitti: hello :)09:52
=== Amaranth [~travis@amaranth.user] has joined #ubuntu-meeting
=== Alessio [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
lamonthi fabbione 09:54
fabbionehi lamont 09:54
fabbione-5 minutes09:55
fabbioneplenty of time :)09:55
zulhey dilinger 09:56
=== lamont does a server i386 install
lamontT-Bone: perms fixed09:56
T-Bonelamont: thx 09:57
T-Bonelamont: figures are getting nicer ;)09:57
=== helio7 [~michael@wbar21.lax1-] has joined #ubuntu-meeting
fabbioneit's 20:00 UTC09:59
fabbionelet's get started09:59
=== jani [~pet@Home03207.cluj.astral.ro] has joined #ubuntu-meeting
fabbioneeverybody is welcome to partecipate10:00
fabbionebut please stay on-topic10:00
fabbionethe first item on the agenda is:10:00
fabbione"Any remaining post-release-candidate panic items before hoary?"10:00
=== ggi [~ggi@ggi.base.supporter.pdpc] has joined #ubuntu-meeting
fabbionewe are clearly full freeze.10:00
fabbioneand we have one critical bug10:01
fabbionebut nobody has been able to debug/fix it10:01
fabbioneso i guess hoary will have to live with it10:01
zulwhich bug is this?10:01
pittiyou mean CAN-2004-0173?10:01
fabbionezul: it's assigned to me. the one about i386 not booting.10:01
zulah ok10:01
fabbionepitti: no i am coming to that one10:02
pittiokay, because it's mostly academic10:02
fabbioneso the only thing left to do from now until the 6th (last possible date for uploads) is security10:02
fabbionepitti did a very neat job here:10:02
fabbioneout of that list there 2/3 security fixes that would be nice to have, but they are not mandatory for hoary10:03
fabbione+ CAN-2005-107310:03
fabbionepitti: want to explain to the rest of the team?10:03
AmaranthCAN-2004-0173 seems to have something to do with Apache and cygwin?10:03
pittiit's a mostly academic bug10:04
pittiabout reading setuid files which are actually only executable10:04
pittiwe thought that we fixed it ages ago, but unfortunately it's not10:04
pittino patch so far, so we have to wait10:04
fabbioneadn this is common mistake across all distros10:04
fabbioneso it's not only us affected by this problem10:04
pittiyeah, all of them just took the upstream patch10:04
smurfixNobody actually verified whether the patch works?10:05
pittibut since we don't ship any executable-only binaries, and Debian Policy mandates readability anyway,10:05
fabbionesmurfix: it doesn't10:05
pittismurfix: there is no patch10:05
pittisuid binaries from packages are not affected anyway10:05
pittiI will notify you if I have anything new about this issue10:05
smurfixYour statements are mutually exclusive, but OK ;-)10:06
=== kiko [~kiko@200-171-140-32.dsl.telesp.net.br] has joined #ubuntu-meeting
pittismurfix: ?10:06
AmaranthDo you have a URL to where this is descrived?10:06
Amarantherr, described10:06
=== kiko [~kiko@200-171-140-32.dsl.telesp.net.br] has left #ubuntu-meeting ["Left]
fabbionesmurfix: what we believed it was a fix, didn't work10:06
pittismurfix: I mean, we only ship them with read+executable10:06
pittismurfix: we don't ship any only-executable binaries (which are a pretty stupid idea anyway)10:06
smurfixpitti: Yeah, I know, sorry -- I meant: if there's no patch, then this nonexistent patch can't work-or-not-work10:07
fabbioneok somebody needs to go again through pitti's list to double check we did not miss known fixes10:07
fabbionewho voluteers for that?10:07
Amaranthoh, 1073. you said 0173 the first time10:07
=== pitti raises hand
fabbionepitti: ok, that's your.10:08
pittiAmaranth: sorry, 1073, right10:08
pittifabbione: I need to reprocess this list anyway10:08
fabbionepitti: ok perfect.10:08
fabbionesince we are talking about security now10:08
pittifabbione: tomorrow's run will clean it up further, then I look over it again10:08
=== jbailey_ [~jbailey@mail.gbc.ca] has joined #ubuntu-meeting
fabbionepitti, do you want to define any specific procedure for hoary-security kernel uploads??10:08
Amaranthpitti: So it's only a problem if you have an executable binary that isn't readable?10:09
fabbioneAmaranth: correct10:09
pittiAmaranth: yeah, the vuln allows you to read it anyway10:09
=== Amaranth wonders why anyone would do that
pittiI'd like to have one person I can bother with undisclosed stuff10:09
zulAmaranth: safer than sorry10:09
pittifabbione: that would be you, or lamont if you are not available?10:10
pittiother than that I'd like to keep the current practice10:10
fabbionepitti: i think we should be at least 2 and i agree for me10:10
lamontpitti: I'm available10:10
fabbionelamont: ?10:10
pittiI collect information and manage the status and advisories, and you/lamont build the packages10:10
pittiand upload them10:10
pittiis that okay for you?10:10
fabbionepitti: due to the new building system. we need to follow certain procedures too10:11
fabbionepitti: yes.10:11
pittiin particular?10:11
fabbioneit is ok for me10:11
fabbionepitti: we need to test/build the kernel all arches before each upload10:11
fabbioneto verify the ABI integrity10:11
pittiI'd like to introduce a basic testing pattern before an upload happens10:11
fabbioneif the ABI breaks due to a fix10:11
pittiABI> that's great10:11
fabbionewe will need to do more than just one upload10:11
lamontfabbione: either we don't check in the embargoed source changes, or we need an embargoed baz repository (either is doable)10:12
fabbionelamont: i used an embargoed repo for that10:12
fabbionelamont: i simply don't commit the changes to the repo10:12
=== Alessio [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
fabbioneand use my local one for test/build10:12
pittiI think we need to define some testing policy10:13
fabbionemdz, pitti: did we ever agree on how to handle an ABI change for a security fix?10:13
pittiyes, I think so10:13
zuli think the embargoed baz repository is good because if either lamont or fabbione than one of you can get a security fix if its critical10:13
fabbionepitti: sure. what are your reccomendations?10:13
pittithe crucial point is that we pre-add the next ABI number10:13
pittiso that the l-r-m build can see the new kernel in the queue10:13
fabbionepitti: the previous actually :)10:14
dilingeryou guys have the same ABI d-i problems that debian does for security fixes, right?10:14
lamontzul: embargoed repository is trivial for fabbione and I to set up...10:14
lamontjust requires ssh access to the same machine somewhere10:14
fabbionedilinger: yes. that's something we need to discuss at UDU10:14
pittil-r-m must be built against the new kernel, but that isn't in the archive yet10:14
jbailey_fabbione: Isn't it less ugly since we generate the udeb's for the kernel packages directly?10:14
pittibut the buildd can use the pending queue10:14
fabbionejbailey_: yes, but we still need a lot of work for an ABI change10:15
janifabbione which is the 386 not booting critical bug?10:15
dilingerfabbione: ok.  i figured it was the case, but i wasn't positive.10:15
fabbionejani: i don't have it handy.. it has been downgraded to Major, but still pretty sever10:15
janiok I'll search bugzilla10:16
fabbionepitti: i am not really afraid of the build sequence problem10:16
fabbionei am more concern to understand10:16
pittifabbione: that's mostly an elmo-ish problem10:16
fabbionelinux-source -> hoary-security10:16
fabbionel-r-m -> ?10:16
fabbionelinux-meta -> ?10:16
fabbioned-i -> ?10:16
lamontfabbione: the key is that nothing be NEW during the process10: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 security10:17
pittiit's still hoary-security10:17
pittifabbione: the buildd sorts out main/restricted/universe etc.10:17
fabbionelamont: the problem is if a security fix breaks the ABI10:17
pittifabbione: erm, s/buildd/katie/10:17
fabbionelamont: we have seen it in warty and we can expect it for hoary10:18
fabbionelamont: the issue is how do we want to handle all the syncage of the other packages10:18
lamontfabbione: 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
fabbionethe outdated cannot be removed10:18
pittifor Warty, elmo pre-added the next 10 ABI versions10:18
pittiwe should do the same for Hoary10:18
fabbionemake sense10:19
pittimaybe 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 bit10:19
pittito force removal of the old package, is that what you mean?10:19
=== PeG [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
fabbionepitti: there is no point in that. they are 2 different packages and lands in 2 different dirs10:19
=== Alessio [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
lamontfabbione: 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
pittithat's what I mean with the conflict and replace10:20
=== Mithrandir [~tfheen@vawad.err.no] has joined #ubuntu-meeting
pittiso the user won't keep an outdated kernel version around10:20
fabbioneit's dangerous to do that10:21
MithrandirI suck, I forgot about the meeting. :(10:21
fabbionei mean it's the counter side of the coin10:21
pittiyeah, I just wanted to know whether this is the problem you talked about10:21
fabbionewe might end up in removing the running kernel10:21
fabbionethat is really BAD!10:21
pittioh, right10:21
pittiokay, let's forget about this proposal10:21
fabbionewe need to keep the following practise and improve for breezy10:22
fabbionepitti: is there anything else you want us to be ready for security related issues?10:22
fabbionejust to sum up:10:22
Mithrandirfabbione: http://people.ubuntu.com/~fabbione/irclogs/ubuntu-meeting-current.html seems fairly useless ATM; is there a log somewhere?10:22
fabbione1) lamont, fabbione: contact points10:22
fabbione2) pitti sends the patches10:22
fabbione3) 1) gets them, apply/test and upload10:23
fabbioneMithrandir: the log is uploaded every hour10:23
pittire 3) we should coordinate and ack an upload to each other10:23
lamontMithrandir: will spew in private window10:23
pittifabbione: otherwise that's fine10:23
fabbionepitti: ok.10:23
fabbionelamont: does it work for you?10:24
Mithrandirlamont: yes please.10:24
lamontfabbione: sounds good10:24
zulwhat if both of you arent available 10:24
fabbioneis there anything else we need to look into before hoary is out?10:24
pittithen we are doomed :-)10:24
zulok cool :)10:24
Amaranthwhat if pitti isn't available? :)10:24
fabbionezul: pitti will be our backup with the support of the rest of the team :-)10:24
zulok just playing devil's advocat10:25
Mithrandirhas there been any discussions surrounding the problem when resuming and the kernel versions don't match?10:25
fabbioneAmaranth: if pitti is unavaliable we are all r00t3d10:25
pittiI know how to build a kernel and how to do patches10:25
=== Amaranth preemptively (sp?) asks questions
pittibut you guys have far more experience with it10:25
pittiso I only want to do this if it's really necessary10:25
fabbionepitti: in case both lamont and i will be unavailable you can coordinate with zul and dilinger10:25
pittihmm, I plan to go to vacation one week before UDU10:25
pittino security from my side then10:25
pittifabbione: ack10:26
fabbionesince they both know the building system 10:26
=== T-Bone knows it as well ;}
pittiif I'm not available, then mdz is the logical fallback10:26
=== T-Bone ducks
pittimdz is on vendor-sec10:26
fabbionewe are covered for security10:26
fabbionepitti: ack that10:26
fabbionei think we can thanks pitti for the security part10:26
fabbionepitti: you are free from us :)10:26
fabbioneand thanks for coming10:26
pittiand fabbione for his excellent hoary work!10:27
pittino worries :-)10:27
pittifabbione: my gf lays beside me and sleeps...10:27
T-Bonepitti: lucky man ;)10:27
fabbionepitti: eh my wife does too already 10:27
fabbioneBreezy plan10:27
pittibye folks10:27
fabbionecya pitti10:27
=== pitti [~pitti@box79162.elkhouse.de] has left #ubuntu-meeting ["Have]
fabbioneit's up to us how long we want to talk about this10:28
=== Alessio [~Alessio@host146-56.pool80116.interbusiness.it] has joined #ubuntu-meeting
fabbionewe have a very long planned BOF @ UDU10:28
fabbioneis there anybody that wants to discuss any particular topic on the list?10:29
fabbionehttps://www.ubuntulinux.org/wiki/UbuntuDownUnderBOFs <-10:29
zulhold on a sec..its slow10:29
zuloh yes...bk snapshot10:30
fabbionezul: go ahead10:30
zulso the way i have a look at it is that you have a bk snapshot and a stable image correct?10:30
fabbionesomething we tried with 2.6.11 but didn't really work due to time (mainly)10:31
zulso the bk snapshot is going to be apart of main or universe?10:31
zulmotu is not going to like that ;)10:31
fabbionewe really do not want to support bk snapshots10:31
T-Bonefabbione: what's the point of a packaged bk snapshot?10:31
fabbionemotu will have almost nothing to do with it10:31
fabbionewe need to find a way to build them automatically10:31
fabbionealmost on a daily base10:32
fabbioneT-Bone: testing, before backporting fixes10:32
T-Bonefabbione: my understanding is that such snapshots would do nothing but hog builders CPU10:32
Mithrandirwe have enough buildd power, so I wouldn't be too worried about that10:32
fabbioneT-Bone: most of the time we hear: "this is fixed in bk". 10:32
fabbioneso ok.. install that kernel and let us know10:32
T-Bonefabbione: bk snapshots don't represent anything correlating to a "release" or some "known state" of any kind, if i'm right10:32
zulfabbione: 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 it10:32
fabbionezul: i was considering linux-source-bleeding-edge10:33
fabbioneor something like that10:33
T-Bone-rc kernels seem much more meaningful to me10:33
fabbioneit doesn't need to respect ABI or anything10:33
fabbionejust be tehere10:33
zuland if the users try it? say in the bug report that its not supported?10:34
fabbioneT-Bone: bk is like any other revision control system around. it has tags and so on.. we just want to have HEAD10:34
T-Bonethey have known changelogs, represent a known state point, etc10:34
T-Bonefabbione: my point is just that -bk may actually not build more than 20% of the flavours in some case (all archs included)10:34
fabbionezul: we need to ask the users to use a bk kernel on debugging request to verify that a certain bug is fixed upstream or not10:34
fabbionewe don't want a user to run it as normal kernel10:35
T-Bonefabbione: ie, -bk might be *known to be broken*10:35
fabbionethat's why it would be in universe10:35
zulgot it but some users will is my point10:35
fabbioneT-Bone: yes i am aware of that.10:35
lamontjust call it 2.6.11-broken10:35
T-Bonefabbione: as zul said. Something like this shouldn't go in the archive, imho10:35
fabbionezul: that's their problem...10:35
=== zul shrugs
fabbioneno i am serious..10:35
zulno i agree 10:36
dilingerT-Bone: that would be a good thing10:36
T-Bonefabbione: if that's for our own testing usage, we can have it in some other archive, can't we?10:36
T-Bonedilinger: what?10:36
fabbioneif we add a proper description and it is in universe10:36
dilingerT-Bone: it would be an easy way for people working on archs to see that they need to be feeding linus fixes10:36
T-Bonedilinger: true, but that's not our purpose, as i see it10:36
dilingerversus grabbing the latest 2.6.x and realizing, hey, it doesn't build on my arch10:36
fabbioneT-Bone: it can be as side-effect10:36
T-Bonedilinger: besides, most of the time, that kind of patches are already on their way to linus when the bk snapshot is taken10:36
dilingerT-Bone: then it gives them incentive to ensure linus applies it :)10:37
zulfabbione: i agree just make sure the description says something like NOT FOR REGULAR DAY USE or something10:37
T-Bonedilinger: heh. Or gives linus incentive to drop them because he's sent several times the same patch? ;o)10:37
fabbionezul: that is kinda what i meant10:37
zulfabbione: gotcha10:37
dilingerT-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-Bonefabbione, 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-Bonedilinger: that script exist :)10:38
T-Bonedilinger: ask willy ;)10:38
zulT-Bone: that would be fine for me at least description is fine though10:38
fabbioneT-Bone: whatever you have in your mind is fine, just send me the patches :)10:38
T-Bonezul: most users don't read package description when they look for a specific package10:39
T-Bonefabbione: hehe :)10:39
dilingerT-Bone: i'm not sure if it's clear, but i would recommend it only does it on fresh installs10:39
T-Bonedilinger: true10:39
dilingerT-Bone: if upgrading a bleeding edge kernel, it shouldn't prompt the user10:39
zuljust send a shock when they install it :)10:39
T-Bonedilinger: got that10:39
fabbioneok so i think we all agree that having a bk snapshot around is good10:40
zuli guess we'll see how it goes :)10:40
fabbionethe main issue is having it "naked" or "full-feature"10:40
T-Bonei didn't say i think it's good, but I understand the points that have been raised pro such a package :)10:40
zuli would say the same features we have on our own kernels10:41
T-Bonemy personnal feeling would have been to use -rc kernels10:41
fabbionezul: most of the patches will start not to apply to a bk snapshot10:41
dilingerfabbione: the obvious benefit of full-feature is that we can see when rarely-used drivers break.  of course, that'll increase FTBFSs10:41
fabbioneor not to compile10:41
fabbionedilinger: exactly, and maintaince of these patches in a bk snapshot env is extremely time consuming10:42
zulfabbione: i mean the same options that we have minus third party drivers10:42
zulie ipw2200 et al10:42
fabbionezul: dilinger has a point10:42
T-Bonefabbione: and pointless, since a snapshot is "moving" by essence10:42
fabbioneT-Bone: it's not pointless10:42
fabbionesince at a certain point that bk snapshot will be released as 2.6.X10:43
fabbioneand you have the patches already rediffed for it10:43
T-Bonefabbione: not absolutely piontless, i understand that, since you prepare what will be needed for the next release,10:43
fabbionein a RCS10:43
fabbioneright now preparing a new upstream release takes me approx 2 days of work10:43
fabbione1 to scream the patches10:43
T-Bonestill, 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 stabiliziing10:43
fabbione2 to make it build on 3 arches10:43
T-Bonehence my opinion that we should use -rc10:44
T-Bonefabbione: ^^^10:44
fabbioneyes i understand10:44
fabbioneok since we have several options, we will need to evaluate which one works better10:44
T-Bonefabbione: what you plan to do would (imho) be best achieved using -rc kernels10:45
=== helio7 [~michael@wbar21.lax1-] has left #ubuntu-meeting []
zulor if you want to release a snapshot monitor lkml for one or 2 days and then move to a new snapshot10:45
fabbionewe can also have bk on a weekly base10:45
T-Bonefabbione: i'm saying that to spare you the overhead of dealing with moving -bk, mind you.10:45
fabbioneit doesn't need to be daily10:46
T-Bonefabbione: i think that your goal is smoother and faster kernel transitions. Using -bk *might* end up to the exact opposite10:46
dilingeri think bk on a weekly basis is a nice compromise10:46
zuli agree10:46
T-Bonethis would probably be better, but this wouldn't solve the issues i've raised10:46
smurfixI think so too. Minimally we should do -rc10:47
T-Bonegiven that you might *fall* on that particular -bk snapshot that will be completely reverted/changed/corrected 2h later10:47
fabbioneT-Bone: that can happen always10:47
T-Bonegiven fabbione's needs, -rc seem to fit the prerequisites better10:47
dilingerT-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 that10:48
=== fabbione points T-Bone to 2.4.11 announcment
T-Bone(that's the analyst speaking ;)10:48
fabbionegiven fabbione's needs <- kernel team10:48
T-Bonedilinger: 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
zulwell if the workload is a problem then split it up10:48
fabbioneit's not only me10:48
T-Bonefabbione: 2.4.11? That was ages ago. Things have (hopefully) changed a bit :)10:49
T-Bonefabbione: i understand, and i also speak in the interest of the team (or so i hope) :)10:49
fabbioneT-Bone: stuff like that still happens... see 2.4.15 ? from Marcello?10:49
zuler...a bit offtopic10:50
fabbionewe need some kind of snapshotting...10:50
T-Boneseems mostly irrelevant to me10:50
T-Boneright. My 2 cents is "use -rc". 'nuff said ;)10:50
fabbionewho would like to start looking at it?10:50
fabbioneeven just a simple analysis of pro and cons10:51
fabbionethat we will bring up @ UDU again10:51
=== zul raises his hand..
dilingerwell, 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
fabbionezul: ok, it's your10:52
fabbionerc happens too slowly imho to be used for this kind of test10:52
zulone more from the wiki :)10:52
fabbionenothing ensures that we will get an rc in the 3 months of breezy development10:53
fabbionezul: ok.. go ahead (again)10:53
T-Bonefabbione: question is "do we need to go faster than -rc to speed up our own transition?"10:53
zul Broader time-based community kernel tree10:53
fabbioneT-Bone: we need to be faster than rc in backporting bug fixes.10:53
T-Bonefair enough10:54
fabbionezul: i think mdz added that one10:54
zulah ok..10:54
fabbionelet's ask him10:54
mdzthat's a sabdfl thing10:54
fabbionedo you know what he means exactly?10:54
dilingermaybe he means something like -as?  or more in line w/ ubuntu, fixes + acpi +..?10:55
fabbionei think sabdfl is not around10:55
fabbionezul: sorry, but i don't have a clear answer for that10:55
zulfabbione: no probs...ill shut up now with the wiki stuff :)10:56
fabbioneok last call for item 2) in the agenda10:56
fabbioneanybody else wants to discuss any of the points in the wiki?10:56
T-BoneBuild fewer flavours10:56
zulother than me10:56
fabbioneall that stuff will mostlikely be part of breezy10:57
fabbioneT-Bone: go ahead10:57
fabbione(mdz is here.. so he can answer that ;))10:57
T-Bonehehe, well, what's the idea behind that point?10:57
T-Bonei mean, what kind of "flavours" would be candidate for removal?10:58
mdzI'm in another meeting right now, so please ask direct questions if you need answers10:58
lamontT-Bone: if 686-smp is not significantly slower than 686, why build both?10:58
lamontfor example.10:58
T-Bonelamont: ok, so that's a "smp vs up" thing?10:59
fabbioneT-Bone: not only10:59
fabbioneif 686 can boot k7.. why do we build k7?10:59
fabbioneit's a global cleanup of flavours10:59
T-Bonemy 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 thing11:00
=== lamont expects that most of the k7/686 differences in the kernel are invisible to the end users... ABX time, eh?
T-Bonegiving a precise example:11:00
T-Boneall pmacs can run ppc601 code,11:00
T-Bonebut not running an altivec enabled kernel on an altivec machine is quite a loss11:00
=== dilinger agrees w/ lamont, and actually runs 686 kernels on an amd machine currently
fabbioneT-Bone: the point is more like: what happen if i enable altivec on a non-altivec machine?11:01
T-Boneit doesn't work11:01
fabbioneperfect, than you need 2 flavours11:01
T-Boneno it does11:02
T-Bonemy example was bad11:02
fabbionethan one flavour is enough11:02
jbailey_You should get SIGILLs for altivec on a non-capable machine.11:02
lamontT-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't11:02
T-Bonethat's fine by me, let's drop that now, it can be clarified later,11:03
lamontABX: I give you A and B and some unknown.  Tell me which it is.11:03
T-Bonebut in regard to what was said (fewer flavours):11:03
T-BoneAdd a -dbg flavour? or enanche the kernel debugging.11:03
T-Bonethat doesn't seem to make much sense to me11:03
fabbioneT-Bone: -dbg is not a flavour11:03
=== lamont notes that, like many feature laundry lists, this one has some internal conflict
T-Bonelamont: hehe ;)11:03
fabbioneflavours are 386, 686, k7 and so on11:03
fabbioneeach of them adds a config and complexity for the user11:04
fabbionea -debug is probably less confusing than 383/68611:04
T-Bonei disagree11:04
T-Bonesome users are confused by -smp11:04
lamontesp since 386 doesn't run on 386 machines, I expect. :-)11:04
fabbionelamont: nope.. minimum is 48611:05
=== T-Bone remembers he needs to update the desc on 2.4 hppa kernels, has a bugreport for that
T-Bonefabbione: what would be the point of a -dbg kernel?11:05
lamontT-Bone: debugging, of course.11:05
T-Bonefabbione: asking the user to install it in case of a problem?11:05
fabbioneT-Bone: the answer is embedded in the question11:06
fabbioneT-Bone: exactly11:06
T-Bonefabbione: i *mean* the question11:06
T-Bonemakes sense11:06
T-Bonei'm done with questions11:06
fabbionethere are tons of debugging features we do not build11:06
zulim for less flavours11:06
dilingerhow many users are actually going to make use of -dbh?11:06
dilingerer, -dbg11:06
fabbionesimply because they slowdown the machine to death11:06
T-Bonedilinger: none unless we ask them11:07
T-Bonebesides, none of those using it will be able to decypher the debug output11:07
fabbionedilinger: these packages will still land in universe11:07
dilingerso, why not have debugging enabled on everything in the -bk or -rc kernels?11:07
T-Bonethat has to be kept in mind11:07
dilingerif a user has a problem, ask them to try a -bk kernel11:07
dilingerif it still happens, you'll have lots of debugging info from that11:07
fabbionedilinger: right...11:07
lamontis this really the time to be having the BOF?11:07
T-Bonethat doesn't work for QA releases11:08
lamontor just to be adding things to the list for the BOF?11:08
fabbionelamont: it's just discussing a few points that people feel more sensible about11:08
fabbionesince not all the team will be at UDU11:08
=== T-Bone won't be attending the BOF, dropping ideas...
T-Bonelamont: as fabbione just said :)11:08
lamontjust wanted to throw that process-check in there11:09
fabbioneoky doky11:09
T-Bonemy 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 release11:09
fabbioneis there any other item that we should discuss here?11:09
MithrandirI 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:09
lamontobviously, 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 UDU11:10
T-Bonelamont: definitely11:10
Mithrandirespecially the latter is _painful_ for laptops where you suspend to disk. :)11:10
fabbionelamont: that's exactly what i was going to ask you to do :)11:10
=== Amaranth [~travis@amaranth.user] has left #ubuntu-meeting ["If]
jbailey_fabbione: At some point we should figure out if initramfs generation should be integrated with kernel builds.11:10
fabbione.i did send the email to kernel-team11:11
lamontfabbione: works for me11:11
fabbioneno replies11:11
fabbionethat was a few days back11:11
fabbioneso my believe is that 1) nobody gives cares 2) nobody is subbed to kernel-team11:11
zulyeah i been going through the list..just havent responded yet11:11
lamontfabbione: or still burried11:11
fabbionejbailey_: patches are always welcome :)11:11
T-Bonefabbione: i guess i missed it11:12
lamontprobably makes sense to fragment the list into bite-sized pieces and being spamomaticide11:12
fabbioneT-Bone: i tend to agree with you. -dbg should match the stable release11:12
jbailey_fabbione: No, the question is whether it should happen that way.  I already have patches to make it work. =)11:12
fabbionebut i also understand dilinger point11:12
T-Boneso do i11:13
fabbionejbailey_: i think we can discuss it on kernel-team ml11:13
jbailey_fabbione: 'kay.11:13
=== T-Bone usually understands most of the points he's contradicting with ;o(
dilingerfabbione: has no one sent mail to k-t in the past few days?11:13
fabbionejbailey_: i don't know enough about it to be able to open a full discuss now11:13
fabbionedilinger: the last mail was from lamont11:14
dilingerthe 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 lis11:14
dilingerfabbione: when was that11:14
fabbionecall for this meeting11:14
dilingerok, it was definitely after that.  someone should send something ;)11:14
fabbioneit looks to me we all agree we need some kind of -dbg flavour, one way or another integrated in -bk or -dbg11:15
fabbioneanything else from point 2)?11:15
fabbionepoint 2 is closed :)11:15
fabbioneis there any other business that we should discuss today?11:16
fabbione(note: my wife is already snoring.. so i have all night)11:16
Simirafabbione: hey, I'm home alone and lonely! Be done!11:17
=== Mithrandir wonders if his two points drowned or if he is being ignored. :/
fabbioneMithrandir: yes i got them :)11:17
=== T-Bone agrees with Mithrandir suggestions
Mithrandirfabbione: ok, so just accepted without further comment, then?11:17
fabbionei agree on the linux-source meta package. that is easy 11:18
fabbioneMithrandir: 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 packages11:18
Mithrandirthe 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:18
zuldebconf message or something 11:19
fabbioneMithrandir: that sounds more an ABI change notification11:19
fabbionescrew debconf to death11:19
Mithrandirzul: no, not debconf, 11:19
fabbioneno debconf will ever enter in the kernel package11:19
lamontMithrandir: that notification stuff11:19
Mithrandirthat can do it, but it might need some changes.11:20
lamontMithrandir: yeah - taht11:20
dilingerfabbione: heh, isn't manoj planning on adding debconf to kernel-package?11:20
T-Bonehe's mad11:20
T-Bonehe needs fixture ;}11:20
fabbionedilinger: at that point i will just write my own kernel-package :)11:20
Mithrandiran "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:20
zulMithrandir: electric shocks :011:21
fabbionezul ++11:21
Mithrandirzul: that's a bit extreme. ;)11:21
fabbioneit seems nobody have any other business11:23
fabbionelamont: are you going to send a mail to kernel-team?11:23
zulwait...one more...after breezy is released what is going to happen to all of those open bugs?11:24
T-Bonezul: they will all be magically closed ;)11:24
fabbionezul: we will need to keep checking them11:24
fabbionelike we do now11:24
lamontfabbione: sure - I'll split the list from the wiki up into bite sized pieces and play spaminator11:24
zulok got it11:24
fabbionelamont: ok11:24
fabbioneanything more?11:25
fabbionemeeting is closed11:25
lamontfabbione: you forgot 211:25
fabbionethanks everybody11:25
fabbionelamont: i know :)11:25
zullamont: it was hex ;)11:25
fabbioneit was to type faster11:25
fabbionecya everybody and have a good<whatever_is_in_your_tz>11:26
T-Bonethx, cya11:26
=== Mithrandir runs off
zulwohoo...i can go home...sortof11:26
=== jani [~pet@Home03207.cluj.astral.ro] has left #ubuntu-meeting []
=== T-Bone [varenet@T-Bone.developer.debian] has left #ubuntu-meeting ["Leaving"]
=== dilinger [dilinger@mouth.voxel.net] has left #ubuntu-meeting ["Leaving"]
=== azeem [~mbanck@socks-out.lrz-muenchen.de] has joined #ubuntu-meeting

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