[00:10] <wxl> cyphermox: good to hear from you. there were some interesting tracebacks as recent comments on the bug report.
[00:52] <slangasek> tsimonq2: so how and why is bug #1647031 affecting you, given that libnss-resolve is in ubuntu-standard and masks the issue?
[00:52] <ubot5`> bug 1647031 in systemd (Ubuntu) "systemd-resolved’s 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
[00:57] <tsimonq2> slangasek: I still get the issue when that is installed afair
[00:57] <slangasek> tsimonq2: "AFAIR"> would be good to have confirmation, since that conflicts the information on the bug
[00:58] <tsimonq2> slangasek: OK, I'll let you know on Thursday when I have access to that install again
[00:58] <slangasek> ok
[08:00] <Mirv> please remove these (unbuildable, related to the upstart removals) s390x binaries from zesty: libqt5purchasing5 qml-module-qtpurchasing qtpurchasing5-dbg qtpurchasing5-dev-dbgsym libqt5purchasing5-dbgsym qml-module-qtpurchasing-dbgsym qtpurchasing5-dev
[08:17] <Mirv> filed bug #1653906 about it
[08:17] <ubot5`> bug 1653906 in qtpurchasing-opensource-src (Ubuntu) "RM: s390x binaries of qtpurchasing-opensource-src" [Undecided,New] https://launchpad.net/bugs/1653906
[09:06] <ginggs> morning! would someone please 'force-badtest ocrmypdf/4.2.5-1/s390x' ?  debian bug #849094
[09:06] <ubot5`> Debian bug 849094 in liblept5 "liblept5: Broken on s390x (+ other big endian archs)" [Normal,Open] http://bugs.debian.org/849094
[11:11] <ginggs> tumbleweed, if you're in a compatible timezone ^
[11:14] <apw> ginggs, why would we want to break that on s390x by letting it migrate?  it worked before
[11:15] <ginggs> apw, my understanding is it was always broken on big-endian, the new tests are exposing the problem
[11:16] <apw> ahh ok
[11:34] <apw> ginggs, and done
[11:35] <ginggs> apw: thanks!
[12:17] <cjwatson> Can somebody remove the force-badtest openssh from the britney hints branch?  It passes everywhere now.
[12:17] <cjwatson> (It's in pitti's hints file, but I don't think he has commit access any more?)
[12:17]  * apw has a look
[12:19] <apw> cjwatson, and done
[12:19] <cjwatson> Cheers
[12:19] <cjwatson> Took about a week of on and off arm's-length debugging ...
[12:20] <apw> that sounds like a lot of a nightmare
[12:20] <cjwatson> A bit.  Should be suitably nailed to the wall now anyway :)
[12:33] -queuebot:#ubuntu-release- Unapproved: libica (yakkety-proposed/universe) [2.6.1-3 => 2.6.1-3ubuntu0.1] (no packageset)
[12:37] -queuebot:#ubuntu-release- Unapproved: libica (xenial-proposed/universe) [2.6.1-1ubuntu2 => 2.6.1-1ubuntu2.1] (no packageset)
[12:44] <flocculant> release team peoples - are you aware the daily boots direct to the desktop? bug 1651716
[12:44] <ubot5`> bug 1651716 in ubiquity (Ubuntu) "17.04 boots direct to live desktop, no option to Try or Install" [Undecided,Confirmed] https://launchpad.net/bugs/1651716
[12:56] <mdeslaur> could someone please remove bubblewrap from the yakkety upload queue, I need to rebuild it in the security pocket instead
[12:57] <apw> mdeslaur, bubblewrap (source)
[12:57] <apw> 0.1.5-1~ubuntu16.10.0
[12:57] <apw> that one ?
[12:57] <mdeslaur> apw: yep
[12:57] <apw> mdeslaur, and gone
[12:57] <mdeslaur> thanks apw
[12:58] -queuebot:#ubuntu-release- Unapproved: rejected bubblewrap [source] (yakkety-proposed) [0.1.5-1~ubuntu16.10.0]
[13:41] <ginggs> apw: do we need 'force-badtest ocrmypdf/4.3.4-2/s390x' as well for the new version?
[13:44] <apw> ginggs, looks to be ignored for example for leptonlib, what are you waiting on
[13:44] <apw> ginggs, oh ocrmypdf is actually waiting to migrate, derp
[13:53] <ginggs> apw: sorry i didn't realize you needed to do that per version, i thought it was worked like >= 4.2.5-1
[13:56] <apw> ginggs, some of them do, some not.
[15:34] <tumbleweed> ginggs: you can do all versions, but then it's easily forgotten
[16:20] <Mirv> could an archive admin bug handle bug #1653906 so that my ticket rebuild qtpurchasing (https://bileto.ubuntu.com/#/ticket/1985) wouldn't show a missing build? (since it's not really missing, as the s390x binaries could not be built in zesty if a rebuild was done anymore, regardless of the landing)
[16:20] <ubot5`> bug 1653906 in qtpurchasing-opensource-src (Ubuntu) "RM: s390x binaries of qtpurchasing-opensource-src" [Undecided,New] https://launchpad.net/bugs/1653906
[16:55] <infinity> Mirv: Err, why are we still doing upstart-related removals?  Didn't xnox put in a bunch of work to make things stop depending on upstart?
[16:57] <Mirv> infinity: probably because the upstart problems need to be fixed all at once. right now libpay2 is unavailable on s390x due to manual stop gap dependency in it, so qtpurchasing can't rebuild on s390x. I think xnox will eventually need to have a single huge silo that removes all upstart dependencies, both actual and the made up ones that were inserted in various points to keep touch stack landable for
[16:57] <Mirv> the last four months.
[16:58] <Mirv> since doing it partially probably would introduce a chain reaction
[16:58] <infinity> *sigh*
[16:58] <infinity> And this removal here was probably one that was missed when people did this crap in yakkety.
[16:59] <infinity> (And yes, "crap" sums up how I feel about the upstart/s390x "solution")
[16:59] <infinity> Alright, I'll poke at this bug.
[16:59] <Mirv> yes, it's pretty crap crap
[17:03] <infinity> Mirv: Done.
[17:09] <Mirv> thank you
[17:21] <tsimonq2> bubblewrap, heh
[17:26] <tsimonq2> Are there docs somewhere showing what exactly is done when a new development release is being formulated? On the release schedule it says "Toolchain Uploaded" and the appropriate wiki page just talks about the various parts of the toolchain, but not actually what it means to have "Toolchain Uploaded"
[17:26] <tsimonq2> I'm just curious, as I'm not finding it documented anywhere.
[17:27] <tsimonq2> Like, inspecting zesty-changes shows some things like setting Zesty as the release etc. but not actually what happens when new releases are a thing.
[17:31] <cjwatson> tsimonq2: https://wiki.ubuntu.com/NewReleaseCycleProcess
[17:35] <tsimonq2> cjwatson: Ooh, fancy, thanks.
[17:36] <tsimonq2> One other thing, why does Lintian *still* not recognize zesty as a release? Should I file a bug, or is that something someone forgot about that I can just submit a debdiff for?
[17:40] -queuebot:#ubuntu-release- Unapproved: lxc (trusty-proposed/main) [2.0.6-0ubuntu1~ubuntu14.04.1 => 1.0.9-0ubuntu2] (ubuntu-server)
[17:40] <cjwatson> how about I just use my upstream commit bit to fix that in Debian
[17:42] <tsimonq2> cjwatson: Yes please. :)
[17:45] <cjwatson> https://anonscm.debian.org/cgit/lintian/lintian.git/commit/?id=0170df01277e46b618c269de0a0622389c573a39 - it's probably OK to just let that be synced later, but feel free to cherry-pick if you're in a rush
[17:47] <tsimonq2> ...maybe if I had upload access I would have that option :P
[17:48] <tsimonq2> cjwatson: But thanks :)
[17:50] <tsimonq2> !info lintian zesty
[17:50] <ubot5`> lintian (source: lintian): Debian package checker. In component main, is optional. Version 2.5.50 (zesty), package size 792 kB, installed size 3831 kB
[17:50] <tsimonq2> !info lintian unstable
[17:50] <ubot5`> lintian (source: lintian): Debian package checker. In component main, is optional. Version 2.5.50 (unstable), package size 1019 kB, installed size 3831 kB
[17:50] <tsimonq2> Ah ok.
[17:50] <tsimonq2> ...why would the package size in unstable be larger than in Ubuntu?
[17:51] <stgraber> infinity: can you let that lxc upload into trusty-proposed pretty please? that should fix the autopkgtest failure we've had so far by having our test detect busted kernels properly
[17:51] <tsimonq2> s/Ubuntu/zesty/
[17:56] <cjwatson> tsimonq2: stripped upstream changelog
[17:56] <cjwatson> $ diff -u <(zcat unstable/usr/share/doc/lintian/changelog.gz) <(zcat zesty/usr/share/doc/lintian/changelog.gz) | diffstat
[17:56] <infinity> stgraber: Hahaha.  I was just looking at that.
[17:56] <cjwatson>  62 |17741 ---------------------------------------------------------------------
[17:57] <cjwatson>  1 file changed, 1 insertion(+), 17740 deletions(-)
[17:57] <infinity> stgraber: (The failure, not your upload)
[17:58] <infinity> stgraber: Oh.  Different (maybe?) failure.
[17:58] <infinity> stgraber: Care to have a glance at https://bugs.launchpad.net/auto-package-testing/+bug/1654025 and see if you can make sense of it?
[17:58] <ubot5`> Ubuntu bug 1654025 in Auto Package Testing "trusty/armhf dkms tests are killing workers" [Undecided,New]
[18:00] <infinity> stgraber: As for this lxc upload... Skipping a test doesn't seem to resolve the bug?
[18:01] <infinity> stgraber: Unless the feature being tested also will refuse to be used on old kernels.
[18:01] <stgraber> infinity: LXC does fail when it runs into that particular kernel issue, it's said LXC failure which was then causing autopkgtest to fail. So we now detect it ahead of time and skip the test rather than failing when we get the error.
[18:02] <stgraber> infinity: it's not ideal in that there's still a kernel bug, but it's limited to the 3.13 kernel and hasn't seen much traction in getting fixed
[18:02] <infinity> stgraber: And this bug/interaction has always existed in trusty lxc-versus-3.13?
[18:02] <infinity> stgraber: As in, no new regression here, just a test that exposed it?
[18:03] <stgraber> infinity: LXC used to go ahead with the busted-ness which was enough to make the test happy and then break people randomly. LXC 1.0.9 detects the kernel being busted and refuses to have anything to do with it.
[18:03] <infinity> stgraber: Okay, that sounds like progress, even.  (not ideal progress, but progress nonetheless)
[18:04] <infinity> stgraber: So, accepting that.
[18:04] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1507463 is the underlying issue I believe
[18:04] <ubot5`> Ubuntu bug 1507463 in linux (Ubuntu) "OverlayFS: Wrong mnt_id and path reported in /proc in linux-3.13" [Medium,Confirmed]
[18:04] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (trusty-proposed) [1.0.9-0ubuntu2]
[18:04] <infinity> stgraber: Can you look at the bug above (specifically, Laney's strace vomit) and tell me if that rings any bells?
[18:04] <infinity> stgraber: It looks suspiciously container/namespace related, and I can't reproduce in a plain old chroot.
[18:06] <stgraber> infinity: so it's apt-get source dkms on trusty blowing up somehow?
[18:07] <infinity> "apt-get source -q --only-source nvidia-graphics-drivers-340=340.98-0ubuntu0.14.04.1" is the call, and yeah, in a chroot, it just does a thing, downloads some source, prints to stdout, life is good.
[18:07] <infinity> stgraber: In a container, it appears to not do a useful thing. :P
[18:08] <infinity> (Though still exits 0, thanks apt)
[18:08] <Laney> Bit weirder
[18:08] <Laney> It exits 0 but the rest of the script doesn't run
[18:08] <infinity> Laney: That's the script's fault, surely.
[18:08] <infinity> Laney: But the apt failure it the curious bit right now.
[18:09] <Laney> I think the whole script is being killed
[18:09] <Laney> But yeah, surely fixing that will fix whatever it is
[18:09] <infinity> Laney: The script being "killed" is by design, surely.
[18:10] <infinity> Laney: It's logging an error, and even gives us the error.
[18:10] <infinity> (The error being that apt exited without printing anything to stdout, and we're pretty uncool with that)
[18:10] <Laney> No
[18:10] <Laney> The script is meant to catch the bad exit code, look at the output and then exit with it
[18:10] <Laney> We should see that happening, given set -x
[18:11] <stgraber> Laney: any chance you can get a dmesg output post failure?
[18:11] <Laney> Hmm
[18:11] <stgraber> the first thing that comes to mind with such behavior (command just stopping halfway through whatever it's doing) would be the kernel oom killer
[18:12] <stgraber> though that usually causes a non-zero exit :)
[18:12] <infinity> OOM kills return a 9, not 0.
[18:12] <Laney> 'fraid I've got to get out of here for a bit
[18:14] <stgraber> I'll try to reproduce this on my m400 (xenial arm64 host), should be as close as I can get
[18:15] <Laney> I'm just running it on my desktop (zesty, amd64)
[18:15] <stgraber> infinity: we've seen the kernel do weird shit when the oom is cgroup triggered :)
[18:15] <Laney> We just get it on armhf for autopkgtest because that's the only place we use lxd
[18:15] <stgraber> Laney: oh, fun
[18:15] <infinity> We use it on s390x too.
[18:15] <infinity> But it might not be triggering the same tests.
[18:16] <stgraber> not on trusty though
[18:16] <infinity> Oh, and trusty.  Yeah.
[18:16] <stgraber> running "apt-get source --only-source nvidia-graphics-drivers-340" in a trusty container here doesn't reproduce the issue though
[18:16] <stgraber> Laney: do you have a reproducer that doesn't involve running all of autopkgtest with the lxd backend?
[18:17] <Laney> Nope, sorry
[18:17] <infinity> Odds are it's just that one command.
[18:17] <infinity> But I don't lxd well enough to tell you that. :P
[18:18] <Laney> I think I tried earlier in a normally started container (but still an autopkgtest one) and it worked
[18:18] <Laney> The desktop is off now because of the aforementioned leaving
[18:18] <Laney> ttyl
[18:22] <stgraber> Laney: does autopkgtest with the lxd backend exec stuff through "lxc exec" or through ssh?
[18:23] <stgraber> I just tried a simple shell script which runs the apt-get source command and then prints something in both of "lxc exec"'s modes and both worked fine
[18:24] <infinity> Define working fine.  Does it download the source?
[18:26] <stgraber> yup
[18:26] <stgraber> downloads and unpacks
[18:28] <infinity> Well, that's irksome.
[18:29] <infinity> ssh certainly could be involved, if it's mimicking the xen and kvm workflows.
[18:35] <tsimonq2> cjwatson: Hmmmm ok thanks
[19:22] -queuebot:#ubuntu-release- New binary: gyoto [s390x] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:24] -queuebot:#ubuntu-release- New binary: gyoto [ppc64el] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:29] -queuebot:#ubuntu-release- New binary: gyoto [amd64] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:32] -queuebot:#ubuntu-release- New binary: gyoto [powerpc] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:34] -queuebot:#ubuntu-release- New binary: gyoto [i386] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:51] -queuebot:#ubuntu-release- New binary: gyoto [arm64] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[19:57] -queuebot:#ubuntu-release- New binary: gyoto [armhf] (zesty-proposed/universe) [1.2.0-2ubuntu1] (no packageset)
[20:37]  * tsimonq2 throws bug 1647031 at barry 
[20:37] <ubot5`> bug 1647031 in systemd (Ubuntu) "systemd-resolved’s 127.0.0.53 server does not follow CNAME records" [Low,Triaged] https://launchpad.net/bugs/1647031
[20:37] <tsimonq2> May be relevant... :)
[20:37] <tsimonq2> (can't respond to the email atm)
[20:48] -queuebot:#ubuntu-release- Unapproved: rejected owncloud-client [source] (yakkety-proposed) [2.2.2+dfsg-1ubuntu0.2]
[20:50] <Laney> stgraber: I think https://git.launchpad.net/~ubuntu-release/autopkgtest/+git/autopkgtest/tree/virt/autopkgtest-virt-lxd#n149 that beauty is prefixed to commands to run
[20:54] -queuebot:#ubuntu-release- Unapproved: owncloud-client (yakkety-proposed/universe) [2.2.2+dfsg-1ubuntu0.1 => 2.2.2+dfsg-1ubuntu0.2] (no packageset)
[20:59] -queuebot:#ubuntu-release- Unapproved: accepted owncloud-client [source] (yakkety-proposed) [2.2.2+dfsg-1ubuntu0.2]
[20:59] <stgraber> Laney: running with that command still works fine here
[21:01] <stgraber> Laney: http://paste.ubuntu.com/23741392/
[21:04] <Laney> Something somewhere is making it break in this specific way :P
[21:04] <Laney> I'll have to look more tomorrow unless one of you gets to it tonight
[21:04] <Laney> Food now
[21:04] <stgraber> Laney: what version of LXD are you using on your machine?
[21:05] <stgraber> we did some tweak to exec handling in recent versions (2.6/2.7), wondering if maybe I can't reproduce it because my version isn't affected somehow
[21:12] <barry> tsimonq2: ha, yes probably related :)  thanks
[21:17] <Laney> stgraber: Right this second I'm on yakkety - seems to be 2.4.1
[21:17] <Laney> can't remember offhand what the autopkgtest infrastructure is on, probably x
[21:17] <Laney> bet it's something in trusty
[21:17] <stgraber> yeah, I'd expect autopkgtest to be on xenial so 2.0.x
[21:18] <stgraber> the exec fixes were in LXD 2.6 or 2.7 so only in zesty so far
[21:18] <stgraber> let me try that against a xenial host
[21:18] <Laney> this means I've seen the same on x, y and z
[21:19] <Laney> does the spew in the strace log tell you anything?
[21:21] <Laney> probably should have compressed that
[21:21] <stgraber> not really, sure looks like it's in a loop but there's no sign of it ever getting out of it
[21:22] <stgraber> which is odd as you should at least see strace exit at some point
[21:27]  * Laney shrugs
[21:28] <Laney> I guess tomorrow, if nobody beats me to it, I'll have to step through everything autopkgtest is doing until it breaks
[21:42] <stgraber> no luck with my minimal reproducer on yakkety
[21:54] <barry> Laney, stgraber what's going on with autopkgtest?  i don't have any relevant scrollback
[22:01] <infinity> barry: https://bugs.launchpad.net/auto-package-testing/+bug/1654025
[22:01] <ubot5`> Ubuntu bug 1654025 in Auto Package Testing "trusty/armhf dkms tests are killing workers" [Undecided,New]
[22:01] <infinity> barry: Insights welcome.
[22:06] <barry> infinity: looking
[22:39] <tsimonq2> barry: np, it's Really Really Annoying so Please Try And Get It Fixed Pretty Please ;)
[22:40] <barry> tsimonq2: oh trust me, i'm hitting it all the time ;)
[22:41] <tsimonq2> barry: Relevant systemd bug: https://github.com/systemd/systemd/issues/3826
[22:41] <tsimonq2> :)
[22:43] <barry> tsimonq2: thanks.  i guess i'll subscribe to that ;)
[22:44] <infinity> Looks like another case of "systemd thought they knew better", given the implementation is intentionally doing the filtering.
[22:44] <barry> please please please give me systemd-emacs
[22:45] <tsimonq2> systemd-editord?
[22:45] <tsimonq2> OH I KNOW! systemd-snapd :P
[22:45]  * tsimonq2 runs
[22:47] <tsimonq2> barry: Thanks, slangasek didn't bite when I linked him yesterday, really glad I'm not the only one being tormented ;)
[22:48] <barry> tsimonq2: yet another fallout of the pitti defection.  we each inherited 1/10th of a pitti, kind of like a horcrux or something
[22:50] <tsimonq2> barry: :P I wish I had the time and expertise to help...
[22:52] <tsimonq2> barry: OOH! https://lists.ubuntu.com/archives/ubuntu-devel/2016-December/039564.html
[22:52] <barry> tsimonq2: i'm not sure i have either either but i've gotten pretty good at annoyance transfer
[22:53] <barry> tsimonq2: yep.  slangasek did suggestion elsewhere a possible revert option until this is fixed
[22:53] <tsimonq2> In the worst case, these are the two commits to revert to undo this: https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/commit/?id=98974a88 https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/commit/?id=47c16e59
[22:55] <tsimonq2> barry: imho that would be good, even though my vote probably doesn't count, +3 :P
[22:55] <barry> tsimonq2: i think i'll at least test that revert tomorrow
[22:56] <barry> then we can decide after some additional data
[22:57] <tsimonq2> barry: And I'd also like to point out that Lubuntu has a bug where ubuntu-standard and ubuntu-minimal (tasks) aren't installed by default, and I Absolutely Hate GUI networking solutions, so there's that...
[22:58] <tsimonq2> barry: Heck, I can package the revert now in a PPA of mine and test it quick here :)
[22:59] <tsimonq2> As I face it on Real Hardware...
[23:02] <barry> tsimonq2: that would be very helpful.  if you do gather useful information, can you please update the LP bug?  i'm very nearly eod and can't run too late tonight.
[23:05] <tsimonq2> barry: Sure, although if it's OK with you, I'd like to link the PPA here once I have a solution and at lt have someone else test it ;)
[23:05] <barry> tsimonq2: +1
[23:05] <tsimonq2> s/lt/least/
[23:05] <tsimonq2> barry: OK, cool! I'll let you know! Have a nice night! :)
[23:05] <barry> tsimonq2: thanks, you too!
[23:25] -queuebot:#ubuntu-release- New binary: qbs [ppc64el] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: qbs [s390x] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:26] -queuebot:#ubuntu-release- New binary: qbs [amd64] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: qbs [i386] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: qbs [powerpc] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:34] -queuebot:#ubuntu-release- New binary: qbs [arm64] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: qbs [armhf] (zesty-proposed/universe) [1.7.0+dfsg-3] (no packageset)