Bug#1067979: python3-pantalaimon: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: python3-pantalaimon
Version: 0.10.5-1
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067965: git-phab: Please replace python3-appdirs dependency with platformdirs

[Simon McVittie]

Package: git-phab
Version: 2.9.0~git20170531+6877964-2
Severity: important
Control: block 1060427 by -1
Tags: trixie sid
User: debian-pyt...@lists.debian.org
Usertags: appdirs-removal

python3-appdirs is dead upstream[1] and its Debian maintainer has indicated
that it should not be included in trixie[2]. A recommended replacement is
python3-platformdirs[3], which is a fork of appdirs with a very similar API.

Please migrate from appdirs to platformdirs or some other replacement,
so that appdirs can be removed.

Thanks,
smcv

[1] 
https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e954910533884
[2] https://bugs.debian.org/1060427
[3] https://pypi.org/project/platformdirs/

Bug#1067171: bleachbit: hard-coded dependency on libgtk-3-0 will become uninstallable on armel/armhf

[Simon McVittie]

Package: bleachbit
Version: 4.6.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1

bleachbit is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency on libgtk-3-0t64 via
gir1.2-gtk-3.0.

On the architectures affected by the 64-bit time_t transition (notably
armel and armhf), this is an impossible dependency, because libgtk-3-0 and
libgtk-3-0t64 conflict.

Please remove the explicit dependency on libgtk-3-0. For Python code
that uses GTK via GObject-Introspection, it is sufficient to depend
on gir1.2-gtk-3.0.

More information about this transition is available on
.

Thanks,
smcv

Bug#1065713: directfb: FTBFS on arm{el,hf}: error: ‘const struct input_event’ has no member named ‘time’

[Simon McVittie]

On Sat, 09 Mar 2024 at 12:29:26 +0100, Sebastian Ramacher wrote:
> linux_input.c: In function ‘translate_event’:
> linux_input.c:761:28: error: ‘const struct input_event’ has no member named 
> ‘time’
>   761 |  devt->timestamp = levt->time;
>   |^~

This seems to be essentially the same bug that was fixed in SDL by:
https://github.com/libsdl-org/SDL/commit/10fc3b3db715f0e2050e49f39d7d6e932813723c
so hopefully that's a useful reference.

smcv

Re: Bug#1065816: weston: Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 0.7.0'

[Simon McVittie]

Control: block 1036884 by -1

On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>= 
> 0.7.0'

This is important for the 64-bit time_t transition, because weston is
part of that transition, and also because packages like gtk4 use weston in
headless mode to test their Wayland backends. This could be mitigated by
temporarily making gtk4 skip its Wayland tests on 32-bit architectures,
but with gtk4 hat on, I would not be comfortable with doing that in
the long term, because in practice it seems to be inevitable that
functionality that isn't tested doesn't actually work.

