It would have been very easy to have spend my entire +1 shift on the Python 3.10 transition but as other people are actively working on that, I tried to look at other things too.
subversion fails on ppc64el because ruby uses gcc-10 on ppc64el and this leads to LTO-related failures. Apparently this will all become irrelevant when ruby3 is the default but I don't know what the ETA on that is.
zodbpickle breaks with python 3.10. There is a patch upstream but Debian seems way out of date and there are no reverse dependencies so it's a bit hard to care. Maybe I'll come back later in the week (I didn't).
siphashc is another package broken by python 3.10 with one upload in debian and no reverse dependencies.
sphinxbase ftbfs i think because python 3.10 added a deprecation warning to the distutils module. This turns out to be a problem from https://www.gnu.org/software/autoconf-archive/ax_python_devel.html. Graham uploaded a new version of autoconf-archive but sphinxbase still required some hacking to use the ax_python_devel.m4 from there. This migrated eventually.
pythonmagick also has autotools problems. I tried a local build with dh-autoreconf but that didn't seem to help. Graham uploaded some related things but then the package still doesn't work because it links the python3.9 extension to the python 3.10 version of the boost_python library for some reason.
h5py failed tests on armhf with a bus error (turned out this had been reported upstream already at https://github.com/h5py/h5py/issues/1927#issuecomment-963639147) This was an unaligned access that was easy to find on canonistack with gdb and I uploaded a simple patch to fix it and it built fine. The autopkgtests were very angry but not, afaict, particularly because of h5py, more just fallout from the python transition.
There were a few packages (eckit, fckit, metkit) that upstream no longer supported on 32 bit, so I got an AA to remove the lingering armhf binaries and they migrated.
supertuxkart ftbfs on arm because an assembly file used vfp instructions without passing an -march option or using a .arch directive to enable FPU instructions (something that only became necessary fairly recently). I patched it to use a .fpu directive (but maybe .arch would have been better -- oh well). It built and migrated after this.
ncurses was blocked by an autopkgtest failure in cunit. I found a patch in the Debian BTS fixing this so I nmu-ed this to debian's DELAYED/5 queue. We could upload this to Ubuntu as delta but it will end up in Ubuntu soon enough so I don't know if it's worth it.
I retried lots of r things, mostly successfully.
Something in the R stack had regressed on s390x (and probably all big endian systems). It showed up in r-cran-s2 and its dependencies, but I suspected the problem was actually in r-cran-wk (whose autopkgtests have never passed on s390x, sigh, so there was no reported regression for this package). After a bit of hunting I found the problem and filed https://github.com/paleolimbot/wk/issues/105 (spoiler, it may cause a laugh/snort, it certainly did for me). I uploaded the simple fix and it helped, with r-cran-wk itself migrating followed by a couple of other r packages.
Cheers,
mwh
