[02:18] <RAOF> Grargh. How is libxml++ not already in main 👿
[04:25] <robert_ancell> RAOF, did you complete LP: #1837700 or did it get automatically completed by the security upload?
[04:25] <ubottu> Launchpad bug 1837700 in HWE Next "Dell system takes a long time to connect network with external dock" [Undecided,New] https://launchpad.net/bugs/1837700
[04:27] <RAOF> robert_ancell that SRU for released, yes.
[04:27] <RAOF> Then the security upload went Bachelor immediately afterwards
[04:28] <robert_ancell> RAOF, did anyone check the autopkgtest failures?
[04:29] <RAOF> Yes. I resolved them all.
[04:29] <robert_ancell> OK, good :)
[04:29] <RAOF> (mostly by hitting the retry button until they passed, a couple by badtest-ing gvfs 😛)
[04:30] <robert_ancell> Shame there wasn't a test for the regression :/
[04:30] <RAOF> Indeed
[04:30] <RAOF> That said, we knew that regression was possible.
[04:31] <RAOF> We just didn't think anyone would hit it.
[04:31] <robert_ancell> ah
[04:31] <robert_ancell> RAOF, you might know this - chrisccoulson said the fix should be uploaded via the security pocket in LP: #1842651
[04:31] <ubottu> Launchpad bug 1842651 in systemd (Ubuntu) "Regression: after Uprade from udev_237-3ubuntu10.25 to udev_237-3ubuntu10.26 network interfaces don't get renamed by 70-persistent-network.rules" [Critical,In progress] https://launchpad.net/bugs/1842651
[04:32] <robert_ancell> Is that just a matter of updating debian/changelog?
[04:32] <RAOF> (because that mechanism had been deprecated since 2015(?) and we'd had automatic migration off it for a while)
[04:34] <RAOF> I'm not sure. I *think* it is just a matter of updating the changelog, though.
[04:34] <RAOF> I don't know if security goes through a private -proposed equivalent?
[04:36] <robert_ancell> I always thought it did the old thing, i.e. straight to users.
[04:36] <robert_ancell> That's a job for Monday I think.
[04:37] <robert_ancell> Oh, I think I understand why Chris said it should go though security - it means everyone got that update, regardless of it they have updates enabled. So you want the fix to go through the same priority.
[04:38] <robert_ancell> Though if only a minority of users are hitting it, they'll probably be happy to update for the fix.
[04:39] <robert_ancell> Using debs feels so clumsy after using Snaps for managing things like this.
[07:00] <cpaelzer> jamespage: the dpdk fix for 1841759 is in Debian and synced to Ubuntu now
[07:01] <cpaelzer> jamespage: it is still building, but later today you should be able to push the OVS upload you were preparing
[07:01] <cpaelzer> https://launchpad.net/ubuntu/+source/dpdk/18.11.2-4
[07:02] <chrisccoulson> ah, I missed robert_ancell
[08:28] <doko> jamespage, cpaelzer: swift wants to promote again. is this expected?
[08:29] <jamespage> doko: yes xnox re-seeded it as we've switch to py3
[08:30] <doko> jamespage: do all packages still have bug subscribers?
[08:32] <doko> apparently yes, promoting
[08:33] <jamespage> it was only unseeded
[08:33] <jamespage> we never intended not to support it :)
[09:57] <cpaelzer> jamespage: fully arrived in proposed, you can build OVS if you want
[09:58] <jamespage> cpaelzer: already uploaded with a versioned BD
[10:08] <cpaelzer> ok, great
[10:26] <doko> jamespage, cpaelzer: https://launchpad.net/ubuntu/+source/liberasurecode/1.6.1-2/+build/17285632
[11:03] <rbasak> Are there any good examples of conditionally applying quilt patches at build time based on a build time check in debian/rules?
[11:03] <rbasak> For mysql-workbench Debian are adding a bunch of patches for MariaDB and they break the build with MySQL.
[11:03] <rbasak> So I'd like for us to send up to Debian a patch that checks and only applies the patches when building against MariaDB.
=== ricab is now known as ricab|lunch
[12:34] <doko> xnox, Laney: deja-dup now depends on duplicity, but this one ftbfs on ppc64el now
[12:34] <xnox> doko:  yes.... i did notice this on #ubuntu-desktop.
[12:36] <xnox> doko:  imho, whilst upstream is trying to fix this, it is best to remove duplicity on ppc64le from the release pocket
[12:36] <xnox> (there are two bugs open about test suite regressions on ppc64le)
[12:37] <xnox> doko:  and deja-dup on ppc64le probably too.... as otherwise it will be uninstallable.
[12:38] <xnox> would need ubuntu-mate-desktop refresh too.
=== ricab|lunch is now known as ricab
[14:21] <ddstreet> juliank cjwatson if you have time to peek at my patch to dpkg here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939516  it's not in debian yet, but I'd like to push it into eoan and sru for the dpkg zstd regression (lp #1842947)
[14:21] <ubottu> Debian bug 939516 in dpkg "dpkg: debian/rules 'configure' rule does not always recreate configure file" [Normal,Open]
[14:21] <ubottu> Launchpad bug 1842947 in dpkg (Ubuntu Eoan) "dpkg 1.19.0.5ubuntu2.2 build did not recreate 'configure' file, losing changes in 'configure.ac'" [Medium,In progress] https://launchpad.net/bugs/1842947
[14:22] <ddstreet> but i'd prefer not to push to eoan before debian accepts it, without agreement it makes sense to do so
[14:22] <juliank> ddstreet: looks ok
[14:24] <juliank> ddstreet: I'm not sure it's what guillem wants for upstream, but um, I guess you'll see eventually
[14:25] <ddstreet> lol yes :)  i'll defintely watch the debian bug in case he prefers something different
[14:25] <ddstreet> thanks!
[14:30] <cjwatson> looks OK
[15:34] <doko> xnox: duplicity still depends on python-lockfile
[15:37] <doko> RikMills: any idea about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/p/plasma-framework/20190906_060041_bb836@/log.gz ?
[15:41] <doko> tjaalton: could you have a look at https://launchpadlibrarian.net/440414264/buildlog_ubuntu-eoan-armhf.xosview_1.21-1build1_BUILDING.txt.gz ? same issue like the xserver ftbfs
[15:43] <doko> same with xserver-xorg-input-mouse xserver-xorg-input-keyboard
[15:44] <RikMills> doko: the history shows me identical fails followed by passes on a retry on the same trigger, so looks like that test has become 'flaky'
[15:58] <tjaalton> doko: yeah, next week
[16:30] <xnox> doko:  argh! will check/fix, but not today.
[18:09] <rcj> vorlon: I see you're on the SRU rotation for today.  Could you look at the SRU exception @ https://wiki.ubuntu.com/ec2-hibinit-agent-Updates
[19:06] <vorlon> rcj: that's not fair, you didn't highlight the SRU vanguard the other day when you asked for this and I ignored it hoping someone else would take it! :)
[19:07] <vorlon> (or maybe you did, looking at the logs... but anyway :)
[19:08] <vorlon> fwiw I wouldn't have considered review of a proposed SRU exception to be a vanguard task as these typically will want a single member of the SRU team taking it up and driving it, and it is likely to be a multi-day thing
[19:08] <vorlon> but ok, I'll have a look
[19:10] <rcj> vorlon: I can take it to an SRU team member early next week.  Someone may have erroneously pointed me at vanguard for this task.
[19:13] <rcj> vorlon: and this one I sent to the mailing list but didn't hear anything.  What I asked for on IRC was uploads for the livecd-rootfs SRU, which I now have someone in mind to ask.
[19:58] <vorlon> rcj: could you add an "SRU template" à la https://wiki.ubuntu.com/walinuxagentUpdates to https://wiki.ubuntu.com/ec2-hibinit-agent-Updates ?
[20:01] <rcj> vorlon: Sure, I can do that.  I happened to copy from one that didn't have that.  I'll name and shame https://wiki.ubuntu.com/gce-compute-image-packages-Updates to ask if that needs an update as well.
[20:02] <rcj> ;)
[20:02] <vorlon> I'm not in a hurry to go back and update older exceptions
[20:03] <rcj> okay, just figured I'd mention it because it's a package I know well.
[20:09] <rcj> vorlon: I've updated https://wiki.ubuntu.com/ec2-hibinit-agent-Updates with the SRU template
[20:11] <vorlon> rcj: thanks, approved & added to https://wiki.ubuntu.com/StableReleaseUpdates
[20:12] <rcj> vorlon: thank you for the review
[20:12] <rcj> vorlon: the link on the page is a bit wonky
[20:12] <rcj> mind if I fix it?
[20:13] <rcj> nm, fixed it.
[20:26] <vorlon> rcj: ack