Looking at the recent neatvnc upload, I was surprised to see that its
former maintainer updated it to a new upstream release in the same upload
as orphaning it (#1065738), and also updated the closely-related wayvnc
package to a new upstream release that matches neatvnc.

I also noticed that neatvnc 0.8.0 has an ABI break without bumping the
SONAME (#1065824), although that might be ignorable since nothing in
Debian seems to use the affected symbol.

I think the options here in the short term are:

1. adapt weston to support neatvnc 0.8.0, if it's straightforward to do so;
2. revert neatvnc to 0.8.0+really0.7.1+dfsg and wayvnc to 0.8.0+really0.7.2,
   and revisit this later, when we are *not* in the middle of a transition
   that touches thousands of packages;
3. temporarily disable the VNC backend in weston, and revisit this later

I would personally be very tempted by (2.) since it seems like the option
with least risk of regressions when compared with what's currently in
trixie, but I have no particular knowledge of these packages, so it
would be better if the maintainers of weston and/or wayvnc could adopt
neatvnc and handle this in whatever way they prefer. If this situation
is not resolved then I might do the revert (2.), by QA-uploading neatvnc
and NMU'ing wayvnc.

Thanks,
smcv

Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote:
> So far in order to investigate I have:
> 
> 1. installed discord on a lwm desktop via flatpak. This works but is pretty
> ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

> 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
> environment.

In the original bug report, part of the solution I suggested was this:

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?

> Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
> (and does not pollute other desktop environments since we can check at that
> point). However it depends on the the package dbus-x11 and I have concerns
> about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

smcv

Bug#1056130: gthumb: (unused?) build-dependency on deprecated libsoup-gnome2.4-dev

[Simon McVittie]

Source: gthumb
Version:  3:3.12.4-1
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libsoup2.4 libsoup-gnome

While checking how many packages are still using the deprecated
libsoup2.4, I noticed that gthumb is one of only two packages in Debian
that still depend on libsoup-gnome2.4-dev.

libsoup-gnome was originally a sub-library for parts of libsoup that
depended on GNOME infrastructure, like GNOME's gconf settings for proxies.
My understanding is that all of that functionality has now been superseded
by components at the cross-desktop layer, like GIO extension points and
the glib-networking package.

gthumb has a build-dependency, but the actual binary has no dependency
on libsoup-gnome2.4-1, and from a quick look at codesearch I can't
see any sign that it is actually using this sub-library. Can the
build-dependency be removed?

This would also be a step closer to being able to port
gthumb from the deprecated libsoup2.4/libwebkit2-gtk-4.0-dev to
libsoup3/libwebkit2-gtk-4.1-dev (a mass bug filing for that will follow
at some point). libsoup3 does not have libsoup-gnome any more.

Thanks,
smcv

Bug#1052113: gnome-shell-mailnag: needs update for GNOME Shell 45

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-4
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-45

As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 45, which is currently being prepared in
experimental. A porting guide is available here:
https://gjs.guide/extensions/upgrading/gnome-shell-45.html

For the 44 -> 45 transition, most or all extensions will need
incompatible code changes, because GNOME Shell has switched from
non-standard gjs modules ("const Foo = imports.gi.Foo") to ECMAScript
modules ("import Foo from 'gi://Foo'") and all extensions need to do
the same. This means most or all extensions will split into a branch
for Shell <= 44 (which might not be maintained upstream any more) and
a branch for Shell >= 45.

If not updated, this extension will have to be removed from testing for
the GNOME Shell 45 transition (I don't know when that will be). This
bug will be raised to serious severity when the transition is ready to
go ahead.

The upstream developer might already have made this change (I haven't
checked). If a new upstream version is compatible with Shell 45 but not
44, please upload to experimental for now.

Thanks,
smcv

Bug#1051015: pekwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: pekwm
Version: 0.1.18-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Pekwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/pekwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/pekwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Pekwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Pekwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg pekwm
* reboot
* Log in as the user account, selecting "Pekwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Pekwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Pekwm

would seem appropriate.

This would allow the Pekwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/pekwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Pekwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/pekwm.desktop, most likely just "Pekwm":

DesktopNames=Pekwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/pekwm-portals.conf
with whatever portal backends are desired for an Pekwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051012: miwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: miwm
Version: 1.1-8
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Miwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/miwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/miwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Miwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Miwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg miwm
* reboot
* Log in as the user account, selecting "Miwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Miwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Miwm

would seem appropriate.

This would allow the Miwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/miwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Miwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/miwm.desktop, most likely just "Miwm":

DesktopNames=Miwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/miwm-portals.conf
with whatever portal backends are desired for an Miwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: lwm
Version: 1.2.4-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Lwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/lwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/lwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Lwm doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Lwm to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg lwm
* reboot
* Log in as the user account, selecting "Lwm" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Lwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Lwm

would seem appropriate.

This would allow the Lwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/lwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Lwm who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/lwm-portals.conf
with whatever portal backends are desired for an Lwm session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1051000: ctwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: ctwm
Version: 4.0.3-2
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, CTWM behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/ctwm.desktop
which can be selected on entry to a display manager such as lightdm.
If it's going to register as a desktop environment, then it should behave
like a desktop environment in other ways, such as choosing an
XDG_CURRENT_DESKTOP identifier.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/ctwm-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, CTWM doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow CTWM to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg ctwm
* reboot
* Log in as the user account, selecting "CTWM" from the menu of
  possible X11 sessions
* Open an xterm and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. CTWM seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=CTWM

would seem appropriate.

This would allow the CTWM session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/ctwm-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of CTWM who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/ctwm.desktop, most likely just "CTWM":

DesktopNames=CTWM;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/ctwm-portals.conf
with whatever portal backends are desired for an CTWM session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1050964: blackbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: blackbox
Version: 0.70.1-39
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

As well as being available as a window manager to integrate into some
larger environment, Blackbox behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/blackbox.desktop
which can be selected on entry to a display manager such as lightdm.

xdg-desktop-portal 1.17.x introduces a new way to select which portals will
be used for which desktop environments, modelled on mimeapps.list:

- each desktop environment should provide a file like
  /usr/share/xdg-desktop-portal/blackbox-portals.conf

- the filename is ${DESKTOP}-portals.conf where ${DESKTOP} is the desktop
  environment's entry in $XDG_CURRENT_DESKTOP (the same as the DesktopNames
  from /usr/share/{x,wayland-}sessions/*.desktop), folded to lower case

- sysadmins and users can override this via files named portals.conf or
  ${DESKTOP}-portals.conf in various locations like /etc/xdg-desktop-portal
  and ~/.config/xdg-desktop-portal

But as far as I can tell, Blackbox doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other desktop environment or window manager.

XDG_CURRENT_DESKTOP is also used in pre-existing freedesktop.org standards
like the OnlyShowIn/NotShowIn fields for .desktop files, and the ability to
provide a desktop-environment-specific mimeapps.list. Setting
XDG_CURRENT_DESKTOP would allow Blackbox to participate in those
specifications.

To reproduce


* Start from a basic non-GUI virtual machine (I used autopkgtest-build-qemu)
* Ensure that a user account exists
* apt install lightdm xorg blackbox
* reboot
* Log in as the user account, selecting "Blackbox" from the menu of
  possible X11 sessions
* Open a terminal and run:
  env | grep XDG_CURRENT_DESKTOP
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`env`, because xdg-desktop-portal will typically be run as a systemd
user service.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Blackbox seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Blackbox

would seem appropriate.

This would allow the Blackbox session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/blackbox-portals.conf.

Actual result
=

XDG_CURRENT_DESKTOP is unset.

This means that xdg-desktop-portal configuration can only be done via a
non-desktop-specific portals.conf, but that's not really something that a
non-opinionated distribution like Debian can usefully ship in a centralized
way, so each user of Blackbox who wants a working xdg-desktop-portal will
have to configure it themselves.

At the moment, this is mitigated by xdg-desktop-portal (>= 1.17) having
been patched to fall back to xdg-desktop-portal-gtk as a last-resort
desktop-environment-specific backend, but hard-coding that implementation
isn't really something we should be doing centrally (and the idea was
rejected upstream), so I intend to remove that patch before trixie
is released.

Suggested fix
=

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/blackbox.desktop, most likely just "Blackbox":

DesktopNames=Blackbox;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

And then create a /usr/share/xdg-desktop-portal/blackbox-portals.conf
with whatever portal backends are desired for a Blackbox session,
for example perhaps this:

[preferred]
default=gtk;

Please see portals.conf(5) or its source code
https://github.com/flatpak/xdg-desktop-portal/blob/main/doc/portals-conf.rst
for full details.

Thanks,
smcv

-- 
This is part of a mass bug filing:
https://lists.debian.org/debian-devel/2023/08/msg00311.html

Bug#1041796: hexxagon: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: hexxagon
Version: 1.0pl1-4
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1
Control: block 967497 by -1

hexxagon Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2. GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance at all.

The direct replacement for gtkmm2.4 is gtkmm3.0, a C++ API for GTK 3.
Please see  for
information about porting from gtkmm2.4 to gtkmm3.0, and
 for general information
about porting from GTK 2 to GTK 3.

Thanks,
smcv

Bug#1041790: dbus-c++: depends on unmaintained gtkmm2.4, and indirectly on GTK 2

[Simon McVittie]

Source: dbus-c++
Version: 0.9.0-11
Severity: normal
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 967733 by -1
Control: block 967497 by -1

dbus-c++ Build-Depends on packages from src:gtkmm2.4, a C++ binding for
GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
). It has been discontinued by its upstream
developer and no longer receives any upstream maintenance.

If dbus-c++ can be either updated to GTK 3, updated to drop the GTK
dependency or removed, then that would reduce the amount of technical
debt in the archive.

>From a quick look at the binary package dependencies and source code,
it looks as though simply dropping the build-dependency should work: this
will result in the dbus-browser example not being compiled any more, but
no changes to the installed files.

Thanks,
smcv

Bug#1039080: antigrav: FTBFS with libsdl1.2-compat-dev: missing build-dependencies

[Simon McVittie]

Source: antigrav
Version: 0.0.3-10
Severity: important
Tags: ftbfs trixie sid

I tried recompiling antigrav with libsdl1.2-compat-dev instead of
libsdl1.2-dev, in preparation for having src:sdl12-compat take over the
libsdl1.2-dev package name.

I found that antigrav failed to build from source due to several missing
build-dependencies: it requires pkg.m4 macros,  and ,
leading to errors such as:

> ./configure: line 5844: syntax error near unexpected token `SDL,'
> ./configure: line 5844: `PKG_CHECK_MODULES(SDL, sdl >= $min_sdl_version,'

or after installing pkgconf:

> checking for sdl >= 1.1.5... yes
> checking for GL/gl.h... no
> configure: error: *** OpenGL not found ***

I'm going to work around this by adding dependencies to
libsdl1.2-compat-dev, but please add explicit build-dependencies on
any packages that antigrav explicitly checks for.

Thanks,
smcv

Bug#1038017: adplay: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:29:14 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine, other than the
missing build-dependency on pkgconf that I reported as #1039074 (which
I intend to work around by making libsdl1.2-compat-dev depend on pkgconf).
I didn't test the resulting binaries.

smcv

Bug#1038016: adlibtracker2: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:28:56 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine. I didn't test
the resulting binaries.

smcv

Bug#1038015: achilles: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 12:28:35 +0100, Simon McVittie wrote:
> 4. Install libsdl1.2-compat-dev and recompile the package.

I tried this on a porterbox and it seems to build fine, other than
the missing build-dependency on libglu1-mesa-dev reported as #1039072
(which I'm going to work around by making libsdl1.2-compat-dev depend
on libsdl2-dev). I didn't test the resulting binaries.

smcv

Bug#1039074: adplay: FTBFS with libsdl1.2-compat-dev: missing build-dependency on pkgconf

[Simon McVittie]

Source: adplay
Version: 1.8.1-3
Severity: important
Tags: ftbfs trixie sid

I tried compiling adplay on a porterbox with libsdl1.2-compat-dev
instead of libsdl1.2-dev, in preparation for having a future version of
sdl12-compat take over the libsdl1.2-dev name.

I found that adplay FTBFS with:

> configure.ac:19: error: possibly undefined macro: AC_CHECK_LIB
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> configure.ac:19: error: possibly undefined macro: AC_MSG_ERROR
> configure.ac:21: error: possibly undefined macro: AC_MSG_WARN
> autoreconf: error: /usr/bin/autoconf failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1

This appears to be fixable by installing pkgconf, which this package
requires for the pkg.m4 macros.

With the old libsdl1.2-dev, pkgconf was pulled in by this dependency chain:

libsdl1.2-dev -> libpulse-dev -> libglib2.0-dev -> pkg-config -> pkgconf

As a pragmatic workaround for legacy software I'm going to make
libsdl1.2-dev depend on pkgconf, but please fix this properly by adding
Build-Depends on all the components that this package explicitly uses.

Thanks,
smcv

Bug#1039072: achilles: Missing build-dependency on libglu1-mesa-dev

[Simon McVittie]

Source: achilles
Version: 2-12
Severity: important
Tags: trixie sid ftbfs

achilles includes  but does not have the corresponding
build-dependency on libglu1-mesa-dev.

At the moment it compiles successfully anyway, because libsdl1.2-dev
pulls in libglu1-mesa-dev; but it fails to build when libsdl1.2-compat-dev
is installed, because libsdl1.2-compat-dev does not have that dependency.

I'm going to add a dependency on libsdl2-dev to libsdl1.2-compat-dev as a
workaround, but please give achilles explicit build-dependencies on all
the libraries that it requires.

Thanks,
smcv

Bug#1038805: gnubiff: Depends on unmaintained gamin

[Simon McVittie]

Source: gnubiff
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 1008205 by -1

This package has a Depends or Build-Depends on gamin, which is unmaintained
upstream (see #1008205).

For software that already depends on GLib, GFileMonitor
(g_file_monitor_file(), g_file_monitor_directory(), g_file_monitor())
is a good replacement.

We shouldn't really be shipping gamin in Debian 13, so this is likely to
become release-critical in future.

Thanks,
smcv

Bug#1038566: tdfsb: Depends on SDL 1.2

[Simon McVittie]

Source: tdfsb
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038563: starvoyager: Depends on SDL 1.2

[Simon McVittie]

Source: starvoyager
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038511: mp3blaster: Depends on SDL 1.2

[Simon McVittie]

Source: mp3blaster
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038508: moon-lander: Depends on SDL 1.2

[Simon McVittie]

Source: moon-lander
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038499: mazeofgalious: Depends on SDL 1.2

[Simon McVittie]

Source: mazeofgalious
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038494: wizznic: Depends on SDL 1.2

[Simon McVittie]

Source: wizznic
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038491: xmms2: Depends on SDL 1.2

[Simon McVittie]

Source: xmms2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038484: zatacka: Depends on SDL 1.2

[Simon McVittie]

Source: zatacka
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038364: glob2: Depends on SDL 1.2

[Simon McVittie]

Source: glob2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038362: gl-117: Depends on SDL 1.2

[Simon McVittie]

Source: gl-117
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038363: glhack: Depends on SDL 1.2

[Simon McVittie]

Source: glhack
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038345: fische: Depends on SDL 1.2

[Simon McVittie]

Source: fische
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Please don't change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
The -compat packages have Provides for the old package names, and my
intention is to make a future version of sdl12-compat take over the old
package names, to minimize the changes that are required in dependent
packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038188: devil: Depends on SDL 1.2

[Simon McVittie]

Source: devil
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038180: csmash: Depends on SDL 1.2

[Simon McVittie]

Source: csmash
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038102: lv-tool-0.4: Depends on SDL 1.2

[Simon McVittie]

Package: lv-tool-0.4
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038099: libdv-bin: Depends on SDL 1.2

[Simon McVittie]

Package: libdv-bin
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038073: magicmaze: Indirectly depends on SDL 1.2

[Simon McVittie]

Source: magicmaze
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package depends on ruby-sdl, which is a language binding for SDL 1.2.
SDL 1.2 has been superseded by SDL 2 and is unmaintained upstream.

If possible, please port this package to SDL 2.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038051: blobandconquer: Depends on SDL 1.2

[Simon McVittie]

Source: blobandconquer
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

I did some brief testing on this package as part of some upstream work on
libsdl1.2-compat-shim and it seemed to work well, but I was not able to
test it thoroughly.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038024: antigrav: Depends on SDL 1.2

[Simon McVittie]

Source: antigrav
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

I did some brief testing on this package as part of some upstream work on
libsdl1.2-compat-shim and it seemed to work well, but I was not able to
test it thoroughly.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038017: adplay: Depends on SDL 1.2

[Simon McVittie]

Source: adplay
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038016: adlibtracker2: Depends on SDL 1.2

[Simon McVittie]

Source: adlibtracker2
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038015: achilles: Depends on SDL 1.2

[Simon McVittie]

Source: achilles
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

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. There
is a migration guide at ,
and 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.

Note that using libsdl1.2-compat and LD_LIBRARY_PATH is not sufficient if
the package contains programs that are setgid games. See

for more information.

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.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1037374: giggle: build-depends on transitional package libgdk-pixbuf2.0-dev

[Simon McVittie]

Source: giggle
Version: 0.7-5
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: split-gdk-pixbuf

This package Build-Depends on libgdk-pixbuf2.0-dev.

In Debian 11, libgdk-pixbuf2.0-dev was split into two packages:

- libgdk-pixbuf-2.0-dev contains the supported gdk-pixbuf-2.0 library

- libgdk-pixbuf-xlib-2.0-dev contains the deprecated, unmaintained
  Xlib integration layer, gdk-pixbuf-xlib-2.0

If this package only requires functionality from gdk-pixbuf-2.0.pc
and , please update the build-dependency to
libgdk-pixbuf-2.0-dev.

If it also requires the Xlib integration gdk-pixbuf-xlib-2.0.pc and
 (unlikely), then you can also build-depend on
libgdk-pixbuf-xlib-2.0-dev until the package can be updated to remove
that requirement.

libgdk-pixbuf-2.0-dev was present in both Debian 11 and Debian 12, so
it is not necessary to have a "| libgdk-pixbuf2.0-dev" alternative
dependency, even for packages that are expected to be backported.

We should remove the libgdk-pixbuf2.0-dev transitional package during
the Debian 13 'trixie' cycle, so this bug is likely to become RC later.

Thanks,
smcv

Bug#1037045: blobandconquer: fails to start with Xwayland: Couldn't set 800x600 video mode: Couldn't find matching GLX visual

[Simon McVittie]

Package: blobandconquer
Version: 1.11-dfsg+20-2
Severity: important

To reproduce:

* GNOME 43 in its default Wayland mode, with Xwayland available
* either of:
* "classic" SDL 1.2 (libsdl1.2debian version 1.2.15+dfsg2-8 tested)
* sdl12-compat (libsdl1.2-compat-shim version 1.2.64 tested)
* run blobAndConquer

Expected result: gameplay

Actual result:

[DEBUG (0)] Pak : Filename set to 
/usr/share/games/blobAndConquer/blobAndConquer.pak
[DEBUG (0)] initSystem()
[DEBUG (0)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/savedata 
does not exist
[DEBUG (118)] Query stencil support: has stencils: 1
[DEBUG (118)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/config 
does not exist
[DEBUG (118)] User Home = /home/smcv/.parallelrealities/blobAndConquer
[DEBUG (118)] Graphics::setResolution() - 0: 800 x 600
Couldn't set 800x600 video mode: Couldn't find matching GLX visual
[DEBUG (119)] Cleaning Up...
[DEBUG (119)] Deleting Tracer...
[DEBUG (119)] Freeing Audio...
[DEBUG (119)] Removing Temp File...
[DEBUG (119)] Saving Config...
[DEBUG (119)] Removing PAK File Data...
[DEBUG (119)] Closing Audio...
[DEBUG (119)] Freeing Game Data...
[DEBUG (119)] Freeing Remaining Entities...
[DEBUG (119)] Freeing Widgets...
[DEBUG (119)] Freeing Sprites and Fonts
[DEBUG (119)] Freeing Textures...
[DEBUG (119)] Freeing Models...
[DEBUG (119)] Closing TTF...
[DEBUG (119)] Quitting SDL...
[DEBUG (0)] All Done.

Workaround (1): log out, and log in to "GNOME on Xorg" instead.

Workaround (2): install libsdl1.2-compat-shim *and* run with
SDL_VIDEODRIVER=wayland,x11 in the environment (which is not the default,
even with SDL 2, because it can cause regressions in other games)

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blobandconquer depends on:
ii  blobandconquer-data 1.11-dfsg+20-2
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libsdl-image1.2 1.2.12-13+b2
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl-ttf2.0-0 2.0.11-6
ii  libsdl1.2debian [local build using sdl12-compat 1.2.64]
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2
ii  zlib1g  1:1.2.13.dfsg-1

blobandconquer recommends no packages.

Versions of packages blobandconquer suggests:
pn  blobwars  

-- no debconf information

Bug#1021815: docbook-xsl: some title lengths result in incorrect escaping of TH line

[Simon McVittie]

Package: docbook-xsl
Version: 1.79.2+dfsg-2
Severity: normal

The ostree package has man pages written in Docbook XML and processed into
man pages via docbook.xsl. The one that has this bug is
man/ostree-admin-config-diff.xml, which contains:


ostree admin config-diff
1


I would expect this to be truncated into something like

.TH "OSTREE ADMIN CONFIG\-" "1" "" "OSTree" "ostree admin config-diff"

or

.TH "OSTREE ADMIN CONFIG" "1" "" "OSTree" "ostree admin config-diff"

which would render in man(1) like this:

> OSTREE ADMIN CONFIG(1)  ostree admin config-diffOSTREE ADMIN CONFIG(1)
> ... [content of man page here] ...
> OSTree  OSTREE ADMIN CONFIG(1)

However, it actually it comes out as

.TH "OSTREE ADMIN CONFIG\" "1" "" "OSTree" "ostree admin config-diff"

which has the effect of escaping the second double quote in the line,
resulting in parts of the header having an unintended interpretation:

> OSTREE ADMIN CONFIG()OSTREE ADMIN CONFIG()
> ... [content of man page here] ...
>  OSTREE ADMIN CONFIG()

I suspect that what has happened here is that the U+002D HYPHEN/MINUS in
the refentrytitle was escaped as \- before the title was truncated to fit
man page conventions, whereas it should have been truncated first and then
escaped second.

This is similar to #821235, in which single quotes are replaced by
\*(Aq before upper-casing, whereas the correct processing would have
probably been to upper-case first and then replace single quotes with
mixed-case \*(Aq afterwards.

smcv

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'oldstable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages docbook-xsl depends on:
ii  xml-core  0.18+nmu1

Versions of packages docbook-xsl recommends:
ii  docbook-xml  4.5-12

Versions of packages docbook-xsl suggests:
pn  dbtoepub
ii  docbook-xsl-doc-html [docbook-xsl-doc]  1.79.1-1
pn  docbook-xsl-saxon   
pn  fop 
pn  libsaxon-java   
ii  libxalan2-java  2.7.2-4
pn  libxslthl-java  
pn  xalan   

-- no debconf information

Bug#1018133: pinpoint: depends on unmaintained clutter-1.0 and related libraries

[Simon McVittie]

Source: pinpoint
Version: 1:0.1.8-5
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package depends on clutter-1.0, which is no longer maintained
upstream (and has been effectively unmaintained for a while).

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31 has some porting
notes for projects that are part of GNOME, which might be useful
inspiration for porting this package.

smcv

Bug#1018126: gthumb: depends on unmaintained clutter-1.0 and related libraries

[Simon McVittie]

Source: gthumb
Version: 3:3.12.2-1
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1

This package depends on clutter-1.0, which is no longer maintained
upstream (and has been effectively unmaintained for a while).

https://gitlab.gnome.org/GNOME/Initiatives/-/issues/31 has some porting
notes for projects that are part of GNOME, which might be useful
inspiration for porting this package.

smcv

Bug#1000259: RM: gnome-mime-data -- RoQA; orphaned, dead upstream for 10+ years, no longer used

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: gnome-mime-d...@packages.debian.org

gnome-mime-data seems to have been the equivalent of shared-mime-info for
the old gnome-vfs framework, which is no longer maintained or part of GNOME
(since GNOME 3.0 in 2011, maybe earlier) and was already removed from Debian.

All modern GNOME versions use freedesktop.org mechanisms involving
shared-mime-info, the same as other major desktop environments.

According to `dak rm -R -n gnome-mime-data`, nothing depends on
gnome-mime-data any more. Please remove it.

Thanks,
smcv

Bug#996077: extension compatibility with GNOME Shell 41

[Simon McVittie]

Control: severity -1 serious

On Sun, 10 Oct 2021 at 21:33:02 +0100, Simon McVittie wrote:
> The metadata.json for this extension doesn't declare compatibility with
> GNOME 41. I don't know whether the actual code will need changes or not:
> the conservative assumption is that it probably will (so please test).

gnome-shell 41 is now in unstable, so incompatibilities with that version
are now RC. Please upload an updated extension if one is available.

smcv

Bug#996077: gnome-shell-mailnag: does not declare compatibility with GNOME Shell 41

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 40.0-1
Severity: normal
Tags: bookworm sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-41

The metadata.json for this extension doesn't declare compatibility with
GNOME 41. I don't know whether the actual code will need changes or not:
the conservative assumption is that it probably will (so please test).
gnome-shell 41 should be available in experimental soon.

In versions of GNOME Shell up to 3.38, metadata.json didn't matter much,
because validation of extensions' metadata against the installed Shell
version was disabled by default; but since GNOME 40 the default has changed
back to enabling the version check by default, in an effort to avoid
issues caused by outdated extensions remaining enabled. As a result,
GNOME Shell extensions in bookworm should probably have a dependency like:

Depends: gnome-shell (>= x), gnome-shell (<< y~)

where x and y are set according to metadata.json.
gnome-shell-extension-caffeine is a good example of this technique.

When we do the GNOME Shell 41 transition, hopefully soon, we will have
to either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#993275: ng: stores wrong paths to cp and ls if built on merged-/usr system

[Simon McVittie]

On Fri, 17 Sep 2021 at 10:46:31 -0700, Vagrant Cascadian wrote:
> On 2021-08-29, Simon McVittie wrote:
> > If gnunet is built on a merged-/usr system
> 
> gnunet -> ng ? ... Or should this be reassigned to gnunet?

Sorry, that was copypasta from a previously-reported bug. ng and gnunet
both have bugs of this class. This one, #993275, is about ng's use of
cp and ls. The similar bug about gnunet's use of ifconfig is #993249.

> Since ng is maintained by QA, you could upload the fix yourself, or I
> may get to it in the coming weeks...

I don't know what ng is or how to test it, only how to build it and
throw it at diffoscope, so I'm unlikely to do a QA upload.

Looking at its package tracker page, it seems to be an Emacs-style
editor with CJK input support, and hasn't had an upstream release since
2003. I have to question whether this is something we really want in
the distribution, if nobody either inside or outside Debian wants to
maintain it...

smcv


signature.asc
Description: PGP signature

Bug#994159: opentmpfiles: abandoned by upstream developer

[Simon McVittie]

Source: opentmpfiles
Version: 0.3.1-2
Severity: important
Tags: upstream wontfix

I happened to notice that opentmpfiles is now unmaintained upstream:

> Since systemd-tmpfiles is a single binary which can be compiled and
> run without systemd, we have decided to retire this project. For more
> information see the related issue[1].
> [1] https://github.com/OpenRC/opentmpfiles/issues/19

If someone wants to maintain a non-systemd implementation of tmpfiles.d
in Debian, they should probably either become the upstream maintainer
of a fork of opentmpfiles that fixes its RC bugs, or package a different
implementation that does not suffer from CVE-2017-18925 (the upstream
issue mentions an implementation in Rust, but I don't know whether it's
production-ready).

systemd/experimental adds a systemd-standalone-tmpfiles binary package
that can be used on Linux ports without using systemd as pid 1, although
that isn't in unstable yet, and is probably not suitable for kFreeBSD or Hurd.

smcv

Bug#993203: transition: GNOME 40 (libmutter-8-0 and friends)

[Simon McVittie]

Control: severity -1 serious

On Sat, 28 Aug 2021 at 13:52:40 +0100, Simon McVittie wrote:
> as usual various third-party extensions will need either updating, or
> temporarily removing from testing

I've now uploaded gnome-shell 40 to unstable, so gnome-shell extensions
incompatible with that version will soon become uninstallable. See
#992870 for more information on this transition.

budgie-desktop is not directly related to gnome-shell, but it's part of
the libmutter transition, so it is in a similar situation.

If new versions suitable for this transition were uploaded
to experimental already, please upload to unstable, or ask
debian-gtk-gn...@lists.debian.org or #debian-gnome if a team upload or
NMU would be helpful.

If versions compatible with GNOME 40 are not yet available, please update
and test the extension if possible, or ask for its removal if it is not
feasible to update it.

Release team: you might want to remove incompatible extensions from
testing if they can't be fixed soon, leaving the incompatible version
available in unstable as a basis for updates. I'll try to follow up to
#992870 soon with a list of unfixed packages.

smcv

Bug#993932: gyrus: unmaintained upstream

[Simon McVittie]

Package: gyrus
Version: 0.3.12-1
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: Yavor Doganov , Jonathan Carter 

gyrus is unmaintained upstream, and has been archived and made read-only:
. Its most recent release was
in 2013.

The version in Debian is effectively a fork, moving it from GTK 2 to
GTK 3. However, there is no Debian maintainer since 2013 either
(see #732011). I don't think it's a good idea for Debian to contain
packages that nobody maintains, either upstream or downstream.

This particular program seems to be a network client, which means it is
probably security-sensitive. I'm also concerned that it's a special-purpose
administrative IMAP client, yet is documented to not support TLS/SSL.

If someone wants to maintain gyrus, I would recommend that they fork the
(abandoned) upstream project and become its new upstream maintainer.

Perhaps this package should be removed from testing/unstable? If anyone
wants it, they can retrieve the most recent version from bullseye.

smcv

Bug#993931: gyrus: depends on amtk which has been abandoned upstream

[Simon McVittie]

Source: gyrus
Version: 0.3.12-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs
Control: block 993922 by -1
X-Debbugs-Cc: Yavor Doganov , Jonathan Carter 

amtk has been frozen and archived upstream, and contributions are no longer
accepted. See https://gitlab.gnome.org/Archive/amtk and
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/564 for
more details.

The versions of gedit and devhelp on GNOME infrastructure stopped using
amtk at the same time they stopped using tepl, which is in a similar
situation (see #993909). I don't think amtk should be included in Debian 12.

The remaining packages that use amtk (genius, goodvibes and gyrus) will
either need to stop using amtk (and switch to making the same calls into
GTK that amtk does, but more directly), or fork it. If they fork it,
the former maintainer requests that they use a different name.

Note that in the case of this unmaintained Debian package, the use of amtk
is a Debian-specific patch (part of the port from GTK 2 to GTK 3) rather
than an upstream decision.

smcv

Re: Bug#978893: ripperx: ftbfs with autoconf 2.70

[Simon McVittie]

On Thu, 31 Dec 2020 at 14:28:53 +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.
...
> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/ripperx_2.8.0-2_unstable_ac270.log
> The last lines of the build log are at the end of this report.

I don't think those lines indicate the actual error, which looks like a C++
compiler problem (perhaps because the new Autoconf version passes options
that make the compiler more strict?):

> In file included from /usr/include/c++/10/ext/string_conversions.h:41,
>  from /usr/include/c++/10/bits/basic_string.h:6535,
>  from /usr/include/c++/10/string:55,
>  from /usr/include/c++/10/stdexcept:39,
>  from err_dialog_handler.h:6,
>  from common.h:21,
>  from calc_stat.h:3,
>  from calc_stat.c:1:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from /usr/include/c++/10/stdlib.h:36,
>  from cddbp.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from cddbp.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in 
> ‘std’
>65 | using std::malloc;
>   |^~
> In file included from /usr/include/c++/10/stdlib.h:36,
>  from cddb.c:6:
> /usr/include/c++/10/cstdlib:151:11: error: ‘malloc’ has not been declared in 
> ‘::’
>   151 |   using ::malloc;
>   |   ^~
> In file included from cddb.c:6:
> /usr/include/c++/10/stdlib.h:65:12: error: ‘malloc’ has not been declared in 
> ‘std’
>65 | using std::malloc;
>   |^~

I tried to reproduce this in sbuild and got a different error:

> checking for strndup... (cached) yes
> checking for strstr... (cached) yes
> checking for openpty... no
> checking for openpty in -lutil... no
> configure: error: Missing required function: openpty
>   tail -v -n \+0 config.log
> ==> config.log <==
...
> configure:5959: checking for openpty
> configure:5959: g++ -o conftest -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c  >&5
...
> /usr/bin/ld: /tmp/ccVfJfLG.o: in function `main':
> ./conftest.c:65: undefined reference to `openpty'
> collect2: error: ld returned 1 exit status
| #ifdef __cplusplus
| extern "C"
| #endif
| char openpty ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS.  Some functions are actually named
| something starting with __ and the normal name is an alias.  */
| #if defined __stub_openpty || defined __stub___openpty
| choke me
| #endif
|
| int
| main (void)
| {
| return openpty ();
|   ;
|   return 0;
| }
...
> configure:5964: checking for openpty in -lutil
> configure:5987: g++ -o conftest -g -O2 -ffile-prefix-map=/<>=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c -lutil   >&5
> /usr/bin/ld: /tmp/ccvWpbnJ.o: in function `main':
> ./conftest.c:46: undefined reference to `openpty()'
...
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply.  */
| char openpty ();
| int
| main (void)
| {
| return openpty ();
|   ;
|   return 0;
| }

This new error might be an Autoconf bug: the second check (with -lutil)
looks like it's missing an extern "C" on the prototype. If so,
http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=b27bc3e230bb12fdd9a813e38e82bc4c3e22b4cc
might help.

smcv

Bug#993743: xdemorse: autopkgtest regression: warning on stderr

[Simon McVittie]

On Sun, 05 Sep 2021 at 21:57:18 +0200, Paul Gevers wrote:
> (xdemorse:3992): dbind-WARNING **: 01:17:04.875: AT-SPI: Error
> retrieving accessibility bus address:
> org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
> provided by any .service files

To avoid this warning, either depend on at-spi2-core (if you need
accessibility technologies), or export NO_AT_BRIDGE=1 (if you don't need
accessibility technologies and just want to silence the warning).

The gtk+3.0 source package currently has examples of both methods in its
autopkgtests. The installed-tests depend on at-spi2-core (some of them use
accessibility interfaces to remote-control a GTK app, I think), and the
superficial python3-gi test sets NO_AT_BRIDGE=1.

smcv

Bug#993275: ng: stores wrong paths to cp and ls if built on merged-/usr system

[Simon McVittie]

Source: ng
Version: 1.5~beta1-9
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If gnunet is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the paths to cp and
ls are recorded in the binary package as being in /usr/bin, rather than the
canonical /bin.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ng.html

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends=usrmerge and once without.

I suspect the same thing would happen if ng was built on a system where
/bin and /usr/bin had instead been unified via a symlink farm.

The problematic situation is if the package is *built* on a unified-/usr
system, but *used* on a non-unified-/usr system. In this situation,
/usr/bin/cp, etc. exist on the build system but not on the system where
the package will be used, resulting in the features that use this
executable not working correctly.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends=usrmerge.

Some developers advocate unifying /bin with /usr/bin via a symlink farm
in /bin instead of merged-/usr, but that strategy would have a similar
practical effect on this particular package, and the same solution would
be required.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From 483dd087b93e02d30a7bf1f022c35d3f88f74d07 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 29 Aug 2021 22:15:25 +0100
Subject: [PATCH] d/rules: Specify canonical paths of cp, ls, mv, rmdir

When ng is built on a system where both /usr/bin/cp and /bin/cp
exist (either merged-/usr or via a symlink farm), this results in storing
/usr/bin/cp in the installed programs, which will not work as intended
on systems where only the traditional path /bin/cp exists.

ls is in a similar situation. mv and rmdir are checked by ./configure
but not hard-coded anywhere; give them the same treatment for symmetry.

Signed-off-by: Simon McVittie 
---
 debian/rules | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/debian/rules b/debian/rules
index 3363b4b..9f0f48b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,13 @@ export CC
 
 DOCDIR = usr/share/doc/ng-common
 
+configure_environment = \
+	ac_cv_path_cp_cmd=/bin/cp \
+	ac_cv_path_ls_cmd=/bin/ls \
+	ac_cv_path_mv_cmd=/bin/mv \
+	ac_cv_path_rmdir_cmd=/bin/rmdir \
+	$(NULL)
+
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
@@ -34,21 +41,21 @@ build-stamp:
 
 	# vanilla ng-latin
 	cp -p debian/config-latin.h config.h
-	./configure
+	$(configure_environment) ./configure
 	$(MAKE)
 	mv ng ng-latin
 	$(MAKE) confclean
 
 	# ng-cjk
 	cp -p debian/config-cjk.h config.h
-	./configure
+	$(configure_environment) ./configure
 	$(MAKE)
 	mv ng ng-cjk
 	$(MAKE) confclean
 
 	# ng-cjk-canna
 	cp -p debian/config-cjk-canna.h config.h
-	./configure --enable-canna
+	$(configure_environment) ./configure --enable-canna
 	$(MAKE) CANNADEF="-DCANNA" CANNALIB="-lcanna"
 	cp -p ng ng-cjk-canna
 
-- 
2.33.0

Bug#993203: gnome-shell-mailnag: does not declare compatibility with GNOME Shell 40

[Simon McVittie]

Package: gnome-shell-mailnag
Version: 3.38.1-1
Severity: important

The metadata.json for this extension doesn't declare compatibility with
GNOME 40. I don't know whether the actual code will need changes.

In many versions of GNOME Shell, metadata.json didn't matter much, because
validation of extensions' metadata against the installed Shell version
was disabled by default; but in GNOME 40 the default has changed back
to enabling the version check by default, in an effort to avoid issues
caused by outdated extensions remaining enabled.

When we do the GNOME 40 transition, hopefully soon, we will have to
either update this extension or remove it from testing. It would be
useful to get a fixed version into experimental.

Thanks,
smcv

Bug#983423: Bug#856877: schroot: Please mount a new instance of /dev/pts

[Simon McVittie]

On Sun, 05 Mar 2017 at 19:23:40 +, Simon McVittie wrote:
> the preferred way to
> set up /dev/pts inside containers in recent kernels is to mount a new
> instance of the devpts filesystem on /dev/pts
...
> In particular, this would make the chroots created by debootstrap
> versions 1.0.76 to 1.0.88 (inclusive) work as expected.
...
> A nice side-effect of this change, which I discovered while testing a
> cut-down version of the same code in a new debootstrap autopkgtest, is
> that it makes script(1) work inside "schroot --sbuild" inside a LXC
> container on a Debian jessie kernel. Previously, that would have failed.

On Tue, 23 Feb 2021 at 23:55:07 +, Simon McVittie wrote:
> schroot: Default profile doesn't provide a working /dev/ptmx inside lxc >= 3
...
> The same patch I proposed in 2017 for #856877 resolves this, setting
> up a working /dev/ptmx.  Under lxc 2 it's a symlink to /dev/ptx/ptmx,
> and under lxc >= 3 it's a device node.
>¯
> Under lxc 4, that patch also provides a working /dev/console.

Here's the patch I proposed in 2017, with an updated commit message.

Also available as a merge request:
https://salsa.debian.org/debian/schroot/-/merge_requests/2

smcv
From: Simon McVittie 
Date: Mon, 20 Feb 2017 10:43:24 +
Subject: Mount a new instance of /dev/pts in the chroot

This avoids various failure modes when schroot is run inside some other
container manager, such as lxc, most commonly manifesting as inability
to run programs that create pseudo-terminals such as script(1).

Mounting a new instance of devpts is considered to be
best-practice for container managers in Linux >= v2.6.29 with
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. That config option was made
unconditional in v4.7.

This has some assumptions, which cannot be avoided if we are going to
mount /dev/pts using schroot's fstab:

* If the kernel is older than v4.7, it is assumed to be v2.6.29 or
  later with CONFIG_DEVPTS_MULTIPLE_INSTANCES=y. Users of older kernels,
  or intermediate versions with CONFIG_DEVPTS_MULTIPLE_INSTANCES=n,
  can revert this change via /etc.

* gid 5 must be the right owner for ptys. This is correct for Debian
  (it's the hard-coded tty group specified in base-passwd) and probably
  many other distributions (it's systemd's configure-time default) but
  not necessarily correct everywhere. However, if the host system and the
  chroot disagree on the right gid, schroot's previous behaviour would
  have been wrong anyway, because it bind-mounted the host's /dev/pts.

* /dev/ptmx inside the chroot must be either a real device node (as
  created by debootstrap < 1.0.76, and debootstrap >= 1.0.89 if possible)
  or a symlink to pts/ptmx (as created by debootstrap between 1.0.76 and
  1.0.88 inclusive, and by debootstrap >= 1.0.89 if run in a container
  whose seccomp rules do not allow it to create the device node, such
  as systemd-nspawn).

Bind-mounting /dev/pts/ptmx over /dev/ptmx, so that we get the
new instance's /dev/ptmx equivalent instead of the host's, can only
be done from code, so I have done it in the 10mount hook instead of
in the fstab.

To keep the host system terminal on which we were invoked (which might
itself be a pty, from a different instance of /dev/pts) available to
the chroot, bind-mount it onto /dev/console. This is the same trick
used in the lxc and systemd-nspawn Linux container managers.

Bug-Debian: https://bugs.debian.org/856877
Bug-Debian: https://bugs.debian.org/983423
Signed-off-by: Simon McVittie 
---
 etc/profile-templates/buildd/linux/fstab  |  2 +-
 etc/profile-templates/default/linux/fstab |  2 +-
 etc/profile-templates/desktop/linux/fstab |  2 +-
 etc/profile-templates/sbuild/linux/fstab  |  2 +-
 etc/setup.d/10mount   | 27 +++
 5 files changed, 31 insertions(+), 4 deletions(-)

diff --git a/etc/profile-templates/buildd/linux/fstab b/etc/profile-templates/buildd/linux/fstab
index 26efe88..f2f6136 100644
--- a/etc/profile-templates/buildd/linux/fstab
+++ b/etc/profile-templates/buildd/linux/fstab
@@ -1,4 +1,4 @@
-/dev/pts/dev/ptsnonerw,bind 0   0
+/dev/pts/dev/ptsdevpts  rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0
 tmpfs   /dev/shmtmpfs   defaults0   0
 # Mount a large scratch space for the build, so we don't use up
 # space on an LVM snapshot of the chroot itself.
diff --git a/etc/profile-templates/default/linux/fstab b/etc/profile-templates/default/linux/fstab
index 777f0ed..181ed80 100644
--- a/etc/profile-templates/default/linux/fstab
+++ b/etc/profile-templates/default/linux/fstab
@@ -1,5 +1,5 @@
 /dev/devnonerw,bind 0   0
-/dev/pts/dev/ptsnonerw,bind 0   0
+/dev/pts/dev/ptsdevpts  rw,newinstance,ptmxmode=666,mode=620,gid=5 0 0
 /home   /home   nonerw,bind 0  

Bug#983423: schroot: Default profile doesn't provide a working /dev/ptmx inside lxc >= 3

[Simon McVittie]

Package: schroot
Version: 1.6.10-11
Severity: normal

Steps to reproduce
--

(Replace or remove the http proxy http://192.168.122.1:3142 as required.)

sudo apt install lxc autopkgtest
(configure lxc as per [1])
sudo AUTOPKGTEST_APT_PROXY=http://192.168.122.1:3142 autopkgtest-build-lxc 
debian sid amd64
sudo lxc-copy --ephemeral -n autopkgtest-sid-amd64 -N temp
sudo lxc-attach -n temp

and then inside the lxc container:

apt install debootstrap schroot
http_proxy=http://192.168.122.1:3142 debootstrap sid /sid
cat > /etc/schroot/chroot.d/sid = 3 it's a device node.

Under lxc 4, that patch also provides a working /dev/console.

I'll re-send the patch with both bug numbers included when I have a
bug number for this report.

smcv

Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Simon McVittie]

Control: severity -1 serious

On Thu, 10 Dec 2020 at 14:37:21 +, Mike Gabriel wrote:
> On  Do 10 Dez 2020 15:35:19 CET, Paul Gevers wrote:
> > We're running into the freeze of bullseye soon. The first bug I checked
> > is still only severity important, so is it realistic to get this done
> > before bullseye release? [...]
> > If yes, action is needed, this isn't going to happen
> > magically. At the least raising the blocking bugs to severity serious.
> 
> I'd suggest to raise severity of the still open bugs and get libappindicator
> kicked out before the bullseye release.
> 
> The fixes are easy to be done. Maintainers can ping me if they have problems.

Raising the blocking bugs to RC as requested.

> I am not so experienced with effective mass manipulation of bugs, Simon,
> could you bump the severity of the respective bugs?

There's no magic to it, you just send mail to the affected bug address(es)
with appropriate Control commands.

smcv

Bug#972126: libopendbx: Please remove support for long-unmaintained sqlite 2

[Simon McVittie]

Package: libopendbx1-sqlite
Version: 1.4.6-14
Severity: important
Tags: bullseye sid
User: debian...@lists.debian.org
Usertags: libsqlite0
Control: block 607969 by -1

libopendbx builds a libopendbx1-sqlite binary package. This is a wrapper
for sqlite 2, which was superseded in 2004 and is planned to be removed
(see #607969), and nothing in Debian seems to depend on it. Please remove
the libopendbx1-sqlite binary package.

This bug is currently non-RC, but is very likely to become RC soon.

Thanks,
smcv

Bug#969273: gnome-shell-extension-weather: Error loading the extension.

[Simon McVittie]

Control: retitle -1 gnome-shell-extension-weather: Incompatible with GNOME 
Shell 3.36

On Sun, 30 Aug 2020 at 16:07:45 +0200, Djalil Chafaï wrote:
> The extension is not loaded by Gnome. 
> 
> The gnome-tweaks displays for it a triangle with an exclamation mark.

On Sun, 06 Sep 2020 at 13:55:09 +0800, Paul Wise wrote:
> I have this issue too and I note that GNOME shell Looking Glass gives:
> 
> TypeError: this.actor.reparent is not a function

This extension is currently unmaintained in Debian and has only had
QA uploads since 2016. If you rely on it, please consider taking over
its maintenance, either as part of the GNOME team or independently:
see #828694.

Note that as outlined on #828694, there is more than one possible upstream
developer to be following.
https://extensions.gnome.org/extension/613/weather/ seems to correspond to
https://github.com/Neroth/gnome-shell-extension-weather while
https://extensions.gnome.org/extension/750/openweather/ seems to correspond
to https://gitlab.com/jenslody/gnome-shell-extension-openweather/
(formerly https://github.com/jenslody/gnome-shell-extension-openweather
which no longer exists). I don't know whether they use the same UUID
or different UUIDs.

smcv

Bug#967583: libindicator: depends on deprecated GTK 2

[Simon McVittie]

Control: tags -1 + upstream wontfix

On Tue, 04 Aug 2020 at 11:47:16 +0100, s...@debian.org wrote:
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.

This package is dead upstream, so this bug won't be fixed.
The replacement is libayatana-indicator (see #895038).

Please leave this bug open (unless/until the package is removed), so we
can use it to track how many packages still depend on GTK 2.

Thanks,
smcv

Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Simon McVittie]

On Wed, 15 Apr 2020 at 19:06:59 +, Mike Gabriel wrote:
> On  Mi 15 Apr 2020 10:49:03 CEST, Simon McVittie wrote:
> > I've done that for you.
> 
> Thanks for that. What is the exact BTS query to list those bugs?

Sorry, I don't know the CLI for it, but I made them block 895037/895038
as appropriate, and applied the same usertags you mentioned earlier in
the bug(s). For pre-existing bugs I just added blocks, so some of them
might not be usertagged correctly.

libappindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895037 (look at "Fix blocked 
by")
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=ayatana-appindicator=pkg-ayatana-devel%40lists.alioth.debian.org

libindicator:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895038
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=ayatanaindicators=pkg-ayatana-devel%40lists.alioth.debian.org

smcv

Bug#895037: Bug#895038: libappindicator: deprecated in Debian; AppIndicator based applications, please switch to Ayatana (App)Indicator(s)

[Simon McVittie]

On Thu, 02 Apr 2020 at 14:11:42 +0200, Ivo De Decker wrote:
> On Mon, Oct 22, 2018 at 10:13:32AM +, Mike Gabriel wrote:
> > > # Broken Depends:
> 
> [...]
> 
> > The above list is irrelevant, what counts are the build-deps.
> 
> Well, this was the output of dak rm. These dependencies need to be resolved
> someway before the removal can be done.

For packages like redshift that do not require binary packages built by
libappindicator at build-time but only at runtime (mostly Python code using
gir1.2-appindicator* via pygobject), there are no Build-Depends, but
the Depends do matter.

`dak rm` is the tool that the ftp team would use if they removed
lib(app)indicator from unstable, so if you want lib(app)indicator to be
removed, all the packages that `dak rm` is concerned about will need to be
either removed or fixed.

> > > To help the overview of what's still missing, it might be good to add
> > > blocking
> > > bugs for every package to this one.
> 
> It seems this wasn't done. Please add blocking bugs to this bug, so it's easy
> to see what's missing.

I've done that for you.

> If you want to get this done for bullseye, please upgrade these bugs to
> serious. Autoremovals will take care of some of the packages. The rest will
> need manual fixes.

I haven't done that. I think the severity of these bugs is a decision
for the maintainer of the replacement to make.

smcv

Bug#956164: gnome-shell-extension-weather: please check compatibility with GNOME Shell 3.36.x

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0~20170402.git34506a6-2
Severity: important
Tags: bullseye sid upstream
Control: block 954422 by -1
Forwarded: 
https://gitlab.com/jenslody/gnome-shell-extension-openweather/-/issues/260

GNOME Shell 3.36.x is currently in experimental, and should hopefully
be heading to unstable soon. Please check whether this extension is
compatible.

You'll probably want to add a Recommends or even Depends on
gnome-shell-extension-prefs, a new package split out from gnome-shell that
is meant to be taking over responsibility for enabling and disabling
extensions from gnome-tweaks (at the moment they both offer this,
but there's a gnome-tweaks merge request open to remove the duplicate
functionality).

One thing that is definitely not compatible is that this extension runs:

Util.spawn(["gnome-shell-extension-prefs", 
"openweather-extens...@jenslody.de"]);

This is no longer supported since GNOME Shell 3.36.1:
gnome-shell-extension-prefs no longer takes a UUID as a command-line
argument. Some of the Debian GNOME team have wondered whether it's
feasible to patch back in, but the code involved is surprisingly
extensive, so the answer might be no.

As far as I can tell from GNOME Shell's upstream commit history, the
preferred way to launch extension preferences in sufficiently recent
versions is to call imports.misc.extensionUtils.openPrefs(), which
was added by gnome-shell!1163. It isn't in 3.36.1, but the version
in experimental (which is halfway between upstream 3.36.1 and 3.36.2)
does have it.

To support older GNOME versions, fall back to the spawn call if
imports.misc.extensionUtils doesn't have an openPrefs method.

Sample code:
https://github.com/Tudmotu/gnome-shell-extension-clipboard-indicator/pull/203

Thanks,
smcv

Bug#952014: freedink: FTBFS: input.cpp:94:15: error: ‘SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH’ was not declared in this scope

[Simon McVittie]

On Sun, 23 Feb 2020 at 08:32:42 +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > input.cpp: In function ‘void input_init()’:
> > input.cpp:94:15: error: ‘SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH’ was not 
> > declared in this scope
> >94 |   SDL_SetHint(SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH, "0");

This appears to have been caused by SDL2 having been upgraded to 2.0.10.
>From SDL2's WhatsNew.txt:

> * Added the hint SDL_HINT_MOUSE_TOUCH_EVENTS to control whether SDL will 
> synthesize touch events from mouse events
...
> Android:
...
> * Removed SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH (replaced by 
> SDL_HINT_MOUSE_TOUCH_EVENTS and SDL_HINT_TOUCH_MOUSE_EVENTS)
>   SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=1, should be replaced by setting 
> both previous hints to 0.
>   SDL_HINT_ANDROID_SEPARATE_MOUSE_AND_TOUCH=0, should be replaced by setting 
> both previous hints to 1.

smcv

Bug#947878: gnome-mime-data: unmaintained upstream for over a decade be removed

[Simon McVittie]

Source: gnome-mime-data
Version: 2.18.0-2
Severity: important
Tags: upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs unmaintained-upstream gnome-mime-data

gnome-mime-data was most recently released in 2007. From its contents
it appears to be related to gnome-vfs, which was removed from Debian
last year.

Modern versions of GNOME (and all other major desktop environments) use
the freedesktop.org shared-mime-info package for MIME type information.

Only one package depends on gnome-mime-data, namely chemical-mime-data.

smcv

Bug#938884: python-zeitgeist (binary) removal blocked by gtk-doc

[Simon McVittie]

On Sun, 22 Sep 2019 at 17:15:55 +0200, Andreas Henriksson wrote:
> Once the two applications using python-zeitgeist stops doing that,
> disabling the use of python2 use in zeitgeist build is still not
> super trivial. The reason is that zeitgeist needs python(3)-rdflib
> to generate the onthologies and the configure.ac uses the AM_PATH_PYTHON
> macro that will find python2 before python3.

It should be possible to add PYTHON=/usr/bin/python3
to the (dh_auto_)configure command-line (preferred), or
export it as an environment variable (as was done in 1.0.1-0.1, see
;
this is less preferred than adding it to the configure command line).
This means the new version of gtk-doc isn't required.

I see Boyuan Yang has imported zeitgeist into
 and started to update it
to version 1.0.2. Are you intending to adopt this package? (If not,
https://salsa.debian.org/debian/zeitgeist/ seems like a good place to
prepare QA uploads.)

smcv

Bug#898949: schroot: PAM config should use common-session-noninteractive

[Simon McVittie]

On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:
> On systems with libpam-systemd installed using common-session will
> create a logind session which schroot should not do.

In particular, creating a logind session results in $XDG_RUNTIME_DIR
being set inside the chroot, to a path that only exists outside the chroot.

Packages that use $XDG_RUNTIME_DIR are expected to have some sort of
reasonable fallback behaviour if it is not set at all (for example
dbus disables the features that need it, and some other packages use
~/.cache/foo as a fallback version of $XDG_RUNTIME_DIR/foo), but they
often do not have a graceful fallback path if $XDG_RUNTIME_DIR is set
to a path that is inaccessible, on the basis that they should do their
best to obey explicit requests from the user/environment ("the user is
always right").

smcv

Bug#917786: gnome-shell-extension-weather: please update gnome-tweak-tool recommendation to gnome-tweaks

[Simon McVittie]

Package: gnome-shell-extension-weather
Version: 0~20170402.git34506a6-1
Severity: wishlist
Tags: buster sid

gnome-shell-extension-weather Recommends gnome-tweak-tool, but since
buster that's a transitional package. Please change the recommendation
to gnome-tweaks.

smcv

Re: Bug#914285: dbus: system bus logs repeated denials for session buses calling GetDynamicUsers() on systemd Manager lines

[Simon McVittie]

Control: reassign -1 systemd-shim
Control: severity -1 important
Control: retitle -1 systemd-shim: prevents calling GetDynamicUsers() and other 
recent APIs on systemd Manager

On Wed, 21 Nov 2018 at 17:24:41 +0100, Francesco Potortì wrote:
> >... so perhaps you have a  rule in /usr/share/dbus-1/system.d/*.conf
> >or in /etc/dbus-1/system.d/*.conf, with higher precedence,
> >that is interfering with those messages? If you search for
> >org.freedesktop.systemd1 or GetDynamicUsers in those files, what do
> >you get?
> 
> fgrep -i -l org.freedesktop.systemd1 /etc/dbus-1/system.d/*.conf  
> /usr/share/dbus-1/system.d/*.conf  /usr/share/dbus-1/system.conf
> /etc/dbus-1/system.d/org.freedesktop.systemd-shim.conf
> /usr/share/dbus-1/system.d/org.freedesktop.systemd1.conf
> /usr/share/dbus-1/system.conf

Aha. Yes, in its current form, org.freedesktop.systemd-shim.conf is going
to break access to every systemd API that is meant to be public and was
added since systemd-shim forked it from systemd, because files in /etc
take precedence over files in /usr.

Workaround: purge the systemd-shim package (removing it is not enough,
because this is a conffile).

Real solution:

> ===File /etc/dbus-1/system.d/org.freedesktop.systemd-shim.conf===
...
> 
...
> 
> 

org.freedesktop.systemd-shim.conf should not have this Deny line. It's
redundant with the implicit default-deny in system.conf, and is going to
break the file installed by the real systemd.

systemd should perhaps mitigate this bug for buster by moving its bus
configuration from /usr/share/dbus-1 back into /etc/dbus-1, and choosing
a filename that is higher precedence than systemd-shim's. (Sorry, I don't
immediately know whether that means earlier or later in ASCII order.)

smcv

Bug#912962: obex-data-server: recommends transitional python-gobject, and indirectly, deprecated python-gobject-2

[Simon McVittie]

Package: obex-data-server
Version: 0.4.6-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs python-gobject
Tags: buster sid
Control: block 912946 by -1

This package recommends python-gobject, which is a transitional package
that depends on both:

* python-gobject-2, the old "static" Python binding for GLib and GObject;
* python-gi, the new GObject-Introspection binding

Presumably only one of those recommendations is actually useful.

python-gobject-2 is only available for Python 2, and is unmaintained
upstream. Python 2 will also reach end-of-life upstream during the
lifetime of Debian 10 'buster'. Please port dependent packages to use
PyGI (the python-gi or python3-gi packages in Debian), which is the
GObject-Introspection-based replacement for python-gobject-2.

More information about porting from the static bindings is available here:
https://pygobject.readthedocs.io/en/latest/guide/porting.html

python-gobject-2 and Python 2 will probably be removed from Debian during
the bullseye release cycle, and the python-gobject transitional package
will also need to be removed.

Thanks,
smcv

Bug#912958: python-gpod: depends on deprecated python-gobject-2

[Simon McVittie]

Package: python-gpod
Version: 0.8.3-13
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygobject-2
Tags: buster sid
Control: block 912946 by -1

This package depends on python-gobject-2, which is the old "static"
Python binding for GLib and GObject.

python-gobject-2 is only available for Python 2, and is unmaintained
upstream. Python 2 will also reach end-of-life upstream during the
lifetime of Debian 10 'buster'. Please port dependent packages to use
PyGI (the python-gi or python3-gi packages in Debian), which is the
GObject-Introspection-based replacement for python-gobject-2.

More information about porting from the static bindings is available here:
https://pygobject.readthedocs.io/en/latest/guide/porting.html

python-gobject-2 and Python 2 will probably be removed from Debian during
the bullseye release cycle, so the severity of this bug is likely to be
increased to serious after the buster release.

Thanks,
smcv

Re: Bug#895025: deprecate/remove libindicate in Debian

[Simon McVittie]

Control: block 895025 by 857260
Control: severity 857260 serious

On Mon, 02 Jul 2018 at 10:38:53 +0100, Simon McVittie wrote:
> On Fri, 06 Apr 2018 at 10:58:00 +, Mike Gabriel wrote:
> > So, in a nutshell, these packages need to be addressed: smuxi,
> > pidgin-libnotify and mopidy-mpris require changes to have libindicate
> > removed from Debian.
> 
> If you do not intend to ship libindicate in buster, should the remaining
> bugs blocking #895025 (#895027 in smuxi and #895026 in pidgin-libnotify)
> inherit RC severity from this one?

dak says libappindicator also needs changes if you want to
remove libindicate from buster (I already opened #857260 some time
ago). libappindicator is RC-buggy already, so escalating #857260 to RC
severity doesn't seem harmful; but there are rather more packages that
depend on libappindicator, so it will probably take longer to remove than
libindicate, and it might be worthwhile for people with an interest in
indicators to do a QA upload to fix #857260.

smcv@coccia ~ % dak rm -R -n -s testing libindicate
...
# Broken Depends:
pidgin-libnotify: pidgin-libnotify
smuxi: smuxi-frontend-gnome

# Broken Build-Depends:
libappindicator: libindicate-dev (>= 0.2.0)
 libindicate-gtk-dev (>= 0.2.0)
pidgin-libnotify: libindicate-dev (>= 0.6.90)
  libindicate-gtk-dev (>= 0.6.90)

(I get the same report for removal from unstable.)

Regards,
smcv

Bug#895025: deprecate/remove libindicate in Debian

[Simon McVittie]

On Fri, 06 Apr 2018 at 10:58:00 +, Mike Gabriel wrote:
> So, in a nutshell, these packages need to be addressed: smuxi,
> pidgin-libnotify and mopidy-mpris require changes to have libindicate
> removed from Debian.

If you do not intend to ship libindicate in buster, should the remaining
bugs blocking #895025 (#895027 in smuxi and #895026 in pidgin-libnotify)
inherit RC severity from this one?

smcv

Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)

[Simon McVittie]

On Sat, 06 Jan 2018 at 03:01:35 +0100, Axel Beckert wrote:
> Axel Beckert wrote:
> > I don't know if that test suite failure shows that expat broke libnih
> > or if the test suite just needs to be adapted to the new expat
> > version.
> >  
> > -   TEST_FILE_EQ (output, ("test:foo:2:0: "
> > +   TEST_FILE_EQ (output, ("test:foo:1:36: "
> >"Invalid object path in  name 
> > attribute\n"));
> > TEST_FILE_END (output);
> > TEST_FILE_RESET (output);

It certainly seems more true to say that the error in
"\n" is at line 1 column 36 (the
closing double quote around the invalid object path) than at line 2
column 0 (after the newline).

> I'd appreciate some more eyes on that change as I have not much of an
> idea of libnih's guts.

I have no idea about how libnih works, but the change looks harmless at
worst - it's not as if it changes the behaviour of non-test code, and the
new output looks more correct than the old. (My only interest in libnih
is in keeping libpam-systemd installable on buildds.)

smcv

Bug#886416: libnih: uninstallable, and FTBFS when rebuilt: FAIL test_parse (unexpected line numbering)

[Simon McVittie]

Source: libnih
Version: 1.0.3-9
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Affects: systemd-shim

libnih was made uninstallable by the glibc 2.26 transition, because it
uses internal glibc symbols. Normally this would be handled by a simple
rebuild. However, the recent binNMU of libnih against glibc 2.26 failed:

> Testing parse_xml()
> ...
> BAD: wrong content in file 0x13be5e730 (output), expected 'test:foo:2:0: 
> Invalid object path in  name attribute
> ' got 'test:foo:1:36: Invalid object path in  name attribute
> '
>at tests/test_parse.c:7954 (test_parse_xml).
> FAIL test_parse (exit status: 134)

I don't know whether the test failure is triggered by glibc 2.26, or by
something else that changed since November.

This is particularly nasty because the missing binNMU makes libnih
(and hence systemd-shim) uninstallable; and until #883569 and #883573
are resolved, that's going to cause problems on the buildds whenever
a chain of (build-)dependencies pulls in libpam-systemd, because apt
apparently commits to installing systemd-shim and is not able to roll
back far enough to consider installing systemd-sysv instead.

smcv

Bug#755494: libmpd: diff for NMU version 11.8.90+git20130319-0.1

[Simon McVittie]

Control: tags 755494 - pending

Hi Etienne,
Are you still interested in gmpc and libmpd?

On Mon, 21 Jul 2014 at 13:16:23 +0200, Etienne Millon wrote:
> I've prepared an NMU for libmpd (versioned as
> 11.8.90+git20130319-0.1).
...
> A source package can be found here while I am contacting sponsors

Do I assume correctly that this never got sponsored?

> It also seems that you are MIA; if that is confirmed I can adopt the
> package and freshen the packaging: hardening, watch file, S-V, remove
> quilt, etc.

Now that the package is orphaned, I think it would make sense to adopt
it on behalf of pkg-mpd. I'm happy to either review/sponsor, or do the
updates myself, time permitting.

Regards,
smcv

Bug#790578: (various packages): depends on python-gnome2 which is deprecated

[Simon McVittie]

Control: severity 790573 serious
Control: tags 790573 = buster sid
Control: severity 790579 serious
Control: tags 790579 = buster sid
Control: severity 790578 serious
Control: tags 790578 = buster sid
Control: severity 790576 serious
Control: tags 790576 = buster sid
Control: severity 790584 serious
Control: tags 790584 = buster sid
Control: severity 790583 serious
Control: tags 790583 = buster sid
Control: severity 790581 serious
Control: tags 790581 = buster sid
Control: severity 790586 serious
Control: tags 790586 = buster sid
Control: severity 790589 serious
Control: tags 790589 = buster sid
Control: severity 790590 serious
Control: tags 790590 = buster sid
Control: severity 790594 serious
Control: tags 790594 = buster sid
Control: severity 790593 serious
Control: tags 790593 = buster sid
Control: severity 790595 serious
Control: tags 790595 = buster sid fixed-upstream
Control: forwarded 790595 
https://git.gnome.org/browse/postr/commit/?id=b8d043bdd4de109f83fa15f8eeaffc7e2bbe8305
Control: severity 790597 serious
Control: tags 790597 = buster sid
Control: severity 790600 serious
Control: tags 790600 = buster sid
Control: severity 790601 serious
Control: tags 790601 = buster sid
Control: severity 790596 serious
Control: tags 790596 = buster sid
Control: severity 790602 serious
Control: tags 790602 = buster sid
Control: severity 790605 serious
Control: tags 790605 = buster sid
Control: severity 845956 serious
Control: tags 845956 = buster sid

On Tue, 30 Jun 2015 at 12:33:03 +0200, po...@debian.org wrote:
> $package depends on python-gnome2, which is long deprecated and going
> to be removed from the archive. $package should be ported away from
> it.
> 
> The way forward is to port your app to use GObject Introspection
> bindings.
> 
> For more information on GObject Introspection see [1] and [2].
>
> [1] https://wiki.gnome.org/action/show/Projects/GObjectIntrospection
> [2] https://wiki.gnome.org/action/show/Projects/PyGObject 
>
> Please try to do this before the Stretch release as we're going to
> try to remove python-gnome2 this cycle.

This didn't happen for stretch, but only 25 packages still have Depends
or Recommends on python-gnome2, many of them already RC-buggy. We should
try to do this for buster.

Regards,
smcv

Bug#876463: Please recompile with OCaml 4.05.0

[Simon McVittie]

Control: tags -1 sid

On Fri, 22 Sep 2017 at 16:36:26 +0200, Stéphane Glondu wrote:
> Please recompile polygen with OCaml 4.05.0. This cannot be done with a
> binNMU, since polygen is arch:all.

The fixed polygen won't migrate to buster until the new OCaml does, but
this is not actually a bug that affects buster (until the new OCaml gets
there, at which point it will be a non-issue). Tagging the bug accordingly
so that it won't trigger autoremovals for packages like ikiwiki-hosting.

smcv

Bug#865149: aumix: please build-depend on automake, not obsolete automake1.11

[Simon McVittie]

Source: aumix
Version: 2.9.1-4
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies in its current state
without automake1.11 in the archive (sbuild always uses the first
option from an "a | b" group). As far as I am aware, there are no
immediate plans to remove automake1.11.

Thanks,
S

Bug#865147: agg: please build-depend on automake, not obsolete automake1.11

[Simon McVittie]

Source: agg
Version: 2.5+dfsg1-11
Severity: normal
User: debian...@lists.debian.org
Usertags: automake1.11 automake1.11-only

This package Build-Depends on the obsolete automake1.11 package.

Please check whether this package can be built correctly with the
recommended automake version, as provided by the automake package
(currently version 1.15). If it can, please build-depend on automake
instead, with no automake1.11 alternative. automake (>= 1:1.11)
has been available since at least Debian 7 'wheezy' (oldoldstable).

If this package has an old build system, it is possible that it
will need build system changes for it to be able to autoreconf with
a current version of automake. If so, those changes should be
forwarded upstream. See `info automake Upgrading` or
https://www.gnu.org/software/automake/manual/html_node/Upgrading.html
for details. automake 1.15 was released in 2014 and is now widespread,
so most upstreams will probably not object to a dependency on
versions >= 1.15 at this point.

If automake1.11 is removed from Debian, this bug will become serious
(release-critical), since the Debian buildd infrastructure would be
unable to satisfy this package's build-dependencies in its current state
without automake1.11 in the archive (sbuild always uses the first
option from an "a | b" group). As far as I am aware, there are no
immediate plans to remove automake1.11.

Thanks,
S

Bug#857260: libappindicator: please do not build-depend on libindicate

[Simon McVittie]

Source: libappindicator
Version: 0.4.92-4
Severity: normal

While investigating whether an RC bug in the orphaned package
src:libindicate should be resolved by fixing the bugs or by removing the
package, I noticed that libappindicator Build-Depends on libindicate-dev,
but has no libindicate runtime dependency.

This appears to have been caused by confusion between libindicator,
which libappindicator does legitimately depend on, and libindicate,
which is not used.

Please remove this obsolete build-dependency.

This bug might be escalated to serious if it is feasible to remove
libindicate from stretch, because the less unmaintained code we have,
the better.

Regards,
S

Bug#761989: Please remove libdc0 from Debian

[Simon McVittie]

Control: reassign 761998 ftp.debian.org
Control: retitle 761998 RM: RoQA; unmaintained, dead upstream, low popcon, 
library with no rdeps

On Wed, 17 Sep 2014 at 21:54:52 +0700, Maia Everett wrote:
> libdc0/valknut's upstream is pretty much dead. The only user of libdc0
> is valknut, for which I'm also filing a removal request and which can be
> replaced by its actively maintained fork, eiskaltdcpp.
> 
> The last stable release of libdc0 was in 2009 and the last SVN commit
> was in 2011.

This reasoning seems good to me. Reassigning to ftp.debian.org for removal.

S

Bug#790991: transition: cal3d (libcal3d12v5)

[Simon McVittie]

retitle 790991 transition: cal3d (libcal3d12v5)
severity 790991 normal
reassign 790991 release.debian.org
user release.debian@packages.debian.org
usertags 790991 + transition
forwarded 790991 https://release.debian.org/transitions/html/auto-cal3d.html
thanks

On Fri, 14 Aug 2015 at 15:54:38 +0100, Manuel A. Fernandez Montecelo wrote:
 Uploaded changes to experimental.

As Julien clarified in
https://lists.debian.org/debian-release/2015/08/msg00426.html,
I believe this is ready for upload to unstable whenever you want.

There are only two reverse dependencies. crystalspace is not in testing
and FTBFS anyway, so I think that one can be disregarded. soya has
no other C++ build-dependencies, so it is probably ready to be queued
up as soon as the updated cal3d gets to unstable:

nmu soya_0.15~rc1-10 . ALL . -m 'Rebuild with libcal3d12v5'
dw soya_0.15~rc1-10 . ALL . -m 'libcal3d12v5'

Regards,
S

Bug#790643: FTBFS: Could NOT find Event (missing: Event_LIBRARIES)

[Simon McVittie]

Control: severity 790643 serious
Control: block 791170 by 790643

On Tue, 30 Jun 2015 at 10:06:46 -0400, Martin Michlmayr wrote:
 museek+ fails to build from source:
...
Could NOT find Event (missing: Event_LIBRARIES)

This is reproducible on the official buildds during the libstdc++ transition:
https://buildd.debian.org/status/package.php?p=museek%2B


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150810074537.ga30...@perpetual.pseudorandom.co.uk

Bug#790983: blackbox: library transition: libbt0v5

[Simon McVittie]

Control: severity 790983 serious
Control: tags 790983 + confirmed
Control: retitle 790983 blackbox: library transition: libbt0v5

On Fri, 03 Jul 2015 at 13:08:57 +, Matthias Klose wrote:
  - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
library API, and are used by the reverse dependencies of the
library.

Yes they are. Rebuilding bbpager, the only rdep of blackbox, fails with:

x86_64-linux-gnu-g++  -Wall -g -O2  -I/usr/include/bt -I/usr/include/freetype2  
 -s   -lSM -lICE -lX11 -o bbpager  bbpager.o main.o Baseresource.o resource.o 
wminterface.o pager.o desktop.o  -lXext -lbt -Wl,-z,relro 
bbpager.o: In function `ToolWindow::ToolWindow(Configuration)':
/«PKGBUILDDIR»/src/bbpager.cxx:40: undefined reference to 
`bt::Application::Application(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, char const*, bool)'
Baseresource.o: In function 
`BaseResource::readString(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const, std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const)':
/«PKGBUILDDIR»/src/Baseresource.cxx:97: undefined reference to 
`bt::Resource::read(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const) const'
Baseresource.o: In function 
`BaseResource::readString(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const, std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const)':
/«PKGBUILDDIR»/src/Baseresource.cxx:104: undefined reference to 
`bt::Resource::read(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const) const'
/«PKGBUILDDIR»/src/Baseresource.cxx:106: undefined reference to 
`bt::Resource::read(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const) const'
Baseresource.o: In function 
`BaseResource::readInt(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, int)':
/«PKGBUILDDIR»/src/Baseresource.cxx:113: undefined reference to 
`bt::Resource::read(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const) const'
Baseresource.o: In function 
`BaseResource::readUInt(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const, unsigned int)':
/«PKGBUILDDIR»/src/Baseresource.cxx:124: undefined reference to 
`bt::Resource::read(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const) const'
Baseresource.o:/«PKGBUILDDIR»/src/Baseresource.cxx:137: more undefined 
references to `bt::Resource::read(std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const, 
std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar  
const, std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const) const' follow
Baseresource.o: In function `BaseResource::BaseResource(bt::Application, 
unsigned int, std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const, std::__cxx11::basic_stringchar, 
std::char_traitschar, std::allocatorchar  const)':
/«PKGBUILDDIR»/src/Baseresource.cxx:37: undefined reference to 
`bt::Resource::load(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const)'
/«PKGBUILDDIR»/src/Baseresource.cxx:46: undefined reference to 
`bt::Resource::read[abi:cxx11](char const*, char const*, char const*) const'
/«PKGBUILDDIR»/src/Baseresource.cxx:83: undefined reference to 
`bt::Resource::merge(std::__cxx11::basic_stringchar, std::char_traitschar, 
std::allocatorchar  const)'
/«PKGBUILDDIR»/src/Baseresource.cxx:41: undefined reference to 

Bug#756032: libdnet: should be multiarch because apparently roaraudio wants it for some unfathomable reason

[Simon McVittie]

Package: libdnet
Version: 2.63
Severity: wishlist

libmuroar0, libmuroard3 and libroar2 depend on libdnet. They cannot be
installed for both :amd64 and :i386 (or whatever) unless libdnet is.

I have no idea why something that appears to be a sound server analogous
to PulseAudio/ESD would depend on what appears to be a library to
communicate with Ultrix and VMS machines over an obsolete non-IP protocol,
but perhaps I'm not understanding the problem space.

In any case, in the unlikely event that someone still cares about DECnet,
they should probably fix this or something.

The dependency chain of interest at the moment is

wine:i386 - libopenal1 - libroar-compat2 - libroar2 - libdnet
other stuff:amd64 - libopenal1 - libroar-compat2 - libroar2 - libdnet

in which the non-multiarch nature of libroar-compat and libroar2 (#755846)
and libdnet (this bug) is preventing wine from being installed on
fairly typical systems.

S

-- System Information:
Debian Release: jessie/sid
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libdnet depends on:
ii  libc6   2.19-7
ii  libgcc1 1:4.9.1-1
ii  libstdc++6  4.9.1-1

libdnet recommends no packages.

Versions of packages libdnet suggests:
pn  dnet-common  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140725143252.ga13...@reptile.pseudorandom.co.uk

Bug#588488: herrie: pulse alsa backend doesn't work on Lenovo X200s

[Simon McVittie]

Package: herrie
Version: 2.2-2
Severity: normal

I noticed this while doing a QA upload, but uploaded it anyway, since there's
a workaround and the QA upload does fix an RC bug.

On my laptop, I have this in ~/.asoundrc:

pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
   type pulse
}
pcm.default {
   type pulse
}

herrie fails to play a perfectly normal Ogg Vorbis file (2 channels, 44.1 kHz)
with Sample rate or amount of channels not supported. When I delete the
third and fourth stanzas from .asoundrc it works fine.

I suspect that my hardware only supports 48 kHz output, and ALSA hardware
output performs some sort of automatic conversion, while the pulse backend
does not. This is on a Lenovo X200s laptop with a
Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03).

-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (101, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages herrie depends on:
ii  libasound21.0.23-1   shared library for ALSA applicatio
ii  libc6 2.11.2-2   Embedded GNU C Library: Shared lib
ii  libcurl3-gnutls   7.21.0-1   Multi-protocol file transfer libra
ii  libglib2.0-0  2.24.1-1   The GLib library of C routines
ii  libid3tag00.15.1b-10 ID3 tag reading library from the M
ii  libmad0   0.15.1b-5  MPEG audio decoder library
ii  libmodplug0c2 1:0.8.8-2  shared libraries for mod music bas
ii  libncursesw5  5.7+20100313-2 shared libraries for terminal hand
ii  libsndfile1   1.0.21-2   Library for reading/writing audio 
ii  libspiff4 1.0.0-3library to read/write XSPF, the XM
ii  libvorbisfile31.3.1-1The Vorbis General Audio Compressi

herrie recommends no packages.

herrie suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature

Bug#588072: giftui: should this package be removed?

[Simon McVittie]

Source: giftui
Severity: serious
Justification: orphaned, low popcon, inactive upstream
User: debian...@lists.debian.org
Usertags: proposed-removal

giftui seems like a candidate for removal from Debian:

* orphaned
* low and declining popcon
* inactive upstream (last activity was a comment on a bug in 2006)

In addition, since GiFTui is a GUI for file-sharing networks, it's
network-facing (so, potentially security-sensitive), and is not useful if the
networks/protocols it uses are no longer popular (I don't know whether they
are).

If you want to keep this package around in Debian, please adopt it and close
this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: giftui -- RoM; orphaned, low popcon, inactive upstream
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564930: aap: should this package be removed?

[Simon McVittie]

Source: aap
Severity: wishlist
Justification: low-popcon build tool with no rdepends
User: debian...@lists.debian.org
Usertags: proposed-removal

aap seems like a candidate for removal from Debian:

* orphaned
* low popcon (12 votes)
* many alternatives exist (it's a make-like tool)
* nothing in Debian depends on it

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: aap -- RoQA; orphaned, low popcon, no rdepends, alternatives
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564933: aub: should this package be removed?

[Simon McVittie]

Source: aub
Severity: serious
Justification: orphaned, orphaned upstream, low popcon, alternatives exist
User: debian...@lists.debian.org
Usertags: proposed-removal

aub seems like a candidate for removal from Debian:

* orphaned
* the previous Debian maintainer was also the upstream
* low popcon (6 votes)
* alternatives exist (e.g. brag, lottanzb, nzb)

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: aub -- RoQA; orphaned, no upstream, low popcon, alternatives
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564934: libcgi: should this package be removed?

[Simon McVittie]

Source: libcgi
Severity: serious
Justification: orphaned, inactive upstream, low popcon, no rdepends
User: debian...@lists.debian.org
Usertags: proposed-removal

libcgi seems like a candidate for removal from Debian:

* orphaned
* inactive upstream (no releases since 2003)
* low popcon (6 votes)
* library with no rdepends
* security-sensitive (CGI) packages shouldn't be unmaintained :-)

If you want to keep this package around in Debian, please adopt it.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: libcgi -- RoQA; orphaned, inactive upstream, library with no 
rdepends
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564938: wip: should this package be removed?

[Simon McVittie]

Source: wip
Severity: wishlist
User: debian...@lists.debian.org
Usertags: proposed-removal

wip seems like a candidate for removal from non-free:

* orphaned
* non-free
* low popcon (20 votes)
* no upstream releases in 10 years
* alternatives exist (presumably... it's described as plotting software)

If you want to keep this package around in Debian, please just close this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: wip -- RoQA; reasons
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature

Bug#564940: wip: should this package be removed?

[Simon McVittie]

Source: sfind
Severity: serious
Justification: orphaned, low popcon, an alternative is Essential: yes
User: debian...@lists.debian.org
Usertags: proposed-removal

sfind seems like a candidate for removal from Debian:

* orphaned
* low popcon (7 votes)
* doesn't seem any better than modern findutils, which is Essential: yes

GNU findutils seems to have the advantages cited in sfind's Description now,
so sfind no longer seems to be necessary?

If you want to keep this package around in Debian, please adopt it and close
this bug.

If you don't think it's worth keeping, please send the following commands
to cont...@bugs.debian.org, replacing nn with this bug's number:

severity nn normal
reassign nn ftp.debian.org
retitle nn RM: sfind -- RoQA; orphaned, low popcon, alternative is Essential
thanks 

For more information, see
http://wiki.debian.org/ftpmaster_Removals
http://ftp-master.debian.org/removals.txt

Regards,
smcv


signature.asc
Description: Digital signature