[00:05] <cyphermox> herton: right, we don't want to revert this, it's going to be in backported kernels too
[00:05] <cyphermox> I think I'll cherry-pick a patc
[00:05] <herton> ack
[00:05] <cyphermox> a patch from NM to fix up this detection code, should make everything work again.
[00:05] <cyphermox> (and will be future-proof)
[00:06] <herton> cyphermox, ok cool. I'll mark the linux tak invalid
[00:06] <herton> *task
[00:06] <cyphermox> herton: thanks
[05:14] <ppisati> moin
[06:26] <ppisati> brb
[07:07] <verwilst> apw, one gfs2 bug squashed, another one pops up :P
[07:18] <verwilst> i kinda feel like i'm the only ubuntu user that uses gfs2 :P
[07:18] <verwilst> ( which probably is pretty true :) )
[07:55] <apw> ppisati, moin
[09:03] <ppisati> i've a problem with my mutt setup: from time to time, it seems to hang there... grrrr...
[11:41]  * henrix -> lunch
[13:14] <ogasawara> rtg: I'm gonna prep an upload, anything you need to push before I kick off test builds?
[13:15] <rtg> ogasawara, do you think 3.5.3 will land today ?
[13:15] <ogasawara> rtg: I am expecting it soonish.  I do plan on doing another upload tuesday before beta-1 freeze, so we can pick it up then if it does land.
[13:16] <rtg> I guess if it does we can still upload next week
[13:16] <rtg> ogasawara, fire away
[14:19] <rtg> ogasawara, did I mention I pushed ubuntu-r v3.6-rc3 yesterday ? still got some armhf build problems that I'll go after today.
[14:19] <ogasawara> rtg: ah cool, thanks
[14:19] <rtg> ogasawara, should prolly sync with Quantal as well
[14:20] <ogasawara> rtg: I need to get back in the habit of pushing to both
[14:21] <rtg> ogasawara, I've got the checkpoint tag. I'll just go through and apply the relevant patches from Quantal
[14:38]  * ogasawara back in 20
[17:15] <herton> rtg, I'm still looking at that gso stuff. If I didn't got it wrong, netif_needs_gso is true if we are going to emulate the GSO stuff, that's why we return 1 there. But I think I was wrong about using the check inside netif_needs_gso for Lucid, seems the features flags from the device can also be used later, eg., inside dev_gso_segment->skb_gso_segment which also calls skb_gso_ok inside it 
[17:17] <rtg> herton, I'm tempted to just dump the whole mess. I don't think it is really vulnerable, at least not like Precise and later are.
[17:19] <herton> rtg, seems to depend on the driver+hardware used for that CVE to be triggered
[17:19] <rtg> herton, agreed, so I'm not real concerned. its more of a PITA then its worth.
[17:20] <herton> rtg, only sfc is using that gso_max_segs, so probably is the only one affected
[17:23] <herton> actually, since other drivers don't set gso_max_segs, it seems only sfc is doing gso...
[17:49] <LoT> what's the latest Precise kernel that is not in -proposed?
[17:52] <bjf> LoT: 3.2.0-29.46
[17:52] <LoT> in the latest precise kernel, did a rss-counter bug (fixed in 3.4.x) get patched?
[17:53] <LoT> bjf:  that's what i found, from checking the repos.  see last message
[17:53] <bjf> LoT: you could check the git repo to see if the commit you are interested in is there
[17:53] <LoT> not even sure what the commit was
[17:54] <LoT> i'm not a kernel expert, i'm being stabbed by a user of my shell(s) who claims they are a kernel expert...
[17:54] <bjf> LoT: there are likely over 150+ commits
[17:54] <LoT> saying we should upgrade to 3.4.xx
[17:54] <LoT> i said to them to shut up :p
[17:55] <rtg> ogasawara, repushed Ubuntu-R-sync and ubunt-r. I'll get the LTS packaged and built after lunch
[17:55] <ogasawara> rtg: ack
[17:55]  * rtg -> lunch
[18:00]  * cking messes up an rbd snapshot and calls it a week. fail
[18:21]  * cking -~> EOD
[18:48] <infinity> bjf: Are armadaxp and ti-omap4 being invalidated and re-based for precise to catch the same bugfix as master?
[19:06]  * ogasawara lunch
[20:25] <bjf> infinity: since that is the point of the bug fix, i'm assuming so though i've not heard anything about them specifically
[20:25] <bjf> infinity: and since the folks responsible for those two flavours are gone for the day ...
[20:27] <herton> bjf, infinity: the bot at least will open new bugs for ti-omap4 and armadaxp once the current master precise packages built on the ppa, they should get notification this way also
[20:27] <herton> *are built
[20:27] <bjf> herton, good point, thanks
[20:32] <infinity> herton: That seems odd.  Shouldn't the bot be opening derivative bugs when the source is uploaded, not when the binaries build?
[20:32] <infinity> herton: Seems like some unnecessary lead time, there.
[20:34] <herton> infinity, it was just to ensure the packages build and there are no other problems on the branch before the rebase, already happened that we had packages that failed to build one or other time, but could be changed
[20:50]  * rtg -> EOW
[21:08] <DanMD> Hey there everyone :), is there anyone out there with any experience building the ubuntu-precise kernel?
[21:09] <DanMD> I have a very strange issue.. Basically I am compiling one of the tags in the ubuntu-precise git repo, I am able to install it and everything works fine. However, if I try and build a kernel module for it, the kernel module cannot be inserted
[21:11] <DanMD> insmod will simply give me a "Killed" message and a line in dmesg says "BUG: unable to handle kernel paging request at ffff8800e018105e"
[21:34] <mjg59> DanMD: There's a bug in your kernel module
[21:36] <DanMD> mjg59: Thank you so much for replying!! I was thinking that as well, but I created my own kernel module that does nothing but printk, it doesn't actually contain any code.
[21:36] <DanMD> mjg59: Other than the module_init and module_exit functions
[21:37] <DanMD> mjg59: It seems like any module I try and create with the linux-headers package that was created in the build fails this way
[21:59] <DanMD> mjg59: Could there possibly be anything wrong with how I built the kernel?
[22:36] <xnox> bug 1038055 is now believed to be kernel issue
[22:36] <ubot2`> Launchpad bug 1038055 in ubiquity "cannot unlock LUKS devices, in kvm with cirrus graphics" [Undecided,Invalid] https://launchpad.net/bugs/1038055
[22:37] <xnox> specifically graphics fail to initialise correctly
[23:12] <slangasek> jsalisbury: ^^ xnox's bug #1038055 is a rather significant issue for quantal VMs running under kvm; can you get it on The List?
[23:12] <ubot2`> Launchpad bug 1038055 in ubiquity "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [Undecided,Invalid] https://launchpad.net/bugs/1038055