# rust-phf & friends Had to rebuild rust-pallete, which was an FTBFS Filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043222 and debian fixed it before I had to upload the package with a delta of our own.
Then rust-markup5ever was failing to build. Traced to rust-tendril failing to build. Fixed upstream in 0.4.3 (https://github.com/servo/tendril/issues/67), which also needs a newer rust-futf. Asked debian to update (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043295), which they did promptly before I uploaded to mantic (I was testing things in a ppa before to be sure), and that sorted the problem. # curl 8.2.1-1ubuntu1 DEP8 failure on ppc64el and s390x Added a retry loop right after slapd was restarted. Fixed in https://launchpad.net/ubuntu/+source/curl/8.2.1-1ubuntu2 and sent to debian via https://salsa.debian.org/debian/curl/-/merge_requests/17 # doxygen FTBFS, causing FTBFS in other packages too https://bugs.launchpad.net/ubuntu/+source/doxygen/+bug/2026834 I had seen this in a previous shift. Debian said they would update to the version that has the fix (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040864), but that didn't happen yet. I had two branches with options: a) 7 patches to make it work (https://git.launchpad.net/~ahasenack/ubuntu/+source/doxygen/tree/debian/patches?h=mantic-doxygen-cairo-compat) b) update to 1.9.7 (https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-update-doxygen unfinished) I ended up with (c): export env var to make cairo produce pdfs without the compressed block, having checked that's the only thing that cairo uses that variable for, CURRENTLY: https://git.launchpad.net/ubuntu/+source/fenics-dolfinx/tree/debian/rules#n166 I tried to avoid this, bug given it's the second shift I encounter this, I decided to go ahead. I hope doxygen gets updated to 1.9.7+ soon. # dolfin-mpc uninstallable packages $ sudo apt install libdolfinx-mpc0.6 -t mantic-proposed libdolfinx-mpc0.6 : Depends: libbasix0.6 (>= 0.6.0) but it is not installable Depends: libdolfinx-real0.6 (>= 1:0.6.0) but it is not installable E: Unable to correct problems, you have held broken packages. Needed a rebuild with fenics-basix 0.6, done: https://launchpad.net/ubuntu/+source/dolfinx-mpc/0.6.1-3build1 # fenics saga Many issues around this ecosystem. One looked simple, and was just a src:mshr rebuild. But that's an FTBFS with the newer src:cgal 5.6 (https://bugs.launchpad.net/ubuntu/+source/mshr/+bug/2030809). Checked upstream, and project looks dead. Filed a bug with debian (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043307), hoping for the best, and they fixed it in https://launchpad.net/ubuntu/+source/mshr/2019.2.0~git20200924.c27eb18+dfsg1-10 # rust-sequoia-ipc FTBFS Troubleshooting led to an ftbfs in src:rust-nettle-sys, which was caused by a src:rust-bindgen bug caused by LLVM-16. https://bugs.launchpad.net/ubuntu/+source/rust-sequoia-ipc/+bug/2030886 Applied the upstream patch to https://launchpad.net/ubuntu/+source/rust-bindgen/0.60.1-2ubuntu1 and uploaded, it's going through migration. Debian is unaffected because, at the time of this troubleshooting, they were still using LLVM-14. I did file https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043374, though. I subscribed to rust-bindgen in debian to be notified whenever they update or apply the patch, so this package can become a sync again. If you see rust-* tests failing and using rust-bindgen without the fix, retrigger them with rust-bindgen from mantic-proposed. I did so for a few and they became green. # rust-bindgen (my upload) migration It's blocked on an arm64-only dep8 failure in rust-loopdev/0.4.0-3: 819s ---- detach_a_backing_file_default stdout ---- 819s thread 'detach_a_backing_file_default' panicked at 'assertion failed: `(left == right)` 819s left: `0`, 819s right: `1`: there should be no loopback devices mounted', tests/integration_test.rs:176:5 I spent the whole afternoon today trying to get an arm64 mantic VM to troubleshoot this (it has to be a VM), but that was very difficult. canonistack isn't an option. My raspberry pi4 fails to launch a lxd VM (similar to https://github.com/canonical/lxd/issues/7191, but disabling secureboot didn't help: ~LXD is investigating). An arm64 MAAS server I have access to is a lottery to find a node that deploys, but eventually I got one that deployed, only to find out the error doesn't happen there. The only place where I reproduced it is in a PPA with the Canonical DEP8 infrastructure, which means the troubleshoot cycle is upload to ppa, wait for build/publish, trigger dep8, wait, repeat, so I didn't get very far in the time that was left. My thought is that perhaps in our arm64 dep8 vms, /dev/loop3 (hardcoded in the failing test) is perhaps taken, but changing it to another one didn't help. Then perhaps there is the 100ms sleep that the test has and that we might have to tweak. But that's just a thought. # haskell-gi-vte FTBFS https://launchpad.net/ubuntu/+source/haskell-gi-vte/2.91.30-1build4 FTBFS Didn't figure out what is going on. GI/Vte/Objects/Terminal.hs:1910:1: error: Could not load module ‘GI.Cairo.Structs.FontOptions’ It is a member of the hidden package ‘gi-cairo-1.0.27’. Perhaps you need to add ‘gi-cairo’ to the build-depends in your .cabal file. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 1910 | import qualified GI.Cairo.Structs.FontOptions as Cairo.FontOptions | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Filed https://bugs.launchpad.net/ubuntu/+source/haskell-gi-vte/+bug/2030910 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043385 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
