I did a +1 shift during the past week. In the past I typically tried to work on large changes (e.g. transitions) during such weeks but with amd64 test runners not working, that would have been difficult. Instead I started from the bottom of excuses (although, for obscure reasons, I wasn't looking at the whole list).
Nevertheless, as usual, I started by re-triggering tests, especially since queues were empty (or at least emptying for amd64). On that note, after amd64 queues become empty, I then reported issues for ppc64el and s390x! Still, at the end of the week, things appear to be working well enough. BTW, I organised the text below in sections: Solved, Need sponsoring, and Investigated. # Solved ## xhmtml2pdf New tests in the latest version fetch files over HTTPS but the code doesn't support proxies. Graham beat me to it and disabled the tests in https://launchpad.net/ubuntu/+source/xhtml2pdf/0.2.15+dfsg-2ubuntu1 I created a PR upstream to skip the tests but only when a proxy is detected: https://github.com/xhtml2pdf/xhtml2pdf/pull/793 ## dojo Removed from testing because it was preventing rhino from migrating and I was preparing to ask for removal but there were reverse-dependencies so I started investigating. It turns out that there must have been an ABI change in rhino and a no-change rebuild of dojo fixes the issues. https://code.launchpad.net/~adrien/ubuntu/+source/dojo/+git/dojo/+merge/480004 ## r-cran-spacetime I worked on that and added r-cran-tibble as a dependency for tests but it got uploaded in Debian first with 1.3-2-2. The fix was the same but there was an additional change too which makes me think that Suggests: for r-cran packages may be automatically derived from the 'DESCRIPTION' file which I was not going to guess (but maybe there's documentation for that somewhere) ## armci-mpi Asked to retry build (related to openmpi and its recent transition?). Thanks sudip! It failed again, probably the builder crashing due to OOM. It turns out a testcase requires more than 17GB of memory to run (and an unknown amount of time because I lost patience after 30 minutes of no progress). Made a change to disable that testcase. https://code.launchpad.net/~adrien/ubuntu/+source/armci-mpi/+git/armci-mpi/+merge/479991 Further investigation has shown that this happens with LTO with recent toolchains (probably only in plucky) but the affected codepath is only for debugging and upstream advised to just skip the testcase. https://github.com/pmodels/armci-mpi/issues/56 # Need sponsoring (possibly under review) ## kakoune FTBFS due to OOM due to LTO. Disabled LTO and proposed that in Debian too but the packaging there seems little active and I don't know if it's likely to be picked up. https://code.launchpad.net/~adrien/ubuntu/+source/kakoune/+git/kakoune/+merge/479992 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093860 ## libnftnl/iptables Test failures in iptables, blocks nftables. There has been an more recent of iptables to Debian so will merge that and see if it helps. https://code.launchpad.net/~adrien/ubuntu/+source/iptables/+git/iptables/+merge/480036 NOTE: these packages are actually owned by the security team, I had assumed libnftnl was in universe; Vladimir made some interesting comments in the MR so someone from the security team could take a look # Investigated ## libunwind (but I don't think there's something to do) FTBFS on arm64, several issues filed in Debian, and apparently a new version should fix them but it hadn't been uploaded so far. Opened an LP bug and tagged it update-excuse: https://bugs.launchpad.net/debian/+source/libunwind/+bug/2095325 Then the version got uploaded and sync. There is still an FTBFS on arm64. I didn't look in depth at the current arm64 FTBFS. ## emscripten (but I don't think there's something to do) There was a wrong path in d/t/control for a file shipped by the package: "tests" instead of "test". Something else too. However the most important part is that emscripten is coupled with LLVM, and wants a very very recent (i.e. tip) LLVM. This is why there are message such as the one below: > emcc: warning: LLVM version for clang executable "/usr/bin/clang-19" appears > incorrect (seeing "19.1", expected "20") [-Wversion-check] The 'expected "20"' is decided by upstream. LLVM 20 is definitely not released yet (and even less back in September when this version of emscripten was uploaded). Upstream wants to support released LLVM version but it is a long endeavour: https://github.com/emscripten-core/emscripten/discussions/22656 There are a bunch of changes in salsa but not released. Aiming for LLVM 19 it seems but probably still WIP. If someone needs to tackle this, make sure to look at salsa first. -- Adrien -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
