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
