Bug#1051002: dwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: dwm
Version: 6.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, dwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/dwm.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/dwm-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, dwm 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 dwm 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 dwm
* reboot
* Log in as the user account, selecting "dwm" 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. dwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=dwm

would seem appropriate.

This would allow the dwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/dwm-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 dwm 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/dwm.desktop, most likely just "dwm":

DesktopNames=dwm;

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

And then create a /usr/share/xdg-desktop-portal/dwm-portals.conf
with whatever portal backends are desired for a dwm 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#1051001: cwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: cwm
Version: 7.1-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, cwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/cwm.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/cwm-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, cwm 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 cwm 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 cwm
* reboot
* Log in as the user account, selecting "cwm" 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. cwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=cwm

would seem appropriate.

This would allow the cwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/cwm-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 cwm 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/cwm.desktop, most likely just "cwm":

DesktopNames=cwm;

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

And then create a /usr/share/xdg-desktop-portal/cwm-portals.conf
with whatever portal backends are desired for a cwm 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#1050999: bspwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: bspwm
Version: 0.9.10-2+b1
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, bspwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/bspwm.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/bspwm-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, bspwm 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 bspwm 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 bspwm dbus-user-session
* reboot
* Log in as the user account, selecting "bspwm" from the menu of
  possible X11 sessions
* In a ssh login as the same user, 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. Normally I would have said "open a terminal and run..."
but I couldn't immediately find how to make bspwm run a program.)

Expected result
===

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

XDG_CURRENT_DESKTOP=bspwm

would seem appropriate.

This would allow the bspwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/bspwm-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 bspwm 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/bspwm.desktop, most likely just "bspwm":

DesktopNames=bspwm;

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

And then create a /usr/share/xdg-desktop-portal/bspwm-portals.conf
with whatever portal backends are desired for an bspwm 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#1050981: xmonad: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

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

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/xmonad-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, XMonad 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 XMonad to participate in those
specifications.

The "GNOME Flashback (Xmonad)" session *does* set XDG_CURRENT_DESKTOP, but
to a value that is indistinguishable from the ordinary GNOME Flashback
session with the metacity window manager, and I don't know whether that's
the most appropriate thing for the purposes of desktop-specific
configuration or not.

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 xmonad
* reboot
* Log in as the user account, selecting "XMonad" from the menu of
  possible X11 sessions
* In a ssh session as the same user, run:
  systemctl --user show-environment
* apt install gnome-session-flashback
* Repeat for the "GNOME Flashback (Xmonad)" session

