Re: Mass bug filing / call for testing: dependencies on SDL 1.2

[Simon McVittie]

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

Bug#1037487: ITP: trantor -- Non-blocking I/O cross-platform TCP network library

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: trantor
  Version : 1.5.11
  Upstream Author : An Tao 
* URL : https://github.com/an-tao/trantor
* License : BSD
  Programming Lang: C++
  Description : Non-blocking I/O cross-platform TCP network library

Trantor is a non-blocking I/O cross-platform TCP network library, using
C++14. Drawing on the design of Muduo Library

This package is needed by weakforced as a transitive dependency of
drogon, which I also intend to package.

For now these packages will be in collab-maint, but I'll see if they
could go somewhere. I'm maintaining them as part of my work at
Gandi.net. This is therefore a Gandi.net contribution to the Debian
Project.

Bug#1037489: ITP: libqt6gui6-gles -- The QtGui module extends QtCore with GUI functionality for GLES platforms.

[Leonardo Held]

Package: wnpp
Severity: wishlist
Owner: Leonardo Held 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : libqt6gui6-gles
Version : 6.4.2
Upstream Author : The Qt Company
* URL : https://www.qt.io/developers/
* License : LGPL-3, GPL-2, GFDL-NIV-1.3, GPL-3 with Qt-1.0 exception,
BSD-3-clause, GFDL-NIV-1.3, Apache-2.0, CC0-1.0, FTL, Hybrid-BSD,
Boost-1.0, W3C, Unicode, libpng, brg-endian, ICC
Programming Lang:  C, C++
Description : The QtGui module extends QtCore with GUI functionality for
GLES platforms.

libqt6gui6-gles is intend for embedded devices that support the OpenGL
ES rendering API.

This package is useful for using Debian with Qt in devices that are not
contemplated by the already packaged libqt6gui6, which only works with
OpenGL implementations.
This is actively used by anyone who is building Qt applications for
embedded and the scope of this was discussed in bug #1035985, hence the ITP.
This package will be maintained under the Qt/KDE team.


[Toradex Logo]    Embedded Computing
Made Easy
Choose Us | 
Products | Developer Center | 
Community | Careers
Join our webinar:
- Simplify the development of critical medical and industrial applications with QNX 
and NXP i.MX 8 | June 23, 2023: 
Register

Meet our engineers at:
- Sensors Converge | California, USA | June 20-22, 2023
- Embedded Open Source Summit (EOSS) | June 26-30, 2023 | Czech Republic

Bug#1037491: ITP: qt6-base-gles-dev -- This package contains the header development files used for building Qt 6 applications.

[Leonardo Held]

Package: wnpp
Severity: wishlist
Owner: Leonardo Held 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : qt6-base-gles-dev
Version : 6.4.2
Upstream Author : The Qt Company
* URL : https://www.qt.io/developers/
* License : LGPL-3, GPL-2, GFDL-NIV-1.3, GPL-3 with Qt-1.0 exception,
BSD-3-clause, GFDL-NIV-1.3, Apache-2.0, CC0-1.0, FTL, Hybrid-BSD,
Boost-1.0, W3C, Unicode, libpng, brg-endian, ICC
Programming Lang:  C, C++
Description : This package contains the header development files used
for building Qt 6 applications.


qt6-base-gles-dev is intend for embedded devices that support the OpenGL
ES rendering API.

This package is useful for using Debian with Qt in devices that are not
contemplated by the already packaged qt6-base-dev, which only works with
OpenGL implementations.
This is actively used by anyone who is building Qt applications for
embedded and the scope of this was discussed in bug #1035985, hence the
ITP.
This package will be maintained under the Qt/KDE team.

[Toradex Logo]    Embedded Computing
Made Easy
Choose Us | 
Products | Developer Center | 
Community | Careers
Join our webinar:
- Simplify the development of critical medical and industrial applications with QNX 
and NXP i.MX 8 | June 23, 2023: 
Register

Meet our engineers at:
- Sensors Converge | California, USA | June 20-22, 2023
- Embedded Open Source Summit (EOSS) | June 26-30, 2023 | Czech Republic

