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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
