Bug 25361

@Luis
Thank you for your very helpful report and diagnostic.
(But this does not merit 'critical' severity; you can live without Alacarte).
Can you please add what Mageia ISO you installed from, and/or what desktop you are using. This is a Gnome thing, but perhaps not exclusive to it.

No registered maintainer for this package, so assigning to the Gnome people; CC'ing Olav because you seen this several times before.

Assignee: bugsquad => gnome
Severity: critical => normal
CC: (none) => olav

(In reply to Lewis Smith from comment #1)
> Thank you for your very helpful report and diagnostic.
> (But this does not merit 'critical' severity; you can live without Alacarte).

You're confusing "priority" and "severity". The severity field is for the impact on the end user. "critical" is for bugs that have the most impact: crashers, or ones that cause some data loss. This bug is a systematic crasher, so on an end-user and Alacarte maintainer point of view, this is critical.

Of course I can live without Alacarte, haven't run it for years before last week (and will probably won't for a few more years). But we're not the ones who are supposed to say the user wether what they're doing is useful or not.

> Can you please add what Mageia ISO you installed from, and/or what desktop
> you are using. This is a Gnome thing, but perhaps not exclusive to it.

I did an online upgrade from Mageia 6 to Mageia 7, following the instructions on the mageia wiki. I also checked that asking for an update would tell me that no more updates are available.

> No registered maintainer for this package, so assigning to the Gnome people;
> CC'ing Olav because you seen this several times before.

I mostly reported that bug because XDG_CONFIG_DIRS not being set correctly might have an impact on other GNOME software relying on it. I don't know if Alacarte is the only one or if others look at XDG_CONFIG_DIRS, maybe Olav would know ?

I confirm this bug on a fresh install of Mageia 7 GNOME.

CC: (none) => cyril.levet0780

Bug 26633 duplicates this one.

CC: (none) => lewyssmith

 https://bugs.mageia.org/show_bug.cgi?id=12153#c3
 https://bugs.mageia.org/show_bug.cgi?id=26633#c0
indicate that "symlinking /etc/xdg/gnome/menus/gnome-applications.menu to /etc/xdg/menus/" fixes this.

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

This bug is still valid in Mageia 8.

*** Bug 32902 has been marked as a duplicate of this bug. ***

CC: (none) => eduardomestresaez

It works here on my Cauldron with alacarte-3.50.0.

CC: (none) => geiger.david68210

Thank you for poking this, David.

on M9 LXDE:
 alacarte-3.44.2-1.mga9
installed it, fired it up, it does not crash; its GUI looks correct.
OTOH it does throw errors:
 $ alacarte

(alacarte:16955): Gtk-CRITICAL **: 21:21:21.376: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed

(alacarte:16955): Gtk-CRITICAL **: 21:21:21.376: gtk_accel_label_set_accel_closure: assertion 'gtk_accel_group_from_accel_closure (accel_closure) != NULL' faile

If somebody else can confirm that this application works for M9 (dead easy to install and start), it looks like the Mageia 9 version works, and this old bug can be closed FIXED.

<pre>[eduardo@ideafix ~]$ cat /etc/mageia-release 
Mageia release 9 (Official) for x86_64
[eduardo@ideafix ~]$ rpm -q alacarte
alacarte-3.44.2-1.mga9
[eduardo@ideafix ~]$ alacarte

(alacarte:35988): Gtk-<span style="color:#A347BA"><b>CRITICAL</b></span> **: <span style="color:#12488B">21:53:28.638</span>: gtk_accel_label_set_accel_closure: assertion &apos;gtk_accel_group_from_accel_closure (accel_closure) != NULL&apos; failed

(alacarte:35988): Gtk-<span style="color:#A347BA"><b>CRITICAL</b></span> **: <span style="color:#12488B">21:53:28.639</span>: gtk_accel_label_set_accel_closure: assertion &apos;gtk_accel_group_from_accel_closure (accel_closure) != NULL&apos; failed
Traceback (most recent call last):
  File &quot;/usr/bin/alacarte&quot;, line 24, in &lt;module&gt;
    main()
  File &quot;/usr/lib/python3.10/site-packages/Alacarte/MainWindow.py&quot;, line 464, in main
    app.setMenuBasename(basename)
  File &quot;/usr/lib/python3.10/site-packages/Alacarte/MainWindow.py&quot;, line 62, in setMenuBasename
    self.editor = MenuEditor(menu_basename)
  File &quot;/usr/lib/python3.10/site-packages/Alacarte/MenuEditor.py&quot;, line 36, in __init__
    self.load()
  File &quot;/usr/lib/python3.10/site-packages/Alacarte/MenuEditor.py&quot;, line 49, in load
    if not self.tree.load_sync():
gi.repository.GLib.GError: g-io-error-quark: Failed to look up menu_file for &quot;gnome-applications.menu&quot;
 (0)
[eduardo@ideafix ~]$</pre>

This is on Mageia 9 with Gnome over Wayland. In Mageia 9 LXDE over X11 works OK. 

I think it's a Wayland related issue.

As it is a Wayland related issue this could be reported upstream at https://gitlab.gnome.org/GNOME/alacarte/-/issues

Summary: Alacarte crashes at startup => Alacarte crashes at startup only on Wayland

This is not a wayland issue, Eduardo tested with a whole different desktop (LXDE). If you test with a GNOME X11 session you have the same error.

I tested with alacarte-3.44.2-1.mga9.

