[07:43] <cpaelzer> is there a runtime component that resolves some of the usrmerge
[07:43] <cpaelzer> I'm trying to find why in a container/vm of eoan I have /usr/sbin/iptables while on an sbuild env it is missing
[07:43] <cpaelzer> the package itself carries only /sbin/iptables, so something else must add that symlink with /usr prefix
[07:44] <cpaelzer> and since that is ok on container/vm but missing in sbuild I wondere if there is something active that doesn't run in the schroot that adds this
[07:46] <cpaelzer> if anyone has a pointer about that please let me know :-)
[07:54] <cpaelzer> oh and s390x seems stuck at https://launchpad.net/builders
[07:54] <cpaelzer> if anyone could bump them that would be great
[07:58] <acheronuk> ^ cjwatson ?
[08:28] <cjwatson> poking
[08:31] <cpaelzer> thanks cjwatson
[12:55] <cyphermox> doko: didrocks: jdstrand: cpaelzer: MIR team meeting?
[12:55] <doko> cyphermox: wrong channel? ;)
[12:56] <cyphermox> no
[12:56] <cyphermox> it's meant to be a ping ;)
[13:07] <ahasenack> hi, diaspora-installer actually downloads the diaspora tarball from github in its postinst, using wget. That fails on the armhf autopkgtest lxd (https://pastebin.ubuntu.com/p/N9MqVKvN4Q/), but works in the other arches (https://pastebin.ubuntu.com/p/RVQFSwXS8F/)
[13:08] <ahasenack> both go through squid.internal, but on the armhf lxd that's unresolveable (dns)
[13:28] <ahasenack> hm, n/m, that was just bad luck, but there is still a real error later on. I created an MP to hint it
[14:10] <coreycb> hello, can an archive admin please remove python-oslo.log 3.44.0-0ubuntu2 from eoan-proposed? we have some recursive dependency issues and this is the easiest resolution.
[14:10] <coreycb> s/recursive/circular
[14:16] <ddstreet> xnox you figured out the systemd storage failures yet?  i won't bother looking if you already fixed it
[14:23] <xnox> ddstreet:  figured out => no; there is related discussion on the upstream mailing list to the similar effect; i do wonder if we somehow activate swap without noticing, to be debugged. As currently the "swap" test is the one that now consistently fails over.
[14:24] <xnox> i should upload my experiment to see if things get better.
[14:45] <ddstreet> xnox i'm pretty sure the problem is the swap (and tmp) tests have ExecStartPost jobs (mkswap and mke2fs) but the test cases don't wait for those post-start jobs to complete, so it's a race between the stop call and the post-start job
[14:45] <ddstreet> not sure if that's how you fixed it or not
[14:45] <ddstreet> maybe i'm wrong
[14:45] <ddstreet> you would know best :)
[14:47] <ddstreet> it's possible just adding --job-mode=fail would fix the race
[14:47] <xnox> hm
[14:47] <xnox> post-start are racy.
[14:47] <xnox> i wonder why that is used, instead of starting a new unit.
[14:47] <ddstreet> or, actually waiting for mkswap or mke2fs to complete; the fstab test does by apply(local-fs.target)
[14:47] <ddstreet> seems the generator stuffs it in there, i assume
[14:47] <ddstreet> didn't actually look at where it's getting added
[17:14] <xnox> ddstreet:  experimenting here locally i replaced mkswap -> with 'sleep 30; mkswap.real /dev/....' shell script.
[17:15] <xnox> ddstreet:  and both 'systemctl start ...' and 'systemctl restart cryptsetup.target' (or like 'local-fs.targer' do seem to block and wait for ExecPostStart to complete.
[17:15] <xnox> ddstreet:  what my patches locally do, is do not do "double start" anymore, as that is strictly redudand and racy. sprinkle udevadm settle, and force remove dm device.
[17:16] <xnox> ddstreet:  https://paste.ubuntu.com/p/PFvkGTT3y3/
[17:16] <xnox> but that's kind of like imperical guessing rather than understanding what is going south here.
[21:46] <Unit193> Well that was concerning, after yesterday's big OpenSSL update, I had a ruby script fail with encoding issues in openssl/buffering.rb.  Either it was a fluke, or re-running the script gave different output such that the issue didn't happen again. :3
[22:03] <sarnold> Unit193: does it do dynamic loading?
[22:05] <Unit193> sarnold: For most elements it's the same if run later in the day as it changes based on the date, for 2 elements though it changes every run.