On 2023-07-20 12:56:16 +0100, Simon McVittie wrote: > 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.
Thanks for handling this issue. > 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) I added removal hints. The libsdl-perl maintainers should have enough time until the release of trixie to fix the bug and make it eligible to migrate back to testing. Cheers -- Sebastian Ramacher
