[08:19] <genkgo> jsalisbury: by any chance had a crashing centos 7? or is still up and running? :)
[09:49] <caribou> xnox: apw: not sure what you're talking about
[09:50] <apw> caribou, i was saying the same, that i have no idea what anyone is talking about here :)
[09:50] <caribou> apw: maybe xnox was talking about the linux-crashdump meta-package; dunno
[09:51] <apw> maybe, didn't we fix that already ?
[09:51] <apw> at least if he means s390x ?
[10:02] <caribou> apw: yes, but after the freeze so it is queued
[10:02] <apw> caribou, ahh ok, then its in hand and will be in the upload tommorrow i assume
[12:24] <tseliot> apw: hey, I'm a little confused, as I can't find any of the drm drivers in the initramfs of my kernel on trusty. Any ideas? (I did lsinitramfs /boot/initrd.img-3.13.0-77-generic | grep drm)
[12:30] <jsalisbury> genkgo, The CentOS VM hasn't crashed yet.  I'm going to let it run for just a few more hours.  MS recommended different versions of LIS, so my next steps are to try those different versions and also compare the 3.10 bits to newer kernels that hit the bug.
[12:31] <genkgo> jsalisbury: alright, wonderful, at least it is good to know that the centos machine probably does not have the bug, so we have a starting point
[12:32] <jsalisbury> genkgo, indeed.  I've always been able to reproduce the bug within 9 hours and I'm now at about 15 hours
[12:33] <caribou> smb: anything special to do to get 3270 access from Ubuntu ? I'm trying with x3270 but the telnet connection doesn't establish
[12:33] <smb> caribou, not really
[12:34] <apw> tseliot, we don't normally put them in the initrd unless you need splash before root
[12:34] <apw> which you only need to encrypted root
[12:35] <apw> we only wait for the root device to appear then mount it and pivot before splashing
[13:16] <apw> tjaalton, that i915_bpo failure ... did you notice it is return an error code of 0, which would imply no error
[13:19] <apw> tjaalton, also as this is a load time failure, this should occur before you even know this is a skl or whatever, so how it can fail on one and not the other is beyond me
[13:19] <apw> tjaalton, well unless your /boot/vmlinux is somehow out of sync with your kernel modules
[14:04] <fg__> cking: I'm out for today, but I did some quick tests and bug 1560869 does not trigger here anymore with a manually built 0.6.5.6 (based on debian/jessie/0.6.5.2-2 and vanilla upstream). Will test xenial packages as soon as they are available.
[14:05] <cking> fg__, that's good to hear, the 0.6.5.6 passed all my regression tests overnight so we're happy with it so far
[14:58] <cmagina> what is the best way to propose a clean cherry-pick from upstream to xenial?
[15:20] <apw> cmagina, cherry-pick it to the tip of the tree you intend it to be applied and then format-patch it out and mail it in
[15:20] <apw> make sure you -sx when you cherry-pick it
[15:20] <apw> cmagina, though we'd prefer a bug to explain why at this stag
[15:20] <apw> e
[15:24] <cmagina> apw: fair enough, thanks, will do
[15:25] <apw> cmagina, by that i mean a bug files _as_well_ as sending it in and referecned in the patch
[15:25] <apw> see the buglink: s in the tree
[15:25] <cmagina> yup, i understand
[15:26] <apw> (i was being my usual british unclear self)
[15:27] <cmagina> :)
[16:52] <xnox> caribou, apw - yes linux-crashdump meta-package. i assume you have it all in hand, i'm just replying to my old pings =)
[16:56] <apw> xnox, yes, its sitting on the tip of -meta for -16
[16:59] <apw> rtg, make sure you update meta for that ...
[17:05] <xnox> .... after beta-2 please, i don't want to test a respin =/
[17:27] <apw> rtg, yeah i mean its in the core repo, so you should have it in for next time, for the -16
[19:07] <tjaalton> apw: yeah the kbl install could be just messed up somehow, will check when i get back home (sunday)
[19:15] <rtg> apw, ack