On Sun, 16 Jul 2023 at 18:18:09 +0100, Simon McVittie wrote: > On Sun, 16 Jul 2023 at 18:55:28 +0200, Sebastian Ramacher wrote: > > Could you check whether that is an issue in sdl12-compat or > > libsdl-perl? > > I already opened <https://bugs.debian.org/1041211> and marked it as > blocking this transition-tracker bug.
After talking to SDL upstream, it looks as though libsdl-perl was always doing something that ought to be undefined behaviour (freeing the global video surface object, which is "owned" by the SDL video implementation), but an implementation quirk of libsdl1.2 meant that attempting to free the global video surface was silently ignored. The regression with sdl12-compat is because sdl12-compat is more likely to deallocate the global video surface and allocate a new one, whereas libsdl1.2 would usually keep using the same global video surface for the lifetime of the process, even if parameters like the colour depth changed. Possible solutions to continue this transition: 1. fix libsdl-perl (#1041211, RC; I sent a potential patch upstream, but I've never tried writing Perl XS bindings before, so I'm not very confident that I'm getting it right) 2. work around the issue in sdl12-compat because they aim for bug-for-bug compatibility (#1041416, wishlist, also forwarded upstream), after which #1041211 can be downgraded to non-RC 3. kick out libsdl-perl, dizzy, frozen-bubble and pangzero from testing until at least one of those two bugs can be fixed (I've checked with `dak rm -R -n -s testing` that those four source packages would be enough) Or wait until one of those happens, and if we wait long enough with no progress, autoremovals will implement (3) for us. smcv