+1 Maintenance report from 2026-08-10 to 2026-08-14

I Started my +1 maintainance by reading the previous report from Renan Rodrigo .

Then, proceeded to check the FTBFS report
and the glibc 2.44 transition preparation test rebuild report.

Finally, I ran the find-proposed-cluster script in ubuntu-dev-tools. Here is the output:

$ ./find-proposed-cluster
rust-gix 48
rust-uucore 15
utop 15
ocamlformat 14
ben 13

The output above pointed us to several build issues with rust-gix and its
dependencies, and to the ongoing ocaml transition.

With all the preparation above, we have more than enough work for the +1 week.

Hector Cao and Grayson Wolf, both from the Ubuntu Server team, joined me for
the +1 this week. I showed them this initial investigation so no one would get
bored during our week.

Then, I started by going through the openssl4 transition tracker page. Looking at
forgejo-cli, and verifying that the forgejo-api package was removed from
Debian, since it was renamed to rust-forgejo-api. I requested removal in Ubuntu
as well (LP: #2163171).

As for the rust-forgejo-api source package, it depends on
librust-reqwest-0.12+rustls-dev, but this dependency does not exist. The new
rust-reqwest-0.12 source package provides librust-reqwest-0.12±-rustls-dev,
which seem to be what we need to depend on. This is also broken in debian.
After going through the matrix release team channel, I realized that the whole
rust ecosystem was going through some transition in Debian. I assessed that
handling rust dependency issues during this week would not be of much help,
based on the matrix discussions. It would be nice to revisit the forgejo
packages then.

Still on the openssl transition, the trantor source package has a hard-coded
dependency on openssl. I bumped the dependency to use openssl4 and filed a bug
in Debian so we can understand why we depend on libssl on Debian bug #1144077

Now, in the FTBFS report, I immediatelly spotted isc-dhcp there. This package
has been replaced by isc-kea as our DHCP server solution and was demoted from
main to universe in noble. This package was recently removed from Debian
unstable and I believe we should drop it from Ubuntu as well. Since we still
carry some reverse dependencies, I filed LP: #2163196 to track the removal.
This will require coordination among different teams and products and should be
viewed as a long term goal.

ruby-mysql2 was FTBFS in armhf. The reason for the failure was the lack of
mysql server in armhf. I merged the package and made some adjustments to skip
some build time checks in armhf. The package is still functional, but runs with
mariadb in that arch. One interesting find here: Ruby packages using dh_ruby
run their upstream test suite during package build time in dh_install. This has
been fixed since 2022, but only applies to debhelper compat 14. Now that
debhelper compat 14 is stable, if you ever need easily tweak with ruby build
time tests, bumping the package to use debhelper compat 14 seems to be the most
straightforward path.

2 Likes

+1 Maintenance report from Aug 10 2026 to Aug 14 2026

I shadowed Athos this week, and spent it mostly cleaning up various FTBFSs along
with the occasional universe merge. I also looked into the coq stack’s current state
of general mayhem.

Work-needed items

  • Much of the coq stack is failing to build as a result of rocq-stdlib building against the wrong version of coq and causing a hash
    mismatch. The rebuild has been requested and done, but now a lot of coq packages need manual retrying of builds:

    • coq-ext-lib 0.13.1-2
    • coq-stdpp 1.13.0-2
    • flocq 4.2.2-2
    • coq-menhirlib 20260209+ds-2
    • coq-record-update 0.3.7-3
    • coq-hott 9.1-2
    • coq-libhyps 5.0.0-2
    • coq-unimath 20260603-2
    • aac-tactics 9.0.0-4
    • rocq-micromega-plugin 1.1.1-1
      (the following three depend on at least one of the above)
    • coq-simple-io 1.11.0-5
    • coq-hierarchy-builder 1.10.3-2
    • coq-quickchick 2.2.0-2
      These packages should all build now that rocq-stdlib has been repaired (though some might have been retried already). Note this (probably) isn’t an exhaustive list, this is just the ones I saw while investigating.
  • The changes to pingus were since accepted by Debian, so my fresh delta can be dropped.

  • esstra pins its gcc-15-base dependency to the exact version it was built with. This makes the package uninstallable
    after every new gcc upload. This seems resolvable by changing the = to an >=, but the pin likely exists for a reason,
    so I’d rather not tear down Chesterton’s Fence without a fuller picture. (this was one of the last packages I looked at
    on Friday, so I didn’t have much time to investigate)

Sponsorship needed

The following need review/sponsorship:

  • openrct2: MP
  • haskell-hakyll: MP
  • bsdgames: MP
  • cauchy: MP
  • elixir-lang: MP
  • openbabel: MP

Full logs

  1. coq stack
    • Much of the Rocq (nĂ©e Coq) stack currently FTBFS, but the root cause was rocq-stlib building against the wrong
      version of coq. Since coq Provides a package whose name is derived from the ABI version, Neither rocq-stlib
      nor any of its dependents could find the correct version. A no-change rebuild got this back in order, so the rest
      of the stack can be set right by either waiting for dependency waits to automatically fall off or in some (many)
      cases manually rebuilding.
  2. pingus
    • This package had in its upstream makefile a race condition where multiple install -Ds hit the same directory, which
      currently fails on uutils. The makefile isn’t parallel safe to begin with, so I disabled parallel installs. This has
      been uploaded here and forwarded to Debian (who accepted it).
  3. openrct2
    • I actually started on this one a bit before my +1 shift, but since it’s still in the spirit of fixing up universe I’ll
      mention it here :).
    • The package used to FTBFS on amd64v3, so our delta fixing this kept us behind Debian.
    • I merged, which revealed another FTBFS issue which is the subject of the linked MP.
    • Ultimately, all the build failures can be traced back to upstream’s -Werror wreaking havoc downstream.
      A reviewer thought we should just drop -Werror instead of shotgun-patching arch-specific warnings over and
      over again. This has been forwarded to Debian, so if/when they accept we should be able to start syncing
      this package again.
    • You should play Rollercoaster Tycoon 2. It’s really fun.
  4. aribas
    • Very, very old (pre-ANSI) C here used true/false as variable names. This is newly(!) forbidden in gnu23 C, so
      the package failed to build. Changing the standard back to gnu17 resolved this, which has been both uploaded here
      and forwarded to Debian.
  5. haskell-hakyll
    • One of the upstream tests of this package (a static site generator in Haskell) ran head -# and checked that it failed.
      In an instance of Hyurm’s law It did this checking the text of the error message,
      which caused the test to fail (and the package to FTBFS) once we switched to uutils, which has a different error message.
      I patched this upstream (by checking for both coreutils implementations), and MPed the patch to Ubuntu.
    • I’m quite happy I was able to contribute to this package, since I myself have used Hakyll for a personal site for many years :).
  6. bsdgames
    • We have ELF metadata on by default. In this case, this was a problem, since the metadata contains % characters which upstream
      uses as a delimiter to generate sed. This caused the sed to be malformed and the package to fail. Turning off ELF metadata
      fixed the build.
  7. cauchy
    • Straightforward CMake 4 FTBFS, fixed by setting the minimum policy version in d/rules.
  8. elixir-lang
    • One of the build-time tests in this package symlinks echo to somewhere else, and then runs it with arg0 set to the original echo.
      UUtils-specific security hardening rejects this, so the test has been patched.
  9. esstra
    • This package pins its gcc-15-base dependency to exactly the version it was built with, meaning the package becomes uninstallable on
      every new gcc upload. The pin probably exists for a reason, so I left it be for now (see the work needed section).
  10. openbabel
    • This was another CMake 4 FTBFS, but this time Debian had already fixed it (we had delta), so I did the merge for this package.
  11. kakoune
    • We were quite out of date here (2024.05.18 vs Debian’s 2026.05.21), so I merged this package from Debian.
  12. kotlin
    • Our only delta here was a FTBFS fix for Java 25. Debian fixed this differently, so I requested a sync for this package, which was done.
