Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Simon McVittie]

On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> I've recently retried switching to Wayland and I think I'm sticking
> with it. But while checking for toolkits support, noticed that SDL 1.2
> does not have native Wayland support, but SDL 2.0 does.

Note that SDL 2.0 currently defaults to using X11 if available, and will
currently only use Wayland if X11 is unavailable, so in environments where
Xwayland is either always run (such as GNOME 3.38) or started automatically
on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
I think typical desktop environments like GNOME and KDE Plasma are
likely to want Xwayland available by default for quite a long time,
even if it's only started on-demand.

You can override this with with environment variable
SDL_VIDEODRIVER=wayland.

On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> As seen in [1] regarding the headers, sdl12-compat isn't a full replacement 
> yet.
> 
> It could work for pure binary-compatibility but you can't build anything
> against it yet so it should be a Provide+Replace rather than something
> like a newer version.
> 
> 1: https://github.com/libsdl-org/sdl12-compat/issues/34

Yes, I'd come to that conclusion too.

If we get to a point where we want to eliminate the original SDL 1.2 from
the archive before sdl12-compat has headers, we could probably make some
sort of hybrid package that builds SDL 1.2, keeps the headers, discards
the actual shared library and uses the shared library from sdl12-compat
instead - but I think it would probably work best to package sdl12-compat
as a separate binary-compatibility-only library first.

It would probably be best to have the sdl12-compat shared library installed
in a directory outside the default search path so that it can be
co-installed with the real SDL 1.2, and then insert it into the default
search path in a separate package that Provides/Conflicts/Replaces the
real SDL 1.2. That way, individual games have the option to use sdl12-compat
via DT_RUNPATH or LD_LIBRARY_PATH without preventing co-installation of
the real SDL 1.2.

In particular, sdl12-compat has a few extra symbols not present in the
real SDL 1.2, which are meant to make it binary-compatible with the
modified SDL 1.2 build "libSDL-1.2.id.so.0" in some id Software games,
such as the quake4-bin:i386 package built by game-data-packager. If
it works well as a replacement for that modified library, then
game-data-packager could prefer to use sdl12-compat.

On Thu, 18 Mar 2021 at 21:30:47 +0100, Stephen Kitt wrote:
> I’m interested in maintaining this, I’ll ask to join the SDL team.

I've added you.

I briefly started looking at this before seeing this message, so I've
created an empty 
(no content yet though).

smcv

Processed: Re: Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Debian Bug Tracking System]

Processing control commands:

> retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility library 
> wrapping SDL 2.0
Bug #985170 [wnpp] RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
library wrapping SDL 2.0
Changed Bug title to 'ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
library wrapping SDL 2.0' from 'RFP: libsdl1.2-compat -- SDL 1.2 binary 
compatibility library wrapping SDL 2.0'.
> owner -1 !
Bug #985170 [wnpp] ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
library wrapping SDL 2.0
Owner recorded as Stephen Kitt .

-- 
985170: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985170
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#985170: RFP: libsdl1.2-compat -- SDL 1.2 binary compatibility library wrapping SDL 2.0

[Stephen Kitt]

Control: retitle -1 ITP: libsdl1.2-compat -- SDL 1.2 binary compatibility 
library wrapping SDL 2.0
Control: owner -1 !

On Sun, 21 Mar 2021 11:17:32 +, Simon McVittie  wrote:
> On Sat, 13 Mar 2021 at 23:47:30 +0100, Guillem Jover wrote:
> > I've recently retried switching to Wayland and I think I'm sticking
> > with it. But while checking for toolkits support, noticed that SDL 1.2
> > does not have native Wayland support, but SDL 2.0 does.  
> 
> Note that SDL 2.0 currently defaults to using X11 if available, and will
> currently only use Wayland if X11 is unavailable, so in environments where
> Xwayland is either always run (such as GNOME 3.38) or started automatically
> on-demand (such as GNOME 40), SDL 2.0 games will normally be using X11.
> I think typical desktop environments like GNOME and KDE Plasma are
> likely to want Xwayland available by default for quite a long time,
> even if it's only started on-demand.
> 
> You can override this with with environment variable
> SDL_VIDEODRIVER=wayland.

Right, I’ll make sure to document this in the package.

> On Sun, 14 Mar 2021 at 02:07:34 +0100, Haelwenn (lanodan) Monnier wrote:
> > As seen in [1] regarding the headers, sdl12-compat isn't a full
> > replacement yet.
> > 
> > It could work for pure binary-compatibility but you can't build anything
> > against it yet so it should be a Provide+Replace rather than something
> > like a newer version.
> > 
> > 1: https://github.com/libsdl-org/sdl12-compat/issues/34  
> 
> Yes, I'd come to that conclusion too.

