[16:22] <jmux> Hi. I'm triaging bug https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1643843
[16:22] <ubot5`> Ubuntu bug 1643843 in xorg (Ubuntu) "Distorted colours after suspend / resume cycle" [Undecided,New]
[16:23] <jmux> My current conclusion is: linux-image-4.2.7-040207-generic broken, linux-image-4.1.35-040135-generic ok
[16:24] <jmux> Is there any other way then starting bisection now (something like LibreOffice bibisect repository?)
[17:01] <jmux> So I'm trying to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel for bibisect, but it seems most checkout don't  have a debian.master directory. Any idea?
[17:34] <henrix> stgraber: hi, i'm seeing adt tests failing on xenial.  would you have a minute to have a look, please?
[17:35] <henrix> stgraber: (lxd failures with the xenial kernel in -propose, to be more precise)
[17:36] <stgraber> henrix: got a URL for me?
[17:37] <henrix> stgraber: sure: http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html
[17:37] <henrix> stgraber: or directly to the logs: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20161122_165140_fb379@/log.gz
[17:38] <henrix> stgraber: it's failing on amd64, i386 and ppc64el
[17:39] <stgraber> henrix: ah yeah, LXD 2.0.5 with 4.8 kernel won't work because the kernel adds extra security checks to mntns mount injection
[17:39] <henrix> stgraber: 4.8?  it should be a xenial kernel, 4.4... /me goes look closer
[17:40] <stgraber> henrix: LXD 2.0.6 which we'll release tomorrow will contain the fix for this (added code to attach to the userns to avoid that particular security check)
[17:40] <stgraber> henrix: either it's 4.8 or you backported the crazy extra security checks to 4.4 :)
[17:42] <henrix> stgraber: ok, so i'm clueless about what's happening.  this is supposed to be testing 4.4.0-49.70.  anyway, thanks for looking.  i'll try to figure out what's going on there, looks like a misconfigured test...
[17:42] <stgraber> henrix: yeah, looks like it's 4.4, which means you cherry-picked a commit which breaks attach to mntns unless you also join the userns
[17:43] <stgraber> henrix: do you have a link to the git tree you've used for that kernel? I should be able to find the kernel commit that causes that issue
[17:43] <stgraber> anyway, as I said, we have a workaround for that change in LXD but it won't be in xenial-updates for another couple of weeks (we tag tomorrow + upload, then 1 week SRU cycle)
[17:44] <henrix> stgraber: the tree is in git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial master-next branch
[17:47] <stgraber> henrix: ac7f3f73cb393f79f94e4ce8eb6c6cd96864dd28 and ca52383ad6a6a4221395727f81e1b561fef02ae9
[17:47] <henrix> stgraber: maybe this one...? https://paste.ubuntu.com/23517963/
[17:47] <henrix> looking
[17:47] <henrix> ugh
[17:47] <henrix> sforshee: ^
[17:47] <stgraber> those basically return EOVERFLOW to LXD when we attempt to create paths leading to our mount target
[17:48] <stgraber> the fixes aren't wrong per say, but they do break existing userspace :)
[17:49] <henrix> stgraber: yeah, i see.  i guess we'll need to revert those for now then
[17:49] <henrix> stgraber: again, thanks a lot for your help!
[17:49] <stgraber> https://github.com/lxc/lxd/commit/6ff0b5f3b73e0431785e2da1cf0913d6e3e5fd8d
[17:50] <stgraber> that's the LXD fix to work with that kernel change. You'll probably be fine including those two changes in your kernel in another SRU cycle or two, by that point we'll have the new LXD in xenial-updates
[17:50] <stgraber> good to see that autopkgtest found an actual regression for once :)
[17:50] <henrix> heh :-)
[17:51] <henrix> stgraber: yeah, we'll revisit these patches once we have userspace sorted out
[19:19] <pfsmorigo> infinity, hi, does ubuntu uses syslinux for something on ppc64el?