[09:56] <psivaa> henrix: hey, I'd like to know how to proceed further on bug  1321646. (Just making sure if it's not waiting on us :))
[09:56] <ubot5> bug 1321646 in Kernel SRU Workflow certification-testing "linux: 2.6.32-61.123 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1321646
[09:57] <henrix> psivaa: so, the fix has been committed and we will have a respin of that kernel.  brad was working on the respin yesterday
[09:57] <henrix> psivaa: basically, we're reverting 2 commits from lucid
[09:58] <psivaa> henrix: ack, so i'll keep watching the tracking bug :). thanks
[09:59] <henrix> psivaa: yeah, it will be updated soon, once brad uploads the fixed kernel ;)
[09:59] <psivaa> henrix: ack
[10:06] <infinity> The fixed kernel is uploaded.
[10:07] <infinity> psivaa: Do you need them in the archive to re-run your tests, or can you cherry-pick from the PPA?
[10:13] <psivaa> infinity: our automated tests pick the kernel from -proposed. cherry picking will be really time consuming
[10:14] <infinity> psivaa: Kay, I can copy it over right now for you to play with.
[10:14] <psivaa> infinity: ack, thanks
[10:16] <henrix> infinity: re. bug #1323980: you attached a new patch.  does that mean the bug is not fixed and you want us to respin T with this patch?
[10:16] <ubot5> bug 1323980 in debian-installer (Ubuntu Utopic) "Enable AHCI config on powerpc/ppc64el" [Undecided,New] https://launchpad.net/bugs/1323980
[10:16] <psivaa> infinity: the same case is for the ec2 lucid kernel as well, 
[10:16] <henrix> infinity: or are we still waiting for the bug verification?
[10:17] <infinity> henrix: bjf declined putting my patch in the current T kernel, we'll get it in next week's.
[10:18] <infinity> henrix: So, consider it verified enough to release, but not actually fixed until next cycle.
[10:18] <henrix> infinity: ah, ok.  thanks
[10:18] <infinity> psivaa: Right, I'll copy the ec2 one over too.
[10:23] <psivaa> infinity: ack, thx
[10:23] <infinity> psivaa: Both should hit the archive over the next 30-60m.
[10:24] <psivaa> infinity: great. thx. i'll run them in 90m
[10:25] <infinity> psivaa: How long would it take to retest the rest of the world, if I copy all the current respins and ask you to test them all? :P
[10:26] <psivaa> infinity: all release kernels? if so it may take a couple of days. but i could try to finish it asap. in some cases one test alone takes 4.5 hrs
[10:26] <infinity> psivaa: Kay, I might pass on that option then.
[10:29] <psivaa> infinity: ack
[12:53] <bjf> infinity, it's got to get to ktml first :-)
[12:55] <infinity> bjf: Bah, no other packages require patches on bugs to go through extra hoops. :P
[13:14] <bjf> infinity, we set the standard others try to follow
[13:39] <jodh> I noticed recently that kernel oops's were not getting reported via apport for me. The reason seems to be https://bugs.launchpad.net/ubuntu/+source/kerneloops/+bug/346303. Do we still not care about WARNING: oopses?
[13:39] <ubot5> Ubuntu bug 346303 in kerneloops (Ubuntu Lucid) "do not generate apport reports for non-critical kernel messages" [Low,Triaged]
[14:24] <apw> jodh, i don't think i knew about that ... hmmm
[14:25] <apw> who knows if that is current given the insertion of whoopsie into the mix
[14:25] <jodh> apw: yeah, quite! I also don't understand why we (and Debian) have such an old version of kerneloops (2009 - latest is 1 Dec 2011).
[14:26] <jodh> apw: I'm happy to raise an MP to take out that filter from the ubuntu patch?
[14:29] <jodh> apw: from a userland perspective it would be rather nice if there was something akin to /proc/sys/kernel/core_pattern for oopses to avoid the need to run yet-another-daemon that gropes in dmesg / /var/log/kern.log. However, I'm guessing that that may be frowned on by upstream since the kernel could be in an unknown state on oops and hence potentially impossible to fork an "oops helper"?
[14:29] <apw> right, that
[14:30] <apw> though it is not clear it couldn't try at least
[15:13] <wilhelm1> Is this expert villiage?
[15:14] <wilhelm1> What do you want a stool sample?
[15:14] <wilhelm1> Why does it take so long to respond.
[15:14] <wilhelm1> As if typing in a little password makes an identity.
[15:15] <wilhelm1> Hey
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:15] <wilhelm1> ping
[15:16] <wilhelm1> What the fuck are these 80,000 users
[15:16] <wilhelm1> They just sit and idle.
[15:17] <wilhelm1> Have to call and talk to a cockaroach to get any interaction?
[15:17] <cking> wilhelm1, stop spamming this channel with insane nonsense, are you on medication?
[18:10] <sconklin> it looks like someone got a lot closer to the ns cleanup bug: https://bugzilla.kernel.org/show_bug.cgi?id=65191#c13
[18:10] <ubot5> bugzilla.kernel.org bug 65191 in Netfilter/Iptables "BUG in nf_nat_cleanup_conntrack" [Normal,New]
[18:11] <sconklin> stgraber: hallyn: ^^
[18:24] <stgraber> sconklin: oh nice, yeah, that sure sounds like what we've been suspecting was happening (and what my test cases have been trying to stress test, albeit unsuccesfuly)
[18:25] <hallyn> stgraber: that's the one that's been crashing your builders?
[18:26] <stgraber> hallyn: no, that's the one arges and I have been trying to reproduce during the sprint, kernel panic when destroying a netns.
[18:26] <hallyn> ah
[18:26] <stgraber> I only ever had that one happen on my laptop and only 2-3 times so far (annoyingly)...
[18:31] <arges> stgraber: yea, sconklin sent this thread : https://github.com/dotcloud/docker/issues/2960 the last comment seems interesting