[01:23] <slangasek> Laney: do you have any insight into the systemd autopkgtest regression (failure to recover from reboot, where this did not happen previously)? looks like some sort of behavior change in the testbed
[09:03] <Laney> slangasek: pitti hinted barry the other day to look at the kernel, something to do with nested qemu
[09:19] <Laney> slangasek: I think this is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1658178 which apw filed at the same time
[09:26] <apw> Laney, interestingly those are showing the tester getting unexpectedly "Killed" and the one we are chasing on i386 is doing that too, in apparmor tests
[09:28] <Laney> apw: it says it timed out
[09:28] <Laney> also pitti said he ran it on debian's 4.9 kernel and it happened for him with that one too
[09:35] <apw> Laney, not uncommon when the world gets oom'd i guess
[09:36] <Laney> It's a theory
[09:37] <Laney> Sounds like it was reproducible locally for him anyway, so someone could confirm that
[09:38] <apw> investigations are on-going at least
[10:00] <LocutusOfBorg> hello, like every monday morning, I'm looking for an AA to make some transitions end/finish
[10:08] <apw> LocutusOfBorg, let us know what you are looking to do, and we can see what we can do
[10:12] <LocutusOfBorg> sigh LP: #1624694
[10:22] <apw> LocutusOfBorg, done
[10:34] <LocutusOfBorg> z3
[10:34] <LocutusOfBorg> <3
[10:34] <LocutusOfBorg> another thing is some demotions to proposed to see ocaml stack migrate
[10:35] <LocutusOfBorg> they are all RC buggy and out of Stretch already
[10:35] <LocutusOfBorg> (leaf packages)
[10:35] <LocutusOfBorg> and third: some hint about imagemagick6 transition might be helpful, that emacs issue is making it stuck
[10:53] <apw> LocutusOfBorg, is there a bug for the demotions ?
[10:58] <LocutusOfBorg> nope, usually nobody asks for it
[10:59] <LocutusOfBorg> when the stuff is already out from debian I mean
[10:59] <LocutusOfBorg> (and is leaf)
[12:01]  * apw will see what he canf ind
[12:02] <Laney> presumably a list would be helpful at least
[12:02] <LocutusOfBorg> oh an llvm trivial promotion to main
[12:03] <LocutusOfBorg> lldb-3.9/amd64 unsatisfiable Depends: python-lldb-3.9
[12:04] <LocutusOfBorg>  please kick janest-core-extended janest-core-kernel janest-core pa-test ocaml-re2 ocaml-textutils in proposed
[12:04] <LocutusOfBorg> this is the list
[12:05] <rbasak> Could someone force-badtest dovecot/1:2.2.25-1ubuntu2/armhf please? This is a known unstable test. It takes an unreasonable number of retry attempts to get it to pass. This is blocking mysql-5.7 migration. I did look into it but I couldn't find the race :-/
[12:06] <apw> rbasak, looking
[12:08] <apw> rbasak, done
[12:09] <Laney> rbasak: Could you make that test non-fatal for the next upload maybe?
[12:09] <apw> rbasak, right if we are going to ignore it anyhow ...
[12:35] <rbasak> Laney, apw: I'd like to. cpaelzer suggest the same. But the test is probably useful on armhf. I wonder if there's any dep8 thing to limit a test by arch? Or should I just make it check dpkg-architecture?
[12:37] <rbasak> Thank you for forcing for now, anyway
[12:37] <Laney> rbasak: There isn't, but I was thinking you'd do it on just that one test which would require patching the code anyway
[12:37] <Laney> (I assume)
[12:38] <rbasak> If you're saying that I use dpkg-architecture or similar to make the test result ignored on armhf but still fatal if failed on amd64, then sure, we can do that.
[12:41] <Laney> rbasak: oh right, I just looked and the testsuite is actually directly contained in debian/tests
[12:41] <Laney> I thought you'd have to modify the upstream testsuite to make that one non-fatal
[12:41] <Laney> So yeah, what you say
[12:45] <rbasak> OK, thanks
[13:22] <cpaelzer> rbasak: in other cases I have touched or written tests that just check dpkg-architecture
[13:23] <cpaelzer> rbasak: although a generic arch feature in d/t/control would be nice I'd expect that since the code snippet is so small nobody ever bothered
[13:23] <cpaelzer> the snipped for your test to check on arch
[13:23] <rbasak> cpaelzer: thanks. Good to know that seems to be the best method right now
[13:24] <cpaelzer> rbasak: if you want me to point to a snippet to resue let me know
[13:29] <cpaelzer> rbasak: https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=blob;f=debian/tests/check-dpdk-supported-arch.sh;h=1105dc2edf4dd4f7ab7f47b715f228efbfbffcf6;hb=refs/heads/16.11.x
[13:29] <cpaelzer> I realized it is useless to ask to ask :-) if you need feel free to pick that up (or suggest changes if you want)
[13:29] <cpaelzer> we reuse that in different tests that are in our d/t/*
[13:32] <rbasak> cpaelzer: thanks. I've noted this in the bug.
[13:52] <acheronuk> release team: ca someone please make an exception, force, skip or whatever is appropriate, for the ppc64el and s390x of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gwenview
[13:53] <acheronuk> one of the test dependencies now requires QtWebEngine, which is not and I don't think ever will be buildable so satisfied on those architectures
[13:54] <LocutusOfBorg> apw, <3
[13:56] <LocutusOfBorg> oh... you need a bigger hammer :(
[13:56] <LocutusOfBorg>     * amd64: libcore-extended-ocaml-dev, libcore-kernel-ocaml-dev, libcore-ocaml-dev, libpa-test-camlp4-dev, libre2-ocaml-dev, libtextutils-ocaml-dev
[13:56] <LocutusOfBorg> they migrated again :/
[14:31] <apw> LocutusOfBorg, grrr ... ok
[14:33] <LocutusOfBorg> block proposed maybe?
[14:33] <apw> LocutusOfBorg, yep, done that
[14:44] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (yakkety-proposed) [3.3+git50-g3c0349b-2~ubuntu16.10.1]
[14:44] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (trusty-proposed) [3.3+git50-g3c0349b-2~ubuntu14.04.1]
[14:44] -queuebot:#ubuntu-release- Unapproved: rejected sosreport [source] (xenial-proposed) [3.3+git50-g3c0349b-2~ubuntu16.04.1]
[14:44] <apw> ^ will be replaced by an updated zesty and associated backports
[14:48] <zul> hey can someone get panko out of binary new please?
[14:53] <LocutusOfBorg> apw, your hammer is not strong enough :/
[14:56] <apw> LocutusOfBorg, erp how is that possible, they are blocked in hint
[14:56] <LocutusOfBorg> don't know... I'm going to open a bug
[14:56] <Laney> check the log first
[14:57] <apw> Laney, i can only assume the hints hit too late or something
[14:57] <LocutusOfBorg> apw, probably, because dinstall run some seconds before your hint
[14:57] <LocutusOfBorg> ran
[14:58] <apw> though i don't know how unlucky i could have gotten
[15:03] <Laney> yeah I expect if they are demoted again it'll be good now
[15:04] <apw> Laney, working on that presumption.  it seems the blocks needs to be in more than a couple of mins before
[15:05] <apw> i guess we update the hints, then do something slow, then evaluate the world against the hints
[15:36] <coreycb> hello, can someone from the release team please reject python-oslo.context python-oslo.context from zesty-proposed?
[15:36] <coreycb> that is, python-oslo.context 2.12.0-0ubuntu1
[15:41] <slangasek> Laney: nested qemu> ah; should that bug be refiled against the kernel, then?
[15:43] <Laney> slangasek: I suppose it will be if apw's minion's investigations confirm the hunch
[15:47] <slashd> Hi SRU, could you please take a look at "krb5 | 1.13.2+dfsg-5ubuntu2" waiting in the Xenial upload queue in order to get a build in -proposed this week if possible ? It will be appreciated, thanks
[15:48] <barry> good to see network-manager got promoted.  any idea what was causing the systemd 'upstream' test to fail and how that got unblocked?
[15:51] <apw> slashd, the existing krb5 has a regressing ADT test so it stuck in -proposed
[15:54] <seb128> apw, pitti said on friday that it was fine to ignore, that's a posgresql test issue see https://irclogs.ubuntu.com/2017/01/20/%23ubuntu-devel.html#t10:19
[16:03] <slashd> apw, please let me know if the situation changes
[16:04] <rbasak> apw: I think it's fine to release krb5 on all three series. Shall I go ahead and do that or are you still looking?
[16:04] <apw> rbasak, i am in the middle of it ...
[16:04] <apw> rbasak, you concur that that openafs failure does not look related in trusty ?
[16:05] <rbasak> apw: agreed. It looks like it's been failing that way for a long time.
[16:06] <apw> rbasak, all gone ... i'll let that propogate before reviewing the new one
[16:07] <apw> slashd, there is no coresponding yakkety upload, do i conclude it is not needed there ?
[16:07] <acheronuk> forensics-all seems stuck in zesty proposed as it requires https://packages.debian.org/sid/rekall-core
[16:07] <acheronuk>  is this syncable?
[16:08] <acheronuk> that issue would block KDE's gwenview from migrating
[16:09] <rbasak> apw: thanks!
[16:09] <slashd> apw, Y and Z already has the code in place
[16:10] <sil2100> bdmurray: hey! You want to take care of ceph in the xenial queue, or can I pick it up? Asking since you accepted the yakkety version
[16:11] <bdmurray> sil2100: feel free to review it
[16:27] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (xenial-proposed) [10.2.5-0ubuntu0.16.04.1]
[16:30] -queuebot:#ubuntu-release- Unapproved: accepted krb5 [source] (xenial-proposed) [1.13.2+dfsg-5ubuntu2]
[16:31] <apw> slashd, ^
[16:33] <slashd> apw, thanks much appreciated
[17:22] -queuebot:#ubuntu-release- New binary: knot [ppc64el] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: knot [s390x] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [ppc64el] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: gtkhash [powerpc] (zesty-proposed/universe) [1.0-1] (no packageset)
[17:28] <Laney> 'sup with the arm64 buildds?
[17:28] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [s390x] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[17:31] -queuebot:#ubuntu-release- New binary: knot [powerpc] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[17:35] <apw> Laney, in motion currently apparently
[17:35] <Laney> apw: literally
[17:36] <apw> Laney, literally
[17:36] <Laney> raise RecursionError
[17:39] -queuebot:#ubuntu-release- New sync: rekall (zesty-proposed/primary) [1.6.0+dfsg-1]
[17:43] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [powerpc] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[17:52] -queuebot:#ubuntu-release- New binary: knot [amd64] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[17:58] -queuebot:#ubuntu-release- New binary: libpgobject-util-dbchange-perl [amd64] (zesty-proposed/universe) [0.050.2-1] (no packageset)
[18:02] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [i386] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[18:05] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [amd64] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[18:57] <sil2100> smoser: hey! I'm reviewing the curtin xenial SRU right now and out of curiosity - what's the reason for removing merge-upstream from the new-upstream-snapshot script?
[18:59] <smoser> sil2100, because i gave up
[19:00] <smoser> merge upstream (prob ably because of some historic luser error or current luser error) was doing the bzr thing where it decides that although 2 files are identical, it should show a diff on the removal of one file and replacement of that same file.
[19:01] <smoser> ie, bzr tracks 'files' rather than just their content, and the file-id in the trunk branh somehow got to be different than the file-id in the packaging brach
[19:01] <sil2100> eh, ok
[19:01] <smoser> at least that is how i understand it, andso 'bzr diff old-version new-version' becomes useless.
[19:04] <sil2100> Anyway, the replacements looks sane, was just missing some context about the change in the comments, but it's all good
[19:05] <sil2100> smoser: IIUC some of the bugs from the release are also for yakkety, right? Could you prepare a yakkety upload later as well?
[19:06] <smoser> have you ever seen taht before ? the file thing ?
[19:08] <smoser> yeah, i can do an upload for yakkety
[19:08] <sil2100> Don't remember seeing it, but I haven't used merge-upstream quite a while though
[19:09] <sil2100> smoser: ok, another small question as it's the first time I review curtin: why is the zesty bzr snapshot revno different from the xenial one? Is it because of the new-upstream-snapshot changes?
[19:11] <sil2100> Ah, no, I see, xenial test skips
[19:11] -queuebot:#ubuntu-release- Unapproved: qemu (xenial-proposed/main) [1:2.5+dfsg-5ubuntu10.7 => 1:2.5+dfsg-5ubuntu10.8] (ubuntu-server, virt)
[19:12] <sil2100> Ok
[19:13] <sil2100> All good, looks like it's the same
[19:13] <sil2100> Ignore my question in that case
[19:14] -queuebot:#ubuntu-release- Unapproved: accepted curtin [source] (xenial-proposed) [0.1.0~bzr437-0ubuntu1~16.04.1]
[19:20] <smoser> sil2100, oh. i uploaded 437 to xenial. i can upload 437 to zesty now
[19:20] <smoser> to make sure that it is newer
[19:20] <smoser> but yeah, the difference is just a commit and a revert
[19:28] <cpaelzer> hi, might anybody have time to look at considering migrate for Xenial as well for bug 1626972 ?
[19:49] <smoser> sil2100, just now uploaded to yakkety.
[19:50] -queuebot:#ubuntu-release- Unapproved: curtin (yakkety-proposed/main) [0.1.0~bzr425-0ubuntu1 => 0.1.0~bzr437-0ubuntu1~16.10.1] (ubuntu-server)
[20:37] <sil2100> smoser: thanks - yeah, you could upload for consistency, but it's all good since they're both the same
[21:31] <bdmurray> slangasek: could you fully phase apport for xenial? The SRU involved an import change at the beginning of a file which will change line numbers for everything thereby creating a different SAS for python trackebacks.
[21:42] -queuebot:#ubuntu-release- New binary: knot [arm64] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[21:50] -queuebot:#ubuntu-release- New binary: knot [armhf] (zesty-proposed/universe) [2.4.0-2] (no packageset)
[21:53] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [arm64] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[21:55] -queuebot:#ubuntu-release- New binary: ros-opencv-apps [armhf] (zesty-proposed/universe) [1.11.14-1] (no packageset)
[22:06] <slangasek> bdrung: phasing done
[22:06] <slangasek> sigh
[22:06] <slangasek> bdmurray: phasing done
[22:08] -queuebot:#ubuntu-release- Unapproved: flash-kernel (xenial-security/main) [3.0~rc.4ubuntu62.1.1 => 3.0~rc.4ubuntu62.1.1] (core) (sync)
[22:08] <barry> Laney, cyphermox, slangasek i see network-manager got promoted, which means systemd 232-10ubuntu1 probably fixed the 'upstream' autopkgtest.  or was some other explicit fix made to get systemd's autopkgtests passing again?
[22:09] -queuebot:#ubuntu-release- Unapproved: flash-kernel (yakkety-security/main) [3.0~rc.4ubuntu64.1.1 => 3.0~rc.4ubuntu64.1.1] (core) (sync)
[22:09] -queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (yakkety-security/multiverse) [1.20161020-0ubuntu1~1.1 => 1.20161020-0ubuntu1~1.1] (no packageset) (sync)
[22:10] -queuebot:#ubuntu-release- Unapproved: linux-firmware-raspi2 (xenial-security/multiverse) [1.20161020-0ubuntu1~0.1 => 1.20161020-0ubuntu1~0.1] (no packageset) (sync)
[22:21] <slangasek> barry: as systemd tests are currently broken I marked them such in proposed-migration
[22:21] <barry> slangasek: ack, thanks
[22:22] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [sync] (xenial-security) [3.0~rc.4ubuntu62.1.1]
[22:22] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [sync] (xenial-security) [1.20161020-0ubuntu1~0.1]
[22:24] -queuebot:#ubuntu-release- Unapproved: accepted flash-kernel [sync] (yakkety-security) [3.0~rc.4ubuntu64.1.1]
[22:24] -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware-raspi2 [sync] (yakkety-security) [1.20161020-0ubuntu1~1.1]
[22:35] <acheronuk> could someone please force-badtest okular/4:16.04.3-0ubuntu1. that old KDE4 version has a new Qt5 version about to take it's place, so the single Qt4 failing test there is pretty much an irrelevance
[22:35] <acheronuk> thx :)
[23:38] -queuebot:#ubuntu-release- New binary: python-limits [amd64] (zesty-proposed/universe) [1.2.1-1] (no packageset)