[00:19] yay, ppc64el no longer the arch with the biggest autopkgtest queue :P [02:17] I: [2021-11-06T09:02:25+0000] - Fetched test result for shibboleth-sp/3.2.2+dfsg1-1ubuntu1/amd64 20211105_200931_f00ed@ (triggers: ['xml-security-c/2.0.3-1', 'automake-1.16/1:1.16.5-1 krb5/1.18.3-7 make-dfsg/4.3-4ubuntu2']): pass [02:17] that... is certainly buggy [02:44] rolling back node-json-stable-stringify, still working on the bootstrap [05:06] node-jsdom bootstrap done [05:12] any idea for openconnect autopkgtest failure? [05:12] looks failed since the begin, but migration-reference thinks otherwise... [05:12] is it possible to trigger another migration reference? [05:16] there've been a few like that, rather curious [05:16] ginggs noticed devpi-common is similar [05:16] you can certainly retry it with migration-reference/0 to see if it's reproducible [05:24] wow thanks! I was not aware of the new keyword [05:24] done lets see [05:24] damn it failed always and consinstently since focal [05:25] not sure what happened with migration-reference [05:25] -queuebot:#ubuntu-release- New binary: target-factory [armhf] (jammy-proposed/universe) [1.4-5] (no packageset) [05:28] fwiw it just passed for me here in a local test [05:29] new keyword> well it's old in Debian, just turned on in Ubuntu :) julian_k posted about it to ubuntu-devel [05:36] -queuebot:#ubuntu-release- New binary: target-factory [riscv64] (jammy-proposed/universe) [1.4-5] (no packageset) === Mirv__ is now known as Mirv [16:02] -queuebot:#ubuntu-release- New: accepted target-factory [armhf] (jammy-proposed) [1.4-5] [16:02] -queuebot:#ubuntu-release- New: accepted target-factory [riscv64] (jammy-proposed) [1.4-5] [17:23] -queuebot:#ubuntu-release- New binary: libyang2 [amd64] (jammy-proposed/none) [2.0.7-1] (no packageset) [17:26] -queuebot:#ubuntu-release- New binary: stayrtr [ppc64el] (jammy-proposed/universe) [0.3.0-1] (no packageset) [17:26] -queuebot:#ubuntu-release- New binary: libyang2 [ppc64el] (jammy-proposed/universe) [2.0.7-1] (no packageset) [17:26] -queuebot:#ubuntu-release- New binary: stayrtr [amd64] (jammy-proposed/universe) [0.3.0-1] (no packageset) [17:27] -queuebot:#ubuntu-release- New binary: stayrtr [arm64] (jammy-proposed/universe) [0.3.0-1] (no packageset) [17:27] -queuebot:#ubuntu-release- New binary: stayrtr [armhf] (jammy-proposed/universe) [0.3.0-1] (no packageset) [17:31] -queuebot:#ubuntu-release- New binary: libyang2 [arm64] (jammy-proposed/universe) [2.0.7-1] (no packageset) [17:31] -queuebot:#ubuntu-release- New binary: libyang2 [armhf] (jammy-proposed/universe) [2.0.7-1] (no packageset) [17:35] -queuebot:#ubuntu-release- New binary: stayrtr [s390x] (jammy-proposed/universe) [0.3.0-1] (no packageset) [17:35] -queuebot:#ubuntu-release- New binary: libyang2 [riscv64] (jammy-proposed/universe) [2.0.7-1] (no packageset) [17:38] -queuebot:#ubuntu-release- New: accepted libyang2 [arm64] (jammy-proposed) [2.0.7-1] [17:38] -queuebot:#ubuntu-release- New: accepted libyang2 [ppc64el] (jammy-proposed) [2.0.7-1] [17:38] -queuebot:#ubuntu-release- New: accepted stayrtr [amd64] (jammy-proposed) [0.3.0-1] [17:38] -queuebot:#ubuntu-release- New: accepted stayrtr [armhf] (jammy-proposed) [0.3.0-1] [17:38] -queuebot:#ubuntu-release- New: accepted libyang2 [armhf] (jammy-proposed) [2.0.7-1] [17:38] -queuebot:#ubuntu-release- New: accepted stayrtr [arm64] (jammy-proposed) [0.3.0-1] [17:38] -queuebot:#ubuntu-release- New: accepted libyang2 [riscv64] (jammy-proposed) [2.0.7-1] [17:38] -queuebot:#ubuntu-release- New: accepted stayrtr [s390x] (jammy-proposed) [0.3.0-1] [17:38] -queuebot:#ubuntu-release- New: accepted libyang2 [amd64] (jammy-proposed) [2.0.7-1] [17:38] -queuebot:#ubuntu-release- New: accepted stayrtr [ppc64el] (jammy-proposed) [0.3.0-1] [17:44] ginggs: joy; hdf5 ftbfs on s390x in Ubuntu but not in Debian, and blocks r-bioc transition [17:52] juliank: I don't have time to dig into it further, but I notice i386 test queue is draining much more slowly than others, including more slowly than amd64; under normal circumstances I would expect it to drain faster because many of the dispatched tests would fail early with uninstallibilities [17:54] juliank: (recent example: https://autopkgtest.ubuntu.com/packages/dipy/jammy/i386) [17:55] 5 minutes to set up the testbed... possibly a problem of stale base images? [18:11] vorlon: negative, image is up-to-date [18:14] it might take time to setup the vm [18:51] juliank: well, the log I looked at showed it upgrading e2fsprogs (which was uploaded today) and therefore triggering an initramfs regeneration; the image might not be >= 1 day out of date but we are paying some costs there [18:52] perhaps not worth the effort of trying to manually fix, but still notable under current conditions [18:59] vorlon: ah yes, we need to s/zstd/lz4/ in the conf [19:00] vorlon: really need to have kernel benchmark sensible zstd level and find better tradeoff [19:00] we compress them at highest level, making it as slow as xz or slower [19:00] just decompress really fast [19:00] would like closer to gzip compression speed [19:01] and yes, when I looked at the images building, we spent all that time in the zstd binary [21:24] juliank: omg yes please [21:24] the single slowest step of a subiquity test install is compressing the initrf [21:24] *initrd [21:25] mwhudson: file a bug and assign it to the kernel team, asking for testing on more reasonable levels of compression :D [21:25] i guess it's initramfs-tools [21:25] but yes, we should i guess [21:25] mwhudson: yup [21:25] mwhudson: it hardcodes -19 because um well that decompresses fastest and is smallest: [21:26] zstd)▸ compress="zstd -q -19 -T0" ;; [21:26] I think it was at about -15 or so I found the sweet spot [21:26] i wonder what the mean number of boots per initramfs compression is [21:26] for me it's not much more than 1 i suspect [21:26] for users of stable series it probably is 1? [21:27] or less boots than initramfs if they use livepatch [21:28] we could do evil things like compress harder for cloud images [21:28] although i guess lots of them don't have an initrd anyway [22:58] vorlon: If you have a cycle and wouldn't mind, I have been pushing updates to the ubuntustudio seed removing "publishing" and "fonts" from the dvd-live seed, yet it's still showing up in the image somehow. I suspect the same problem as before. [22:59] Eickmeyer[m]: well before the only problem was racing the archive publisher? [23:00] vorlon: I don't remember that being the issue, but what I'm seeing is that what is pushed is not necessarily what is showing up in the image. The most recent changes should have eliminated a lot from the image. [23:00] Yet, they're still showing up in the daily. [23:30] -queuebot:#ubuntu-release- New binary: python-tomli [amd64] (jammy-proposed/universe) [1.2.2-2] (no packageset) [23:31] -queuebot:#ubuntu-release- New binary: bazel-rules-java [amd64] (jammy-proposed/universe) [0.1.1-1] (no packageset)