[00:05] <Unit193> Yeeeah, glibc this late seems a bit...Well..  Also I keep getting emails. :(
[00:06] <mwhudson> it would be nice if the releases aligned better
[00:07] <sarnold> better 21.10 than 22.04 though :)
[00:07] <mwhudson> glibc 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 cycle
[00:11] <Eickmeyer> I'm assuming I'm in the same boat as everyone else with stuff stuck in proposed due to glibc.
[00:13] <Unit193> sarnold: Someone should quickly sync autoconf 2.70 from Debian, that seems to breaks some things. :D
[00:14] <sarnold> Unit193: one two three *not it*
[00:15] <Unit193> So that means autoconf 2.70, gcc-11, and openssl3 will land for TLS?
[00:15] <Eickmeyer> I've seen some ideas in my time, and that one could be easily labeled as *BAD*.
=== genii is now known as genii-core
[07:16] <schopin_> mwhudson: Uh. That's... new? I'm pretty much never touching the signature line, always relying on dch to do its thing.
=== doko_ is now known as doko
[09:25] <TJ-> anyone able to think of a workaround for Bug #1940908 ?
[09:25] <ubottu> Bug 1940908 in systemd (Ubuntu) "resolved: closes listening socket too rapidly and sends Destination port unreachable" [Undecided, New] https://launchpad.net/bugs/1940908
=== schopin_ is now known as schopin
=== sunweave1 is now known as sunweaver
[11:18] <rbasak> TJ-: I'm not sure I understand why this issue breaks name lookups
[11:18] <rbasak> Looking 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] <rbasak> So if it has an answer from elsewhere, why are name lookups broken?
[11:27] <mwhudson> ginggs: cod-tools/ppc64el has regressed in release: https://autopkgtest.ubuntu.com/packages/cod-tools/impish/ppc64el you can stop retrying it :)
[11:27] <mwhudson> i meant to make a hint for it but didn't get around to it and now i'm about to fall asleep
[11:29] <ginggs> mwhudson: I did see that, it looked like an OOM failure to me, so thought 2 more retries wouldn't hurt
[11:29] <mwhudson> ah ok
[11:29] <ginggs> mwhudson: i'll do the hint
[11:29] <mwhudson> i guess it could be that yes
[11:29] <mwhudson> thanks
[11:30] <ginggs> or at least the MP for it
[13:50] <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)
[14:21] <rbasak> TJ-: I don't understand why this wouldn't affect everyone such that DNS effectively doesn't work at all. What's different here?
=== sarnold_ is now known as sarnold
[14:44] <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 issue
[14:44] <TJ-> rbasak: the only way I can think to workaround it is force all queries over TCP
[14:56] <rbasak> TJ-: 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] <rbasak> If 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.
[15:05] <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 issue
[15:09] <TJ-> rbasak: oops, thats the merge. the actual commit is 80710ade03d
[15:10] <rbasak> Thanks. otp. I'll look again in a bit.
[15:13] <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:14] <TJ-> I was hoping there was an easy workaround!
=== genii-core is now known as genii
=== tumbleweed_ is now known as tumbleweed