Snaps not appearing in Debian9 Stretch LXDE menu (Not Wayland Bug)

Hi guys, I’m encountering a weird problem. Anyone sheds some light?


Background
Apparently, installed snaps are working fine via terminal commands. However, Apps like Atom, VLC and Firefox has their own respective .Desktop files. They aren’t appearing in the menu.

UPDATE 8/14/2018 21:55 +0800: /etc/profile is not sourced at login. You must add source /etc/profile in ~/.bashrc or ~/.xsessionrc manually in order to make snaps commands available to use. It’s not a bug but an expectation for all Debian users.

Expected Outcome
Shortcuts are made available in the menu for those that have .Desktop without manual intervention.

Urgently Looking For
A way to export the .Desktop path like how we do for $PATH.

Discovered Date
13 August 2018 +8000

Workaround
The snaps .Desktop files are located in /var/lib/snapd/desktop/applications/. Navigate into that folder and copy the file out to Desktop for easy access.

OR

softlink them into $HOME/.local/share/applications/..

Snapd Info

  1. Using native package? Yes
  2. Snapd Version?
snap    2.34.3
snapd   2.34.3
series  16
debian  9
kernel  4.9.0-7-amd64
  1. Upgrade it to latest? Still looking for way to update it towards the latest.

Hypothesis 1: Wayland bug
Source: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1705122
Attempted: Desktop snaps do not appear in the dash/menu on gnome in 17.10 final beta, no result.
Inferences:

  1. My case is X11, as loginctl dump these outputs:
holloway:fennec$ loginctl 
   SESSION        UID USER             SEAT             TTY             
         2       1000 holloway         seat0                            
         4       1000 holloway                                          
        c1        111 lightdm          seat0                            

3 sessions listed.
holloway:fennec$ loginctl show-session 2 -p Type
Type=x11
holloway:fennec$ loginctl show-session 4 -p Type
Type=tty
holloway:fennec$ loginctl show-session c1 -p Type
Type=x11

Also attempted XDG_DATA_DIRS environment variables, no luck.
Checked my terminal type:

holloway:fennec$ echo $SHELL
/bin/bash

Hypothesis 2: The .desktop files are misplaced
Source: https://askubuntu.com/questions/910821/snap-install-programs-not-in-launcher
Attempted:

