[05:52] <nevyn> 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] <apw> 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
[09:30] <apw> hggdh, you guys do a bunch of kvm based testing right?  had any problems with recent rarings ?
[12:48] <apw> henrix, this CVE with kees patch, have we asked security to add the POC to the QR tests ?
[12:49] <henrix> apw: no, i haven't done that
[12:49] <henrix> i guess i should :)
[12:49] <henrix> i'll ping jj about that
[12:50] <apw> thanks :)
[12:50]  * henrix -> lunch
[12:51] <apw> henrix, this -ELOOP patch, for P doesn't apply
[12:52] <apw> well without fuzz anyhow
[12:52] <apw> is that to be expected
[12:59] <hggdh_> 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] <apw> hggdh_, i am seeing corrupt background in my raring vms backed by precise, all crosshatchy, wondered if you had seen similar
[13:01] <apw> 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] <hggdh_> 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
[13:03] <apw> 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] <apw> i would expect the unity lot to be moaning a lot if it doesn't work mind you
[13:04] <hggdh> apw: the failures to start the domain happen (on Precise) on all tested versions. I will start monitoring for these paiting issues
[13:05] <apw> hggdh, thanks
[13:05] <hggdh> yw
[13:22] <henrix> apw: ah, i see. you're seeing the 'Auto-merging ...' messages, right?
[13:22] <henrix> apw: i guess i mixed up all the patches
[13:23]  * henrix should have sent all the patches separated, per serie
[13:23] <henrix> 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] <henrix> apw: but i can resubmit the whole set
[13:25] <henrix> 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] <apw> 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] <henrix> apw: ok, cool.  i'll do that. let me know when you push them
[13:38] <apw> 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] <henrix> apw: yeah, makes sense. will do that next time. its too easy to mess up the whole set...
[13:40] <henrix> apw: thanks
[13:40] <apw> neither is ideal sadly, it is just a hard problem, people don't cope with lots of anything very well
[13:40] <henrix> heh, true.
[13:41]  * apw bets gomeisa is howling right now
[13:42] <henrix> it is ;)
[13:42] <henrix> fortunatly, my build ended already :)
[13:44] <apw> load of 80, not bad
[14:12] <apw> henrix, all pushed
[14:22] <henrix> apw: Precise looks fine. shall i check all the others?
[14:22] <henrix> apw: also, want me to build test them, or you've done that already?
[14:24] <apw> all build-tested, p was the most worrying, but you might pass an eye and make sure on the others
[14:24] <henrix> apw: ok, will do
[14:37] <henrix> apw: diff returned 0 changes from my trees, so they all look ok to me
[14:42] <apw> henrix, yay brill thanks, at least i did something right today
[14:42] <henrix> :)
[14:42] <henrix> thanks
[15:43] <apw> henrix, did you add the break-fix magic for 2012-4530 in the end?
[15:43] <henrix> apw: no, not yet. thank you for reminding me
[15:44] <apw> henrix, i recon a :title() will work best on that one, using local-2012-4530, and the same in the tracker
[15:45] <henrix> apw: yep, makes sense. i'll check the examples and add that to that CVE
[15:47] <apw> yeah so as it is a U: S: patch it won't pick up the upstream one when that comes
[15:47] <apw> so we will have to be sensitive to that appearing
[15:48] <apw> and switch the local-NNN to that sha1 when it arrives
[15:49] <henrix> apw: ok, i'll monitor that
[15:49]  * henrix hopes not to miss it...
[15:50] <apw> yeah it is not idea, as it will drop off the radar probabally
[15:50] <apw> as in no longer be on the matrix to remind us
[15:51] <henrix> i've added that to my todo list, so i'll see it everyday in my list
[15:51] <henrix> hopefully that'll be enough :)
[15:58] <henrix> apw: ok, just committed linux-overlay and cve-tracker
[16:07] <apw> henrix, don't see the linux-overlay pushed ?
[16:08]  * henrix goes check..
[16:08] <apw> and hurry, :10 is when it all kickes off :)
[16:08] <henrix> apw: it should be now
[16:08] <henrix> heh, its done. i had forgot to press enter in the terminal :)
[16:09] <apw> got it
[16:09] <apw> looks right to me
[16:09] <henrix> cool
[16:10] <henrix> i added the two break-fix lines: one for the SHA1 and other for the local-
[16:10] <apw> yep that look plausible
[16:10] <apw> we'll know at about :45
[16:29] <dhanasekaran> what is kworker?  I've started seeing something called "kworker" listed recently when I run top. 
[16:30] <dhanasekaran> I have server running with 32 core, it's says kworker/3:0
[16:31] <apw> 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] <apw> i think the /3 suffix indicates it is a per-cpu kworker thread
[16:31] <apw> for cpu #3 in this case
[16:33] <dhanasekaran> apw: please look my log http://paste.ubuntu.com/1452690/
[16:33] <dhanasekaran> top out put
[16:33] <dhanasekaran> In my case running 32 cores
[16:34] <apw> yes, and only top is runnig ?
[16:35] <apw> dhanasekaran, nothing apparently unsusal about that output
[16:36] <dhanasekaran> 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] <apw> 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] <Nafallo> apw: what class of hardware? :-)
[16:43] <Nafallo> oh. nvm.
[16:54] <kees> apw: hrm, which patch?
[16:58] <henrix> 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] <henrix> 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] <kees> henrix: ah! yes. I'm still hoping akpm will send that to linus.
[17:05] <henrix> kees: me too :)
[17:05] <kees> 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] <henrix> kees: yes, we've applied that one for this CVE plus the -mm patch
[17:07] <infinity> henrix: Hrm, the bot seems to have failed its derivative security check.
[17:08] <infinity> 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] <ubot2`> Launchpad bug 1087212 in linux-armadaxp (Ubuntu Precise) "linux-armadaxp: 3.2.0-1612.17 -proposed tracker" [Undecided,In progress]
[17:08] <infinity> (And I swear this worked on some other rebases...)
[17:09] <herton> infinity, I'll take a look
[17:09] <henrix> herton: thanks :)
[17:09] <kees> henrix: cool, great :)
[17:10] <infinity> 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] <herton> infinity, ack thanks
[17:12] <infinity> (Released)
[17:12] <infinity> herton: When you figure out what went wrong with it, feel free to set my tasks to Fix Released for me. :P
[17:13] <apw> henrix, it seemed to not update the kteam-tools repo locally, not sure why
[17:13] <apw> let it run at :20 and see then
[17:14] <henrix> apw: ack, thanks
[17:14] <herton> infinity, sure, I'll take care of remaining status on the bug
[17:17] <infinity> herton: Danke.
[23:11] <xnox> is it expected that : include/linux/version.h is now under include/generated/uapi/linux/version.h or is this "temporary" ?
[23:52] <Sarvatt> xnox: intended
[23:53] <xnox> 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] <xnox> thanks.
[23:54] <Sarvatt> yeah its a pain in the butt, all the blob video drivers needed fixing too
[23:56] <ohsix> it's good medium & long term :]
[23:57] <xnox> this is me first time tinkering with kernel related stuff. But I guess modules is not really kernel hacking...