/srv/irclogs.ubuntu.com/2021/08/24/#ubuntu-devel.txt

Unit193Yeeeah, glibc this late seems a bit...Well..  Also I keep getting emails. :(00:05
mwhudsonit would be nice if the releases aligned better00:06
sarnoldbetter 21.10 than 22.04 though :)00:07
mwhudsonglibc is getting close finally, it would be nice to to a rebuild and at least amd64 autopkgtest run with a 2.35 snapshot earlier in the next cycle00:07
EickmeyerI'm assuming I'm in the same boat as everyone else with stuff stuck in proposed due to glibc.00:11
Unit193sarnold: Someone should quickly sync autoconf 2.70 from Debian, that seems to breaks some things. :D00:13
sarnoldUnit193: one two three *not it*00:14
Unit193So that means autoconf 2.70, gcc-11, and openssl3 will land for TLS?00:15
EickmeyerI've seen some ideas in my time, and that one could be easily labeled as *BAD*.00:15
=== genii is now known as genii-core
schopin_mwhudson: Uh. That's... new? I'm pretty much never touching the signature line, always relying on dch to do its thing.07:16
=== doko_ is now known as doko
TJ-anyone able to think of a workaround for Bug #1940908 ?09:25
ubottuBug 1940908 in systemd (Ubuntu) "resolved: closes listening socket too rapidly and sends Destination port unreachable" [Undecided, New] https://launchpad.net/bugs/194090809:25
=== schopin_ is now known as schopin
=== sunweave1 is now known as sunweaver
rbasakTJ-: I'm not sure I understand why this issue breaks name lookups11:18
rbasakLooking at the upstream issue, it seems like the issue is just that the port unreachable gets sent? Because systemd is stopping listening when it has an answer from elsewhere.11:18
rbasakSo if it has an answer from elsewhere, why are name lookups broken?11:18
mwhudsonginggs: cod-tools/ppc64el has regressed in release: https://autopkgtest.ubuntu.com/packages/cod-tools/impish/ppc64el you can stop retrying it :)11:27
mwhudsoni meant to make a hint for it but didn't get around to it and now i'm about to fall asleep11:27
ginggsmwhudson: I did see that, it looked like an OOM failure to me, so thought 2 more retries wouldn't hurt11:29
mwhudsonah ok11:29
ginggsmwhudson: i'll do the hint11:29
mwhudsoni guess it could be that yes11:29
mwhudsonthanks11:29
ginggsor at least the MP for it11:30
TJ-rbasak: sorry, was away. The issue affects it when there is no answer from elsewhere (in our case there is no alternate DNS server - any alternate would have to be on the other side of the same link)13:50
rbasakTJ-: I don't understand why this wouldn't affect everyone such that DNS effectively doesn't work at all. What's different here?14:21
=== sarnold_ is now known as sarnold
TJ-rbasak: I presume its the satellite link latency (Starlink). Most of the time it works but occassionally it fails in this way when latency spikes. Been seeing the effect for a while but only tracked it down yesterday whilst anaylsing an unrelated issue14:44
TJ-rbasak: the only way I can think to workaround it is force all queries over TCP14:44
rbasakTJ-: are you sure it's that bug? Does a local patch fix it? I'm still dubious because it sounded like the bug was fixing something else, rather than just high latency links.14:56
rbasakIf resolved is timing out while a UDP request is in transit, then ICMP port unreachable is exactly what I'd expect to see if the reply does eventually arrive.14:56
TJ-rbasak:  yes, commit e03d156f78cb5a0ca solves it. In that patch, line 71 of src/resolve/resolved-dns-transaction.c  has a comment that explains the issue15:05
TJ-rbasak: oops, thats the merge. the actual commit is 80710ade03d15:09
rbasakThanks. otp. I'll look again in a bit.15:10
TJ-rbasak: I'll doing some builds here with patches cherry-picked onto Ubuntu packages instead of testing upstream so I'll add to the report once those are tested.15:13
TJ-I was hoping there was an easy workaround!15:14
=== genii-core is now known as genii
=== tumbleweed_ is now known as tumbleweed

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