MBF: adding portals.conf(5) to desktop environments

[Simon McVittie]

xdg-desktop-portal is a D-Bus service providing access to
desktop-environment-related functionality for applications. It was
originally written to provide sandboxed apps (Flatpak, Snap, etc.) with
limited access to resources outside their sandbox with user consent, but
is increasingly also used by non-sandboxed apps (.deb or equivalent) as a
desktop-environment-independent interface to features like screen-sharing
that are otherwise difficult to implement in a cross-desktop way.

xdg-desktop-portal itself does not contain any
desktop-environment-specific code, and is shared between
all desktop environments. However, a lot of what it does requires use of
desktop-environment-specific mechanisms or user interface conventions.
To allow for that, it contacts a desktop-specific backend (x-d-p-gtk,
x-d-p-gnome, x-d-p-kde and so on) and uses that to provide its full
functionality.

In Debian 12, if xdg-desktop-portal does not find a suitable backend
for the current desktop environment, it would fall back to trying *any*
backend. This meant that all backends needed to be prepared to run in an
environment where their functionality cannot actually work, which is
rarely tested, leading to undesired situations where a desktop
environment's backend can cause bugs (such as crashes or slow application
startup) while running different desktop environments.

xdg-desktop-portal 1.17.x is now available in experimental, and this version
contains upstream changes so that desktop environments can have more control
over the backends they use. As described in
,
the recommendation is now that each desktop environment should provide
a file listing its preferred backends, similar to the one added by

in GNOME.

In a future version of xdg-desktop-portal, installing a portals.conf(5)
file is likely to become a requirement for desktop environments that
want to have working portal interfaces. For the moment, there is some
backwards-compatibility to keep existing desktop environments mostly
working (see below).

I'm intending to re-upload x-d-p 1.17.x to unstable soon.

Packages affected
=

