tjaaltonLocutusOfBorg: hi, ideas how to fix 1829034?06:23
tjaaltonbug 182903406:23
ubottubug 1829034 in llvm-toolchain-8 (Ubuntu) "libomp5-8 fails to install" [Undecided,New] https://launchpad.net/bugs/182903406:23
tjaaltonlooks like conflicts/replaces aren't properly set on the backport..06:26
seb128sbeattie: 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 upload06:45
ubottubug 1829245 in qemu (Ubuntu) "Networking issues after upgrade to 1:2.5+dfsg-5ubuntu10.37" [Undecided,New] https://launchpad.net/bugs/182924506:45
cpaelzerseb128: he's off now - but I subscribed him and others06:51
seb128cpaelzer: thx06:53
=== alan_g_ is now known as alan_g
rbasakddstreet: thank you for raising the sudo/HOME question on ubuntu-devel-discuss@10:01
rbasakddstreet: 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:01
ddstreetrbasak i think user input is fairly important for this change as much as developer input, which is why i chose -discuss10:32
rbasakddstreet: fair enough11:02
xnoxbdmurray:  please purge resolvconf from your system. and use resolved only.11:20
LocutusOfBorgtjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-defaults/commit/a1287b19315f64f15fba7126cb98c314f1a5ebc211:58
LocutusOfBorgunfortunately that meta-package seems to be non-existing in bionic...11:58
LocutusOfBorg libomp-dev | 5.0.1-1               | bionic/universe          | amd64, arm64, armhf, i386, ppc64el12:00
LocutusOfBorgit is provided by another libomp package, not by llvm12:00
=== ricab is now known as ricab|lunch
tjaaltonLocutusOfBorg: no, the breaks/replaces are built wrong on bionic for llvm7 & 812:52
tjaaltonConflicts: libomp512:53
tjaaltonConflicts: libomp-x.y12:53
tjaaltoner, C/R12:53
tjaaltonLocutusOfBorg: unless you mean llvm-defaults would fix this12:54
tjaaltonLocutusOfBorg: uhm, no.. I'm just confused. it's llvm7 where libomp5-7 doesn't provide libomp-x.y13:08
seb128cyphermox, hey, bug #1828996 ... wouldn't be that an hostnamed issue? I think g-c-c only calls into that13:11
ubottubug 1828996 in network-manager-applet (Ubuntu) ""Advanced Network Configuration" is displayed in both Utilities and Sundry categories" [Low,Confirmed] https://launchpad.net/bugs/182899613:11
seb128sorry wrong bug number13:11
tjaaltonLocutusOfBorg: so we'd need d9b6d3fd40bc107 in bionic13:11
seb128bug #1162475 I meant13:13
ubottubug 1162475 in systemd (Ubuntu Xenial) "[hostnamed] Changing hostname doesn't update /etc/hosts" [Low,Triaged] https://launchpad.net/bugs/116247513:13
cyphermoxit 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-hostname13:45
=== ricab|lunch is now known as ricab
seb128cyphermox, k, thx14:09
seb128cyphermox, hey btw :)14:09
cyphermoxseb128: good morning :)14:10
seb128cyphermox, 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 helps14:10
bdmurrayxnox: that only helps me, not other users of Ubuntu 18.0414:39
vorlonbdmurray: refresh my memory, what actually introduced the behavior regression originally?14:43
bdmurrayvorlon: upgrading to 18.04 iirc14:44
vorlonbdmurray: right, I mean, what component of the system changed its resolver behavior14:44
cyphermoxseb128: I'll see when I can get to that14:44
vorlonis it newer glibc doing more aggressive pipelining?14:44
seb128cyphermox, sounds like "not now/help welcome"? :)14:45
bdmurrayvorlon: I haven't had a clear understanding of the issue. ddstreet might14:45
LocutusOfBorgyes tjaalton probably that one14:45
LocutusOfBorgsbeattie, I syncd intel-microcode from Debian, because their version looks better than the Ubuntu one... https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.114:46
ddstreetbdmurray dns lookups with responses > 512 bytes cause getaddrinfo to fallback to TCP dns lookups, unless 'options edns0' is enabled14:46
ddstreetthe systemd stub resolver doesn't (correctly) support that until disco14:47
LocutusOfBorglooks like they are picking stuff from github repo now, and the "releasenotes" are more up-to-date14:47
ddstreetwith only systemd installed, this was worked around by adding 'options edns0' to systemd stub resolver14:47
ddstreetbut 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:48
ddstreethence, bionic/cosmic without resolvconf installed can lookup e.g. toomany.ddstreet.org14:49
vorlonddstreet: bdmurray's configuration isn't using the stub resolver, he has resolvconf and therefore upstream nameservers in /etc/resolv.conf14:49
ddstreetwhile bionic/cosmic with resolvconf installed cannot lookup e.g. toomany.ddstreet.org14:49
ddstreetvorlon resolvconf throws the stub resolver in there too14:49
ddstreetand strips out edns014:49
vorlonand 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 resolvconf14:49
ddstreetso gai won't fallback to edns0, it'll fallback to tcp14:50
ddstreetedns0 is a resolv.conf conf, not systemd conf14:50
vorlonbdmurray: what's your /etc/resolv.conf?14:50
ddstreetit tells glibc's gai what to fall back to14:50
bdmurrayvorlon: https://pastebin.ubuntu.com/p/X6zdcSSdS2/14:51
vorlonok so the problem is falling back to tcp and then trying to talk to the stub resolver which doesn't listen14:51
vorlonso in fact if you have resolvconf and ONLY systemd-resolved as a DNS server, we should in fact set options edns014:52
vorlonor else "fix" the stub resolver by backporting a huge new feature what could go wrong14:52
vorlonor alternatively, after we finish nuking resolvconf from eoan and make systemd conflict with it (calling dr xnox), we could SRU that to bionic14:53
vorlonexcept that's a package removal which won't be applied by update-manager14:53
ddstreetyeah we really need to fix the cases where upstream nameservers are handed to resolvconf, then we can apply edns0 safely14:54
ddstreete.g. ifupdown static ip's14:54
ddstreetmaybe ibft14:54
ddstreetno idea about network-manager or openvpn14:54
vorlonmaybe we should update resolvconf itself to magically re-add options edns0 if it sees only the resolved ip14:54
ddstreetwhat if it does have an upstream nameserver?14:55
vorlonI don't see a sane way to solve that case14:55
ddstreetdoes it rip out the stub resolver?14:55
vorlonhmmm there's an idea14:55
vorlonwhy not?14:55
ddstreetbecause the  upstream namesever might not resolve all addresses14:55
ddstreete.g. local stuff, per-interface stuff, etc14:55
ddstreetwe had this discussion already when you reverted my patch to make resolvconf use upstream nameservers :)14:56
ddstreetpretty sure either we corral and kill all things that might put an upstream nameserver into resolvconf, or we backport resolved tcp pipelining14:56
ddstreeti think tcp pipeline backport is probably the less dangerous option, but it's certainly not trivial14:57
vorlonI 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 them14:57
vorlonif 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 before14:58
ddstreetthat only works if you don't actually need the stub resolver to resolve anything14:59
ddstreetand that's hardly going to be the case all the time14:59
vorlonright, 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 resolvconf14:59
ddstreetbesides backporting tcp piplining, the only sane thing to do is make all your dns belong to resolved14:59
ddstreetwell resolved has per-interface dns15:00
ddstreetyou can't do that with resolv.conf15:00
ddstreetthere is no way to fit resolved into resolv.conf15:00
ddstreetthat covers all situations15:00
vorlonyes, which means you would not have BOTH per-interface dns AND upstream nameservers in resolvconf15:00
vorlonchanging the resolvconf package in the presence of resolved to emit only into /etc/resolv.conf, and redirect all other servers to resolved?15:01
vorlon(did we already rule that option out?)15:01
ddstreetyes, that is the only sane solution - all your dns belong to resolved15:02
ddstreetbut, 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 resolved15:02
vorlonin that case we don't need to backport tcp support at all as long as we're telling gai to use edns015:03
vorlonI think hacking resolvconf centrally is better15:03
vorlonxnox: ^^15:07
seb128juliank, bug #1829401 looks like a recent regression/bug from your changes15:18
ubottubug 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/182940115:18
xnoxbdmurray:  it helps everyone who did clean install of bionic, as none of those use resolvconf15:19
xnoxvorlon:  ok15:20
sbeattieLocutusOfBorg: that's fine, thanks15:38
coreycbsil2100: 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 -proposed16:23
sil2100coreycb: sure, let me try getting to that16:26
coreycbsil2100: thank you16:27
sil2100coreycb: hm, actually, I think the .changes file for at least the disco one seems to be missing one version16:52
sil2100coreycb: the current nova in disco-proposed has 2 versions pending SRU verification, 2:19.0.0-0ubuntu2.1 and 2:19.0.0-0ubuntu2.216:52
sil2100coreycb: you included 2:19.0.0-0ubuntu2.2 in it, but 2:19.0.0-0ubuntu2.1 got dropped16:53
sil2100coreycb: could you re-upload with -v2:19.0.0-0ubuntu2 ?16:53
sil2100Then we should have all the bugs in the .changes file16:53
coreycbsil2100: i thought the 2nd version i uploaded included it16:53
sil2100coreycb: it includes 2, while it should include 3 ;)16:54
sil2100The 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 file16:54
coreycbsil2100: gotcha! fixing.16:55
coreycbsil2100: ok uploaded a new one to disco16:59
sil2100coreycb: thanks o/17:01
sil2100coreycb: 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
sil2100coreycb: this section should outline where one should expect issues to pop up if anything after looking at which parts of the code have been touched17:07
sil2100coreycb: 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 this17:09
sil2100(that's for the two new bugs)17:09
sil2100Anyway, accepted that for now17:10
coreycbsil2100: yes i'll do my best to improve on that. there's a lot of throughput as you can tell with openstack.17:11
coreycbsil2100: thank you17:11
coreycbsil2100: 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:13
sil2100coreycb: that's always useful info, but we always feel safer after we know someone did look through some of the regression-potential scenarios ;)17:14
sil2100Also, it really depends on the fix, since sometimes there can really be not much to write in the regression potential field indeed17:15
coreycbsil2100: ack on both points17:15

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!