1 Like

As Athos mentioned, I was shadowing Athos for +1 maintenance

Notes: I am also looking for sponsor for my MRs

FTBFS

qatzip:

I reported and proposed a fix upstream and debian; Upstream had a new version release 2.0 and Debian upgraded qatzip to this new version and synced to Ubuntu: 2.0.0-1 : qatzip package : Ubuntu

efibootguard:
Bug: Bug #2163183 “ftbfs on ubuntu stonking” : Bugs : efibootguard package : Ubuntu
MR: Merge into ubuntu/devel : lp2163183-stonking : lp:~hectorcao/ubuntu/+source/efibootguard : Git : Code : efibootguard package : Ubuntu

faketime
Bug: Bug #2163170 “ftbfs on ubuntu stonking due to new glibc” : Bugs : faketime package : Ubuntu
MR: Merge into ubuntu/devel : lp2163170-stonking : lp:~hectorcao/ubuntu/+source/faketime : Git : Code : faketime package : Ubuntu

rabbitmqadmin-ng

rabbitmqadmin-ng is a new Rust package and FTBFS because there is mismatch for its B-D versions and Rust version.
I sent 2 MRs to Debian and propose the fix here:

Bug: Bug #2163465 “ftbfs in ubuntu stonking due to dependency version...” : Bugs : rabbitmqadmin-ng package : Ubuntu
MR:

hyprland-qtutils

FTBFS but upstream repo has been archived, I decided not to fix it!

1 Like