[01:53] <wxl> infinity, vorlon: any reason why lubuntu can't have usb-creator(-kde) in our packageset?
[02:02] <vorlon> wxl: implying that lubuntu devs would be able to upload usb-creator, a package for which the Lubuntu team are definitely not the current maintainers?
[02:03] <vorlon> LocutusOfBorg: reprotest/i386> yeah I was trying to figure out if that wasn't the result of a progression rather than a regression, but I see now that it isn't - hinting
[02:17] <teward> vorlon: can you hand-wave a no-change rebuild in the SRU queue?  Or should I wait for the rest of the SRU team to address it?
[04:08] <wxl> vorlon: we do use usb-creator-kde in our flavor. perhaps that's insufficient?
[04:55] <vorlon> wxl: and usb-creator-gtk is seeded in ubuntu-desktop, ubuntukylin-desktop, and ubuntu-mate-desktop.  So ubuntu-desktop looks like the correct packageset to me
[04:56] <vorlon> teward: I'm not in a position to do SRU reviews this evening, sorry
[04:56] -queuebot:#ubuntu-release- New: accepted pdal [arm64] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [armhf] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [amd64] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [armhf] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [ppc64el] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [amd64] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [ppc64el] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [arm64] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [s390x] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [s390x] (eoan-proposed) [1.9.1+ds-1]
[04:57] -queuebot:#ubuntu-release- New: accepted hypre [i386] (eoan-proposed) [2.16.0-2]
[04:57] -queuebot:#ubuntu-release- New: accepted pdal [i386] (eoan-proposed) [1.9.1+ds-1]
[06:14] -queuebot:#ubuntu-release- New binary: python-pdal [amd64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [i386] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [s390x] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:15] -queuebot:#ubuntu-release- New binary: python-pdal [ppc64el] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: python-pdal [arm64] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[06:16] -queuebot:#ubuntu-release- New binary: python-pdal [armhf] (eoan-proposed/universe) [2.1.8+ds-2] (no packageset)
[07:45] -queuebot:#ubuntu-release- Unapproved: lasso (bionic-proposed/main) [2.5.1-0ubuntu1 => 2.5.1-0ubuntu1.1] (ubuntu-server)
[07:45] -queuebot:#ubuntu-release- Unapproved: lasso (disco-proposed/main) [2.6.0-2build1 => 2.6.0-2ubuntu0.1] (ubuntu-server)
[07:48] <sil2100> grrr, pending-sru page again is outdated, I'm running sru-report locally to determine if it's crashing or maybe it's just something with the runs on snakefruit
[07:49] <sil2100> Ok, it doesn't crash
[07:50] <sil2100> Laney, cjwatson: could one of you log into snakefruit and check what's up? The current report is "Generated: 2019-07-12 15:54:18 UTC"
[07:50] <sil2100> I was able to successfully run sru-report and get some meaningful output
[07:52] <RikMills> sil2100: morning. I need to do some more verification on the list of bugfixes, which I doubt I can finish today, but I assume it would be possible to get the Plasma SRU out later in the week?
[07:53] <RikMills> I would like it to have some time in release pocket before we cook the 18.04.3 isos!
[07:58] <sil2100> RikMills: sure, +1 on that - just give me a poke once you feel we're good to go
[07:59] <RikMills> thanks :)
[08:05] <Laney> sil2100: ok, done - that's the third time this has happened lately
[08:06] <Laney> dunno if you want to add some logging and find out where it's hanging, then make that part more resillient
[08:06] <sil2100> Laney: actually I saw compontent-mismatches outdated as well
[08:06] <sil2100> Like, the current component-mismatches is from 2019-07-12 20:30
[08:06] <sil2100> There's a .html.new from today, but it's like half-way generated?
[08:07] <sil2100> Weird things are happening lately
[08:08] <sil2100> Laney: anyway, thanks for running that, guess +1 on adding some logging - we never had frequent issues like that, so no one really needed any debugging
[08:09] <Laney> actually I found this from component-mismatches
[08:09] <Laney> https://paste.ubuntu.com/p/nhkGXGfcjk/
[08:24] <sil2100> huh
[08:39] <Laney> thanks freenode™
[08:40] <Laney> this person's display name is breaking it https://launchpad.net/~paelzer 😈
[08:42] <cjwatson> haha
[08:42] <cjwatson> hopefully not too hard to fix
[08:43] <apw> oh the circle of friends; heh
[08:48] <sil2100> cpaelzer: ^ hah, it's you who broke the component-mismatches report!
[08:48] <ogra> probably time to switch it to utf8 then ;(
[08:48] <ogra> err
[08:48] <ogra> ;)
[08:50] <cpaelzer> sil2100: yes apw found that
[08:50] <cpaelzer> but I have the UTF char so long that I wonder it broke now
[08:50] <cpaelzer> anyway thanks apw for fixing
[08:51]  * apw hands the bottle of thanks to Laney
=== pieq_ is now known as pieq
[08:58] <Laney> sil2100: something like lp:~laney/ubuntu-archive-tools/cm-utf8
[08:58] <Laney> there's probably a strictly more complete / correct way to do that
[08:59] <Laney> I can't commit to lp:ubuntu-archive-tools so please review and do it if you like it :-)
[09:00] <cjwatson> I have horrible things at the start of various scripts I've written that force stdout to be UTF-8
[09:01] <cjwatson> That sort of thing may do the job but note that I'm pretty certain it will break in Python 3
[09:02]  * cjwatson hunts
[09:02] <cjwatson> Laney: https://bazaar.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu/view/head:/build/util/help-to-gfxboot.py#L14 maybe?
[09:03] <Laney> cjwatson: yeah OK, this is probably better than leaving a time-bomb behind
[09:03] <Laney> thanks
[09:04] <cjwatson> (The Python 3 hack there shouldn't be necessary in practice as of 3.7, since it was really just to deal with LC_CTYPE=C and 3.7 coerces that to UTF-8, but it should also still be harmless on 3.7)
[09:07] <LocutusOfBorg> vorlon, hello, how do you feel about merging iptables from unstable=?
[09:15] <LocutusOfBorg> and please don't look at my squid upload, thanks (I'm deeply sorry for the quality of the upload, but I couldn't fix it)
[09:17] <LocutusOfBorg> (I can say, such bugs are already there, gcc-9 is just showing them)
[09:52]  * Laney pokes sil2100 
[09:56]  * LocutusOfBorg pockes somebody to accept python-pdal
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [amd64] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [armhf] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [ppc64el] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [arm64] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [s390x] (eoan-proposed) [2.1.8+ds-2]
[09:59] -queuebot:#ubuntu-release- New: accepted python-pdal [i386] (eoan-proposed) [2.1.8+ds-2]
[10:22] <sil2100> Laney: ugh! Looking ;)
[10:23] <sil2100> Ah, I see apw already merged it o/
[10:24] <Laney> yeah
[10:26] <LocutusOfBorg> thanks nftables for not failing locally, on pbuilder, on sbuild on debomatic and failing on ubuntu archive with no reason :(
[10:29] <sil2100> Laney: btw. do you know if sru-report is hung again on snakefruit?
[10:30] <Laney> sil2100: no, should run soon
[10:31] <sil2100> Ah, ok, I see the .new there indeed, thanks
[10:32] <Laney> yeah seems to be moving
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (bionic-proposed/main) [2.0.0-0ubuntu2~18.04.0 => 2.0.0-0ubuntu2~18.04.1] (no packageset)
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (xenial-proposed/main) [2.0.0-0ubuntu2~16.04.0 => 2.0.0-0ubuntu2~16.04.1] (no packageset)
[11:36] -queuebot:#ubuntu-release- Unapproved: wslu (disco-proposed/main) [2.0.0-0ubuntu2 => 2.0.0-0ubuntu2.19.04.0] (core)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [amd64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [ppc64el] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [i386] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:41] -queuebot:#ubuntu-release- New binary: nftables [s390x] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: nftables [arm64] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[11:43] -queuebot:#ubuntu-release- New binary: nftables [armhf] (eoan-proposed/universe) [0.9.1-2ubuntu2] (no packageset)
[12:48] <LocutusOfBorg> hello, please accept nftables, I plan to transition it...
[12:50] <teward> anyone on SRU today to handle the no change rebuild SRU for NGINX in the Bionic unapproved queue?  Just asking since theres TLS1.3 isms for managing TLS 1.3 proto and ciphers hat are ignored unless we build against 1.1.1 now in the repos there
[12:51] <apw> teward, can do
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [amd64] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [armhf] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [ppc64el] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [arm64] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] <teward> apw thank you kindly.
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [s390x] (eoan-proposed) [0.9.1-2ubuntu2]
[12:51] -queuebot:#ubuntu-release- New: accepted nftables [i386] (eoan-proposed) [0.9.1-2ubuntu2]
[12:55] <apw> teward, and those are correctly in -security ?  the openssl updates
[12:57] <apw> teward, or are we actually trying to have nginx in -security with different support to those in -updates
[12:57] <teward> apw: ask mdeslaur.  they never brought 1.1.1 into -security
[12:57] <teward> so the repos are TECHNICALLY in a diverged state
[12:57] <teward> and that was apparently Security's decision
[12:58] <mdeslaur> nono, we're still waiting for the last openssl SRU to go through before all the packages get copied to -security
[12:58] <teward> so that is out of my hands to answer
[12:58] <teward> so it sounds like the SRU queue needs more love and attention then?
[12:59] <apw> mdeslaur, so it is appropriate to have an nginx in -proposed built against 1.1.1 then, right ?
[12:59] <mdeslaur> not sure why 1832919 isn't being released for bionic
[12:59] <mdeslaur> apw: yes
[12:59] <mdeslaur> apw: we can rebuild it in -security if/when we want
[13:00] <apw> mdeslaur, i can see no reason it is not released and some time ago
[13:01] <apw> mdeslaur, oh because its not released in disco
[13:01] <mdeslaur> :(
[13:02] <apw> xnox, your openssl upload is all lagging in disco ... for lack of validation on some of the 'other' bugs
[13:05] -queuebot:#ubuntu-release- Unapproved: accepted nginx [source] (bionic-proposed) [1.14.0-0ubuntu1.3]
[13:05] <apw> teward, anyhow ^ seems appropriate in the new world order, even if we cannot release it
[13:05] <apw> (though i believe we can to -updates only)
[13:08] <teward> apw: ack.
[13:11] -queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (disco-proposed) [2.10.0-1~19.04]
[13:11] -queuebot:#ubuntu-release- New binary: linux-signed-oem-osp1 [amd64] (bionic-proposed/universe) [5.0.0-1014.15] (no packageset)
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted dkms [source] (disco-proposed) [2.6.1-4ubuntu2.2]
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted iproute2 [source] (disco-proposed) [4.18.0-1ubuntu2.1]
[13:41] -queuebot:#ubuntu-release- Unapproved: accepted creduce [source] (bionic-proposed) [2.10.0-1~18.04]
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (bionic-proposed/main) [1.4~ubuntu0.18.04.1 => 1.5~ubuntu0.18.04.1] (core)
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (xenial-proposed/main) [1.4~ubuntu0.16.04.1 => 1.5~ubuntu0.16.04.1] (core)
[13:47] -queuebot:#ubuntu-release- Unapproved: secureboot-db (disco-proposed/main) [1.4 => 1.5~ubuntu0.19.04.1] (core)
[13:49] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (disco-proposed) [2.0.0-0ubuntu2.19.04.0]
[13:53] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (bionic-proposed) [2.0.0-0ubuntu2~18.04.1]
[14:06] <xnox> apw:  right, let me verify all the things then.
[14:18] <coreycb> sil2100: hello, if you have any cycles for your SRU rota today we have cinder and designate in the bionic unapproved queue that fix ftbfs in bionic-proposed. i've also synced with folks since to make sure we're on the same page with ensuring packages build successfully before hand.
[14:22] -queuebot:#ubuntu-release- Unapproved: accepted wslu [source] (xenial-proposed) [2.0.0-0ubuntu2~16.04.1]
[14:56] <sil2100> coreycb: ok o/
[15:10] -queuebot:#ubuntu-release- Unapproved: accepted cinder [source] (bionic-proposed) [2:12.0.7-0ubuntu2]
[15:22] -queuebot:#ubuntu-release- Unapproved: accepted designate [source] (bionic-proposed) [1:6.0.1-0ubuntu1.2]
[15:24] -queuebot:#ubuntu-release- Unapproved: cargo (disco-proposed/universe) [0.35.0-0ubuntu1~19.04.1 => 0.36.0-0ubuntu1~19.04.1] (no packageset) (sync)
[15:25] -queuebot:#ubuntu-release- Unapproved: rustc (disco-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~19.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: cargo (bionic-proposed/universe) [0.35.0-0ubuntu1~18.04.1 => 0.36.0-0ubuntu1~18.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: rustc (bionic-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~18.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1] (no packageset) (sync)
[15:26] -queuebot:#ubuntu-release- Unapproved: cargo (xenial-proposed/universe) [0.35.0-0ubuntu1~16.04.1 => 0.36.0-0ubuntu1~16.04.1] (no packageset) (sync)
[15:27] -queuebot:#ubuntu-release- Unapproved: rustc (xenial-proposed/universe) [1.34.1+dfsg2+llvm-0ubuntu1~16.04.1 => 1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1] (no packageset) (sync)
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (bionic-proposed) [0.36.0-0ubuntu1~18.04.1]
[15:29] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (bionic-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~18.04.1]
[15:32] -queuebot:#ubuntu-release- New: accepted linux-signed-oem-osp1 [amd64] (bionic-proposed) [5.0.0-1014.15]
[15:37] <coreycb> sil2100: thanks!
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (disco-proposed) [0.36.0-0ubuntu1~19.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted cargo [sync] (xenial-proposed) [0.36.0-0ubuntu1~16.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (disco-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~19.04.1]
[15:41] -queuebot:#ubuntu-release- Unapproved: accepted rustc [sync] (xenial-proposed) [1.35.0+dfsg0.1+llvm-0ubuntu1~16.04.1]
[15:47] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (disco-proposed) [13.2.6-0ubuntu0.19.04.2]
[15:56] <xnox> apw:  about eoan - 5.2.0-8.9 looks all green on autopkgtests (retried a few things in the morning) is it good to unblock, or not yet?
[15:57] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (bionic-proposed) [12.2.12-0ubuntu0.18.04.1]
[16:04] <apw> xnox, do i have it blocked ?
[16:04] <apw> xnox, i thought sforshee had a couple of test failures; perhaps not
[16:04] <apw> xnox, or is it blocked on the bug ...
[16:10] <sforshee> apw, xnox: yes blocked on the bug
[16:11] <sforshee> trying to confirm that a network-manager test regression is not a kernel regression
[16:13] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (disco-proposed) [1.5~ubuntu0.19.04.1]
[16:13] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (bionic-proposed) [1.5~ubuntu0.18.04.1]
[16:14] <Laney> the network-manager tests are in a fairly bad state atm unfortunately
[16:14] -queuebot:#ubuntu-release- Unapproved: rejected secureboot-db [source] (xenial-proposed) [1.5~ubuntu0.16.04.1]
[16:14] <Laney> Till's been working on them
[16:15] <Laney> rcj: could you review https://code.launchpad.net/~mvo/livecd-rootfs/+git/livecd-rootfs/+merge/370065 again pls?
[16:16] <vorlon> Laney: do you also intend to cherry-pick https://code.launchpad.net/~tobijk/livecd-rootfs/+git/livecd-rootfs/+merge/370096 to bionic or do you need tobikoch to submit a second MP?
[16:16] <sforshee> Laney: I assume part of that is because it tries to build modules and the -fcf-protection thing is breaking that
[16:17] <vorlon> if that were so, the tests should be passing w/ linux 5.2 in -proposed
[16:17] <sforshee> right, there are some IPv6 address assignment tests failing with 5.2 that look to be new failures
[16:17] <Laney> sforshee: They're broken independent of that
[16:18] <sforshee> although my laptop is getting an IPv6 address just fine
[16:18] <Laney> I suppose you could run what you've seen past Till and he might be able to tell you if it's new or not
[16:18] <vorlon> anyway, 'AssertionError: 0 not greater than or equal to 2 : []' doesn't point to a kernel module issue ;)
[16:19] <Laney> vorlon: I can do, once these changes are validated in eoan
[16:19] <Laney> would be helpful if the bug(s) were proactively SRUified if they aren't already
[16:20] <vorlon> Laney: validated in eoan> since there seems to be a fair bit of urgency around this, I'd suggest not waiting for such verification before SRUing but doing it in parallel
[16:20] <vorlon> tobikoch: ^^ could you fix up the bug report to add the appropriate SRU template?
[16:20] <Laney> vorlon: well I'm not going to be able to get to it before finishing today, was planning to see tomorrow's ISOs and then backport
[16:20] <vorlon> ok :)
[16:21] <Laney> feel free to take over though if you'd like
[16:21] <vorlon> probably ENOTIME for that, just trying to make sure no one is blocked :)
[16:21] <Laney> nod
[16:25] <sforshee> tkamppeter: so Laney says you've been working on broken network-manager tests, I'm seeing a couple of failures with the kernel in eoan-proposed and it would be helpful to know if those are known to be broken or racy
[16:25] <sforshee> the ones that are failing are:
[16:25] <sforshee> ethernet: manual connection, IPv6 with only RA, preferring public address
[16:25] <sforshee> ethernet: manual connection, IPv6 with only RA, preferring temp address
[16:28] <sforshee> oh and this one shows up in one of the logs too, but only once - ethernet: auto-connection, IPv6 with DHCP
[16:28] <sforshee> the others have appeared in multiple runs
[16:32] <tkamppeter> I was only aware of that some tests do not work.
[16:33] <tkamppeter> sforshee, for further development on the test script (better debuggability) I have repeatedly run some of the tests. There I have also observed that the  ethernet: manual connection, IPv6 with only RA, preferring public address sometimes fails.
[16:34] <tkamppeter> sforshee, the test system has kernel 5.0.0-20.
[16:34] <sforshee> tkamppeter: ok so that's something, though it has seemed to fail fairly consistently in adt with 5.2
[16:34] <sforshee> but maybe I'm just having bad luck
[16:35] <sforshee> it's only happened on amd64 and i386 though which is also odd
[16:36] <tkamppeter> sforshee, what is "adt"?
[16:37] <sforshee> tkamppeter: autopkgtest, I can't remember what that acronym was for (auto device test?) but I guess it is outdated
[16:38] <cjwatson> In the very early days it was autodebtest and the initialism persisted in command names for a while (partly because apt- wasn't a good prefix to use)
[16:38] <cjwatson> Now the commands are just autopkgtest or autopkgtest-* though)
[16:39] <sforshee> our kernel tooling still calls it adt, so that's what I tend to call it
[16:40] <Laney> rcj: (I think that it's not the place you indicated it should be put in)
[16:51] <tkamppeter> Is there any known bug in network support in kernel 5.2? Or a known change of how some of its networking functionality works?
[16:51] <Laney> (commented)
[16:52] <Laney> (re: livecd-rootfs; going to upload without mvo's change now)
[16:53] <teward> sil2100: autopkgtest fail due to internal test env networking issues is unrelated to NGINX SRU; retry queued
[16:53] <sforshee> tkamppeter: I'm not aware of any relevant networking bugs/changes from 5.2 right now, but every release has a lot of networking changes
[16:53] <teward> internal "unable to connect to ftpmaster" tends to be env related :P
[16:55] <sforshee> tkamppeter: I'm looking through the logs, it seems like the connection is getting activated so maybe it just isn't happening quickly enough
[16:56] <sforshee> the inconsistency of which tests fail in a given run also support that as a possibility
[16:57] <tkamppeter> sforshee, this is possible. for me it fails in the ethernet case (still with 5.0.x kernel) in the .add_and_activate_connection() step, this is also a reason why I continued improving the debuggability of the main loops.
[17:03] <tkamppeter> sforshee, generally, the failures I observe happens rather rarely, perhaps once in 10 runs, so a timout or race issue is possible, probably not a general incompatibility, but note that I am still on 5.0.0-20.
[17:04] <sforshee> tkamppeter: yeah the thing that worries me is that I can't get any run with no failures at all
[17:06] <tkamppeter> sforshee, does it fail always at the same place in the same way (=incompatibility of new kernel with current NM -> Need to contact NM upstream) or is the density of sporadic failures so high that the probability of all the tests passing is near zero?
[17:15] <sforshee> tkamppeter: it's that one or more of a small subset of tests fail every time, but which test varies from run to run
[17:20] <tkamppeter> sforshee, if each test passes at least sometimes we have most probably no incompatibility but more some slowing factor.
[17:20] <sforshee> yeah that's what I'm thinking
[17:32] <teward> sil2100: autopkgtest regression for bug #1836366 cleared - the regression was entirely local to the test env with networking, no actual regression observed.
[17:32] <ubot5> bug 1836366 in nginx (Ubuntu Bionic) "[SRU] No Changes Rebuild in Bionic for OpenSSL compat reasons" [Medium,Fix committed] https://launchpad.net/bugs/1836366
[19:20] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:21] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:23] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
[19:24] -queuebot:#ubuntu-release- Unapproved: fwupd (eoan-proposed/main) [1.2.10-1ubuntu1 => 1.2.10-1ubuntu1] (core)
=== msalvatore_ is now known as msalvatore
[21:16] -queuebot:#ubuntu-release- New binary: plymouth [amd64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:16] -queuebot:#ubuntu-release- New binary: plymouth [s390x] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:17] -queuebot:#ubuntu-release- New binary: plymouth [i386] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:17] -queuebot:#ubuntu-release- New binary: plymouth [ppc64el] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:21] -queuebot:#ubuntu-release- New binary: plymouth [armhf] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)
[21:26] -queuebot:#ubuntu-release- New binary: plymouth [arm64] (eoan-proposed/main) [0.9.4git20190712-0ubuntu1] (core)