=== BenC- is now known as BenC
[02:53] <jjohansen> JayF: I dug into the oneiric-lts-backport kernel and the fix is not there, I am not sure what you are seeing
[04:20] <infinity> jjohansen: I'm guessing he was looking at sw_perf_event_destroy instead of perf_swevent_init?  Maybe?
[04:20] <infinity> jjohansen: Yeah, he referenced line 5433, which is in the declaration of the previous function.
[04:21] <infinity> JayF: ^^
[04:30] <jjohansen> yeah
[12:24] <bjf> smb, bug 1164739
[12:24] <ubot2> Launchpad bug 1164739 in linux (Ubuntu Quantal) "Can not mount cephfs in VM from cloud image" [Medium,Fix committed] https://launchpad.net/bugs/1164739
[12:24] <bjf> smb, do we need to verify it or is it trivial enough to just mark it verified ?
[12:25] <bjf> smb, can you verify or have someone verify it?
[12:29] <henrix> bjf: iirc smb is off today
[12:30] <rtg_> bjf, try hassling james Hunt. I think he's the ceph cloud dude
[12:33] <bjf> jodh, ^ ?
[12:34] <jodh> bjf/rtg_: you have the wrong guy. I've never used ceph :)
[12:36] <bjf> jodh, interested in learning ? :-)
[12:37] <bjf> jodh, i think rtg probably meant james page
[12:43]  * cking takes a short break, back in 15
[13:08] <rtg_> henrix, cking: bouncing gomeisa for kernel update
[13:08] <cking> rtg_, ack
[13:08] <rtg_> when henrix build is done
[13:08] <henrix> rtg_: can you wait 5 mins? just finishing a build
[13:09] <henrix> rtg_: thanks, shouldn't take long
[13:13] <henrix> rtg_: gomeisa is now free
=== henrix_ is now known as henrix
=== kentb-out is now known as kentb
[14:27] <tseliot> apw: are you around?
[14:27] <apw> tseliot, sort of, not so good today
[14:42] <psivaa> bjf, just managed to saucy jobs for kernel regression tests
[14:42] <psivaa> bjf, there is this, http://pastebin.ubuntu.com/5674186/ with 3.9.0-2.6 in almost all the saucy regression kernel tests.
[14:44] <rtg_> jjohansen, is that your test ? ^^
[14:45] <stgraber> cking: heya. You may want to s/14.10/13.10/ in your lttng blog post :)
[14:46] <stgraber> (spotted by the #lttng guys)
[14:46] <cking> stgraber, bah, I'm in a time machine mode again
[14:46] <cking> thanks :-)
[14:46] <stgraber> ;)
[14:47] <bjf> psiva, let me look. i may have to update a file on my end for saucy
[14:48] <psivaa> bjf: ack
[15:11] <bjf> psivaa, jjohansen indeed, this looks like my issue
[15:12] <psivaa> bjf: ack
[15:26] <bjf> psiva, just sent out a new release email that should address this issue.
=== slangase` is now known as slangasek
[15:39] <psivaa> bjf: ack, got it. thanks
[15:52] <JayF> infinity: TYVM for that update. Do you have a better link for a full patch than what I was looking at then so I can ensure my kernel is properly patched?
[16:01]  * henrix -> back in 15
=== ferai is now known as jefferai
[16:40] <rbasak> ogasawara: any objection to documenting the DKMS situation with the HWE stack on https://wiki.ubuntu.com/Kernel/LTSEnablementStack? Or would you prefer that somewhere else? It would be nice to have something to point bug reporters to.
[16:42] <ogasawara> rbasak: you mean about the point I mentioned for trying to ensure we test DKMS packages against the HWE stacks
[16:43] <ogasawara> rbasak: I'm leaning towards that residing somewhere else at the moment, as it's not a hardened policy/procedure
[16:43] <ogasawara> rbasak: I'm thinking it'll reside in a blueprint somewhere first, just not sure which one yet
[16:43] <ogasawara> rbasak: likely as a work item for me
[16:43] <rbasak> ogasawara: I'm not sure. I'm prompted by a bug report for a DKMS build failure on an HWE stack. I'd just like to document that some failures are known to exist right now, and that users who don't need the HWE stack but got it by default, and who need a particular DKMS module that is failing can use the old kernel for now.
[16:44] <rbasak> A bug tag might be useful too. How about hwe-dkms?
[16:44] <ogasawara> rbasak: definitely a meaningful tag to use across those types of DKMS bugs would be good
[16:45] <ogasawara> rbasak: hwe-dkms works for me
[16:46] <ogasawara> rbasak: let me give some more thought about where to document the use of that though and how to effectively communicate to anyone affected
[16:46] <rbasak> ogasawara: OK. Thanks!
[16:49] <rtg_> rbasak, are there reasons we shouldn't carry some of these packages in the kernel ? (though I'm not interested in binary blobs)
[16:50] <rbasak> rtg_: I think there are individual reasons for them not being in the upstream kernel. open-vm-tools is in multiverse, for example.
[16:51] <rtg_> rbasak, no, I meant in _our_ kernel tree.
[16:51] <ogasawara> rtg_: I'd prefer out kernel not becoming a dumping ground for drivers which have the ability to be DKMS'ified
[16:52] <rbasak> rtg_: what I mean is that if they aren't upstream, then the same reason might apply for not wanting them in our tree.
[16:52] <rtg_> ogasawara, I'm not implying we should take everything, but there are a couple of server drivers that might be of benefit.
[16:52] <ogasawara> rtg_: and if we (ie I) can get the proper QA in place so that DKMS package maintainers are notified of any breakage, it would have the same affect
[16:53] <rbasak> And for the ones that are not in main, would that cause an additional maintenance burden?
[16:53] <rtg_> dkms has the side effect of requiring compilers and such, something that many server operators are not fond of.
[16:57] <rbasak> openvswitch is probably the module that we care about the most. I'll ask jamespage about it.
[17:04] <rtg_> rbasak, it also solves the backport issue with the LTS kernels
[17:06] <rbasak> rtg_: it's around the same amount of work though, right? Either the DKMS package is forward-ported or someone finds upstream support and backports it, or your team does it by maintaining our tree?
[17:07]  * henrix -> eow
[17:07] <rtg_> rbasak, I'm kind of assuming its a one-time integration effort per release. for example, once done for saucy then the backport is free.
[17:07] <rtg_> rbasak, I'm only proposing this for high value, slow moving targets.
[17:08] <rtg_> hyper-v doesn't fall into taht category :)
[17:08] <rbasak> :)
[17:08] <rbasak> I'm guessing openvswitch does though. jamespage will know better.
[17:09] <rbasak> I'm probably just an extra cook to spoil this broth though. I should step out and let jamespage discuss it here. I've updated him in #ubuntu-server since he's not on this channel, and I'll step out now. Thanks for discussing this!
[17:24]  * rtg_ should never let LKML get to over 5500+ unread emails
[17:47]  * rtg_ -> lunch
[20:48]  * rtg_ -> EOW
[21:19] <sscorrea> /echo $version