I was on +1 maintenance this week. I'm on PTO today/tomorrow, so sending my
report now.
High-level feedback from me on how proposed is going: we are in very good
shape for the cycle. We have several years of history now on queue sizes
and "backlog" (package count x time stuck) at
https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.csv
and compared to the past couple of cycles, we are in much better shape now
than we had been at the same point - and that's ignoring the fact that we
recently (post-jammy) fixed how we track the "age" of packages to not reset
on a new release. There are only 3 packages stuck in -proposed for over 200
days, and only 19 packages that have been stuck for more than 100 days.
Nice work, everyone who's contributed! I would say that from the Release
Team / Archive Team side, this has been one of the easiest cycles ever in
terms of managing devel-proposed.
Details:
* Looked at bootstrapping `crystal` which has a self-build-dependency.
The Debian unstable binary isn't installable because `libevent` has a
different package name in Debian vs Ubuntu. Turns out @zhsj patched libevent
in Debian to not break ABI. Merged this from Debian to restore package
dependency compatibility, then requested a bootstrap build against the
now-installable Debian binary.
* Had a second thought about the `libevent` implementation, decided this
should be a transitional package for the upgrade from kinetic to lunar
instead of a `Provides`. Reuploaded.
* Groomed the NBS list; contacted Till about sourceful changes required to
the two packages referencing `libcupsfilters1` (because he's the maintainer
of both). Those packages are now in -proposed awaiting autopkgtest results.
With this and `libevent` resolved, we'll be down to 0 NBS packages for lunar.
* took another brief look at `nthash`. FTBFS (regression) on riscv64 in its
own right due to non-portable references to atomic function implementations.
blocked on s390x because `btllib` build-depends on `libomp-dev` from llvm,
which has not been ported to s390x (a brief attempt to address this at
https://launchpad.net/~vorlon/+archive/ubuntu/ppa/+build/25686061, but
ultimately requires s390x assembly coding which I'm not touching. And it
FTBFS on armhf due to test timeouts; it would be reasonable to raise the
timeouts or skip the tests on this slower arch, but as that's the only
change that's particularly tractable and wouldn't unblock, I'm not spending
effort on it currently.
* looked at `node-address` autopkgtest failure on ppc64el. Appears to be a
genuine upstream regression, and is probably cross-architecture but happens
to only trigger on ppc64el because of coincidental idiosyncracies of device
naming on the testbed for ppc64el. Not trivially reproducible and packaging
all of NPM in Ubuntu is uninteresting, so punting.
* `kgb-bot`: package in release pocket FTBFS the same way (since the package
in -proposed is a no-change rebuild). Reproducible locally, so is not
caused by a proxy configuration or network issue. The build failure is not
reproducible in a Debian chroot. Thanks to a hint from @juliank, learned
about `apt build-dep -s` which can be used to find out which packages apt
would install as build-dependencies, with version numbers, to ease
comparison of build-deps between Debian and Ubuntu. After eliminating all
the interesting package version differences in the perl build-deps between
Debian and Ubuntu (i.e., any differences that are not due to no-change
rebuilds), the package still FTBFS in Ubuntu. So unfortunately I had to dig
down into what the test suite was actually doing. Ultimately strace seemed
the best tool for cutting through the various layers, and showed me an error
that:
I had a problem posting to event json_request of session KGB for DIR
handler '^/json-rpc'. As reported by Kernel: 'No such file or directory',
perhaps the session name is spelled incorrectly for this handler? at
/usr/share/perl5/POE/Session.pm line 483
and the immediately prior syscall is wait4() which fails, as this process has
never spawned a subprocess anyway. And an attempt to get a stack trace out
of perl shows nothing but POE::Kernel functions, and `libpoe-kernel` isn't even
one of the packages that was at a different version between Debian and Ubuntu.
So at this point I've given up.
* `sc-im`: FTBFS, sponsored a fix from the Debian maintainer (@ItzSwirlz)
* `bettercap-caplets`: uninstallable because it depends on `bettercap-ui`
which is in the Debian NEW queue. Ignoring for now, but if someone wanted it
removed and out of the way, we could remove it and add it to extra-removals
so that it got pulled back in once bettercap-ui is available.
* `nextepc`: confirmed that the ppc64el ftbfs is caused by a compiler issue
incorrectly calculating object sizes when identifying overflows
(-Werror=stringop-overflow), seen on ppc64el in several cases. Filed
[LP:
#2013140](https://bugs.launchpad.net/ubuntu/+source/gcc-12/+bug/2013140)
for this.
* `obexpushd`: FTBFS, references an obsolete linux header, has a Debian
bug open about it failing to build since *2018*, not in the past two Debian
stable releases or in testing, and I don't think anyone has used OBEX as a
protocol since Android was created. Removed.
* `aws-checksums`: build-depends on package that doesn't exist, even in the
Debian NEW queue. https://bugs.debian.org/1029332 is open about this.
Removed from lunar-proposed and added to extra-removals so it can come back
if its dependency appears.
* `ruby-rackup`, `ruby-rack-session`: build-depend on `ruby-rack` from
experimental that we're not going to sync for lunar. No good way to remove
these and track that they get back, so leaving in -proposed.
* `x-loader`, brings back memories from the early days of Ubuntu ARM
enablement. Originally an Ubuntu package, it was copied to Debian in 2012
and was never rebuilt since. The new version fails to build, but this is
an early boot package that is only useful on OMAP-based boards that we
haven't supported in a long time so not worth fixing. Removed.
* `rust-snapbox`: depends on obsolete rust packages,
https://bugs.debian.org/1029331. Removed.
* `fpga-icestorm`: autopkgtest regression, reproducible in Debian but there
the baseline regressed and the regression was allowed into the release. The
test is failing on invocation of a command in a different package, so marking
as a badtest and letting migrate.
* `wtforms-alchemy`: new package, requires newer python3-sqlalchemy to build.
Not something to be touched post-FF, leaving it for the next cycle. Opened
an [update-excuse bug](https://bugs.launchpad.net/bugs/2013156).
* `wtforms-json`: build-depends on `wtforms-alchemy`, self explanatory.
* `papi`: FTBFS only on ppc64el, builds when LTO is disabled. Patched,
uploaded, submitted to Debian.
* `wtdbg2`: Debian maintainer dropped all archs except for amd64, and this
has migrated to Debian testing. Followed suit.
* `eye`: build-depends on newer `swi-prolog-nox` than we have;
`swi-prolog` hasn't been merged since March 2022. Since there are only
three reverse-build-deps, I went ahead and merged it. This should be
low-risk for lunar buildability as the other reverse-dependencies are in
sync with Debian unstable and have no reported build failures.
* oh, except `logol` depends on libswipl.so.8, which is somehow NOT
one of the virtual packages provided, and therefore has autopkgtests
that correctly break because now we have libswipl.so.9. Filed [a
bug](https://bugs.debian.org/1033636) against `swi-prolog` in Debian for this.
* `clasp`: ftbfs on s390x only with a regression in the test suite. skipped
for now.
* `libprotocol-http2-perl`: existing ftbfs in lunar release as well. Does not
fail in Debian. No significant differences in versions of build-deps between
lunar and unstable. Skipped.
* `azure-functions-devops-build`: depends on `azure-cli` which is blacklisted.
Added this to the blacklist and removed from -proposed and the release pocket,
since this is an unsatisfiable build-dep for the release version also.
* `libpoe-component-server-simplehttp-perl`: FTBFS with the same
`libpoe-kernel` error as `kgb-bot`. Skipped.
* `r-cran-gstat`: s390x build dep-wait on `r-cran-lwgeom` because its new
build-dep `r-cran-stars` depends on it. The s390x binary was removed in
Debian, so followed suit.
* `github-backup`: FTBFS in release pocket and in Debian unstable with
undeclared build-dependency on an old libghc-github-dev. Not in Debian
testing; removed from -proposed and the release pocket.
* `otf2`: regressed in riscv64 support because it expects gcc atomics and isn't
finding them. Pinged @xypron for advice. The answer is we need to explicitly
link to `-latomic`; added this to debian/rules rather than hacking upstream m4,
and forwarded to Debian.
* `elementpath`: regresses autopkgtests, being worked out in
[Debian](https://bugs.debian.org/1027439).
* `vectorscan`: blocked because ppc64el was removed, but this is reverted in
unstable. Synced new version.
* `mailman3`: autopkgtest fails on ppc64el, but this package was removed
from the release pocket so this is not a true autopkgtest regression. Also
it's an arch: all package but the test only fails on one arch, so likely
still a timing issue. Hinted.
* `rust-document-features` build-depends on `dh-sequence-cargo`, a virtual
package provided by `dh-cargo` 30 in Debian but not version 28 that we have.
This is not for merging post-FF. Next release cycle someone will need to
manually retry the package since dep-waits on virtual packages don't clear
automatically.
* `php-dompdf-svg-lib`: build-depends on horde which is blacklisted. Removed
and also blacklisted.
* `godot`: build failures also unresolved in Debian. Skipping.
* `newsboat`: gcc can't detect that a variable *won't* be used without
initialization so fails under -Werror. False positive, pass
-Wno-error=maybe-uninitialized and forward to Debian.
* `zulucrypt`: released in Debian because autopkgtests require machine
isolation and are therefore skipped. But these tests passed on the previous
Ubuntu version and now fail. Low confidence that this isn't a genuine
regression, so moving on.
* `meta-phosh`: depends on newer `gnome-calls` which is in Debian but hasn't
been merged. Leave for next cycle.
* `gmenuharness`: the single relevant change in the Debian update was to
add a symbol to the symbols file - a C++ template symbol that isn't emitted
on most Ubuntu archs. Marked the symbol optional, uploaded, forwarded to
Debian.
* `firefox-esr-mobile-config`: blacklisted with the rest of firefox debs.
* `libsigc++-3.0`: mess of template symbols being listed in symbols file,
causing build failures on various archs (specifically, LTO-enabled archs).
Patched, submitted to Debian.
* `cppad`: binary-indep build fails in Ubuntu and Debian. Removed from
-proposed, let the maintainer take care of it.
--
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@ubuntu.com vorlon@debian.org
