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:43 |
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:44 |
cpaelzer | if anyone has a pointer about that please let me know :-) | 07:46 |
cpaelzer | oh and s390x seems stuck at https://launchpad.net/builders | 07:54 |
cpaelzer | if anyone could bump them that would be great | 07:54 |
acheronuk | ^ cjwatson ? | 07:58 |
cjwatson | poking | 08:28 |
cpaelzer | thanks cjwatson | 08:31 |
=== ricab is now known as ricab|lunch | ||
cyphermox | doko: didrocks: jdstrand: cpaelzer: MIR team meeting? | 12:55 |
doko | cyphermox: wrong channel? ;) | 12:55 |
cyphermox | no | 12:56 |
cyphermox | it's meant to be a ping ;) | 12:56 |
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:07 |
ahasenack | both go through squid.internal, but on the armhf lxd that's unresolveable (dns) | 13:08 |
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 | 13:28 |
=== ricab|lunch is now known as ricab | ||
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:10 |
ddstreet | xnox you figured out the systemd storage failures yet? i won't bother looking if you already fixed it | 14:16 |
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:23 |
xnox | i should upload my experiment to see if things get better. | 14:24 |
=== cpaelzer__ is now known as cpaelzer | ||
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:45 |
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 | 14:47 |
xnox | ddstreet: experimenting here locally i replaced mkswap -> with 'sleep 30; mkswap.real /dev/....' shell script. | 17:14 |
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:15 |
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. | 17:16 |
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 | 21:46 |
sarnold | Unit193: does it do dynamic loading? | 22:03 |
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. | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!