| 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:56 |
| 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:57 |
| psivaa | henrix: ack, so i'll keep watching the tracking bug :). thanks | 09:58 |
| henrix | psivaa: yeah, it will be updated soon, once brad uploads the fixed kernel ;) | 09:59 |
| psivaa | henrix: ack | 09:59 |
| infinity | The fixed kernel is uploaded. | 10:06 |
| infinity | psivaa: Do you need them in the archive to re-run your tests, or can you cherry-pick from the PPA? | 10:07 |
| psivaa | infinity: our automated tests pick the kernel from -proposed. cherry picking will be really time consuming | 10:13 |
| infinity | psivaa: Kay, I can copy it over right now for you to play with. | 10:14 |
| psivaa | infinity: ack, thanks | 10:14 |
| 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:16 |
| infinity | henrix: bjf declined putting my patch in the current T kernel, we'll get it in next week's. | 10:17 |
| 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:18 |
| psivaa | infinity: ack, thx | 10:23 |
| infinity | psivaa: Both should hit the archive over the next 30-60m. | 10:23 |
| psivaa | infinity: great. thx. i'll run them in 90m | 10:24 |
| 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:25 |
| 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:26 |
| psivaa | infinity: ack | 10:29 |
| bjf | infinity, it's got to get to ktml first :-) | 12:53 |
| infinity | bjf: Bah, no other packages require patches on bugs to go through extra hoops. :P | 12:55 |
| bjf | infinity, we set the standard others try to follow | 13:14 |
| 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] | 13:39 |
| apw | jodh, i don't think i knew about that ... hmmm | 14:24 |
| 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:25 |
| jodh | apw: I'm happy to raise an MP to take out that filter from the ubuntu patch? | 14:26 |
| 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:29 |
| apw | though it is not clear it couldn't try at least | 14:30 |
| wilhelm1 | Is this expert villiage? | 15:13 |
| 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:14 |
| 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:15 |
| wilhelm1 | What the fuck are these 80,000 users | 15:16 |
| wilhelm1 | They just sit and idle. | 15:16 |
| 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? | 15:17 |
| 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:10 |
| sconklin | stgraber: hallyn: ^^ | 18:11 |
| 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:24 |
| hallyn | stgraber: that's the one that's been crashing your builders? | 18:25 |
| 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:26 |
| arges | stgraber: yea, sconklin sent this thread : https://github.com/dotcloud/docker/issues/2960 the last comment seems interesting | 18:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!