[01:12] <melkor> How does it happen. 3.8, no microphone. 3.9 microphone but no usb camera.
[08:15] <smb> infinity, Do you happen to be awake? 
[08:18] <apw>     activation/volume_list configuration setting not defined: Checking only host tags for datavg/smarm-s32
[08:18] <apw>       datavg/smarm-s64 is active exclusive locally
[08:18] <apw>       Locking LV grYo1SGxtnZW9nKNg12eDppfJtGHwsZecfziYaHzn4KqomE8EJcIrmMxBJRjRHgK (R)
[08:18] <apw> smb, ^^
[08:19]  * smb scratches his head
[08:24] <ppisati> seems like i've to update my email cfg... uh...
[08:44] <apw> ppisati, oh crap, that means i have to too
[08:44] <ppisati> apw: if you didn't opt-out, then yes, you have too
[08:45] <ppisati> FWIW, i took 5mins, everything seems to be ok here
[08:45] <apw> ppisati, care to /msg me any pointers you have :)
[08:45] <ppisati> apw: i just had to change imap server/pwd
[08:47] <apw> ppisati, was your email moved over, your old email ?
[08:47] <ppisati> apw: yep
[08:47] <apw> ppisati, bugger
[08:56] <ppisati> but i don't new emails... uhmm...
[08:56] <ppisati> *don't get
[09:16] <ppisati> apw: are you using offlineimap? if yes, i hit this: http://docs.offlineimap.org/en/latest/FAQ.html#what-is-the-uid-validity-problem-for-folder
[09:17] <ppisati> apw: i'm redownloading all my emails right now
[09:17] <apw> ppisati, i am assuming i will not move mail email across now as a local cache anyhow
[09:17] <ppisati> apw: i see
[10:29]  * ppisati -> workout
[13:09] <apw> smb, remembered to file that bug: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1183346
[13:09] <ubot2> Ubuntu bug 1183346 in lvm2 (Ubuntu) "vgcahnge -a n removed dm mappings but they come back immediatly" [Undecided,New]
[13:11] <smb> apw, Ah cool. Now we only need to find out whom to annoy about that whole plumbing thing
[13:11] <apw> yeah
[13:11] <apw> i would think slangasek would know best who knows the lvm/udev interactions best
[13:11]  * smb suspects lvm2 as package is not right but anyway
[13:12] <smb> him or maybe xnox ...
[13:13] <xnox> smb: apw: sounds like a dupe.
[13:14] <apw> apport didn't offer me any to choose from, though i guess that might be my spelling
[13:14] <apw> xnox, got a reference to the original
[13:14] <xnox> a long time ago keybuk & pitti (?! or possibly someone else from kernel/security from that time) actually came up with how it should properly behave.
[13:15] <xnox> imho - we shouldn't trigger activation on change event (which is emitted in addition to the removed event)
[13:15] <xnox> apw: yeap, let me look it up.
[13:15] <xnox> but I'm not certain, what would be the consequence of removing such trigger.
[13:16] <apw> no indeed
[13:16] <apw> xnox, but early in saucy is a perfect time to test such scarey changes
[13:17] <smb> xnox, apw Experimenting with a precise userspace + quantal kernel it seems that back then I do only get remove events
[13:18]  * smb wonders when and why the change event comes from
[13:18] <smb> apw, IIRC you said the change event is for the now free underlying /dev/sd??
[13:25] <xnox> apw: marked as duplicate of bug 1088081
[13:25] <ubot2> Launchpad bug 1088081 in lvm2 (Ubuntu) "udev rules make it impossible to deactivate lvm volume group with vgchange -an" [High,Confirmed] https://launchpad.net/bugs/1088081
[13:30] <apw> smb, that is correct, i believe as the sda2 is closed a change is generated telling you it is no longer locked exclusivly
[13:30] <apw> xnox, ta
[13:33] <apw> smb, though that begs the question what does dmsetup remove do different that stops that happening
[13:33] <smb> Ah, interesting. That dupe bug rather seems to indicate that udev is creating the change event and not the kernel (which was not completely clear to me)
[13:33] <smb> Yeah, good question
[13:35] <apw> it does the same stuff looking at udev, but we get no sda2 event, so there is a subtlty
[13:35] <apw> i bet this is a bug in the libdm in lvm2
[13:44] <smb> apw, One difference seems to be that lvm2 depends on libdevmapper-events (which the same source produces) while dmsetup does not
[13:46] <apw> hmmm
[14:04] <stgraber> hallyn: hey, are you running an up to date saucy kernel with the stock lxcbr0?
[14:04] <hallyn> stgraber: no, not yet
[14:05] <hallyn> will probably upgrade everything this weekend
[14:05] <stgraber> hallyn: ok, I think the current kernel breaks dhclient
[14:05] <hallyn> hm.  i've got a canonistack instance set up, lemme try it
[14:06] <marvin24> rtg: 3.10 needs several patches so it compiles on arm (broken non-arch related drivers)
[14:06] <stgraber> hallyn: not sure if you're familiar with the dhclient UDP checksum offloading issue that affected virtio, basically the kernel tries to be clever and not compute the checksum when on a virtual device
[14:06] <stgraber> hallyn: then dhclient gets a DHCP packet without checksum and ignores it
[14:06] <marvin24> rtg: most of them are already published on linux-kernel ml
[14:07] <rtg> marvin24, I imagine they'll get hoovered up sometime before Linus releases
[14:07] <hallyn> stgraber: yeah...
[14:07] <stgraber> hallyn: that used to be limited to virtio and libvirt has been working around it for a while by using a mangle rule, but now cjwatson just reported the same happening with veth devices (and I reproduced it here quite easily)
[14:07] <hallyn> why the hell would veth do that?
[14:07] <marvin24> rtg: it seems to me that some got lost
[14:08] <marvin24> rtg: I'll try to trigger the relevant people ...
[14:08] <stgraber> hallyn: my assumption being that this breaks LXC containers that runs anything earlier than quantal
[14:09] <stgraber> hallyn: it looks like something that changed with 3.9 (just managed to reproduce this with 3.9.0-0-generic)
[14:15] <cjwatson> 3.9 would be roughly consistent with my experience, yeah
[14:15] <stgraber> hallyn: so I think what I'll do is upload the remaining two SRUs for this (lucid and precise) adding the needed code to dhclient to deal with the missing checksums.
[14:15] <hallyn> stgraber: flaky internet at home, heading out, will be back in a bit.
[14:15] <hallyn> stgraber: sounds good.
[14:22] <psivaa> infinity: just to let you know the regression testing for linux-ti-omap4: 3.5.0-225.36 is still going on. 
[14:23] <psivaa> i've had to re-run them a couple of times due to lab maintenance 
[14:23] <psivaa> for bug 1180204 that is 
[14:23] <ubot2> Launchpad bug 1180204 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.5.0-225.36 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1180204
[14:31] <slangasek> apw: I thought you were the expert on lvm/udev ;)
[14:31] <apw> slangasek, i am fingering smb (phnar) for this
[14:32] <smb> apw, phnar?
[14:54] <ppisati> robher_: do you know that cpu hotplug doesn't work on highbank?
[14:55] <ppisati> robher_: i saw the support was committed together with the initial platform support in 3.2
[14:55] <ppisati> robher_: but it didn't work and it's still broken
[14:59] <hallyn> stgraber: so with those SRUs done, openstack can drop the special iptables rules?
[14:59] <ppisati> robher_: http://paste.ubuntu.com/5693960/
[14:59] <stgraber> hallyn: as long as you don't run any guest that doesn't have the patches (like Debian)
[15:00] <hallyn> right
[15:41] <arges> hey guys noticed something about a patch in 3.5:
[15:41] <arges> git tag --contains f56d0eed546c83bbc5ad3052a809077341ce28f3
[15:41] <arges> shows this patch is in 3.5.0-225.36 / 29.49 / 31.52
[15:42] <arges> but it seems to not be in 3.5.0-30.51 ? why would it have been dropped in an inbetween release? (its a linux-stable patch)
[15:42] <arges> maybe this is a henrix question ^^^
[15:44] <henrix> arges: let me have a look...
[15:46] <henrix> arges: oh, i got it.
[15:47] <henrix> arges: we had an emergency kernel and that kernel was prepared in a branch
[15:47] <henrix> arges: while there was another kernel prepared in master that contained that commit
[15:48] <henrix> if you use gitk to visualise the branches its easy to understand this ;)
[16:12] <stgraber> cjwatson: turns out porting a patch for isc-dhcp 4.2 to dhcp3 3.1 is a real pain ;)
[16:15] <cjwatson> stgraber: heh, not surprised
[17:19] <infinity> smb: I was awake when you pinged, but not at a computer, apparently.
[17:21] <smb> infinity, That was the other possibility. It was just my routine of trying to push forward with the Xen updates business. If possible.
[17:23] <infinity> smb: Has your pet Andy failed to review and sponsor your stuff?
[17:24] <smb> infinity, I try to not neglect my favourite sponsor
[17:25] <smb> or the other one
[17:25] <infinity> And you refuse to say which is which, right? ;)
[17:26] <smb> Of course. :)
[17:28] <smb> infinity, Somehow it more or less ends up in a split of xen you and the rest apw. That may result in a slight imbalance currently
[17:28] <smb> But then this update is a bit special so it might end up in your judgement anyway
[17:34] <n0yd> Hi, I know this isnt ubuntu support per se. But I have already asked in two support channels, and waited quite awhile. And no one can answer me
[17:34] <n0yd> So, my issue is this:  I have installed a custom kernel and headers that I am using. It works perfect
[17:35] <n0yd> but I would like to completely remove the default ubuntu kernels from the repos
[17:35] <n0yd> I know how to just simply remove them via apt, but there seems to be a meta package that causes them to reinstall when I do an upgrade
[17:36] <n0yd> I dont know which meta package it might be, or even how to find it.  I figured you since a lot of you test kernels often, someone might know how to stop the default kernels from installing themselves
[17:36] <n0yd> Its not a huge issue, I just dont like the clutter on my grub list
[17:38] <rtg> n0yd, its gonna be something of the form linux-image-{server,generic}
[17:39]  * rtg -> lunch
[17:39] <bjf> n0yd, dpkg -l | grep linux-image-
[17:40] <n0yd> ahg ok, i never tried the generic image pkg
[17:40] <n0yd> So that must be it
[17:40] <n0yd> I just removed the normal image pkg and the two header packages
[17:41] <n0yd> bjf: thank you very much for the help, gonna try it now
[17:46] <n0yd> bjf: well, I just tested it.  Works fine. Much thanks
[18:06]  * henrix -> EOD
[20:29]  * rtg -> EOD
[21:10] <chiluk> is there a way to make fakeroot debian/rules only rebuild what's needed to be rebuilt?
[21:14] <chiluk> I've been using fdr binary-generic flavours=generic      for development builds, but waiting 40 minutes between spins is slow!
[21:36] <infinity> plars: *poke*
[21:36] <plars> infinity: hi
[21:37] <infinity> plars: How long would it take to get the regression-testing task closed out for the last three SRU kernels (ti-omap4/precise, lts-quantal/precise, lts-raring/precise)?
[21:37] <plars> looking
[21:38] <plars> that would be...
[21:38] <plars> https://launchpad.net/bugs/1181023
[21:38] <ubot2> Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress]
[21:38] <plars> https://launchpad.net/bugs/1181071
[21:38] <ubot2> Ubuntu bug 1181071 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-31.52~precise1 -proposed tracker" [Medium,In progress]
[21:38] <plars> and, don't see the other one, but I'm not looking in the best place, one sec
[21:38] <infinity> And http://launchpad.net/bugs/1180358
[21:38] <ubot2> Ubuntu bug 1180358 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1432.41 -proposed tracker" [Medium,In progress]
[21:39] <plars> right
[21:39] <plars> was just about to paste
[21:39] <plars> ok
[21:40] <plars> so on 1180358, I hit a problem, pinged bjf[afk] and jdstrand about it
[21:40]  * infinity finds http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html is about the best place to keep track of where things are hung up.
[21:41] <plars> I'm not sure if I've heard back yet, still trying to deal with the chaos of mail filters today
[21:41] <plars> will dig for that in a moment
[21:41] <infinity> Ahh.  What was the problem?
[21:41] <plars> infinity: a few failures, looked to be timeout related stuff in qrt
[21:41] <plars> I suspect it just didn't cope with timing properly on the panda, but wanted some confirmation from one of them
[21:42] <plars> the other two seem to have just arrived, I'll get those kicked off right now