-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-5ubuntu9 => 2.02+dfsg1-5ubuntu9] (core)00:19
-queuebot:#ubuntu-release- Unapproved: grub2 (disco-proposed/main) [2.02+dfsg1-5ubuntu9 => 2.02+dfsg1-5ubuntu9] (core)01:04
bluesabrevorlon: xubuntu-devel@lists.ubuntu.com should suffice01:38
vorlonbluesabre: done, thanks01:41
vorlonjbicha: I think you missed subscribing ubuntu-archive to LP: #180269701:49
ubot5Launchpad bug 1802697 in rarian (Ubuntu) "Remove rarian from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/180269701:49
jbichaI'm surprised you didn't go ahead and remove rarian too! thanks though :)03:00
rbalinthi, i'd like to start the transition of libnfs in Debian and in Ubuntu if no-one opposes05:37
rbalintit is a small one https://release.debian.org/transitions/html/auto-libnfs.html05:38
-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]05:59
LocutusOfBorgjbicha, I had to merge php-defaults08:20
LocutusOfBorgbecause due to version constraints, stuff like e.g. php-apcu was not installable08:21
LocutusOfBorgor php-memcached08:21
-queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1031.36]08:29
juliankLaney: Looking at the networkmanager/dnsmasq mess, should we just revert the upstream commit in dnsmasq that broke things?09:41
juliankwould at least get stuff unblocked a bit09:41
* juliank is trying to get gnutls28 migrated09:42
Laneyjuliank: don't know, maybe talk to Robie/server team about that?09:43
LaneyI was/am hoping to poke upstream into fixing it or at least giving me enough information on how to09:44
Laneybut I'm a clueless person really, if someone with more clue doesn't mind doing that to unblock the situation then cool by me09:45
juliankrbasak: ^ 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=e27825b0ef1e79ab05b1752c8c838cb43ad39d7909:51
juliankrbasak: We could revert that temporarily to unblock things while getting a proper fix09:52
juliankthis restores a problem with RAs not being sent, but should not cause any regressions compared to stable releases09:53
Laneyor you can do something hacky like add a static bool to only do that codepath one time09:56
* rbasak looks09:57
juliankLaney: static seems wrong though, because this is supposed to run once per interface09:58
Laneythe proposal I suggest upstream checked a field in the struct09:59
rbasakI agree that reverting seems unlikely to cause any regressions from our perspective. But what happens if an upstream fix never arrives?10:01
juliankthe 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
rbasakI'm not keen on having to maintain that patch then, as I guess no Ubuntu dev really understands it?10:02
rbasakFeels to me that there's some kind of latent state management bug upstream.10:02
rbasakDoes the regression being introduced actually cause a problem for us? Or just the dep8 failure?10:03
rbasakI'd prefer to skip/modify the test and not carry the patch if it actually won't be damanging to us.10:03
Laneysomeone else posted a thread on the upstream list about infinite RAs10:03
Laneythat person said it randomly went away for them, but ...10:04
juliankdnsmasq code is terrible10:14
juliankI feel like there is definitely a bug in there10:26
juliankLaney: I wonder what happens if we insert a break at the end of the if in the upstream patch.10:31
juliankCurrently, this is overriding _all_ non-template entries with a smaller prefix for the same subnet10:32
LaneyI'd advise you to take any suggestions to the mailing list10:32
juliankand then starts doing ra on them all10:32
juliankLaney: That's only reliable reproducble on the infra, right?10:32
Laneythat's where I've been doing it10:33
Laneydownload a deb into temp/ and find my command in history10:34
juliankLaney: um, what was the hostname again? Seems I forgot it10:37
juliankand my bash_history forgot it too10:37
juliankoh nice, it's a 1.0 package, not a 3.0 quilt10:45
juliankand no patch queue either10:45
Laneythe maintainer is the upstream developer, don't think it matters that much10:47
Laneyactually it made it nice and easy for me to test out changes :-)10:47
juliankwell, that explains a lot10:48
LocutusOfBorgdo we know that armhf autopkgtests are loosing work?10:48
LocutusOfBorge.g. autopkgtest for php-horde-listheaders/unknown: armhf: Regression ♻10:48
LocutusOfBorgoh... network issue10:48
juliankrbasak: 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... fun11:12
juliankThis should fix it: https://paste.ubuntu.com/p/HK3p28KNkz/11:12
juliankThis 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 patch11:13
-queuebot:#ubuntu-release- New binary: mando [amd64] (disco-proposed/universe) [0.6.4-4] (no packageset)11:14
-queuebot:#ubuntu-release- New binary: botan [s390x] (disco-proposed/universe) [2.8.0-3] (no packageset)11:19
-queuebot:#ubuntu-release- New binary: botan [ppc64el] (disco-proposed/universe) [2.8.0-3] (no packageset)11:20
LocutusOfBorgjuliank, https://github.com/mysql/mysql-server/tree/5.7 ?11:21
juliankLocutusOfBorg: Well, that does not contain this year's commits11:22
juliankI think they dump code after release?11:23
LocutusOfBorgoh... you are right... it was saying "updated 5 days ago", but probably that is the last pull/issue commented/opened11:23
rbasakjuliank: thanks!11:28
-queuebot:#ubuntu-release- New binary: botan [amd64] (disco-proposed/universe) [2.8.0-3] (no packageset)11:38
-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:41
juliankE: 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 (, connection timed out11:43
-queuebot:#ubuntu-release- New binary: botan [armhf] (disco-proposed/universe) [2.8.0-3] (no packageset)11:44
* LocutusOfBorg retries some armhf tests11:45
ahasenackI'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/ping11:58
ahasenackit's hard to get my hands on an armhf lxd11:58
Laneyvorlon was looking into that11:59
LocutusOfBorgahasenack, iputils is to blame12:01
ahasenackLocutusOfBorg: how so?12:02
LocutusOfBorgmeh, https://launchpad.net/ubuntu/+source/iputils/3:20180629-2ubuntu2 some fscap missing on lxd, so the bit are not set, something denies12:03
ahasenackI see12:03
ahasenack"everywhere including lxd"12:04
LocutusOfBorgI 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 set12:04
LocutusOfBorgso we got the issue once it migrated, because new installation of the tool fails12: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:04
ahasenackyou mean when the image is generated with that iputils?12:05
LocutusOfBorgso we need probably a new lxc on the infra, or something like that, and vorlon is having a look iirc12:06
ahasenackok, thanks12:09
=== shadeslayer is now known as shadeslayer[m]
=== shadeslayer[m] is now known as shadeslayer
-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:09
juliankThere are 3 regressions left for gnutls28; the gnupg2 one should be fixed by gnupg2 in proposed15:17
julianksystemd fails its boot smoke test on arm6415:17
juliankand network-manager still hits the dnsmasq bug (which is in release), but only on ppc64el15:18
juliankThe new gnutls28 is also causing a lot of unrelated test failures, because it's needed by new libraries in proposed but not pulled in correctly15:19
juliankSo, it seems the best thing to do is to move ahead here15:21
Laneywant to upload that dnsmasq revert?15:21
LaneyIf it comes down to the unrelated systemd thing we could go for a skiptest15:21
juliankLaney: I think we should skiptest with both, and keep dnsmasq as-is for now15:22
Laneywhy's that then?15:22
juliankI'm starting to lose track of the uploads15:23
juliankbut 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 gnutls2815:24
juliankwhich is what I'm hitting with gnupg2 right now15:24
juliankwhich I uploaded for gnutls28 :)15:24
juliankReleasing gnutls28 first, we simply get a lot more working autopkgtests15:25
-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
LaneyWe can retry n-m with gnutls28/dnsmasq/nm and then when it goes green, add the skiptest and then retry everything else after gnutls28 migrates15:27
-queuebot:#ubuntu-release- Unapproved: accepted adobe-flashplugin [source] (trusty-proposed) [1:20190108.1-0ubuntu0.14.04.1]15:28
* Laney has done similar with gnupg2 triggered by gnutls28 just now15:29
juliankI'll do dnsmasq now :)15:30
juliankin any case, gnutls 3.6.5 is a quite some annoyance15:31
juliankI missed that they bumped up shlibs deps for all symbols to 3.6.5 when I uploaded it15:39
juliankthere are nicer ways to handle adding new members to enums15:40
juliankno actually not15:41
juliankLaney: FWIW, my idea for dnsmasq did not help15:45
juliankI hope upstream figures out the issue15:45
Laneypresumably if it's a real problem other people will start to report it15:46
-queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (bionic-proposed) [1.8.10-2ubuntu2]15:57
jamespagebdmurray: ta :-)16:17
bdmurrayjamespage: no problem, sorry for any delay16:20
jamespagebdmurray: no worries it was a odd one16:20
-queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:]16:29
vorlonLocutusOfBorg, 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:31
stgrabervorlon: what image is used for this exactly?16:33
juliankLaney: Just retriggered nm with gnutls28,dnsmasq,nm; hopefully this passes16:35
juliankWell, 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
vorlonstgraber: images:ubuntu/$series/armhf16:36
juliankoh well, should have added wpa to the list of triggers16:37
cyphermoxcould someone please review grub2 amd64/arm64 binaries in the unapproved queue for disco?16:37
stgrabervorlon: ok, let me check that one, maybe there's something wrong in our build process that'd explain this16:40
stgrabervorlon: IIRC we mostly tested the cloud images so far for fscaps16:40
vorlonstgraber: I've already checked, the image as imported does have the fscap in the squashfs16:40
stgraberah, ok, so that's not the issue then16:41
vorlonbut if I launch that image, the fscap is missing16:41
stgrabervorlon: what kernel is running on those systems?16:41
vorlonstgraber: 4.4.0-128-generic16:41
vorlondo we need bionic?16:41
stgrabervorlon: what binary have you been using for testing caps?16:42
vorlonstgraber: /bin/ping16:42
stgraberok, so that looks good on the amd64 image, getcap shows the cap inside the container on my system16:42
stgraberlet me test on armhf now16:42
vorlonstgraber: on xenial w/ lxd from backports?16:43
stgrabervorlon: and you said it's on btrfs I think, right?16:44
vorlonstgraber: /var/lib/lxd/storage-pools/default is btrfs yes16:44
vorlonand I confirmed that if I manually set the cap on the file in that tree, the fs does take it16:45
stgraberso that's running setcap from inside the container then?16:46
vorlonstgraber: I don't know that I tried that, I was trying from the host before. let me se16:46
vorlon# setcap cap_net_raw+ep /bin/ping16:47
vorlonFailed to set capabilities on file `/bin/ping' (Operation not permitted)16:47
vorlonThe value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file16:47
stgraberah, so that may be a kernel issue after all16:47
stgraberlet me track exactly when fscapsv3 landed16:47
vorlonmeanwhile, how about if I just try rebooting to the latest kernel ;P16:47
infinityvorlon: Are those trusty or xenial hosts?16:48
vorloninfinity: xenial16:48
infinityvorlon: If xenial, maybe running the bionic HWE kernel would be a solid plan.16:48
stgraberyeah, 4.15 has it for sure, so that's an option but I thought we had this backported16:48
ubot5Ubuntu bug 1778286 in linux (Ubuntu Xenial) "Backport namespaced fscaps to xenial 4.4" [Medium,Fix released]16:48
stgraberah, you're on -128, this says -134 has it16:49
infinityAhh, maybe it's just an upgrade away then.  Nice.16:49
stgraberhopefully that's the only issue :)16:49
vorlonsorry, didn't realize this was a recently-landed bit on the kernel side16:50
vorlonI'll go through and reboot all the hosts16:50
vorlon(after checking that the fscap is preserved in a fresh launch)16:50
stgrabervorlon: /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:51
vorlonstgraber: ack, thanks16:52
vorlonstgraber: so a fresh launch still doesn't have the fscap16:53
infinityOf course, all of this highlights a different bug, that autopkgtest (ch)roots are way too fat. :P16:53
infinityping really shouldn't be there.16:53
stgrabervorlon: do you see fscaps support detected in /var/log/lxd/lxd.log?16:53
stgrabershould look like:16:54
stgrabert=2018-12-28T10:36:22+0000 lvl=info msg=" - unprivileged file capabilities: yes"16:54
vorloninfinity: the autopkgtest fs is not stock; we can tune as appropriate16:54
vorlonstgraber: that line is there, yes16:54
stgrabervorlon: ok, did you do the full dance of removing the image with "lxc image delete", then creating a container again?16:54
infinityvorlon: 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
vorlonstgraber: I did not, that's what I'm doing now16:54
stgrabervorlon: 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 happy16:57
vorlonstgraber: 'lxc image delete b6c9401e848a' which appears to be the current fingerprint of images:ubuntu/disco/armhf; lxc launch ; getcap still returns empty16:57
stgrabervorlon: 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 there17:01
vorlonstgraber: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i .ssh/scalingstack-bos02-id_rsa ubuntu@
stgraberah, that one is on dir backend17:04
stgrabertrying on btrfs quickly to see if that somehow makes a difference17:05
stgrabernope, no difference17:05
stgraberah, out of date squashfs-tools maybe?17:09
infinitydist-upgrade instead of selective upgrades? :P17:10
stgraberubuntu@lxd-armhf1:~$ lxc launch images:ubuntu/disco/armhf fscaps17:10
stgraberCreating fscaps17:10
stgraberStarting fscaps17:10
stgraberubuntu@lxd-armhf1:~$ lxc exec fscaps -- getcap /bin/ping17:10
stgraber/bin/ping = cap_net_raw+ep17:10
stgrabervorlon: ^ there you go17:10
stgraberall you needed is to apply package updates :)17:10
stgraberout of date kernel and out of date squashfs-tools caused the issue17:11
stgraberinfinity: 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:11
vorlonstgraber: ah oops17:13
vorlonstgraber: thanks, I'll get the others updated now17:13
vorlonbut yeah, we're using the u-u defaults (security updates only)17:13
infinityThat doesn't seem sane if we're using an lxd from backports.17:16
infinityDoesn't backports depend on updates?17:16
-queuebot:#ubuntu-release- New binary: libnfs [s390x] (disco-proposed/universe) [3.0.0-1] (kubuntu)17:17
infinityIt sure does.17:17
-queuebot:#ubuntu-release- New binary: libnfs [amd64] (disco-proposed/universe) [3.0.0-1] (kubuntu)17:18
-queuebot:#ubuntu-release- New binary: libnfs [i386] (disco-proposed/universe) [3.0.0-1] (kubuntu)17:22
-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:23
-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:25
-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:26
-queuebot:#ubuntu-release- New binary: chaosread [ppc64el] (disco-proposed/universe) [1.1-1] (no packageset)17:28
-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:34
juliankLaney: 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:44
juliankso, please force-skiptest gnutls28/3.6.5-2ubuntu1  # systemd has its common remaining service type of failure in boot smoke test17:47
Laneyjuliank: yep, k, hopefully one day that'll get fixed...17:50
* juliank throws stuff at x n o x17:51
-queuebot:#ubuntu-release- New binary: libnfs [arm64] (disco-proposed/universe) [3.0.0-1] (kubuntu)17:51
-queuebot:#ubuntu-release- New binary: libnfs [armhf] (disco-proposed/universe) [3.0.0-1] (kubuntu)17:54
juliankOh, this should be unblocking apt too, gotta retry that later17:54
acheronukcould 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 transition17:58
ahasenackvorlon: will you also retry the armhf failed tests, or should each one take care of its own?17:58
-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:19
-queuebot:#ubuntu-release- New binary: utox [arm64] (disco-proposed/universe) [0.17.0-1] (no packageset)18:25
vorlonahasenack: I've retried the failed backuppc test twice now but don't see any results coming out; still looking18:41
vorloninfinity: "depend on updates" - well it doesn't have a versioned dep on squashfs-tools18:42
ahasenackvorlon: you mean, your retries are not showing up here? http://autopkgtest.ubuntu.com/packages/b/backuppc/disco/armhf18:42
vorlonahasenack: exactly18:42
ahasenackvorlon: #is was sorting out through some bileto issues today, I don't know how much that is shared with autopkgtests18:46
vorlonnot at all18:47
-queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-ubuntu-dock [source] (cosmic-proposed) [63ubuntu1.18.10.1]19:13
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (cosmic-proposed) [2:18.0.3-0ubuntu2]19:18
infinityvorlon: 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
vorloninfinity: right, but partial upgrades *are* expected to work19:26
vorlonyes, dist-upgrading would've avoided this bug19:26
infinityvorlon: To be fair, the partial upgrade did work.  You just didn't get the new feature enabled.  Nothing old broke.19:27
vorlonanyway, I think I have succeeded in putting all the bits in place for a test to pass19:27
vorloninfinity: ok, that is fair :)19:27
-queuebot:#ubuntu-release- Unapproved: accepted nova [source] (bionic-proposed) [2:17.0.7-0ubuntu2]19:28
vorlonall 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 retry19:28
-queuebot:#ubuntu-release- New binary: utox [armhf] (disco-proposed/universe) [0.17.0-1] (no packageset)19:28
-queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (cosmic-proposed) [2.542.1]19:35
-queuebot:#ubuntu-release- Unapproved: accepted alsa-lib [source] (bionic-proposed) [1.1.3-5ubuntu0.2]19:39
ahasenackvorlon: :)19:41
acheronukvorlon: could you skiptest pyqt5 please?20:00
vorlonahasenack: http://autopkgtest.ubuntu.com/packages/b/backuppc/disco/armhf20:09
vorlonacheronuk: want to give me a rationale with that request? :)20:09
ahasenackvorlon: \o/20:09
vorlonacheronuk: ah, apport.  ok20:11
acheronukvorlon: the failing test is apport, which is/was the valgrinf/usrmerge issue, and not anything to do with pyqt520:11
acheronukvorlon: yup20:11
vorlonacheronuk: done20:11
acheronukvorlon: thank you. can see now what else may block Qt....20:12
-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:13
-queuebot:#ubuntu-release- Unapproved: accepted gjs [source] (bionic-proposed) [1.52.5-0ubuntu18.04.1]20:39
acheronukvorlon: looks like that finished oof the Qt transition :)20:41
-queuebot:#ubuntu-release- Unapproved: accepted gparted [source] (bionic-proposed) [0.30.0-3ubuntu2]20:44
mitya57\o/ \o/ Thanks acheronuk and vorlon for helping with it!20:48
tewardbdmurray: 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.20:53
vorlonacheronuk: spiff21:15

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!