Description of problem: Setting XDG_DATA_DIRS to a list of paths that does not include "/usr/share" causes gtk+3.x apps to abort / segfault / crash. E.g: [shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist ; eom ) (eom:1888748): GLib-GIO-ERROR **: 14:28:47.952: No GSettings schemas are installed on the system [1] 1888748 trace trap (core dumped) ( export XDG_DATA_DIRS=/notexist ; eom; ) [shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist ; gvim -f ) (gvim:1888762): Gtk-WARNING **: 14:28:56.851: Could not find the icon 'document-open-ltr'. The 'hicolor' theme was not found either, perhaps you need to install it. You can get a copy from: http://icon-theme.freedesktop.org/releases (gvim:1888762): Gtk-WARNING **: 14:28:56.852: Could not load a pixbuf from /org/gtk/libgtk/icons/16x16/status/image-missing.png. This may indicate that pixbuf loaders or the mime database could not be found. ** Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3) Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/16x16/status/image-missing.png: Unrecognised image file format (gdk-pixbuf-error-quark, 3) Vim: Caught deadly signal ABRT Vim: Finished. [1] 1888762 abort (core dumped) ( export XDG_DATA_DIRS=/notexist ; gvim -f; ) [shlomif@telaviv1 ~]$ ( export XDG_DATA_DIRS=/notexist:/usr/share ; gvim -f ) it also happens in a mostly new user in icewm-over-startx. Version-Release number of selected component (if applicable): Cauldron. How reproducible: Steps to Reproduce: ( export XDG_DATA_DIRS=/notexist ; gvim -f )
Note that KDE's "gwenview" starts fine in that case, but doesn't display previews for directories/folders.
It's de facto standard to have at least /usr/local/share and /usr/share in $XDG_DATA_DIRS. Basically you're shooting yourself in the foot if you're not having /usr/share in it. So, the fix would be adding /usr/share to $XDG_DATA_DIRS. :P
(In reply to Jani Välimaa from comment #2) > It's de facto standard to have at least /usr/local/share and /usr/share in > $XDG_DATA_DIRS. Basically you're shooting yourself in the foot if you're not > having /usr/share in it. > > So, the fix would be adding /usr/share to $XDG_DATA_DIRS. :P I see. I don't mind adding it to my .bashrc/etc., but I don't recall needing to do it explicitly on mageia in the past. Did something change? Thanks!
Did you have it like this before? Meaning, it is a recent change in behaviour (regression)?
CC: (none) => olav
(In reply to Olav Vitters from comment #4) > Did you have it like this before? Meaning, it is a recent change in > behaviour (regression)? Yes, it is a regression. I recall that in the past, after I filled $XDG_DATA_DIRS with some paths, (not including "/usr/share") the gtk+ apps worked well enough as before. So it is a recent change in behaviour.
Well, on Mageia 7, without fiddling it at all: $ echo $XDG_DATA_DIRS /usr/share/gdm:/var/lib/menu-xdg:/home/lewis/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share Need to try this on Mageia 8. If 'out of the box' this path variable does include the necessary (comment 2), I would say this is not a bug. If it worked in the past, comment 5, could that have been just been by luck?
CC: (none) => lewyssmith
In Mageia 8 Cauldron (Beta1) Plasma, freshly installed. $ echo $XDG_DATA_DIRS return: /home/aurelien/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
CC: (none) => ouaurelien
I had forgotten to check M8; thanks for doing so. Thus it look as if 'out of the box', Mageia does include /usr/local/share & /usr/share in $XDG_DATA_DIRS. @Shlomi : can you say how you created an installation that did not? In your original comment, to make the point, you explicitly set XDG_DATA_DIRS not to have the share paths; which does not count. You also cite: > it also happens in a mostly new user in icewm-over-startx which is cryptic. A bug would be if a standard Mageia installation got it wrong; for which the exact circumstance needs stating, please.
Seems like it is fine now in a new user as well as my main one: kdetest@telaviv1:~ # echo $XDG_DATA_DIRS /home/kdetest/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share I'm closing this ticket for now - thanks all for your help.
Status: NEW => RESOLVEDResolution: (none) => FIXED