+1 maintenance shift (07/AUG - 11/AUG)

Fri Aug 11 21:40:16 UTC 2023

# 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