From debbugs-submit-bounces@debbugs.gnu.org Mon May 02 08:49:53 2022 Received: (at 48796) by debbugs.gnu.org; 2 May 2022 12:49:54 +0000 Received: from localhost ([127.0.0.1]:35086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlVUv-0001rV-Ag for submit@debbugs.gnu.org; Mon, 02 May 2022 08:49:53 -0400 Received: from ns13.heimat.it ([46.4.214.66]:46448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlVUs-0001rG-Oq for 48796@debbugs.gnu.org; Mon, 02 May 2022 08:49:52 -0400 Received: from localhost (ip6-localhost [127.0.0.1]) by ns13.heimat.it (Postfix) with ESMTP id 105E330219B; Mon, 2 May 2022 12:49:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at ns13.heimat.it Received: from ns13.heimat.it ([127.0.0.1]) by localhost (ns13.heimat.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD5HH8gePHQH; Mon, 2 May 2022 12:49:41 +0000 (UTC) Received: from bourrache.mug.xelera.it (unknown [93.56.171.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by ns13.heimat.it (Postfix) with ESMTPSA id B1D14300FB0; Mon, 2 May 2022 12:49:41 +0000 (UTC) Received: from roquette.mug.biscuolo.net (roquette [10.38.2.14]) by bourrache.mug.xelera.it (Postfix) with SMTP id 3CD091A478C9; Mon, 2 May 2022 14:49:41 +0200 (CEST) Received: (nullmailer pid 17901 invoked by uid 1000); Mon, 02 May 2022 12:49:40 -0000 From: Giovanni Biscuolo To: Liliana Marie Prikler , Maxim Cournoyer , bo0od Subject: Re: bug#48796: Guix on Debian 11 - Cant run or find applications from Guix in Desktop Menus In-Reply-To: <59eff3512f8726c4ac0ee4071d878536b197d31f.camel@gmail.com> Organization: Xelera.eu References: <87zgs3jxvr.fsf@gmail.com> <87pml1gpw8.fsf@xelera.eu> <59eff3512f8726c4ac0ee4071d878536b197d31f.camel@gmail.com> Date: Mon, 02 May 2022 14:49:39 +0200 Message-ID: <871qxcf6ak.fsf@xelera.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 48796 Cc: 48796@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Liliana Marie, thank you for your heads up! I confess I'm pretty much confused about "Freedesktop.org's xdg menu system" because I thought it's now a cross-distro standard that should work out of the box without much tinkering by the distro maintainers and/or by the user. There is a non zero chance that it does depend on poor implementation or documentation, and for sure I'm not the only one that is experiencing issues in this regard[1]. There is obviously a non zero chance it depends on my poor understanding, please forgive me in this case. This situation (obviously) does /not/ depend on Guix, it depends on the Xsession setup and "xdg menu system" (and lack of documentation?) of the foreign distro side. I just think that if Guix (the package manager) cannot automate desktop integration on all foreign distros then it should be stated in the manual, possibly explaining why and pointing users to the foreign distro documentation. Anyway, I still think (hope) that we can "fill the gap" since we probably have al the pieces (env and information) and we probably "just" need to connect the dots to have the whole picture... working cross-distro I mean. To add a little bit of context (and highlight it's not an issue just for Guix as a package manager) I found this bug reports interesting: 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D927907 flatpak directories not added to XDG_DATA_DIRS on Plasma + Wayland (still open, last update 2022-04-16) 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D931776 snapd: Installed snaps do not appear in desktop launcher in Debian buster. (still open, last update 2022-04-22) 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D647427 XDG_DATA_DIRS not set when using openbox-gnome-session (resolved on 2013-07-23) Liliana Marie Prikler writes: [...] >> > It even set XDG_DATA_DIRS, which should allow integration with the >> > GNOME Shell and other graphical dashboards. >>=20 >> No: this does not work, for three reasons: >>=20 >> 1. AFAIU "/etc/profile.d/guix.sh" or "~/.profile" are not >> sourced/executed in a graphical session (graphical shell?), we need >> to ~/.xsessionrc to configure that environment: am I wrong? > Depends on your setup. Some systemd setups don't source it, So it depends on the /default/ systemd setup of the foreign distro, Debian 11 in this case, because I did not customize it: please do you know where I should check for the systemd specific documentation on "xdg related stuff"? The documentation I was able to find does not help me with systemd config: =2D https://wiki.debian.org/Xsession [2] =2D https://wiki.debian.org/EnvironmentVariables#Using_graphical_display_ma= nager This statement (in https://wiki.debian.org/Xsession) =2D-8<---------------cut here---------------start------------->8--- Finally, note that the ~/.xsession file is only read if you are using a Debian X session. If you login with gdm3 and choose a GNOME session, the ~/.xsession file will be ignored completely. (But you may still use ~/.xsessionrc.) =2D-8<---------------cut here---------------end--------------->8--- makes me wonder what (and why) is the differenxe betweeen a Gnome Session and an LXDE one: shouldn't the setup be standard? It's the systemd specific way to setup an xsession? Also: https://manpages.org/xsession/5 By default, on Debian 11 this is the content of /etc/X11/Xsession.options: =2D-8<---------------cut here---------------start------------->8--- # $Id: Xsession.options 189 2005-06-11 00:04:27Z branden $ # # configuration options for /etc/X11/Xsession # See Xsession.options(5) for an explanation of the available options. allow-failsafe allow-user-resources allow-user-xsession use-ssh-agent use-session-dbus =2D-8<---------------cut here---------------end--------------->8--- Do I miss some specific systemd Debian 11 xdg related documentation? > but note that you can work around that by editing the offending file. Please can you point me to the offending file? > More importantly... > >> 2. XDG_DATA_DIRS gets someway hard reset by "something" to this >> value: >>=20 >> XDG_DATA_DIRS=3D/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/men >> u-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu- >> xdg/ > I would investigate what actually "resets" this. If it survives > XDG_DATA_DIRS=3Dblah $SHELL, then it's in the stuff your shell sources. Actually if I give that command in a terminal I get "XDG_DATA_DIRS=3Dblah", but I'm pretty sure there is nothing in the stuff of my shell sources that resets XDG_DATA_DIRS > If it doesn't, then you probably just experience (1). Yes: there is something in the default systemd/xsession configuration of Debian 11 that resets XDG_DATA_DIR. Please is there some user with a default Debian 11 xsession configuration that can try to reproduce this? Am I the only one to experience this XDG_DATA_DIR reset issue? >> (I found workaround, see below) >>=20 >> 3. desktop menus (I tested LXDE and Mate, not Gnome Shell) are not >> updated > We hacked our Gnome Shell package to do this on Guix =E2=80=93 naturally = this > won't work for foreign systems or other packages. OK thank you, now I understand how it works. I still have not found some time to check how Debian packages are live-updating the desktop menus, AFAIK that update works cross-desktop-environment and I'd like to know: 1. is that also a cross-distro standard? 2. why "xdg-desktop-menu forceupdate" does not work for user installed *.desktop menus? 3. is there any other CLI that allows users to uptate their graphical menus after having "manually installed" (write the right file in the right folder) a *.desktop file? >> [...] >> The main point of this workaround is that I configure XDG_DATA_HOME, >> described in the specifications: > And that is evil. Please can you expand what do you mean with "evil"? I as told (did I told?) I found that information in the "XDG Base Directory Specification" [3]=20 Also, the "9.4.10. Starting a program from GUI" [4] current Debian manual states: =2D-8<---------------cut here---------------start------------->8--- This is an oversimplified description. The *.desktop files are scanned as f= ollows. The desktop environment sets $XDG_DATA_HOME and $XDG_DATA_DIR environment v= ariables. For example, under the GNOME 3: $XDG_DATA_HOME is unset. (The default value of $HOME/.local/share is used.) $XDG_DATA_DIRS is set to /usr/share/gnome:/usr/local/share/:/usr/share/. So the base directories (see XDG Base Directory Specification) and the appl= ications directories are as follows. $HOME/.local/share/ =E2=86=92 $HOME/.local/share/applications/ /usr/share/gnome/ =E2=86=92 /usr/share/gnome/applications/ /usr/local/share/ =E2=86=92 /usr/local/share/applications/ /usr/share/ =E2=86=92 /usr/share/applications/ The *.desktop files are scanned in these applications directories in this o= rder. [Tip] Tip A user custom GUI menu entry can be created by adding a *.desktop file in t= he $HOME/.local/share/applications/ directory. [Tip] Tip Similarly, if a *.desktop file is created in the autostart directory under = these base directories, the specified program in the *.desktop file is exec= uted automatically when the desktop environment is started. See Desktop App= lication Autostart Specification. =2D-8<---------------cut here---------------end--------------->8--- Also, the Freedesktop.org "Desktop Menu Specification" chapter "C. Integrating your application in the menus" [5] documents how to add menu items; it states: =2D-8<---------------cut here---------------start------------->8--- If an application is intended to be installed by an unprivileged user for e= xclusive use by that user only then $XDG_DATA_HOME should be used as value = for datadir and $XDG_CONFIG_HOME should be used as value for sysconfdir. If= $XDG_DATA_HOME is not set, the default value of $HOME/.local/share should = be used for it. If $XDG_CONFIG_HOME is not set, the default value of $HOME/= .config should be used for it. =2D-8<---------------cut here---------------end--------------->8--- Reading the above it seems perfectly legit to customize XDG_DATA_HOME pointing that variable to any user directory I need to add custom GUIX menu entries... and I let handle that menu entries to my guix profile: do I miss something? Should I also customize $XDG_CONFIG_HOME to point to a specific directory different from $HOME/.config? >> [...] >> Anyway to make the new installed *.desktop files appear in the menu, >> I have to logout and login again: I've still not found a command (or >> configuration) to update the menu, "xdg-desktop-menu forceupdate" >> does not work. > Should it? It might only honor XDG_DATA_DIRS and ignore XDG_DATA_HOME > by accident. AFAIU xdg-desktop-menu is supposed to also update user menus > Other than that, restarting your shell (if running on X) might be a > more lightweight way of refreshing the menu. Restarting the shell means restarting the desktop environment? I know how to do it with i3 (reload config) but I don't know hot to do it with LXDE (or mate, Gnome3, ecc.) Cheers. Gio' [1] as I already wrote, I don't use any desktop environment graphical menu so I rarely experience this issues, but when trying to help other users I still cannot find a deterministic solution to this class of issues. [2] it also points to https://www.debian.org/doc/manuals/debian-reference/ch07.en.html#_starting_= the_x_window_system but that node is /not/ present on a recent manual [3] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.htm= l#variables [4] https://www.debian.org/doc/manuals/debian-reference/ch09.en.html#_start= ing_a_program_from_gui [5] https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#thi= rd-party-howto =2D-=20 Giovanni Biscuolo Xelera IT Infrastructures --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEERcxjuFJYydVfNLI5030Op87MORIFAmJv02QMHGdAeGVsZXJh LmV1AAoJENN9DqfOzDkSFywQAIY0vmyexNexicFHcY6E5P764fEUrwq0165vCk4S IZH6Gj8Xkg9WXxaZefEPJAfmyihGrsEJYukWxl4eXCDLIgkuYTvkfAzirBQjzIna pJRxRcI/4p7Jnm7erggJI4zBXyChVoF2ku7+M7IKlxczrfUaGmbqaHetHcPJyuSy FCvxrvodscFYyg+R2TVkEBfaQkUKcOoMNp+Wb+cT91groadop9wsr+KfnFJ8tBcc zGRyPs0Y8/w9hnmpZihej0YybGqRDfSF1xDiwOozy9rqTkfMouQQ8l6mpqYzcXRB YquuvsnMd6XG4kVSVWUJ3POH/sYqbS9sU6SFInkI8yn1c5NqznXuNgHvboqfkvhS d5FYc6b6NoiTKj686gqTPGOruNd4mnZgPmzQAaSLZXjcGZO0ZksJuj3Ar9SPdw2u MCrOhuxCx4I5sn9YAWC+CehGlY1fh7+qNkU3JD5kN7BozYpFBd9dNfhea2oPJqNB kLjkmTbEgodbPP5dL4Y3h7vgi2+6QErlrX2UoHSmvptBMi5BINfm1PprUXUTXpeT FNCjYcaPPr0Nn9hfVFaqTPvnyNejK1eePf5V3TjYa8BonNTgMGuJzH9/RN5ku85L FVtAYqwm9XnvzctVBgEAoCARxPexHsLdNePIJb8Uq4OCB7bGERakFbIUXKzL/FZ6 9qwN =YNOa -----END PGP SIGNATURE----- --=-=-=--