+1 maintenance report: the reportening

[Steve Langasek]

Wound up not actually being out yesterday, so I got some more work done on
+1 maintenance.  So here's a second report!

* `rust-diesel`: uninstallable on armhf because it depends on packages not
built on any 32-bit arch.  Added a build-dependency on these packages, so
that the uninstallable binaries wouldn't be built; and forwarded to Debian
for consideration (either they should add the build-dependency or drop the
runtime dependency, either way).  [LP:
#2024059](https://bugs.launchpad.net/bugs/2024059)  However, it appears
`rust-diesel` has just started failing to build on all architectures, so I
filed [Debian bug #1038138](https://bugs.debian.org/1038138) for that and
removed the package from mantic-proposed.

* `maxima`: FTBFS on ppc64el, but not in Debian; so tried rebuilding `gcl`
with -O3 disabled but it still segfaulted.  Dumped some information in [bug
#2024061](https://bugs.launchpad.net/bugs/2024061) after trying a few more
things, and gave up.

* `cgreen`: unsatisfied versioned build-dependency on libbinutils; we had
done a no-change rebuild once before but this didn't manage to migrate?  So
trying again.  But also, it regressed in buildability on s390x, so filed
[Debian bug #1038145](https://bugs.debian.org/1038145) about this.

* `calligra`: build failure wasn't reproducible locally.  Retried and it
succeeded.

* `rust-sequoia-net`: unpick build-dep chain `rust-sequoia-openpgp` ->
`rust-nettle` -> `rust-nettle-sys`.  Current `rust-sequoia-openpgp` needs
the newer `rust-base64` in -proposed, but `rust-sequoia-net` needs the older
one.  Removed `rust-sequoia-net` from -proposed to let this settle out in
Debian.

* `python-cogent`: stuck in -proposed because Debian dropped 32-bit arch
support and we have armhf binaries left behind; removed the binaries.

* `eztrace`: [LP: #2016471](https://bugs.launchpad.net/bugs/2016471)
identified that the test was broken because `libomp` was built with
`-Bsymbolic-functions` but there was reluctance to disable this option.  It's
legitimate to build without `-Bsymbolic-functions` when a package in the
archive needs to intercept internal library calls.
[LP: #230460](https://bugs.launchpad.net/bugs/230460) is a prior example
of this from when the hardening flag was introduced.  Uploaded
`llvm-toolchain-15` with a targeted change to disable `-Bsymbolic-functions`
only for libomp, not for all of llvm.  But it somehow didn't work.  And
somehow rebuilding `llvm-toolchain-15` with no relevant changes also [now
fails](https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/26313388).
Giving up.

* `opm-simulators`: stuck because the riscv64 build had been cancelled.
Retriggered it, and it failed again with no build log.  Between this and the
changelog, seems like it might be OOMing the builders.  Opened [a
bug](https://bugs.launchpad.net/bugs/2024246).

* Retriggered autopkgtests for packages involved in the `r-base` transition.
There are packages not yet ready for the new `r-base`, but this makes clear
which ones those are.


-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                   https://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230616/807c0293/attachment.sig>