-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) | 06:33 | |
-queuebot:#ubuntu-release- New binary: leaflet-markercluster [amd64] (disco-proposed/universe) [1.4.1~dfsg-6] (no packageset) | 08:39 | |
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 ? | 08:59 |
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:17 |
ubot5 | Ubuntu bug 1819448 in wala (Ubuntu) "update to openjdk 11 in 18.04 LTS (android-tools packages)" [Undecided,New] | 09:17 |
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:18 |
LocutusOfBorg | hello, can anybody please update debci hint to 2.0 too? | 09:36 |
LocutusOfBorg | please also hint octave-image/2.10.0-2 on ppc64el, regressed in release | 09:45 |
LocutusOfBorg | (its already ignored on amd64 and i386, same OOM) | 09:46 |
LocutusOfBorg | apw, ^^ | 09:46 |
-queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.15 => 237-3ubuntu10.16] (core) | 10:24 | |
-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:39 | |
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.3multiversemiscmediumubuntu-cloudProposed2019-03-11 | 10:47 |
LocutusOfBorg | 10:47 | |
LocutusOfBorg | [Source] virtualbox (source) | 10:48 |
LocutusOfBorg | 4.3.40-dfsg-0ubuntu14.04.1multiversemiscmediumubuntu-cloudProposed2019-03-01 | 10:48 |
LocutusOfBorg | 10:48 | |
LocutusOfBorg | [Source] virtualbox (source) | 10:48 |
LocutusOfBorg | 4.3.40-0ubuntu14.04.1multiversemiscmediumubuntu-cloudProposed2019-01-21 | 10:48 |
LocutusOfBorg | I rebased the upload on top of the proposed version | 10:48 |
doko | apw: please could you look at the linux autopkg test failure triggered by binutils? | 11:26 |
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:40 |
doko | these are *not* in the ppa:android-tools for cosmic | 11:42 |
-queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418 (disco-proposed/primary) [418.43-0ubuntu1] | 11:44 | |
doko | vorlon: now removed | 11:45 |
doko | apw: ^^^ | 11:45 |
apw | doko, will get it checked | 12:14 |
-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:17 | |
-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:18 | |
-queuebot:#ubuntu-release- New sync: equinox-bundles (bionic-proposed/primary) [4.9-2~18.04] | 12:20 | |
-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:21 | |
-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:22 | |
-queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (cosmic-proposed) [6.0.1-7~18.10] | 12:23 | |
doko | vorlon: also removed apktool and enjarify | 12:45 |
-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:12 | |
-queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (cosmic-proposed) [25.0.0+10~18.04.2] | 13:14 | |
-queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (bionic-proposed) [25.0.0+10~18.04.2] | 13:15 | |
tjaalton | fwupdate is in bionic NEW, could someone ack the packages | 14:19 |
seb128 | tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text= is empty? | 14:20 |
tjaalton | hmm | 14:20 |
tjaalton | binaries | 14:21 |
tjaalton | not src | 14:21 |
seb128 | ah | 14:21 |
tjaalton | https://launchpad.net/ubuntu/+source/fwupdate/12-3bionic2 | 14:22 |
tjaalton | unapproved? | 14:22 |
seb128 | indeed | 14:23 |
seb128 | I let it though, I think fwupdate is somewhat special and vorlon had issues with the previous upload | 14:24 |
tjaalton | yes, those issues got fixed | 14:33 |
apw | bionic2 .... didnt we stop with the names years back | 14:43 |
-queuebot:#ubuntu-release- New sync: wlroots (disco-proposed/primary) [0.3-1] | 14:45 | |
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:07 |
doko | hmm, I'm pretty sure I copied everything there, and then removed the ones which were not needed | 15:17 |
-queuebot:#ubuntu-release- New: accepted wlroots [sync] (disco-proposed) [0.3-1] | 15:18 | |
-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:20 | |
-queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (disco-proposed/none) [0.3-1] (no packageset) | 15:21 | |
-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:22 | |
Eickmeyer | Anybody up for looking at carla again now that I fixed its copyright issues? (vorlon, cyphermox)? | 15:23 |
mdeslaur | how to I retrigger the ghostscript autopkgtest now that there's a new ocrmypdf version in disco? | 15:24 |
-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:27 | |
-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:30 | |
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:44 |
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:45 |
Eickmeyer | vorlon: ack | 15:46 |
cyphermox | that would need some livecd-rootfs change (os-prober) | 15:56 |
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:57 |
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 | 15:58 |
-queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.18] (core) | 16:05 | |
-queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.1-0ubuntu1.3 => 1.36.1-0ubuntu1.3.1] (desktop-core) | 16:07 | |
Eickmeyer | vorlon: If there's anything I can do to help, let me know. | 16:11 |
Trevinho | sil2100: hey, maybe you can review this https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 ? | 17:15 |
sil2100 | Trevinho: hey! I can, yes! But not sure if we actually want this feature ;p | 17:18 |
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:19 |
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:20 | |
sil2100 | Thanks for the branch, let me take a look at it and at least do a code-review | 17:21 |
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:22 |
Trevinho | also dont' kill bileto! :) | 17:26 |
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:27 | |
Trevinho | Laney: I was mentioend that was the part causing troubles. | 17:28 |
cjwatson | Landing mvo's command-not-found publisher integration for the primary archive (only >= disco) | 17:29 |
cjwatson | I'm just watching a couple of publisher runs to make sure it doesn't break | 17:30 |
cjwatson | Hm, not quite right, fixing | 17:35 |
-queuebot:#ubuntu-release- Unapproved: python-ldappool (cosmic-proposed/universe) [2.2.0-3ubuntu1 => 2.2.0-3ubuntu2] (no packageset) | 17:46 | |
-queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server) | 17:53 | |
-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:50 | |
-queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-8.9] (core, kernel) | 18:52 | |
-queuebot:#ubuntu-release- New source: intel-mediasdk (disco-proposed/primary) [18.4.1-0ubuntu1] | 19:00 | |
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (cosmic-proposed) [5.1.2-4ubuntu1.1] | 20:05 | |
-queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (cosmic-proposed) [0.7-1ubuntu1.18.10.1] | 20:10 | |
-queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (bionic-proposed) [0.7-1ubuntu1.18.04.1] | 20:12 | |
-queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3.1] | 20:14 | |
vorlon | ddstreet: for awareness: LP: #1819625 | 20:40 |
ubot5 | Launchpad bug 1819625 in resolvconf (Ubuntu) "Package resolvconf=1.79ubuntu10.18.04.1 broken" [Undecided,Confirmed] https://launchpad.net/bugs/1819625 | 20:40 |
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:41 |
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:42 |
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:43 |
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 | 20:44 |
-queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu10.18.10.1 => 1.79ubuntu10.18.10.2] (no packageset) | 21:18 | |
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:21 |
ddstreet | but of course, your call ;-) | 21:22 |
ddstreet | depends on whose dns resolution you want to break | 21:22 |
ddstreet | personally, i'd recommend rejecting your revert upload so we can try to figure out what the problem is and fix it | 21:23 |
vorlon | ddstreet: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1819625/comments/6 | 21:25 |
ubot5 | Ubuntu bug 1819625 in resolvconf (Ubuntu) "Package resolvconf=1.79ubuntu10.18.04.1 broken" [Undecided,Confirmed] | 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:25 |
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:27 |
ubot5 | Ubuntu bug 1817903 in resolvconf (Ubuntu Disco) "systemd-resolve appends "options edns0" to resolv.conf" [Critical,Fix released] | 21:27 |
ddstreet | vorlon well, this is how things worked pre-bionic, with resolvconf you don't get per-interface dns resolution | 21:29 |
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:30 |
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:31 |
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:32 |
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:33 |
ddstreet | vorlon you may want to note in lp #1817903 that everyone affected will see breakage again with your reversion | 21:35 |
ubot5 | Launchpad bug 1817903 in resolvconf (Ubuntu Disco) "systemd-resolve appends "options edns0" to resolv.conf" [Critical,Fix released] https://launchpad.net/bugs/1817903 | 21:35 |
vorlon | ddstreet: xnox has some ideas about a proper fix | 21:37 |
xnox | ddstreet, hey | 21:38 |
xnox | ddstreet, let's use this channel. | 21:38 |
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:39 |
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:40 |
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:41 |
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:42 |
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:43 |
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:44 |
* 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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
ddstreet | xnox re: majority of our users, that's probably true, tho not with UA, but that's not really imporant | 21:52 |
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:53 |
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:54 |
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 | 21:55 |
Ukikie | I hear in order for other things to get past -proposed golang-golang-x-sys needs hinting. | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!