[09:47] <brendand> henrix - hi, i just noticed the lucid kernel has been verified
[09:48] <henrix> brendand: yep, there were only 3 commits to be verified
[09:48] <henrix> brendand: so, it was fast :)
[09:51] <brendand> henrix, can we leave it to our discretion whether to do the testing before or after UDS?
[09:53] <henrix> brendand: i believe you can start whenever you're ready. my understanding is that this cycle will have 4 weeks anyway, but the soon we finish the better i guess :)
[09:55] <brendand> henrix, sure. it will be done by the end of the cyle for sure, we may even do it this week - bandwidth permitting
[09:55] <brendand> henrix, we'll see
[09:56] <henrix> brendand: ok, cool. it's likely that we'll have oneiric ready as well (2 bugs to go)
[09:56] <brendand> henrix, tehcnically speaking we can even do the testing during UDS :)
[09:56] <cking> isn't it all automated?
[09:56] <brendand> henrix, we're not certification testing oneiric anymore
[09:57] <henrix> brendand: oh, right!
[09:57] <brendand> cking, how we wish :)
[09:57] <brendand> cking, the tests are all automated, indeed
[09:58] <cking> so what isn't automated?
[09:59] <brendand> cking, in the best case there's still the subject of laptops not power-cycling automatically
[09:59] <brendand> cking, there are also invariably various gremlins that need attention
[09:59] <cking> :-/
[10:00] <brendand> cking, if only every system supported WoL!
[10:00] <brendand> or similar
[11:05]  * ppisati -> out for lunch
[11:33]  * henrix -> lunch
[13:06] <herton> apw, do you have access to pre-proposed ppa? builds there are failing because of lack of space
[13:07] <apw> herton, shuould have i guess
[13:07] <herton> not sure if needs cleanup or just increase the ppa size, the natty builds looks to be something that can be cleaned
[13:08] <herton> *natty and maverick
[13:12]  * smb kindly asks the person standing on gomeisa's network cable to step aside... 155KB/s.... yawn...
[13:13] <apw> herton, seems i can clean it out and am doing so, however we really should move this PPA so anyone in our team can clean it
[13:14] <herton> apw, thanks, yep that would be great if we can do
[13:15] <apw> herton, do you know of anyone who uses that PPA for anything, other than us really looking at the builds for failures ?
[13:16] <herton> apw, I got a complaining of an user in one of the stable tracking bugs that the latest precise kernel in pre-proposed didn't had the 3.2.32 update yet, so I think there is people using it
[13:30] <apw> herton, they are mad as spoons
[13:31] <apw> herton, ok i've cleaned it out and rerun lucid, precise, and fixed up quantal; they should start building shortly
[13:33] <apw> herton, that reminds me, you h
[13:33] <herton> apw, cool thanks. yeah, hope they are using only for testing it :)
[13:33] <apw> you have  branch for mainline something something, is that avilaable somewhere ?
[13:33] <herton> apw, you mean the pre-stable builds?
[13:34] <apw> i do indeed
[13:34] <herton> apw, git://kernel.ubuntu.com/herton/linux-stable.git
[13:36] <herton> I push to the linux-* branches, and create prestable-* tags, the tree tracks linus master
[13:38] <apw> herton, ok so those are the 'results' of your stuff right ?
[13:39] <apw> herton, where can i find the mainline build changes you needed
[13:39] <herton> apw, yes, the kernel builds are done from the prestable-* tags. As there is no tag upstream for it, I have to tag manually to trigger the build
[13:39] <herton> apw, git://kernel.ubuntu.com/herton/kteam-tools.git prestable-build
[13:39] <apw> herton, ok so the process is you slurp up the emails, you push them there, and then the automation makes them
[13:40] <herton> apw, correct
[13:44] <apw> herton, is this branch once applied "just" doing prestable ?
[13:46] <herton> apw, yes, I created a separate directory in the tree, prestable-build, and it does just the prestable build, as I'm running this as my user for the moment
[13:47] <apw> herton, ok so how do those branches differ from the mainline tips, as far as i am concerned /
[13:47] <apw> ?
[13:47] <apw> herton, as in given you are making those branches, why can i not just build the tips of them as we do the drm-next for example
[13:49] <herton> apw, the difference is the tagging, as I'm who pushes the stuff, the different repo, I also build the arm flavours for build testing, these are the main differences
[13:50] <apw> herton, ok ta, will have a look
[13:52] <herton> apw, also the version numbering is different, I produce packages with rc number on it on the ABI part, and keep the latest 10 builds for each stable upstream version (http://kernel.ubuntu.com/~herton/prestable/ where packages land)
[13:52] <apw> herton, that sounds  like the current crack builds though
[13:53] <apw> herton, i am wondering if much new is actually needed if we treat them as crack daily builds
[13:54] <herton> apw, yep. I didn't want to keep the kernels forever, as this is just used for testing, mainline builds already have the needed history
[13:55] <apw> herton, as in do you even need to bother tagging them if we just build the tips of the .y branches daily if changed
[13:55] <herton> apw, it only differs from crack daily builds where I keep main kernel versions, that is, I keep latest 10 3.2 kernels, 10 2.6.32 kernels, etc.
[13:55] <apw> you pick up the patches and shove them on
[13:55] <herton> yes
[13:55] <apw> herton, right so if i added each of your stable branches as a crack build
[13:56] <apw> would that not basically do the same (other than needing to build arm)
[13:56] <apw> ie you would push patches as you find them, don't bother even tagging the tips, just push the patches
[13:57] <herton> apw, the problem is that the kernel history is not linear, sometimes the tag is for a 3.2 kernel, sometimes is for a 3.0, so it's slightly different from cod build of a branch
[13:57] <apw> then the current stuff could pick up the tip every day and make it if changed, keeping the last 10
[13:57] <apw> herton, you have separate branches for each release right ?
[13:58] <herton> apw, yes, I guess you could do a cod of each branch
[13:58] <apw> that was what i was wondering, would that not be basically the same
[13:59] <herton> true, it's that I used the mainline build scripts which uses the tags, but treating them as cod should do it I think
[14:00] <apw> herton, i am wondering if the tags do anything for you other than being a sync point for the checks
[14:01] <apw> herton, would it make sense for me to pick a random one of these branches and add it (without stopping your bits) and see how it pans out
[14:01] <apw> herton, so that when we get to UDS we can see what it did ?
[14:02] <herton> apw, let me take a look again at the script
[14:02] <apw> obvsioly it is not going to make arm right now, and we'd need some way to ask for that
[14:02] <apw> but from a 'does it produce the builds i need' point of view
[14:05] <apw> herton, gah aminline builds are a bit of a house of cards arn't they
[14:05] <herton> apw, yes, should work ok. Also the versioning will not be correct, though we can fix later in mainline-build-one, or I can change it in the Makefile before commiting the branch
[14:05] <herton> apw, yes hehe :)
[14:06] <apw> herton, whats up with the versioning, so i can think about it
[14:07] <herton> apw, I just commit the patches without bumping the version in the Makefile. so lets say for 3.0.12 stable update in review, it still have 3.0.11 version
[14:07] <herton> minor issue
[14:07] <apw> because the version bump is the last patch which you don't get
[14:07] <herton> yep
[14:08] <apw> makes sense
[14:08] <cking> smb, I'm seeing really poor rx rates from gomeisa too
[14:09] <smb> cking, Luckily I am done with it for the moment. So at least its not me that causes it for you now
[14:13]  * cking notes that caffine stimulants and pain killers don't do the head any good
[14:20] <apw> cking, go away
[14:21] <bjf> apw, that's hostile
[14:21] <bjf> :-)
[14:21] <ogasawara> go away, please :)
[14:21] <apw> bjf, good point
[14:21] <apw> cking, you are not welcome, thank you :)
[14:22]  * cking gets the point
[14:22] <cking> i'll take a break for sure
[14:23] <bjf> cking, we'll see you at uds :-)
[14:34] <apw> bjf, i hope not
[14:36] <apw> herton, soooo, do you want to be able to use tags, or would you prefer not
[14:37] <herton> apw, no, just try to add as a cod build as you said, and we can sort it out what's missing
[14:40] <apw> herton, ack
[15:12] <ogasawara> sconklin: just fyi, I've renamed your kernel-r-cve-process-review blueprint to hardware-r-cve-process-review so it gets slotted in the right track and autoscheduled
[15:13] <sconklin> ogasawara: ok, I think that the reasons for wanting that have largely vanished as far as I'm concerned, it's likely to not yield any action items. Do you want to cancel it?
[15:13] <ogasawara> sconklin: sure
[15:30] <apw> sconklin, ok ... those fixes to the matrix have flowed through, looking much better
[15:30] <sconklin> ack
[15:30] <apw> sconklin, once natty goes we'll have a nice view
[15:35] <jsalisbury> rtg,  thanks for taking care of bug 1047527 .  I just finished building a test kernel with CONFIG_USB_OTG disabled if you want me to post it ?
[15:35] <ubot2> Launchpad bug 1047527 in linux (Ubuntu Quantal) "12d1:1038 Dual-Role OTG device on non-HNP port - unable to enumerate USB device on port 1" [Undecided,In progress] https://launchpad.net/bugs/1047527
[15:38] <rtg_> jsalisbury, I think that isn't necessary. I checked that the configs are identical to Precise
[15:51] <herton> rtg, I think you missed to push latest precise master-next with that bluetooth firmware changes, can't find the commits applied
[15:56] <rtg_> herton, done
[15:56] <herton> ack thanks
[15:56] <ogasawara> bryce: heya, I was thinking we should have a session/blueprint at UDS just to resync about 12.04.2 and the 12.10 enablement stack.  I was gonna open a bp and get it scheduled, just wanted to make sure your team hadn't already done so.
[15:57] <rtg_> herton, sounds like there are a couple more patches, right ?
[15:58] <herton> rtg_, yes, Jesse posted two more
[15:58] <rtg_> herton, I'll go ahead and apply them as well.
[16:00] <rtg_> and I'm gonna stick bjf's ACK on 'em cause they are all part of the same batch of patches
[16:01] <bjf> ack ack ack  some free ack's which rtg is free to use as he sees fit
[16:01] <rtg_> bjf, now you sound like that  martian movie
[16:02]  * smb hopes there will be no music on mumble for that
[16:46] <apw> herton, ok its got all the limitations we talked abuot, but its building something at least: http://kernel.ubuntu.com/~kernel-ppa/mainline/prestable/
[16:46] <apw> i'lll look at pulling in the flavours stuff later
[16:48] <herton> apw, yeah, needs tuning but looks ok
[16:49] <apw> herton, yep, its clearly a half-assed attempt, but i'll poke it some more
[16:49] <apw> i wanted to get it building something, more so we could see if it reacted as you needed
[16:49] <apw> as you generate new bits, and lessa bout what it produces
[16:50] <apw> herton, so you are making this repo out of your incoming email, by hand I guess yes ?
[16:51] <herton> apw, yes, I apply by hand. Sometimes I can get from the stable queues, but it's not reliable always
[16:51] <apw> it is annoying those queues aren't always up to date, as making the branches from them would be easy to script
[16:51] <herton> yep
[16:51] <apw> we should be pushing them to make sure they do that
[17:20]  * ppisati -> EOD
[17:33]  * rtg_ -> lunch
[17:34] <bryce> ogasawara, go for it, we haven't made one
[17:35] <ogasawara> bryce: ack
[17:46]  * smb ->EOD
[17:53]  * henrix -> EOD
[18:02] <apw> herton, are we really still releasing stable updates for 2.6.34, unexpected
[18:03] <herton> apw, I think it is still maintained, by Paul Gortmaker, I think last release was 1/2 months ago
[18:04] <apw> herton, just supprised to see us building something against maverick configs :)
[18:28] <rtg_> bjf, http://comments.gmane.org/gmane.linux.kernel/1379326
[18:31] <rtg_> one of the guys complaining has the same Lenovo x121e as me.
[22:27] <apw> herton, bjf, it seems shankbot didn't make a prepare-meta task for my linux-lowlatency ... bug ?
[22:28] <herton> apw, I think it misses a entry in ktl/ubuntu.py, it needs a meta in dependent-packages
[22:28] <bjf> apw, more fallout from it not knowing about your lowlatency kernel. i think the changes that herton has made should do the trick
[22:28] <herton> apw, bjf, I'll check and commit a fix
[22:28] <bjf> herton, thanks much
[22:28] <apw> bjf, i so wish there was some way these 'self' connected ... i realise thats fantasy
[22:28] <apw> herton, thanks a lot, i know i am bending your system
[22:32] <apw> herton, bjf, is there some 'better' way to create these, the issue is that lowlatency depends on master's headers
[22:32] <apw> so we really want the thing to not be promotable to -proposed before master
[22:33] <bjf> apw, we could add that dependency into shankbot but it would be a special case for that package 
[22:34] <herton> yes, would need some more logic into it
[22:34] <apw> bjf, well, it should apply for -ec2 and any other rebase kernel really
[22:34] <bjf> apw, it would be doable to generalize it. we just haven't run into that case before
[22:34] <bjf> apw, yes, i was thinking the same
[22:34] <herton> bjf, apw, fix commited, should create meta task on future lowlatency tracking bugs
[22:35] <herton> actually, with ec2, since the bot create the bug after the master is built, it should be ok
[22:36] <bjf> apw, you also do't want a kernel package to go to -proposed without the accompanying -meta package ready
[22:36] <bjf> herton, apw, uds beer fodder
[22:40] <apw> bjf, it would be nice to make linux and linux-meta go through together, but here i am more interested in saying linux-ec2 must wait for linux
[22:43] <herton> apw, right now the bot opens automatically the tracking bug for ec2 right after linux is built on the ppa, I think that is sufficient
[22:44] <apw> herton, this is not about the making/building part, but about when it is offered for copying
[22:45] <apw> the copying part i would like to have wait for -foo derivatives until you are not respinning master
[22:45] <apw> which is necessary for -lowlatency, and very desirable -ec2
[22:47]  * rtg -> EOD
[22:47] <herton> apw, hmm ok, yeah that would need additional checks in shank bot.
[22:47] <apw> bjf, lets put it on the UDS beer list :)
[23:10] <bjf> apw will do. herton, i agree it would be nice to not set the copy-to-proposed task on lowlatency until the linux kernel has gone to -proposed
[23:11] <herton> bjf, indeed, it's bad having things not installable in -proposed
[23:11] <bjf> herton, and shank-bot isn't _nearly_ complex enough yet
[23:11] <apw> and from a testing point of view it makes sense to hold -ec2 etc as master gets more testing
[23:14] <bjf> herton, apw, agenda updated
[23:15] <herton> thanks, shank bot someday will dominate the world at this rate :P
[23:15] <infinity> bjf: It's not the proposed task that's interesting here (though maybe that's also a valid argument for lowlatency, because of the header deps), but it may be a future consideration that all derivative/rebased kernels shouldn't be promoted to updates/security until master is marked ready.
[23:15] <bjf> infinity, agreed
[23:16] <infinity> bjf: Since, I assume, we do much more rigorous regression testing on master, and if it fails, odds are the bug is everywhere (except in the odd case where it's x86-specific and the derivative/rebase is an ARM kernel, or something)
[23:16] <bjf> infinity, you can bring that to the uds-beer meeting
[23:16] <infinity> bjf: I suspect I'll be at a few of them. ;)
[23:18] <herton> yeah, the promoting to release is more important, I agree any promoting must consider the dependencies
[23:19] <infinity> Well, "dependencies".
[23:19] <infinity> lowlatency is the only one here with an ACTUAL dependency to watch out for.
[23:19] <infinity> The rest, it's just about getting master's testing for "free" for the derivatives.
[23:20] <infinity> Seems unclever to promote, say, armadaxp two days before someone notices a hideous bug in a generic USB driver in master that also affects its rebases.
[23:21] <infinity> (we had a real-world example of this last cycle where we had a hard stop-ship based ona bug found in master, and had to respin all the rebases in a hurry)
[23:21] <infinity> Don't recall what the bug was now.
[23:22] <bjf> ack