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.
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel