Seems that menu entries are being installed in /usr/share/gdm/applications instead of /usr/share/applications, causing them to not be shown in gnome menu: $ ls -l /usr/share/gdm/applications/ total 16 -rw-r--r-- 1 root root 439 dic 28 23:51 gdmflexiserver.desktop -rw-r--r-- 1 root root 504 dic 28 23:51 gdmflexiserver-xnest.desktop -rw-r--r-- 1 root root 564 dic 28 23:51 gdmphotosetup.desktop -rw-r--r-- 1 root root 470 dic 28 23:51 gdmsetup.desktop Portage 2.1.3.19 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-tuxonice-r5 i686) ================================================================= System uname: 2.6.23-tuxonice-r5 i686 Genuine Intel(R) CPU T2300 @ 1.66GHz Timestamp of tree: Fri, 04 Jan 2008 15:46:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r6 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.10-r5 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium-m -mfpmath=sse -msse3" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium-m -mfpmath=sse -msse3" DISTDIR="/usr/distfiles" FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.ovh.net/gentoo-distfiles/ " LANG="es_ES.UTF-8" LC_ALL="es_ES.UTF-8" LINGUAS="es es_ES en_US" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi aim alsa ape asf audiofile avahi avi bash-completion bcmath beagle bitmap-fonts bonobo bzip2 bzlib cairo caps cdb cddb cdparanoia cdr cdrparanoia cli cpdflib cracklib cross crypt css cups curl curlwrappers daap dbus divx4linux djvu dts dv dvb dvd dvdr dvdread dvi eds emerald encode escreen evo exif fam fbcon fbsplash ffmpeg firefox flac foomaticdb fortran ftp galago gb gcj gd gif gimp gimpprint glitz glut glx gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal hddtemp iconv imagemagick imlib ipv6 isdnlog jabber jack java jikes jpeg kde kdeenablefinal kdehiddenvisibility latex lcms lesstif libnotify lm_sensors logrotate mac mad mbox midi mikmod mime ming mmap mmx mmxext mng modplug mono motif mp3 mpeg mpi mplayer mudflap musepack musicbrainz nas ncurses nethack nls nocd nptl nptlonly nsplugin ntfs nvidia ogg oggvorbis openal opengl openmp opnegl pam pcmcia pcre pdf pdflib perl pic png pnp posix ppds pppd python qt qt3 qt4 quicktime readline real reflection reiserfs rpm rtc ruby scanner sdl seamonkey session slang slp smp sndfile sockets socks5 speex spell spl sse sse2 sse3 ssl startup-notification svg syslog tcltk tcpd tetex tga theora threads tiff timidity tk truetype truetype-fonts trusted type1-fonts unicode usb userlocales v4l v4l2 vcd videos vim vorbis wifi win32codecs wma wmf wxwindows x86 xattr xcomposite xine xml xorg xpm xv xvid zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" DVB_CARDS=" " ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="es es_ES en_US" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa fbdev" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS Reproducible: Always
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.
Done: http://bugzilla.gnome.org/show_bug.cgi?id=510358
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.
