[06:33] -queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.33-0ubuntu0.16.04.2 => 7.0.33-0ubuntu0.16.04.3] (kubuntu, ubuntu-desktop, ubuntu-server)
[08:39] -queuebot:#ubuntu-release- New binary: leaflet-markercluster [amd64] (disco-proposed/universe) [1.4.1~dfsg-6] (no packageset)
[08:59] <apw> anyone know anything about the set of android tools (android-platform-development) which have managed to get into cosmic-proposed with a lower version than cosmic-release ?
[08:59] <apw> likely binary copy forwards from bionic done in error ?
[09:17] <LocutusOfBorg> apw, I think this has been done by vorlon in effort to backport https://bugs.launchpad.net/ubuntu/+source/android-platform-libcore/+bug/1819448 to bionic (and also cosmic) to ensure smooth upgrades path?
[09:18] <LocutusOfBorg> but of course some of them already have higher version in release, so they should be just removed from the proposed pocket?
[09:18] <apw> yeah that is what my reports are telling me to do :)
[09:36] <LocutusOfBorg> hello, can anybody please update debci hint to 2.0 too?
[09:45] <LocutusOfBorg> please also hint octave-image/2.10.0-2 on ppc64el, regressed in release
[09:46] <LocutusOfBorg> (its already ignored on amd64 and i386, same OOM)
[09:46] <LocutusOfBorg> apw, ^^
[10:24] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.15 => 237-3ubuntu10.16] (core)
[10:39] -queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.1~14.04.6 => 4.3.40-dfsg-0ubuntu1.14.04.1~14.04.1] (no packageset)
[10:39] -queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu1.14.04.2 => 4.3.40-dfsg-0ubuntu14.04.1] (ubuntu-cloud)
[10:47] <LocutusOfBorg> can anybody please reject from trusty queue the below?
[10:47] <LocutusOfBorg>  	
[10:47] <LocutusOfBorg> [Source] virtualbox (source)
[10:47] <LocutusOfBorg> 4.3.36-dfsg-1+deb8u1ubuntu1.14.04.3	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-11
[10:47] <LocutusOfBorg>  	
[10:48] <LocutusOfBorg> [Source] virtualbox (source)
[10:48] <LocutusOfBorg> 4.3.40-dfsg-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-01
[10:48] <LocutusOfBorg>  	
[10:48] <LocutusOfBorg> [Source] virtualbox (source)
[10:48] <LocutusOfBorg> 4.3.40-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-01-21
[10:48] <LocutusOfBorg> I rebased the upload on top of the proposed version
[11:26] <doko> apw: please could you look at the linux autopkg test failure triggered by binutils?
[11:40] <doko> vorlon: where did you copy these packages from: android-platform-development android-platform-external-boringssl android-platform-external-libunwind  android-platform-frameworks-native android-platform-system-tools-aidl
[11:42] <doko> these are *not* in the ppa:android-tools for cosmic
[11:44] -queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418 (disco-proposed/primary) [418.43-0ubuntu1]
[11:45] <doko> vorlon: now removed
[11:45] <doko> apw: ^^^
[12:14] <apw> doko, will get it checked
[12:17] -queuebot:#ubuntu-release- Unapproved: openjfx (cosmic-proposed/universe) [11.0.2+1-1~18.04.2 => 11.0.2+1-1~18.10] (no packageset) (sync)
[12:18] -queuebot:#ubuntu-release- Unapproved: scilab (cosmic-proposed/universe) [6.0.1-7~18.04.1 => 6.0.1-7~18.10] (no packageset) (sync)
[12:20] -queuebot:#ubuntu-release- New sync: equinox-bundles (bionic-proposed/primary) [4.9-2~18.04]
[12:21] -queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (cosmic-proposed) [11.0.2+1-1~18.10]
[12:21] -queuebot:#ubuntu-release- New sync: equinox-framework (bionic-proposed/primary) [4.9-1~18.04]
[12:21] -queuebot:#ubuntu-release- New sync: equinox-p2 (bionic-proposed/primary) [4.9-1~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-bundles [sync] (bionic-proposed) [4.9-2~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-p2 [sync] (bionic-proposed) [4.9-1~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-framework [sync] (bionic-proposed) [4.9-1~18.04]
[12:23] -queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (cosmic-proposed) [6.0.1-7~18.10]
[12:45] <doko> vorlon: also removed apktool and enjarify
[13:12] -queuebot:#ubuntu-release- Unapproved: android-sdk-meta (bionic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
[13:12] -queuebot:#ubuntu-release- Unapproved: android-sdk-meta (cosmic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
[13:14] -queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (cosmic-proposed) [25.0.0+10~18.04.2]
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (bionic-proposed) [25.0.0+10~18.04.2]
[14:19] <tjaalton> fwupdate is in bionic NEW, could someone ack the packages
[14:20] <seb128> tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text= is empty?
[14:20] <tjaalton> hmm
[14:21] <tjaalton> binaries
[14:21] <tjaalton> not src
[14:21] <seb128> ah
[14:22] <tjaalton> https://launchpad.net/ubuntu/+source/fwupdate/12-3bionic2
[14:22] <tjaalton> unapproved?
[14:23] <seb128> indeed
[14:24] <seb128> I let it though, I think fwupdate is somewhat special and vorlon had issues with the previous upload
[14:33] <tjaalton> yes, those issues got fixed
[14:43] <apw> bionic2 .... didnt we stop with the names years back
[14:45] -queuebot:#ubuntu-release- New sync: wlroots (disco-proposed/primary) [0.3-1]
[15:07] <vorlon> doko: when yesterday you listed android-tools ppa as one of the ppas to copy from for cosmic, I pointed out that ppa had no packages in cosmic at the time so I would copy forward directly from bionic
[15:17] <doko> hmm, I'm pretty sure I copied everything there, and then removed the ones which were not needed
[15:18] -queuebot:#ubuntu-release- New: accepted wlroots [sync] (disco-proposed) [0.3-1]
[15:20] -queuebot:#ubuntu-release- New binary: wlroots [amd64] (disco-proposed/none) [0.3-1] (no packageset)
[15:20] -queuebot:#ubuntu-release- New binary: wlroots [s390x] (disco-proposed/none) [0.3-1] (no packageset)
[15:21] -queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [arm64] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [i386] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [armhf] (disco-proposed/none) [0.3-1] (no packageset)
[15:23] <Eickmeyer> Anybody up for looking at carla again now that I fixed its copyright issues? (vorlon, cyphermox)?
[15:24] <mdeslaur> how to I retrigger the ghostscript autopkgtest now that there's a new ocrmypdf version in disco?
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [amd64] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [armhf] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [arm64] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [s390x] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [i386] (disco-proposed) [0.3-1]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [12-3bionic2]
[15:44] <vorlon> Eickmeyer: it needs an archive admin now to review it as it's been reuploaded to the NEW queue (so not cyphermox).  I am not looking at it currently, but it's on my list to come back to; I was currently prioritizing trying to get the image builds working again, since my os-prober fix was ineffective
[15:45] <Eickmeyer> vorlon: Okay, let me know if I need to reinstate that update-grub exists check.
[15:45] <vorlon> Eickmeyer: that won't help.  update-grub DOES exist, and is failing in the livecd-rootfs build environment.
[15:46] <Eickmeyer> vorlon: ack
[15:56] <cyphermox> that would need some livecd-rootfs change (os-prober)
[15:57] <vorlon> cyphermox: that's what I changed and it apparently isn't os-prober that was failing
[15:57] <cyphermox> vorlon: need more eyes?
[15:57] <vorlon> I /assumed/ it was but it's actually failing due to grub-probe
[15:57] <vorlon> (which, granted, was in the error message in the build log)
[15:58] <cyphermox> is it a similar issue to what we've seen in cloud images?
[15:58] <vorlon> so I really don't understand how this has wound up an ubuntustudio-specific problem, I would have expected more things to be calling update-grub before now, and we have no diversions
[15:58] <vorlon> which issue?
[15:58] <cyphermox> some time ago, livecd-rootfs hooks were confusing grub / grub-probe a bit re: UUIDs and whatnot
[15:58] <cyphermox> I haven't looked at the build logs yet
[16:05] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.18] (core)
[16:07] -queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.1-0ubuntu1.3 => 1.36.1-0ubuntu1.3.1] (desktop-core)
[16:11] <Eickmeyer> vorlon: If there's anything I can do to help, let me know.
[17:15] <Trevinho> sil2100: hey, maybe you can review this https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 ?
[17:18] <sil2100> Trevinho: hey! I can, yes! But not sure if we actually want this feature ;p
[17:19] <Trevinho> sil2100: well, people is complaining about not being able to review the SRUs quickly... so...
[17:19] <Trevinho> I should have done it probably 3 years ago, but...
[17:20] <sil2100> Well, it's not that we couldn't do it, it's mostly because no one wanted to
[17:20] -queuebot:#ubuntu-release- Unapproved: unity (xenial-proposed/main) [7.4.5+16.04.20180221-0ubuntu1 => 7.4.5+16.04.20190312-0ubuntu1] (ubuntu-desktop) (sync)
[17:21] <sil2100> Thanks for the branch, let me take a look at it and at least do a code-review
[17:22] <Laney> IMO you might as well have it while bileto is still alive, to make the SRU review experience easier - currently those reviews seem to be quite painful
[17:26] <Trevinho> also dont' kill bileto! :)
[17:27] <Trevinho> at least not everything, you can get rid of autopkg stuff, but it makes many things less annoying. So, get rid of what is broken and even a simple way to have a PPA setup and publishing is enough.
[17:27] <Laney> doing that is work in itself, and why would you hate on the testing integration?
[17:27]  * Laney sulks
[17:28] <Trevinho> Laney: I was mentioend that was the part causing troubles.
[17:29] <cjwatson> Landing mvo's command-not-found publisher integration for the primary archive (only >= disco)
[17:30] <cjwatson> I'm just watching a couple of publisher runs to make sure it doesn't break
[17:35] <cjwatson> Hm, not quite right, fixing
[17:46] -queuebot:#ubuntu-release- Unapproved: python-ldappool (cosmic-proposed/universe) [2.2.0-3ubuntu1 => 2.2.0-3ubuntu2] (no packageset)
[17:53] -queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server)
[18:50] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[18:50] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[18:52] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[19:00] -queuebot:#ubuntu-release- New source: intel-mediasdk (disco-proposed/primary) [18.4.1-0ubuntu1]
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (cosmic-proposed) [5.1.2-4ubuntu1.1]
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (cosmic-proposed) [0.7-1ubuntu1.18.10.1]
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (bionic-proposed) [0.7-1ubuntu1.18.04.1]
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3.1]
[20:40] <vorlon> ddstreet: for awareness: LP: #1819625
[20:41] <vorlon> I've seen a problem myself with DNS on cosmic after upgrade, which I'm working to reproduce under controlled circumstances that don't involve me being locked out of my desktop
[20:42] <ddstreet> vorlon you use resolvconf on cosmic?
[20:42] <vorlon> ddstreet: yes, because I upgrade and dogfood
[20:42] <ddstreet> and it doesn't work?
[20:42] <vorlon> ddstreet: post SRU, it stopped working because all of the upstream DNS servers got blatted into /run/resolvconf/resolv.conf instead of the system pointing at systemd-resolved which dtrt
[20:42] <ddstreet> vorlon to be clear - you use resolvconf but not ifupdown?
[20:43] <vorlon> resolvconf plus NM - this is on my laptop locally
[20:43] <ddstreet> and you can't directly access your upstream ns?  only thru resolved?
[20:44] <ddstreet> anyway, do put more info into the bug when you have time
[20:44] <vorlon> ddstreet: I was on the corporate VPN and the VPN dropped and resolvconf didn't notice
[20:44] <vorlon> yeah I'm going to chase this shortly
[20:44] <ddstreet> ah ok
[21:18] -queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu10.18.10.1 => 1.79ubuntu10.18.10.2] (no packageset)
[21:21] <ddstreet> vorlon if you simply revert it then you place things back into edns0-to-upstream-dns server land, which isn't good either
[21:22] <ddstreet> but of course, your call ;-)
[21:22] <ddstreet> depends on whose dns resolution you want to break
[21:23] <ddstreet> personally, i'd recommend rejecting your revert upload so we can try to figure out what the problem is and fix it
[21:25] <vorlon> ddstreet: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1819625/comments/6
[21:25] <vorlon> as far as I'm concerned, the root cause is that we failed to kick resolvconf to the curb prior to 18.04 release
[21:27] <vorlon> and my /run/resolvconf/resolv.conf prior to the SRU did not have the configuration described in 2) of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817903 - I have the local stub resolver and not the upstream name servers, which is what we should be aiming for
[21:29] <ddstreet> vorlon well, this is how things worked pre-bionic, with resolvconf you don't get per-interface dns resolution
[21:30] <vorlon> yes, and we switched to resolved in bionic because it was the pre-bionic behavior was broken
[21:30] <ddstreet> it seems, based on my (time-)limited testing, that the problem is resolved doesn't remove nameservers once routes go away
[21:30] <vorlon> that is also a problem
[21:30] <ddstreet> e.g. i connectd to vpn, /run/systemd/resolve/resolv.conf added the vpn nameserver, i disconnected, but it's still there
[21:30] <vorlon> but round-robining the VPN dns servers by exposing them in /etc/resolv.conf is also a problem, and a regression introduced by this SRU
[21:30] <ddstreet> maybe resolved magically knows not to talk to it, but it has to remove it for resolvconf to knwo that and update /etc/resolv.conf
[21:31] <ddstreet> ok...well if you're rejecting the pre-bionic behavior of resolvconf, then we'll have to figure out a better way to have it use resolved than pull the stub-resolver
[21:32] <ddstreet> because in that case, with ifupdown/resolvconf and systemd now including edns0, dns will definitely break unless all nameservers in the world start supporting edns0
[21:33] <ddstreet> we could revert systemd including edns0 but that breaks from upstream, and we would then need to backport systemd resolved tcp pipelining from upstream, which is significantly more headache
[21:33] <ddstreet> anyway, it's complex
[21:33] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (cosmic-proposed) [1.79ubuntu10.18.10.2]
[21:33] <ddstreet> go for the revert if you think that's best - once it's changed, i'll figure out how to best fix the entire situation (since it's still broken, but now just for other people)
[21:35] <ddstreet> vorlon you may want to note in lp #1817903 that everyone affected will see breakage again with your reversion
[21:37] <vorlon> ddstreet: xnox has some ideas about a proper fix
[21:38] <xnox> ddstreet, hey
[21:38] <xnox> ddstreet, let's use this channel.
[21:39] <xnox> ddstreet, switching from stub-resolv.conf to resolv.conf is broken and should not have been ever done. As we have created stub-resolv.conf to specifically address integration on ubuntu, we want to use resolved's resolver all the time, as that's the only way to get correct split dns resolution.
[21:39] <xnox> ddstreet, i do understand that options ends0 (with the systemd's sru) started to leak into /etc/resolv.conf with unintended consequences.
[21:39] <xnox> ddstreet, the answer to that is to filter that option out as in:
[21:39] <xnox> i was expecting to diff be:
[21:40] <xnox> -ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | /sbin/resolvconf -a systemd-resolved'
[21:40] <xnox> +ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | grep -v edns0 | /sbin/resolvconf -a systemd-resolved'
[21:40] <ddstreet> xnox er, without edns0, the bug *that* fixed isn't fixed at all
[21:40] <ddstreet> so people iwth resolvconf installed shouldn't get that fix?
[21:40] <xnox> ddstreet, now that is sort of a majority fix, as we do kind of need ends0 when talking to resolved, but that's life for those that upgrade to bionic.
[21:40] <xnox> ddstreet, yes.
[21:41] <ddstreet> er...
[21:41] <ddstreet> ok...
[21:41] -queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu10.18.04.1 => 1.79ubuntu10.18.04.2] (no packageset)
[21:41] <xnox> ddstreet, now to fix this further, for everyone. we would need to reverse the flow of nameservers.
[21:41] <xnox> ddstreet, instead of adding resolved' to resolvconf, we'd need to feed all the resolvconf entries into resolved.
[21:41] <ddstreet> xnox so systems with resolvconf should definitely *not* be able to successfuly resolve dns if the reply is > 512 bytes?
[21:42] <xnox> ddstreet, they will over TCP, won't they?
[21:42] <xnox> ddstreet, you did SRU back listing on TCP, in addition to UDP?
[21:42] <ddstreet> hopefully!  that was the entire problem tho
[21:42] <xnox> *listening
[21:42] <ddstreet> no i didn't backport tcp pipelining
[21:42] <xnox> ddstreet, i just don't understand how you tested http://launchpadlibrarian.net/413182599/resolvconf_1.79ubuntu10_1.79ubuntu10.18.04.1.diff.gz this
[21:43] <xnox> ddstreet, and why did you think that switching to raw nameservers would ever work, when ubuntu has never used those, in any of the releases.
[21:43] <xnox> ddstreet, that's not a cherrypick from any release, is it?
[21:43] <ddstreet> xnox that's how things were x and earlier
[21:43] <ddstreet> with ifupdown/resolvconf
[21:43] <xnox> ddstreet, which didn't have resolved by default.
[21:43] <ddstreet> right...
[21:43] <xnox> ddstreet, and also broken.
[21:43] <xnox> (differently)
[21:43] <ddstreet> what, x and earlier were broken?
[21:44] <vorlon> yes
[21:44] <xnox> it leaked dns, failed at split-dns, etc.
[21:44] <ddstreet> ok :)
[21:44] <xnox> all the things that were fixed in bionic.
[21:44] <vorlon> we introduced systemd-resolved by design to fix architecture issues
[21:44] <xnox> and now regressed.
[21:44] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu10.18.04.2]
[21:44] <xnox> not just systemd-resolved, but stub-resolv.conf usage of systemd-resolved.
[21:45]  * vorlon nods
[21:45] <ddstreet> got it.  so b+ should *always* use resolved under all circumstances, period.
[21:45] <xnox> ddstreet, note that people who have resolvconf installed on bionic; are upgrade peopel; and i'm ok with keeping them not as good as default install of bionic with resolved.
[21:45] <ddstreet> well, except with ifupdown
[21:45] <xnox> or upgraders
[21:45] <xnox> (from ifupdown)
[21:45] <ddstreet> xnox note that default installers of bionic don't get resolvconf
[21:45] <ddstreet> ;-)
[21:45] <vorlon> right
[21:46] <xnox> hence it's ok to keep them without options ends0
[21:46] <vorlon> and without resolvconf, things work better
[21:46] <ddstreet> i will say that upgraders from xenial are likely a large number of users
[21:46] <ddstreet> and that's *future* upgraders too - lots still on t/x
[21:46] <xnox> ddstreet, that's subjective of the users you are exposed to ;-)
[21:46] <vorlon> yeah; and I think xnox's | grep -v edns0 helps there
[21:46] <ddstreet> yep, we can do that
[21:46] <ddstreet> hopefully upstream nameservers will behave better than resolved-stub
[21:47] <xnox> ddstreet, long term solution is to remove resolvconf from the archive, and make systemd provide /sbin/resolvconf that feeds into resolved (most things)
[21:47] <ddstreet> (probably they will, i think dnsmasq and bind handle tcp pipelining ok, but i haven't specificalyl checked)
[21:47] <xnox> ddstreet, then we can finally put all of the mess behind us.
[21:47] <ddstreet> xnox yep i look forward to that day in 2050 xD
[21:47] <xnox> ddstreet, it's usually the crappy home router between machine and the real internet that is shit.
[21:48] <ddstreet> so xnox you want to update resolvconf with grep -v edns0, or should i?  or vorlon?
[21:48] <xnox> ddstreet, vast majority of our users are fresh launches of cloud-images/containers btw ;-)
[21:49] <xnox> irrespective of the bug volumes that we see.
[21:49] <ddstreet> also one additional thought for vorlon - x upgraders who still use ifupdown with dhcp (and resolvconf), will have upstream nameservers in /etc/resolv.conf
[21:50] <xnox> ddstreet, no.
[21:50] <xnox> ddstreet, dhcp from ifupdown feeds into resolved via my resolved hook to isc-dhcp
[21:50] <xnox> ddstreet, and feeds nothing into resolvconf
[21:50] <ddstreet> ah right, resolved is lexically after resolvconf
[21:50] <ddstreet> i'm thinking of ifupdown static ip/dns
[21:50] <xnox> static bits feed into resolv.conf
[21:51] <ddstreet> that is what gets into /etc/resolv.conf via the /etc/network/if-up.d/resolvconf script
[21:51] <vorlon> yes; this is still broken
[21:51] <vorlon> but we need to fix that local bug locally, not revert the architecture
[21:51] <ddstreet> ok, as long as you're aware it's broken :)
[21:51] <xnox> oh yes we are.
[21:51] <ddstreet> well remove/fix the if-up script, shoudl be easy.
[21:52] <ddstreet> xnox re: majority of our users, that's probably true, tho not with UA, but that's not really imporant
[21:53] <ddstreet> xnox so should i update and reupload resolvconf with the grep -v?
[21:53] <ddstreet> not sure if you or vorlon are doing it now
[21:53] <vorlon> not me
[21:54] <vorlon> I'm doing a straight revert which is under my SRU team purview
[21:54] <ddstreet> xnox also while i have you, there's a bug where dhcp doesn't work for bionic+ guests inside libguestfs because dhcp calls the systemd hook, and systemd isn't init in the libguestfs appliance :(  not sure if you have any quick thoughts on that
[21:55] <ddstreet> vorlon ack i'll do a follow up to add grep per xnox's comment above
[21:55] <xnox> vorlon, ddstreet - we can do more heuristics, like if there are no nameservers apart from the stub-resolver in the end, we can append the ends0 option back in safely.
[21:55] <ddstreet> vorlon do you want me to wait for your revert to get to -updates or just upload when i have it ready
[21:55] <vorlon> ddstreet: feel free to upload when ready
[21:55] <vorlon> I'll make sure the revert gets published first regardless
[21:55] <ddstreet> thnx will do (probably tomrorow, it's late here)
[21:55] <xnox> vorlon, ddstreet - cause that should be another common case with ifupdown+dhcp+resolvconf+resolved
[23:38] <Ukikie> I hear in order for other things to get past -proposed golang-golang-x-sys needs hinting.