- LP: #2139441 Requested removal of raspberrypi-userland after verifying it’s obsolete (and replacement is in place)
- LP: #2142782 Sponsored wsl-pro-service package for @cnihelton
- LP: #2143894 Investigating FTBFS of yuzu on arm64; managed to get a build, but only by disabling several (probably important) tests
- LP: #2137565 Fixed FTBFS of ubiquity for flavours
- LP: #2140556 Patched kodi to build with ffmpeg8 (horrid patchset, but hopefully can ditch it all when kodi 22 arrives)
Investigated FTBFS of vera++. This turned out to be because boost1.90 was last built with both Python 3.13 and Python 3.14 available in the archive. Consequently, boost builds libboost-python with all available versions. In projects that use libboost-python they then link against the lowest version of libboost-python available. When Python 3.13 was dropped, boost needed a rebuild otherwise things building against libboost-python tried build against Python 3.14 and libboost-python-py313 (which then segfaulted the second libboost-python tried to do anything at runtime).
@ginggs kindly rebuilt boost1.90 with only Python3.14 support, and I spent a bit of extra time looking at the regressions from that. All but one turned out to be regressions just needing a NCR to build against libboost-python-py314, so I uploaded NCRs for:
- minieigen
- py3exiv2
- pybdsf
- pythonmagick
However, that leaves one more regression for ompl. This is armhf specific and is because tons of r-cran packages are now being built without armhf (no-32bit) and s390x (no-big-endian) support. Looks like @seb128 is working through rm’ing the fallout from that, and once r-cran-rsqlite disappears, ompl should migrate, allowing boost1.90 to migrate.