| Summary: | gnome-base/gdm-2.20.*: menu entries (.desktop) files are being installed in unproper place | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Pacho Ramos <pacho> |
| Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | micheleschi, reavertm |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://bugzilla.gnome.org/show_bug.cgi?id=510358 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 264647 | ||
| Bug Blocks: | |||
| Attachments: | Xsession.diff | ||
|
Description
Pacho Ramos
2008-01-04 19:28:27 UTC
From Changelog: 2007-05-14 Brian Cameron <brian.cameron@sun.com> * daemon/slave.c, gui/Makefile.am: Now install GDM desktop files to /usr/share/gdm/applications and append this directory to XDG_DATA_DIR before starting the user session, so that these desktop files are only visible if using the GDM program as the display manager. This will ensure these menu options do not appear when using other display managers such as KDM or CDE login. Fixes bug #434813. But seems that it isn't being exported :-/ strange because I still see gdmflexiserver.desktop, gdmflexiserver-xnest.desktop and gdmsetup.desktop in my menus (maybe I've hidden the gdmphotosetup one). I changed my menu layout but didn't mess with variables. Could somebody else comment here ? I get the same problem also from amd64 :-/ I just checked on a brand new amd64 install besides the work box and on x86 and I definitively get the path added to XDG_DATA_DIRS. Here is how it looks here: $ env |egrep XDG XDG_SESSION_COOKIE=7de5ae80b19a2715ae393300457c3e00-1200470429.485326-1960207559 XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/share/gdm/ I have xdg-utils-1.0.2 installed but I doubt it changes anything. Other than that, I've tested gdm-2.20.2 and 2.20.3 and it works with these. what are you guys using ? Does it work on a fresh account ? (In reply to comment #4) > I definitively get the path added to XDG_DATA_DIRS. Here is how it looks here: > > $ env |egrep XDG > XDG_SESSION_COOKIE=7de5ae80b19a2715ae393300457c3e00-1200470429.485326-1960207559 > XDG_DATA_DIRS=/usr/local/share/:/usr/share/:/usr/share/gdm/ > Me not :-/ I only get: XDG_DATA_DIRS=/usr/share:/usr/kde/3.5/share:/usr/local/share Also with a new created user with all gdm-2.20* Seems that you don't have kde-base/kdelibs-3.5.7-r3 installed. It adds /etc/env.d/45kdepaths file that exports XDG_DATA_DIRS="/usr/share:/usr/kde/3.5/share:/usr/local/share" /usr/kde/3.5/share is needed for being able to see a lot of kde apps menu entry from gnome-menu. Maybe gdm should also export /usr/share/gdm/applications with an env.d file :-/ I also have xdg-utils-1.0.2 maybe it's not being set because you're environment already sets an XDG_DATA_DIRS variable. What happens if you comment it out in the env.d file, update-env and restart gdm ? It works, but, then, I miss a lot of KDE apps to be shown in gnome-menu :-/ (In reply to comment #7) > It works, but, then, I miss a lot of KDE apps to be shown in gnome-menu :-/ > could you open a bug upstream, I'd like to get their opinion on this stuff. The workaround is easy but it defeats the purpose of what upstream did. From upstream bug report: Comment #1 from Brian Cameron (gdm developer, points: 21) 2008-01-18 21:17 UTC [reply] Look in session_child_run in daemon/slave.c: old_system_data_dirs = g_getenv ("XDG_DATA_DIRS") ? g_getenv ("XDG_DATA_DIRS") : "/usr/local/share/:/usr/share/"; new_system_data_dirs = g_build_path (":", old_system_data_dirs, DATADIR "/gdm/", NULL); g_setenv ("XDG_DATA_DIRS", new_system_data_dirs, TRUE); That code looks like it should get the existing value via g_getenv, and only append DATADIR/gdm to the end. If you see something wrong here, feel free to provide a patch. ________ The problem is that I am not a programmer :-(, Can somebody check it? Thanks a lot same problem (In reply to comment #11) > same problem these kind of comments don't help solving the bug, thanks for understanding. I've tested this on a fresh install with gnome-2.20.3 ebuilds and it appears that the behavior is indeed broken. I copy/pasted the code to make it into a separate executable to test the logic and it _should_ work but it appears something is wrong anyway. My test involved creating a /etc/env.d/50test file which contained: XDG_DATA_DIRS="/usr/share/applications" (maybe /usr/share is the correct value though) and then on login, I would have lost 99% of the menu items. Obviously, gdm items wouldn't show up as well. any news from upstream ? No one, I have just posted with your check :-| Upstream says that it works ok on his non-gentoo system, he asks:
> What, specifically, is causing the breakage?
But I don't know what should I reply :-/
Seems that the problem is caused because /etc/gdm/Xsession sources /etc/profile dropping new generated XDG_DATA_DIRS (better explained in http://bugzilla.gnome.org/show_bug.cgi?id=510358#c35 ) Upstream thinks that this is a gentoo problem: http://bugzilla.gnome.org/show_bug.cgi?id=510358#c36 The problem is that I don't know other way for exporting XDG_DATA_DIRS :-| Seems that it is not an upstream bug, the problem can be fixed exporting this in /etc/profile: XDG_DATA_DIRS=$XDG_DATA_DIRS:/usr/share:/usr/kde/3.5/share/:/usr/local/share The problem is that XDG_DATA_DIRS *must* be exported WITHOUT quotation marks, but env-update doesn't respect this (I will open a bug report) and always add "'" causing it to not be exported properly I have checked manually editing /etc/profile.env file (only for checking) and it FIXES this bug :-) (well, dirs are duplicated because seems that /etc/profile is being sourced more than one time, but this is a tiny problem that won't produce any problem, I think) You *cannot* use FOO="${BAR}:/something/else" for env.d stuff, see Bug 126231.
(In reply to comment #19) > You *cannot* use FOO="${BAR}:/something/else" for env.d stuff, see Bug 126231. > Isn't there any other place where export this ? Thanks 1/ The place is wrong. The desktop entries should have OnlyShowIn=GNOME; defined instead. 2/ You do not need any such thing, just create another entry in /etc/env.d and define XDG_DATA_DIRS="/usr/share/gdm/applications" there is you really insist on doing it wrong, the variables are additive. (In reply to comment #12) > My test involved creating a /etc/env.d/50test file which contained: > XDG_DATA_DIRS="/usr/share/applications" (maybe /usr/share is the correct value > though) and then on login, I would have lost 99% of the menu items. Obviously, > gdm items wouldn't show up as well. # env | grep XDG XDG_DATA_DIRS=/usr/share:/usr/kde/3.5/share:/usr/local/share # echo XDG_DATA_DIRS=/usr/share/gdm > /etc/env.d/50test; env-update; source /etc/profile; env | grep XDG >>> Regenerating /etc/ld.so.cache... XDG_DATA_DIRS=/usr/share:/usr/kde/3.5/share:/usr/local/share:/usr/share/gdm If you've lost 99% of menu entries after doing this, then Gnome totally sucks. :P (In reply to comment #21) > 1/ The place is wrong. The desktop entries should have OnlyShowIn=GNOME; > defined instead. > This cannot be used because the expected behavior is show these entries when GDM is being used (under gnome and under KDE) > 2/ You do not need any such thing, just create another entry in /etc/env.d and > define XDG_DATA_DIRS="/usr/share/gdm/applications" there is you really insist > on doing it wrong, the variables are additive. > This cannot also be used because menu entries would be shown always, not only when GDM is being used :-/ I really fail to see why a desktop entry should only be shown when using gdm, doesn't make absolutely any sense to me... Anyway, if gdm gets messed up on quoted variables and can't append stuff to those, then it's plain broken. http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=5#doc_chap2_sect1 (In reply to comment #24) > I really fail to see why a desktop entry should only be shown when using gdm, > doesn't make absolutely any sense to me... This is needed because these menu entries will only work if GDM is being used > Anyway, if gdm gets messed up on > quoted variables and can't append stuff to those, then it's plain broken. > The variable is being appended (please check upstream bug report http://bugzilla.gnome.org/show_bug.cgi?id=510358 ), but Gentoo is forcing a XDG_DATA_DIRS in /etc/profile (through /etc/env.d/45kdepaths) because it is needed for being able to see kde menu entries under gnome (because of the place where KDE is being installed in gentoo) (In reply to comment #25) > but Gentoo is forcing a > XDG_DATA_DIRS in /etc/profile (through /etc/env.d/45kdepaths) because it is > needed for being able to see kde menu entries under gnome (because of the place > where KDE is being installed in gentoo) Yeah, so what? gdm should append to whatever the current value is this and move on. If it can't coexist with environment defined in /etc/profile then how is this a Gentoo problem? (In reply to comment #26) > Yeah, so what? gdm should append to whatever the current value is this and move > on. If it can't coexist with environment defined in /etc/profile then how is > this a Gentoo problem? > This is a Gentoo problem because gentoo is forcing a strict value for XDG_DATA_DIRS instead of add $XDG_DATA_DIRS allowing gdm to properly add the new dir But I think that there is another possible solution that wouldn't need touch anything in /etc/env.d , please just a few minutes for testing Thanks (In reply to comment #27) > This is a Gentoo problem because gentoo is forcing a strict value for > XDG_DATA_DIRS instead of add $XDG_DATA_DIRS allowing gdm to properly add the > new dir It's not forcing anything; it's defining sane defaults as required. This is the same nonsense like if you complained that we set a default PATH. *Anything* can append to those. On another note, I'd suggest you create yourself a new user account and test with that one, since the behaviour you describe looks pretty much impossible on a sane setup. /etc/X11/startDM.sh sources /etc/profile and *after* that it runs the login manager. If you get your /etc/profile sources multiple times after gdm actually started, then it's a problem with your local configuration. Created attachment 144328 [details, diff]
Xsession.diff
The problem is caused by /etc/X11/gdm/Xsession, that is sourcing /etc/profile
This workaround fixes the issue
(In reply to comment #28) > (In reply to comment #27) > > This is a Gentoo problem because gentoo is forcing a strict value for > > XDG_DATA_DIRS instead of add $XDG_DATA_DIRS allowing gdm to properly add the > > new dir > > It's not forcing anything; it's defining sane defaults as required. This is the > same nonsense like if you complained that we set a default PATH. *Anything* can > append to those. > > On another note, I'd suggest you create yourself a new user account and test > with that one, since the behaviour you describe looks pretty much impossible on > a sane setup. /etc/X11/startDM.sh sources /etc/profile and *after* that it runs > the login manager. If you get your /etc/profile sources multiple times after > gdm actually started, then it's a problem with your local configuration. > I already replied to this question in http://bugs.gentoo.org/show_bug.cgi?id=204310#c5 I have tried with a new created user account Would you guys please stop the chitchat. Thanks. The problem is now identified and we (gnome herd) are going to try and fix it. Thanks for all the investigation you did. (In reply to comment #29) > The problem is caused by /etc/X11/gdm/Xsession, that is sourcing /etc/profile Eh... Why's it sourcing all that profile stuff at all? There's no need to actually mess with the variable if it's already defined in your env. If you really want to check whether gdm does what's it supposed to do (i.e., append to existing XDG_DATA_DIRS), then you need something like this: <snip> if test "x$XDG_DATA_DIRS" = "x" then XDG_DATA_DIRS="/usr/local/share:/usr/share:/usr/share/gdm" export XDG_DATA_DIRS fi </snip> Get around to test the supposed fix and it appears it doesn't fix the issue at all. The file comes from upstream's tarball (probably an old copy though) but the profile sourcing is still there anyway. I don't see why gdm should be "smart" in setting the variable in the C code if the script just stomps on it by default. Bug 264647 should solve this issue. since gdm-2.20.10 makes uses of changes in bug #264647, I thinkg we can close this bug. |