[07:43] is there a runtime component that resolves some of the usrmerge [07:43] 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] the package itself carries only /sbin/iptables, so something else must add that symlink with /usr prefix [07:44] 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] if anyone has a pointer about that please let me know :-) [07:54] oh and s390x seems stuck at https://launchpad.net/builders [07:54] if anyone could bump them that would be great [07:58] ^ cjwatson ? [08:28] poking [08:31] thanks cjwatson === ricab is now known as ricab|lunch [12:55] doko: didrocks: jdstrand: cpaelzer: MIR team meeting? [12:55] cyphermox: wrong channel? ;) [12:56] no [12:56] it's meant to be a ping ;) [13:07] 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] both go through squid.internal, but on the armhf lxd that's unresolveable (dns) [13:28] hm, n/m, that was just bad luck, but there is still a real error later on. I created an MP to hint it === ricab|lunch is now known as ricab [14:10] 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] s/recursive/circular [14:16] xnox you figured out the systemd storage failures yet? i won't bother looking if you already fixed it [14:23] 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] i should upload my experiment to see if things get better. === cpaelzer__ is now known as cpaelzer [14:45] 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] not sure if that's how you fixed it or not [14:45] maybe i'm wrong [14:45] you would know best :) [14:47] it's possible just adding --job-mode=fail would fix the race [14:47] hm [14:47] post-start are racy. [14:47] i wonder why that is used, instead of starting a new unit. [14:47] or, actually waiting for mkswap or mke2fs to complete; the fstab test does by apply(local-fs.target) [14:47] seems the generator stuffs it in there, i assume [14:47] didn't actually look at where it's getting added [17:14] ddstreet: experimenting here locally i replaced mkswap -> with 'sleep 30; mkswap.real /dev/....' shell script. [17:15] 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] 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] ddstreet: https://paste.ubuntu.com/p/PFvkGTT3y3/ [17:16] but that's kind of like imperical guessing rather than understanding what is going south here. [21:46] 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] Unit193: does it do dynamic loading? [22:05] 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.