holloway:fennec$ ln -st ~/.local/share/applications /var/lib/snapd/desktop/applications/*.desktop 

Turns out it is working fine but I need to run this every time I install a new snap.


1 Like

Desktop environments are supposed to look for their .desktop files in all dirs defined in the XDG_DATA_DIRS environment variable.

$ env |grep XDG_DATA_DIRS
XDG_DATA_DIRS=/usr/share/ubuntu:/usr/share/gnome:/usr/local/share:/usr/share:/var/lib/snapd/desktop:/var/lib/snapd/desktop

Whatever login manager you use (GDM, lightdm, sddm) should set this variable and whatever desktop environment you use should respect its content to search for the applications subdir in all the provided entries.

For details see:

https://specifications.freedesktop.org/menu-spec/menu-spec-1.0.html#paths

1 Like

hmm, I wonder why it’s there twice :slight_smile:

1 Like

looks like a bug in /etc/X11/Xsession.d/65snappy … the else condition should get an additional check to not append it if it is already set … (it has no functional impact though (apart from scanning the same dir twice though))

1 Like

YKWTD.

1 Like

It is getting weirder. My XDG_DATA_DIRS has the path stated correctly (unaltered version)

XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/:/var/lib/snapd/desktop/applications

I tested the adding the missing /var/lib/snapd/desktop after what I got. No luck either. Looking at lightdm documentations at the moment to root cause the issue.

UPDATE (14/8/2018 20:00 +0800): My /etc/X11/Xsession.d/65snappy:

# This file is sourced by Xsession(5), not executed.
# Add the additional snappy desktop path

if [ -z "$XDG_DATA_DIRS" ]; then
    # 60x11-common_xdg_path does not always set XDG_DATA_DIRS
    # so we ensure we have sensible defaults here (LP: #1575014)
    # as a workaround
    XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop
else
    XDG_DATA_DIRS="$XDG_DATA_DIRS":/var/lib/snapd/desktop
fi
export XDG_DATA_DIRS

it does not, it has /var/lib/snapd/desktop/applications which would make the desktop search in /var/lib/snapd/desktop/applications/applications (which in turn does not exist) … you should find out what did put this broken entry there …

and also find out why /etc/X11/Xsession.d/65snappy does not seem to be used at all.

1 Like

Any tips/pointers for tracing the environment variables? Apart from reading through the manuals (might take some times for ramping up).

in .xsession-errors, I got:

dbus-update-activation-environment: setting XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop                                                                                                  
dbus-update-activation-environment: setting CLUTTER_IM_MODULE=xim                                                                                                                                               
** Message: main.vala:102: Session is LXDE                                                                                                                                                                      
** Message: main.vala:103: DE is LXDE     

XDG_DATA_DIRS is showing the correct /var/lib/snapd/desktop.

Still working on tracking the cause.

Well, if you say you see the correct value in XDG_DATA_DIRS now, it can only be an issue on the desktop side itself, perhaps a bug in debians lxde session package or some such …

if the XDG_DATA_DIRS variable is set properly, snapd is out of the list of suspects, since setting this var correctly is all it can do. it can not do anything if the desktop does not pick it up …

1 Like

My apology.

Did a full system scan using sudo grep -rnw / -e '/var/lib/snapd/desktop'. Found the culprit (it was me adding it manually inside /etc/profile.d/apps-bin-path.sh during the investigation.

My original app-bin-path.sh is:

# Expand the $PATH to include /snap/bin which is what snappy applications
# use
PATH=$PATH:/snap/bin

Earlier investigation found that /etc/profile is not sourced at login at all. I did a manual sourcing in my own $HOME/.bashrc, in order to reach /etc/profile.d/app-bin-path.sh. After reboot by removing all my changes, in both $HOME/.bashrc and app-bin-path.sh,

holloway:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
holloway:~$ echo $XDG_DATA_DIRS
/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/
holloway:~$

Worst still: terminal based snap commands are no longer available. Updated post.


Additional note: scan shows /etc/X11/Xsession.d/65snappy has that line but looks like it’s not being called out as well.

Following the Debian discussion https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752129, Bug #794315 “lightdm forgets to source /etc/profile and ~/.profi...” : Bugs : lightdm package : Ubuntu, and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752192, it appeared that lightdm does not and will not source /etc/profile and /etc/environment by default. User is expected to do ~/.xsessionrc. In my case, source via ~/.bashrc is making a lot more sense. Hence, based on https://superuser.com/questions/881102/etc-profile-not-being-sourced-at-login, we can use:

test -f /etc/environment && source /etc/environment
test -f /etc/profile && source /etc/profile

This restores the terminal based snap commands, since it’s lightdm specific matter.


As for .desktop, no update yet, still investigating.

1 Like

The profile.d snippet is mainly for PATH in shell terminals (see the comment at the top of /etc/profile which sources profile.d at the bottom)… XDG_DATA_DIRS in there is only used in wayland sessions (which require GDM to my knowledge), because wayland obviously does not use Xsession.d.

The important part for your setup is really /etc/X11/Xsession.d/65snappy which should definitely be sourced during Xorg startup, no matter which DM is used.

1 Like

Update:

  1. /etc/X11/Xsession.d/65snappy did run after I injected export DEBUG_SNAPP_RUN=$XDG_DATA_DIRS.

The output from env did show DEBUG_SNAPP_RUN as: DEBUG_SNAPP_RUN=/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

However, XDG_DATA_DIRS shows XDG_DATA_DIRS=/usr/local/share:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/ instead.

What I can deduce is something had override XDG_DATA_DIRS after the Xsession.d initialization.

  1. Currently scanning for XDG_DATA_DIRS and /var/lib/menu-xdg/ source code to find out which guy overriden the variable. It’s been 10 hours straight yet scan is still running.

  2. Performing a source /etc/X11/Xsession.d/65snappy then sudo update-desktop-database doesn’t do any effect.

Found the culprit: /usr/bin/startlxde

There is a known bug Bug #1499650 “local applications are not shown in menu (LXDE)” : Bugs : ltsp package : Ubuntu for lxde local desktop to appear in the menu. This startlxde script overrides XDG_DATA_DIRS implicitly, at this line:

export XDG_DATA_DIRS="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"

To fix this, we need to monkey-patch /usr/bin/startlxde by replacing that line with (ensure you edit it with sudo):

xdg_path="/usr/local/share/:/usr/share/:/usr/share/gdm/:/var/lib/menu-xdg/"
if [ -z "$XDG_DATA_DIRS" ]; then
        export XDG_DATA_DIRS="$xdg_path"
else
        if [ -z "$(echo "$XDG_DATA_DIRS" | grep "$xdg_path")" ]; then
                export XDG_DATA_DIRS="${XDG_DATA_DIRS}:$xdg_path"
        fi
fi
unset xdg_path

Reboot your machine and you should see all the .desktop from the snap folders appear in the menu.


@ogra, should we notify the lxde team about it?

If yes, how to we proceed from here before I mark the post as solution?

1 Like

Well if the debian lxde team isnt aware of this bug it would surely be good to make them aware … though given the focus of the lxde teams in various distros to move to lxqt your mileage may vary in getting it fixed by them (not sure if the qt version exposes similar issues). in any case making developers aware of problems with their software is always a good thing :slight_smile:

1 Like

Done. I submitted a bug report to Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906288. We should close this topic now and follow up via the bug report. Not a snapd issue. :star_struck:

Looking forward to lxqt on my side too. Thanks for the help @ogra!

3 Likes