[06:23] <tjaalton> LocutusOfBorg: hi, ideas how to fix 1829034?
[06:23] <tjaalton> bug 1829034
[06:23] <ubottu> bug 1829034 in llvm-toolchain-8 (Ubuntu) "libomp5-8 fails to install" [Undecided,New] https://launchpad.net/bugs/1829034
[06:26] <tjaalton> looks like conflicts/replaces aren't properly set on the backport..
[06:45] <seb128> sbeattie: hey, pointing that bug in case you didn't see it/it's interesting, bug #1829245 claims to be a regression from the recent security upload
[06:45] <ubottu> bug 1829245 in qemu (Ubuntu) "Networking issues after upgrade to 1:2.5+dfsg-5ubuntu10.37" [Undecided,New] https://launchpad.net/bugs/1829245
[06:51] <cpaelzer> seb128: he's off now - but I subscribed him and others
[06:53] <seb128> cpaelzer: thx
=== alan_g_ is now known as alan_g
[10:01] <rbasak> ddstreet: thank you for raising the sudo/HOME question on ubuntu-devel-discuss@
[10:01] <rbasak> ddstreet: FWIW, ubuntu-devel@ would have been fine. https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel says "Discussions seeking consensus among Ubuntu developers" is on-topic.
[10:32] <ddstreet> rbasak i think user input is fairly important for this change as much as developer input, which is why i chose -discuss
[11:02] <rbasak> ddstreet: fair enough
[11:20] <xnox> bdmurray:  please purge resolvconf from your system. and use resolved only.
[11:58] <LocutusOfBorg> tjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-defaults/commit/a1287b19315f64f15fba7126cb98c314f1a5ebc2
[11:58] <LocutusOfBorg> unfortunately that meta-package seems to be non-existing in bionic...
[12:00] <LocutusOfBorg>  libomp-dev | 5.0.1-1               | bionic/universe          | amd64, arm64, armhf, i386, ppc64el
[12:00] <LocutusOfBorg> it is provided by another libomp package, not by llvm
=== ricab is now known as ricab|lunch
[12:52] <tjaalton> LocutusOfBorg: no, the breaks/replaces are built wrong on bionic for llvm7 & 8
[12:53] <tjaalton> Conflicts: libomp5
[12:53] <tjaalton> vs
[12:53] <tjaalton> Conflicts: libomp-x.y
[12:53] <tjaalton> er, C/R
[12:54] <tjaalton> LocutusOfBorg: unless you mean llvm-defaults would fix this
[13:08] <tjaalton> LocutusOfBorg: uhm, no.. I'm just confused. it's llvm7 where libomp5-7 doesn't provide libomp-x.y
[13:11] <seb128> cyphermox, hey, bug #1828996 ... wouldn't be that an hostnamed issue? I think g-c-c only calls into that
[13:11] <ubottu> bug 1828996 in network-manager-applet (Ubuntu) ""Advanced Network Configuration" is displayed in both Utilities and Sundry categories" [Low,Confirmed] https://launchpad.net/bugs/1828996
[13:11] <seb128> sorry wrong bug number
[13:11] <tjaalton> LocutusOfBorg: so we'd need d9b6d3fd40bc107 in bionic
[13:13] <seb128> bug #1162475 I meant
[13:13] <ubottu> bug 1162475 in systemd (Ubuntu Xenial) "[hostnamed] Changing hostname doesn't update /etc/hosts" [Low,Triaged] https://launchpad.net/bugs/1162475
[13:45] <cyphermox> it is a systemd issue, as currently assigned to it. there are *control-center tasks too because of .pkla issues in the past, and I don't know whether they all go call on whatever the dbus method is to set-transient-hostname
[13:45] <cyphermox> err
[13:45] <cyphermox> set-static-hostname
=== ricab|lunch is now known as ricab
[14:09] <seb128> cyphermox, k, thx
[14:09] <seb128> cyphermox, hey btw :)
[14:10] <cyphermox> seb128: good morning :)
[14:10] <seb128> cyphermox, oh, while I'm talking to you. Do you plan to look at the plymouthd patches/update early in the cycle? I'm mostly curious and I a bit interested in helping with upstreaming some of our distro changes if that helps
[14:39] <bdmurray> xnox: that only helps me, not other users of Ubuntu 18.04
[14:43] <vorlon> bdmurray: refresh my memory, what actually introduced the behavior regression originally?
[14:44] <bdmurray> vorlon: upgrading to 18.04 iirc
[14:44] <vorlon> bdmurray: right, I mean, what component of the system changed its resolver behavior
[14:44] <cyphermox> seb128: I'll see when I can get to that
[14:44] <vorlon> is it newer glibc doing more aggressive pipelining?
[14:45] <seb128> cyphermox, sounds like "not now/help welcome"? :)
[14:45] <bdmurray> vorlon: I haven't had a clear understanding of the issue. ddstreet might
[14:45] <LocutusOfBorg> yes tjaalton probably that one
[14:46] <LocutusOfBorg> sbeattie, I syncd intel-microcode from Debian, because their version looks better than the Ubuntu one... https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.1
[14:46] <ddstreet> bdmurray dns lookups with responses > 512 bytes cause getaddrinfo to fallback to TCP dns lookups, unless 'options edns0' is enabled
[14:47] <ddstreet> the systemd stub resolver doesn't (correctly) support that until disco
[14:47] <LocutusOfBorg> looks like they are picking stuff from github repo now, and the "releasenotes" are more up-to-date
[14:47] <ddstreet> with only systemd installed, this was worked around by adding 'options edns0' to systemd stub resolver
[14:48] <ddstreet> but with resolvconf installed, it might throw upstraem nameservers into /etc/resolv.conf, depending on the specific system config, so xnox told me to strip 'edns0' out of resolv.conf when resolvconf is installed to avoid that (since we can't guarantee upstream nameservers support edns0)
[14:49] <ddstreet> hence, bionic/cosmic without resolvconf installed can lookup e.g. toomany.ddstreet.org
[14:49] <vorlon> ddstreet: bdmurray's configuration isn't using the stub resolver, he has resolvconf and therefore upstream nameservers in /etc/resolv.conf
[14:49] <ddstreet> while bionic/cosmic with resolvconf installed cannot lookup e.g. toomany.ddstreet.org
[14:49] <ddstreet> vorlon resolvconf throws the stub resolver in there too
[14:49] <ddstreet> and strips out edns0
[14:49] <vorlon> and the configuration of the stub resolver itself is independent of /etc/resolv.conf, so if he WAS using the stub resolver it should work, since the configuration of options on the stub resolver (edns0) should be independent of the configuration of /etc/resolv.conf via resolvconf
[14:50] <ddstreet> so gai won't fallback to edns0, it'll fallback to tcp
[14:50] <ddstreet> edns0 is a resolv.conf conf, not systemd conf
[14:50] <vorlon> bdmurray: what's your /etc/resolv.conf?
[14:50] <ddstreet> it tells glibc's gai what to fall back to
[14:51] <bdmurray> vorlon: https://pastebin.ubuntu.com/p/X6zdcSSdS2/
[14:51] <vorlon> ok so the problem is falling back to tcp and then trying to talk to the stub resolver which doesn't listen
[14:52] <vorlon> right
[14:52] <vorlon> so in fact if you have resolvconf and ONLY systemd-resolved as a DNS server, we should in fact set options edns0
[14:52] <vorlon> or else "fix" the stub resolver by backporting a huge new feature what could go wrong
[14:53] <vorlon> or alternatively, after we finish nuking resolvconf from eoan and make systemd conflict with it (calling dr xnox), we could SRU that to bionic
[14:53] <vorlon> except that's a package removal which won't be applied by update-manager
[14:54] <ddstreet> yeah we really need to fix the cases where upstream nameservers are handed to resolvconf, then we can apply edns0 safely
[14:54] <ddstreet> e.g. ifupdown static ip's
[14:54] <ddstreet> maybe ibft
[14:54] <ddstreet> no idea about network-manager or openvpn
[14:54] <vorlon> maybe we should update resolvconf itself to magically re-add options edns0 if it sees only the resolved ip
[14:55] <ddstreet> what if it does have an upstream nameserver?
[14:55] <vorlon> I don't see a sane way to solve that case
[14:55] <ddstreet> does it rip out the stub resolver?
[14:55] <vorlon> hmmm there's an idea
[14:55] <vorlon> why not?
[14:55] <ddstreet> because the  upstream namesever might not resolve all addresses
[14:55] <ddstreet> e.g. local stuff, per-interface stuff, etc
[14:56] <ddstreet> we had this discussion already when you reverted my patch to make resolvconf use upstream nameservers :)
[14:56] <ddstreet> pretty sure either we corral and kill all things that might put an upstream nameserver into resolvconf, or we backport resolved tcp pipelining
[14:57] <ddstreet> i think tcp pipeline backport is probably the less dangerous option, but it's certainly not trivial
[14:57] <vorlon> I thought the reason we reverted it was because we were winding up with /etc/resolv.conf containing *both* resolved which requires options edns0, *and* upstream nameservers that were not guaranteed to work with them
[14:58] <vorlon> if we always select one or the other, and choose whether to emit options edns0 selectively according to which we choose, I don't think that has the regressions we had before
[14:59] <ddstreet> that only works if you don't actually need the stub resolver to resolve anything
[14:59] <ddstreet> and that's hardly going to be the case all the time
[14:59] <vorlon> right, we do also need to make sure in such a case that there are no DNS servers being poked into resolved that aren't also poked into resolvconf
[14:59] <ddstreet> besides backporting tcp piplining, the only sane thing to do is make all your dns belong to resolved
[15:00] <ddstreet> well resolved has per-interface dns
[15:00] <ddstreet> you can't do that with resolv.conf
[15:00] <ddstreet> there is no way to fit resolved into resolv.conf
[15:00] <ddstreet> that covers all situations
[15:00] <vorlon> yes, which means you would not have BOTH per-interface dns AND upstream nameservers in resolvconf
[15:01] <vorlon> changing the resolvconf package in the presence of resolved to emit only 127.0.0.53 into /etc/resolv.conf, and redirect all other servers to resolved?
[15:01] <vorlon> (did we already rule that option out?)
[15:02] <ddstreet> yes, that is the only sane solution - all your dns belong to resolved
[15:02] <vorlon> ok
[15:02] <ddstreet> but, you have to either fix the soures (ifupdown, open-iscsi, etc) to send stuff to resolved, or oyu have to hack resolvconf to send stuff to resolved
[15:03] <vorlon> in that case we don't need to backport tcp support at all as long as we're telling gai to use edns0
[15:03] <ddstreet> yes
[15:03] <vorlon> I think hacking resolvconf centrally is better
[15:07] <vorlon> xnox: ^^
[15:18] <seb128> juliank, bug #1829401 looks like a recent regression/bug from your changes
[15:18] <ubottu> bug 1829401 in software-properties (Ubuntu) "/usr/bin/software-properties-gtk:TypeError:on_pktask_finish:on_pktask_finish:new_init:__init__:new_init:__init__:new_init" [Undecided,New] https://launchpad.net/bugs/1829401
[15:19] <xnox> bdmurray:  it helps everyone who did clean install of bionic, as none of those use resolvconf
[15:20] <xnox> vorlon:  ok
[15:38] <sbeattie> LocutusOfBorg: that's fine, thanks
[16:23] <coreycb> sil2100: hi, any chance you could take a look at accepting nova into disco-proposed and cosmic-proposed? (the latest upload, the one before that can be rejected) - note this version will replace the current versions in -proposed
[16:26] <sil2100> coreycb: sure, let me try getting to that
[16:27] <coreycb> sil2100: thank you
[16:52] <sil2100> coreycb: hm, actually, I think the .changes file for at least the disco one seems to be missing one version
[16:52] <sil2100> coreycb: the current nova in disco-proposed has 2 versions pending SRU verification, 2:19.0.0-0ubuntu2.1 and 2:19.0.0-0ubuntu2.2
[16:53] <sil2100> coreycb: you included 2:19.0.0-0ubuntu2.2 in it, but 2:19.0.0-0ubuntu2.1 got dropped
[16:53] <sil2100> coreycb: could you re-upload with -v2:19.0.0-0ubuntu2 ?
[16:53] <sil2100> Then we should have all the bugs in the .changes file
[16:53] <coreycb> sil2100: i thought the 2nd version i uploaded included it
[16:54] <sil2100> coreycb: it includes 2, while it should include 3 ;)
[16:54] <sil2100> https://launchpadlibrarian.net/424039899/nova_19.0.0-0ubuntu2.3_source.changes
[16:54] <sil2100> The current one in -proposed already has 2 versions scheduled, so puttin the new one on top means it should have 3 entries in the .changes file
[16:55] <coreycb> sil2100: gotcha! fixing.
[16:59] <coreycb> sil2100: ok uploaded a new one to disco
[17:01] <sil2100> coreycb: thanks o/
[17:07] <sil2100> coreycb: for the future, could we get a bit more info regarding regression potential? I'd say normally it's not enough giving context where the patches come from - every cherry-pick can cause regressions (as it was visible multiple times in the past)
[17:07] <sil2100> coreycb: this section should outline where one should expect issues to pop up if anything after looking at which parts of the code have been touched
[17:09] <sil2100> coreycb: it should be more of a thought exercise, identifying what areas can regress potentially due to the code changes, which other pieces can be affected by this
[17:09] <sil2100> (that's for the two new bugs)
[17:10] <sil2100> Anyway, accepted that for now
[17:11] <coreycb> sil2100: yes i'll do my best to improve on that. there's a lot of throughput as you can tell with openstack.
[17:11] <coreycb> sil2100: thank you
[17:13] <coreycb> sil2100: the point i usually try to make with with cherry-picked changes is that they've gone through a whole lot of gate testing, unit and functional, and upstream reviews.
[17:14] <sil2100> coreycb: that's always useful info, but we always feel safer after we know someone did look through some of the regression-potential scenarios ;)
[17:15] <sil2100> Also, it really depends on the fix, since sometimes there can really be not much to write in the regression potential field indeed
[17:15] <coreycb> sil2100: ack on both points