Hi there,
I was on my second +1 maintenance shift last week. I spent most of my time working through the update_excuses page from time to time. I spent some time analyzing package-revdep pairs from the non-amd64-nbs list, but couldn’t derive the kind of conclusions that I expected to (I must admit that I learnt to think more clearly about NBS in the process).
I list the universe packages that I picked up from the update_excuses regressions and my work on each of them.
=== siconos ===
I came across this package in the NBS list. Tests that use the Python interface fail with 4.4.0+dfsg-4build1 because the Python interface isn’t installed (though it is generated), making it akin to FTBFS. I filed a bug report [1]. The upstream setup.py depends on distutils and needs to be migrated to use setuptools, for which I submitted a merge proposal [2]. The bug report has been marked ‘wont fix’ and siconos binaries removed from noble.
[1] Bug #2061719 “Python interface is not installed with 4.4.0+dfsg...” : Bugs : siconos package : Ubuntu
[2] Merge into ubuntu/devel : fix-2061719 : lp:~pushkarnk/ubuntu/+source/siconos : Git : Code : siconos package : Ubuntu
=== ogre-next ===
Upstream changes to ogre-next, that apparently enable ogre projects co-exist with ogre-next projects, led to a massive clean-up of debian/rules in version 2.3.3+dfsg-0ubuntu1. The previous version let cmake find OGRE-Next projects by installing a patched .cmake file, which was removed by the latest version. I submitted a bug report [4] and a simple merge proposal [5]. I later withdrew the MP in favor of another MP [6], submitted a few hours before [5].
[4] Bug #2062378 “Autopkgtests fail with version 2.3.3+dfsg-0ubuntu1...” : Bugs : ogre-next package : Ubuntu
[5] https://code.launchpad.net/~pushkarnk/ubuntu/+source/ogre-next/+git/ogre-next/+merge/464628
[6] Merge into ubuntu/devel : ubuntu/devel : lp:~j-rivero/ubuntu/+source/ogre-next : Git : Code : ogre-next package : Ubuntu
=== nodejs ===
I found the nodejs autopkgtests failing because of a stale python3-distutils dependency in debian/control/tests. Reported the bug [7] and submitted an MP [8]. Thanks bdrung for sponsoring.
[7] Bug #2061946 “nodejs autopkgtests fail due to a python3-distutil...” : Bugs : nodejs package : Ubuntu
[8] Merge into ubuntu/devel : fix-2061946 : lp:~pushkarnk/ubuntu/+source/nodejs : Git : Code : nodejs package : Ubuntu
=== dgit ====
With version 11.7, the manpages-format test fails because it cannot find the tag2upload.5 manpage installed by the git-debpush binary. On investigation, I found tag2upload.5.gz being wrongly installed under man1 (instead of man5). I created a bug report [9] and found a Debian commit [10] that fixes this issue in version 11.8. It might be worth keeping [9] open until we sync with the latest version (11.9 for now) in Debian.
[9] Bug #2062955 “autopkgtest failure with version 11.7” : Bugs : dgit package : Ubuntu
[10] https://salsa.debian.org/dgit-team/dgit/-/commit/7e33c8decf6438727a5b2fe15443b3c2f8f1cd43
=== tcpxtract ===
This is an interesting case where an assertion failure can be consistently reproduced on arm64, albeit only with the 1.0.1-17ubuntu1 binaries in the proposed pocket (as of today). The test command is a simple one and I cannot reproduce the failure locally (noble/arm64 on Pi5). Created a bug report [11]. Ran out of guesswork here (maybe I am missing something very fundamental)!
[11] Bug #2063015 “autopkgtest fails with version 1.0.1-17ubuntu1 " : Bugs : tcpxtract package : Ubuntu
Other than the above investigations, I also did some autopkgtest requests with the right targets, to get things off the update_excuses list:
pyfai vs. pocl/5.0-2.1build3, which also needed silx/2.0.0+dfsg-1build1
dotnet8 vs. ltt-control -
gnucobol vs. gmp
nauty vs. gmp
normaliz vs. gmp
debcong/1.5.86ubuntu1 vs. rsyslog/8.2312.0-3ubuntu9
python-eventlet vs cinder
As a part of the NBS investigations, I looked into the following package-revdep pairs,
thanks to a guidance document from doko:
libpcap0.8 vs. aircrack-ng - thanks to schopin!
libcups2 vs. libqt5printsupport5t64
libcups2 vs. libqt6printsupport6
libcups2 vs. libqt6printsupport6t64
libcups2 vs. openjdk-8-jre-headless
jdupes vs. libjodycode
libgeoip1 vs. geoip-database
libgeoip1 vs. python3-geoip
libgeoip1 vs. subnetcalc
Thank you!
Pushkar
p.s: Apologies for not using markdown