Tooling: I don't know what others do already, but for bulk no-change
rebuild uploads I left behind some of my usual one liners and put
together a couple of quick tools:
prep-rebuild: given a list of source packages, automate fetching,
bumping the changelog and preparing the upload. This leaves a pile of
changes files in the current directory ready to debsign and dput.
lp_build_status.py: some people might have already attempted no change
rebuilds, so if I look at the current state of things to get a list of
packages that look like they need a no change rebuild, I might be
duplicating effort and wasting build resources. This tool takes a list
of source packages, examines Launchpad, and lists any packages whose
highest versions are currently not built on amd64 for whatever reason
(eg. in the queue, build in progress, failed to build). This allows me
to remove these from my list of no-change rebuild uploads and
investigate these manually.
Get these from: https://git.launchpad.net/~ubuntu-server/+git/ubuntu-helpers/tree/rbasak
My running notes are below. It's getting late so I'm not going to polish
them up right now. If you need any more detail on anything, please ask.
boost
No change rebuilds uploaded:
ball
freecad
lgogdownloader
supercollider
FTBFS:
frogatto (fixed and uploaded)
slic3r-prusa (I didn't get to this but I see Graham has)
dep8 failures:
icinga2 - needs a hint? Further discussion at https://lists.ubuntu.com/archives/ubuntu-devel/2022-May/042051.html
libreoffice - since fixed in https://cgit.freedesktop.org/libreoffice/core/commit/sw/qa/uitest/writer_tests7/tdf144439.py?id=a31a7b53c42eef3a8007766c60ec5a2539054a7c and already uploaded and migrated so just needed retests
hilive - looks flaky but previous migration-reference reset attempts failed (ie. the test passed) so tried just a retry. This failed, so tried a migration-reference/0
pytest
beets arm64: seems to need net access. Not sure how it passed previously. Looked at s390x which already always fails for the same reason (plus one other). Submitted retry with trigger=migration-reference/0, but then jbicha kindly reminded me about Internet-requiring tests so I also just retried
einsteinpy arm64: looks like maybe the OOM killer. One spurious past in far history (Jammy). Submitted retry with trigger=migration-reference/0
These packages also needed resubmitting because they require Internet access:
fiat arm64
pandas arm64
pytest-doctestplus arm64
pytest-mpi arm64
python-cooler
python-css-parser
python-mechanicalsoup
rdflib
repo
snakemake
sphinx-astropy
sphinx-automodapi
python-parameterized i386: build depends on python3-nose which depends on python3-coverage which is not available on i386. Not sure why it worked previously in Hirsute, but don't think it will now, so submitted a migration-reference/0.
libzstd
ccache: armhf retest already pending
debspawn arm64 needed a retry due to needing Internet access
golang-github-valyala-gozstd looks like a genuine failure against the newer libzstd. I think this needs further investigation
octave
octave 6.4.0-2 Provides octave-abi-56 in the release pocket
octave 7.1.0-2 Provides octave-abi-57 in the proposed pocket
Submitted no change uploads
Added transition tracker for octave after getting some FTBFSs back and realising it needs multiple levels
octave is in dep-wait on riscv64 for libpetsc-real3.16-dev
Produced by src:petsc which FTBFS on riscv64
FTBFS is because of missing symbol SCOTCH_ParMETIS_V3_NodeND
On amd64 this is shipped in libptscotchparmetisv3-7.0.1.so in libptscotch-7.0_7.0.1-2_amd64.deb
Also available on riscv64
So why does the configure script not find it specifically on riscv64? Not sure but it's not looking in libptscotchparmetisv3.so at all. Looks like this was fixed in petsc upstream commit 3307d110e72ee4e6d2468971620073eb5ff93529 that hasn't been released yet. Upstream latest tag is v3.17.1. petsc is 3.16.6 in Ubuntu and Debian has 3.17.0+dfsg1-1exp1 in experimental.
petsc is currently built on all archs except riscv64, but a rebuild of amd64 fails for me locally.
Looks like this generally needs a deeper investigation. Upstream has a
very large number of recent commits. It might be easier just to wait for
them to release rather than patch up our older version.
