#2174 closed defect (invalid)
xpra shadow raises "Error parsing xdg menu data"
Reported by: | stdedos | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | minor | Milestone: | 2.5 |
Component: | server | Version: | 2.4.x |
Keywords: | Cc: |
Description (last modified by )
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
Attachments (2)
Change History (13)
Changed 2 years ago by
comment:1 Changed 2 years ago by
Description: | modified (diff) |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 Changed 2 years ago by
What if it doesn't fail?
$ python2 -c "from xdg.Menu import parse;parse()" $ echo $? 0 $
No further debug coming with -d menu
:/
comment:3 Changed 2 years ago by
No further debug coming with -d menu :/
Whoops, sorry. Try -d exec
. It will honour -d menu
as of r21875.
comment:4 Changed 2 years ago by
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.
comment:5 Changed 2 years ago by
It must be related to some environment variable that's going to be different when running under xpra.
comment:6 follow-up: 7 Changed 2 years ago by
FYI: the problem does occur if you run that python command from within the xpra session. (ie: from an xterm started with --start=xterm
.
comment:7 Changed 2 years ago by
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.
comment:8 Changed 2 years ago by
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.
comment:9 Changed 2 years ago by
Logging in via ssh does not set the XDG_MENU_PREFIX
, so sessions started via ssh will not have the menus. What a mess!
comment:10 Changed 2 years ago by
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 ...
comment:11 Changed 6 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2174
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:
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.