It feels related to #2153, but no idea if it is. Search returns nothing.
2019-02-25 10:21:05,810 xpra GTK2 shadow version 2.5-r21828 64-bit 2019-02-25 10:21:05,810 running with pid 1055 on Linux Ubuntu 16.04 xenial
This isn't related to #2153, different menu: this one is your system "start menu" definition.
That's a bug in your distribution. You can reproduce it with:
python2 -c "from xdg.Menu import parse;parse()"
On most distributions this works fine but on Ubuntu this can fail. IIRC, that's because the menu definitions point to a menu file which is missing. (further details can be obtained by running with -d menu
)
They shouldn't be shipping a library that cannot be called: either the library should fail more gracefully or they should ensure that their menu definitions do not trigger the problem.
What if it doesn't fail?
$ python2 -c "from xdg.Menu import parse;parse()" $ echo $? 0 $
No further debug coming with -d menu
:/
No further debug coming with -d menu :/
Whoops, sorry. Try -d exec
. It will honour -d menu
as of r21875.
The error is not "more helpful":
2019-02-25 11:01:11,521 load_xdg_menu_data() Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/platform/xposix/xdg_helper.py", line 218, in load_xdg_menu_data menu = parse() File "/usr/lib/python2.7/dist-packages/xdg/Menu.py", line 570, in parse raise ParsingError('File not found', "/etc/xdg/menus/%s" % candidate) ParsingError: ParsingError in file '/etc/xdg/menus/debian-menu.menu', File not found
The file indeed does not exist:
$ ls -lah /etc/xdg/menus/ total 36K drwxr-xr-x 2 root root 4,0K Φεβ 25 11:02 . drwxr-xr-x 5 root root 4,0K Αύγ 28 14:46 .. -rw-r--r-- 1 root root 19K Ιούν 30 2016 gnome-applications.menu -rw-r--r-- 1 root root 2,8K Φεβ 14 2017 unitycc.menu -rw-r--r-- 1 root root 3,8K Ιούλ 1 2016 unity-lens-applications.menu
touch
ing does not help xpra either; but the call itself has no issues working either way. I even "changed" the code to verify the call explicitly following the same code path:
$ python2 -c "from xdg.Menu import parse;parse()" ; echo $? filename /etc/xdg/menus/gnome-applications.menu <xml.dom.minidom.Document instance at 0x7ff8d8c1bb00> 0 $
vs
2019-02-25 11:16:23,713 xpra is ready. filename /etc/xdg/menus/debian-menu.menu 2019-02-25 11:16:23,812 load_xdg_menu_data() Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/platform/xposix/xdg_helper.py", line 218, in load_xdg_menu_data menu = parse() File "/usr/lib/python2.7/dist-packages/xdg/Menu.py", line 583, in parse raise ParsingError('Not a valid .menu file', filename) ParsingError: ParsingError in file '/etc/xdg/menus/debian-menu.menu', Not a valid .menu file 2019-02-25 11:16:23,813 Error parsing xdg menu data: 2019-02-25 11:16:23,813 ParsingError in file '/etc/xdg/menus/debian-menu.menu', Not a valid .menu file 2019-02-25 11:16:23,813 this is either a bug in python-xdg, 2019-02-25 11:16:23,813 or an invalid system menu configuration
No idea why xpra needs to "fallback to default" and the python call itself doesn't.
It must be related to some environment variable that's going to be different when running under xpra.
FYI: the problem does occur if you run that python command from within the xpra session. (ie: from an xterm started with --start=xterm
.
Replying to Antoine Martin:
FYI: the problem does occur if you run that python command from within the xpra session. (ie: from an xterm started with
--start=xterm
.
More debugs show the issue:
#559: candidate = applications.menu #560: filename = None 2019-02-25 11:16:23,812 load_xdg_menu_data() Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/platform/xposix/xdg_helper.py", line 218, in load_xdg_menu_data menu = parse() File "/usr/lib/python2.7/dist-packages/xdg/Menu.py", line 583, in parse raise ParsingError('Not a valid .menu file', filename) ParsingError: ParsingError in file '/etc/xdg/menus/debian-menu.menu', Not a valid .menu file
It seems that "someone" sets XDG_MENU_PREFIX=gnome-
on "normal ubuntu 16.04":
https://gitlab.gnome.org/GNOME/gnome-session/blob/3.8.2.1/gnome-session/main.c#L362
not set in xpra though. Simple
XDG_MENU_PREFIX=gnome- python2 -c "from xdg.Menu import parse;parse()"
does the job.
try without the XDG_MENU_PREFIX first
Thanks for figuring it out.
That's bogus IMO, here's the spec: menu spec which states that For example if a system contains both the GNOME and the KDE desktop environments it can decide to use gnome-applications.menu as the menu layout in GNOME sessions and kde-applications.menu as the menu layout in KDE sessions. To correctly reflect this, it should set the $XDG_MENU_PREFIX environment variable to "gnome-" respectively "kde-".
We're not gnome or KDE, so during server initialization we run the code that reads:
#we don't want client apps to think these mean anything: #(if set, they belong to the desktop the server was started from)
This ticket looks similar to: applications.menu file has been renamed to gnome-applications.menu but XDG_MENU_PREFIX is not set: If they decide to only respect specifications, no menu will be found.
Anyway, we will now avoid sanitizing this value, and so we'll keep the "gnome-" prefix even though we're not gnome: r21878. The patch above would solve it by trying both without and with the prefix, but I don't have time to test it.
Logging in via ssh does not set the XDG_MENU_PREFIX
, so sessions started via ssh will not have the menus. What a mess!
Should now work as of r21880, even from ssh or a clean environment.
It is now possible to run the code directly for testing:
$ python ./xpra/platform/xposix/xdg_helper.py * Accessories - Comment : Desktop accessories - Entries - About Xfce - Categories : Utility, X-XFCE, Documentation - Comment : Information about the Xfce Desktop Environment - Exec : xfce4-about - GenericName : - Hidden : False - Icon : help-about ...
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2174