Bug#1050964: blackbox: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal
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
[bts-link] source package cmatrix
# # bts-link upstream status pull for source package cmatrix # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #715743 (http://bugs.debian.org/715743) # Bug title: cmatrix: Segfault when $TERM is unset # * https://github.com/abishekvashok/cmatrix/issues/174 # * remote status changed: (?) -> open usertags 715743 + status-open thanks
Processed: Re: Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Processing control commands: > block -1 by 1016558 Bug #1042911 [elpa-muse] Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc 1042911 was not blocked by any bugs. 1042911 was not blocking any bugs. Added blocking bug(s) of 1042911: 1016558 -- 1042911: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042911 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Control: block -1 by 1016558 Hi, I'm just updating this bug to note the adopted muse-el package is just about ready to upload (the ITA is also a pseudo-RFS bug), and I plan to upload in the next few days. If this update isn't enough to prevent autoremoval...well, at least the package will be fixed very soon. Regards, Nicholas signature.asc Description: PGP signature
Bug#1050899: qa.debian.org: https://qa.debian.org lists repository size not matching GitLab's data
On Thursday, 31 August 2023 11:13:41 CEST Filippo Rusconi wrote: > I have reduced the size of the repository recently as a response to this > message How did you do that? On a local git repo I can do `git gc --aggressive`, but I have no idea if such a thing is possible on a repo hosted on Salsa and if it's possible, how to do it. signature.asc Description: This is a digitally signed message part.
Bug#1050899: qa.debian.org: https://qa.debian.org lists repository size not matching GitLab's data
Package: qa.debian.org Severity: minor Greetings, [ Message sent last 22 June and today to debian-qa@lists.debian.org ] I am having trouble with the Salsa git repos for my package (upstream also) minexpert2. The ddpo page (https://qa.debian.org/cgi-bin/vcswatch?package=minexpert2) says this: minexpert2 (9.2.1-1) [PTS] [DDPO] ERROR: Git: https://salsa.debian.org/debichem-team/minexpert2.git Branch: master Path: debian/changelog Repo size: 1096462336 Browser: https://salsa.debian.org/debichem-team/minexpert2 Last scan: 2023-06-20 15:29:01+00 Error: Repository size 1096462336 exceeds 1 GiB, blocking it Repository is blocked I have reduced the size of the repository recently as a response to this message and now, when I look into Settings->Usage quotas, the GitLab interface of Salsa tells this: Git repository. 325.6 MiB Now, when I click onto the "Scan now" button of that ddpo page, nothing changes. What is it that I am misunderstanding on the whole repository size problematic ? Thank you for your kind attention and for your help, Sincerely Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Researcher at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org
Enquiry about one QA page I do not understand
Greetings, [ Previous message sent last 22 June] I am having trouble with the Salsa git repos for my package (upstream also) minexpert2. The ddpo page (https://qa.debian.org/cgi-bin/vcswatch?package=minexpert2) says this: minexpert2 (9.2.1-1) [PTS] [DDPO] ERROR: Git: https://salsa.debian.org/debichem-team/minexpert2.git Branch: master Path: debian/changelog Repo size: 1096462336 Browser: https://salsa.debian.org/debichem-team/minexpert2 Last scan: 2023-06-20 15:29:01+00 Error: Repository size 1096462336 exceeds 1 GiB, blocking it Repository is blocked I have reduced the size of the repository recently as a response to this message and now, when I look into Settings->Usage quotas, the GitLab interface of Salsa tells this: Git repository. 325.6 MiB Now, when I click onto the "Scan now" button of that ddpo page, nothing changes. What is it that I am misunderstanding on the whole repository size problematic ? Thank you for your kind attention and for your help, Sincerely Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Researcher at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org