| === smb` is now known as smb | ||
| brendand | henrix - hi, i just noticed the lucid kernel has been verified | 09:47 |
|---|---|---|
| henrix | brendand: yep, there were only 3 commits to be verified | 09:48 |
| henrix | brendand: so, it was fast :) | 09:48 |
| brendand | henrix, can we leave it to our discretion whether to do the testing before or after UDS? | 09:51 |
| 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:53 |
| 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:55 |
| 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:56 |
| henrix | brendand: oh, right! | 09:57 |
| brendand | cking, how we wish :) | 09:57 |
| brendand | cking, the tests are all automated, indeed | 09:57 |
| cking | so what isn't automated? | 09:58 |
| 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 | :-/ | 09:59 |
| brendand | cking, if only every system supported WoL! | 10:00 |
| brendand | or similar | 10:00 |
| === henrix_ is now known as henrix | ||
| === henrix_ is now known as henrix | ||
| === henrix_ is now known as henrix | ||
| * ppisati -> out for lunch | 11:05 | |
| * henrix -> lunch | 11:33 | |
| === yofel_ is now known as yofel | ||
| herton | apw, do you have access to pre-proposed ppa? builds there are failing because of lack of space | 13:06 |
| 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:07 |
| herton | *natty and maverick | 13:08 |
| * smb kindly asks the person standing on gomeisa's network cable to step aside... 155KB/s.... yawn... | 13:12 | |
| 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:13 |
| herton | apw, thanks, yep that would be great if we can do | 13:14 |
| apw | herton, do you know of anyone who uses that PPA for anything, other than us really looking at the builds for failures ? | 13:15 |
| 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:16 |
| apw | herton, they are mad as spoons | 13:30 |
| apw | herton, ok i've cleaned it out and rerun lucid, precise, and fixed up quantal; they should start building shortly | 13:31 |
| 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:33 |
| apw | i do indeed | 13:34 |
| herton | apw, git://kernel.ubuntu.com/herton/linux-stable.git | 13:34 |
| herton | I push to the linux-* branches, and create prestable-* tags, the tree tracks linus master | 13:36 |
| apw | herton, ok so those are the 'results' of your stuff right ? | 13:38 |
| 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:39 |
| herton | apw, correct | 13:40 |
| apw | herton, is this branch once applied "just" doing prestable ? | 13:44 |
| 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:46 |
| 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:47 |
| 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:49 |
| apw | herton, ok ta, will have a look | 13:50 |
| 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:52 |
| apw | herton, i am wondering if much new is actually needed if we treat them as crack daily builds | 13:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| apw | herton, i am wondering if the tags do anything for you other than being a sync point for the checks | 14:00 |
| 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:01 |
| 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:02 |
| 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:05 |
| apw | herton, whats up with the versioning, so i can think about it | 14:06 |
| 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:07 |
| apw | makes sense | 14:08 |
| cking | smb, I'm seeing really poor rx rates from gomeisa too | 14:08 |
| smb | cking, Luckily I am done with it for the moment. So at least its not me that causes it for you now | 14:09 |
| * cking notes that caffine stimulants and pain killers don't do the head any good | 14:13 | |
| apw | cking, go away | 14:20 |
| 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:21 |
| * cking gets the point | 14:22 | |
| cking | i'll take a break for sure | 14:22 |
| bjf | cking, we'll see you at uds :-) | 14:23 |
| apw | bjf, i hope not | 14:34 |
| apw | herton, soooo, do you want to be able to use tags, or would you prefer not | 14:36 |
| herton | apw, no, just try to add as a cod build as you said, and we can sort it out what's missing | 14:37 |
| apw | herton, ack | 14:40 |
| === e11bits_ is now known as e11bits | ||
| 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:12 |
| 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:13 |
| 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:30 |
| 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:35 |
| rtg_ | jsalisbury, I think that isn't necessary. I checked that the configs are identical to Precise | 15:38 |
| herton | rtg, I think you missed to push latest precise master-next with that bluetooth firmware changes, can't find the commits applied | 15:51 |
| 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:56 |
| rtg_ | herton, sounds like there are a couple more patches, right ? | 15:57 |
| herton | rtg_, yes, Jesse posted two more | 15:58 |
| rtg_ | herton, I'll go ahead and apply them as well. | 15:58 |
| rtg_ | and I'm gonna stick bjf's ACK on 'em cause they are all part of the same batch of patches | 16:00 |
| 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:01 |
| * smb hopes there will be no music on mumble for that | 16:02 | |
| 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:46 |
| herton | apw, yeah, needs tuning but looks ok | 16:48 |
| 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:49 |
| apw | herton, so you are making this repo out of your incoming email, by hand I guess yes ? | 16:50 |
| 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 | 16:51 |
| * ppisati -> EOD | 17:20 | |
| * rtg_ -> lunch | 17:33 | |
| bryce | ogasawara, go for it, we haven't made one | 17:34 |
| ogasawara | bryce: ack | 17:35 |
| * smb ->EOD | 17:46 | |
| * henrix -> EOD | 17:53 | |
| === henrix is now known as henrix_ | ||
| apw | herton, are we really still releasing stable updates for 2.6.34, unexpected | 18:02 |
| herton | apw, I think it is still maintained, by Paul Gortmaker, I think last release was 1/2 months ago | 18:03 |
| apw | herton, just supprised to see us building something against maverick configs :) | 18:04 |
| rtg_ | bjf, http://comments.gmane.org/gmane.linux.kernel/1379326 | 18:28 |
| rtg_ | one of the guys complaining has the same Lenovo x121e as me. | 18:31 |
| === hugh__ is now known as Guest77744 | ||
| apw | herton, bjf, it seems shankbot didn't make a prepare-meta task for my linux-lowlatency ... bug ? | 22:27 |
| 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:28 |
| 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:32 |
| bjf | apw, we could add that dependency into shankbot but it would be a special case for that package | 22:33 |
| 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:34 |
| herton | actually, with ec2, since the bot create the bug after the master is built, it should be ok | 22:35 |
| 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:36 |
| 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:40 |
| 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:43 |
| apw | herton, this is not about the making/building part, but about when it is offered for copying | 22:44 |
| 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:45 |
| * 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 :) | 22:47 |
| 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:10 |
| 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:11 |
| bjf | herton, apw, agenda updated | 23:14 |
| 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:15 |
| 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:16 |
| herton | yeah, the promoting to release is more important, I agree any promoting must consider the dependencies | 23:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| bjf | ack | 23:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!