Yup, for the time being it’s really only a runtime replacement, it’s not
ready as a build-time SDL2 shim for SDL1.2 projects.

> If we get to a point where we want to eliminate the original SDL 1.2 from
> the archive before sdl12-compat has headers, we could probably make some
> sort of hybrid package that builds SDL 1.2, keeps the headers, discards
> the actual shared library and uses the shared library from sdl12-compat
> instead - but I think it would probably work best to package sdl12-compat
> as a separate binary-compatibility-only library first.

Yes, that’s my plan at least. If we do end up wanting to drop (or deprecate)
libsdl1.2debian, I’m not sure we’d really even need a hybrid package — it
would be simpler to make libsdl1.2-dev depend on libsdl1.2-compat instead of
libsdl1.2debian... It’s not as if the licensing concerns really affect Debian
in this instance, AFAICT.

> It would probably be best to have the sdl12-compat shared library installed
> in a directory outside the default search path so that it can be
> co-installed with the real SDL 1.2, and then insert it into the default
> search path in a separate package that Provides/Conflicts/Replaces the
> real SDL 1.2. That way, individual games have the option to use sdl12-compat
> via DT_RUNPATH or LD_LIBRARY_PATH without preventing co-installation of
> the real SDL 1.2.
> 
> In particular, sdl12-compat has a few extra symbols not present in the
> real SDL 1.2, which are meant to make it binary-compatible with the
> modified SDL 1.2 build "libSDL-1.2.id.so.0" in some id Software games,
> such as the quake4-bin:i386 package built by game-data-packager. If
> it works well as a replacement for that modified library, then
> game-data-packager could prefer to use sdl12-compat.

Good point, I hadn’t thought of that. So we’d have a libsdl1.2-compat package
usable by packages that explicitly prefer the compatibility layer, and a
libsdl1.2-compat-shim (or something like that) package which actually
replaces libsdl1.2debian.

> On Thu, 18 Mar 2021 at 21:30:47 +0100, Stephen Kitt wrote:
> > I’m interested in maintaining this, I’ll ask to join the SDL team.  
> 
> I've added you.
> 
> I briefly started looking at this before seeing this message, so I've
> created an empty 
> (no content yet though).

Thanks!

Regards,

Stephen


pgpKBf3rxz9ei.pgp
Description: OpenPGP digital signature

Processed: sword-text-kjv: Build from source

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 984600
Bug #985655 [sword-text-kjv] sword-text-kjv: Build from source
985655 was not blocked by any bugs.
985655 was not blocking any bugs.
Added blocking bug(s) of 985655: 984600

-- 
985655: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985655
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: sword-text-sparv: Build from source

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 984600
Bug #985656 [sword-text-sparv] sword-text-sparv: Build from source
985656 was not blocked by any bugs.
985656 was not blocking any bugs.
Added blocking bug(s) of 985656: 984600

-- 
985656: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985656
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#985669: RFP: pnpm -- Efficent NPM replacement

[Calum McConnell]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: calumlikesapple...@gmail.com, 
pkg-javascript-de...@lists.alioth.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: pnpm
  Version : 5.18.8
  Upstream Author : Zoltan Kochan 
* URL : https://pnpm.js.org/
* License : MIT
  Programming Lang: Javascript
  Description : Efficent NPM replacement

PNPM is a disk-efficent replacement for the NPM command. It
prevents duplication of package files across projects by hard
linking files to a content-addressed store.  It is a great solution
for developers with limited hard-drive space, or a large number of
projects.

- 

