xpra shadow raises "Error parsing xdg menu data"

[totaam]

Issue migrated from trac ticket # 2174

component: server | priority: minor | resolution: invalid

2019-02-25 08:27:28: stdedos created the issue

---

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-21828 64-bit
2019-02-25 10:21:05,810  running with pid 1055 on Linux Ubuntu 16.04 xenial

[totaam]

2019-02-25 08:27:41: stdedos uploaded file :0.log (2.1 KiB)

[totaam]

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.

[totaam]

2019-02-25 08:51:46: stdedos commented

---

What if it doesn't fail?

$ python2 -c "from xdg.Menu import parse;parse()"
$ echo $?
0
$

No further debug coming with -d menu :/

[totaam]

No further debug coming with -d menu :/

Whoops, sorry. Try -d exec. It will honour -d menu as of r21875.

[totaam]

2019-02-25 09:08:58: stdedos commented

---

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

touching 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.

[totaam]

It must be related to some environment variable that's going to be different when running under xpra.

[totaam]

FYI: the problem does occur if you run that python command from within the xpra session. (ie: from an xterm started with --start=xterm.

[totaam]

2019-02-25 20:39:06: stdedos commented

---

Replying to [comment:6 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.

[totaam]

2019-02-26 01:02:45: antoine uploaded file menu-context.patch (3.0 KiB)

try without the XDG_MENU_PREFIX first

[totaam]

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.

[totaam]

Logging in via ssh does not set the XDG_MENU_PREFIX, so sessions started via ssh will not have the menus. What a mess!

[totaam]

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
...

[totaam]

Some OSes don't set things up correctly: problem getting application data from DE
We already try various magic values that might help make it load the menus without errors:

xpra/xpra/platform/xposix/menu_helper.py

Lines 379 to 382 in b1454da

	for prefix in (None, "", "gnome-", "kde-"):
	if prefix is not None:
	os.environ["XDG_MENU_PREFIX"] = prefix
	try:

[brainchild0]

What component, functionality, operation, or so on, should be included in the OS for the menu to appear correctly?

I have not yet understood how all the pieces of this problem fit together, and am simply wondering, if I imagine myself as the OS provider, what change I would have to make to the OS for the relevant support to be provided.

[brainchild0]

We already try various magic values that might help make it load the menus without errors

Is there any reason for not at least picking some file name rather than none? At the moment, I have no menu available. Surely, there are sensible changes that are unlikely to degrade the situation further, right?

[brainchild0]

Ultimately, it not the server receiving the request for the Xpra session that ought to determine the desktop environment, but in my view, the client, which is where the end user would be situated. Is it sensible to approach the question of choosing a desktop environment as a user preference, rather than one imposed by the remote site?

[totaam]

What component, functionality, operation, or so on, should be included in the OS for the menu to appear correctly?

The ability to use the library, out of the box, without relying on the XDG_MENU_PREFIX environment variable being set to a specific value.

Is there any reason for not at least picking some file name rather than none?

That's exactly what we try to do, see the comment just above: #2174 (comment)
We try gnome-, etc..

At the moment, I have no menu available.
Surely, there are sensible changes that are unlikely to degrade the situation further, right?

I literally have no idea what these "sensible" changes would be.
We can keep adding strings to our guess list of values to try when the defaults don't work out of the box.
Feel free to provide the prefix that does work on your specific system setup.

Is it sensible to approach the question of choosing a desktop environment as a user preference, rather than one imposed by the remote site?

No. The html5 client, MS Windows and MacOS desktops don't have the concept of a desktop environment.
The server needs to be able to use the xdg library without making any assumptions about what the client may or may not have in terms of DE.

[brainchild0]

What component, functionality, operation, or so on, should be included in the OS for the menu to appear correctly?

The ability to use the library, out of the box, without relying on the XDG_MENU_PREFIX environment variable being set to a specific value.

Yes, but from the standpoint of asking the question, such an answer is circular. What I am seeking to understand is what actual component must be inserted into the distribution's file tree, or what must be changed in an existing file or utility, that would bring about such a functional change.

That's exactly what we try to do, see the comment just above: #2174 (comment) We try gnome-, etc..

We can keep adding strings to our guess list of values... Feel free to provide the prefix that does work on your specific system setup.

Not quite. I intended to suggest the idea of literally any file, whether or not blessed by a prescribed list of prefixes, necessarily being better than none.

(That is to say nothing of the observation that Xfce4 is conspicuously absent from the list. If it were given, then connections to my server would not experience the reported problem.)

The server needs to be able to use the xdg library without making any assumptions about what the client may or may not have in terms of DE.

Again, not quite what I meant. I was not suggesting that the choice of desktop environment for the server should try to match the one used on the client, any more than I would suggest that the password given for server login must match the local password for the same user. I was simply suggesting that which desktop environment to prefer for the remote host, among those available, might be a matter of preference, by the user invoking the session from the client.

[totaam]

such an answer is circular

No comment.

What I am seeking to understand is what actual component must be inserted into the distribution's file tree

Perhaps you should ask your distribution / python-xdg / desktop environment instead as this is not an xpra problem.
You can clearly see this by running the command from a clean environment (ie: ssh session) on your system:

python -c "from xdg.Menu import parse;parse()"

Not quite.
(..)

Again, if your distribution wants to fix things in a different / better way, go right ahead.

I was simply suggesting...

This would be "nice" but does literally nothing to solve the bug discussed here.

I am going to lock this issue because it is meant as a quick reference on the source of this common problem and is quickly devolving into bike shedding.

a42e234 should be the correct fix for this issue: we try menu files until we find one that works. This is not ideal but it's the only option we have.