Bug#1037492: ITP: qt6-base-private-gles-dev -- This package contains the private header development files for building some Qt 6 applications like the Qt Creator QML Designer plugin.

[Leonardo Held]

Package: wnpp
Severity: wishlist
Owner: Leonardo Held 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name : qt6-base-private-gles-dev
Version : 6.4.2
Upstream Author : The Qt Company
* URL : https://www.qt.io/developers/
* License : LGPL-3, GPL-2, GFDL-NIV-1.3, GPL-3 with Qt-1.0 exception,
BSD-3-clause, GFDL-NIV-1.3, Apache-2.0, CC0-1.0, FTL, Hybrid-BSD,
Boost-1.0, W3C, Unicode, libpng, brg-endian, ICC
Programming Lang:  C, C++
Description : This package contains the private header development files
for building some Qt 6 applications like the Qt Creator QML Designer plugin.


qt6-base-private-gles-dev is intend for embedded devices that support
the OpenGL ES rendering API.

This package is useful for using Debian with Qt in devices that are not
contemplated by the already packaged qt6-base-private-dev, which only
works with OpenGL implementations.
This is actively used by anyone who is building Qt applications for
embedded and the scope of this was discussed in bug #1035985, hence the
ITP.
This package will be maintained under the Qt/KDE team.


[Toradex Logo]    Embedded Computing
Made Easy
Choose Us | 
Products | Developer Center | 
Community | Careers
Join our webinar:
- Simplify the development of critical medical and industrial applications with QNX 
and NXP i.MX 8 | June 23, 2023: 
Register

Meet our engineers at:
- Sensors Converge | California, USA | June 20-22, 2023
- Embedded Open Source Summit (EOSS) | June 26-30, 2023 | Czech Republic

Bug#1037495: ITP: drogon -- Daemon for detecting brute force attacks

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: drogon
  Version : 1.8.4
  Upstream Author : An Tao 
* URL : https://github.com/drogonframework/drogon
* License : MIT
  Programming Lang: C++
  Description : C++14/17-based HTTP application framework

Drogon can be used to easily build various types of web application server
programs using C++. Drogon is the name of a dragon in the American TV series
"Game of Thrones" that I really like.

Drogon is a cross-platform framework, It supports Linux, macOS, FreeBSD,
OpenBSD, HaikuOS, and Windows. Its main features are as follows:

  * Use a non-blocking I/O network lib based on epoll (kqueue under
macOS/FreeBSD) to provide high-concurrency, high-performance network
IO, please visit the TFB Tests Results for more details;
  * Provide a completely asynchronous programming mode;
  * Support Http1.0/1.1 (server side and client side);
  * Based on template, a simple reflection mechanism is implemented to
completely decouple the main program framework, controllers and
views.
  * Support cookies and built-in sessions;
  * Support back-end rendering, the controller generates the data to the view
to generate the Html page. Views are described by CSP template files, C++ 
codes
are embedded into Html pages through CSP tags. And the drogon command-line 
tool
automatically generates the C++ code files for compilation;
  * Support view page dynamic loading (dynamic compilation and loading at 
runtime);
  * Provide a convenient and flexible routing solution from the path to the
controller handler;
  * Support filter chains to facilitate the execution of unified logic (such as
login verification, Http Method constraint verification, etc.) before 
handling
HTTP requests;
  * Support https (based on OpenSSL);
  * Support WebSocket (server side and client side);
  * Support JSON format request and response, very friendly to the Restful API
application development;
  * Support file download and upload;
  * Support gzip, brotli compression transmission;
  * Support pipelining;
  * Provide a lightweight command line tool, drogon_ctl, to simplify the
creation of various classes in Drogon and the generation of view code;
  * Support non-blocking I/O based asynchronously reading and writing database
PostgreSQL and MySQL(MariaDB) database);
  * Support asynchronously reading and writing sqlite3 database based on thread
pool;
  * Support Redis with asynchronous reading and writing;
  * Support ARM Architecture;
  * Provide a convenient lightweight ORM implementation that supports for
regular object-to-database bidirectional mapping;
  * Support plugins which can be installed by the configuration file at load