Any package that registers itself as an X11 or Wayland desktop session
(/usr/share/xsessions/*.desktop, /usr/share/wayland-sessions/*.desktop)
is potentially affected. I attach a dd-list of packages that register
these files (excluding gnome-session, which I already changed).

As a lower priority, any other session manager, window manager or
other desktop-environment-like thing that sets the XDG_CURRENT_DESKTOP
environment variable could also participate in this mechanism. I don't
intend to mass-file bugs for these in any systematic way.

I intend to prioritize opening bugs for the major desktop environments that
have a task-foo-desktop metapackage: cinnamon, gnome-flashback, kde, lxde,
lxqt, mate, xfce. For task-gnome-desktop, I already uploaded gnome-session
44.0-3 with

included in it - that's an example of the sort of changes that are needed.

Action to be taken
==

If the desktop environment is independent of any others, with no ":"
in $XDG_CURRENT_DESKTOP (like GNOME, KDE Plasma, Cinnamon) then it should:

- take the single string that it uses in XDG_CURRENT_DESKTOP
  (GNOME, KDE, X-Cinnamon)
- fold it to lower case (gnome, kde, x-cinnamon)
- install /usr/share/xdg-desktop-portal/${desktop}-portals.conf in either
  the package that provides the desktop session or one of its dependencies
- in that file, describe the portal backends that xdg-desktop-portal users
  should normally be using while logged in to this desktop environment

If the desktop environment behaves like a variant of another desktop
environment and sets XDG_CURRENT_DESKTOP to a ":"-separated sequence of
decreasingly specific names (like Budgie, which sets XDG_CURRENT_DESKTOP
to "Budgie:GNOME") then it has two choices:

1. Behave like an independent desktop environment by installing its own
   ${desktop}-portals.conf, for example Budgie could install
   budgie-portals.conf
2. Behave like its parent desktop environment and accept the parent desktop
   environment's choice of backends, for example Budgie could rely on
   GNOME's gnome-portals.conf

The correct choice depends on how similar the desktop environment is to
its parent. I suspect that GNOME Classic (in the gnome-shell-extensions
package) is similar enough to the default GNOME environment that it
can safely rely on gnome-portals.conf, but Budgie and GNOME Flashback
are sufficiently different that they will probably need their own
desktop-specific *-portals.conf.

A desktop-specific *-portals.conf can either be provided by the upstream
project or by the Debian maintainer. It will usually be appropriate to
try to send this change upstream.

For des

Bug#1050810: ITP: asahi-scripts -- Asahi Linux maintenance scripts

[Tobias Heider]

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

* Package name: asahi-scripts
  Version : 20230821
  Upstream Authors: The Asahi Linux project
  URL : https://github.com/AsahiLinux/asahi-scripts
* License : MIT
  Description : Asahi Linux maintenance scripts
 This package contains miscellaneous admin scripts from the Asahi Linux
 reference distro.

Package will be maintained within the Debian Bananas Apple M1 team.

Re: MBF: adding portals.conf(5) to desktop environments

[Simon McVittie]

On Tue, 29 Aug 2023 at 11:11:29 +0100, Simon McVittie wrote:
> I intend to prioritize opening bugs for the major desktop environments that
> have a task-foo-desktop metapackage: cinnamon, gnome-flashback, kde, lxde,
> lxqt, mate, xfce.

Opened and usertagged:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=xdg-desktop-portal%40packages.debian.org&tag=portals.conf

When I get round to completing the mass-bug-filing for packages that
ship an X/Wayland session description but are not on that shortlist,
they will be usertagged similarly.

> Debian Qt/KDE Maintainers 
>plasma-bigscreen
...
> DebianOnMobile Maintainers 
> 
>plasma-mobile

These two seem to depend on plasma-workspace and share its
XDG_CURRENT_DESKTOP=KDE, so solving #1050798 should be enough for all
Plasma variants, and I don't intend to open separate bugs for -bigscreen
and -mobile.

smcv

Bug#1050815: snapshot.d.o has been in a bad state for several months

[Holger Levsen]

package: snapshot.debian.org
severity: important
x-debbugs-cc: debian-devel@lists.debian.org, 
reproducible-bui...@lists.alioth.debian.org

Hi,

filing this as a bug report, again, because the problem has become worse
than when #1031628 was filed and since snapshot.d.o is part of the central 
services Debian provides and it should work better than it does right now.
else, why do we operate it? ;)

On Wed, Aug 02, 2023 at 01:33:11PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> snapshot.debian.org is getting worse again. There is not a single snapshot for
> August yet and the last days of July are spotty:
> 
> http://snapshot.debian.org/archive/debian/?year=2023&month=7
> 
> None for the 29. and only a single timestamp for the 26., 27., 28. and 30.
> There should be four per day. The situation is even worse for other archives.
> For debian-ports, for the month of July, there are only 22 snapshots overall:
> 
> http://snapshot.debian.org/archive/debian-ports/?year=2023&month=7
> 
> This problem has been known for half a year already:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031628
> 
> But that bug got closed in favor of #1029744 which was filed because
> debian-ports had no snapshots at all for January and only three for February
> this year but there is no reply to that bug.
> 
> In #1031628 Julien said that there is "not much we can do about it at the
> moment".
> 
> What is the status of this problem? What is needed to fix it? Is this just a
> problem of computational and/or storage resources which an be fixed by the
> funds available to Debian?
> 
> I'd argue that snapshot.d.o is part of the central services Debian provides 
> and
> it should work better than it does right now.

On https://snapshot.debian.org/archive/debian-ports/?year=2023&month=8 I count
31 snapshot for those 29 days of August so far, with no snapshots so far for
2023-08-01, 2023-08-08, 2023-08-17 and 2023-08-29.

But it get's worse:

On Wed, Aug 09, 2023 at 11:34:56AM -0400, Theodore Ts'o wrote:
> BTW, it also looks like not only are some snapshots not being taken,
> some of the snapshots are missing packages.   For example:
> 
>https://snapshot.debian.org/archive/debian/20230806T091912Z/
> 
> is missing the package libc-dev-bin, and:
> 
>https://snapshot.debian.org/archive/debian/20230807T150823Z/
> 
> is missing the package dbus.  Which is something that I'm finding when
> I try building an kvm-xfstests VM using:
> 
> https://github.com/tytso/xfstests-bld/blob/master/test-appliance/gen-image
> 
> Ah, well, I guess I'll try the snapshot for 20230805T151946Z next


Please don't just close this bug report as it was done with #1031628,
it's useful to be able to track this, point out that this problem
has been existed since some time and have a place to discussion
workarounds.

Also, how can one start helping with this issue (or others)? where does 
the snapshot team communicate?

https://salsa.debian.org/snapshot-team/snapshot/-/commits/master has
not seen any commit since 7 months.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Alles weird gut.


signature.asc
Description: PGP signature

DEP-5 copyright with different licenses for two parts of the same file

[Marc Haber]

Hi,

in daemon(1), I have a file with has two contradicting licenses in the
same file. See
https://salsa.debian.org/debian/daemon/-/blob/master/libslack/getopt.c

>From the wording of the second copyright notice, I think it is clear
that that notice applies to the POD documentation included in the file
while the actual code is LGPL. Upstream confirms that this is the
intention and agrees that this is somehow suboptimally worded.

Now, how do I write this in a DEP-5 copyright file? Having two stanzas
for the same file gets flagged by Lintian as an Error, and the DEP-5
syntax doesn't seem to allow to mention two Licenses in the License:
line.

Any hints woule be appreciated.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: DEP-5 copyright with different licenses for two parts of the same file

[Russ Allbery]

Marc Haber  writes:

> Now, how do I write this in a DEP-5 copyright file? Having two stanzas
> for the same file gets flagged by Lintian as an Error, and the DEP-5
> syntax doesn't seem to allow to mention two Licenses in the License:
> line.

This is the intended purpose of "and": cases where one file is covered by
multiple licenses simultaneously.  So, basically:

License: LGPL-2+ and manpage-license

or whatever the right tag for that second license is.  This is a bit
confusing when the licenses conflict, but I think it's close enough to
capturing what's going on here, and you can explain further in a Comment.

-- 
Russ Allbery (r...@debian.org)  

Re: DEP-5 copyright with different licenses for two parts of the same file

[Jonas Smedegaard]

Quoting Marc Haber (2023-08-29 18:31:52)
> in daemon(1), I have a file with has two contradicting licenses in the
> same file. See
> https://salsa.debian.org/debian/daemon/-/blob/master/libslack/getopt.c
> 
> >From the wording of the second copyright notice, I think it is clear
> that that notice applies to the POD documentation included in the file
> while the actual code is LGPL. Upstream confirms that this is the
> intention and agrees that this is somehow suboptimally worded.
> 
> Now, how do I write this in a DEP-5 copyright file? Having two stanzas
> for the same file gets flagged by Lintian as an Error, and the DEP-5
> syntax doesn't seem to allow to mention two Licenses in the License:
> line.

Yes, DEP-5 supports multiple licenses for one file:

Files: getopt.c
Copyright: 1987-1998  Free Software Foundation, Inc.
License: GPL-2+ and LGPL-2+
Comment:
 Embedded POD documentation is licensed LGPL-2+
 and other parts are licensed GPL-2+.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature