[00:19] -queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-5ubuntu9 => 2.02+dfsg1-5ubuntu9] (core)
[01:04] -queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-5ubuntu9 => 2.02+dfsg1-5ubuntu9] (core)
[01:38] <bluesabre> vorlon: xubuntu-devel@lists.ubuntu.com should suffice
[01:41] <vorlon> bluesabre: done, thanks
[01:49] <vorlon> jbicha: I think you missed subscribing ubuntu-archive to LP: #1802697
[01:49] <ubot5> Launchpad bug 1802697 in rarian (Ubuntu) "Remove rarian from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1802697
[03:00] <jbicha> I'm surprised you didn't go ahead and remove rarian too! thanks though :)
[05:37] <rbalint> hi, i'd like to start the transition of libnfs in Debian and in Ubuntu if no-one opposes
[05:38] <rbalint> it is a small one https://release.debian.org/transitions/html/auto-libnfs.html
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [amd64] (disco-proposed) [20190101+dfsg-2]
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [armhf] (disco-proposed) [20190101+dfsg-2]
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [ppc64el] (disco-proposed) [20190101+dfsg-2]
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [arm64] (disco-proposed) [20190101+dfsg-2]
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [s390x] (disco-proposed) [20190101+dfsg-2]
[05:59] -queuebot:#ubuntu-release- New: accepted re2 [i386] (disco-proposed) [20190101+dfsg-2]
[08:20] <LocutusOfBorg> jbicha, I had to merge php-defaults
[08:21] <LocutusOfBorg> because due to version constraints, stuff like e.g. php-apcu was not installable
[08:21] <LocutusOfBorg> or php-memcached
[08:29] -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1031.36]
[09:41] <juliank> Laney: Looking at the networkmanager/dnsmasq mess, should we just revert the upstream commit in dnsmasq that broke things?
[09:41] <juliank> would at least get stuff unblocked a bit
[09:42]  * juliank is trying to get gnutls28 migrated
[09:43] <Laney> juliank: don't know, maybe talk to Robie/server team about that?
[09:44] <Laney> I was/am hoping to poke upstream into fixing it or at least giving me enough information on how to
[09:45] <Laney> but I'm a clueless person really, if someone with more clue doesn't mind doing that to unblock the situation then cool by me
[09:51] <juliank> rbasak: ^ Laney found the commit in dnsmasq that caused the regression in network-manager tests, namely http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=0a496f059c1e9d75c33cce4c1211d58422ba4f62;hp=e27825b0ef1e79ab05b1752c8c838cb43ad39d79
[09:52] <juliank> rbasak: We could revert that temporarily to unblock things while getting a proper fix
[09:53] <juliank> this restores a problem with RAs not being sent, but should not cause any regressions compared to stable releases
[09:56] <Laney> or you can do something hacky like add a static bool to only do that codepath one time
[09:57]  * rbasak looks
[09:58] <juliank> Laney: static seems wrong though, because this is supposed to run once per interface
[09:58] <Laney> indeed
[09:59] <Laney> the proposal I suggest upstream checked a field in the struct
[09:59] <Laney> 🤷
[10:01] <rbasak> I agree that reverting seems unlikely to cause any regressions from our perspective. But what happens if an upstream fix never arrives?
[10:02] <juliank> the patch certainly makes sense logically, as setting the new address before doing RAs is more correct, but I don't see it mkaing a difference as we are not starting anything yet.
[10:02] <rbasak> I'm not keen on having to maintain that patch then, as I guess no Ubuntu dev really understands it?
[10:02] <rbasak> Feels to me that there's some kind of latent state management bug upstream.
[10:03] <rbasak> Does the regression being introduced actually cause a problem for us? Or just the dep8 failure?
[10:03] <rbasak> I'd prefer to skip/modify the test and not carry the patch if it actually won't be damanging to us.
[10:03] <Laney> someone else posted a thread on the upstream list about infinite RAs
[10:04] <Laney> that person said it randomly went away for them, but ...
[10:14] <juliank> dnsmasq code is terrible
[10:26] <juliank> I feel like there is definitely a bug in there
[10:31] <juliank> Laney: I wonder what happens if we insert a break at the end of the if in the upstream patch.
[10:32] <juliank> Currently, this is overriding _all_ non-template entries with a smaller prefix for the same subnet
[10:32] <Laney> I'd advise you to take any suggestions to the mailing list
[10:32] <juliank> and then starts doing ra on them all
[10:32] <juliank> Laney: That's only reliable reproducble on the infra, right?
[10:33] <Laney> that's where I've been doing it
[10:34] <Laney> download a deb into temp/ and find my command in history
[10:37] <juliank> Laney: um, what was the hostname again? Seems I forgot it
[10:37] <juliank> and my bash_history forgot it too
[10:41] <Laney> wendigo
[10:43] <juliank> thanks
[10:45] <juliank> oh nice, it's a 1.0 package, not a 3.0 quilt
[10:45] <juliank> and no patch queue either
[10:47] <Laney> the maintainer is the upstream developer, don't think it matters that much
[10:47] <Laney> actually it made it nice and easy for me to test out changes :-)
[10:48] <juliank> well, that explains a lot
[10:48] <LocutusOfBorg> do we know that armhf autopkgtests are loosing work?
[10:48] <LocutusOfBorg> e.g. autopkgtest for php-horde-listheaders/unknown: armhf: Regression ♻
[10:48] <LocutusOfBorg> oh... network issue
[11:12] <juliank> rbasak: mysql-5.7 (and probably other versions) tests fail because one tests expects an event of date 2018-12-31 to be recorded, but it's in the past and hence dropped... fun
[11:12] <juliank> This should fix it: https://paste.ubuntu.com/p/HK3p28KNkz/
[11:13] <juliank> This was fixed upstream in 5.7.26, but that's not been released, and I don't know if they have a public git to find their patch
[11:14] -queuebot:#ubuntu-release- New binary: mando [amd64] (disco-proposed/universe) [0.6.4-4] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: botan [s390x] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:20] -queuebot:#ubuntu-release- New binary: botan [ppc64el] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:21] <LocutusOfBorg> juliank, https://github.com/mysql/mysql-server/tree/5.7 ?
[11:22] <juliank> LocutusOfBorg: Well, that does not contain this year's commits
[11:23] <juliank> I think they dump code after release?
[11:23] <LocutusOfBorg> oh... you are right... it was saying "updated 5 days ago", but probably that is the last pull/issue commented/opened
[11:28] <rbasak> juliank: thanks!
[11:38] -queuebot:#ubuntu-release- New binary: botan [amd64] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: botan [arm64] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: botan [i386] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:43] <juliank> E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/l/lz4/liblz4-1_1.8.3-1ubuntu1_armhf.deb  Could not connect to ftpmaster.internal:80 (91.189.89.99), connection timed out
[11:43] <juliank> wooho
[11:44] -queuebot:#ubuntu-release- New binary: botan [armhf] (disco-proposed/universe) [2.8.0-3] (no packageset)
[11:45]  * LocutusOfBorg retries some armhf tests
[11:58] <ahasenack> I'm checking backuppc on armhf again, it runs in a lxd and for some reason a regular user cannot run "/bin/ping6", which is a symlink to the suid root binary /bin/ping
[11:58] <ahasenack> it's hard to get my hands on an armhf lxd
[11:59] <Laney> vorlon was looking into that
[12:01] <LocutusOfBorg> ahasenack, iputils is to blame
[12:02] <ahasenack> LocutusOfBorg: how so?
[12:03] <LocutusOfBorg> meh, https://launchpad.net/ubuntu/+source/iputils/3:20180629-2ubuntu2 some fscap missing on lxd, so the bit are not set, something denies
[12:03] <ahasenack> I see
[12:04] <ahasenack> "everywhere including lxd"
[12:04] <LocutusOfBorg> I missed it, because the last good test has already the bad iputils, but the problem is that during upgrade from old to new, the bit was already set
[12:04] <LocutusOfBorg> so we got the issue once it migrated, because new installation of the tool fails
[12:04] -queuebot:#ubuntu-release- New: accepted botan [amd64] (disco-proposed) [2.8.0-3]
[12:04] -queuebot:#ubuntu-release- New: accepted botan [armhf] (disco-proposed) [2.8.0-3]
[12:04] -queuebot:#ubuntu-release- New: accepted botan [ppc64el] (disco-proposed) [2.8.0-3]
[12:04] -queuebot:#ubuntu-release- New: accepted mando [amd64] (disco-proposed) [0.6.4-4]
[12:04] -queuebot:#ubuntu-release- New: accepted botan [arm64] (disco-proposed) [2.8.0-3]
[12:04] -queuebot:#ubuntu-release- New: accepted botan [s390x] (disco-proposed) [2.8.0-3]
[12:04] -queuebot:#ubuntu-release- New: accepted botan [i386] (disco-proposed) [2.8.0-3]
[12:05] <ahasenack> you mean when the image is generated with that iputils?
[12:05] <LocutusOfBorg> yep
[12:06] <LocutusOfBorg> so we need probably a new lxc on the infra, or something like that, and vorlon is having a look iirc
[12:09] <ahasenack> ok, thanks
=== shadeslayer is now known as shadeslayer[m]
=== shadeslayer[m] is now known as shadeslayer
[15:09] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (bionic-proposed/partner) [1:20181205.1-0ubuntu0.18.04.1 => 1:20190108.1-0ubuntu0.18.04.1] (no packageset)
[15:09] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (trusty-proposed/partner) [1:20181205.1-0ubuntu0.14.04.1 => 1:20190108.1-0ubuntu0.14.04.1] (no packageset)
[15:09] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (cosmic-proposed/partner) [1:20181205.1-0ubuntu0.18.10.1 => 1:20190108.1-0ubuntu0.18.10.1] (no packageset)
[15:09] -queuebot:#ubuntu-release- Unapproved: adobe-flashplugin (xenial-proposed/partner) [1:20181205.1-0ubuntu0.16.04.1 => 1:20190108.1-0ubuntu0.16.04.1] (no packageset)
[15:17] <juliank> There are 3 regressions left for gnutls28; the gnupg2 one should be fixed by gnupg2 in proposed
[15:17] <juliank> systemd fails its boot smoke test on arm64
[15:18] <juliank> and network-manager still hits the dnsmasq bug (which is in release), but only on ppc64el
[15:19] <juliank> The new gnutls28 is also causing a lot of unrelated test failures, because it's needed by new libraries in proposed but not pulled in correctly
[15:21] <juliank> So, it seems the best thing to do is to move ahead here
[15:21] <Laney> want to upload that dnsmasq revert?
[15:21] <Laney> If it comes down to the unrelated systemd thing we could go for a skiptest
[15:22] <juliank> Laney: I think we should skiptest with both, and keep dnsmasq as-is for now
[15:22] <Laney> why's that then?
[15:23] <juliank> I'm starting to lose track of the uploads
[15:24] <juliank> but um, I can upload it. But there might very well be tests in reverse deps that fail because they depend on stuff linked against the new gnutls28
[15:24] <juliank> which is what I'm hitting with gnupg2 right now
[15:24] <juliank> which I uploaded for gnutls28 :)
[15:25] <juliank> Releasing gnutls28 first, we simply get a lot more working autopkgtests
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (cosmic-proposed) [1:20190108.1-0ubuntu0.18.10.1]
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (bionic-proposed) [1:20190108.1-0ubuntu0.18.04.1]
[15:27] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (xenial-proposed) [1:20190108.1-0ubuntu0.16.04.1]
[15:27] <Laney> We can retry n-m with gnutls28/dnsmasq/nm and then when it goes green, add the skiptest and then retry everything else after gnutls28 migrates
[15:28] -queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190108.1-0ubuntu0.14.04.1]
[15:29]  * Laney has done similar with gnupg2 triggered by gnutls28 just now
[15:30] <juliank> I'll do dnsmasq now :)
[15:31] <juliank> in any case, gnutls 3.6.5 is a quite some annoyance
[15:39] <juliank> I missed that they bumped up shlibs deps for all symbols to 3.6.5 when I uploaded it
[15:40] <juliank> there are nicer ways to handle adding new members to enums
[15:41] <juliank> no actually not
[15:45] <juliank> Laney: FWIW, my idea for dnsmasq did not help
[15:45] <juliank> I hope upstream figures out the issue
[15:46] <Laney> indeed
[15:46] <Laney> presumably if it's a real problem other people will start to report it
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (bionic-proposed) [1.8.10-2ubuntu2]
[16:17] <jamespage> bdmurray: ta :-)
[16:20] <bdmurray> jamespage: no problem, sorry for any delay
[16:20] <jamespage> bdmurray: no worries it was a odd one
[16:29] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11.3]
[16:31] <vorlon> LocutusOfBorg, Laney, ahasenack: I looked into it, I did deploy the new lxd and it didn't change the results.  I don't know why the images are ending up without the fscaps set, and I need guidance from stgraber here (or else we should revert iputils)
[16:33] <stgraber> vorlon: what image is used for this exactly?
[16:35] <juliank> Laney: Just retriggered nm with gnutls28,dnsmasq,nm; hopefully this passes
[16:36] <juliank> Well, all triggers: ['gnutls28/3.6.5-2ubuntu1', 'gobject-introspection/1.58.3-1', 'network-manager/1.12.6-0ubuntu3', 'dnsmasq/2.80-1ubuntu1']
[16:36] <vorlon> stgraber: images:ubuntu/$series/armhf
[16:37] <juliank> oh well, should have added wpa to the list of triggers
[16:37] <cyphermox> could someone please review grub2 amd64/arm64 binaries in the unapproved queue for disco?
[16:40] <stgraber> vorlon: ok, let me check that one, maybe there's something wrong in our build process that'd explain this
[16:40] <stgraber> vorlon: IIRC we mostly tested the cloud images so far for fscaps
[16:40] <vorlon> stgraber: I've already checked, the image as imported does have the fscap in the squashfs
[16:41] <stgraber> ah, ok, so that's not the issue then
[16:41] <vorlon> but if I launch that image, the fscap is missing
[16:41] <stgraber> vorlon: what kernel is running on those systems?
[16:41] <vorlon> stgraber: 4.4.0-128-generic
[16:41] <vorlon> do we need bionic?
[16:42] <stgraber> vorlon: what binary have you been using for testing caps?
[16:42] <vorlon> stgraber: /bin/ping
[16:42] <stgraber> ok, so that looks good on the amd64 image, getcap shows the cap inside the container on my system
[16:42] <stgraber> let me test on armhf now
[16:43] <vorlon> stgraber: on xenial w/ lxd from backports?
[16:44] <stgraber> vorlon: and you said it's on btrfs I think, right?
[16:44] <vorlon> stgraber: /var/lib/lxd/storage-pools/default is btrfs yes
[16:45] <vorlon> and I confirmed that if I manually set the cap on the file in that tree, the fs does take it
[16:46] <stgraber> so that's running setcap from inside the container then?
[16:46] <vorlon> stgraber: I don't know that I tried that, I was trying from the host before. let me se
[16:47] <vorlon> # setcap cap_net_raw+ep /bin/ping
[16:47] <vorlon> Failed to set capabilities on file `/bin/ping' (Operation not permitted)
[16:47] <vorlon> The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
[16:47] <stgraber> ah, so that may be a kernel issue after all
[16:47] <stgraber> let me track exactly when fscapsv3 landed
[16:47] <vorlon> ok
[16:47] <vorlon> meanwhile, how about if I just try rebooting to the latest kernel ;P
[16:48] <infinity> vorlon: Are those trusty or xenial hosts?
[16:48] <vorlon> infinity: xenial
[16:48] <infinity> vorlon: If xenial, maybe running the bionic HWE kernel would be a solid plan.
[16:48] <stgraber> yeah, 4.15 has it for sure, so that's an option but I thought we had this backported
[16:48] <stgraber> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778286
[16:48] <ubot5> Ubuntu bug 1778286 in linux (Ubuntu Xenial) "Backport namespaced fscaps to xenial 4.4" [Medium,Fix released]
[16:49] <stgraber> ah, you're on -128, this says -134 has it
[16:49] <vorlon> ok
[16:49] <infinity> Ahh, maybe it's just an upgrade away then.  Nice.
[16:49] <vorlon> tada
[16:49] <stgraber> hopefully that's the only issue :)
[16:50] <vorlon> sorry, didn't realize this was a recently-landed bit on the kernel side
[16:50] <vorlon> I'll go through and reboot all the hosts
[16:50] <vorlon> (after checking that the fscap is preserved in a fresh launch)
[16:51] <stgraber> vorlon: /var/log/lxd/lxd.log should show a summary of kernel features on startup, including whether fscaps v3 are supported (I just checked that I backported that change to 3.0.3 too)
[16:52] <vorlon> stgraber: ack, thanks
[16:53] <vorlon> stgraber: so a fresh launch still doesn't have the fscap
[16:53] <infinity> Of course, all of this highlights a different bug, that autopkgtest (ch)roots are way too fat. :P
[16:53] <infinity> ping really shouldn't be there.
[16:53] <stgraber> vorlon: do you see fscaps support detected in /var/log/lxd/lxd.log?
[16:54] <stgraber> should look like:
[16:54] <stgraber> t=2018-12-28T10:36:22+0000 lvl=info msg=" - unprivileged file capabilities: yes"
[16:54] <vorlon> infinity: the autopkgtest fs is not stock; we can tune as appropriate
[16:54] <vorlon> stgraber: that line is there, yes
[16:54] <stgraber> vorlon: ok, did you do the full dance of removing the image with "lxc image delete", then creating a container again?
[16:54] <infinity> vorlon: Yeah, but I suspect we can't pare it down to essential-only, because it needs to be a live, bootable thing, unless we reengineer to run autopkgtest in a chroot on top of the booted root.
[16:54] <vorlon> stgraber: I did not, that's what I'm doing now
[16:57] <stgraber> vorlon: ok, so what should be an identical setup on x86 works here. kernel is 4.4.0-141-generic, storage pool is btrfs, lxd is 3.0.3 from backports and getcap looks happy
[16:57] <vorlon> stgraber: 'lxc image delete b6c9401e848a' which appears to be the current fingerprint of images:ubuntu/disco/armhf; lxc launch ; getcap still returns empty
[17:01] <stgraber> vorlon: how do I get to the system you're on? I'm on wendigo as prod-ues-proposed-migration but can't remember what juju magic to do from there
[17:02] <vorlon> stgraber: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i .ssh/scalingstack-bos02-id_rsa ubuntu@10.44.41.11
[17:04] <stgraber> ah, that one is on dir backend
[17:05] <stgraber> trying on btrfs quickly to see if that somehow makes a difference
[17:05] <stgraber> nope, no difference
[17:09] <stgraber> ah, out of date squashfs-tools maybe?
[17:10] <infinity> dist-upgrade instead of selective upgrades? :P
[17:10] <stgraber> ubuntu@lxd-armhf1:~$ lxc launch images:ubuntu/disco/armhf fscaps
[17:10] <stgraber> Creating fscaps
[17:10] <stgraber> Starting fscaps
[17:10] <stgraber> ubuntu@lxd-armhf1:~$ lxc exec fscaps -- getcap /bin/ping
[17:10] <stgraber> /bin/ping = cap_net_raw+ep
[17:10] <stgraber> ubuntu@lxd-armhf1:~$
[17:10] <stgraber> vorlon: ^ there you go
[17:10] <stgraber> all you needed is to apply package updates :)
[17:11] <stgraber> out of date kernel and out of date squashfs-tools caused the issue
[17:11] <stgraber> infinity: yeah, I'm not used to dealing with systems that don't have their package updates applied daily with unattended-upgrade, otherwise we'd have sorted this out much faster :)
[17:13] <vorlon> stgraber: ah oops
[17:13] <vorlon> stgraber: thanks, I'll get the others updated now
[17:13] <vorlon> but yeah, we're using the u-u defaults (security updates only)
[17:16] <infinity> That doesn't seem sane if we're using an lxd from backports.
[17:16] <infinity> Doesn't backports depend on updates?
[17:17] -queuebot:#ubuntu-release- New binary: libnfs [s390x] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:17] <infinity> It sure does.
[17:18] -queuebot:#ubuntu-release- New binary: libnfs [amd64] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:22] -queuebot:#ubuntu-release- New binary: libnfs [i386] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:23] -queuebot:#ubuntu-release- New binary: chaosread [amd64] (disco-proposed/universe) [1.1-1] (no packageset)
[17:23] -queuebot:#ubuntu-release- New binary: dh-vim-addon [amd64] (disco-proposed/universe) [0.1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: chaosread [i386] (disco-proposed/universe) [1.1-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: libnfs [ppc64el] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:25] -queuebot:#ubuntu-release- New binary: utox [amd64] (disco-proposed/universe) [0.17.0-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: chaosread [s390x] (disco-proposed/universe) [1.1-1] (no packageset)
[17:25] -queuebot:#ubuntu-release- New binary: python-shade [amd64] (disco-proposed/universe) [1.30.0-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: utox [i386] (disco-proposed/universe) [0.17.0-1] (no packageset)
[17:26] -queuebot:#ubuntu-release- New binary: utox [s390x] (disco-proposed/universe) [0.17.0-1] (no packageset)
[17:28] -queuebot:#ubuntu-release- New binary: chaosread [ppc64el] (disco-proposed/universe) [1.1-1] (no packageset)
[17:34] -queuebot:#ubuntu-release- Unapproved: rejected raspi3-firmware [source] (bionic-proposed) [1.20181112-1ubuntu0.18.04.1]
[17:34] -queuebot:#ubuntu-release- Unapproved: rejected raspi3-firmware [source] (cosmic-proposed) [1.20181112-1ubuntu0.18.10.1]
[17:34] -queuebot:#ubuntu-release- New binary: utox [ppc64el] (disco-proposed/universe) [0.17.0-1] (no packageset)
[17:44] <juliank> Laney: ok, we're down to the systemd "regression" on arm64 now, which is the usual "there's still a running service at the end" thing (in this case, it's the user-runtime-dir@119.service)
[17:47] <juliank> so, please force-skiptest gnutls28/3.6.5-2ubuntu1  # systemd has its common remaining service type of failure in boot smoke test
[17:50] <Laney> juliank: yep, k, hopefully one day that'll get fixed...
[17:51]  * juliank throws stuff at x n o x
[17:51] -queuebot:#ubuntu-release- New binary: libnfs [arm64] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:54] -queuebot:#ubuntu-release- New binary: libnfs [armhf] (disco-proposed/universe) [3.0.0-1] (kubuntu)
[17:54] <juliank> Oh, this should be unblocking apt too, gotta retry that later
[17:58] <acheronuk> could pyqt5 be skiptested please? this is another that is blocked by the apport fail which is not its fault, and is a partial blocker of the Qt transition
[17:58] <ahasenack> vorlon: will you also retry the armhf failed tests, or should each one take care of its own?
[18:19] -queuebot:#ubuntu-release- New binary: chaosread [arm64] (disco-proposed/universe) [1.1-1] (no packageset)
[18:19] -queuebot:#ubuntu-release- New binary: chaosread [armhf] (disco-proposed/universe) [1.1-1] (no packageset)
[18:25] -queuebot:#ubuntu-release- New binary: utox [arm64] (disco-proposed/universe) [0.17.0-1] (no packageset)
[18:41] <vorlon> ahasenack: I've retried the failed backuppc test twice now but don't see any results coming out; still looking
[18:42] <vorlon> infinity: "depend on updates" - well it doesn't have a versioned dep on squashfs-tools
[18:42] <ahasenack> vorlon: you mean, your retries are not showing up here? http://autopkgtest.ubuntu.com/packages/b/backuppc/disco/armhf
[18:42] <vorlon> ahasenack: exactly
[18:46] <ahasenack> vorlon: #is was sorting out through some bileto issues today, I don't know how much that is shared with autopkgtests
[18:47] <vorlon> not at all
[19:13] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (cosmic-proposed) [63ubuntu1.18.10.1]
[19:18] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.0.3-0ubuntu2]
[19:26] <infinity> vorlon: Sure, I didn't mean lxd had an explicit dep, I mean that backports builds against updates, so might depend on updates, so using backports and not updates isn't really a supported configuration.
[19:26] <vorlon> infinity: right, but partial upgrades *are* expected to work
[19:26] <vorlon> yes, dist-upgrading would've avoided this bug
[19:27] <infinity> vorlon: To be fair, the partial upgrade did work.  You just didn't get the new feature enabled.  Nothing old broke.
[19:27] <vorlon> anyway, I think I have succeeded in putting all the bits in place for a test to pass
[19:27] <vorlon> infinity: ok, that is fair :)
[19:28] -queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.7-0ubuntu2]
[19:28] <vorlon> all the bits> I mean, except for the 3 hosts that I've politely avoided rebooting while there are long-running tests in progress, and of course that's one of the hosts that picked up my latest retry
[19:28] -queuebot:#ubuntu-release- New binary: utox [armhf] (disco-proposed/universe) [0.17.0-1] (no packageset)
[19:35] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542.1]
[19:39] -queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (bionic-proposed) [1.1.3-5ubuntu0.2]
[19:41] <ahasenack> vorlon: :)
[20:00] <acheronuk> vorlon: could you skiptest pyqt5 please?
[20:09] <vorlon> ahasenack: http://autopkgtest.ubuntu.com/packages/b/backuppc/disco/armhf
[20:09] <vorlon> acheronuk: want to give me a rationale with that request? :)
[20:09] <ahasenack> vorlon: \o/
[20:11] <vorlon> acheronuk: ah, apport.  ok
[20:11] <acheronuk> vorlon: the failing test is apport, which is/was the valgrinf/usrmerge issue, and not anything to do with pyqt5
[20:11] <acheronuk> vorlon: yup
[20:11] <acheronuk> thanks
[20:11] <vorlon> acheronuk: done
[20:12] <acheronuk> vorlon: thank you. can see now what else may block Qt....
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (disco-proposed) [2.02+dfsg1-5ubuntu9]
[20:13] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (disco-proposed) [2.02+dfsg1-5ubuntu9]
[20:39] -queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (bionic-proposed) [1.52.5-0ubuntu18.04.1]
[20:41] <acheronuk> vorlon: looks like that finished oof the Qt transition :)
[20:41] <acheronuk> *off
[20:44] -queuebot:#ubuntu-release- Unapproved: accepted gparted [source] (bionic-proposed) [0.30.0-3ubuntu2]
[20:48] <mitya57> \o/ \o/ Thanks acheronuk and vorlon for helping with it!
[20:53] <teward> bdmurray: thanks for accepting gparted into proposed, once it's up I can do some testing, I'm sure if I ask psusi to take a look too that might not hurt, since they're designated maintainer it seems.
[21:15] <vorlon> acheronuk: spiff