+1 Maintenance report from April 6 to April 10, 2026
Busy week with Resolute Raccoon entering Final Freeze very soon, so this was effectively a half-shift while I was distracted with Desktop duties.
I have unblocked a few FTBFS and Proposed Migration (“PM”) issues.
I have also uncovered an issue with dpkg which breaks builds using the mingw toolchain.
Work-needed items
- dxvk / dpkg: I only managed to debug the issue, but I don’t have a proposed solution yet.
Sponsorship needed
- weston: needs to be synced from Debian unstable.
Full logs
FTBFS: libmediaart: regression from the new gdk-pixbuf, which now refuses to save pixbufs with an alpha channel as JPEG files, whereas previously it silently dropped the alpha channel without complaining.
There is an open merge-request upstream to switch libmediaart to a different image loading library, glycin, which has better APIs for dealing with pixel formats and avoid this problem. I proposed backporting this patch, and requested a FFe for resolute.
The FFe was granted (thank you Graham) and the package uploaded to Debian and Ubuntu (thank you Seb for sponsoring).
FTBFS: libpeas: regression from the new pygobject. A test-case was probably too strict, assuming some internals of pygobject. A diff was proposed upstream to adapt the test (although this specific assertion could probably be dropped instead). I have uploaded the proposed diff from upstream to Ubuntu, and forwarded it to Debian.
devops: autopkgtest: contributed a little QoL improvement for running foreign-architecture testing, which Paride rewrote and committed.
PM: libsdl3: both an autopkgtest misconfiguration and an issue with foreign-architecture testing.
One of the tests is relying on libudev1 being installed for dlopen’ing, but it was not explicitly listed as a dependency. On native architectures this is always already installed (as a dependency of the essential package util-linux), but in foreign-architecture testing like i386 that is not the case.
The most immediate solution would to explicitly add libudev1 as an autopkgtest dependency; but this uncovered a second issue where autopkgtest resolves its Depends stanza against the host architecture and not the test architecture, except binary packages built by the target source package.
After brainstorming with other Ubuntu devs (thank you Seb and Paride) and the Debian maintainer for SDL3, we found that we could add a libudev1 dependency to the libsdl3-tests package, which is a binary built from src:libsdl3 and is specifically used for running autopkgtests: this way the dependency does get resolved with the right architecture.
The change was uploaded to Ubuntu (thank you Seb for sponsoring), and later to Debian where we’ll sync back next cycle.
PM: weston: the Vulkan renderer was disabled on armhf because it was found to be broken, but it was still being tested at autopkgtest time which was preventing migration.
I adjusted the autopkgtest rules to always test the same feature set enabled at build time.
The Debian maintainer uploaded this to unstable, and it needs syncing to Ubuntu.
PM: cosign / gitsign / sigstore-go: Unblocked migration by retrying autopkgtests.
PM + FTBFS: dxvk: The new --package-metadata linker option passed by dpkg is not recognised by the mingw linker, which makes the dxvk build fail.
This is both a FTBFS and a proposed-migration issue since some architectures managed to get a build done before the dpkg update while amd64v3 didn’t. Today, all architectures would fail to build.
This topic still needs ideas for a solution, preferably one that does not involve simply stripping the bad flag from LDFLAGS in the debian/rules of every individual mingw package.