I was on my first +1 maintenance shift last week. I began the week with some reading of +1 reports
of the past shifts, to get a basic idea of what to do and how to do it.
First thing, I re-triggered tests related to a proposed migration excuse bug that I had fixed just before my +1 began:
- onionshare vs. python3-werkzeug
- lektor vs. python3-werkzeug
They passed. But I learnt that a prior run had also passed and python3-werkzeug was no longer blocked.
I ran the find-proposed-cluster script from the ubuntu-archive tools package. Though I was
aware of the python3 and perl transition clusters in noble-proposed, I was curious about the script output.
I realize that universe packages are the primary target of +1 shifts. But because the Perl & Python migrations are critical at this moment, I decided to split my time between universe packages, Python 3.12 migration excuses and Perl 5.38 migration excuses.
The package produces two binaries, only one of which is Perl-based. The autopkgtests failed because a new upstream release brings in a new PHP-dependency, for the other binary. This didn’t seem like Perl-blocker. I wrote up a bug report. I later realized that vorlon triggered autopkgtests with the right targets and cleaned this up from the list.
I investigated an autopkgtest failure which is reported on arm64, but failed intermittently on my amd64 setup too. Its a flaky test that depends on the output of the
ps command. I think it has now been marked as a badtest (through a different investigation by vorlon/ginggs).
The failing autopkgtests indicated a disutils dependency. I filed a bug report and was trying to backport an upstream change when I realised that faiss fails to build from source in noble. Most likely it is the swig 4.2.0 (now released) that does not generate a couple of faiss’ Python bindings. I filed an Ubuntu bug report (a Debian report exists) and an upstream bug report.
Autopkgtests for flye failed because the Python 3.12 removed support for find_module(), replacing it with find_spec() for path-based module finders. A vendor’d dependency of flye uses find_module() which fails to load a module causing an import failure. I submitted an upstream pull-request. While filing a Debian bug report, I realized that a new package release with the vendor’d dependency removed was done on the same day. This package is no longer a blocker.
The freedombox package depends on bootstrapform. Autopkgtests of the former fail because the latter imports distutils. I did a Debian merge request to replace distutils.StrictVersion with packaging.Version. But I now see bootstrapform also failing, independent of this MR, with Python 3.12. Test pipelines on the MR are failing and this needs more investigation.
This needs a migration from package “imp”, which was purged in Python 3.12, to package “importlib”. I submitted a Debian merge request for it.
An autopkgtest of factory-boy, evidently picks up zero tests to run, at least since the past four releases. In Python 3.12, the behaviour of package “unittest” was modified to return failure (exit code 5) if zero tests were selected. As a result, the factory-boy autopkgtest began failing. I submitted a Debian merge request .
Autopkgtests fail because a new upstream change causes uncaught exceptions which bring down the ccache utility with a SIGABRT. Interestingly, the test which core-dumps is deemed as passed, but the core-dump messages on stderr cause tests to fail.
I started a discussion on the upstream repository, which was later accepted as a bug and there is a fix committed. The upstream maintainer, who also happens to maintain the Debian package mentioned on the Debian bug report  that the fix will be out through a new upstream release next week. I also have a merge-proposal with a work-around.
This package represents an asterisk module related to speech synthesis. The failing test just tried to load the module into asterisk, but failed. I have an Ubuntu merge proposal as well as a Debian merge request for this. Please read the connected bug reports for more details.
It was a nice experience. Given my limited experience with distro packages prior to this shift, I must say I learnt a lot!
Thanks for reading!