=== smb` is now known as smb [09:47] henrix - hi, i just noticed the lucid kernel has been verified [09:48] brendand: yep, there were only 3 commits to be verified [09:48] brendand: so, it was fast :) [09:51] henrix, can we leave it to our discretion whether to do the testing before or after UDS? [09:53] 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] 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] henrix, we'll see [09:56] brendand: ok, cool. it's likely that we'll have oneiric ready as well (2 bugs to go) [09:56] henrix, tehcnically speaking we can even do the testing during UDS :) [09:56] isn't it all automated? [09:56] henrix, we're not certification testing oneiric anymore [09:57] brendand: oh, right! [09:57] cking, how we wish :) [09:57] cking, the tests are all automated, indeed [09:58] so what isn't automated? [09:59] cking, in the best case there's still the subject of laptops not power-cycling automatically [09:59] cking, there are also invariably various gremlins that need attention [09:59] :-/ [10:00] cking, if only every system supported WoL! [10:00] or similar === henrix_ is now known as henrix === henrix_ is now known as henrix === henrix_ is now known as henrix [11:05] * ppisati -> out for lunch [11:33] * henrix -> lunch === yofel_ is now known as yofel [13:06] apw, do you have access to pre-proposed ppa? builds there are failing because of lack of space [13:07] herton, shuould have i guess [13:07] not sure if needs cleanup or just increase the ppa size, the natty builds looks to be something that can be cleaned [13:08] *natty and maverick [13:12] * smb kindly asks the person standing on gomeisa's network cable to step aside... 155KB/s.... yawn... [13:13] 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] apw, thanks, yep that would be great if we can do [13:15] herton, do you know of anyone who uses that PPA for anything, other than us really looking at the builds for failures ? [13:16] 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] herton, they are mad as spoons [13:31] herton, ok i've cleaned it out and rerun lucid, precise, and fixed up quantal; they should start building shortly [13:33] herton, that reminds me, you h [13:33] apw, cool thanks. yeah, hope they are using only for testing it :) [13:33] you have branch for mainline something something, is that avilaable somewhere ? [13:33] apw, you mean the pre-stable builds? [13:34] i do indeed [13:34] apw, git://kernel.ubuntu.com/herton/linux-stable.git [13:36] I push to the linux-* branches, and create prestable-* tags, the tree tracks linus master [13:38] herton, ok so those are the 'results' of your stuff right ? [13:39] herton, where can i find the mainline build changes you needed [13:39] 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] apw, git://kernel.ubuntu.com/herton/kteam-tools.git prestable-build [13:39] herton, ok so the process is you slurp up the emails, you push them there, and then the automation makes them [13:40] apw, correct [13:44] herton, is this branch once applied "just" doing prestable ? [13:46] 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] herton, ok so how do those branches differ from the mainline tips, as far as i am concerned / [13:47] ? [13:47] 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] 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] herton, ok ta, will have a look [13:52] 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] herton, that sounds like the current crack builds though [13:53] herton, i am wondering if much new is actually needed if we treat them as crack daily builds [13:54] 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] 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] 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] you pick up the patches and shove them on [13:55] yes [13:55] herton, right so if i added each of your stable branches as a crack build [13:56] would that not basically do the same (other than needing to build arm) [13:56] ie you would push patches as you find them, don't bother even tagging the tips, just push the patches [13:57] 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] then the current stuff could pick up the tip every day and make it if changed, keeping the last 10 [13:57] herton, you have separate branches for each release right ? [13:58] apw, yes, I guess you could do a cod of each branch [13:58] that was what i was wondering, would that not be basically the same [13:59] 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] herton, i am wondering if the tags do anything for you other than being a sync point for the checks [14:01] 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] herton, so that when we get to UDS we can see what it did ? [14:02] apw, let me take a look again at the script [14:02] obvsioly it is not going to make arm right now, and we'd need some way to ask for that [14:02] but from a 'does it produce the builds i need' point of view [14:05] herton, gah aminline builds are a bit of a house of cards arn't they [14:05] 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] apw, yes hehe :) [14:06] herton, whats up with the versioning, so i can think about it [14:07] 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] minor issue [14:07] because the version bump is the last patch which you don't get [14:07] yep [14:08] makes sense [14:08] smb, I'm seeing really poor rx rates from gomeisa too [14:09] 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] cking, go away [14:21] apw, that's hostile [14:21] :-) [14:21] go away, please :) [14:21] bjf, good point [14:21] cking, you are not welcome, thank you :) [14:22] * cking gets the point [14:22] i'll take a break for sure [14:23] cking, we'll see you at uds :-) [14:34] bjf, i hope not [14:36] herton, soooo, do you want to be able to use tags, or would you prefer not [14:37] apw, no, just try to add as a cod build as you said, and we can sort it out what's missing [14:40] herton, ack === e11bits_ is now known as e11bits [15:12] 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] 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] sconklin: sure [15:30] sconklin, ok ... those fixes to the matrix have flowed through, looking much better [15:30] ack [15:30] sconklin, once natty goes we'll have a nice view [15:35] 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] 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] jsalisbury, I think that isn't necessary. I checked that the configs are identical to Precise [15:51] rtg, I think you missed to push latest precise master-next with that bluetooth firmware changes, can't find the commits applied [15:56] herton, done [15:56] ack thanks [15:56] 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] herton, sounds like there are a couple more patches, right ? [15:58] rtg_, yes, Jesse posted two more [15:58] herton, I'll go ahead and apply them as well. [16:00] and I'm gonna stick bjf's ACK on 'em cause they are all part of the same batch of patches [16:01] ack ack ack some free ack's which rtg is free to use as he sees fit [16:01] bjf, now you sound like that martian movie [16:02] * smb hopes there will be no music on mumble for that [16:46] 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] i'lll look at pulling in the flavours stuff later [16:48] apw, yeah, needs tuning but looks ok [16:49] herton, yep, its clearly a half-assed attempt, but i'll poke it some more [16:49] i wanted to get it building something, more so we could see if it reacted as you needed [16:49] as you generate new bits, and lessa bout what it produces [16:50] herton, so you are making this repo out of your incoming email, by hand I guess yes ? [16:51] apw, yes, I apply by hand. Sometimes I can get from the stable queues, but it's not reliable always [16:51] it is annoying those queues aren't always up to date, as making the branches from them would be easy to script [16:51] yep [16:51] we should be pushing them to make sure they do that [17:20] * ppisati -> EOD [17:33] * rtg_ -> lunch [17:34] ogasawara, go for it, we haven't made one [17:35] bryce: ack [17:46] * smb ->EOD [17:53] * henrix -> EOD === henrix is now known as henrix_ [18:02] herton, are we really still releasing stable updates for 2.6.34, unexpected [18:03] apw, I think it is still maintained, by Paul Gortmaker, I think last release was 1/2 months ago [18:04] herton, just supprised to see us building something against maverick configs :) [18:28] bjf, http://comments.gmane.org/gmane.linux.kernel/1379326 [18:31] one of the guys complaining has the same Lenovo x121e as me. === hugh__ is now known as Guest77744 [22:27] herton, bjf, it seems shankbot didn't make a prepare-meta task for my linux-lowlatency ... bug ? [22:28] apw, I think it misses a entry in ktl/ubuntu.py, it needs a meta in dependent-packages [22:28] 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] apw, bjf, I'll check and commit a fix [22:28] herton, thanks much [22:28] bjf, i so wish there was some way these 'self' connected ... i realise thats fantasy [22:28] herton, thanks a lot, i know i am bending your system [22:32] herton, bjf, is there some 'better' way to create these, the issue is that lowlatency depends on master's headers [22:32] so we really want the thing to not be promotable to -proposed before master [22:33] apw, we could add that dependency into shankbot but it would be a special case for that package [22:34] yes, would need some more logic into it [22:34] bjf, well, it should apply for -ec2 and any other rebase kernel really [22:34] apw, it would be doable to generalize it. we just haven't run into that case before [22:34] apw, yes, i was thinking the same [22:34] bjf, apw, fix commited, should create meta task on future lowlatency tracking bugs [22:35] actually, with ec2, since the bot create the bug after the master is built, it should be ok [22:36] apw, you also do't want a kernel package to go to -proposed without the accompanying -meta package ready [22:36] herton, apw, uds beer fodder [22:40] 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] 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] herton, this is not about the making/building part, but about when it is offered for copying [22:45] the copying part i would like to have wait for -foo derivatives until you are not respinning master [22:45] which is necessary for -lowlatency, and very desirable -ec2 [22:47] * rtg -> EOD [22:47] apw, hmm ok, yeah that would need additional checks in shank bot. [22:47] bjf, lets put it on the UDS beer list :) [23:10] 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] bjf, indeed, it's bad having things not installable in -proposed [23:11] herton, and shank-bot isn't _nearly_ complex enough yet [23:11] and from a testing point of view it makes sense to hold -ec2 etc as master gets more testing [23:14] herton, apw, agenda updated [23:15] thanks, shank bot someday will dominate the world at this rate :P [23:15] 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] infinity, agreed [23:16] 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] infinity, you can bring that to the uds-beer meeting [23:16] bjf: I suspect I'll be at a few of them. ;) [23:18] yeah, the promoting to release is more important, I agree any promoting must consider the dependencies [23:19] Well, "dependencies". [23:19] lowlatency is the only one here with an ACTUAL dependency to watch out for. [23:19] The rest, it's just about getting master's testing for "free" for the derivatives. [23:20] 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] (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] Don't recall what the bug was now. [23:22] ack