(I couldn't work out how to open a shell in an otherwise unconfigured
XMonad session, but in any case 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. XMonad seems to be its
own thing rather than being based on another desktop environment or
window manager, so

XDG_CURRENT_DESKTOP=XMonad

would seem appropriate.

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

For XMonad's GNOME Flashback variant, I don't know whether
XDG_CURRENT_DESKTOP should be set to GNOME-Flashback:GNOME (exactly
the same as GNOME Flashback with metacity), or whether it would be better
to set it to something like XMonad-GNOME-Flashback:GNOME-Flashback:GNOME
so that XMonad's GNOME Flashback variant can have its own portal
configuration, mimeapps.list, OnlyShowIn/NotShowIn, etc. if it wants to
(in principle someone could develop a portal backend similar to
xdg-desktop-portal-gtk that works better with tiling window managers,
although I'm not aware of such a thing having been written).

Actual result
=

In the XMonad session, 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 XMonad 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.

For XMonad's GNOME Flashback variant, XDG_CURRENT_DESKTOP is currently set
to GNOME-Flashback:GNOME (exactly the same as GNOME Flashback with metacity),
so it will always use the same portal configuration, etc. as
gnome-session-flashback (see #1050799).

Suggested fix
=

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

DesktopNames=XMonad;

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

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

[preferred]
default=gtk;

Please see portals.conf(5) or its source code

Bug#1050980: awesome: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: awesome
Version: 4.3-7
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/awesome-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, awesome 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 awesome 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 awesome
* reboot
* Log in as the user account, selecting "awesome" 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. awesome seems to be its
own thing rather than being based on another desktop environment or
window manager, so

XDG_CURRENT_DESKTOP=awesome

would seem appropriate.

This would allow the awesome session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/awesome-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 awesome 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/awesome.desktop, most likely just "awesome":

DesktopNames=awesome;

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

And then create a /usr/share/xdg-desktop-portal/awesome-portals.conf
with whatever portal backends are desired for an awesome 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#1050966: amiwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: amiwm
Version: 0.21pl2-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, amiwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/amiwm.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/amiwm-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, amiwm 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 amiwm 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 amiwm
* reboot
* Log in as the user account, selecting "amiwm" 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. amiwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=amiwm

would seem appropriate.

This would allow the amiwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/amiwm-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 amiwm 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/amiwm.desktop, most likely just "amiwm":

DesktopNames=amiwm;

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

And then create a /usr/share/xdg-desktop-portal/amiwm-portals.conf
with whatever portal backends are desired for an amiwm 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#1050965: aewm++: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: aewm++
Version: 1.1.2-5.3
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, aewm++ behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/aewm++.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/aewm++-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, aewm++ 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 aewm++ 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 aewm++
* reboot
* Log in as the user account, selecting "aewm++" 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. aewm++ seems to be based
on aewm, so maybe

XDG_CURRENT_DESKTOP=aewm++:aewm

would seem appropriate.

This would allow the aewm++ session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/aewm++-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 aewm++ 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/aewm++.desktop, perhaps:

DesktopNames=aewm++;aewm;

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

And then create a /usr/share/xdg-desktop-portal/aewm++-portals.conf
with whatever portal backends are desired for a aewm++ 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#1050963: evilwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: evilwm
Version: 1.4.2-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, evilwm behaves like a very small desktop environment
in its own right, by providing a /usr/share/xsessions/evilwm.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/evilwm-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, evilwm 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 evilwm 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 evilwm
* reboot
* Log in as the user account, selecting "evilwm" 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. evilwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=evilwm

would seem appropriate.

This would allow the evilwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/evilwm-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 evilwm 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/evilwm.desktop, most likely just "evilwm":

DesktopNames=evilwm;

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

And then create a /usr/share/xdg-desktop-portal/evilwm-portals.conf
with whatever portal backends are desired for an evilwm 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#1050962: fvwm3: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: fvwm3
Version: 1.0.6a+ds-1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/fvwm-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, fvwm 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 fvwm 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 fvwm3
* reboot
* Log in as the user account, selecting Fvwm 1 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. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-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 fvwm 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
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm3.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

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

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm3;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm3:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm3-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

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#1050961: fvwm1: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: fvwm1
Version: 1.24r-57+b1
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/fvwm-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, fvwm 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 fvwm 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 fvwm1
* reboot
* Log in as the user account, selecting Fvwm 1 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. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-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 fvwm 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
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm1.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

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

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm1;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm1:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm1-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

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#1050960: fvwm-crystal: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: fvwm-crystal
Version: 3.4.1+dfsg-3
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/fvwm-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, fvwm 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 fvwm 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 fvwm-crystal
* reboot
* Log in as the user account, selecting Fvwm 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. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-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 fvwm 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
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm-crystal.desktop,
perhaps just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

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

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=FVWM-Crystal;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=FVWM-Crystal:Fvwm" in the
environment, and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm-crystal-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

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#1050959: fvwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: fvwm
Version: 1:2.7.0-2
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/fvwm-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, fvwm 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 fvwm 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 fvwm
* reboot
* Log in as the user account, selecting Fvwm 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. fvwm seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Fvwm

would seem appropriate.

This would allow the fvwm session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/fvwm-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 fvwm 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
=

Normally my advice would be to add a sequence of semicolon-separated
desktop environment names to /usr/share/xsessions/fvwm.desktop, perhaps
just "Fvwm":

DesktopNames=Fvwm;

(Some similar examples: icewm and windowmaker use "ICEWM" and
"WindowMaker" in their equivalent xsessions files.)

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

[preferred]
default=gtk;

A complicating factor for fvwm is that fvwm, fvwm-crystal, fvwm1 and
fvwm3 are all variations of fvwm, so they can't all own the filename
/usr/share/xdg-desktop-portal/fvwm-portals.conf. One way to it would
either have to be in some shared package that they all depend on, or
managed non-exclusively somehow (alternatives?).

Or, if it's desirable to be able to distinguish between all these fvwm
variants, they could have a fully-qualified name in the xsessions/*.desktop
file:

DesktopNames=Fvwm2;Fvwm;

which would result in "XDG_CURRENT_DESKTOP=Fvwm2:Fvwm" in the environment,
and xdg-desktop-portal trying to load files like
/usr/share/xdg-desktop-portal/fvwm2-portals.conf, falling back to
/usr/share/xdg-desktop-portal/fvwm-portals.conf if those don't exist.

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#1050958: afterstep: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: afterstep
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/afterstep-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, Afterstep 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 Afterstep 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 afterstep
* reboot
* Log in as the user account, selecting "Afterstep" 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. Afterstep seems to be its
own thing rather than being based on another desktop environment, so

XDG_CURRENT_DESKTOP=Afterstep

would seem appropriate.

This would allow the Afterstep session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/afterstep-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 Afterstep 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/afterstep.desktop, most likely just "Afterstep":

DesktopNames=Afterstep;

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

And then create a /usr/share/xdg-desktop-portal/afterstep-portals.conf
with whatever portal backends are desired for an Afterstep 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#1050956: weston: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

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

In addition to being available as a compositor that is part of
a more comprehensive desktop environment, weston behaves like
a small desktop environment in its own right, by providing a
/usr/share/wayland-sessions/weston.desktop which can be selected on
entry to a display manager such as gdm3.

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/weston-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, weston doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other equally simple session.

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 weston 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 and has a password
* apt install gdm3 weston
* reboot
* Log in as the user account, selecting Weston from the menu of
  possible X11/Wayland sessions before entering the password
* Open a terminal and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`echo $XDG_CURRENT_DESKTOP`, 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. For Weston on its own
as a simple desktop environment,

XDG_CURRENT_DESKTOP=Weston

would seem appropriate?

This would allow the Weston session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/weston-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 Weston 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/wayland-sessions/weston.desktop, most likely just "Weston":

DesktopNames=Weston;

And then create a /usr/share/xdg-desktop-portal/weston-portals.conf
with whatever portal backends are desired for a Weston 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#1050951: openbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: openbox
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

In addition to being available as a window manager that is part of
a more comprehensive desktop environment like LXDE, openbox behaves
like a very small desktop environment in its own right, by providing a
/usr/share/xsessions/openbox.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/openbox-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, openbox doesn't set XDG_CURRENT_DESKTOP, so for
the purposes of this mechanism, it's not programmatically distinguishable
from any other equally simple session.

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 openbox 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 openbox
* reboot
* Log in as the user account, selecting "Openbox" from the menu of
  possible X11 sessions
* Open a terminal and run:
  systemctl --user show-environment

(It's the systemd activation environment that matters here, more than
`echo $XDG_CURRENT_DESKTOP`, 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. For Openbox on its own
as a simple desktop environment,

XDG_CURRENT_DESKTOP=Openbox

would seem appropriate.

This would allow the Openbox session to have its own
desktop-environment-specific mimeapps.list or portals.conf(5), for
example /usr/share/xdg-desktop-portal/openbox-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 openbox 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/openbox.desktop, most likely just "Openbox":

DesktopNames=Openbox;

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

And then create a /usr/share/xdg-desktop-portal/openbox-portals.conf
with whatever portal backends are desired for an openbox 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#1050950: openbox-gnome-session: please make XDG_CURRENT_DESKTOP different from full GNOME, and use it to configure xdg-desktop-portal

[Simon McVittie]

Package: openbox-gnome-session
Version: 3.6.1-11
Severity: normal
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/gnome-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, openbox-gnome-session sets
XDG_CURRENT_DESKTOP=GNOME, so for the purposes of this mechanism, it's
not programmatically distinguishable from a full GNOME session with GNOME
Shell. This is problematic, because gnome-portals.conf in gnome-session
selects portal implementations that are only appropriate for the full
GNOME session.

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 openbox-gnome-session
* # reboot
* Log in as the user account, selecting "GNOME/Openbox" from the menu of
  possible X11 sessions
* In a parallel ssh login as the same user:
  $ systemctl --user show-environment

(Normally I would say to use a shell inside the X11 environment, but
openbox-gnome-session doesn't currently work because it declares required
components that don't exist - I opened a separate RC bug.)

Expected result
===

XDG_CURRENT_DESKTOP should be set to a colon-separated sequence of
desktop environment names, most specific first. Because this seems to
be intended to behave like a variant of GNOME Flashback, which is itself
a variant of full GNOME, a good value might be:

XDG_CURRENT_DESKTOP=Openbox-GNOME:GNOME-Flashback:GNOME

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

Actual result
=

XDG_CURRENT_DESKTOP is set to "GNOME", the same as a full GNOME Shell
session.

This means that xdg-desktop-portal will use xdg-desktop-portal-gnome for
all interfaces, but some of the functionality of xdg-desktop-portal-gnome
can only work when running under GNOME Shell.

Suggested fix
=

Fixing the RC bug I opened today (that openbox-gnome-session doesn't start)
will be a prerequisite for usefully fixing this. If it's resolved by
removing openbox-gnome-session, then obviously no further action is needed.

Assuming that openbox-gnome-session is kept, the solution for this bug
would be to add a sequence of semicolon-terminated desktop environment
names to /usr/share/xsessions/openbox-gnome.desktop, perhaps this:

DesktopNames=Openbox-GNOME;GNOME-Flashback;GNOME;

(Note that this is not the same separator as in $XDG_CURRENT_DESKTOP!
It's a semicolon here, as is standard for .desktop file syntax, but it's
a colon in the environment variable.)

And then create a /usr/share/xdg-desktop-portal/openbox-gnome-portals.conf
with whatever portal backends are desired for openbox-gnome-session;
or alternatively, rely on gnome-flashback to provide a
gnome-flashback-portals.conf that this session can fall back to (please
see #1050799 for more information).

Thanks,
smcv

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

Bug#1050946: openbox-gnome-session: missing dependencies, not all RequiredComponents exist any more

[Simon McVittie]

Package: openbox-gnome-session
Version: 3.6.1-11
Severity: grave
Justification: renders package unusable

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 openbox-gnome-session
* # reboot
* Log in as the user account, selecting "GNOME/Openbox" from the menu of
  possible X11 sessions

Expected result
===

A basic GNOME-Flashback-like session with Openbox as window manager

Actual result
=

Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'org.gnome.SettingsDaemon.A11ySettings'
...
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'org.gnome.SettingsDaemon.XSettings'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'gnome-panel'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'nautilus-classic'
Aug 31 16:55:58 host gnome-session-binary[1795]: WARNING: Unable to find 
required component 'gnome-flashback-services'

and the session fails with the GNOME Session "something went wrong"
full-screen dialog.

Root cause
==

/usr/share/gnome-session/sessions/openbox-gnome.session declares the
following as required components of a GNOME/Openbox session:

openbox;
org.gnome.SettingsDaemon.A11ySettings;
[some more pieces of gnome-settings-daemon]
org.gnome.SettingsDaemon.XSettings;
gnome-panel;
nautilus-classic;
gnome-flashback-services

but openbox-gnome-session does not have Depends or even Recommends on the
necessary packages to provide those components.

As a minimum, I think it needs to depend on gnome-settings-daemon,
gnome-panel and gnome-flashback, but I tried installing those packages
and that did not fix the failure to start.

gnome-settings-daemon no longer has Clipboard or Mouse plugins according
to gnome-flashback commits

and
.

nautilus-classic hasn't existed for 5
years according to gnome-flashback commit
.

I don't know what gnome-flashback-services is/was, but
gnome-session-flashback lists gnome-flashback as a required component
instead.

Thanks,
smcv

Bug#1050798: plasma-workspace: please provide a kde-portals.conf for xdg-desktop-portal

[Simon McVittie]

Control: reassign -1 xdg-desktop-portal-kde
Control: affects -1 + plasma-workspace
Control: tags -1 + fixed-upstream
Control: forwarded -1 
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/196,https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/218

On Tue, 29 Aug 2023 at 11:36:32 +0100, Simon McVittie wrote:
> xdg-desktop-portal 1.17.x (currently in experimental) 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/kde-portals.conf

It looks as though KDE have chosen to ship this as part of
xdg-desktop-portal-kde. Please consider cherry-picking these two:

https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/196
https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/merge_requests/218

> plasma-workspace (and plasma-mobile?) should probably have at least a
> Recommends on xdg-desktop-portal-kde for this (see also #1019918).

If x-d-p-kde is responsible for providing kde-portals.conf, then I
think the desktop environments need some sort of dependency relationship
with it.

Thanks,
smcv

Bug#1050931: cutefish-core: please provide a cutefish-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: cutefish-core
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/cutefish-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

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.

If I'm reading its code correctly, I think Cutefish intends to set
XDG_CURRENT_DESKTOP to "Cutefish"? (But if I'm wrong, please adjust my
suggestions accordingly.)

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for Cutefish. Please add a cutefish-portals.conf to tell x-d-p
more explicitly what backends Cutefish is meant to be using by default.

At the moment x-d-p is hard-coded to fall back to the x-d-p-gtk backend
if nothing more suitable is found, but that's a short-term hack which
we should remove before trixie.

For example, if the intention is that Cutefish should be using the
x-d-p-gtk backend, the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either cutefish-core or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050928: enlightenment-data: please provide an enlightenment-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: enlightenment-data
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/enlightenment-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

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.

If I'm reading its code correctly, I think Enlightenment asks the display 
manager
to set XDG_CURRENT_DESKTOP to "Enlightenment"? (But if I'm wrong, please
adjust my suggestions accordingly.)

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for Enlightenment. Please add an enlightenment-portals.conf to tell x-d-p
more explicitly what backends Enlightenment is meant to be using by default.

At the moment x-d-p is hard-coded to fall back to the x-d-p-gtk backend
if nothing more suitable is found, but that's a short-term hack which
we should remove before trixie.

For example, if the intention is that Enlightenment should be using the
x-d-p-gtk backend, the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either enlightenment-data or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050917: phosh: please provide a phosh-portals.conf for xdg-desktop-portal

[Simon McVittie]

Control: tags -1 + fixed-upstream
Control: forwarded -1 
https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/1301

On Thu, 31 Aug 2023 at 14:22:17 +0200, Guido Günther wrote:
> I wasn't aware that `none` works, thanks for that!

I must admit that I've never actually tried that feature, so you might
have to report bugs if it falls back to considering UseIn (I expect this
to be a relatively rare use-case).

> Do you know of a way to have the config outside of `/etc/` so that
> admins don't have to modify the conf file but can override it if they
> want to make changes?

Since 1.17.1 it can/should be
/usr/share/xdg-desktop-portal/phosh-portals.conf (and that's what I've been
recommending in this MBF).

In the initial implementation of this feature in x-d-p
1.17.0, only /etc was searched, but I thought that was
wrong, and fixed it to behave more like mimeapps.list in
 which was
included in 1.17.1.

I opened  upstream
with a suggested (but untested) change.

smcv

Bug#1050920: wmaker-common: please provide a windowmaker-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: wmaker-common
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/windowmaker-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

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.

If I'm reading its code correctly, I think wmaker asks the display manager
to set XDG_CURRENT_DESKTOP to "WindowMaker"? (But if I'm wrong, please
adjust my suggestions accordingly.)

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for WindowMaker. Please add a windowmaker-portals.conf to tell x-d-p
more explicitly what backends wmaker is meant to be using by default.

For example, if the intention is to use the x-d-p-gtk backend,
the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either wmaker-common or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on
whatever portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050919: sxmo-utils: please provide a sxmo-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: sxmo-utils
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/sxmo-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

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.

If I'm reading correctly, I think sxmo-utils inconsistently uses either
XDG_CURRENT_DESKTOP="SXMO" or XDG_CURRENT_DESKTOP="sway"? (But perhaps I'm
reading it wrong...)

If it uses XDG_CURRENT_DESKTOP="SXMO", then it should provide a
sxmo-portals.conf that sets up the correct portal backends.
For example, if the intention is to use x-d-p-wlr for the interfaces
that it supports (screenshots and screencasting), and x-d-p-gtk for
other interfaces (such as File->Open and File->Save As... dialogs),
then the simplest way to write that would be:

[preferred]
default=wlr;gtk;

The desktop environment (either sxmo-utils or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on
whatever portals would be most appropriate for it. I see that it already
Depends on sway, which Suggests xdg-desktop-portal-wlr, but not -gtk.

If sxmo-utils is using XDG_CURRENT_DESKTOP="sway", then it has no ability
to choose its own portals, and will have to rely on Sway choosing something
vaguely appropriate (#1050913).

It might be better for it to use XDG_CURRENT_DESKTOP="SXMO:sway", which
means use SXMO-specific settings if they exist, or sway-specific settings
if not, in the same way that Ubuntu's customized GNOME session uses
"Ubuntu:GNOME".

Thanks,
smcv

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

Bug#1050918: icewm: please provide an icewm-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: icewm
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/icewm-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

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.

If I'm reading its code correctly, I think icewm asks the display manager
to set XDG_CURRENT_DESKTOP to "ICEWM"?

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for ICEWM. Please add an icewm-portals.conf to tell x-d-p more explicitly
what backends icewm is meant to be using by default.

For example, if the intention is to use the x-d-p-gtk backend,
the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either icewm or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050917: phosh: please provide a phosh-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: phosh
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/phosh-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

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.

If I'm reading correctly, I think phosh uses
XDG_CURRENT_DESKTOP="Phosh:GNOME" but needs portals that are not quite the
same as GNOME's, because it's using a wlroots-based compositor instead of
the mutter-based GNOME Shell?

If that's the case, then it should provide a phosh-portals.conf so that
individual users aren't required to set this up for themselves.

For example, it might look something like this (this is untested and based
on guesses, I don't use Phosh myself, so please check this carefully):

[preferred]
default=gtk;
org.freedesktop.impl.portal.Secret=gnome-keyring;
# Non-GNOME-Shell-specific parts of x-d-p-gnome
org.freedesktop.impl.portal.Account=gnome;gtk;
org.freedesktop.impl.portal.AppChooser=gnome;gtk;
org.freedesktop.impl.portal.Background=gnome;gtk;
org.freedesktop.impl.portal.DynamicLauncher=gnome;gtk;
org.freedesktop.impl.portal.FileChooser=gnome;gtk;
org.freedesktop.impl.portal.Lockdown=gnome;gtk;
org.freedesktop.impl.portal.Print=gnome;gtk;
org.freedesktop.impl.portal.Settings=gnome;gtk;
org.freedesktop.impl.portal.Wallpaper=gnome;gtk;
# Phosh-specific
org.freedesktop.impl.portal.Access=phosh;
org.freedesktop.impl.portal.RemoteDesktop=none;
org.freedesktop.impl.portal.ScreenCast=wlr;
org.freedesktop.impl.portal.Screenshot=wlr;

The desktop environment (either phosh or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050914: wayfire: please provide a wayfire-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: wayfire
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/wayfire-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

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.

If I'm reading correctly, I think wayfire uses XDG_CURRENT_DESKTOP="Wayfire"?
If that's the case, then it should provide a wayfire-portals.conf so that
individual users aren't required to set this up for themselves.

For example, if the intention is to use x-d-p-wlr for the interfaces
that it supports (screenshots and screencasting), and x-d-p-gtk for
other interfaces (such as File->Open and File->Save As... dialogs),
then the simplest way to write that would be:

[preferred]
default=wlr;gtk;

The desktop environment (either wayfire or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it. I see that it already Suggests
xdg-desktop-portal-wlr, but not -gtk.

Thanks,
smcv

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

Bug#1050913: sway: please provide a sway-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: sway
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/sway-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

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.

If I'm reading correctly, I think sway uses XDG_CURRENT_DESKTOP="sway"? If
that's the case, then it should provide a sway-portals.conf so that
individual users aren't required to set this up for themselves.

For example, if the intention is to use x-d-p-wlr for the interfaces
that it supports (screenshots and screencasting), and x-d-p-gtk for
other interfaces (such as File->Open and File->Save As... dialogs),
then the simplest way to write that would be:

[preferred]
default=wlr;gtk;

The desktop environment (either sway or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it. I see that it already Suggests
xdg-desktop-portal-wlr, but not -gtk.

Thanks,
smcv

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

Bug#1050911: i3-wm: please provide an i3-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: i3-wm
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/i3-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

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.

If I'm reading its code correctly, I think i3-wm asks the display manager
to set XDG_CURRENT_DESKTOP to "i3"?

As a backwards-compatibility mechanism, x-d-p will fall back to trying to
guess the most appropriate portals from the portals' deprecated UseIn=
fields, but it will log warnings when it does that, and anyway Debian
doesn't currently ship any portal backends that are flagged as suitable
for i3. Please add an i3-portals.conf to tell x-d-p more explicitly
what backends i3-wm is meant to be using by default.

For example, if the intention is to use the x-d-p-gtk backend,
the way to write that would be:

[preferred]
default=gtk;

The desktop environment (either i3-wm or some larger metapackage) should
probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050908: ukui-session-manager: please provide a ukui-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: ukui-session-manager
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/ukui-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for UKUI.
Please add a ukui-portals.conf to tell x-d-p more explicitly what backends
UKUI is meant to be using by default.

For example, if the intention is to use x-d-p-gtk, the way to write that
would be:

[preferred]
default=gtk;

The desktop environment (either ukui-session-manager or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.

For an example of a more complex portal configuration, see gnome-session:
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d

Thanks,
smcv

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

Bug#1050907: gnome-shell-extensions: please check whether a gnome-classic-portals.conf for xdg-desktop-portal is needed

[Simon McVittie]

Package: gnome-shell-extensions
Severity: wishlist
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/gnome-classic-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

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.

Because GNOME Classic declares itself as being GNOME-based with
XDG_CURRENT_DESKTOP=GNOME-Classic:GNOME, it has two options:

1. Delegate its choice of portals to "ordinary" GNOME by accepting
   whatever GNOME does in gnome-portals.conf, and don't install a
   gnome-classic-portals.conf

2. Take control over its own choice of portals by providing a
   /usr/share/xdg-desktop-portal/gnome-classic-portals.conf

If the first option is what the GNOME Classic maintainers want, then this
bug can be closed without further action. If I understand the situation
correctly, GNOME Classic is just GNOME Shell with a stylesheet and some
pre-configured extensions, so it provides most (all?) of the APIs that
GNOME Shell does, and can just inherit gnome-portals.conf from GNOME?
So closing this bug without further action is probably OK?

But if GNOME Classic wants to override the choice of portals,
the way to do that would be something similar to the
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
in ordinary GNOME.

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

Bug#1050905: budgie-core: please provide a budgie-portals.conf for xdg-desktop-portal if appropriate

[Simon McVittie]

Package: budgie-core
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/budgie-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

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.

Because budgie-desktop declares itself as being GNOME-based with
XDG_CURRENT_DESKTOP=Budgie:GNOME, it has two options:

1. Delegate its choice of portals to GNOME by accepting whatever GNOME
   does in gnome-portals.conf, and don't install a budgie-portals.conf

2. Take control over its own choice of portals by providing a
   /usr/share/xdg-desktop-portal/budgie-portals.conf

If the first option is what the Budgie maintainers want, then this bug
can be closed without further action.

>From what I've seen elsewhere, in the short term Budgie probably wants to
use a mixture of -gtk and -gnome? But in the GNOME 45 cycle, it seems to be
switching away from mutter 44/45 to a fork of mutter 43, which might no
longer have the APIs that x-d-p-gnome requires? So the second option is
probably more appropriate. GNOME's gnome-portals.conf was added in
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
and might make a good basis for designing a budgie-portals.conf: it
illustrates how a different fallback order can be selected for each portal
interface.

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

Bug#1050904: lomiri-session: please provide a lomiri-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: lomiri-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/lomiri-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for
Lomiri. Please add a lomiri-portals.conf to tell x-d-p more explicitly
what backends Lomiri is meant to be using by default.

For example, if it's a GTK-based environment where xdg-desktop-portal-gtk
is the most appropriate backend, it might look like this:

[preferred]
default=gtk;

I don't know much about Lomiri, so I can't assess what the most
appropriate portal backend for it would be! But it seems to be a
descendant of Ubuntu's Unity, so GTK is probably reasonably appropriate.

Or if it has its own portal(s), a more elaborate lomiri-portals.conf
like the one added for GNOME in
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
might be desirable.

Thanks,
smcv

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

On Thu, 31 Aug 2023 at 08:30:00 +0200, Aurelien Jarno wrote:
> This has already been discussed on IRC that you should not worry about
> debootstrap for buster, provide you leave us ~1 month. Not sure yet what
> we'll do, it could be your option, stopping the buildds as discussed on
> IRC, or maybe yet another option.

Thank you! (I was not part of that IRC conversation.)

Some of the forward progress with DEP-17 is blocked by getting an updated
debootstrap into 12.2 and 11.8, which are planned for 2023-10-07 if I
understand correctly, so resolving this within the next month would take
mips64el off the critical path.

Another option that occurred to me would be that the affected buildds
could perhaps be upgraded to bullseye user-space, but with the kernel
metapackage held back to buster's? Obviously that's not ideal (no
kernel security updates) but at least that way they'd have user-space
security updates to components like sshd, together with the same
schroot/sbuild/debootstrap behaviours as most of the other architectures'
buildds.

smcv

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

On Wed, 30 Aug 2023 at 21:26:24 +0200, Aurelien Jarno wrote:
> On 2023-08-30 16:54, Simon McVittie wrote:
> > Luca Boccassi and I have been preparing stable and oldstable updates for
> > debootstrap so that the transition described in DEP-17 can continue.
> > Because DEP-17 involves changes to trixie/sid chroots' bootstrap
> > procedures, the updated debootstrap needs to be deployable to every
> > official buildd
>
> We have issues running [bookworm?] and bullseye kernels on
> some arm32 and mips*el buildds. The problem on arm has been solved by
> decommissioning the hardware or by hosts dying. We still have problems
> with a big part of the mips*el hosts.

Would it be possible to make an exception to the usual rule that buildds
get their debootstrap from (old)stable point releases, and manually
install a newer debootstrap (the version proposed for bullseye should
be suitable) onto the affected mips*el machines? I see that they already
have a newer-than-buster version of sbuild, possibly from the
buster-backports suite (which was discontinued when buster was handed over
to the LTS team).

I would prefer not to spend time preparing and testing a special buster
version of debootstrap and negotiating with the Debian 10 LTS team to get
it into buster/updates in the security archive; and it's not clear to
me that there is actually any apt repository that we could put it into
that would be accepted by the affected buildds, because buster is read-only
in the main Debian archive, and debian-security no longer has
dists/buster/updates/main/binary-mips64el at all?

(debian-security does have binary-all, and debootstrap is Architecture:
all, but I'm not sure how much that would help us with buster's apt, since
separate Packages files for binary-all seem to be a relatively new thing.)

> > From the point of view of the project having control over its own future,
> > I would have hoped that official Debian infrastructure would only be using
> > suites that are supported by Debian as a whole, rather than handing over
> > control and responsibility to the Debian-LTS subproject.

Sam Hartman pointed out on #debian-devel that this is worse than I thought,
because Debian-LTS doesn't cover mips*el. So as far as I can see, there is
no channel that gets security updates onto these buildds at all?

smcv

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Simon McVittie]

3+deb11u1/debian/changelog	2022-07-28 12:04:03.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/changelog	2023-08-30 22:34:37.0 +0100
@@ -1,3 +1,47 @@
+debootstrap (1.0.123+deb11u2) bullseye; urgency=medium
+
+  * Non-maintainer upload targeting Debian 11, with maintainer approval
+from Luca Boccassi.
+
+  [ Samuel Thibault ]
+  * Enable usrmerge on hurd-i386 too
+
+  [ Ansgar, Tianon Gravi ]
+  * debian-common: exclude usrmerge and its dependencies when installing
+usr-is-merged. These are not needed on systems where /usr is already
+merged, and avoiding them saves around 50M in a minbase installation.
+(Closes: #1025657)
+
+  [ Hideki Yamane ]
+  * Add support for bootstrapping trixie
+
+  [ Simon McVittie, Luca Boccassi ]
+  * Backport merged-/usr support changes from trixie:
+- Implement merged-/usr by post-merging.
+  This changes the bootstrap order so that it will be possible for a
+  future version of base-files in trixie/sid to take responsibility for
+  creating the /bin, /sbin, /lib* symlinks, and is a prerequisite for
+  lifting the moratorium imposed by #1035831.
+  (Closes: #1049898; implementation by Helmut Grohne)
+- functions: Reinstate setup_merged_usr() as it existed before
+  fixing #1049898, for backwards-compatibility with older versions of
+  mmdebstrap.
+- functions: Default to merged-/usr for suites newer than bookworm,
+  even for the buildd profile. This allows packages targeting trixie
+  to assume that merged-/usr is the only layout possible, and is a
+  prerequisite for lifting the moratorium imposed by #1035831.
+- Mention --merged-usr in --help output. (Closes: #1031828)
+  * Backport autopkgtest regression fixes from trixie:
+- Revert fake/schroot-1.6.10-3 to an accurate emulation of the
+  behaviour of schroot 1.6.10-3 (Closes: #983311)
+- Document schroot 1.6.10-3 with the default profile as expected to
+  fail to use /dev/pts in a lxc >= 3 or Docker container; this is a
+  schroot bug (#983423) and not a debootstrap bug
+- With these changes, the autopkgtest is confirmed to pass in
+  autopkgtest-virt-qemu (Closes: #983197)
+
+ -- Simon McVittie   Wed, 30 Aug 2023 22:34:37 +0100
+
 debootstrap (1.0.123+deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru debootstrap-1.0.123+deb11u1/debian/gbp.conf debootstrap-1.0.123+deb11u2/debian/gbp.conf
--- debootstrap-1.0.123+deb11u1/debian/gbp.conf	2022-07-13 23:17:17.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/gbp.conf	2023-08-30 22:34:37.0 +0100
@@ -1,2 +1,3 @@
-[buildpackage]
+[DEFAULT]
 debian-tag = %(version)s
+debian-branch = bullseye
diff -Nru debootstrap-1.0.123+deb11u1/debian/.gitignore debootstrap-1.0.123+deb11u2/debian/.gitignore
--- debootstrap-1.0.123+deb11u1/debian/.gitignore	1970-01-01 01:00:00.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/.gitignore	2023-08-30 22:34:37.0 +0100
@@ -0,0 +1,6 @@
+debootstrap
+debootstrap-udeb
+files
+*.debhelper.log
+*.substvars
+
diff -Nru debootstrap-1.0.123+deb11u1/debian/salsa-ci.yml debootstrap-1.0.123+deb11u2/debian/salsa-ci.yml
--- debootstrap-1.0.123+deb11u1/debian/salsa-ci.yml	2022-07-13 23:17:17.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/salsa-ci.yml	2023-08-30 22:34:37.0 +0100
@@ -6,3 +6,4 @@
 variables:
   SALSA_CI_DISABLE_BLHC: 1
   SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1
+  RELEASE: 'bullseye'
diff -Nru debootstrap-1.0.123+deb11u1/debian/tests/debian-testing debootstrap-1.0.123+deb11u2/debian/tests/debian-testing
--- debootstrap-1.0.123+deb11u1/debian/tests/debian-testing	2022-07-13 23:17:17.0 +0100
+++ debootstrap-1.0.123+deb11u2/debian/tests/debian-testing	2023-08-30 22:34:37.0 +0100
@@ -132,12 +132,31 @@
 cat /etc/debian_version)]),
 $reference);
 
-check_fake_schroot(%params, reference => $reference);
+# The schroot behaviour proposed to fix #856877 and #983423 works,
+# even inside (privileged) lxc.
 check_fake_schroot(%params, reference => $reference, version => 'proposed');
 check_fake_schroot(%params, reference => $reference, version => 'proposed',
 extra_argv => ['--sbuild']);
 
-# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817236
+# As of 1.6.10-3, or equivalently 1.6.10-11, the default profile
+# certainly doesn't work in lxc >= 3 or in Docker:
+# https://bugs.debian.org/983423
+# It probably won't work in other container managers either, for
+# similar reasons.
+if (defined $params{container}) {
+TODO: {
+local $TODO = "schroot default profile doesn't work in lxc >= 3 or Docker";
+check_fake_schroot(%params, reference => $reference,
+version => '1.6.10-3');
+}
+}
+else {
+check_fake_schroot(%params, reference => $reference,
+version => '1.6.10-3');
+

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Simon McVittie]

Control: tags -1 + d-i

On Wed, 30 Aug 2023 at 16:27:12 +0100, Simon McVittie wrote:
> Part of the transition to merged-/usr, and more specifically, allowing
> us to stop shipping files in trixie whose physical path on disk does
> not match their path in the dpkg database due to directory aliasing.
> 
> This change needs to be in bookworm (and bullseye, and maybe buster)
> before that process can continue, because official buildds run debootstrap
> from stable (or older).
> 
> I also took the opportunity to backport changes that make the autopkgtests
> pass.

Sorry, I should have mentioned that this is a (significant) d-i component
and so will presumably need a d-i ack. I haven't explicitly cc'd
debian-boot on the basis that it's already the package's maintainer of
record (and the bug already appeared on the mailing list).

smcv

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, bl...@debian.org, 
debian-wb-t...@lists.debian.org

Luca Boccassi and I have been preparing stable and oldstable updates for
debootstrap so that the transition described in DEP-17 can continue.
Because DEP-17 involves changes to trixie/sid chroots' bootstrap
procedures, the updated debootstrap needs to be deployable to every
official buildd, and we've been told that (old)stable point releases
are the preferred way to achieve that.

When Luca asked how many suites we needed this change in, we were hoping
the answer would be stable only, and maybe oldstable (which is still
in its 1 year of overlapping support from the security team and DDs
in general).

However, if I understand correctly, Luca has been told that some official
mips64el buildds are running mipsel user-space on mips64el hardware which
only works with the buster kernel, and therefore those official buildds
are still stuck on buster, meaning we also need to prepare a buster
version of debootstrap and get it into Debian 10 LTS via buster-security.

Is this true?

>From the point of view of the project having control over its own future,
I would have hoped that official Debian infrastructure would only be using
suites that are supported by Debian as a whole, rather than handing over
control and responsibility to the Debian-LTS subproject.

Also, from the point of view of continued development of testing/unstable,
I would have hoped that packages in testing/unstable could safely
assume that they will run on at least the kernel from stable (or maybe
oldstable for a short time after a new stable release), following our
usual "skipping a release is unsupported" rule. Obviously if the buildds
are running on an oldoldstable kernel, any mips64el package that might
be used at compile-time or for build-time tests will be unable to make
that assumption.

Please could someone with knowledge of the buildds clarify the situation?

If our official buildds for a release architecture are unable to run on
either the stable or oldstable kernel, I think that raises some important
questions about suitability for inclusion in future releases.

Thanks,
smcv

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Simon McVittie]

ocument schroot 1.6.10-3 with the default profile as expected to
+  fail to use /dev/pts in a lxc >= 3 or Docker container; this is a
+  schroot bug (#983423) and not a debootstrap bug
+- With these changes, the autopkgtest is confirmed to pass in
+  autopkgtest-virt-qemu (Closes: #983197)
+
+ -- Simon McVittie   Wed, 30 Aug 2023 15:21:17 +0100
+
 debootstrap (1.0.128+nmu2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru debootstrap-1.0.128+nmu2/debian/gbp.conf debootstrap-1.0.128+nmu2+deb12u1/debian/gbp.conf
--- debootstrap-1.0.128+nmu2/debian/gbp.conf	2022-10-18 23:48:32.0 +0100
+++ debootstrap-1.0.128+nmu2+deb12u1/debian/gbp.conf	2023-08-30 15:21:17.0 +0100
@@ -1,2 +1,3 @@
 [DEFAULT]
 debian-tag = %(version)s
+debian-branch = bookworm
diff -Nru debootstrap-1.0.128+nmu2/debian/.gitignore debootstrap-1.0.128+nmu2+deb12u1/debian/.gitignore
--- debootstrap-1.0.128+nmu2/debian/.gitignore	1970-01-01 01:00:00.0 +0100
+++ debootstrap-1.0.128+nmu2+deb12u1/debian/.gitignore	2023-08-30 15:21:17.0 +0100
@@ -0,0 +1,6 @@
+debootstrap
+debootstrap-udeb
+files
+*.debhelper.log
+*.substvars
+
diff -Nru debootstrap-1.0.128+nmu2/debian/salsa-ci.yml debootstrap-1.0.128+nmu2+deb12u1/debian/salsa-ci.yml
--- debootstrap-1.0.128+nmu2/debian/salsa-ci.yml	2022-08-30 20:48:37.0 +0100
+++ debootstrap-1.0.128+nmu2+deb12u1/debian/salsa-ci.yml	2023-08-30 15:21:17.0 +0100
@@ -6,3 +6,4 @@
 variables:
   SALSA_CI_DISABLE_BLHC: 1
   SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 1
+  RELEASE: 'bookworm'
diff -Nru debootstrap-1.0.128+nmu2/debian/tests/debian-testing debootstrap-1.0.128+nmu2+deb12u1/debian/tests/debian-testing
--- debootstrap-1.0.128+nmu2/debian/tests/debian-testing	2022-08-30 20:48:37.0 +0100
+++ debootstrap-1.0.128+nmu2+deb12u1/debian/tests/debian-testing	2023-08-30 15:21:17.0 +0100
@@ -132,12 +132,31 @@
 cat /etc/debian_version)]),
 $reference);
 
-check_fake_schroot(%params, reference => $reference);
+# The schroot behaviour proposed to fix #856877 and #983423 works,
+# even inside (privileged) lxc.
 check_fake_schroot(%params, reference => $reference, version => 'proposed');
 check_fake_schroot(%params, reference => $reference, version => 'proposed',
 extra_argv => ['--sbuild']);
 
-# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817236
+# As of 1.6.10-3, or equivalently 1.6.10-11, the default profile
+# certainly doesn't work in lxc >= 3 or in Docker:
+# https://bugs.debian.org/983423
+# It probably won't work in other container managers either, for
+# similar reasons.
+if (defined $params{container}) {
+TODO: {
+local $TODO = "schroot default profile doesn't work in lxc >= 3 or Docker";
+check_fake_schroot(%params, reference => $reference,
+version => '1.6.10-3');
+}
+}
+else {
+check_fake_schroot(%params, reference => $reference,
+version => '1.6.10-3');
+}
+
+# schroot 1.6.10-3's sbuild profile does work in lxc, but only on newer
+# kernels: https://bugs.debian.org/856877
 if (Dpkg::Version->new($params{kernel}) < Dpkg::Version->new('4.7') &&
 defined $params{container} && $params{container} eq 'lxc') {
 TODO: {
@@ -160,10 +179,12 @@
 extra_argv => ['--sbuild']);
 }
 
+# pbuilder >= 0.228.6 works fine
 check_fake_pbuilder(%params, reference => $reference,
 version => 'proposed');
 
-# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817236
+# Older pbuilder doesn't work if we are in a container where we can't
+# create the /dev/ptmx device node: https://bugs.debian.org/841935
 if (! $params{can_mknod_ptmx}) {
 TODO: {
 local $TODO = "schroot --sbuild doesn't work when /dev/ptmx is ".
diff -Nru debootstrap-1.0.128+nmu2/debian/tests/fake/schroot-1.6.10-3 debootstrap-1.0.128+nmu2+deb12u1/debian/tests/fake/schroot-1.6.10-3
--- debootstrap-1.0.128+nmu2/debian/tests/fake/schroot-1.6.10-3	2022-08-30 20:48:37.0 +0100
+++ debootstrap-1.0.128+nmu2+deb12u1/debian/tests/fake/schroot-1.6.10-3	2023-08-30 15:21:17.0 +0100
@@ -34,7 +34,6 @@
 
 [ "$bind_dev" = no ] || mount --bind /dev "$chroot/dev"
 mount --bind /dev/pts "$chroot/dev/pts"
-mount --bind /dev/ptmx "$chroot/dev/ptmx"
 
 ls -l "$chroot/dev/ptmx" | sed -e 's/^/# fake-schroot: /' >&2
 ls -l "$chroot/dev/pts/ptmx" | sed -e 's/^/# fake-schroot: /' >&2
@@ -43,7 +42,6 @@
 chroot "$chroot" "$@" || e=$?
 
 umount "$chroot/dev/pts"
-umount "$chroot/dev/ptmx"
 [ "$bind_dev" = no ] || umount "$chroot/dev"
 
 exit "$e"
diff -Nru debootstrap-1.0.128+nmu2/debootstrap deboots

Bug#1050325: Unknown group "wheel" in message bus configuration file

[Simon McVittie]

On Wed, 30 Aug 2023 at 11:44:56 +0200, Michael Biebl wrote:
> [iwd] triggers a warning on every start or reload of dbus:
> 
> Aug 08 20:01:51 pluto dbus-daemon[706]: Unknown group "wheel" in message bus
> configuration file
> 
> I do consider this a bug in the configuration that is shipped by the iwd
> package.

I agree with Michael. Debian packages should only refer to groups
that are reserved by base-passwd, the package itself, or the package's
dependencies.

This is arguably even a security issue: the "wheel" group name is not
reserved on Debian systems, so there would be nothing preventing a user
(presumably one without knowledge of 1980s Unix tradition or conventional
group names in non-Debian distros) from creating a new user/group of
that name, not expecting that it would grant extra privileges.

The closest Debian equivalent of other distros' wheel group is the
sudo group, as defined by base-passwd.

(It would probably also be better if iwd could avoid group-based policy in
dbus-daemon configuration files and instead use polkit to query policy,
but I realise that's non-trivial upstream development work, and it's
out of scope for this particular bug.)

smcv

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Simon McVittie]

Control: tags -1 + moreinfo

On Wed, 07 Dec 2022 at 20:11:11 +, Luca Boccassi wrote:
> An improvement to reduce the number of dependencies pulled down by the
> usr-merged debootstrapped image has been available in unstable,
> bookworm and bullseye-backports for a while. I'd like to make this
> improvement available in bullseye as well, as it saves ~50MB on a
> minbase image.

As discussed with jmw at the #debian-uk summer party, I'm repurposing
this bug for a newer debootstrap backport incorporating some changes that
are needed to complete the transition to merged /usr, so it is not ready
for further action until updated. Marking as moreinfo to take it off the
SRMs' radar for now.

(Our intention is that I'll implement and test a release candidate,
Luca will review, and then we'll re-propose this when we're both happy.)

On Wed, 15 Mar 2023 at 21:07, Jonathan Wiltshire  wrote:
> This sounds like a behaviour change in stable, which would be very unusual
> unless it fixes significant issues. Can it really be justified?

The situation has changed since then: bookworm is now stable, bullseye
is oldstable, bookworm has the "new" behaviour, and we're going to need
to make a larger behaviour change in bullseye anyway (for the benefit of
any official buildds that have not yet been upgraded to bookworm).
Aligning bullseye debootstrap behaviour more closely with bookworm seems
likely to be more palatable than entirely new behaviours.

I discussed this with jmw and he agreed the SRMs could consider getting
#1025657 fixed in oldstable. Of course, if the change previously proposed
here seems too risky, we can revert it and keep only the higher-priority
stuff.

smcv

Bug#1050804: lxqt-session: please provide an lxqt-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: lxqt-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/lxqt-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for LXQt
(https://github.com/lxqt/xdg-desktop-portal-lxqt exists, but I couldn't
find an ITP for it). Please add an lxqt-portals.conf to tell x-d-p more
explicitly what backends LXQt is meant to be using by default.

For example, if the intention is to try to use the -lxqt backend, falling
back to -gtk if -lxqt isn't installed or doesn't know how to do something,
the way to write that would be:

[preferred]
default=lxqt;gtk;

The desktop environment (either lxqt-session or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050803: mate-session-manager: please provide a mate-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: mate-session-manager
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/mate-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for MATE
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an mate-portals.conf to tell x-d-p more explicitly what backends
MATE is meant to be using by default.

For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:

[preferred]
default=xapp;gtk;

The desktop environment (either mate-session-manager or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050802: xfce4-session: please provide an xfce-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: xfce4-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/xfce-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for XFCE
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an xfce-portals.conf to tell x-d-p more explicitly what backends
XFCE is meant to be using by default.

For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:

[preferred]
default=xapp;gtk;

The desktop environment (either xfce4-session or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050801: cinnamon-common: please provide an x-cinnamon-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: cinnamon-common
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/x-cinnamon-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for Cinnamon
(although I see there's an ITP open for x-d-p-xapp, #1038946). Please
add an x-cinnamon-portals.conf to tell x-d-p more explicitly what backends
Cinnamon is meant to be using by default.

For example, if the intention is to try to use the -xapp backend, falling
back to -gtk if -xapp isn't installed or doesn't know how to do something,
the way to write that would be:

[preferred]
default=xapp;gtk;

The desktop environment (either cinnamon-common or some larger metapackage)
should probably also have a Recommends, or at least a Suggests, on whatever
portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050800: openbox-lxde-session: please provide an lxde-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: openbox-lxde-session
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf

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/lxde-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

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.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that, and anyway Debian doesn't
currently ship any portal backends that are flagged as suitable for LXDE
(https://github.com/lxqt/xdg-desktop-portal-lxqt exists, but I couldn't
find an ITP for it). Please add an lxde-portals.conf to tell x-d-p more
explicitly what backends LXDE is meant to be using by default.

For example, if the intention is to try to use the -lxqt backend, falling
back to -gtk if -lxqt isn't installed or doesn't know how to do something,
the way to write that would be:

[preferred]
default=lxqt;gtk;

The desktop environment (either openbox-lxde-session or some larger
metapackage) should probably also have a Recommends, or at least a
Suggests, on whatever portals would be most appropriate for it.

Thanks,
smcv

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

Bug#1050799: gnome-session-flashback: please provide a gnome-flashback-portals.conf for xdg-desktop-portal

[Simon McVittie]

Package: gnome-session-flashback
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
Forwarded: https://gitlab.gnome.org/GNOME/gnome-flashback/-/issues/91

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/gnome-flashback-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

In the case of gnome-session-flashback, XDG_CURRENT_DESKTOP is set to
GNOME-Flashback:GNOME, so in the absence of other configuration it would
use the gnome-portals.conf from gnome-session (if installed). However,
because GNOME Flashback uses metacity rather than GNOME Shell, its mix
of desired portals is probably somewhat different from the full-fat GNOME
session, so probably it should have its own gnome-flashback-portals.conf
that doesn't try to make use of GNOME-Shell- or Mutter-specific interfaces?

https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
was the equivalent change for gnome-session.

Thanks,
smcv

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

Bug#1050798: plasma-workspace: please provide a kde-portals.conf for xdg-desktop-portal

[Simon McVittie]

Source: plasma-workspace
Severity: normal
Tags: trixie sid
User: xdg-desktop-por...@packages.debian.org
Usertags: portals.conf
Control: affects -1 plasma-mobile

xdg-desktop-portal 1.17.x (currently in experimental) 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/kde-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

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 of the search mechanism.

As a backwards-compatibility mechanism, x-d-p will fall back to trying
to guess the most appropriate portals from the portals' UseIn= fields,
but it will log warnings when it does that. Please add a kde-portals.conf
to tell x-d-p more explicitly what backends Plasma is meant to be using
by default, and test with x-d-p from experimental to check that it's
working as expected.
https://salsa.debian.org/gnome-team/gnome-session/-/commit/b201c9c40e3adc7bf0b1c3504bef4c8602aac31d
is an example of the equivalent change in GNOME.

In KDE's case, it looks as though plasma-workspace and plasma-mobile share
the DesktopNames=KDE name but plasma-mobile depends on plasma-workspace,
so kde-portals.conf can probably be in plasma-workspace without any
further changes required in plasma-mobile?

I believe the file contents can be as simple as this (untested):

[preferred]
default=kde;

plasma-workspace (and plasma-mobile?) should probably have at least a
Recommends on xdg-desktop-portal-kde for this (see also #1019918).

Thanks,
smcv

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

Bug#1033274: gnome-session: recommends xdg-desktop-portal-gnome and not depends

[Simon McVittie]

On Tue, 29 Aug 2023 at 10:32:23 +0100, Pablo Mazzini wrote:
> > Therefore, the desktop session needs to depend on the portal that has the
> > best integration.
> 
> Why does this dependency needs to be specified in the gnome-session package?
> Wouldn't gnome-core be a better place to specify this?

gnome-core is a somewhat complete GNOME session with various utilities
included (an image viewer, a calculator, software updates, a terminal...),
while gnome-session is the minimal GNOME session containing only the
necessary infrastructure to log in to a working GNOME interface.
Their scope is rather different.

x-d-p-gnome is more like behind-the-scenes desktop environment plumbing
than a user-facing application: various applications will not work
correctly without it. It also isn't very large. Having a working portal
backend is becoming similar to having a working D-Bus session bus,
or a working fd.o Notifications interface, or a working X11 or Wayland
display, or a working sound server: something that apps assume, such
that the app can't work correctly without it.

Let me turn this around: what is your use-case for installing
gnome-session but not x-d-p-gnome, such that logging into a minimal
GNOME session is possible, but applications that require a working portal
backend will not work correctly while logged into that session?

smcv

Bug#1029842: ITP: randombytes -- Library generating fresh randomness

[Simon Josefsson]

Sam Hartman  writes:

>>>>>> "Jan" == Jan Mojzis  writes:
>
> * Package name: randombytes
>   Version : 20230126
>   Upstream Author : Daniel J. Bernstein
> * URL : https://randombytes.cr.yp.to/
> * License : Public domain
>
> Public domain is problematic  as a license.
> At least under US copyright law, there are very few circumstances when
> something can actually be public domain.
> One example is software written by US government employees.
> But I don't think any of those circumstances apply to this library.
> So I'm not sure the license is okay.

We have plenty of code written under that same license from the same
group of authors, already in Debian.  Look in OpenSSH and OpenSSL for
example.  So I would disagree there is a license problem having this
package in Debian.

Jan, I'm happy to help review, sponsor and co-maintain randombytes if
you are interested.  I rely on it as a dependency in some projects I'm
working on.

/Simon


signature.asc
Description: PGP signature

Bug#1044135: openmw: Crosshair, interactive prompts and character creation menus not visible.

[Simon McVittie]

Control: reassign -1 src:mygui 3.4.2+dfsg-1
Control: affects -1 + openmw

On Mon, 28 Aug 2023 at 13:17:22 +0200, bret curtis wrote:
> On Sun, Aug 13, 2023 at 5:33 PM dwimo  wrote:
> > After starting a new game [of openmw] the crosshair and the interactive 
> > prompts
> > (fe. typing in your name, clicking 'ok' or 'yes'/'no') and the menus
> > for character creation are not visble. They do seem to respond though
> > (fe. clicking exit in the menu and then pressing enter stops the game
> > like expected).
> > Otherwise it seems I can play the game normally, except from being unable
> > to create a character I want (because I don't now what has been selected)
> 
> the issue is with MyGUI, a known issue, resolved upstream.[1] The problem
> is that unless a config release type is defined, it will produce a broken
> build. So there are two fixes proposed:
> 
> 1) rebuild MyGUI 3.4.2 but set the build to: RelWithDebugInfo
> 
> 2) upload MyGUI 3.4.3 which I've already prepared here:
> https://mentors.debian.net/package/mygui
> 
> Caveat: 3.4.3 will require a patch for OpenMW 0.48 to support as there are
> ABI changes. :(
> 
> Could someone recategorize this error as being caused by MyGUI 3.4.2
> please? [2]

Reassigning to mygui as requested.

If the fixed upstream release breaks ABI and will require a transition,
then I think it would be best if someone can prepare and test a patch
for 3.4.2 to get this fixed (either by changing the build options or
by patching upstream source to fix the bug), and then the transition to
3.4.3 can be a separate change.

smcv

Bug#1050665: clutter-1.0: FTBFS on riscv64 due to test timeout

[Simon McVittie]

On Sun, 27 Aug 2023 at 21:18:38 +0200, Aurelien Jarno wrote:
>  test(t, test_bin,
>suite: suite_name,
>env: test_env,
> +  timeout: 100,
>  )

It's probably worth mentioning before you file too many bugs similar to
this one that Meson has a feature that's really useful in this situation:
if debian/rules passes an argument like `--timeout-multiplier 5` to
`meson test`, then all test(timeout:) arguments are multiplied by 5.

Choosing an appropriate --timeout-multiplier is often enough to make
tests pass on slower buildds without having to patch any upstream source,
which reduces the time spent on rebasing patches later.

smcv

Bug#967622:

[Simon McVittie]

Control: unmerge 967622 1050361
Control: reopen 967622
Control: block 967497 by 967622
Control: block 947713 by 967622

On Wed, 23 Aug 2023 at 23:02:07 -0700, Vincent Cheng wrote:
> forcemerge 967622 1050361

I have no objection to the removal request #1050361 being closed without
action, but please don't treat #967622 as equivalent to a removal
request. mangler *does* depend on GTK 2 and gtkmm2.4 - that's just a
fact - and it's going to be much easier to keep track of how much GTK 2
is left in the archive if we keep the bug reports around.

(I'm listed as a maintainer for at least one GTK 2 package myself, gmpc,
and I have no plan to remove that during the trixie cycle and probably
too many other things on my list to upgrade it to GTK 3 this cycle either;
so its bug stays open.)

If there are no plans to either remove mangler or upgrade it to GTK 3
any time soon, perhaps you could take #967622 off your radar by tagging
it wontfix, rather than by closing it?

Thanks,
smcv

Bug#1050001: Unwinding directory aliasing

[Simon McVittie]

On Wed, 23 Aug 2023 at 17:04:36 +0100, Ian Jackson wrote:
> Simon McVittie writes ("Bug#1050001: Unwinding directory aliasing"):
> > What do you consider to be the end goal of this proposal?
> 
> My idea of a desired end state is as follows:
> 
> /bin and /lib etc. remain directories (so there is no aliasing).  All
> actual files are shipped in /usr.  / contains compatibility symlinks
> pointing into /usr, for those files/APIs/programs where this is needed
> (which is far from all of them).  Eventualloy, over time, the set of
> compatibility links is reduced to a mere handful.

This is not merged-/usr with the meaning used by the technical committee's
past resolutions, and by most (all?) non-Debian distributions (among
which Fedora and Arch were among prominent early adopters).

I recognise that you don't want merged-/usr, and instead you want
this non-merged-/usr layout, which shares some of the properties of
merged-/usr; but it isn't the same thing, and it makes discussion
and reasoning unnecessarily difficult if we use the same name for two
different things, so please could you avoid the term "merged /usr"
for this?

> I think this is a more desirable situation than the current planned
> end state, which is that /bin and /lib are symlinks.

The meaning ascribed to "merged /usr" or "the /usr merge" by previous
TC resolutions is exactly the layout where /bin and /lib (and so on)
are symlinks. Outside Debian, that's also the layout described in
documents like "The Case for the /usr Merge".

I acknowledge that, whatever we choose to call it, you would prefer not
to end at that state, and this is a point on which our opinions differ.

> The current plan, as I understand it, is that we will fix these
> problems by arranging to *always* name files by their canonical paths,
> ie the ones in /usr.

Using the word "canonical" is not necessarily helpful here, because
there are two reasonable-but-contradictory things you might mean by
it. Depending who you ask, the canonical path of /bin/sh on a system
with some sort of unified /usr might be:

* /usr/bin/sh, because that's the physical path as returned by realpath()
  (I believe this is what you mean when you say "canonical", because
  you're thinking in terms of the path canonicalization operation done
  by realpath() and similar things);

* or /bin/sh, because that's the interoperable path that has worked on
  all Linux distributions since time immemorial (even though this might
  not have anything to do with the physical path)

May I suggest we avoid saying "canonical" as ambiguous, and use something
like "physical path" and "traditional path" for these two concepts?

If by "name files" you mean references to filenames from elsewhere, then
that is not the plan as I understand it (see below).

If by "name files" you mean "name files in dpkg's database", then yes,
I believe the current plan is that we end up with dpkg's idea of the list
of installed files referring to every file by its physical path, so that
for example the dpkg database contains the physical path /usr/bin/sh,
even though the traditional path is /bin/sh. Another way to express
this is that if you install a Debian chroot and pack it into an archive
in the obvious way, what you should get (in the absence of any uses of
dpkg-divert, etc.) is the union of the data.tar of all the installed
packages, plus additional non-dpkg-managed files like /etc/passwd.

> Naming files by their canonical names will have to be done everywhere.

I would dispute that. We routinely name system-critical files by
non-physical paths - for example /bin/sh is really /{usr/,}bin/dash,
and /lib64/ld-linux-x86-64.so.2 is really
/{usr/,}lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 - and have done so
for a long time.

> violations of the "use only [physical] names" rule are not only
> expected, they are *necessary*:

Right, and that's why that is not a rule we are following.

One of the reasons that merged-/usr appeals to me personally is
that it takes an entire equivalence class of bugs, and turns them
into non-bugs. If merged-/usr is ubiquitous, then we don't need to
expect third-party software developers to "just know" that /bin/sh and
/usr/bin/perl are the traditionally "correct" paths, because /usr/bin/sh
and /bin/perl become equally valid and interoperable things to put at
the beginning of a script.

In the state we had before bookworm, where merged-/usr was supported but
not mandatory, we required Debian maintainers to be careful to refer to
files by their traditional name, even though on a newly-installed Debian
system with merged-/usr, the "other" name would have worked equally well;
and we were also implicitly expecting upstream and third-party developers
to also know that they had to use t

Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

[Simon McVittie]

Control: tags -1 - pending

On Sat, 19 Aug 2023 at 12:34:31 +0100, Simon McVittie wrote:
> I haven't reconstructed the actual images for a visual comparison yet.
> If the mis-rendering doesn't seem release-critically bad then we'll work
> around this by ignoring those particular test failures on mips*el.

The mis-rendering doesn't seem likely to cause RC-severity bugs for end
users, so yes I'm going to ignore them.
https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/16

smcv

Bug#1043144: transition: mutter/gnome-shell 44

[Simon McVittie]

On Sun, 20 Aug 2023 at 19:52:50 +, Graham Inggs wrote:
> On Tue, 15 Aug 2023 at 17:18, Simon McVittie  wrote:
> > I think this is ready to go. Repeating the list of packages needing
> > sourceful uploads from experimental into unstable in approximately this
> > order, for the release team's convenience

We uploaded all these, and then did a follow-up upload of mutter and
gnome-shell to ignore some mutter autopkgtest regressions on s390x
(#1050220, which I do not intend to treat as RC since s390x is not
really a useful or realistic platform for this purpose).

> > And then any remaining extensions in
> > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org=gnome-shell-44
> > will need temporarily removing from testing to let the transition through.

Please consider adding hints as follows:

remove gnome-shell-extension-arc-menu/49+forkv29-3
remove gnome-shell-extension-dashtodock/75-1
remove gnome-shell-extension-easyscreencast/1.7.0-2
remove gnome-shell-extension-flypie/21-1
remove gnome-shell-extension-freon/52+dfsg-1
remove gnome-shell-extension-gamemode/8-2
remove gnome-shell-extension-hamster/0.10.0+git20210628-4
remove gnome-shell-extension-impatience/0.4.8-2
remove gnome-shell-extension-panel-osd/1.0.50.gc032923-3
remove gnome-shell-extension-system-monitor/40-5
remove gnome-shell-extension-vertical-overview/10-1
remove gnome-shell-extension-weather/119-1

which if all goes well should get this transition migrated at the weekend.

If I understand britney syntax correctly, if extension maintainers do
a new sourceful upload fixing the "needs update for GNOME Shell 44" RC
bugs, those removal hints would not match the updated package because
its version would be higher, so the newer version would still be allowed
to migrate and stay in testing.

Thanks,
smcv

Bug#1050027: libcoq-mathcomp-classical: undeclared file conflict with libcoq-mathcomp-analysis/bookworm+trixie

[Simon McVittie]

On Wed, 23 Aug 2023 at 08:41:44 +0200, julien.pu...@gmail.com wrote:
> let's lower the severity to avoid blocking migration during the
> discussion -- after all the Breaks already avoids the file conflict
> issue.

Sorry, no, it does not. What Helmut said looks correct.

The Breaks prevents apt from installing the new libcoq-mathcomp-classical
without also upgrading or deconfiguring libcoq-mathcomp-analysis, but
does not constrain the order in which apt/dpkg will carry out the upgrade.

If they happen to have chosen this order of operations, which is what
happened when I tried an upgrade from bookworm to sid, and presumably
also what you saw in your own testing:

1. unpack the new libcoq-mathcomp-analysis
  (leaving its dependency on libcoq-mathcomp-classical temporarily
  unsatisfied - the overall state of the system is "partially broken")
2. unpack the new libcoq-mathcomp-classical
3. configure libcoq-mathcomp-classical
4. configure libcoq-mathcomp-analysis
   (the system is back to a consistent state)

then the file-overwrite will be avoided. But if it chooses this order
of operations:

1. temporarily mark the old libcoq-mathcomp-analysis as deconfigured
   (again, the overall state of the system is "partially broken")
2. unpack the new libcoq-mathcomp-classical
3. unpack the new libcoq-mathcomp-analysis
4. configure libcoq-mathcomp-classical
5. configure libcoq-mathcomp-analysis
   (the system is back to a consistent state)

then step 2 is going to fail, because the old libcoq-mathcomp-analysis
contained files also present in the new libcoq-mathcomp-classical.
(Symptom: "trying to overwrite x, which is also in package y")

With the current metadata, there is no guarantee which of those
two upgrade sequences apt will choose. It is common for bugs of this
category to not happen during the maintainer's testing, but then be easily
reproducible by other users who have more/different packages installed,
which makes apt choose a slightly different upgrade path.

smcv

Bug#1050322: Partial versus complete replacement of a package by another

[Simon McVittie]

On Wed, 23 Aug 2023 at 09:22:41 +0200, julien.pu...@gmail.com wrote:
> In src:mathcomp-analysis 0.6.4-2, I declared that libcoq-mathcomp-
> classical Breaks libcoq-mathcomp-analysis (<< 0.6.4) and closed the
> bug. It was swiftly re-opened because I hadn't used Breaks+Replaces
> according to Policy 7.6.1. But I don't want to use Replaces as libcoq-
> mathcomp-classical isn't a *complete* replacement for libcoq-mathcomp-
> analysis (<< 0.6.4) -- it only provides a small part of it!

It seems you've misunderstood what Replaces means: it doesn't mean
"is a complete drop-in replacement for". (That would need a Provides too.)

Policy 7.6.1 talks about an old package foo which has been split into
new packages foo and foo-data, which seems like your situation with the
names changed?

> The problem is with section 7.6 on how to use Replaces: indeed, the
> very first paragraph of 7.6 mentions "two distinct purposes", partial
> and complete replacement... but the rest of the section is all about
> complete replacement

What I see in that section is:

7.6. Overwriting files and replacing packages - Replaces
7.6.1. Overwriting files in other packages
7.6.2. Replacing whole packages, forcing their removal

7.6.2 is about complete replacement, so by a process of elimination,
7.6.1 ought to be about partial replacement (and it is: it talks about
"The new version of the package foo", which wouldn't exist if foo-data
had completely superseded it).

> In fact subsection 7.6.1 has an example which looks exactly like
> #1050027, but it looks wrong: if foo 1.2-2 is installed on a system and
> foo-data 1.2-3's installation is requested, then because of Breaks dpkg
> will know about the file conflicts and beware, but because of Replaces,
> it will think it's a complete replacement -- foo will disappear if I
> understand well.

No, the central misunderstanding here is that you think Replaces will
have the effect of instructing dpkg to remove the replaced package
completely, which is not the case.

smcv

Bug#1050312: gtk4: a change in some dependency caused different line wrapping on i386 only

[Simon McVittie]

Source: gtk4
Version: 4.10.5+ds-4
Severity: normal
User: debian...@lists.debian.org
Usertags: i386
X-Debbugs-Cc: b...@debian.org

gtk4 4.12.0 failed some tests on i386, which I initially thought were a
regression in 4.12.0, but then 4.10.5+ds-4 failed in the same way.
4.10.5+ds-3 and 4.10.5+ds-4 are essentially the same (the only changes
were unrelated) so this must have been triggered to a change to a
dependency: I would guess fontconfig and pango1.0 are the most likely
candidates.

I don't know whether this results in user-visible regressions to GTK
4 applications on i386; that would be a question for someone who is
routinely using a full i386 system.

These are reftests, which work by rendering GTK's internal representation
of two UIs (loaded from text files) to an image, and comparing them. The
idea is that they're two different ways to achieve the same result, one
simple and one exercising some more complicated code path.

The tests still pass on every other architecture, so I suspect that what's
happening here might be that different rounding from the i387 floating
point interface having extended-precision registers, and as a result of
that different rounding, the text is a very slightly different width?

To reproduce: build gtk4 source package.

Expected (good) result: the two affected reftests pass, and do not leave
output files in debian/build/deb/testsuite/reftests/output/x11/.

Actual (bad) result: they do leave output files. This does not cause FTBFS
or cause them to be marked as failures, but only because we've told the
test suite to ignore them.

Alternative bad result: before version 4.10.5+ds-5, the failures were not
ignored and caused FTBFS.

Logs:
success (slightly older versions of dependencies):
https://buildd.debian.org/status/fetch.php?pkg=gtk4=i386=4.10.5%2Bds-3=1691406899=0
failure:
https://buildd.debian.org/status/fetch.php?pkg=gtk4=i386=4.10.5%2Bds-4=1692723794=0
failure ignored:
https://buildd.debian.org/status/fetch.php?pkg=gtk4=i386=4.10.5%2Bds-5=1692731298=0

smcv


  
0

  

  
Hello World
end
True
char
  

  

  



  
0

  

  
Hello World
True
char
  

  

  



  
0

  

  
Hello World
1
  

  

  



  
0

  
Hello World
1
  

  

Bug#1050075: (no subject)

[Simon McVittie]

On Tue, 22 Aug 2023 at 12:54:02 +0200, Nathan Teodósio wrote:
> I'm proposing disabling those tests as they were deemed flaky by upstream.

I'm testing what I think is a better approach to disabling *all* tests that
are considered flaky or failing, so I'm not going to apply this unless the
package I'm testing is unsuccessful. (It seemed OK in i386 and s390x builds
on the porterboxes.)

> +Description: Disable flaky checkerboard tests.
> + .
> + gitlab.gnome.org/GNOME/gtk/-/commit/a235b59089a7fe2d7957f20bcd2a67f9aef2f724
> + gitlab.gnome.org/GNOME/gtk/-/commit/5e8e4130a51f8d1f599ee74360c5e9126ff40d48
> + .
> + "When textures are too large, we will scale them down to fit the max texture
> + size, which will cause comparisons to fail."

In future, please could you use clickable URLs rather than deleting the
https:// prefix, and please could you use the `git format-patch`-like
dialect of DEP-3? (Look at most of the existing patches and you'll see
what I mean)

Thanks,
smcv

Bug#1042547: RFS: rednotebook/2.29.6+ds-2~bpo11+1 -- Modern desktop diary and personal journaling tool

[Simon Quigley]

Hello,

I've never uploaded to this pocket before, so I'll leave the bug open just in 
case.

$ dput ftp-master ../rednotebook_2.29.6+ds-2~bpo11+1_source.changes
D: Setting host argument.
Checking signature on .changes
gpg: ../rednotebook_2.29.6+ds-2~bpo11+1_source.changes: Valid signature from 
E27F2CF8458C2FA4
Checking signature on .dsc
gpg: ../rednotebook_2.29.6+ds-2~bpo11+1.dsc: Valid signature from 
E27F2CF8458C2FA4
Package includes an .orig.tar.gz file although the debian revision suggests
that it might not be required. Multiple uploads of the .orig.tar.gz may be
rejected by the upload queue management software.
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading rednotebook_2.29.6+ds-2~bpo11+1.dsc: done.
  Uploading rednotebook_2.29.6+ds.orig.tar.gz: done.
  Uploading rednotebook_2.29.6+ds-2~bpo11+1.debian.tar.xz: done.
  Uploading rednotebook_2.29.6+ds-2~bpo11+1_source.buildinfo: done.
  Uploading rednotebook_2.29.6+ds-2~bpo11+1_source.changes: done.
Successfully uploaded packages.

Have fun,
--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1040359: RFS: vim-julia/0.0~git20221020.fca7e3e-1 [ITA] -- Vim support for Julia language

[Simon Quigley]

Control: tags -1 + moreinfo

Please fix the autopkgtest. Thanks.

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039514: RFS: cil/0.07.00-13 -- command line issue tracker

[Simon Quigley]

Control: tags -1 + moreinfo

Please fix the autopkgtest. Thanks.

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050220: mutter: autopkgtest regression on s390x: tests time out after 5 minutes

[Simon McVittie]

Source: mutter
Severity: normal
Version: 44.0-2
Tags: help
X-Debbugs-CC: debian-s...@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x

Recent versions of the mutter compositor/window manager library fail their
"as-installed" tests on s390x.

Steps to reproduce:

* have a Debian testing/unstable environment
* `apt install gnome-desktop-testing mutter-${v}-tests`
  (where ${v} is 11, 12 or 13 for mutter 43.x, 44.x or 45.x respectively)
* `ginsttest-runner mutter-`
  (you can add other options from its --help if they are useful to you)

Or run the "installed-tests" autopkgtest from the mutter source package,
which automates this.

Expected result:

* 20+ test-cases are run (the exact number varies between versions)
* A summary at the end shows something like this:
  SUMMARY: total=31; passed=31; skipped=0; failed=0; user=16.6s; system=3.7s; 
maxrss=150496
  (possibly with "# " prepended, if you are using ginsttest-runner --tap)

Actual result:

With 43.x, the expected result.

With 44.x, many tests run for 5 minutes (300 seconds) each, with no
useful output, and then are killed by ginsttest-runner with signal 9:

4949s # Executing: 
mutter-12/closed-transient-no-input-no-take-focus-parent.test
4949s not ok - Test timed out after 300 seconds
4949s # FAIL: mutter-12/closed-transient-no-input-no-take-focus-parent.test 
(Child process killed by signal 9)
4949s not ok - mutter-12/closed-transient-no-input-no-take-focus-parent.test
4949s # SUMMARY: total=35; passed=19; skipped=0; failed=16; user=8.6s; 
system=1.8s; maxrss=146164

Since version 44.3-7, this test failure is ignored on s390x, on the basis
that getting GNOME 44 into unstable for users of architectures where
desktop/laptop systems exist seems like it should be a higher priority
for the Debian project than making a 3D-accelerated compositing manager
available on mainframe computers that do not typically have any graphical
output at all. The regression is presumably still a bug, though.

The build-time tests are currently also skipped on s390x.

None of the GNOME maintainers own a $15K+ mainframe or have any particular
interest in running graphical software on one, so we are not intending
to work on this issue further. If this is to be investigated, someone
who values the ability to run the GNOME desktop on s390x should take
responsibility.

s390x has been a repeated time-sink for GNOME maintenance, and I am not
aware of any reasons why mutter/gnome-shell would ever be practically
useful on a mainframe, so I am very tempted to make mutter artificially
unbuildable on that architecture and ask for older mutter, gnome-shell
and related packages to be removed from the archive. This would not
affect the ability to run individual graphical programs from GNOME on
s390x via X11 forwarding (if anyone does that), but it would prevent
the full GNOME desktop from being installed or run on s390x.

Thanks,
smcv

Bug#1050206: rust-test-case: Failed autopkgtest after 3.1.0-3

[Simon Quigley]

Hello,

Since Jonas is in LowNMU, I've uploaded this patch to DELAYED/2 and committed 
it in Git.

Jonas, feel free to cancel the upload (or tell me to) if you have a better 
solution.

Thank you!

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041569: gnome-shell-extension-easyscreencast: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 https://github.com/EasyScreenCast/EasyScreenCast/pull/345
Control: tags -1 + patch fixed-upstream

On Thu, 20 Jul 2023 at 23:27:25 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

According to upstream it seems that only metadata changes were needed.

smcv

Bug#1041571: gnome-shell-extension-flypie: needs update for GNOME Shell 44

[Simon McVittie]

Control: tags -1 + fixed-upstream patch

On Thu, 20 Jul 2023 at 23:28:09 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

Upstream version 21 already declares compatibility with GNOME Shell 44 in
metadata.json, so unless you know otherwise, the required change should
be as simple as this edit to debian/control:

-Depends: gnome-shell (<< 44~), gnome-shell (>= 3.36~), ${misc:Depends}
+Depends: gnome-shell (<< 45~), gnome-shell (>= 3.36~), ${misc:Depends}

Please remember to check metadata.json when importing new upstream releases.

Thanks,
smcv

Bug#1041572: gnome-shell-extension-freon: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 
https://github.com/UshakovVasilii/gnome-shell-extension-freon/pull/257
Control: tags -1 + patch fixed-upstream

On Thu, 20 Jul 2023 at 23:28:26 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

According to the upstream issue tracker, only metadata changes are needed.

smcv

Bug#1041573: gnome-shell-extension-gamemode: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 https://github.com/gicmo/gamemode-extension/pull/65
Control: tags -1 + patch fixed-upstream

On Thu, 20 Jul 2023 at 23:28:48 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

>From upstream it appears that only metadata changes are needed for GNOME
Shell 44.

Please set the dependency version to gnome-shell (<< 45~) to make sure this
extension is not falsely advertised as compatible with Shell 45, even if
metadata.json says it's compatible: according to comments on the
upstream PR, 45 was added to metadata.json wrongly, and according to
https://github.com/gicmo/gamemode-extension/issues/70 code changes will
be required for Shell 45.

smcv

Bug#1041574: gnome-shell-extension-hamster: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 
https://github.com/projecthamster/hamster-shell-extension/pull/357
Control: tags -1 + patch fixed-upstream

On Thu, 20 Jul 2023 at 23:29:30 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

>From upstream it appears that only metadata changes are needed.

smcv

Bug#1041575: gnome-shell-extension-impatience: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 
https://github.com/timbertson/gnome-shell-impatience/pull/31
Control: tags -1 + patch fixed-upstream

On Sun, 20 Aug 2023 at 23:54:13 +0100, Simon McVittie wrote:
> On Thu, 20 Jul 2023 at 23:29:56 +0100, Simon McVittie wrote:
> > This extension has not been checked for compatibility with GNOME Shell
> > 44. Depending how compatible it is, it will either need an update to
> > its metadata.json and debian/control to declare compatibility with the
> > new version, or code changes to adapt it to the new Shell version.

>From upstream it appears that only metadata changes are needed.

smcv

Bug#1041579: gnome-shell-extension-system-monitor: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 
https://github.com/paradoxxxzero/gnome-shell-system-monitor-applet/pull/788
Control: tags -1 + upstream patch

On Thu, 20 Jul 2023 at 23:35:29 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

>From upstream it appears that only a metadata update is needed.

smcv

Bug#1041580: gnome-shell-extension-tiling-assistant: needs update for GNOME Shell 44

[Simon McVittie]

On Mon, 21 Aug 2023 at 00:24:01 +0100, Simon McVittie wrote:
> On Thu, 20 Jul 2023 at 23:38:49 +0100, Simon McVittie wrote:
> > The version of gnome-shell-extension-tiling-assistant in unstable is
> > not marked as compatible with GNOME Shell 44, but the version in
> > experimental is.
> 
> I've just uploaded gnome-shell 44 to unstable. Please upload the
> experimental version of this extension to unstable whenever is convenient,
> and close this bug in that upload.

Alternatively, upstream version 41 seems to be "officially" compatible
with Shell 44 without needing downstream patches.

smcv

Bug#1041582: gnome-shell-extension-vertical-overview: needs update for GNOME Shell 44

[Simon McVittie]

Control: forwarded -1 
https://github.com/RensAlthuis/vertical-overview/issues/122
Control: tags -1 + upstream patch

On Thu, 20 Jul 2023 at 23:39:33 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

It appears that code changes are required. A merge request has been proposed
upstream <https://github.com/RensAlthuis/vertical-overview/pull/124> but has
not yet been reviewed or merged.

(I have not checked that change for correctness: I don't use this
extension myself.)

smcv

Bug#1050150: gnome-shell-extension-gsconnect: new upstream version 55

[Simon McVittie]

Source: gnome-shell-extension-gsconnect
Version: 54-2
Severity: wishlist
Tags: trixie sid

I've just uploaded mutter version 44 to experimental, starting transition
#1043144. This means gnome-shell-extension-gsconnect 55 (in experimental)
can now be uploaded to unstable; please close this bug with that upload.

Thanks,
smcv

Bug#1050149: budgie-desktop: Please upload a version compatible with mutter 44 to unstable

[Simon McVittie]

Source: budgie-desktop
Version: 10.7.1-1
Severity: serious
Tags: trixie sid
Justification: transition #1043144

I've just uploaded mutter version 44 to experimental, starting transition
#1043144. Please upload a compatible version of budgie-desktop to
unstable, and close this bug with that upload. The newer upstream version
currently in experimental seems suitable.

Thanks,
smcv

Bug#1041580: gnome-shell-extension-tiling-assistant: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:38:49 +0100, Simon McVittie wrote:
> The version of gnome-shell-extension-tiling-assistant in unstable is
> not marked as compatible with GNOME Shell 44, but the version in
> experimental is.

I've just uploaded gnome-shell 44 to unstable. Please upload the
experimental version of this extension to unstable whenever is convenient,
and close this bug in that upload.

Thanks,
smcv

Bug#1041582: gnome-shell-extension-vertical-overview: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:39:33 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1038412: gnome-shell-extension-weather: Update to 121 to support GNOME 44

[Simon McVittie]

Control: severity -1 serious

On Sat, 17 Jun 2023 at 23:06:51 +0200, Amr Ibrahim wrote:
> Please update to 121 to support GNOME 44.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041577: gnome-shell-extension-panel-osd: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:34:18 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041575: gnome-shell-extension-impatience: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:29:56 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041574: gnome-shell-extension-hamster: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:29:30 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041572: gnome-shell-extension-freon: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:26 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041573: gnome-shell-extension-gamemode: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:48 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041571: gnome-shell-extension-flypie: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:28:09 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041569: gnome-shell-extension-easyscreencast: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious

On Thu, 20 Jul 2023 at 23:27:25 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1033100: Update gnome-shell-extension-dashtodock to 84 to support GNOME 44

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + pending

On Thu, 22 Jun 2023 at 17:37:21 +, Amr Ibrahim wrote:
> Please update to 84 to support gnome-shell 44.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when ready (it seems to be staged
in the git repository but not yet uploaded).

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

Thanks,
smcv

Bug#1041567: gnome-shell-extension-arc-menu: needs update for GNOME Shell 44

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + fixed-upstream

On Thu, 20 Jul 2023 at 23:24:52 +0100, Simon McVittie wrote:
> This extension has not been checked for compatibility with GNOME Shell
> 44. Depending how compatible it is, it will either need an update to
> its metadata.json and debian/control to declare compatibility with the
> new version, or code changes to adapt it to the new Shell version.

I'm about to upload GNOME Shell 44 to unstable, making this RC. Please
upload a compatible version to unstable when available.

If this has not happened by the time the GNOME Shell 44 transition
is otherwise ready to go through, then this extension will be removed
from testing.

On Sun, 30 Jul 2023 at 10:50:39 +0300, Jeremy Bícha wrote:
> It looks like the new upstream repo for this extension is
> https://gitlab.com/arcmenu/ArcMenu

The latest version in that repository seems to declare compatibility
with Shell 44. It appears that code changes were required.

smcv

Bug#1043144: transition: mutter/gnome-shell 44

[Simon McVittie]

On Sun, 20 Aug 2023 at 19:52:50 +, Graham Inggs wrote:
> I added your combined ben file to the tracker with some minor changes:
> https://release.debian.org/transitions/html/gnome-shell-44.html

Thanks!

> Please go ahead.

Initial round of builds in progress.

smcv

Bug#1050124: bookworm-pu: package vte2.91/0.70.6-2~deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: vte2...@packages.debian.org
Control: affects -1 + src:vte2.91

I've uploaded another proposed vte2.91 update for bookworm. Please consider
this for 12.2.

[ Reason ]
#1040049

[ Impact ]
If not fixed, there is a crash with an assertion failure that occurs
frequently in some user workflows (I've never been able to reproduce it
myself, but the bug reporter Luca Boccassi saw it frequently).

[ Tests ]
Luca has been running a prerelease version of this update (identical except
for version number) for several weeks, and has not seen the bug again.
Available from: https://people.debian.org/~smcv/12.2/pool/main/v/vte2.91/

A functionally equivalent version was in testing for about 1 week before
being superseded by a newer upstream release, with no regression reports.
The version proposed here is a straightforward rebuild of that version
for bookworm.

[ Risks ]
Low risk: targeted fix from upstream which just invalidates caches more
often.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
All changes are for #1040049, no extraneous diff present.
diffstat for vte2.91-0.70.6 vte2.91-0.70.6

 debian/changelog  |   17 ++
 debian/patches/series |1 
 debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch |   69 
++
 src/vte.cc|   13 +
 4 files changed, 100 insertions(+)

diff -Nru vte2.91-0.70.6/debian/changelog vte2.91-0.70.6/debian/changelog
--- vte2.91-0.70.6/debian/changelog 2023-06-14 12:17:06.0 +0100
+++ vte2.91-0.70.6/debian/changelog 2023-08-09 13:01:27.0 +0100
@@ -1,3 +1,20 @@
+vte2.91 (0.70.6-2~deb12u1) bookworm; urgency=medium
+
+  * Team upload
+  * Rebuild for bookworm (Closes: #1040049)
+
+ -- Simon McVittie   Wed, 09 Aug 2023 13:01:27 +0100
+
+vte2.91 (0.70.6-2) unstable; urgency=medium
+
+  * Team upload
+  * d/p/widget-Invalidate-ringview-when-the-invalidating.patch:
+Add patch from upstream git to invalidate ring view more often when
+necessary, fixing various assertion failures during event handling
+(Closes: #1040049)
+
+ -- Simon McVittie   Fri, 14 Jul 2023 11:31:40 +0100
+
 vte2.91 (0.70.6-1~deb12u1) bookworm; urgency=medium
 
   * Team upload
diff -Nru vte2.91-0.70.6/debian/patches/series 
vte2.91-0.70.6/debian/patches/series
--- vte2.91-0.70.6/debian/patches/series2023-06-14 12:17:06.0 
+0100
+++ vte2.91-0.70.6/debian/patches/series2023-08-09 13:01:27.0 
+0100
@@ -1 +1,2 @@
+widget-Invalidate-ringview-when-the-invalidating.patch
 Allow-background-color-and-color-on-VteTerminal-widgets-t.patch
diff -Nru 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
--- 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
1970-01-01 01:00:00.0 +0100
+++ 
vte2.91-0.70.6/debian/patches/widget-Invalidate-ringview-when-the-invalidating.patch
2023-08-09 13:01:27.0 +0100
@@ -0,0 +1,69 @@
+From: Egmont Koblinger 
+Date: Thu, 13 Jul 2023 21:59:29 +0200
+Subject: widget: Invalidate ringview when the invalidating
+
+When the ringview is not invalidated when the ring has changed leads to
+failed assertion aborts when handling events, e.g. vte#2636, vte#2637,
+vte#2632, vte#2577.
+
+Bug: https://gitlab.gnome.org/GNOME/vte/-/issues/2636
+Bug: https://gitlab.gnome.org/GNOME/vte/-/issues/2637
+Bug-Debian: https://bugs.debian.org/1040049
+Applied-upstream: 0.73.0, commit:461bc3e43c819fa0e3b62d0cf40ef533a69cc7f7
+---
+ src/vte.cc | 13 +
+ 1 file changed, 13 insertions(+)
+
+diff --git a/src/vte.cc b/src/vte.cc
+index b8e15d7..561cc42 100644
+--- a/src/vte.cc
 b/src/vte.cc
+@@ -2050,6 +2050,7 @@ Terminal::queue_adjustment_value_changed(double v)
+ _vte_debug_print(VTE_DEBUG_ADJ,
+  "Scrolling by %f\n", dy);
+ 
++m_ringview.invalidate();
+ invalidate_all();
+ match_contents_clear();
+ emit_text_scrolled(dy);
+@@ -2899,6 +2900,9 @@ Terminal::drop_scrollback()
+ if (m_screen == _normal_screen) {
+ queue_adjustment_value_changed(m_normal_screen.insert_delta);
+ adjust_adjustments_full();
++m_ringview.invalidate();
++invalidate_all();
++match_contents_clear();
+ }
+ }
+ 
+@@ -7548,6 +7552,9 @@ Terminal::set_size(long columns,
+   gtk_widget_queue_resize(m_widget); // FIXMEgtk4

Bug#1034356: gnome-shell: Frozen UI and massive log flodding

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 17 Aug 2023 at 09:58:42 +0100, Simon McVittie wrote:
> The key change in gjs seems to be the second commit of
> <https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/832> so I'll try to
> build a package with that change for testing.

Please could you try installing the libgjs0g from here:
<https://people.debian.org/~smcv/12.2/pool/main/g/gjs/>
and then do whatever is necessary to reproduce the issue?

The result I'm hoping for from that change is that you will still get
a message like

> Apr 13 14:50:39 schroeder gnome-shell[6317]: Attempting to call back into 
> JSAPI during the sweeping phase of GC. This is most likely caused by not 
> destroying a Clutter actor or Gtk+ widget with ::destroy signals connected, 
> but can also be caused by using the destroy(), dispose(), or remove() vfuncs. 
> Because it would crash the application, it has been blocked and the JS 
> callback not invoked.

but only once (or a small number of times), and the log flooding /
infinite loop will not occur.

If that change is tested successfully then it can be included in a
Debian 12 stable update.

smcv

Bug#1041810: librsvg: CVE-2023-38633

[Simon McVittie]

On Sat, 19 Aug 2023 at 18:57:29 +0200, Salvatore Bonaccorso wrote:
> If you are happy with the results and coverage from unstable, would
> you be open to prepare/finalize next the respective updates for
> bookworm-security and bullseye-security?

I already had them in what I believe to be an uploadable state, so I've
uploaded them to security-master. Please do whatever testing you feel is
appropriate and approve or reject.

librsvg_2.54.7+dfsg-1~deb12u1 is a trivial backport of what's in unstable,
<https://salsa.debian.org/gnome-team/librsvg/-/merge_requests/19>
(diff vs. unstable below, debdiff vs. bookworm attached). I've been
using it on a bookworm GNOME desktop for the last few weeks with no
apparent regressions, and I haven't seen any regression reports from
testing/unstable users either.

librsvg_2.50.3+dfsg-1+deb11u1 is
<https://salsa.debian.org/gnome-team/librsvg/-/merge_requests/20>
(debdiff vs. bullseye attached). I don't have bullseye on actual hardware
any more, so this has only been tested on a GNOME VM.

smcv



diff --git a/debian/changelog b/debian/changelog
index d58c430b1..825f50e1e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+librsvg (2.54.7+dfsg-1~deb12u1) bookworm-security; urgency=medium
+
+  * Team upload
+  * Rebuild for bookworm-security
+
+ -- Simon McVittie   Sun, 30 Jul 2023 17:13:13 +0100
+
 librsvg (2.54.7+dfsg-1) unstable; urgency=high
 
   * Team upload
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 4ed071a96..098b7f22b 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,7 +1,7 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/master
-upstream-branch = upstream/latest
+debian-branch = debian/bookworm
+upstream-branch = upstream/2.54.x
 
 [buildpackage]
 sign-tags = True


librsvg_2.50.3+dfsg-1+deb11u1.debdiff.gz
Description: application/gzip


librsvg_2.54.7+dfsg-1~deb12u1.debdiff.gz
Description: application/gzip

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

[Simon McVittie]

On Wed, 24 Feb 2021 at 00:47:46 +, Simon McVittie wrote:
> On Sun, 05 Mar 2017 at 19:23:40 +0000, Simon McVittie wrote:
> > [the change proposed here] 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

2½ years later, updating a debootstrap merge request reminded me that this
is unresolved. I see schroot now has a new maintainer and a new upstream:
please consider applying the patch proposed here to set up a working
/dev/ptmx and /dev/console in more situations.

I don't currently have a codeberg account set up, so I haven't proposed
this at the new upstream yet. I'll try to do that and mark this bug as
forwarded.

Thanks,
smcv

Bug#1050077: gtk4: 4.12 regression: FTBFS on mips(64)el: multiple test failures

[Simon McVittie]

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mips64el mipsel

gtk4 4.12.0 in experimental has test failures on multiple buildds.
Of those, mips64el and mipsel seem to have the same failure mode:
failure mode:

  72/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
border-one-rounded flipped   FAIL   
  5.47s   exit status 1
 315/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl / gl opacity-overdraw   
 FAIL   
  4.89s   exit status 1
 316/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-flipped-gl / gl 
opacity-overdraw flipped FAIL   
  4.94s   exit status 1
 317/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-repeated-gl / 
gl opacity-overdraw repeated   FAIL 
5.05s   exit status 1
 318/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-rotated-gl / gl 
opacity-overdraw rotated FAIL   
  4.95s   exit status 1
 319/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+gsk-compare-masked-gl / gl 
opacity-overdraw masked   FAIL  
   5.02s   exit status 1
1406/1464 gtk:reftest / reftest label-sizing.ui 
 FAIL   
 19.29s   0/1 subtests passed
1422/1464 gtk:reftest / reftest opacity.ui  
 FAIL   
  6.79s   0/1 subtests passed

These are "reftests", which work by rendering the same image in two
different ways and then doing a pixel-by-pixel comparison. Because
Debian buildds do not give us a way to capture test artifacts, the images
are output into the log with uuencode, for example these:

begin-base64 644 testsuite/gsk/compare/opacity-overdraw.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iRklEQVRIie3WMQ4AIAxCUWo8uDev
B7BjYwc+I8tLmAgpjwayJlDgr9lVmYpWJJRP5zc1MDAwMDAwsDFcfq7qI3XHb2o/+AJ0lQS/vZJx
GQBJRU5ErkJggg==


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.out.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iS0lEQVRIie3WMQ4AIAhD0aIe3Isb
vACDA5GB35HlJWWpSb5VkFGBAn/Nio5HlopM+Rv8o4Z+PwYGBgYGBgauh8PpY8FGyk6/qvvBF6Er
BMOKG8HLAElFTkSuQmCC


begin-base64 644 
debian/build/deb/testsuite/gsk/compare/gl/x11/opacity-overdraw.diff.png
iVBORw0KGgoNSUhEUgAAAB4eCAY7MK6iKklEQVRIie3NoQEAIAzEwGdvZPeG
BUBR3J2MSQKfjFOsZHVO5uUDAAC82WlIAgJv9eZaAElFTkSuQmCC


The way these work is that they are output in sets of three: a reference
image, an actual output, and an artifically-enhanced diff image to
highlight what the difference is. See #1024391, #993550, #1003348 for
previous examples of architecture-specific rendering differences (#1024391
was not on mips*, but has details of how to run individual tests which
might be useful, while the other two were on mips*el).

I haven't reconstructed the actual images for a visual comparison yet.
If the mis-rendering doesn't seem release-critically bad then we'll work
around this by ignoring those particular test failures on mips*el.

mips*el are the only architectures where we are using the softpipe GL
driver (because llvmpipe appears to be otherwise broken there) so that is a
possible root cause.

Having to investigate and work around failing tests in GL-dependent
packages on mips*el is becoming a significant time sink for the GNOME team,
so I would appreciate it if mips porters could fix its llvmpipe so that it
can be back in the same situation as every other release architecture.

smcv

Bug#1043147: [Pkg-sssd-devel] Bug#1043147: Bug#1043147: ding-libs: please consider upgrading to 3.0 source format

[Simon Josefsson]

Hi.  I have uploaded a fixed ding-libs to DELAYED/5 now, see attached
for easy review.

/Simon
diff -Nru ding-libs-0.6.2/debian/changelog ding-libs-0.6.2/debian/changelog
--- ding-libs-0.6.2/debian/changelog	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/changelog	2023-08-19 13:12:21.0 +0200
@@ -1,3 +1,30 @@
+ding-libs (0.6.2-2) unstable; urgency=medium
+
+  [ Simon Josefsson ]
+  * control: Add myself as Uploaders.
+  * control: Use new pkg-sssd email address.
+  * copyright: Add myself for debian/*, silencing lintian warning update-
+debian-copyright.
+  * Add Rules-Requires-Root: no.
+  * Standards-Version 4.6.2.
+  * Build with hardening=+all.
+  * Drop '--with quilt'.  Remove placeholder series.
+  * Update watch (thanks Oneric!) and add debian/upstream/signing-key.asc.
+  * source/options: Add extend-diff-ignore.
+  * Add Build-Depends-Package to *.symbols.
+  * copyright: Drop obsolete build/ltmain.sh.
+
+  [ Debian Janitor ]
+  * Use secure copyright file specification URI.
+  * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse.
+  * Update standards version to 4.6.1, no changes needed.
+  * Apply multi-arch hints.
+
+  [ Timo Aaltonen ]
+  * source: Migrate to format 3.0 (quilt). (Closes: #1043147)
+
+ -- Simon Josefsson   Sat, 19 Aug 2023 13:12:21 +0200
+
 ding-libs (0.6.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru ding-libs-0.6.2/debian/control ding-libs-0.6.2/debian/control
--- ding-libs-0.6.2/debian/control	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/control	2023-08-08 14:52:15.0 +0200
@@ -1,22 +1,25 @@
 Source: ding-libs
 Section: libs
 Priority: optional
-Maintainer: Debian SSSD Team 
-Uploaders: Timo Aaltonen 
+Maintainer: Debian SSSD Team 
+Uploaders: Timo Aaltonen ,
+   Simon Josefsson 
 Build-Depends: debhelper-compat (= 13),
  quilt,
  check,
  pkg-config,
-Standards-Version: 4.6.0
+Standards-Version: 4.6.2
 Homepage: https://github.com/SSSD/ding-libs
 Vcs-Git: https://salsa.debian.org/sssd-team/ding-libs.git
 Vcs-Browser: https://salsa.debian.org/sssd-team/ding-libs
+Rules-Requires-Root: no
 
 Package: libpath-utils-dev
 Section: libdevel
 Architecture: any
 Depends: ${misc:Depends},
  libpath-utils1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libpath_utils
  Utility functions to manipulate filesystem pathnames. Development files.
  .
@@ -39,6 +42,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libdhash1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libdhash
  A hash table which will dynamically resize to achieve optimal storage & access
  time properties. Development files.
@@ -63,6 +67,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libcollection4 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for libcollection
  A data-type to collect data in a hierarchical structure for easy iteration
  and serialization. Development files.
@@ -87,6 +92,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libref-array1 (= ${binary:Version}),
+Multi-Arch: same
 Description: Development files for refcounted array for C
  A dynamically-growing, reference-counted array. Development files.
  .
@@ -136,6 +142,7 @@
 Architecture: any
 Depends: ${misc:Depends},
  libbasicobjects0 (= ${binary:Version}),
+Multi-Arch: same
 Description: Basic object types for C -- development files
  Library that add basic object types for C. Development files.
  .
diff -Nru ding-libs-0.6.2/debian/copyright ding-libs-0.6.2/debian/copyright
--- ding-libs-0.6.2/debian/copyright	2023-08-19 13:24:21.0 +0200
+++ ding-libs-0.6.2/debian/copyright	2023-08-19 13:07:29.0 +0200
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: ding-libs
 Source: https://github.com/SSSD/ding-libs
 
@@ -10,10 +10,6 @@
 Copyright: 2009-2010 Dmitri Pal 
 License: GPL-3+
 
-Files: build/ltmain.sh
-Copyright: 1996 Gordon Matzigkeit 
-License: GPL-2+
-
 Files: dhash/* path_utils/*
 Copyright: 2009 Red Hat
 License: LGPL-3+
@@ -30,30 +26,9 @@
 Copyright: 2011 Fabrice Coutadeur ,
2011 Jonathan Carter ,
2011 Timo Aaltonen 
+	   2023 Simon Josefsson 
 License: GPL-3+
 
-License: GPL-2+
- This program is free software; you can redistribute it
- and/or modify it under the terms of the GNU General Public
- License as published by the Free Software Foundation; either
- version 2 of the License, or (at your option) any later
- version.
- .
- This program is distributed in the hope that it will be
- useful, but WITHOUT ANY WARRANTY; without even the implied
- warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
- PURPOSE.  See the GNU General Public License for more
- details.
- .
- You should have received a copy of the GNU General Public
- License along with this package; if not, w

Bug#1050076: gtk4: 4.12 regression: FTBFS on i386: assertion failed (r == tests[i].r (+/- FLT_EPSILON))

[Simon McVittie]

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Usertags: i387

gtk4 4.12.0 in experimental has test failures on multiple buildds.
On i386 there is this failure:

not ok /color/roundtrips - 
ERROR:../../../testsuite/gtk/colorutils.c:43:test_roundtrips: assertion failed 
(r == tests[i].r (+/- FLT_EPSILON)): (1.1920929e-07 == 0)

I think this is our old enemy, the legacy i387 FPU and its 80-bit
extended precision, and the test will need to apply more fuzz to its
acceptable result.

If our i386 port had a baseline that included SSE2 so that we could
build everything with -mfpmath=sse, this class of bug would probably
go away; but at the moment our baseline is officially a not-quite-i686
(i686 with one missing opcode, to accommodate certain Geode CPUs) so
we cannot assume MMX, SSE or SSE2, and various developers have resisted
suggestions to raise the baseline. I'm going to start tracking bugs in
this class with a usertag to get an idea of how many of them there are.

smcv

Bug#1050075: gtk4: 4.12 regression: FTBFS on arm*|ppc64el|s390x: several checkerboard tests failing

[Simon McVittie]

Source: gtk4
Version: 4.12.0+ds-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

gtk4 4.12.0 in experimental has test failures on multiple buildds.
Of those, arm64, armel, armhf, ppc64el and s390x all seem to have the same
failure mode:

  36/1464 gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+wayland_gles_failing / gl 
big-checkerboard-scaled-down2  FAIL 
   3.48s   exit status 1
  37/1464 
gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+wayland_gles_failing+gsk-compare-flipped-gl
 / gl big-checkerboard-scaled-down2 flipped   FAIL3.50s 
  exit status 1
  38/1464 
gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+wayland_gles_failing+gsk-compare-repeated-gl
 / gl big-checkerboard-scaled-down2 repeated FAIL3.78s  
 exit status 1
  39/1464 
gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+wayland_gles_failing+gsk-compare-rotated-gl
 / gl big-checkerboard-scaled-down2 rotated   FAIL3.62s 
  exit status 1
  42/1464 
gtk:gsk+gsk-compare+gsk-gl+gsk-compare-gl+wayland_gles_failing+gsk-compare-masked-gl
 / gl big-checkerboard-scaled-down2 masked FAIL
4.00s   exit status 1

I'm unsure why we are running tests that appear to be flagged as "failing".
Perhaps it just needs some --no-suite=failing added?

Test failures on i386 and mips64el are out of scope for this bug report.

smcv

Bug#1050025: mutter: non-upstreamed workaround for serial mismatch in Wayland drag-and-drop

[Simon McVittie]

On Fri, 18 Aug 2023 at 10:18:29 -0400, Jeremy Bícha wrote:
> I figure we can keep the patch for Debian 12 since it's there and not
> causing problems, but we can drop it for Ubuntu 23.10 and Debian
> Trixie.

Right, that's what I was thinking. Let's plan to drop this after the
mutter 44 transition has gone through, as I suggested for some other
non-upstreamed workarounds around the same time.

smcv

Bug#1050001: Unwinding directory aliasing

[Simon McVittie]

On Fri, 18 Aug 2023 at 07:57:14 +0100, Ian Jackson wrote:
> I think we can probably fix it by backing out this change, and then
> doing usrmerge the traditional Debian way by making changes to
> debhelper, so that we move the files package by package, in the .debs.

What do you consider to be the end goal of this proposal?

If I understand your proposal correctly, it is to return all Debian
systems to their traditional (let's say circa 2010) layout, and then
restart the transition differently. Imagine for a moment that the
usrmerge package, debootstrap --merged-usr, etc. had never existed,
and all Debian systems were in their 2010 state (or equivalently, that
your proposed revert has happened and we are now ready for the second
stage of your plan).

If we carry out this transition package-by-package without central
coordination ("the traditional Debian way"), it seems to me that the
best we can achieve is for /bin, /sbin, /lib* to be symlink farms,
consisting of symlinks that are either owned by the same package that
owns the symlink target, or are unowned from dpkg's perspective and are
created by maintainer scripts.

Here's a simplified view of the resulting system:

/bin/sh -> /usr/bin/sh
/bin/rm -> /usr/bin/rm
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Obviously in real life, /bin and /usr/bin are a lot larger than that,
and /sbin and /lib* are also necessary for a bootable system, but
considering a small number of /{usr/,}bin files is enough to illustrate
my point.)

This does some but not all of what merged-/usr does: calling /usr/bin/sh
would become a non-bug, but calling /bin/env would still be an error,
/bin would still represent non-trivial on-disk and/or in-dpkg-database
state, and we would still potentially have other issues triggered by
the directories being distinct from one another (like the one discussed
by the tech committee in #911225, which was exactly a regression caused
by having moved a library in the traditional Debian way).

The merged-/usr version of that same simplified system is this:

/bin -> usr/bin
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Again, in real life we also have to consider /sbin and /lib*, but
showing /bin is enough to illustrate the difference.)

As was discussed in 2019 and repeatedly since then, some of the reasons
to want merged-/usr are only available with that layout, and are not
provided by the symlink farm.

If I remember correctly, openSUSE tried to get from unmerged /usr to
merged /usr by essentially the route you propose, successfully reached
the symlink-farm state, but then got stuck without a way to get from the
symlink farm to the single symbolic link. Do you have a plan for how that
would be achieved without breaking upgrades or going behind dpkg's back?

If your plan was a longer, slower, arguably more robust way to achieve
the same end goal, that would be more appealing than a longer, slower,
arguably more robust way to get halfway to the same end goal and then
become unable to go further.

smcv