(In reply to Eduardo Mestre from comment #11)
> 
> This is on Mageia 9 with Gnome over Wayland. In Mageia 9 LXDE over X11 works
> OK. 
> 
> I think it's a Wayland related issue.

I read this from Eduardo!

Sure, I'm just saying testing a GNOME bug on LXDE won't give you a relevant result. The issue is that alacarte can't find the `gnome_applications.menu` file.

Proof of that:

> strace -fff alacarte 2>&1 | grep menu
> [...]
> [pid  8964] readlink("/home/luis/.config/menus", 0x7ffceb550c60, 1023) = -1 EINVAL (Argument invalide)
> [pid  8964] readlink("/home/luis/.config/menus/gnome-applications.menu", 0x7ffceb550c60, 1023) = -1 ENOENT (Aucun fichier ou dossier de ce type)
> [pid  8964] readlink("/etc/xdg/menus", 0x7ffceb550c60, 1023) = -1 EINVAL (Argument invalide)
> [pid  8964] readlink("/etc/xdg/menus/gnome-applications.menu", 0x7ffceb550c60, 1023) = -1 ENOENT (Aucun fichier ou dossier de ce type)
> [pid  8964] write(2, "    self.editor = MenuEditor(men"..., 44    self.editor = MenuEditor(menu_basename)
> [pid  8964] write(2, "gi.repository.GLib.GError: g-io-"..., 107gi.repository.GLib.GError: g-io-error-quark: Failed to look up menu_file for "gnome-applications.menu"

It's looking at:
- /etc/xdg/menus
- /etc/xdg/menus/gnome-applications.menu

But it needs to find (mind the "gnome" dir in the path):
- /etc/xdg/gnome/menus/gnome-applications.menu

This is why in Comment #5 we're told that a symlink fixes the problem.
Another way might be to use XDG_CONFIG_DIRS, but I don't know what's the prefered way.

> man alacarte
>
> ENVIRONMENT
>       XDG_CONFIG_DIRS
>           alacarte looks in the menus subdirectory of these directories for menu files. The default location for menu files is /etc/xdg/menus.

Running this in a terminal works for me:
> XDG_CONFIG_DIRS=/etc/xdg/gnome alacarte

Could someone with an LXDE session paste the result of the following command here? I'm running low on disk space. Thanks.

> env | grep XDG

FWIW, it's also crashing in the IceWM session, so LXDE seems to be an outlier.

To settle the dust, I have just painfully tried this as follows:
Cinnamon, IceWM, LXDE, LxQt, Mate, Plasma X11, Xfce:
 2 GTK errors, but it starts OK.
Gnome (Wayland), Gnome (Xorg):
 errors as comment 11, does not start.

This does not accord with comment 18, but I am sure this *is* a Gnome problem.
For each desktop, I scanned ENV for - curses - 'ayland' or 'X11'; it should be 'x11' which is what I see here on Xfce:
 $ env | grep XDG
 XDG_SESSION_TYPE=x11
 XDG_CONFIG_DIRS=/etc/xdg

Sigh, will try again both Gnome variants.

Here under straight 'Gnome' from LightDM, which - surprise - is running X11:
 $ env | grep XDG
 XDG_SESSION_TYPE=x11
 XDG_CONFIG_DIRS=/etc/xdg/mate:/etc/xdg
and fails as noted above.

Blast, need to try another display Manager to get Wayland.

Back again, GDM to straight 'Gnome'; this time under Wayland:
 $ env | grep XDG
 XDG_SESSION_TYPE=wayland           at last      
note *no* XDG_CONFIG_DIRS.
It fails as per comment 11, does not start.

Next to try Gnome X11 ex GDM.

Here finally from GDM to Gnome on X11:
 XDG_SESSION_TYPE=x11
and again, *no XDG_CONFIG_DIRS*.

(In reply to Luis Menina from comment #18)
> FWIW, it's also crashing in the IceWM session
Can you check this variable, $ env | grep XDG

It may be that the crash comes just from this ENV variable XDG_CONFIG_DIRS not being set.

> It may be that the crash comes just from this ENV variable XDG_CONFIG_DIRS not being set.

The crash comes from the .menu file not being found. Now the question is: are we supposed to change the filesystem layout adding symlinks so that the file is found using alacarte's default configured paths? Because otherwise, all sessions would need to have XDG_CONFIG_DIR set to have alacarte not crash. The problem with the latter is that as it's an XDG setting, it may interact with other xdg-compatible applications (breaking them).

This is what is at the beginning of the `/etc/gnome/gnomerc` file.

> if [ "$MGA_MENU_STYLE" = "upstream" ]; then
> 	if  [ -z "$XDG_CONFIG_DIRS" ]; then
>  	    export XDG_CONFIG_DIRS="/etc/xdg/gnome:/etc/xdg"
> 	else
> 	    export XDG_CONFIG_DIRS="/etc/xdg/gnome:$XDG_CONFIG_DIRS"
> 	fi
> else
> 	if  [ -z "$XDG_CONFIG_DIRS" ]; then
>  	    export XDG_CONFIG_DIRS="/etc/xdg:/etc/xdg/gnome"
> 	else
> 	    export XDG_CONFIG_DIRS="$XDG_CONFIG_DIRS:/etc/xdg/gnome"
> 	fi
> fi

So if XDG_CONFIG_DIRS is not defined, it's supposed to define it. However it's been a long time (I found this bug almost 5 years ago on Mageia 7) and I don't know with the way the session changed in all those years if this file should be sourced somewhere. Grepping in the /etc dir, though, seems to indicate that nothing loads that file.

$ cat /usr/bin/startgnome
#!/usr/bin/sh
if [ -x ~/.gnomerc ]; then 
 exec ~/.gnomerc
else
 exec /etc/gnome/gnomerc
fi

CC: (none) => davidwhodgins

Isn't startgnome a relic of the past? I mean, it might be provided for backards compatibility with old systems, but AFAIK, this is has been superseded by systemd handling the session ages ago.

Possibly. I normally use run level 3 and startx.