Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Wed, 21 Jun 2023 10:33:01 +0100, Simon McVittie wrote: > On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie > > wrote: > > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer > > > receives upstream maintenance or releases. Maintained software that > > > uses SDL 1.2 should be ported to SDL 2. > > > > Given the time scales involved, is it worth waiting for SDL 3 (soon...) > > before porting SDL 1.2 software? I’m assuming that SDL 3 will be available > > for Trixie, and this would avoid two porting efforts. > > I don't know what the timescale for a stable release of SDL 3 is like - > I hope it'll be ready before trixie, but I can't guarantee anything. Many > games will not be able to move to SDL 3 until additional libraries like > SDL2_image have a SDL 3 version, so even after everything is API-stable, > it's going to take several trips through NEW before we can ask maintainers > to port to it. > > The first step in porting from SDL 1.2 to SDL 3 will be porting to SDL 2 > (both the core library and the version of addons like SDL_image), and > the second step would be moving away from any deprecated SDL-2-era APIs, > so I think it's worth doing those regardless. Right, so in any case the effort involved in porting to SDL 2 won’t be “wasted” by a subsequent port to SDL 3. > What I would prefer to try to avoid here is for maintainers to think > "I'll just wait for SDL 3", and then time passes, maintainers are busy > with something else, we freeze, and we have to ship trixie with *three* > major versions of SDL (or at least their -compat equivalents). > > Ideally these bugs would have been opened in 2013 or 2014, but better late > than never. (I was not involved in SDL maintenance at that point.) Indeed! Regards, Stephen pgpCmvhueWNnW.pgp Description: OpenPGP digital signature
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to SDL 2. > > Given the time scales involved, is it worth waiting for SDL 3 (soon...) > before porting SDL 1.2 software? I’m assuming that SDL 3 will be available > for Trixie, and this would avoid two porting efforts. I don't know what the timescale for a stable release of SDL 3 is like - I hope it'll be ready before trixie, but I can't guarantee anything. Many games will not be able to move to SDL 3 until additional libraries like SDL2_image have a SDL 3 version, so even after everything is API-stable, it's going to take several trips through NEW before we can ask maintainers to port to it. The first step in porting from SDL 1.2 to SDL 3 will be porting to SDL 2 (both the core library and the version of addons like SDL_image), and the second step would be moving away from any deprecated SDL-2-era APIs, so I think it's worth doing those regardless. What I would prefer to try to avoid here is for maintainers to think "I'll just wait for SDL 3", and then time passes, maintainers are busy with something else, we freeze, and we have to ship trixie with *three* major versions of SDL (or at least their -compat equivalents). Ideally these bugs would have been opened in 2013 or 2014, but better late than never. (I was not involved in SDL maintenance at that point.) smcv
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
Hi Simon, On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > upstream maintenance or releases. Maintained software that uses SDL 1.2 > should be ported to SDL 2. Given the time scales involved, is it worth waiting for SDL 3 (soon...) before porting SDL 1.2 software? I’m assuming that SDL 3 will be available for Trixie, and this would avoid two porting efforts. Regards, Stephen pgpNOBwOwE0Bk.pgp Description: OpenPGP digital signature
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Tue, 13 Jun 2023 at 11:10:41 +0800, Paul Wise wrote: > On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to SDL 2. > > It was pointed out to me on IRC that some SDL 1.2 extension libraries > might not have an SDL 2 equivalent yet, or they might not be in Debian. ... > Looking through the packages, these appear to be missing: > > console kitchensink pango sge sound > > Perhaps there are better equivalents for these in SDL 2 though? -kitchensink is already a SDL-2-only library, despite its name and version number not containing a 2 (but it appears to have only one reverse-dependency, and is currently orphaned, so I wouldn't recommend relying on it). The SDL extension libraries that I've mainly been looking at are the ones maintained by the same upstream developers as SDL itself: -image, -mixer, -net and -ttf. Those all have maintained SDL 2 equivalents (or semi-maintained in the case of -net, which is IPv4-only and generally fairly obsolete - I believe the recommended replacement for software that wants IPv6 support is to use BSD-style socket APIs directly). Nothing in Debian depended on -console, and that has been true for quite some time, so I've asked for it to be removed from trixie. SDL 2 has a "render" API which might be quite close to being a replacement for -sge. libsdl2-gfx also seems to deal with the same general problem space. I'm not sure how the purpose of -sound differs from -mixer: they both seem to be primarily a convenience API for decoding and playing popular formats like MP3. You seem to have looked at -pango already. > Will the SDL team be packaging available SDL 2 equivalents for > the SDL 1.2 extension libraries that are in Debian? I can't speak for other SDL team members. I don't plan to package third-party SDL extension libraries (those not maintained by SDL upstream) myself, but interested maintainers of games that need them are very welcome to do so. I'm not intending to ask for the SDL 1.2 extension libraries to be removed unless they either get unfixed RC bugs, or reach a situation where no other Debian package depends on them - but I'm also not intending to maintain those myself, and part of the purpose of this MBF is to raise awareness that the whole SDL 1.2 ecosystem has been effectively dead for multiple years. > > For legacy software that cannot be ported, SDL upstream have produced a > > replacement library, sdl12-compat, which implements the SDL 1.2 API/ABI > > by dlopening SDL 2 (and correcting for API/ABI changes). In Debian, this > > is currently available as libsdl1.2-compat-shim. > > I tested hex-a-hop under GNOME Wayland. It segfaults with SDL 1.2 and > SDL_VIDEODRIVER=wayland "Classic" SDL 1.2 never had a Wayland backend, so that is not an interesting test-case: it is expected that games will crash or otherwise exit unsuccessfully when asked to use a backend that doesn't exist. SDL_VIDEODRIVER=wayland is only expected to work with SDL >= 2, either directly or via libsdl1.2-compat-shim. > When using the compat lib via LD_PRELOAD, the X11 mode has > a window title bar and border but those are missing in Wayland mode. libsdl2-2.0-0 Depends on libdecor-0-0, which Recommends libdecor-0-plugin-1-cairo | libdecor-0-plugin-1. If at least one libdecor plugin is available, then you should get a titlebar under native Wayland (in practice usually bold white text on a black background, with minimize/maximize/close buttons that light up orange/green/red on mouseover - that's the cairo plugin). openarena and chocolate-doom in windowed mode are examples of SDL2 games where I've verified that this works, and amoebax is an example of a SDL 1.2 game where this works while using libsdl1.2-compat-shim. If Recommends are not installed, then as per Policy §7.2 you have an unusual installation and can expect to see reduced functionality. smcv
Re: Mass bug filing / call for testing: dependencies on SDL 1.2
On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote:
> SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives
> upstream maintenance or releases. Maintained software that uses SDL 1.2
> should be ported to SDL 2.
It was pointed out to me on IRC that some SDL 1.2 extension libraries
might not have an SDL 2 equivalent yet, or they might not be in Debian.
For example hex-a-hop can use SDL_ttf or SDL_Pango. Pango is a more
featureful text renderer, so the Debian package uses it. There is an
SDL2_Pango project available on GitHub but it isn't in Debian yet.
https://github.com/markuskimius/SDL2_Pango
Looking through the packages, these appear to be missing:
console kitchensink pango sge sound
Perhaps there are better equivalents for these in SDL 2 though?
Will the SDL team be packaging available SDL 2 equivalents for
the SDL 1.2 extension libraries that are in Debian?
> For legacy software that cannot be ported, SDL upstream have produced a
> replacement library, sdl12-compat, which implements the SDL 1.2 API/ABI
> by dlopening SDL 2 (and correcting for API/ABI changes). In Debian, this
> is currently available as libsdl1.2-compat-shim.
I tested hex-a-hop under GNOME Wayland. It segfaults with SDL 1.2 and
SDL_VIDEODRIVER=wayland but does not with the SDL 1.2 compat lib via
LD_PRELOAD. When using the compat lib via LD_PRELOAD, the X11 mode has
a window title bar and border but those are missing in Wayland mode.
dpkg-architecture -c sh -c
'LD_PRELOAD=/usr/lib/${DEB_HOST_MULTIARCH}/sdl12-compat/libSDL-1.2.so.0
hex-a-hop'
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a digitally signed message part
Mass bug filing / call for testing: dependencies on SDL 1.2
SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives upstream maintenance or releases. Maintained software that uses SDL 1.2 should be ported to SDL 2. For legacy software that cannot be ported, SDL upstream have produced a replacement library, sdl12-compat, which implements the SDL 1.2 API/ABI by dlopening SDL 2 (and correcting for API/ABI changes). In Debian, this is currently available as libsdl1.2-compat-shim. Some other distributions like Fedora and Arch have fully replaced their "classic" SDL 1.2 libraries with sdl12-compat, and I would like to do the same in Debian during the trixie release cycle (which will probably involve taking over the libsdl1.2debian and libsdl1.2-dev package names). Since all SDL 1.2 applications will get one of these bug reports, we might as well also use those bug reports as a prompt to ask maintainers to test against libsdl1.2-compat-shim. I did some brief testing on the remaining SDL 1.2 games in bookworm as part of some work on helping upstream with sdl12-compat, and many of them work as-is or after adding bug fixes or workarounds to sdl12-compat. I was not able to do thorough testing (I generally played the tutorial or first level, if applicable), and for a few more opaque games I couldn't work out how to test gameplay at all. In general I wasn't able to test non-game applications that depend on SDL 1.2 (mostly emulators and music production software), because I didn't have the necessary ROMs, time or knowledge. For libraries that extend SDL 1.2 (sdl-image1.2 and so on), the bug about depending on SDL 1.2 is likely to have to be "won't fix" because it would be an API/ABI break to move to SDL 2, but in many cases there are equivalent libraries with a very similar API available for SDL 2. Here's a template bug mail: 8< --- This package has a Depends or Build-Depends on SDL version 1.2, which is unmaintained upstream. If possible, please port this package to SDL 2 and close this bug. Examples of successful ports from SDL 1.2 to SDL 2 can be found in the commit history of packages like darkplaces and ioquake3. If it is not possible to port to SDL 2, please test the package with libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave this bug open to track the package as still using SDL 1.2 APIs. libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2 API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2 library in some other distributions like Fedora and Arch, and my intention is to do the same in Debian during the trixie release cycle. The interesting scenarios to test with libsdl1.2-compat-shim are: 1. Install libsdl1.2-compat-shim and run the program in an X11 environment, such as "GNOME on Xorg" or XFCE. ($XDG_RUNTIME_DIR/wayland-* should not exist) 2. Install libsdl1.2-compat-shim and run the program in a Wayland environment such as GNOME's default mode, using Xwayland. ($XDG_RUNTIME_DIR/wayland-* should exist) 3. Install libsdl1.2-compat-shim and run the program in a Wayland environment, but this time with environment variable SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface (this is not currently the default for SDL 2). 4. Install libsdl1.2-compat-dev and recompile the package. If any of those fail, please report it as a bug in the libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate, with "affects" pointing to the program that is affected. 8< --- dd-list of affected packages attached. Thanks, smcv A Mennucc1 mplayer (U) A. Maitland Bottoms gnuradio Adrian Bunk black-box Adrien Boussicault mlv Agustin Henze crrcsim Alberto Garcia fuse-emulator Alessio Treglia din (U) libde265 (U) meterbridge (U) xjadeo (U) Alexander Lazarević gnu-smalltalk (U) Alexandre Detiste game-data-packager (U) Alfonso Sabato Siciliano openssn (U) Ana Custura vor Andrea Colangelo tennix Andreas B. Mundt tiemu (U) Andreas Beckmann povray Andreas Gnau icebreaker (U) Ansgar Burchardt btanks (U) Antonin Kral atari800 Ari Pollak gav gltron Axel Beckert links2 Balint Reczey taoframework (U) Barak A. Pearlmutter basic256 gtkboard Barry deFreese amphetamine (U) bloboats (U) brutalchess (U) btanks (U) dd2 (U) late (U) mu-cade (U) netpanzer (U) pathogen (U) titanion (U) tumiki-fighters (U) Barry deFreese airstrike (U) alienblaster (U) asc (U) barrage (U) biniax2 (U) boswars (U) ceferino (U) clanlib (U) enemylines3 (U) fenix (U) fenix-plugins (U) gravitywars (U) hex-a-hop (U) holotz-castle (U) ketm (U) mousetrap (U) netrek-client-cow (U) nikwi (U) plee-the-bear (U) powermanga (U) qonk (U) raincat (U) ri-li (U)
