[01:12] <RAOF> xnox: Are you aware of the autopkgtest failures for apt/zesty-proposed? From a quick look they appear to be due to a real behaviour change.
[03:05] <nacc> RAOF: there was discussion between slangasek and juliank about that being fixed with sbuild?
[03:05] <nacc> RAOF: about 6 hours ago, i think
[03:07] <RAOF> nacc: oooh, ta. Didn't notice the sbuild task.
[03:08] <nacc> RAOF: np, i wasn't involved, just remembered seeing it go by
[03:16] <slangasek> nacc, RAOF: yeah, I'm retrying those autopkgtests now that sbuild is in -updates
[03:54] -queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.2 => 3.3-2ubuntu7.3] (core)
[04:39] <tsimonq2> slangasek: Is the information here sufficient for an FFE in your eyes? https://bugs.launchpad.net/ubuntu/+source/pupnp-1.8/+bug/1716117
[04:40] <tsimonq2> (it's the Debian Maintainer and someone involved with upstream saying that the version in Artful is buggy and shouldn't be shipped, but that changes should be synced from Debian, it technically breaks Feature Freeze so I want to ask before syncing)
[04:42] <slangasek> tsimonq2: yes. commented to that effect on the bug.
[04:43] <tsimonq2> slangasek: ack, thank you
[04:48] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [ppc64el] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:50] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [amd64] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:50] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [armhf] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:50] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [s390x] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:50] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [arm64] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:51] -queuebot:#ubuntu-release- New binary: pupnp-1.8 [i386] (artful-proposed/universe) [1:1.8.2-2] (no packageset)
[04:58] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [amd64] (artful-proposed) [1:1.8.2-2]
[04:58] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [i386] (artful-proposed) [1:1.8.2-2]
[04:58] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [arm64] (artful-proposed) [1:1.8.2-2]
[04:58] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [ppc64el] (artful-proposed) [1:1.8.2-2]
[04:59] -queuebot:#ubuntu-release- New: accepted puppetdb [amd64] (artful-proposed) [4.4.1-1]
[04:59] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [armhf] (artful-proposed) [1:1.8.2-2]
[04:59] -queuebot:#ubuntu-release- New: accepted pupnp-1.8 [s390x] (artful-proposed) [1:1.8.2-2]
[04:59] -queuebot:#ubuntu-release- Unapproved: rejected mdadm [source] (xenial-proposed) [3.3-2ubuntu7.3]
[05:02] -queuebot:#ubuntu-release- Unapproved: mdadm (xenial-proposed/main) [3.3-2ubuntu7.2 => 3.3-2ubuntu7.3] (core)
[05:04] -queuebot:#ubuntu-release- Unapproved: cryptkeeper (trusty-proposed/universe) [0.9.5-5.1ubuntu3 => 0.9.5-5.1ubuntu3.1] (no packageset)
[05:21] -queuebot:#ubuntu-release- Unapproved: plymouth (zesty-proposed/main) [0.9.2-3ubuntu15 => 0.9.2-3ubuntu15.1] (core)
[05:27] -queuebot:#ubuntu-release- Unapproved: plymouth (xenial-proposed/main) [0.9.2-3ubuntu13.1 => 0.9.2-3ubuntu13.2] (core)
[06:12] <didrocks> good morning
[06:13]  * slangasek waves
[06:57] <acheronuk> morning. on glibc, I have no response to my email to upstream KDE dev about the kscreenlocker test regression. I will try again this afternoon if they happen to be around on IRC today.
[07:50] <LocutusOfBorg> didrocks, do we have voting results? :)
[07:54] <didrocks> LocutusOfBorg: hum, on what? sorry, out of context
[07:55] <LocutusOfBorg> DMB
[07:55] <LocutusOfBorg> but that was a general question
[07:56] <didrocks> I don't manage the DMB vote
[07:56] <didrocks> (nor applied to it ;))
[07:57] <LocutusOfBorg> somebody told that in the voting mail your name was somewhere inside
[07:58]  * LocutusOfBorg already deleted the email, don't care :)
[07:59] <LocutusOfBorg> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_31d21ec25959d7d2
[07:59] <LocutusOfBorg> here they are
[10:05] <doko> where can I see the test overrides? had mbuffer on ppc64el on my list, but now it's overridden
[10:06] <LocutusOfBorg> bzr branch bzr+ssh://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/
[10:06] <LocutusOfBorg> grep mbuffer . -R
[10:06] <LocutusOfBorg> ./vorlon:force-badtest mbuffer/20161115-1/ppc64el
[11:28] -queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (zesty-proposed) [0.9.2-3ubuntu15.1]
[11:28] -queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (xenial-proposed) [0.9.2-3ubuntu13.2]
[12:10] -queuebot:#ubuntu-release- New binary: edk2 [amd64] (artful-proposed/universe) [0~20170911.5dfba97c-1] (no packageset)
[12:25] -queuebot:#ubuntu-release- New: accepted edk2 [amd64] (artful-proposed) [0~20170911.5dfba97c-1]
[13:33] <xnox> doko, i am subscribed to the hints-ubuntu branch and get email about it =) very useful to spy on ~ubuntu-release
[13:34] -queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.22 => 1.2.2-0ubuntu13.1.23] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
[13:48] <LocutusOfBorg> maybe the bot here can write something when an hint is changed, or a transition is opened on tracker
[15:42] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (vivid-proposed/main) [3.19.0-93.101] (core, kernel)
[15:42] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (zesty-proposed/main) [4.10.0-35.39] (core, kernel)
[16:41] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (artful-proposed/main) [4.13.0-11.12] (core, kernel)
[16:52] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (artful-proposed) [4.13.0-11.12]
[17:23] <slangasek> xnox: is the systemd zesty/armhf autopkgtest failure a test bug that's fixed in artful? or something else?  (been failing since February, and apparently no one has bothered to annotate this, just pushed SRUs through around it :/ )
[17:31] <xnox> slangasek, so we noticed zesty/armhf autopkgtest failures; improved on them in artful (via upstream bug report and code changes; and added arch-specific skips in debian/tests/); backported that to zesty, but alas that was not enough to fix zesty/armhf
[17:31] <slangasek> ok
[17:31] <xnox> slangasek, so further investigation fix-up of zesty/armhf is outstanding
[17:32] <slangasek> I'm also trying to understand if the zesty-updates/ppc64el failure is a flaky test or something actually fixed in zesty-proposed
[17:32] <slangasek> diff tells me the answer is 'flaky'
[17:47] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (xenial-proposed/main) [4.4.0-96.119] (core, kernel)
[18:24] <acheronuk> FYI on glibc kscreenlocer test regression. just waiting for upstream to decide on final patch. https://bugs.kde.org/show_bug.cgi?id=384651
[18:25] <acheronuk> *kscreenlocker
[18:46] <bdmurray> doko: bug 1695093 is missing the standard SRU template although I can kind of guess at the test case
[18:46] <bdmurray> doko: and bug 1709727 has a blank regression potential
[18:49] <doko> bdmurray: asan is not used in any package afaik. having the timeouts replaced by suceeding tests in the testsuite seems to be better
[18:49] <doko> bdmurray: and the first one, that should be tested by dannf (and already was with test build)
[18:51] <doko> actually, tome is using it ...
[18:51] <bdmurray> doko: I'm saying the bugs are missing SRU information per the SRU policy point 3 here https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[18:57] <doko> bdmurray: what should I write? that this will regress if the kernel is uploaded again without 48bit-vma support?
[18:59] <doko> wondering how the kernel SRU looked like when this was changed in the release ...
[19:04] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (xenial-proposed) [4.4.0-96.119]
[19:04] -queuebot:#ubuntu-release- New: accepted linux-signed [amd64] (zesty-proposed) [4.10.0-35.39]
[19:07] <slangasek> doko: you should write things down so that the SRU team doesn't have to know everything you know to tell if the SRU is successful or failed
[19:14] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.5 => 2.441.6] (desktop-core)
[19:24] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (xenial-proposed/main) [2.408.16 => 2.408.17] (desktop-core)
[19:25] <slangasek> rbasak, arges: hi, does one of you have time to look at the xenial/zesty livecd-rootfs SRUs in the queue above?  These are critical path for getting cloud images building again in LP; if neither of you has time I will self-accept, but I would prefer another set of eyeballs if possible
[19:26] <bdmurray> I think rbasak is on holiday
[19:27] <nacc> bdmurray: yeah, until next week (and only partial next week, i beleive)
[19:27] <slangasek> ok
[19:27] <slangasek> bdmurray: do you have a minute to look?
[19:28] <bdmurray> slangasek: sure, just a moment
[19:29] <doko> slangasek: could you have a look at the pcs autopkg test failure triggered by python2.7?  you looked at that package before ...
[19:31] <slangasek> doko: checking
[19:33] <slangasek> doko: very different error than what I was fixing before; I was just fixing the proxy env handling on the package, this new error seems to care about something else.  But let's see
[19:37] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.6]
[19:39] <cjwatson> slangasek: (they shouldn't in fact be critical-path now; I fixed this issue in two different ways on the principle of defence in depth, one of which was in launchpad-buildd and is already deployed)
[19:39]  * bdmurray stops then
[19:39] <slangasek> cjwatson: hmm; rcj tells me image builds are still failing
[19:39] <cjwatson> slangasek: ah, depends what the change is
[19:39]  * cjwatson goes to check
[19:39] <cjwatson> there have been several different failures
[19:39] <slangasek> cjwatson: this is related to us not unwinding our own submounts, it's not the lxd dev bind mount thing
[19:40]  * bdmurray starts again
[19:40] <cjwatson> ah, that
[19:40] <cjwatson> yeah, I think vanilla images are OK but not CPC
[19:41] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (xenial-proposed) [2.408.17]
[19:41] <slangasek> unfortunately there was a change already staged for SRU when this came in, so that landed and revealed some more brittleness in the cpc sauce
[19:41] <slangasek> which is now being made less brittle
[19:41] <cjwatson> right, it could have been done just in CPC, but I agree it's probably better to fix here
[19:42] <cjwatson> slangasek: er, isn't the umount_partition change wrong though?
[19:42] <slangasek> not to my knowledge! :)
[19:42] <cjwatson> slangasek: teardown_mountpoint umounts everything under $mountpoint, but not $mountpoint itself, so that's a significant change in behaviour, probably not for the better
[19:42] <cjwatson> slangasek: (it also now involves two udevadm settle calls, though that's a minor point)
[19:43] <slangasek> cjwatson: ah - the point is that there are some times when the top-level dir is not a mount point (because e.g. it's a source dir for mksquashfs); so we now have a function which is symmetric with setup_mountpoint, to only tear down the bits /under/ that dir
[19:43] <cjwatson> slangasek: I agree, but that's not where umount_partition is used
[19:44] <cjwatson> slangasek: teardown_mountpoint makes sense for those cases and I agree with its introduction
[19:44] <cjwatson> slangasek: but e.g. in live-build/ubuntu-cpc/hooks/032-disk-image.binary, umount_partition must umount $mountpoint as well or the following rmdir will fail
[19:44] <slangasek> cjwatson: ah. we leave the 'umount -R $mountpoint' in place below that
[19:45] <cjwatson> slangasek: that's not what I see in http://launchpadlibrarian.net/336881284/livecd-rootfs_2.441.5_2.441.6.diff.gz ?
[19:45] <cjwatson>  umount_partition() {
[19:45] <cjwatson>      local mountpoint=${1}
[19:45] <cjwatson> -    mv resolv.conf.tmp "$mountpoint/etc/resolv.conf"
[19:45] <cjwatson> -    umount -R $mountpoint
[19:45] <cjwatson> +    teardown_mountpoint $mountpoint
[19:45] <slangasek> looking
[19:45] <slangasek> it looks correct on xenial
[19:45] <slangasek> yeah, zesty's is borked
[19:46] <cjwatson> also trunk
[19:46] <acheronuk> is there a problem publishing from proposed to release? getting multiple instances of unsatisfiable deps
[19:46] <slangasek> cjwatson: thanks - clearly rcj and I had a blindspot
[19:47] <cjwatson> lucky I happened to look at zesty :)
[19:47] <cjwatson> the /var/{cache,lib}/apt divergence is odd, but I assume that's due to existing weirdness
[19:47] <slangasek> yes
[19:48] <rcj> slangasek, cjwatson: I screwed up the patch on trunk and zesty when I tried to apply it from xenial.
[19:50] -queuebot:#ubuntu-release- Unapproved: livecd-rootfs (zesty-proposed/main) [2.441.6 => 2.441.7] (desktop-core)
[19:51] <slangasek> ^^ self-accepted
[19:52] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (zesty-proposed) [2.441.7]
[19:54] <acheronuk> Ok. I hope sorted now. sorry to interrupt you 2. Usually publishing delays on seem to make things uninstalable for a few mins, but that was nearly an hr
[19:55] <slangasek> acheronuk: http://people.canonical.com/~ubuntu-archive/proposed-migration/artful_uninst.txt will generally show the current state
[19:56] <acheronuk> slangasek: thank you :)
[19:57] <acheronuk> that reminds me that I need to make a decision on cantor :/
[20:03] <slangasek> doko: badtest; it looks for /etc/init.d/networking to know if 'lsb:networking' is available; so pacemaker-cli-utils is now buggy
[20:04] <slangasek> doko: actually it's one step down from pcs though, so probably skiptest here
[20:05] <doko> slangasek: if you skiptest, please could you ignore the test failures for twisted? twisted itself is blocked (free is working on that), so that python2.7 with dropping the _fpectl extension can migrate?
[20:05] <doko> bdmurray: bug descriptions are updated
[20:08] <slangasek> doko: yes, I'll see what I can sort out.  FWIW there's a new pacemaker in -proposed also, which ftbfs; I can't tell if it fixes this problem or not since I can't find any references to /etc/init.d/networking in pacemaker source
[20:08] <nacc> slangasek: which problem?
[20:08] <slangasek> nacc: pcs autopkgtest fails because crm_thingy resource yadda lsb:networking tries to look at /etc/init.d/networking, which is from ifupdown and no longer exists
[20:09] <nacc> slangasek: ah
[20:10] <doko> armhf only?
[20:11] <slangasek> timing of the run vs. availability of ifupdownless image?
[20:11] <slangasek> I can reproduce the specific failure here on amd64 in an ifupdownless chroot
[20:12] <nacc> slangasek: isn't that from src:pcs itself?
[20:12] <nacc> slangasek: it's tests seem to do some lsb:networking stuff?
[20:13] <slangasek> $ crm_resource --show-metadata lsb:networking
[20:13] <slangasek> Metadata query for lsb:networking failed: -2
[20:13] <slangasek> nacc: ^^
[20:13] <slangasek> strace on that shows it trying to access /etc/init.d/networking
[20:13] <slangasek> this is independent of pcs
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted gcc-5 [source] (xenial-proposed) [5.4.0-6ubuntu1~16.04.5]
[20:13] <slangasek> but I haven't pinned this down in source yet
[20:17] <nacc> slangasek: i think lrmd_api_get_metadata -> lsb_get_metadata -> LSB_ROOT_DIR
[20:17] <nacc> include/crm/services.h:#    define LSB_ROOT_DIR "/etc/init.d"
[20:17] <nacc> presuming it's a lsb:networking query?
[20:18] <slangasek> y
[20:18] <slangasek> so does this mean 'lsb' always just looks at /etc/init.d?
[20:19] <nacc> slangasek: if it isn't given an absolute path (e.g. lsb:/etc/networking would look there)
[20:19] <nacc> slangasek: but for lookup by type, i think so
[20:19] <slangasek> ok so it is a pcs bug
[20:19] <slangasek> nacc: thanks, badtesting pcs then
[20:19] <nacc> the above is in src:pacemaker, but it's all so intertwined :)
[20:19] <nacc> slangasek: np
[20:27] <slangasek> doko: I'm not sure I understand what you're asking for wrt twisted.  You said twisted is blocked and free is working on it; if twisted is blocked, what is helped by ignoring its test failures?
[20:29] <slangasek> doko: the one last thing I do see blocking python2.7 is this darn openvswitch/i386
[20:30] <doko> jamespage: told me that this is caused by some setup issue, nplan if I correctly remember
[20:31] <slangasek> however, openvswitch/i386 has had passing tests in between the failures
[20:32] <doko> hrm, twisted doesn't show up there anymore ...
[20:32] <doko> strange
[20:32] <doko> so twisted is not a blocker for python2.7
[20:33] <slangasek> according to http://autopkgtest.ubuntu.com/packages/t/twisted/artful/amd64 twisted was only being tested for -defaults, not for 2.7
[20:33] <slangasek> "conveniently"
[20:33] <doko> hahaha
[20:34] <doko> also was wondering about the little amount of libjpeg-turbo dependencies ... another dependency package issue
[21:06] -queuebot:#ubuntu-release- New: accepted python-certbot [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
[21:18] <robert_ancell> Who can I bribe to get snapd-glib out of the trust NEW queue? bug 1698984
[21:45] <slangasek> jamespage: AIUI we're still waiting for an openstack team decision on xclip vs. xsel on LP: #1713617
[21:46] <slangasek> robert_ancell: I might be amenable to bribing on Friday :)
[21:47] <robert_ancell> slangasek, (bribe may delayed until NY)
[21:48] <jamespage> slangasek: yeah sorry I'll get that sorted now
[23:39] -queuebot:#ubuntu-release- New binary: python-certbot-apache [amd64] (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1] (no packageset)
[23:39] -queuebot:#ubuntu-release- New binary: python-certbot-nginx [amd64] (xenial-proposed/universe) [0.14.2-0ubuntu0.16.04.1] (no packageset)
[23:46] -queuebot:#ubuntu-release- New: accepted python-certbot-apache [amd64] (xenial-proposed) [0.14.2-0ubuntu0.16.04.1]
[23:49] <slangasek> LocutusOfBorg: puma 3.6.0-1build1, what prompted that?  The existing package was FTBFS, so not much point in a no-change rebuild...