| -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 | |
| bluesabre | vorlon: xubuntu-devel@lists.ubuntu.com should suffice | 01:38 |
|---|---|---|
| vorlon | bluesabre: done, thanks | 01:41 |
| 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 | 01:49 |
| jbicha | I'm surprised you didn't go ahead and remove rarian too! thanks though :) | 03:00 |
| rbalint | hi, i'd like to start the transition of libnfs in Debian and in Ubuntu if no-one opposes | 05:37 |
| rbalint | it is a small one https://release.debian.org/transitions/html/auto-libnfs.html | 05: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 | |
| LocutusOfBorg | jbicha, I had to merge php-defaults | 08:20 |
| LocutusOfBorg | because due to version constraints, stuff like e.g. php-apcu was not installable | 08:21 |
| LocutusOfBorg | or php-memcached | 08:21 |
| -queuebot:#ubuntu-release- New: accepted linux-signed-oem [amd64] (bionic-proposed) [4.15.0-1031.36] | 08:29 | |
| 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:41 |
| * juliank is trying to get gnutls28 migrated | 09:42 | |
| Laney | juliank: don't know, maybe talk to Robie/server team about that? | 09:43 |
| Laney | I was/am hoping to poke upstream into fixing it or at least giving me enough information on how to | 09:44 |
| 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:45 |
| 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:51 |
| juliank | rbasak: We could revert that temporarily to unblock things while getting a proper fix | 09:52 |
| juliank | this restores a problem with RAs not being sent, but should not cause any regressions compared to stable releases | 09:53 |
| Laney | or you can do something hacky like add a static bool to only do that codepath one time | 09:56 |
| * rbasak looks | 09:57 | |
| juliank | Laney: static seems wrong though, because this is supposed to run once per interface | 09:58 |
| Laney | indeed | 09:58 |
| Laney | the proposal I suggest upstream checked a field in the struct | 09:59 |
| Laney | 🤷 | 09:59 |
| rbasak | I agree that reverting seems unlikely to cause any regressions from our perspective. But what happens if an upstream fix never arrives? | 10:01 |
| 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:02 |
| 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:03 |
| Laney | that person said it randomly went away for them, but ... | 10:04 |
| juliank | dnsmasq code is terrible | 10:14 |
| juliank | I feel like there is definitely a bug in there | 10:26 |
| juliank | Laney: I wonder what happens if we insert a break at the end of the if in the upstream patch. | 10:31 |
| 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:32 |
| Laney | that's where I've been doing it | 10:33 |
| Laney | download a deb into temp/ and find my command in history | 10:34 |
| juliank | Laney: um, what was the hostname again? Seems I forgot it | 10:37 |
| juliank | and my bash_history forgot it too | 10:37 |
| Laney | wendigo | 10:41 |
| juliank | thanks | 10:43 |
| juliank | oh nice, it's a 1.0 package, not a 3.0 quilt | 10:45 |
| juliank | and no patch queue either | 10:45 |
| 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:47 |
| 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 | 10:48 |
| 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:12 |
| 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: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 | |
| LocutusOfBorg | juliank, https://github.com/mysql/mysql-server/tree/5.7 ? | 11:21 |
| juliank | LocutusOfBorg: Well, that does not contain this year's commits | 11:22 |
| 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:23 |
| rbasak | juliank: 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 | |
| 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:43 |
| -queuebot:#ubuntu-release- New binary: botan [armhf] (disco-proposed/universe) [2.8.0-3] (no packageset) | 11:44 | |
| * LocutusOfBorg retries some armhf tests | 11:45 | |
| 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:58 |
| Laney | vorlon was looking into that | 11:59 |
| LocutusOfBorg | ahasenack, iputils is to blame | 12:01 |
| ahasenack | LocutusOfBorg: how so? | 12:02 |
| 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:03 |
| 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:04 | |
| ahasenack | you mean when the image is generated with that iputils? | 12:05 |
| LocutusOfBorg | yep | 12:05 |
| LocutusOfBorg | so we need probably a new lxc on the infra, or something like that, and vorlon is having a look iirc | 12:06 |
| ahasenack | ok, thanks | 12: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 | |
| 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:17 |
| juliank | and network-manager still hits the dnsmasq bug (which is in release), but only on ppc64el | 15:18 |
| 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:19 |
| 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:21 |
| juliank | Laney: I think we should skiptest with both, and keep dnsmasq as-is for now | 15:22 |
| Laney | why's that then? | 15:22 |
| juliank | I'm starting to lose track of the uploads | 15:23 |
| 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:24 |
| juliank | Releasing gnutls28 first, we simply get a lot more working autopkgtests | 15: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 | |
| 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: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 now | 15:29 | |
| juliank | I'll do dnsmasq now :) | 15:30 |
| juliank | in any case, gnutls 3.6.5 is a quite some annoyance | 15:31 |
| juliank | I missed that they bumped up shlibs deps for all symbols to 3.6.5 when I uploaded it | 15:39 |
| juliank | there are nicer ways to handle adding new members to enums | 15:40 |
| juliank | no actually not | 15:41 |
| juliank | Laney: FWIW, my idea for dnsmasq did not help | 15:45 |
| juliank | I hope upstream figures out the issue | 15:45 |
| Laney | indeed | 15:46 |
| Laney | presumably if it's a real problem other people will start to report it | 15:46 |
| -queuebot:#ubuntu-release- Unapproved: accepted network-manager-applet [source] (bionic-proposed) [1.8.10-2ubuntu2] | 15:57 | |
| jamespage | bdmurray: ta :-) | 16:17 |
| bdmurray | jamespage: no problem, sorry for any delay | 16:20 |
| jamespage | bdmurray: no worries it was a odd one | 16:20 |
| -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (cosmic-proposed) [1:18.10.11.3] | 16:29 | |
| 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:31 |
| stgraber | vorlon: what image is used for this exactly? | 16:33 |
| juliank | Laney: Just retriggered nm with gnutls28,dnsmasq,nm; hopefully this passes | 16:35 |
| 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:36 |
| 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:37 |
| 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:40 |
| 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:41 |
| 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:42 |
| vorlon | stgraber: on xenial w/ lxd from backports? | 16:43 |
| 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:44 |
| vorlon | and I confirmed that if I manually set the cap on the file in that tree, the fs does take it | 16:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| vorlon | stgraber: ack, thanks | 16:52 |
| 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:53 |
| 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:54 |
| 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 | 16:57 |
| 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:01 |
| vorlon | stgraber: ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i .ssh/scalingstack-bos02-id_rsa ubuntu@10.44.41.11 | 17:02 |
| stgraber | ah, that one is on dir backend | 17:04 |
| stgraber | trying on btrfs quickly to see if that somehow makes a difference | 17:05 |
| stgraber | nope, no difference | 17:05 |
| stgraber | ah, out of date squashfs-tools maybe? | 17:09 |
| 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:10 |
| 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:11 |
| 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:13 |
| infinity | That doesn't seem sane if we're using an lxd from backports. | 17:16 |
| infinity | Doesn't backports depend on updates? | 17:16 |
| -queuebot:#ubuntu-release- New binary: libnfs [s390x] (disco-proposed/universe) [3.0.0-1] (kubuntu) | 17:17 | |
| infinity | It 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 | |
| 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:44 |
| juliank | so, please force-skiptest gnutls28/3.6.5-2ubuntu1 # systemd has its common remaining service type of failure in boot smoke test | 17:47 |
| Laney | juliank: yep, k, hopefully one day that'll get fixed... | 17:50 |
| * 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:51 | |
| -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:54 |
| 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? | 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 | |
| vorlon | ahasenack: I've retried the failed backuppc test twice now but don't see any results coming out; still looking | 18:41 |
| 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:42 |
| ahasenack | vorlon: #is was sorting out through some bileto issues today, I don't know how much that is shared with autopkgtests | 18:46 |
| vorlon | not at all | 18: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 | |
| 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:26 |
| 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:27 |
| -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: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 | |
| ahasenack | vorlon: :) | 19:41 |
| acheronuk | vorlon: could you skiptest pyqt5 please? | 20:00 |
| 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:09 |
| 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:11 |
| acheronuk | vorlon: 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 | |
| acheronuk | vorlon: looks like that finished oof the Qt transition :) | 20:41 |
| acheronuk | *off | 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 |
| 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. | 20:53 |
| vorlon | acheronuk: spiff | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!