time;
  * Support AOP with build-in joinpoints.
  * Support C++ coroutines

This package is needed by weakforced, which I also intend to package.

For now these packages will be in collab-maint, but I'll see if they
could go somewhere. I'm maintaining them as part of my work at
Gandi.net. This is therefore a Gandi.net contribution to the Debian
Project.

Bug#1037498: ITP: weakforced -- Daemon for detecting brute force attacks

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: Pierre-Elliott Bécue 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: weakforced
  Version : 2.8.0
  Upstream Author : Neil Cook 
* URL : https://github.com/PowerDNS/weakforced
* License : GPL-3
  Programming Lang: C++, Python
  Description : Daemon for detecting brute force attacks

The goal of 'wforce' is to detect brute forcing of passwords across many
servers, services and instances. In order to support the real world, brute
force detection policy can be tailored to deal with "bulk, but legitimate"
users of your service, as well as botnet-wide slowscans of passwords.
The aim is to support the largest of installations, providing services to
hundreds of millions of users.

weakforced doesn't have any real alternative for now in Debian as far as I can
see.

For now these packages will be in collab-maint, but I'll see if they
could go somewhere. I'm maintaining them as part of my work at
Gandi.net. This is therefore a Gandi.net contribution to the Debian
Project.

Bug#1037500: ITP: golang-github-sherclockholmes-webpush-go -- Web Push API library with encryption and VAPID support

[Taavi Väänänen]

X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 

* Package name: golang-github-sherclockholmes-webpush-go
  Version : 1.2.0-1
  Upstream Author : Ethan Holmes
* URL : https://github.com/SherClockHolmes/webpush-go
* License : Expat
  Programming Lang: Go
  Description : Web Push API library with encryption and VAPID support

webpush-go provides a Web Push API library with support for encryption 
and VAPID.


This is a dependency of the soju IRC bouncer that I'm packaging.


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037503: ITP: golang-gopkg-irc.v4 -- Simple Go IRC library

[Taavi Väänänen]

X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 

* Package name: golang-gopkg-irc.v4
  Version : 4.0.0-1
  Upstream Author : Kaleb Elwert
* URL : https://github.com/go-irc/irc
* License : Expat
  Programming Lang: Go
  Description : Simple Go IRC library

go-irc is a simple GO IRC library meant to be a building block for other 
projects.


This is a dependency of the soju IRC bouncer that I'm packaging.


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037504: ITP: golang-sourcehut-sircmpwn-go-bare -- Implementation of BARE message encoding for Go

[Taavi Väänänen]

X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Taavi Väänänen 

* Package name: golang-sourcehut-sircmpwn-go-bare
  Version : 0.0~git20210406.ab86bc2-1
  Upstream Author : Drew DeVault 
* URL : https://sr.ht/~sircmpwn/go-bare
* License : Apache-2.0
  Programming Lang: Go
  Description : Implementation of BARE message encoding for Go

go-bare provides an implementation of the BARE message format for Go.

This is a dependency of the soju IRC bouncer that I'm packaging.


OpenPGP_0xEF242F709F912FBE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037506: ITP: prjtrellis -- Tools to generate Lattice ECP5 bitstreams

[Daniel Gröber]

Package: wnpp
Severity: wishlist
Owner: Daniel Gröber 
X-Debbugs-Cc: debian-devel@lists.debian.org, d...@darkboxed.org

* Package name: prjtrellis
  Version : 1.4
  Upstream Authors: David Shah 
William D. Jones 
Miodrag Milanovi 
myrtle 
* URL : https://github.com/YosysHQ/prjtrellis
* License : ISC/MIT
  Programming Lang: C++/Python
  Description : Tools to generate Lattice ECP5 bitstreams

Project trellis supplies documentation and tools for generating the
bitstream format used by Lattice ECP5 family of FPGAs.

It has been requested[1] that nextpnr enable support for this FPGA
family so we need to package prjtrellis to do this.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028137

I need a sponsor as always. ~Victims~, eer, volunteers welcome :)

--Daniel

Bug#1035883: Close out this report, please

[Jim Anderson]

