| === ericm-Zzz is now known as ericm|ubuntu | ||
| slangasek | bjf[afk]: so bug #900522 is a fun bot corner case. If I reboot to the new kernel, it's possible I won't be able to reproduce the bug at all because I don't know how the kernel routing table has gotten into this state to begin with ;) | 00:30 |
|---|---|---|
| ubot2 | Launchpad bug 900522 in linux "cached route that can't be removed with 'ip route flush cache'" [Low,Incomplete] https://launchpad.net/bugs/900522 | 00:30 |
| slangasek | bjf[afk]: do you know who might be interested / able to help debug the kernel side of this? If not, I guess I'll just reboot at some point and probably close the bug | 00:35 |
| === bjf[afk] is now known as bjf | ||
| bjf | slangasek: tgardner would probably be the best but i'm not sure | 01:54 |
| bjf | slangasek: you can add the "bot-stop-nagging" tag if you want | 01:55 |
| === bjf is now known as bjf[afk] | ||
| slangasek | I know... I'm just not sure that's a useful thing to do in this case :) | 01:56 |
| bjf[afk] | slangasek: agreed | 01:56 |
| === bladernr_ is now known as bladernr_afk | ||
| === smb` is now known as smb | ||
| smb | morning .+ | 08:26 |
| ppisati | morning | 08:26 |
| === himcesjf1 is now known as himcesjf | ||
| * apw yawns | 09:44 | |
| * abogani waves all | 09:53 | |
| abogani | BenC: ping | 09:53 |
| apw | ppisati, when you have ti-omap4 'fixed' i can probabally test it, so push it up somewhere i an grab it | 10:36 |
| === brendand_ is now known as brendand | ||
| ppisati | yep | 10:58 |
| ppisati | it's baking... | 10:58 |
| apw | chocolate cake ? | 10:59 |
| * smb gets hungry | 10:59 | |
| ppisati | uhmm... i should make tiramisu one of this day... :) | 10:59 |
| apw | bring it to rally | 10:59 |
| ppisati | uhm... | 11:00 |
| * apw likes tiramisu | 11:00 | |
| smb | Guess it would count as "liquid" | 11:00 |
| * smb +1 | 11:00 | |
| ppisati | actually if i froze it but then it will turn crap i guess... | 11:00 |
| apw | heh yeah i bet it would, sigh | 11:01 |
| apw | i know we can just have a sprint at paolo's place | 11:01 |
| smb | Right, have a look at his new flat | 11:01 |
| apw | he can sleep on the floor | 11:02 |
| ppisati | but before the sprint i'll have to disassemlbe all the boxes... way too hard... :) | 11:03 |
| apw | we can use the boxes as desks, no problem | 11:04 |
| smb | No problem we are good at disassembling... | 11:04 |
| smb | ...assembling is another problem | 11:04 |
| cking | especially when the pieces have been lost and the manuals are wrong | 11:04 |
| smb | the what? | 11:05 |
| * apw swings his hammer widly "this screw will go in this square hole I am sure" | 11:05 | |
| * cking notes that when ever he reassembles furniture there is always one critical bolt or screw missing | 11:06 | |
| apw | cking, though that is probabally triggered by offspring | 11:06 |
| smb | cking, Can't be critical if things still hold together | 11:07 |
| * apw notes wobbly is ok | 11:07 | |
| smb | Remembers a shelf that survived quite a bit of time after moving and having a handful of pieces of unknown destination in my hands | 11:08 |
| cking | DIY kernel team style sounds a bit hacky to me | 11:10 |
| apw | cking, we could do your extension if you like | 11:11 |
| smb | back to the essentials | 11:11 |
| cking | back to rubble more like | 11:11 |
| apw | always need rubble | 11:11 |
| cking | not when I need to live in it | 11:11 |
| smb | hey , things usually do work and hold together | 11:11 |
| cking | not with kids about | 11:12 |
| smb | Though in that case those few screws don't help much either | 11:12 |
| apw | na just more sharps for them to find | 11:13 |
| cking | "..but daddy you made it and it's your fault" is what I expect to hear | 11:13 |
| smb | cking, It is your fault anyway | 11:16 |
| cking | yeah, that's very true | 11:16 |
| apw | you should not buy anything, so there is nothing to break | 11:16 |
| cking | I can imagine being a hermit... | 11:16 |
| apw | cking, it'd be cheaper | 11:20 |
| cking | no beer though | 11:20 |
| apw | those hermit types are the ones who invented beer | 11:20 |
| ppisati | beer was invented by monks AFAIK | 11:26 |
| ppisati | apw: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-precise.git;a=shortlog;h=refs/heads/ti-omap4 | 11:26 |
| ppisati | apw: last commit, the kernel compiled here | 11:26 |
| apw | ppisati, ok ta, will test | 11:28 |
| ppisati | back in 10mins | 11:28 |
| apw | ppisati, where are we with bug #861296 ? | 11:44 |
| ubot2 | Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296 | 11:44 |
| ogra_ | apw, i think we missed the two weeks SRU window (at least thats what i gathered from GrueMaster's complaints yesterday) | 11:45 |
| ppisati | should be in every omap4 and imx51 branch | 11:45 |
| ogra_ | (ask him for more detail) | 11:46 |
| ppisati | except for P/omap4 | 11:46 |
| ppisati | which is based off O/omap4 | 11:46 |
| apw | ppisati, ok so it should be available, and it is with stable to roll out | 11:46 |
| ppisati | so, next sync with will get it | 11:46 |
| ppisati | yep | 11:46 |
| apw | ogra_, as its for the buildds we could get them a kernel potentially out of band i guess ? | 11:46 |
| ppisati | we did it indeed | 11:47 |
| ogra_ | i guess lamont already runs it (not sure though, second hand info) | 11:47 |
| ppisati | i handed custom kernels to #is with that fix way back | 11:47 |
| apw | ok then we are good | 11:47 |
| ogra_ | apw, but GrueMaster needs to test them again | 11:47 |
| ogra_ | to have them in the next SRU batch | 11:47 |
| apw | yep, there is always new batches to test | 11:47 |
| ogra_ | (which is quite annoying for him) | 11:47 |
| ppisati | apw: with the armhf i'll sync with O so P will get that fix too | 11:48 |
| ogra_ | apw, well, he tested them two weeks ago already | 11:48 |
| apw | ogra_, well there would be a new kernel to test next two weeks whether that is in or not | 11:48 |
| apw | as there will be security fixes in those kernels every cycle as well | 11:48 |
| ogra_ | sure | 11:48 |
| apw | so i don't think there is any more or less testing to do | 11:48 |
| apw | ppisati, ok good news, my full build of your branch looks good | 11:48 |
| ogra_ | well, its just bad if he is told to test something that doesnt get uploaded in time and then he has to start over | 11:49 |
| ogra_ | the test means to build java stuff which is really time consuming | 11:49 |
| apw | ahh i see, sorry about that then | 11:49 |
| ogra_ | yeah, not to me :) ... | 11:50 |
| * ogra_ is just the cassandra here :) | 11:50 | |
| apw | ppisati, is this branch 'good' ... do we want it pushed and uploaded? | 11:50 |
| ppisati | apw: not yet, let me sync it with O first | 11:51 |
| ppisati | apw: then i'll send the entire batch of changes | 11:51 |
| apw | ppisati, ok, back to you :) | 11:51 |
| apw | ogra_, are you waiting on armhf ti-omap4 at all ? | 11:52 |
| ogra_ | yep | 11:52 |
| apw | how much is it holding you up | 11:52 |
| ogra_ | omap4 and ac100 kernels are the last nits missing before we can start armhf images | 11:52 |
| ogra_ | *bits | 11:52 |
| ogra_ | everything else is ready | 11:52 |
| apw | ppisati, how long i the resync going to take ? | 11:53 |
| * apw is considering whether to upload the unresynced version | 11:53 | |
| ppisati | half an hour, one hour max | 11:53 |
| apw | oh then... that is an easy decision | 11:54 |
| apw | if it is going to be today then cool | 11:54 |
| apw | ogra_, are you on the hook for ac100 | 11:54 |
| ogra_ | apw, infinity is just testbuilding a changed package | 11:54 |
| ogra_ | should be uploaded once he gets up again | 11:55 |
| apw | ok cool, ppisati poke me when you are done so we can expedite this thing into the queue | 11:56 |
| ogra_ | my expectation is that we can build hf images weekendish ... | 11:56 |
| apw | ppisati, have we uploaded ti-omap4 to P at all yet ? | 11:57 |
| ogra_ | once i think | 11:57 |
| ogra_ | yup, on nov 21 | 11:58 |
| apw | oh now i see why i am confused | 12:12 |
| apw | infinity, did you just invent a linux-meta for ti-omap4 ? | 12:13 |
| ogra_ | apw, he uploaded it ahead of the kernel it seems, yep | 12:15 |
| apw | but where the heck did he get it from | 12:15 |
| ogra_ | (there was a conversation in #ubuntu-arm about it ) | 12:15 |
| ogra_ | <infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf. So, now I just need a kernel. ;) | 12:16 |
| apw | ogra_, great, that just throws all the kernel team process into a cocked hat | 12:16 |
| apw | ogra_, and is liable to bollox anyone who is an upgrader from oneiric | 12:19 |
| ogra_ | yup | 12:20 |
| ogra_ | dont blame me :) | 12:20 |
| apw | infinity, *slap* | 12:20 |
| * apw just has no idead what infinity has been doing to ti-omap4 meta, this is an utter mess | 12:23 | |
| * apw stomps off to sulk in the corner | 12:23 | |
| infinity | apw: Invent it? It's always been there. | 12:30 |
| apw | infinity, you didn't use one of our source trees to make it | 12:30 |
| infinity | apw: All I did was add armhf to it (and rev it to the correct ABI) | 12:30 |
| infinity | apw: Uhh. | 12:30 |
| infinity | apw: It was apt-get source linux-omap4. :P | 12:30 |
| apw | so now i have to unf*ck all our trees | 12:30 |
| infinity | apw: It's been in the archive for eons. | 12:31 |
| apw | yeah the package is fine, its that we nolonger have a tree we can build meta from | 12:31 |
| infinity | apw: And I based it on what was in the archive, not much to "unfuck". debdiff, apply, done. | 12:31 |
| apw | so if i naievly uploaded the top of ours, your changes would go poof | 12:31 |
| infinity | apw: See above, then? | 12:32 |
| apw | infinity, but the bigger issue is you shouldn't upload meta before the binaries are built | 12:32 |
| apw | as now anyone with the thing installed is liable to end up with no kernel and in a heap of trouble | 12:32 |
| infinity | apw: I uploaded it for armel, where the binaries have been built for weeks but no one updated the meta. | 12:32 |
| infinity | apw: No one has armhf installed with a kernel, cause there are none. | 12:32 |
| infinity | apw: (-meta was out-of-date on armel, and has been for a long time) | 12:32 |
| apw | ok then we are ok | 12:32 |
| * apw whines | 12:33 | |
| infinity | apw: Whine less? | 12:33 |
| apw | na bad for me | 12:33 |
| apw | maybe i could be andy whine-house | 12:33 |
| ogra_ | want to join the arm team ? | 12:33 |
| ogra_ | :P | 12:33 |
| apw | ogra_, heh no you are all mad, i'd not fit in | 12:34 |
| infinity | apw: Is it really that tough to apply my delta to git? Cause, I can provide you with a branch to merge, if you want. | 12:35 |
| infinity | apw: I just have no zinc access anymore to actually commit it. | 12:36 |
| apw | infinity, nope its not hard, i am moaning about not knowing as i nearly broke things | 12:36 |
| infinity | apw: Meh, if you broke things, I'd just whine right back. ;) | 12:36 |
| apw | :) | 12:36 |
| apw | i would hope so too | 12:36 |
| ogra_ | whiners | 12:37 |
| ogra_ | all you ! | 12:37 |
| infinity | (And, for the record, anyone who uploads anything without checking the current state of the archive, and diffing current:new should probably rethink their workflow) | 12:37 |
| apw | infinity, that'd be us for sure :) | 12:37 |
| infinity | I figured. ;) | 12:37 |
| apw | infinity, i have also taken a note to slap tim for uploading the kernel and never uploading -meta to match | 12:37 |
| apw | well actually, i clearly do check cause i just noticed :) | 12:37 |
| apw | infinity, aside of that, meta looks good | 12:38 |
| infinity | S'ok. I'll go back to mangling unsupported kernels now. ;) | 12:38 |
| apw | ac100 i assume | 12:38 |
| infinity | Yeah. | 12:38 |
| apw | if you have a tip somewhere i can test build it before you upload it, takes about 10mins | 12:39 |
| apw | (test building the packaging as it were) | 12:39 |
| ppisati | ok, pull req sent to the kernel ml | 12:39 |
| infinity | Oh, it's already building on my Panda. | 12:39 |
| apw | ppisati, ok will do | 12:39 |
| * ppisati goes to find some food (aka lunch) | 12:39 | |
| apw | infinity, well it takes a lot less time my way | 12:39 |
| infinity | I don't do kernel iterations often enough to have a cross environment set up for it. Don't care. | 12:39 |
| infinity | It's an excuse to get caught up on Dexter. | 12:40 |
| ogra_ | heh | 12:40 |
| apw | heh ok, i found building udebs painful as it takes sooo long to fail | 12:40 |
| ogra_ | we dont ahve udebs for ac100 | 12:40 |
| apw | ahh then you are likely to work then | 12:40 |
| ogra_ | (i think ... unless jani recently added them) | 12:40 |
| infinity | Also, you're assuming it will fail. | 12:41 |
| infinity | You should know me better than that. ;) | 12:41 |
| ogra_ | it cant fail, its maintained by the arm team :D | 12:41 |
| infinity | ogra_: We have udebs for ac100, yes. | 12:41 |
| ogra_ | ah, thats new then | 12:41 |
| ogra_ | i explicitly didnt build them when i maintained it | 12:41 |
| ogra_ | but jani moved to git and all ... using the ubuntu sauce etc | 12:41 |
| infinity | Well, sort of. | 12:42 |
| ogra_ | so i guess we inherit udeb building | 12:42 |
| infinity | It's more linaroish than ubuntuish. | 12:42 |
| ogra_ | yeah | 12:42 |
| apw | ick :) | 12:42 |
| ogra_ | i originally based on n900 ... he moved to some generic linaro ways from that | 12:42 |
| ogra_ | but added the sauce | 12:43 |
| apw | ogra_, i have often felt the right thing is to take linaro tip and merge our master into it each time to make the new version | 12:43 |
| infinity | I miss being a lot less confused by kernels. When that all built from the same source package, and x86-centric people whined that merging patches with Sparc was "too hard", so they just didn't, and then they whined when it would FTBFS. | 12:44 |
| infinity | Good times. | 12:44 |
| ogra_ | apw, well the prob is that linaro refuses to maintain tehir kernels after a release ... and they release monthly | 12:44 |
| apw | infinity, its cirtainly different now, i think i've lived through it all, quite a ride | 12:44 |
| apw | ogra_, oh i know, you'd be merging their original tip into our tip with cves and hoping that the result worked | 12:45 |
| ogra_ | we could go from snapshot to snapshot ... but as soon as *we* release there isnt a way to get SRUs or security fixes | 12:45 |
| apw | ogra_, the one thing i am fully aware of is the amount of work their cause me and my arm peeps | 12:45 |
| ogra_ | yep | 12:45 |
| apw | we essentially maintain > 2x the kernel revisions we want to cause of this crap | 12:46 |
| infinity | apw: I think we still need some clever way to keep the packaging more centralised and sane than it currently is. And the secret sauce. And all that jazz. Even if we don't want one massive source package that takes forever to build and has (potentially) conflicting patches. | 12:46 |
| infinity | apw: Like, some shiny tool that will essentially roll a proper source package from git, with grafted branches as needed. | 12:46 |
| apw | infinity, care to be part of a discussion at rally about ideas on how we can improve things | 12:46 |
| infinity | apw: So they all look and act the same. | 12:46 |
| infinity | apw: Yeah, perhaps. | 12:47 |
| apw | that has been suggested and the AAs went mad that the source should be the source | 12:47 |
| ogra_ | hard to do if you have as many different versions as linaro has though | 12:47 |
| ogra_ | (read: BSP kernels) | 12:47 |
| apw | and we arn't allowed to backport the packaging changes to older releases | 12:47 |
| ogra_ | iirc there are still boards they run with .35 | 12:47 |
| apw | and .. 200 other complaints against anything we have suggested | 12:47 |
| infinity | apw: I mean, for Linaro-maintained kernels, we can't do as much, and that's fine, but anything that's theoretically maintained by the Ubuntu kernel team should all match with packaging, enforce, etc. | 12:47 |
| apw | infinity, and we'd do that in an instant if the sru team would take the harmonised packaging | 12:48 |
| infinity | apw: The source is never the source. I wonder if maybe some wires got crossed in describing how to do such a thing. | 12:48 |
| apw | but we did try and they said flat no | 12:48 |
| infinity | apw: I mean, heck, nothing that uses autoconf is "pristine source", upstream always generates configure, etc. | 12:48 |
| apw | infinity, yeah, its the debian packaging changing in old releases they won't let us do | 12:49 |
| infinity | apw: I don't see how SRUs relate. That's just different (and stagnant) branches. You always have to branch at a stable release. | 12:49 |
| infinity | apw: Anything "auto-generating" packaging in a stable release should be deterministic anyway. | 12:49 |
| ogra_ | the past is whats creating the workload ... | 12:49 |
| apw | well if we commonise, we want to commonise everywhere no? | 12:49 |
| apw | else the old stuff is different and the world is more of a pain than now | 12:50 |
| ogra_ | while we can change it for the future, kernel team is stuck with the past stuff | 12:50 |
| infinity | apw: (ie: if I rerun autotools across a source package with the same versions of autoconf, libtool, etc, it won't change the output) | 12:50 |
| apw | right | 12:50 |
| infinity | apw: No, changing the past is a no-go. But that doesn't perclude improving the future. ;) | 12:50 |
| apw | a ripe discussion for rally | 12:50 |
| apw | infinity, well except where the new differs from the old in semantics as that creates mantenance burden | 12:51 |
| infinity | apw: But let's have an informal beer on Sunday night at the Rally and see if it comes to fisticuffs and/or agreement before you care about my opinions on the matter. :) | 12:51 |
| apw | and right now most of the burden is on people making new branches | 12:51 |
| apw | infinity, sounds good to me | 12:51 |
| infinity | I'll go work out. | 12:52 |
| abogani | BenC: About "Reviving Ubuntu PowerPC"... | 13:08 |
| abogani | BenC: What systems will be used as reference in this effort? | 13:08 |
| infinity | abogani: My PowerStation, for one. ;) | 13:21 |
| smb | herton, I discovered this morning that I had missed one change in the upstream patches which has a related bug in the ec2 deviated files (had been missing two files in the deviations file). I suppose the correct way forward is a completely new tracking bug and to invalidate/mark duplicate the old one. Or is there another option? | 13:27 |
| * cking grabs some food | 13:27 | |
| herton | smb, yes, doing a new tracking bug, duplicating the old against the new is ok, no other way | 13:28 |
| smb | herton, ok, will follow-up with that then. thanks | 13:29 |
| === himcesjf1 is now known as himcesjf | ||
| bullgard6 | How is a »kernel update« defined? Is the term »kernel update« a technical term meaning something else than just any change in the kernel code to reflect a newer development? So far I did not find a definition when googling. How can one write: "The package linux-generic is a kernel update"? | 13:46 |
| apw | generally when we talke about a 'kernel update' we are talking about an updated package containing the kernel | 13:47 |
| apw | i don't think i would ever write "the package linux-generic is a kernel update" | 13:47 |
| bullgard6 | Ah! | 13:47 |
| apw | the package linux-generic trigers your kernel to be updated | 13:47 |
| apw | by always depending on the latest kernel package available | 13:47 |
| bullgard6 | apw: Thank you very much for explaining. | 13:49 |
| apw | np | 13:50 |
| apw | ppisati, did you get an email in response to my upload | 13:52 |
| ppisati | apw: i got the "applied" email | 13:54 |
| apw | ppisati, did you get anything from launchpad about it | 13:55 |
| ppisati | nope | 13:55 |
| apw | bloody lp | 13:55 |
| infinity | apw: The librarian's down. | 14:08 |
| apw | infinity, does that break uploads? presume so | 14:08 |
| infinity | apw: Since they have to be stored in the librarian, yeah. | 14:09 |
| infinity | apw: They should be tucked away in queues, waiting to flush when it's fixed, though. In theory. | 14:09 |
| apw | infinity, yeah heres hoping ... | 14:10 |
| === bladernr_afk is now known as bladernr_ | ||
| tgardner | jsalisbury, do you have a way to search for bugs against linux-meta ? In almost all cases they should be changed to linux (unless they really are meta package bugs) | 15:05 |
| ppisati | apw: P/omap4 is in and it's building | 15:05 |
| jsalisbury | tgardner, yes, I can do a search on them. I'll do that and move them over linux | 15:05 |
| ppisati | apw: but the armhf version says "need building" | 15:05 |
| ppisati | seems it's queued | 15:06 |
| ppisati | gut | 15:06 |
| apw | ppisati, yep all good, given the state of the librarian its amazing its building at all | 15:07 |
| ppisati | apw: but since we don't have any armhf builder, how does it build? | 15:07 |
| jsalisbury | herton, bjf, Request for a patch backport to oneiric: bug 899598 | 15:08 |
| ubot2 | Launchpad bug 899598 in linux "[Patch] The resolution of Display Port for intel cards is limited" [Medium,Triaged] https://launchpad.net/bugs/899598 | 15:08 |
| herton | jsalisbury, we will take a look | 15:08 |
| * herton -> lunch | 15:08 | |
| apw | ppisati, yep we do, we have about 10 | 15:09 |
| ppisati | ah cool | 15:10 |
| apw | ppisati, we actually have more than we have armel right now, but then we have 1000s of packages to build | 15:10 |
| ppisati | i see | 15:10 |
| jsalisbury | herton, thanks | 15:10 |
| ogra_ | ppisati, apw, infinity can raise the priority for the armhf build | 15:18 |
| ogra_ | (or any other archive admin) | 15:18 |
| apw | ogra_, yep, its already started building too | 15:19 |
| ogra_ | ah, k | 15:19 |
| === bjf[afk] is now known as bjf | ||
| jsalisbury | ** | 15:51 |
| jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 15:51 |
| jsalisbury | ** | 15:51 |
| * apw wimpers | 15:53 | |
| * ogasawara back in 20 | 15:57 | |
| GrueMaster | ogra_, apw: My issue on kernel SRU yesterday was that a much needed feature that was tested in various kernels a couple of weeks ago didn't get included with this SRU cycle, meaning that people that need these fixes need to wait until almost EOY for them. Or they run with a test kernel and not get any of the SRU updates in this release. | 16:13 |
| GrueMaster | Just to clarify. | 16:13 |
| ogra_ | yeah, i think i got that across to apw and he even apologized | 16:13 |
| apw | yep and i suspect that is because the submitter was on holiday when he results came in, and appoligies for the testing effort that is wasted as a result | 16:14 |
| apw | separate to the inconvienience, it sounds like we need some updated test kerenls as well | 16:14 |
| apw | i am assured the fix is applied now though i can't say i have checked | 16:15 |
| ogra_ | well, the important part (buildds) is fixed anyway already ... essentially getting it into the archive is rather the formal afterwork :) | 16:15 |
| GrueMaster | For the record, I'm not trying to stir up that argument again, just clarifying where I stood. | 16:15 |
| apw | GrueMaster, nope and i am not seeing it as a moan either | 16:15 |
| GrueMaster | Good. :) | 16:15 |
| apw | and had i realised that it was a 2 day effort to test it i'd have been more careful to shepherd the fix | 16:15 |
| apw | i tend to assume its boot and run for a couple of minutes and know, whcih isn't at all the case for this puppy | 16:16 |
| GrueMaster | I do have some qrt tests that magically work with that fix, but since i have had to manually run them anyways until now, it isn't too much effort to monitor them again. | 16:16 |
| ogra_ | well, we could just ask lamont to set the verification-done tag on the bug | 16:17 |
| apw | topdown mmap support | 16:17 |
| ogra_ | gievn he already runs the fix on the buildds | 16:17 |
| apw | its that set isn't it we are talking about | 16:17 |
| ogra_ | without having GrueMaster to runn a full test ... | 16:17 |
| GrueMaster | Part of the test process is that I am struggling to automate SRU testing. Largely due to script issues and the lack of any automated installation capabilities prior to Oneiric on omap4. | 16:17 |
| GrueMaster | But those are almost resolved. | 16:18 |
| apw | ppisati, where do i expect to find 'topdown mmap support' applied? | 16:18 |
| apw | ppisati, fsl-imx51 and natty and oneiric ti-omap4 right? (which it is) | 16:18 |
| ppisati | apw: M/N/O/P/omap4 and L/imx51 | 16:18 |
| apw | so it looks like it is applied everywhere i am expecting it to be, so i assume it'll be in teh next roll up | 16:19 |
| apw | ppisati, ok cool, just checking they got applied right | 16:19 |
| ppisati | i posted the testing kernels the day X, but i got the ack about all of them the day _after_ the SRU process started | 16:20 |
| GrueMaster | ppisati: In the future, when you go on vacation to get away from it all, make sure to take your laptop so you can still work. :P | 16:20 |
| ppisati | so i couldn't pull | 16:20 |
| ppisati | i did it before my internet disconnection | 16:20 |
| ogra_ | lol | 16:20 |
| ogra_ | ppisati, dont listen to him ! | 16:20 |
| apw | ppisati, yep that is likely our fault | 16:20 |
| cking | hrm, still more workitems to plough through... | 16:20 |
| ppisati | IMO it was just an unfortunate timing | 16:21 |
| ppisati | the problerm is that i can't pull in fixes if they aren't tested | 16:21 |
| GrueMaster | Agreed. Actually, I was on a national holiday that week as well. | 16:21 |
| infinity | ogra_: Err, reading backscroll, I don't think the buildds are fixed. | 16:22 |
| infinity | ogra_: lamont tested a kernel on a machine, he didn't do any sort of mass roll-out. | 16:22 |
| ogra_ | infinity, i thought lamont was using the fixed kernels since a while | 16:22 |
| ogra_ | oh | 16:22 |
| ogra_ | ok | 16:22 |
| ogra_ | but after all he did the testing and could just comment on the bug ... leaving tobin off the hook | 16:23 |
| GrueMaster | I tested it too. Thought I had commented on the bug. | 16:23 |
| * GrueMaster goes to check. | 16:23 | |
| * ogra_ hasnt looked at the bug | 16:23 | |
| infinity | ogra_: He tested one kernel on one machine type. That's not quite the scope of tobin's testing. | 16:24 |
| ogra_ | oh | 16:24 |
| * ogra_ leaves that topic alone then | 16:25 | |
| * ppisati goes back to 3.2/omap4... | 16:25 | |
| ogra_ | i somewhat had a different impression | 16:25 |
| GrueMaster | I tested it on babbage3 (Lucid) and panda (natty & oneiric). Not sure if we had a test kernel for maverick. | 16:27 |
| GrueMaster | Does the patch need to be retested on top of this new SRU kernel or can it just float into the next SRU cycle and get tested there? | 16:28 |
| GrueMaster | (I may have missed this answer due to lack of caffeine). | 16:29 |
| apw | GrueMaster, for me, just when it gets applied to teh next SRU, i am not expecting it to break | 16:30 |
| ogra_ | ++ | 16:30 |
| GrueMaster | Ok, great. Means I can focus on other things until next SRU cycle without a special testcase getting thrown into the mix. | 16:30 |
| infinity | apw: Looks like I win, my kernel will get built first. | 16:38 |
| apw | heh | 16:38 |
| infinity | (not that it matters, cause neither one can be published to the archive for a few hours) | 16:38 |
| amb__ | We have a bug (LP #886521) which is marked "Fix Committed" in Oneiric. What is the process / timescale that a new kernel gets released to incorporate such fixes (and presumably changes it to "Fix Released")? | 16:46 |
| ubot2 | Launchpad bug 886521 in linux "CONFIG_XEN_PLATFORM_PCI should be "y" when building 3.1 kernel" [Medium,Fix committed] https://launchpad.net/bugs/886521 | 16:46 |
| apw | amb__, it is likely the fix if already rolled up in the -proposed kernel for testing | 16:46 |
| smb | Could be in the pending round of getting into proposed | 16:47 |
| amb__ | apw, so is that an automatic process? | 16:47 |
| smb | But normally you find an update in the bug that is automatically generated which tells you to test the proposed kernel | 16:47 |
| amb__ | (and/or how do we get at the .debs to test such kernels) | 16:48 |
| amb__ | ah, it's not there yet | 16:48 |
| amb__ | then | 16:48 |
| apw | amb__, ok its only just been commited, so it missed the current sru round, so i'd say you'll see it in a kernel in about 3 weeks | 16:48 |
| smb | No, I think its is on the way. The auto entry has some instructions about enabling proposed | 16:48 |
| smb | but one also can get the debs from launchpad history of the linux package | 16:49 |
| smb | https://launchpad.net/ubuntu/+source/linux/+publishinghistory | 16:49 |
| smb | ^ if lp is willing | 16:49 |
| bjf | amb__: we will be building the next oneiric kernel next week, as apw said it will hit -updates three weeks after that, it will be available via -proposed earlier | 16:49 |
| apw | amb__, and expect testing requests for it around then | 16:49 |
| smb | gah! lp timeout | 16:50 |
| amb__ | bjf, thanks | 16:51 |
| bjf | amb__: np | 16:51 |
| ppisati | don't we have the meeting in 1 hour? | 16:52 |
| ppisati | sorry | 16:52 |
| ppisati | 8mins | 16:52 |
| jsalisbury | ppisati, yes | 16:53 |
| tgardner | jsalisbury, we've been screwed by going off of daylight savings time. there are 2 entries in the calendar | 16:54 |
| jsalisbury | tgardner, ahh, ok. Should one of the entries be removed? | 16:55 |
| tgardner | jsalisbury, yeah, but which one ? | 16:56 |
| tgardner | I'll nuke the later one | 16:56 |
| apw | the meeting is at 17:00 UTC right | 16:57 |
| bjf | apw, yes, the meeting is now | 16:57 |
| jsalisbury | apw, yes, in about 3 minutes | 16:57 |
| tgardner | hmm, I can't delete the bogus entry. I'll send a note to Pete | 16:58 |
| apw | stupid google | 16:58 |
| === arges is now known as arges_away | ||
| ppisati | brb | 17:23 |
| lamont | ogra_: I was given to understand that some post-my-testing kernel had the fix, which was great, since that was what I was waiting for - the rollout of a fixed SRU is semi-automatic, manually rolling out a non-standard kernel is a royal pain | 17:31 |
| ogra_ | aha | 17:31 |
| ogra_ | thanks for clearifying :) | 17:31 |
| === arges_away is now known as arges | ||
| === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues Dec 13 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| * tgardner -> lunch | 18:36 | |
| bjf | jsalisbury: i believe bug 793367 can be "Fix Released" | 19:53 |
| ubot2 | Launchpad bug 793367 in linux "ecryptfs corruption during make -j" [Medium,Fix committed] https://launchpad.net/bugs/793367 | 19:53 |
| jsalisbury | bjf, Ok, thanks. I'll update it. | 19:53 |
| jsalisbury | bjf, I'll keep an eye on and to ensure it falls off the hot list automatically as expected. | 20:02 |
| jsalisbury | bjf | 21:39 |
| jsalisbury | bjf, herton, possible Lucid update regression: bug 900943 | 21:39 |
| ubot2 | Launchpad bug 900943 in linux "System clock runs fast in kernel 2.6.32-36" [Medium,Confirmed] https://launchpad.net/bugs/900943 | 21:39 |
| * tgardner -> EOD for now | 21:40 | |
| bjf | jsalisbury: thanks for the pointer, have added comment, am monitoring it | 21:59 |
| jsalisbury | bjf, great, thanks. | 21:59 |
| === BenC__ is now known as BenC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!