[00:40] <rsalveti> apw: mind taking care of https://bugs.launchpad.net/ubuntu/+source/linux-manta/+bug/1412543 ?
[00:40] <ubot5> Launchpad bug 1412543 in Canonical System Image "udev bridge fails to get events from kernel (missing FHANDLE)" [High,Confirmed]
=== gerald is now known as Guest3853
[09:20] <apw> rsalveti, see it
=== morgan is now known as yossarianuk
[09:23] <yossarianuk> chris112: you can use the 3.18.x kernels from mainline in 14.10 
[09:25] <yossarianuk> the kernels in mainline ppa use the version they are targeted for - however just because 3.18 doesn't have 'utopic' in the version names does't mean they don't work in utopic ...
=== hugbot is now known as swordsmanz
[11:13] <chris112> yossarianuk, thx for the info. is it save to use the btrfs tools of utopic?
[11:19] <yossarianuk> chris112: that I am not 100% sure of.
[11:20] <yossarianuk> (not used btrfs in ubuntu yet at all - only opensuse / neptuneos)
[12:11] <rsalveti> apw: thanks
[12:11] <apw> rsalveti, i am assuming the normal plan and uploading them to the CKT PPA
[12:11] <rsalveti> apw: yeah, just ping me once you get the packages in there
[12:11] <rsalveti> I'll validate and copy them around
[12:12] <apw> rsalveti, will do, mako is building, working on the otehrs now
[12:12] <rsalveti> great, thanks a lot
=== spideyman is now known as Guest32025
[12:57] <apw> rsalveti, ok it is all uploaded and building ... should be done in about an hour
[13:09] <Odd_Bloke> I'm running the kernel tests in an Azure instance and have got to: https://pastebin.canonical.com/123777/
[13:09] <Odd_Bloke> Nothing has happened in almost 20 minutes.
[13:09] <Odd_Bloke> Is this a slow test, or has something broken?
[13:13] <apw> Odd_Bloke, is that the ASLR test, i think it has to try several thousand times to check the distribution is random
[13:13] <apw> Odd_Bloke, i cannot however say that i have run those recently to have a feel for how long
[13:17] <smb> Yeah that test runs ages
[13:23] <smb> ages being something of 40min+ depending on hw 
[13:28] <rsalveti> apw: thanks
[15:00] <thell> Hello. After a year of having hardware that seemed to enjoy crashing (almost daily) I now have a stable (for a week) non crashing core i7 4700MQ with i915 video driver while running Utopic with 3.19rc4! Woohoo!
[15:00] <thell> My question is: What should I be monitoring for backporting of changes (I presume it was something in the drm-intel-next in Dec) to get back inline with Utopic kernels?
[15:33] <Odd_Bloke> apw: smb: Thanks for the info.
[15:36] <jsalisbury> ##
[15:36] <jsalisbury> ## Kernel team meeting today @ 17:00 UTC
[15:36] <jsalisbury> ##
[15:37] <trippeh> thell: there was just a bunch of intel gfx fixes that went into the upstream stable trees (not released yet)
[15:38]  * thell cheers!
[15:39] <thell> trippeh: I assume I should watch the changes file in the utopic kernel releases. Do you have a link of where you saw this so I can have an idea of what to watch for?
[16:28] <dsmythies> I'll ask my questions after a few lines, they are related to (are exactly):
[16:28] <bjf> cmagina, can you verify LP: #1404335 ?
[16:28] <ubot5> Launchpad bug 1404335 in linux (Ubuntu) "xgene: BUG: soft lockup - CPU#0 stuck for 23s! [halt:2059] on poweroff" [Medium,Confirmed] https://launchpad.net/bugs/1404335
[16:28] <dsmythies> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765717
[16:28] <ubot5> Debian bug 765717 in src:linux "linux-image-3.16-2-amd64: High CPU load with linux-image-3.16-2-amd64" [Normal,Fixed]
[16:28] <dsmythies> https://lkml.org/lkml/2014/11/5/905
[16:29] <dsmythies> The patch was submitted on Nov 6th, which I assume was in time for the 3.19 merge window, but it still doesn't appear in 3.19RC5.
[16:29] <dsmythies> I cannot find any other references for it, nor any "ACK".
[16:29] <dsmythies> Is there any to determine the status of the patch? Or might it be in limbo?
[16:29] <dsmythies> Should I enter a launchpad bug report to track the issue within the Ubuntu context?
[16:32] <apw> dsmythies, that sounds familiar
[16:34] <dsmythies> apw, I was helping someone on Ubuntu forums with this issue. I saw you made a post on another thread there yesterday. I am now wondering how to follow up to ensure this get resolved.
[16:37] <apw> dsmythies, ok the one i thought it was, it wasn't :) ... so ... yes please lets file a bug against "linux", using "ubuntu-bug linux"
[16:37] <dsmythies> O.K. thanks.
[16:50] <jsalisbury> ##
[16:50] <jsalisbury> ## Ubuntu Kernel Team Meeting - in 10 minutes - #ubuntu-meeting
[16:50] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ## Meeting starting now
[17:00] <jsalisbury> ##
=== jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues January 27th, 2015 - 17:00 UTC || If you have a question just ask, and do wait around for an answer!  If the question is should I file a bug for something, likely you can assume yes.
[17:42] <Odd_Bloke> I'm beginning to think we may need to skip that stack collision test on (at least) Azure; about to hit the three hour mark. >.<
[17:44] <apw> Odd_Bloke, you may be able to change the iteration count on that one, though it is likely hard coded
[17:46] <Odd_Bloke> apw: It is hard-coded, regrettably.
[17:46] <apw> Odd_Bloke, well "patch" can fix it then
[17:47] <apw> if [ on hypervisor ]; then patch -p1 hyperv.patch
[17:47] <Odd_Bloke> Ah, good point.
[17:48] <apw> Odd_Bloke, it would be good to let one finish to find out how how long a "bazillion" iterations take, so you have a framework to work out a good "finish in 10m" number :)
[17:48] <Odd_Bloke> Will see how it does on GCE (currently running the full qa suite there) to decide how to go about it.
[17:48] <Odd_Bloke> Yeah, will definitely leave it going in to the evening.
[17:50] <apw> Odd_Bloke, though ... it would be a lot more sensible if the iterations stuff did somethign saner, liek "run for 5m" 
[17:50] <apw> Odd_Bloke, and it would maek a lot of sense to tell #security that this is out of control slow, and get a recommendation
[17:51] <apw> Odd_Bloke, they may say ... if it isn't at least 10k iters its not worth doing sort of thing
[17:52] <Odd_Bloke> Yeah, good idea.
[17:53] <Odd_Bloke> I'll probably also look at splitting it out of the main run (in a downstream semi-hacky sort of a way) so it can get its own instance to run on.
[17:54] <Odd_Bloke> That'll let us run it in parallel with the other tests, so it taking X minutes will be slightly less painful.
[17:55] <apw> Odd_Bloke, a good plan, if you come up with a way to run the tests as groups or whatever "--not-aslr" "--not-all --aslr" or whatever, we should feed that back to the master
[18:01] <Odd_Bloke> Sounds like a problem for Tomorrodd_Bloke.
[18:02] <apw> Odd_Bloke, :) i know that man
[19:45] <soee> hi, gusy when 3.18.3 will make its way into Vivid ?
=== pgraner is now known as pgraner-afk
[21:45] <apw> soee, after the freeze for A2
[22:16] <soee> apw: thank you
[22:56]  * RAOF looks for a target to poor bees into.
=== SturmFlut is now known as SturmFlut|AFK