[01:12] How does it happen. 3.8, no microphone. 3.9 microphone but no usb camera. === Traxer|on is now known as Traxer === smb` is now known as smb [08:15] infinity, Do you happen to be awake? [08:18] activation/volume_list configuration setting not defined: Checking only host tags for datavg/smarm-s32 [08:18] datavg/smarm-s64 is active exclusive locally [08:18] Locking LV grYo1SGxtnZW9nKNg12eDppfJtGHwsZecfziYaHzn4KqomE8EJcIrmMxBJRjRHgK (R) [08:18] smb, ^^ [08:19] * smb scratches his head [08:24] seems like i've to update my email cfg... uh... [08:44] ppisati, oh crap, that means i have to too [08:44] apw: if you didn't opt-out, then yes, you have too [08:45] FWIW, i took 5mins, everything seems to be ok here [08:45] ppisati, care to /msg me any pointers you have :) [08:45] apw: i just had to change imap server/pwd [08:47] ppisati, was your email moved over, your old email ? [08:47] apw: yep [08:47] ppisati, bugger [08:56] but i don't new emails... uhmm... [08:56] *don't get [09:16] 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] apw: i'm redownloading all my emails right now === ivoks_ is now known as ivoks [09:17] ppisati, i am assuming i will not move mail email across now as a local cache anyhow [09:17] apw: i see [10:29] * ppisati -> workout [13:09] smb, remembered to file that bug: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1183346 [13:09] Ubuntu bug 1183346 in lvm2 (Ubuntu) "vgcahnge -a n removed dm mappings but they come back immediatly" [Undecided,New] [13:11] apw, Ah cool. Now we only need to find out whom to annoy about that whole plumbing thing [13:11] yeah [13:11] 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] him or maybe xnox ... [13:13] smb: apw: sounds like a dupe. [13:14] apport didn't offer me any to choose from, though i guess that might be my spelling [13:14] xnox, got a reference to the original [13:14] 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] imho - we shouldn't trigger activation on change event (which is emitted in addition to the removed event) [13:15] apw: yeap, let me look it up. [13:15] but I'm not certain, what would be the consequence of removing such trigger. [13:16] no indeed [13:16] xnox, but early in saucy is a perfect time to test such scarey changes [13:17] 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] apw, IIRC you said the change event is for the now free underlying /dev/sd?? [13:25] apw: marked as duplicate of bug 1088081 [13:25] 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] 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] xnox, ta [13:33] smb, though that begs the question what does dmsetup remove do different that stops that happening [13:33] 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] Yeah, good question [13:35] it does the same stuff looking at udev, but we get no sda2 event, so there is a subtlty [13:35] i bet this is a bug in the libdm in lvm2 [13:44] apw, One difference seems to be that lvm2 depends on libdevmapper-events (which the same source produces) while dmsetup does not [13:46] hmmm [14:04] hallyn: hey, are you running an up to date saucy kernel with the stock lxcbr0? [14:04] stgraber: no, not yet [14:05] will probably upgrade everything this weekend [14:05] hallyn: ok, I think the current kernel breaks dhclient [14:05] hm. i've got a canonistack instance set up, lemme try it [14:06] rtg: 3.10 needs several patches so it compiles on arm (broken non-arch related drivers) [14:06] 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] hallyn: then dhclient gets a DHCP packet without checksum and ignores it [14:06] rtg: most of them are already published on linux-kernel ml [14:07] marvin24, I imagine they'll get hoovered up sometime before Linus releases [14:07] stgraber: yeah... [14:07] 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] why the hell would veth do that? [14:07] rtg: it seems to me that some got lost [14:08] rtg: I'll try to trigger the relevant people ... [14:08] hallyn: my assumption being that this breaks LXC containers that runs anything earlier than quantal [14:09] hallyn: it looks like something that changed with 3.9 (just managed to reproduce this with 3.9.0-0-generic) [14:15] 3.9 would be roughly consistent with my experience, yeah [14:15] 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] stgraber: flaky internet at home, heading out, will be back in a bit. [14:15] stgraber: sounds good. === kentb-out is now known as kentb [14:22] infinity: just to let you know the regression testing for linux-ti-omap4: 3.5.0-225.36 is still going on. [14:23] i've had to re-run them a couple of times due to lab maintenance [14:23] for bug 1180204 that is [14:23] 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] apw: I thought you were the expert on lvm/udev ;) [14:31] slangasek, i am fingering smb (phnar) for this [14:32] apw, phnar? [14:54] robher_: do you know that cpu hotplug doesn't work on highbank? [14:55] robher_: i saw the support was committed together with the initial platform support in 3.2 [14:55] robher_: but it didn't work and it's still broken [14:59] stgraber: so with those SRUs done, openstack can drop the special iptables rules? [14:59] robher_: http://paste.ubuntu.com/5693960/ [14:59] hallyn: as long as you don't run any guest that doesn't have the patches (like Debian) [15:00] right [15:41] hey guys noticed something about a patch in 3.5: [15:41] git tag --contains f56d0eed546c83bbc5ad3052a809077341ce28f3 [15:41] shows this patch is in 3.5.0-225.36 / 29.49 / 31.52 [15:42] 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] maybe this is a henrix question ^^^ [15:44] arges: let me have a look... [15:46] arges: oh, i got it. [15:47] arges: we had an emergency kernel and that kernel was prepared in a branch [15:47] arges: while there was another kernel prepared in master that contained that commit [15:48] if you use gitk to visualise the branches its easy to understand this ;) [16:12] cjwatson: turns out porting a patch for isc-dhcp 4.2 to dhcp3 3.1 is a real pain ;) [16:15] stgraber: heh, not surprised [17:19] smb: I was awake when you pinged, but not at a computer, apparently. [17:21] 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] smb: Has your pet Andy failed to review and sponsor your stuff? [17:24] infinity, I try to not neglect my favourite sponsor [17:25] or the other one [17:25] And you refuse to say which is which, right? ;) [17:26] Of course. :) [17:28] 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] But then this update is a bit special so it might end up in your judgement anyway [17:34] 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] So, my issue is this: I have installed a custom kernel and headers that I am using. It works perfect [17:35] but I would like to completely remove the default ubuntu kernels from the repos [17:35] 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] 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] Its not a huge issue, I just dont like the clutter on my grub list [17:38] n0yd, its gonna be something of the form linux-image-{server,generic} [17:39] * rtg -> lunch [17:39] n0yd, dpkg -l | grep linux-image- [17:40] ahg ok, i never tried the generic image pkg [17:40] So that must be it [17:40] I just removed the normal image pkg and the two header packages [17:41] bjf: thank you very much for the help, gonna try it now [17:46] bjf: well, I just tested it. Works fine. Much thanks [18:06] * henrix -> EOD === bjf is now known as bjf[afk] [20:29] * rtg -> EOD [21:10] is there a way to make fakeroot debian/rules only rebuild what's needed to be rebuilt? [21:14] I've been using fdr binary-generic flavours=generic for development builds, but waiting 40 minutes between spins is slow! [21:36] plars: *poke* [21:36] infinity: hi [21:37] 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] looking [21:38] that would be... [21:38] https://launchpad.net/bugs/1181023 [21:38] Ubuntu bug 1181023 in Kernel SRU Workflow "linux-lts-raring: 3.8.0-22.33~precise1 -proposed tracker" [Medium,In progress] [21:38] https://launchpad.net/bugs/1181071 [21:38] Ubuntu bug 1181071 in Kernel SRU Workflow "linux-lts-quantal: 3.5.0-31.52~precise1 -proposed tracker" [Medium,In progress] [21:38] and, don't see the other one, but I'm not looking in the best place, one sec [21:38] And http://launchpad.net/bugs/1180358 [21:38] Ubuntu bug 1180358 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1432.41 -proposed tracker" [Medium,In progress] [21:39] right [21:39] was just about to paste [21:39] ok [21:40] 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] I'm not sure if I've heard back yet, still trying to deal with the chaos of mail filters today [21:41] will dig for that in a moment [21:41] Ahh. What was the problem? [21:41] infinity: a few failures, looked to be timeout related stuff in qrt [21:41] I suspect it just didn't cope with timing properly on the panda, but wanted some confirmation from one of them [21:42] the other two seem to have just arrived, I'll get those kicked off right now === kentb is now known as kentb-out