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
