| === cpaelzer_ is now known as cpaelzer | ||
| schopin | o/ looking for a good soul to click on the following link (combo openssl+linux-meta-aws for the sysdig autopkgtest) https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=arm64&package=sysdig&trigger=openssl/1.1.1l-1ubuntu1&trigger=linux-meta-aws/5.13.0.1000.2 | 12:12 |
|---|---|---|
| ginggs | schopin: . | 12:17 |
| schopin | Thanks! | 12:18 |
| ginggs | de rien | 12:21 |
| schopin | ginggs: if you feel like it, s'more links to click on ;-) https://pastebin.ubuntu.com/p/k3yJtsPyTX/ | 12:59 |
| * ginggs clicks all the things | 13:01 | |
| slyon | ddstreet: I investigated LP: #1934221 again today. https://errors.ubuntu.com/problem/c4e5be3f1c7af9483993c7e6007b9325ab5b78cd (new) looks very similar to https://errors.ubuntu.com/problem/bb0ce4ff8e6ef86041cfb5647b792823a20b44f7 (old) – I think it's the same root cause. | 13:41 |
| slyon | Apparently my patch did not fix it, but it is now failing in `sd_event_source_disable_unref` instead of `sd_event_source_unref`, so probably there is something more to it. | 13:41 |
| ubottu | Launchpad bug 1934221 in systemd (Ubuntu Impish) "systemd-resolve segfault" [Undecided, Fix Released] https://launchpad.net/bugs/1934221 | 13:41 |
| slyon | I cannot really reproduce the issue on my system, but only observe that it does NOT crash. And our bug reporter mentioned that it would not crash anymore on his system with the patch applied. The same patch (almost, except some whitespace) was also applied to systemd-stable: https://github.com/systemd/systemd-stable/commit/78a43c33c8847ebbc2d3cf530ebe304924c58b32 | 13:43 |
| ubottu | Commit 78a43c3 in systemd/systemd-stable "resolved: disable event sources before unreffing them" | 13:43 |
| slyon | ddstreet: So I wonder if we should rather revert that patch, to go back to the old SEGFAULT, or keep it in and force phasing of the update, as it does not really make the situation worse with the SEGFAULT happening in a different subroutine from within the same callback handler. | 13:45 |
| slyon | what would be your preferred option? | 13:46 |
| schopin | ginggs: https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=mosquitto&trigger=mosquitto/2.0.11-1 (trying to prove that mosquitto is broken without openssl's help) | 13:49 |
| ginggs | schopin: . | 14:17 |
| schopin | ginggs: thanks. | 14:27 |
| schopin | OK, looking for insights here. mosquitto is failing its tests with the latest openssl, but self-triggering passes the tests. I cannot reproduce the failure locally using qemu, and I cannot make canonistack work. Any thoughts on how to solve this? | 14:30 |
| schopin | https://autopkgtest.ubuntu.com/packages/mosquitto/impish/amd64 <- the tests in question. | 14:30 |
| bdmurray | schopin: I have an amd64 system in canonistack setup let me run the test there | 14:32 |
| schopin | thanks! | 14:32 |
| bdmurray | schopin: it passed for me `sudo autopkgtest --shell-fail --apt-upgrade --apt-pocket=proposed=src:openssl mosquitto -- lxd autopkgtest/ubuntu/impish/amd64` is what I ran | 15:08 |
| schopin | ... great. Works everywhere but on the runners, then :/ | 15:09 |
| dbungert | to get vip-manager improved, I ended up doing some debug builds from a PPA and run in autopackage test to get info on why the runners were different - might something like that help, schopin ? | 15:12 |
| schopin | dbungert: I don't have autopkgtest privileges so it'd be a bit cumbersome, but I'll keep it in mind. | 15:13 |
| dbungert | your point is valid - it will require some help to get the tests started, but the process did work well | 15:14 |
| schopin | before I do that though, would it be worth it to trigger the failing test again? Last failure was a couple of days ago, whereas the success (without openssl) was today. Things might have changed? | 15:15 |
| dbungert | sounds worth a try | 15:16 |
| schopin | https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=mosquitto&trigger=openssl/1.1.1l-1ubuntu1 would somebody be so kind? | 15:18 |
| bdmurray | I did it | 15:25 |
| ddstreet | slyon i suspect it's a problem with the query, upstream there are a series of commits that try to fix stuff in that area, ultimately winding up adding proper refcnting to the query candidate objects in 0e0fd08fc832b8f42e567d722d388eba086da5ff | 15:26 |
| ddstreet | however then c856ef0457c35e9edfdbf085b69ec81c126d48e5 was added onto that, so i'm not sure if things are all fixed upstream yet; maybe, but i only did a quick look | 15:27 |
| ddstreet | not sure how appropriate sru'ing all that would be, or if there's anything that made it into -stable from the refcnting stuff | 15:28 |
| schopin | bdmurray: since you already did the amd64 one and it worked, would you be so kind and click there? -> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=s390x&package=mosquitto&trigger=openssl/1.1.1l-1ubuntu1 | 15:39 |
| bdmurray | schopin: done | 15:48 |
| schopin | Thanks! | 15:48 |
| abeato | hey, could I get a review for https://launchpad.net/ubuntu/+source/xrt/202020.2.8.743-0ubuntu1 ? (so it is published in the release pocket) | 15:54 |
| bdmurray | abeato: I'm not sure what kind of review you are looking for. You can see it is stuck in -proposed here https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xrt | 15:57 |
| abeato | bdmurray, ah I see. Well, yeah. one of the changes is to remove non-working amd64 packages from the build (this has been discussed with xilinx upstream). What can be done to move it forward? | 15:58 |
| vorlon | abeato, bdmurray: binaries removed from the release pocket, it should migrate now | 16:02 |
| abeato | vorlon, cool, thanks! | 16:03 |
| slyon | ddstreet: ack. I'll double check that tomorrow. | 16:03 |
| schopin | bdmurray: looking at the mosquitto s390x failures and the test history, it's always the same test that fails, and it seems rather random. Could it possibly be a timeout thing? | 16:06 |
| schopin | would it be OK to simply disable this particular test? | 16:06 |
| schopin | (gotta run, but I'll prepare a patch for that tomorrow) | 16:07 |
| vorlon | schopin: s390x being our fastest architecture, it's unlikely that we would hit a timeout on that architecture but not others | 16:13 |
| bdmurray | schopin: I'd look and see what the autopkgtests look like in debian | 16:14 |
| === genii-core is now known as genii | ||
| jawn-smith | moving to this channel instead of ubuntu-meeting for this discussion | 20:56 |
| jawn-smith | mwhudson: I have the risc-v go change prepared for 1.17, just testing it on my Unmatched from a PPA before I upload it | 20:56 |
| mwhudson | jawn-smith: ah great | 21:21 |
| === genii is now known as genii-core | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!