=== chiluk is now known as chiluk_away [05:52] I have an insanely stupid question. what is the best path to a very current kernel (really just need a very very current alsa)) on quantal? [09:26] nevyn, i assume you are saying that the quantal kernel is not sufficient for your needs. there is no supported later kernel. you can (and i do) run raring kernels on quantal, but you do need to manually maintain them in the face of updates === yofel_ is now known as yofel [09:30] hggdh, you guys do a bunch of kvm based testing right? had any problems with recent rarings ? === henrix_ is now known as henrix === apw` is now known as apw === akgraner` is now known as akgraner [12:48] henrix, this CVE with kees patch, have we asked security to add the POC to the QR tests ? [12:49] apw: no, i haven't done that [12:49] i guess i should :) [12:49] i'll ping jj about that [12:50] thanks :) [12:50] * henrix -> lunch [12:51] henrix, this -ELOOP patch, for P doesn't apply [12:52] well without fuzz anyhow [12:52] is that to be expected [12:59] apw: we are running Precise for the formal tests (and yes, we have been having issues). On my local machine I run Raring, bu not as intensive (3, 4 images per day) [13:00] hggdh_, i am seeing corrupt background in my raring vms backed by precise, all crosshatchy, wondered if you had seen similar [13:01] hggdh_, though the whole thing was precipitated by someone asking on #ubuntu-quality about kvm and implying raring doesn't boot there, which does nto match my experience [13:02] apw: I have not, but most tests are automated. OTOH we are seeing failures to start the domain. I do run raring KVMs on Precise (mostly no-desktop envs), and I have had no prolems === hggdh_ is now known as hggdh [13:03] it would be nice to try and confirm if this is a local to apw issue or a general issue with graphics in the VMs [13:03] i would expect the unity lot to be moaning a lot if it doesn't work mind you [13:04] apw: the failures to start the domain happen (on Precise) on all tested versions. I will start monitoring for these paiting issues [13:05] hggdh, thanks [13:05] yw [13:22] apw: ah, i see. you're seeing the 'Auto-merging ...' messages, right? [13:22] apw: i guess i mixed up all the patches [13:23] * henrix should have sent all the patches separated, per serie [13:23] apw: if that's what you're complaining about, i just checked that the patch applies ok (i checked against the kernel i've tested) [13:24] apw: but i can resubmit the whole set [13:25] apw: i'll prepare the patches again, and send them again. this time, i'll send 5 different sets (L, O, P, Q and R) [13:37] henrix, no don't bother, i have applied them all now, you can make sure they are right on master-next once my build tests finish [13:38] apw: ok, cool. i'll do that. let me know when you push them [13:38] henrix, but for next time, i do tend to send out one series per release when it is complex, and say in teh 0/N which ones are identicle [13:39] apw: yeah, makes sense. will do that next time. its too easy to mess up the whole set... [13:40] apw: thanks [13:40] neither is ideal sadly, it is just a hard problem, people don't cope with lots of anything very well [13:40] heh, true. [13:41] * apw bets gomeisa is howling right now [13:42] it is ;) [13:42] fortunatly, my build ended already :) [13:44] load of 80, not bad [14:12] henrix, all pushed === chiluk_away is now known as chiluk [14:22] apw: Precise looks fine. shall i check all the others? [14:22] apw: also, want me to build test them, or you've done that already? [14:24] all build-tested, p was the most worrying, but you might pass an eye and make sure on the others [14:24] apw: ok, will do [14:37] apw: diff returned 0 changes from my trees, so they all look ok to me [14:42] henrix, yay brill thanks, at least i did something right today [14:42] :) [14:42] thanks [15:43] henrix, did you add the break-fix magic for 2012-4530 in the end? [15:43] apw: no, not yet. thank you for reminding me [15:44] henrix, i recon a :title() will work best on that one, using local-2012-4530, and the same in the tracker [15:45] apw: yep, makes sense. i'll check the examples and add that to that CVE [15:47] yeah so as it is a U: S: patch it won't pick up the upstream one when that comes [15:47] so we will have to be sensitive to that appearing [15:48] and switch the local-NNN to that sha1 when it arrives [15:49] apw: ok, i'll monitor that [15:49] * henrix hopes not to miss it... [15:50] yeah it is not idea, as it will drop off the radar probabally [15:50] as in no longer be on the matrix to remind us [15:51] i've added that to my todo list, so i'll see it everyday in my list [15:51] hopefully that'll be enough :) [15:58] apw: ok, just committed linux-overlay and cve-tracker [16:07] henrix, don't see the linux-overlay pushed ? [16:08] * henrix goes check.. [16:08] and hurry, :10 is when it all kickes off :) [16:08] apw: it should be now [16:08] heh, its done. i had forgot to press enter in the terminal :) [16:09] got it [16:09] looks right to me [16:09] cool [16:10] i added the two break-fix lines: one for the SHA1 and other for the local- [16:10] yep that look plausible [16:10] we'll know at about :45 [16:29] what is kworker? I've started seeing something called "kworker" listed recently when I run top. [16:30] I have server running with 32 core, it's says kworker/3:0 [16:31] kworker is a thread executing code on behalf of the kernel normally, code which needs a process context to allow it to sleep or the like and so cannnot be naturally executed as kernel code [16:31] i think the /3 suffix indicates it is a per-cpu kworker thread [16:31] for cpu #3 in this case [16:33] apw: please look my log http://paste.ubuntu.com/1452690/ [16:33] top out put [16:33] In my case running 32 cores [16:34] yes, and only top is runnig ? [16:35] dhanasekaran, nothing apparently unsusal about that output [16:36] apw: kworker/28:1 ? kworker/11:0 ? 28:1 what? and 11:0? what, i think 28 is mean by core and :1 means what? [16:41] do you have 32 cores or 32 threads, they may be the hyper-thread number i am not 100% sure off the top of my head [16:42] apw: what class of hardware? :-) [16:43] oh. nvm. [16:54] apw: hrm, which patch? [16:58] kees: he was referring to CVE-2012-4530, with commit d740269867021faf4ce38a449353d2b986c34a67 and the -mm patch exec-do-not-leave-bprm-interp-on-stack.patch [16:58] apw: btw, looks like the matrix has not been updated as i expected [16:58] * henrix goes back to see what's wrong [17:04] henrix: ah! yes. I'm still hoping akpm will send that to linus. [17:05] kees: me too :) [17:05] the other patch that went certainly helps, but doesn't strictly solve it. :) (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=d740269867021faf4ce38a449353d2b986c34a67) [17:06] kees: yes, we've applied that one for this CVE plus the -mm patch [17:07] henrix: Hrm, the bot seems to have failed its derivative security check. [17:08] henrix: https://bugs.launchpad.net/ubuntu/+source/linux-armadaxp/+bug/1087212 was a rebase including a CVE, the master bug had a promote-to-security, I thought we'd agreed that meant derivatives should also? [17:08] Launchpad bug 1087212 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1612.17 -proposed tracker" [Undecided,In progress] [17:08] (And I swear this worked on some other rebases...) [17:09] infinity, I'll take a look [17:09] herton: thanks :) [17:09] henrix: cool, great :) [17:10] herton: I'll leave the bug alone for now so you can look at it, but I'll release this kernel to both updates and security, as that's where it should go. [17:11] infinity, ack thanks [17:12] (Released) [17:12] herton: When you figure out what went wrong with it, feel free to set my tasks to Fix Released for me. :P [17:13] henrix, it seemed to not update the kteam-tools repo locally, not sure why [17:13] let it run at :20 and see then [17:14] apw: ack, thanks [17:14] infinity, sure, I'll take care of remaining status on the bug [17:17] herton: Danke. === johanbr_ is now known as johanbr === chiluk is now known as chiluk_away === chiluk_away is now known as chiluk === henrix is now known as henrix_ === bryce is now known as bryce2 === chiluk is now known as chiluk_away === lamont` is now known as lamont === bryce2 is now known as bryce === chiluk_away is now known as chiluk [23:11] is it expected that : include/linux/version.h is now under include/generated/uapi/linux/version.h or is this "temporary" ? [23:52] xnox: intended [23:53] Sarvatt: /me is going through pains of porting dkms module..... to this whole new uapi world order. It moved header files around as far as kernelnewbies is teaching me. [23:53] thanks. [23:54] yeah its a pain in the butt, all the blob video drivers needed fixing too [23:56] it's good medium & long term :] [23:57] this is me first time tinkering with kernel related stuff. But I guess modules is not really kernel hacking...