[00:16] DalekSec, will have a look [00:16] apw: Great, thanks! === shuduo-afk is now known as shuduo [10:58] interesting stuff, cgroup namespaces. [11:04] no you don't want to use all that complex stuff, you'll break it [11:05] * xnox giggles [11:20] do we have regression tests for it? [15:43] jsalisbury: aroudn yet? [15:45] cking, yes, it's called systemd in a docker image in lxd container. [15:45] =) [15:46] why doesn't that surprise me === Elimin8r is now known as Elimin8er [15:51] lamont, yes [15:53] lamont, about to update the bug [15:54] cool. did I maybe convince you to do the for loop? [15:54] lamont, only two kernels left to test in the bisect, then on more after that with a revert of the actual commit. I'll post then next two to try shortly [16:01] jsalisbury: cool. my hope was to be done destroying my work setup in minimum time [16:01] because it's getting old [16:01] lamont, yeah, bisecting is a pain [16:03] tbf, it would suck far less if it wasn't my primary worksurface [16:51] apw: hey, I pinged you about the backport of amdgpu from 4.5, and you recommended that I file a bug report and link the commits to it; I have one more question: would I have to rename that as amdgpu_bpo, or could I simply leave it as it is? [16:53] tseliot, how utterly vile is the delta, if its likely to make maintenance huge its better if its separate [16:55] apw: it's about 230 commits. I'm at 136 and I haven't had to fix up commits (other than whitespace issues) so far [16:56] apw: I want to make it clear that, if anything fails, I can maintain that code [16:57] * apw dries [16:57] dies [16:57] well i guess its really bjf's call, as he has to work with it [16:57] * tseliot prepares a nice coffin [16:58] the added benefit would be no fglrx ;) [16:59] as in it would no longer be required, or no longer work :) [17:01] the former, and purged too [17:01] tseliot, which series is this for? Xenial? [17:01] bjf: yep [17:02] tseliot, i'll feel better when you are at commit 230 and still feel everything is fine [17:03] bjf: so will I ;) [17:04] tseliot, i mostly trust your decision as it _will_ be you fixing any/all problems. but it feels late to be sucking in something this huge. [17:05] bjf: that is understandable but I didn't have the hardware to work on. I'll let you know how my work goes [17:05] tseliot, ack, thanks [17:06] also, I'm preparing i915_bpo for SKL/KBL/BXT.. [17:06] SKL again, as it's still not done, and shares audio bits with KBL [17:09] * apw gets his shit-list out and checks your name is on it [17:09] :D [17:09] and underlined and highlighted in luminious orange [17:10] tseliot, oh and you'll prolly have to file FFEs now as that is in the past [17:11] apw: it won't be a problem [17:11] depending if there is anything non-fixy [17:11] well, it's both things [17:28] bug #1545401 [17:28] bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,Confirmed] https://launchpad.net/bugs/1545401 [17:57] stgraber, seems adt testing is broken again: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1548440 [17:57] Launchpad bug 1548440 in lxc (Ubuntu) "lxc: adt testing failing with 4.4.0-7.22" [Undecided,New] [17:58] passed on all arches but amd64, lets just retry it [17:59] well, not seeing any retry link on proposed-migration, so guess it's not considered a migration blocker then [18:00] stgraber, not passing for me, on anything [18:00] http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html [18:00] stgraber, ^ [18:01] stgraber, britney is confused by kernels, because triggers for those _switch_ the installed kernel [18:01] stgraber, so it doesn't maintain history so there are never regressions there, i intuit them in the adt-matrix for the kernel from actual history [18:02] so looks like this may be some kind of apparmor bug preventing you from getting an IP somehow [18:02] jjohansen, ^ [18:02] we always love apparmor bugs [18:03] would be nice if we could get a dmesg dump after that particular failure [18:03] stgraber, presumably that only applies in lxc land, else we'd not be able to use the kernel for any testing at all [18:03] right [18:04] so that's the current xenial-proposed kernel then? [18:05] * stgraber uprades the big test VM [18:05] stgraber, yes [18:25] got a system running the proposed kernel now, creating a container to see what's going on [18:26] apw: ok, same behavior here, though I have an idea as to what's going on [18:26] hallyn: around? [18:26] apw: that kernel brings us cgns support correct? [18:27] stgraber: yeah [18:27] though you need the git head lxc [18:27] to get the moun tpermissions [18:27] hallyn: so we have adt regressions with the latest kernel and current lxc, would my assumption that lxcfs detects cgns and so doesn't mount /sys/fs/cgroup but old lxc blocks the cgroupfs mount be correct? [18:28] yup [18:28] if so, I'll just tag rc2 and upload that to the archive along with my packaging rework, that should fix adt [18:28] alright, let me re-test with current lxc upstream [18:28] yeah, the lxd nesting profile allows 'mount,' iirc, which hid that one from me [18:29] gah, ok, so we need both a new lxc and lxd then [18:30] ok, so lxd cherry-pick of your fix and new lxc rc, that should do the trick [18:30] apw: will have both uploaded within the hour [18:30] stgraber, sounds good thanks [18:30] stgraber: yup, unless there's another glitch hiding, but those were working for me over the weekend [18:34] lxd uploaded [18:34] going to grab some food and then get tagging for lxc rc2 [18:44] lxc uploaded [19:03] stgraber, ack thanks [19:12] Does the kernel team hire individuals that wish to get into kernel development without much (or any) kernel experience? [19:13] I've got professional experience in other development areas but always found kernel work interesting. [19:17] we have been known to, but it all depends on the roles that are open, not sure what all we have open right now [19:20] Thanks-- is the best way to find out to apply or is there someone I could talk to directly? [19:21] aiguu_, if you apply through the web site for a specific, open req. it gets the attention of the appropriate team [19:22] Thanks! [21:35] stgraber, hrrmm, seems the new one has a new problem: [21:35] raceback (most recent call last): [21:35] File "/tmp/tmp.rGuQP5EXYB", line 101, in [21:35] assert(container.init_pid > 1) [21:35] AssertionError [21:36] crap, lets see [21:37] hallyn: ^ [21:38] what's weird is that this passed jenkins somehow [21:39] ? [21:39] hallyn: rc2 is failing on all arches [21:40] I'm wondering if it's not my fault though, could be explained by apparmor not loading somehow [21:40] what exactly is failing. lxd autotest? booting at all? [21:40] hallyn: all the lxc-tests-* are pretty much (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxc/20160222_210046@/log.gz) [21:40] and that's on a non-cgns kernel [21:41] hm, so it can't be that lxc-container-default-cgns just isn't installed then [21:43] * hallyn tries adt locally on proposed [21:45] I'm setting it up here too, didn't re-install it after I did a clean install on this box [21:47] PASS: lxc-tests: /usr/bin/lxc-test-apparmor [21:47] it's a start [21:50] but im'hanging there [22:00] manjo, did you get to test the initramfs-tools in -proposed ? [22:01] got interupted a bit, back to looking at the adt failure now [22:02] adt running, maybe I'll get lucky and get the same failure, if not, we'll just blame the DC and hit retry until it passes [22:02] apw, will do it in the next 1/2 hr [22:02] but most of those tests are offline so I'm unsure how that would be [22:02] stgraber, we've failed the same way on 3 arches, so i am suspicious [22:03] yeah, me too, but I'm surprised that hallyn didn't manage to reproduce it [22:04] no i think i was hanging differently [22:04] (maybe my network hiccoughed at the wrong time) [22:04] what would make the most sense is that I screwed up something with my packaging rework and the apparmor profile doesn't get loaded, I think that would explain all the failures [22:05] ah ffs, adt is blowing up on me again, I thought pitti said he'd fixed that [22:05] stgraber, he fixes that about once a week, its a fragile beastie [22:05] adt-run [17:04:45]: testing package lxc version 2.0.0~rc2-0ubuntu1 [22:05] adt-run [17:04:45]: build not needed [22:05] tar: Unexpected EOF in archive [22:05] tar: Unexpected EOF in archive [22:05] tar: Error is not recoverable: exiting now [22:05] qemu-system-x86_64: terminating on signal 15 from pid 12772 [22:06] corrupt tarball ? [22:06] supposedly it's a very rare error, yet I've got it on all my machines even after re-installing both of them with new disks and switching from trusty to xenial :) [22:07] heh [22:08] re-trying, if that doesn't work, I'll just start a trusty VM manually, turn proposed on in there and install lxc manually [22:08] trusty? [22:08] s/trusty/xenial/ [22:08] sorry [22:08] been debugging another issue that's trusty :) [22:09] just checking [22:09] gah and yeah, just got the exact same issue again... [22:10] taking over the canonical-lxd VM again, that's up to date xenial, will save me some setup time. I'm wiping lxc and lxd from it, rebooting and do a clean lxc install, lets see what happens [22:15] yeah, clearly an apparmor profile... [22:16] lxc-start 20160222205626.155 ERROR lxc_apparmor - lsm/apparmor.c:apparmor_process_label_set:234 - No such file or directory - failed to change apparmor profile to lxc-container-default [22:16] ok, so that's my fault for sure, now to figure out how I caused this mess [22:25] found something wrong in the packaging, fixed it and doing a test build now to see if the maintainer scripts make more sense then [22:25] though since I can't actually reproduce the adt failure, I'm not 100% sure it'll do the trick [22:33] stgraber, that is annoying isn't it [22:33] yeah [22:33] anyway, sbuild is happy and generated maintscripts look more correct than they did before [22:34] lets hope that was it, uploading [22:47] stgraber, thanks [23:06] ok so fwiw i expect unprivileged containers in xenial to be temporarily broken. there's a bad interaction between sforshee's patchset and cgns. i'm going to test a fix, but it'll take some time to buld [23:13] hallyn, cna i build you a kernel or something ? [23:14] hallyn, as i was about to upload, and i suspect i want that kernel in there [23:17] apw: i'm trying http://paste.ubuntu.com/15175046/ [23:18] not sure it's right, but it seems more right than not doing it [23:18] apw: i'm about to head out for a bit, if you're going to push that somewhere i'll wait forthat, else i'll leave a build going here [23:20] apw since my server tends to crap out when i build a kernel, i'm happy to wait for you :) [23:21] eh, i'll leave it building - /me out to get a coffee, bbl [23:29] hallyn, i'll let you know whn its built [23:35] apw, is the initramfs in your ppa / [23:35] ? [23:36] apw, or is it in proposed ? [23:41] manjo, in proposed [23:42] yes I see it in proposed .. just installed it [23:53] hallyn, http://people.canonical.com/~apw/master-next-xenial/ [23:53] hallyn, let me know how it fairs [23:56] ports is so slow