[00:03] <sarnold> mwhudson: hmm. I've got sshebang installed, and that dehashes ssh hostnames; and I probably had liquidprompt installed and running then, too, which would fiddle with PS1; I'm not sure what else in my local environment is all that 'funny'
[00:04] <mwhudson> sarnold: anyway, as to why this doesn't happen all the time, dunno
[00:05] <mwhudson> sarnold: we do get people to reboot after upgrade but i don't know why things don't break during upgrade more
[00:07] <sarnold> mwhudson: certainly, some of my machines go a very long time between reboots..
[00:10] <mwhudson> sarnold: ah ha! copying my sshebanged .ssh into the container got me a repro
[00:12] <mwhudson> sarnold: how how do i debug this :/
[00:13] <sarnold> mwhudson: sheeeesh, beats me, this is well into magic territory as far as I'm concerned :)
[00:30] <mwhudson> oh it's ~ expansion
[00:30] <mwhudson> maybe?
[01:16] <mwhudson> yes it is
[01:17] <mwhudson> i have _no_ idea how it doesn't cause problems on update though
[01:23] <sarnold> I'm still not entirely sure how my setup gets around to calling into a pthread initializer in a long-lived process over and over again..
[01:23] <sarnold> but it feels like that configuration is already pretty rare
[01:23] <sarnold> (despite how quickly and easily I hit it :)
[01:25] <sarnold> and if most tunables never get changed from their default values, re-arranged tunables is probably invisible -- if all the bytes in a block are zeros, does it matter in which order you read ints, long ints, chars, etc? they're all zero...
[01:25] <sarnold> actually changing the type of one, and having it stored juuuuuust right to then stomp over a canary, feels pretty unlikely too
[01:28] <mwhudson> sarnold: tilde expansion does nss things, that dlopen libnss_systemd, which depends on libpthread
[01:29] <mwhudson> (and also tunables don't all default to zero, unfortunately)
[01:33] <sarnold> mwhudson: hmm... how did that not kill my shell dead? does bash fork itself while doing these things?
[01:34] <mwhudson> sarnold: if you start a shell, upgrade libc and then execute "echo ~a" that kills the shell
[01:35] <mwhudson> sarnold: in the completion case it must be happening off in a subprocess somewhere
[01:35] <mwhudson> if you start a shell, execute "echo ~a" and then upgrade libc everything continues to work, of course
[01:35] <mwhudson> "of course" should be in quotes there
[01:35] <mwhudson> eep gotta run
[01:35] <sarnold> happy running :)
[09:21] <schopin> Hi all! Could a good soul retry this build? https://launchpad.net/ubuntu/+source/socat/1.7.4.1-3ubuntu3/+build/22446936
[09:28] <GunnarHj> schopin: Retried
[09:32] <schopin> Thank you!
[09:49] <schopin> Hi! There a package in the archive that has a .orig.tar.gz.asc that doesn't match its orig tarball. I checked upstream and it's our (well, Debian's) orig tarball that has been changed, switching the UID and GID of the files to root
[09:49] <schopin> How can I fix it?
[10:15] <ginggs> schopin: which package?
[10:16] <schopin> eggdrop
[10:16] <schopin> I checked in Debian, and they have the same problem.
[10:25] <schopin> Looking for a sponsor for LP: #1945812. OpenSSL related, but it's a server-related package
[10:28] <ginggs> schopin: re eggdrop, I think file a bug against debian, but just rm the .asc file locally before uploading
[10:30] <schopin> OK, will do.
[10:51] <shailangsa> does anybody know whether higher RAM frequency in contrast to lower timings result in better build times?
[11:04] <schopin> shailangsa: do you mean something like 3200MHz/CL16 vs 3600MHz/CL18 ?
[11:06] <shailangsa> yes or more specifically 3600 mhz c16 vs 4400 c19?
[11:10] <schopin> The latter one will result in lower RAM latency (19 cycles at 4400MHz is faster than 16 cycles at 3600MHz) but I'm not sure how big an impact it has on your typical compilation workload.
[11:14] <shailangsa> does it make a difference whether 4x16GB 4400mhz DDR is used? motherboard says "dual channel" not sure what that means https://www.msi.com/Motherboard/PRO-Z690-A-WIFI-DDR4/Specification
[16:44] <ahasenack> Unit193: hi
[16:44] <ahasenack> Unit193: I'm working on the wireguard MIR in ubuntu
[16:45] <ahasenack> https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1950317
[16:45] <ahasenack> which spawned two other tickets I'm also working on: https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1952767 and https://bugs.launchpad.net/ubuntu/+source/wireguard/+bug/1952102
[16:45] <ahasenack> I'll put these up for review soon, and would like to add you as a reviewer
[16:46] <ahasenack> and, when this gets promoted to main, we would of course still love to have you work on the package, so what do you think about applying at least for a PPU (per package uploader) for it?
[18:04] <schopin> Still looking for a sponsor for LP: #1945812 :)
[18:42] <jawn-smith> schopin: I'll take a look!
[18:42] <schopin> aha!
[18:56] <jawn-smith> schopin: uploaded :)
[18:56] <schopin> Nice!
[19:55] <dbungert> This retest link should pull pyqt5 from proposed, right?  https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=armhf&package=pyqt5&trigger=python3-defaults/3.9.7-4&trigger=node-jquery/3.5.1%2Bdfsg%2B~3.5.5-8  I ask because it's the link from the retest button beside the non-proposed version of the package, but the wiki makes it sound like these retests pull the proposed package.
[20:06] <jawn-smith> dbungert: I _think_ so
[20:07] <dbungert> jawn-smith: care to use your new powers? ;)
[20:07] <jawn-smith> dbungert: test request submitted :)
[20:08] <dbungert> one more please, different package https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=ppc64el&package=skimage&trigger=python3-defaults/3.9.7-4&trigger=matplotlib/3.5.0-2&trigger=scipy/1.7.1-1ubuntu1&trigger=pillow/8.4.0-1&trigger=node-jquery/3.5.1%2Bdfsg%2B~3.5.5-8
[20:09] <jawn-smith> dbungert: done
[20:09] <dbungert> jawn-smith: thanks x2
[20:36] <dbungert> Retest click please?  Just passed on ppc64el https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=armhf&package=skimage&trigger=python3-defaults/3.9.7-4&trigger=matplotlib/3.5.0-2&trigger=scipy/1.7.1-1ubuntu1&trigger=pillow/8.4.0-1&trigger=node-jquery/3.5.1%2Bdfsg%2B~3.5.5-8
[20:43] <bdmurray> that's done
[20:52] <dbungert> bdmurray: thanks!  (and RikMills also)
[21:46] <Unit193> ahasenack: Howdy!  Re: LP #1952102, not sure how well you know Debian's autopkgtest setup, but it doesn't do full VM so as it is src:wireguard-linux-compat's autopkgtests aren't run, and this wouldn't likely be either (I'm presuming you'd require isolation-machine restriction.)  That doesn't mean it couldn't be merged upstream in Debian, but it would have limited usefulness in doing so.  I'd presume
[21:46] <Unit193> you've already seen https://sources.debian.org/src/wireguard-linux-compat/1.0.20210606-1/debian/tests/netns-mini/ of course.  I could do PPU, but not sure about the timing of things right now.
[21:49] <dbungert> jawn-smith: the test we triggered for pyqt5 did pull the NONproposed version of the package.  Maybe this one is better? https://autopkgtest.ubuntu.com/request.cgi?release=jammy&arch=armhf&package=pyqt5&trigger=pyqt5/5.15.6+dfsg-1&trigger=python3-defaults/3.9.7-4&trigger=node-jquery/3.5.1%2Bdfsg%2B~3.5.5-8
[21:51] <jawn-smith> dbungert: that looks to me like it should work
[21:51] <jawn-smith> I'll go ahead and start it
[21:54] <jawn-smith> That's giving me a "Malformed trigger" error. Time to defer to bdmurray
[21:54] <ahasenack> Unit193: ah, I didn't know debian didn't do isolation-machine
[21:57] <ahasenack> Unit193: we can still add it to debian, so the moment they implement isolation-machine, they would get the test
[22:01] <jawn-smith> dbungert: got it working, just had to escape the + symbol in the URL as %2B
[22:31] <mwhudson> yes constructing trigger urls is a great way to learn the url escaping rules