I have looked at my other debian computers and the TMOUT setting works 
on them. I'm not sure why TMOUT does not work on my one computer, but it 
is not worth the effort to try to debug this issue for one system. 
Please consider this issue closed.



Jim A.

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Steve Langasek]

On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote:

> On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:

> > The difference in my view is that the changes to handle Provides: are
> > something that should persist in the packaging (until the next soname
> > change, at which point it's easy to handle as part of the overall renaming),
> > whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are
> > something that ideally would be dropped immediately after dpkg-buildflags is
> > updated, and could (though unlikely) be a source of bugs later.  I'd prefer
> > to avoid any transition plan which means I should be NMUing all of the
> > affected library packages twice.

> I think I understand where you are coming from, and I see how ideally
> these would be dropped soon, but I also don't see this as a pressing
> matter that would even need NMUs, as the explicit settings should map
> to the then current defaults. Of course that precludes those defaults
> then changing globally in the future, but if needed (!?) that could be
> handled later on. But again, I think the flag day can potentially be
> done in multiple other ways that might avoid the breakage w/o needing
> these changes, and if so I'm happy with that as well.

After thinking about it, I'd like to suggest the following approach.

- dpkg with the new default behavior uploaded to experimental
- libraries uploaded to experimental with the new package names (so, NEW
  processing gets done) and with a versioned build-dependency (easy to
  automate with sed on debian/control)
- once all the libraries have cleared NEW, copy to unstable without dropping
  the versioned build-dependency; it will never be wrong, it will always at
  most be cruft that can be cleaned up lazily

What do you think?

> > > Hmm, rechecking the script, I think we'd want to at least
> > > unconditionally add the Breaks and Replaces (no need for substvars
> > > then), otherwise we'd get upgrade errors?

> > > That would leave only the Provides as potentially conditional…

> > You're absolutely right, thanks for catching this!  Fixed in git.

> As hinted above, I think the source:Version substvar should be
> switched to a hardcoded version at the point the migration was done,
> otherwise it will be floating forward and not catch older affected
> versions?

Oh ok, I didn't catch that this is what you meant.  But it's not clear to me
what you mean by "not catch older affected versions" - why would it be wrong
to Breaks/Replaces against non-existent, newer versions of an obsolete
binary package name?

It's not a difficult change to make, I just don't understand why it's
important.

> > > > And btw, given the analysis that there are likely < 100 shared libraries
> > > > overall whose ABI changes when enabling LFS, this might be a change we 
> > > > want
> > > > to consider in the trixie cycle as well - just preferably not bundled 
> > > > with
> > > > the time_t transition at the same time, as that would just cause more 
> > > > delays
> > > > for testing migration vs splitting the two transitions.

> > > If the plan is to go with a flag day by switching the default for
> > > time64, then I don't see how the LFS change can be decoupled, as that
> > > automatically will also forcibly enable LFS globally on glibc arches.
> > > I've also in general been worried about automatically enabling LFS w/o
> > > someone looking into each package, given the greater potential for
> > > data loss. :/

> > I think in the case of LFS-sensitive libraries that aren't part of the
> > dependency graph of packages affected by the time_t change, it's easy enough
> > to patch them to not turn on the LFS flag and avoid a transition.

> Just to try to understand whether we are on the same page. If these
> libraries have no time_t usage at all, then disabling time64 should
> then provoke no time_t issue and should stop implicitly enabling LFS.
> But if the library contains internal time_t usage that is not part of
> the exposed ABI, but part of its operation, then I'm not sure I see
> how we can patch them to disable LFS w/o at the same time losing
> time64 support (as the latter forces/requires the former).

> I'm not sure whether you are talking about the first or second case?
> And whether we have no libraries at all falling under the second case?

I was only thinking about the first case, I had not previously considered
the second case.  We should be able to determine fairly easily whether there
are any in the second case; for all ELF binaries which are built from the
same source package as an LFS-sensitive library, check whether they have
references to any of the static list of symbols in glibc that are affected
by time_t, and if they are, add them to the list of libraries to transition.

I'll add this to the analysis in progress.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the wor