PATH and graphical sessions
- Inicie sesión o regístrese para enviar comentarios
In a plasma (KDE) wayland session opened right after boot, I have:
echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
If I open a GNOME wayland session, close it and open a plasma wayland session again:
echo $PATH /home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
Opening a GNOME wayland session is so fast that I can't measure the time it takes (whereas plasma takes about 25 seconds to start!) so it isn't a terrible burden to open and close a GNOME wayland session first to get the right PATH, but I wonder whether there is a way without doing that.
Besides, the more I open and close sessions the longer PATH becomes, with many things there repeated, for example:
echo $PATH /home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/home/david/.local/bin:/home/david/bin:/home/david/.guix-profile/bin:/home/david/.config/guix/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
I never tried tweaking the PATH variable so this is coming from things automatically installed.
I see that my .profile is adding ~/bin et ~/.local/bin but for some reason it wasn't executed when I started a plasma wayland session. I believe that /etc/profile.d/guix.sh is what sets the pathes for guix, so it also wasn't executed.
I don't know how to check what triggers the execution of the files in /etc/profile/ and ~/.profile, and I am surprised that the contents of PATH set in previous sessions persists in another session, it looks like a bug.
I added my .bashrc, .profile and the whole contents of /etc/profile, which I guess is what is relevant to this (I had it prepared and selected but I tend to forget that having the file selected is not enough, one needs to click on the "attach" button).
Adjunto | Tamaño |
---|---|
init.tar.gz | 2.41 KB |
I personally use GNU Bash (by default in Trisquel) and add the $HOME/Travail/bin directory to PATH with that line in ~/.bashrc:
PATH="$HOME/Travail/bin:$PATH"
I could do that but when opening a session in a number of graphical environments, everything is set properly in PATH already, including for programs installed by guix.
Besides, when the PATH is not set for guix, XDG_DATA_DIRS (and other variables) is also not set for guix, and also not for flatpak. I see that /etc/profile.d/guix.sh is setting everything properly for guix, and there is also /etc/profile.d/flatpak.sh setting XDG_DATA_DIRS for flatpak, and there are other .sh files in /etc/profile.d/ for other things, and when PATH is not only what is in /etc/environment (seems to be the system default), all the variables are set according to all files in /etc/profile.d.
So it looks like either /etc/profile is not sourced in some cases, or it is but something fails at some point so that at least guix.sh and flatpak.sh are not executed, or could there be another reason?
When the PATH (and other variables are not set), apps installed by guix are not visible in the menus of KDE, but apps installed by flatpak are visible still. I don't know how KDE does to create its menus, whether flatpak apps do something for them to persist even when the environment is not fully set.
So the twin giants Plasmo and Gnomo are stepping on each other's feet, and Guixo is taking the heat? If I am not mistaken, your setting involves systemd + gdm + wayland + gnomeshell + guix vs. systemd + gdm + wayland + plasmashell + guix. I would try installing Triskel on a VM, see if the situation is different, and if so, see which settings are different.
There is a documented attempt to improve Guix integration on "foreign" distros [1]. It is a bit less ambitious than your setting, but it looks like it still got some unexpected behavior with all DEs. It also has a specific comment about Triskel 10.
I am currently almost exclusively using LXDE and the Trisquel repo, from a clean Trisquel Mini 11 install, so obviously I live in a corner of the world where these integration hickups sound like bogeyman stories. At least, you are not "seeing a splash screen with a spinner for a while, then the screen goes black [2]".
[1] https://gist.github.com/peanutbutterandcrackers/844c211a91137c19607ae75b59fa116f
[2] https://lists.gnu.org/archive/html/help-guix/2022-05/msg00147.html
So the twin giants Plasmo and Gnomo are stepping on each other's feet
My current assumption is simply that ~/.profile and /etc/profile are not sourced in the plasma wayland session.
Actually, I am not trying to mix Plama and Gnome. Xorg crashes quickly on my newest laptop and I suspect there are gradually less people willing to spend time debugging Xorg, so I decided to try environments using Wayland, and so far I had no similar issue on them. After trying Gnome, I tried Plama and found it much easier to use and configure using only software from Trisquel repository (including automatic tiling) so I don't plan to use Gnome anymore, I was just comparing with Gnome when investigating this issue.
Your idea of the VM is good, I will try it but without Gnome. If ~/.profile and /etc/profile are not sourced, one solution that should work is to create symbolic links to them in ~/.config/plasma-workspace/env. I have a few other small annoyances with Plasma on wayland, like ssh-agent not started automatically and the keepassxc icon missing from the panel (but if I open keepassxc and in its options, untick that option and click ok, then tick it back and click ok, it appears and remains for the rest of the session), that I could investigate too.
I am currently almost exclusively using LXDE and the Trisquel repo, from a clean Trisquel Mini 11 install, so obviously I live in a corner of the world where these integration hickups sound like bogeyman stories.
I use MATE with dwm on other computers, and with dolphin with previews of pdf files, which I have not managed to have with any other file manager. So KDE has the nice properties of providing everything and looking easily usable in general, so I could probably recommend it.
There is in fact an open guix issue report about the glitch with KDE Plasma: https://issues.guix.gnu.org/56050.
> previews of pdf files, which I have not managed to have with any other file manager.
Now this is a bit surprising. PCManFM has a hard-coded 32 MB file size limit for previews, but I do not recall any issue with Caja. You may need to check that the value for the file size limit is set high enough. But maybe it also depends on which pdf viewer you are using? The thumbnails have to be fetched somewhere, and I have now noticed that Caja has a specific "Atril properties" extension that is selected by default and may be taking care of just that.
EDITED UPDATE: installing Atril on Trisquel Mini made pdf preview thumbnails available in PCManFM. After swapping back to Evince, only the thumbnails that had been generated by Atril earlier were displayed, new pdf files did not get a preview. So Evince is just not doing its thumbnailing job properly when paired with PCManFM, even if it can be found in usr/share/thumbnailers. I have now swapped forward to Atril, and all is swell.