While I would love to package this myself, I do not work with
JavaScript regularally (in part due to ecosystem problems like
NPM's love of duplication).  As such, I am filing this as an RFP,
as opposed to an ITP.



-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAmBXkokdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzI/TxAAsIFoz0j7TLtDJLsi
dN5hbn+SAHg42qDWoWJs5OIkIAWkMOZxT/JIc+KP1dbMM/9nmBYwUHBTAMcK4uwB
DyHEJzRACW4cKsg7oC07O4cq9+7cld25DMpqDyLfOhU1NOO7VT3o94lsCcX17Ntb
Fi5DkdbYEzjVx+/+txM4l6nAMEjF5O3QggnWZwXLpuA8CLiWaLfgcjXSMDNZ37e3
9tNX3gxQd3a7HeLU0ffyhUQ3se1/UfM5jcivGSH6ILn7tV/4ShciVlLPojNYSbIB
vb6GGh2EQFk9CsmEUDZVouDHVDm4A1nNmntnK8x50TIOpUUPJlyCvVUdc+9FYNkb
J3PsD6rwi1wZV9jqpST2gzQi11Q5jFwlc77Gd8cnTQWfwZSSJM309iudHIvoQzeU
mUr6nhKIhWgGih3z/6q2Fvm/dagHE++jm3nhOv7EpXmP9AEXj3CqLGHc0gAXvzyS
zWo6jp+egqqoRlOAPpv6dA6t+egoxQUbgpFgSYRkUdIlttMzywPCI7VFjUT/arp1
D3xNG/O4DeceP0fQhyCWsDxy6fWstiihlw4zj9oP/PHPEqrMv3VQhvJPH7fucgje
vzKV9JztAyps1ppJ4Q2ttVbZMte6HYok+38hSEBOgDYl3tK9L5TjJC4ZDxutP8RZ
AMwHU4KRgQXZWNI8R3MhHok0O7g=
=YNZB
-END PGP SIGNATURE-

Bug#985677: O: acpica-unix -- ACPICA tools for the development and debug of ACPI tables

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:acpica-unix

I am orphaning the acpica-unix package.

The package description is:
 The ACPI Component Architecture (ACPICA) project provides an OS-independent
 reference implementation of the Advanced Configuration and Power Interface
 Specification (ACPI).  ACPICA code contains those portions of ACPI meant to
 be directly integrated into the host OS as a kernel-resident subsystem, and
 a small set of tools to assist in developing and debugging ACPI tables.
 .
 This package contains only the user-space tools needed for ACPI table
 development, not the kernel implementation of ACPI.  The following commands
 are installed:
-- iasl: compiles ASL (ACPI Source Language) into AML (ACPI Machine
   Language), suitable for inclusion as a DSDT in system firmware.
   It also can disassemble AML, for debugging purposes.
-- acpibin: performs basic operations on binary AML files (e.g.,
   comparison, data extraction)
-- acpidump: write out the current contents of ACPI tables
-- acpiexec: simulate AML execution in order to debug method definitions
-- acpihelp: display help messages describing ASL keywords and op-codes
-- acpinames: display complete ACPI name space from input AML
-- acpisrc: manipulate the ACPICA source tree and format source files
   for specific environments
-- acpixtract: extract binary ACPI tables from acpidump output (see
   also the pmtools package)

Processed: O: acpica-unix -- ACPICA tools for the development and debug of ACPI tables

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:acpica-unix
Bug #985677 [wnpp] O: acpica-unix -- ACPICA tools for the development and debug 
of ACPI tables
Added indication that 985677 affects src:acpica-unix

-- 
985677: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985677
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#985678: O: rasdaemon -- utility to receive RAS error tracings

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:rasdaemon

I orphaning the rasdaemon package.

The package description is:
 rasdaemon is a RAS (Reliability, Availability and Serviceability) logging
 tool.  It currently records memory errors, using the EDAC tracing events.
 EDAC are drivers in the Linux kernel that handle detection of ECC errors
 from memory controllers for most chipsets on x86 and ARM architectures.
 This userspace component consists of an init script which makes sure EDAC
 drivers and DIMM labels are loaded at system startup, as well as a utility
 for reporting current error counts from the EDAC sysfs files.

Processed: O: gnucobol -- COBOL compiler

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:gnucobol
Bug #985679 [wnpp] O: gnucobol -- COBOL compiler
Added indication that 985679 affects src:gnucobol

-- 
985679: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985679
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#985679: O: gnucobol -- COBOL compiler

[Al Stone]

Package: wnpp
Severity: normal
Control: affects -1 src:gnucobol

I am orphaning the gnucobol package.

The package description is:
 GnuCOBOL (formerly OpenCOBOL) is a free, modern COBOL compiler. GnuCOBOL
 implements a substantial part of the COBOL 85, COBOL 2002 and COBOL 2014
 standards and X/Open COBOL, as well as many extensions included in other COBOL
 compilers (IBM COBOL, MicroFocus COBOL, ACUCOBOL-GT and others).
 .
 GnuCOBOL translates COBOL into C and compiles the translated code using a
 native C compiler.
 .
 Build COBOL programs on various platforms, including GNU/Linux, Unix, Mac OS X,
 and Microsoft Windows. GnuCOBOL has also been built on HP/UX, z/OS, SPARC,
 RS6000, AS/400, along with other combinations of machines and operating
 systems.
 .
 While being held to a high level of quality and robustness, GnuCOBOL does not
 claim to be a “Standard Conforming” implementation of COBOL.
 .
 GnuCOBOL passes over 9600 of the NIST COBOL 85 test suite tests and over 750
 internal checks during build.

Processed: O: rasdaemon -- utility to receive RAS error tracings

[Debian Bug Tracking System]

Processing control commands:

> affects -1 src:rasdaemon
Bug #985678 [wnpp] O: rasdaemon -- utility to receive RAS error tracings
Added indication that 985678 affects src:rasdaemon

-- 
985678: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985678
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems