GNOME Bugzilla – Bug 510358
XDG_DATA_DIRS is not set to /usr/share/gdm/applications if variable has been already exported
Last modified: 2008-02-22 15:46:53 UTC
Please describe the problem: Under Gentoo, XDG_DATA_DIRS is exported to /usr/share:/usr/kde/3.5/share:/usr/local/share for get KDE menu entries be shown in gnome-menu (because of the way kde is installed in gentoo) The problem is that seems that gdm doesn't add /usr/share/gdm/applications to XDG_DATA_DIRS if it's already exported You can see more in: http://bugs.gentoo.org/show_bug.cgi?id=204310 Steps to reproduce: 1. before gdm is launched XDG_DATA_DIRS is set 2. 3. Actual results: /usr/share/gdm/applications is not added to XDG_DATA_DIRS causing gdm menu entries not being shown Expected results: /usr/share/gdm/applications should be appended to XDG_DATA_DIRS Does this happen every time? Yes Other information: Thanks a lot
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 :'( I will ask in gentoo bugzilla
A gnome gentoo maintainer tried to copy paste this code into a separate executable and it also fails :-/ http://bugs.gentoo.org/show_bug.cgi?id=204310#c12 Sorry, but I cannot help more :'(
It seems to work okay for me on my non-Gentoo system. The Gentoo maintainer says: > 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. Unfortunately this doesn't really highlight what the problem is. I really need more assistance to help fix this. What, specifically, is causing the breakage?
I have tried also in Fedora and OpenSuSE, but I don't know how to export XDG_DATA_DIRS in these distributions. I have tried stopping already launched gdm and X login in a console and running: export XDG_DATA_DIRS="/home/pacho" /usr/sbin/gdm I expected to get, after login in my session, get a value like XDG_DATA_DIRS="/home/pacho:/usr/share/gdm" but, instead of that, I always get XDG_DATA_DIRS="/usr/share:/usr/local/share:/usr/share/gdm", seems that it simply ignores my export Do you know how could I export a wrong XDG_DATA_DIRS variable for checking if gdm appends "/usr/share/gdm" like should do ? Thanks a lot
Created attachment 104672 [details] [review] proposed patch I think I see the problem. The code is calling ve_clearenv before we check the XDG_DATA_DIRS. Could you try building GDM with this patch? If this fixes the problem, I'll get the fix upstream in the 2.20 branch. Note, I plan to do a 2.20.4 release soon because there are a few fairly important bug fixes in the 2.20 branch that aren't in the latest release. So it would be great if I could get confirmation that this fixes your issues.
It is still failling :-( Same problem
Did you make sure to run gdm-restart as root (or reboot) to restart the GDM daemon after building and installing with the patch? I don't see any other calls to clearenv () in the code, so I'm surprised. If it is still not working, then we need to track down where the environment variable is getting lost. One way you can do this would be to try the following: - Insert some gdm_debug in a few places. I'd recommend starting with: 1) at the beginning of main in gdm.c 2) just before the call to gdm_start_first_unboard_local in main in gdm.c 3) At the top of gdm_display_manage in display.c 4) At the slave entry point - the top of the function gdm_slave_start in slave.c 5) At the beginning of session_child_run in slave.c 6) Where we set old_system_data_dirs in session_child_run in slave.c I'd use this message, but I'd give each of the 6 tests a different "Test 3" so it is clear which is which in the debug output. ("Test #1 - The XDG_DATA_DIRS value is %s", XDG_DATA_DIRS" Then run "make" and "make install", then make sure debug is on in the GDM configuration, and run gdm-restart. Then set XDG_DATA_DIRS and run gdm. Then look in your syslog (/var/log/messages) and grep for the "The XDG_DATA_DIRS value is". This should help narrow down where the problem is happening. Obviously if you see the variable is getting lost between two messages, then you could try to further narrow down where the value is getting lost by adding more debug statements in between the last point it displayed properly and the point where it is lost.
(In reply to comment #8) > Did you make sure to run gdm-restart as root (or reboot) to restart the GDM > daemon after building and installing with the patch? I don't see any other > calls to clearenv () in the code, so I'm surprised. > Yes, I have restarted gdm and, after reading this, also rebooted, but still the same :-| > If it is still not working, then we need to track down where the environment > variable is getting lost. One way you can do this would be to try the > following: > > - Insert some gdm_debug in a few places. I'd recommend starting with: > I have tried, but gdm no longer compiles, I will attach the diff. display.c: In function 'gdm_display_manage': display.c:330: error: expected declaration specifiers before 'g_log' display.c:459: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token display.c:487: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token display.c:513: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token display.c:668: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token display.c:685: error: expected '{' at end of input make[2]: *** [display.o] Error 1 make[2]: *** Se espera a que terminen otras tareas.... gdm.c:142: error: expected declaration specifiers or '...' before '(' token gdm.c:142: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:142: error: expected declaration specifiers or '...' before string constant gdm.c:144: warning: return type defaults to 'int' gdm.c:144: warning: conflicting types for 'g_log' /usr/include/glib-2.0/glib/gmessages.h:96: warning: previous declaration of 'g_log' was here gdm.c: In function 'g_log': gdm.c:144: error: parameter 'stored_argv' is initialized gdm.c:145: error: parameter 'stored_argc' is initialized gdm.c:147: error: storage class specified for parameter 'main_loop' gdm.c:147: error: parameter 'main_loop' is initialized gdm.c:148: error: storage class specified for parameter 'config_file' gdm.c:148: error: parameter 'config_file' is initialized gdm.c:149: error: storage class specified for parameter 'gdm_restart_mode' gdm.c:149: error: parameter 'gdm_restart_mode' is initialized gdm.c:150: error: storage class specified for parameter 'monte_carlo_sqrt2' gdm.c:150: error: parameter 'monte_carlo_sqrt2' is initialized gdm.c:159: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token gdm.c:182: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token gdm.c:237: error: expected declaration specifiers or '...' before '(' token gdm.c:237: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:237: error: expected declaration specifiers or '...' before string constant gdm.c:238: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gdm_start_first_unborn_local' gdm.c:294: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token ... gdm.c:1342: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token gdm.c:1398: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token gdm.c:1416: error: parameter 'options' is initialized gdm.c:1417: warning: braces around scalar initializer gdm.c:1417: warning: (near initialization for 'options') gdm.c:1417: warning: initialization from incompatible pointer type gdm.c:1417: warning: excess elements in scalar initializer gdm.c:1417: warning: (near initialization for 'options') ...
Created attachment 104730 [details] [review] 1.diff These are the changes
Sorry, the line to add is: gdm_debug ("Test #1 - The XDG_DATA_DIRS value is %s", XDG_DATA_DIRS); Remove the " from after the XDG_DATA_DIRS and it should compile. Sorry I didn't format it properly before.
Created attachment 104732 [details] [review] 2.diff Thanks a lot I now get these errors: display.c:327: error: expected declaration specifiers or '...' before '(' token display.c:327: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' display.c:327: error: expected declaration specifiers or '...' before string constant display.c:327: error: expected declaration specifiers or '...' before 'XDG_DATA_DIRS' display.c:327: warning: data definition has no type or storage class display.c:327: warning: type defaults to 'int' in declaration of 'g_log' display.c:327: error: conflicting types for 'g_log' /usr/include/glib-2.0/glib/gmessages.h:96: error: previous declaration of 'g_log' was here make[2]: *** [display.o] Error 1 make[2]: *** Se espera a que terminen otras tareas.... gdm.c:142: error: expected declaration specifiers or '...' before '(' token gdm.c:142: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:142: error: expected declaration specifiers or '...' before string constant gdm.c:142: error: expected declaration specifiers or '...' before 'XDG_DATA_DIRS' gdm.c:142: warning: data definition has no type or storage class gdm.c:142: warning: type defaults to 'int' in declaration of 'g_log' gdm.c:142: error: conflicting types for 'g_log' /usr/include/glib-2.0/glib/gmessages.h:96: error: previous declaration of 'g_log' was here gdm.c:237: error: expected declaration specifiers or '...' before '(' token gdm.c:237: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:237: error: expected declaration specifiers or '...' before string constant gdm.c:237: error: expected declaration specifiers or '...' before 'XDG_DATA_DIRS' gdm.c:237: error: conflicting types for 'g_log' gdm.c:142: error: previous declaration of 'g_log' was here gdm.c:239: warning: return type defaults to 'int' gdm.c:239: warning: no previous prototype for 'gdm_start_first_unborn_local' gdm.c: In function 'gdm_make_global_cookie': gdm.c:1495: warning: dereferencing type-punned pointer will break strict-aliasing rules gdm.c:1495: warning: dereferencing type-punned pointer will break strict-aliasing rules
Argh. I'm sorry, I'm obviously not thinking clearly, my brain-compiler isn't working so well. Try this: gdm_debug ("Test #1 - The XDG_DATA_DIRS value is %s", g_getenv (XDG_DATA_DIRS)); I'm pretty sure that's what is needed.
I get the same :-/
should be: gdm_debug ("Test #1 - The XDG_DATA_DIRS value is %s", g_getenv ("XDG_DATA_DIRS"));
Ah, thanks Ray. Sorry for that.
Created attachment 104981 [details] 3.diff I still get the same :-(
Looking at some of the gdm_debug statements, you aren't adding them in the functions. Look here: --- - +gdm_debug ("Test #3 - The XDG_DATA_DIRS value is %s", g_getenv ("XDG_DATA_DIRS")); gboolean gdm_display_manage (GdmDisplay *d) { --- So you have added the gdm_debug line before the function declaration. This is not valid. You should add the function call inside the function, after the variable declarations. In other words here: --- gboolean gdm_display_manage (GdmDisplay *d) { pid_t pid; int fds[2]; + +gdm_debug ("Test #3 - The XDG_DATA_DIRS value is %s", g_getenv if (!d) return FALSE; --- Test message #4 and #5 has a similar problem as above. Similarly, you insertion of test message #1 is in the global variable area, not inside the function main(). Note main starts around line 1518.
Created attachment 105020 [details] [review] 4.diff I get know the following error: gdm-daemon-config.c: In function 'load_xservers_group': gdm-daemon-config.c:1186: warning: unused variable 'vname_array' gdm-daemon-config.c: In function 'gdm_daemon_config_load_displays': gdm-daemon-config.c:1441: warning: unused variable 'res' gdm-daemon-config.c:1440: warning: unused variable 'j' gdm-daemon-config.c:1439: warning: unused variable 'new_group' gdm-daemon-config.c:1438: warning: unused variable 'value_list' gdm-daemon-config.c:1437: warning: unused variable 'name' gdm-daemon-config.c:1436: warning: unused variable 'display_value' gdm-daemon-config.c:1435: warning: unused variable 'value' gdm-daemon-config.c: At top level: gdm-daemon-config.c:1409: warning: 'have_display_for_number' defined but not used gdm.c:142: error: expected declaration specifiers or '...' before '(' token gdm.c:142: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:142: error: expected declaration specifiers or '...' before string constant gdm.c:142: error: expected declaration specifiers or '...' before 'g_getenv' gdm.c:142: warning: data definition has no type or storage class gdm.c:142: warning: type defaults to 'int' in declaration of 'g_log' gdm.c:142: error: conflicting types for 'g_log' /usr/include/glib-2.0/glib/gmessages.h:96: error: previous declaration of 'g_log' was here gdm.c:237: error: expected declaration specifiers or '...' before '(' token gdm.c:237: error: expected declaration specifiers or '...' before 'G_LOG_LEVEL_DEBUG' gdm.c:237: error: expected declaration specifiers or '...' before string constant gdm.c:237: error: expected declaration specifiers or '...' before 'g_getenv' gdm.c:237: error: conflicting types for 'g_log' gdm.c:142: error: previous declaration of 'g_log' was here gdm.c:239: warning: return type defaults to 'int' gdm.c:239: warning: no previous prototype for 'gdm_start_first_unborn_local' gdm.c: In function 'gdm_make_global_cookie': gdm.c:1495: warning: dereferencing type-punned pointer will break strict-aliasing rules gdm.c:1495: warning: dereferencing type-punned pointer will break strict-aliasing rules make[2]: *** [gdm.o] Error 1 make[2]: *** Se espera a que terminen otras tareas.... mv -f .deps/gdm-daemon-config.Tpo .deps/gdm-daemon-config.Po make[2]: se sale del directorio `/var/tmp/portage/gnome-base/gdm-2.20.3/work/gdm-2.20.3/daemon' make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio `/var/tmp/portage/gnome-base/gdm-2.20.3/work/gdm-2.20.3' make: *** [all] Error 2 Seems the same (or very similar :-( )
Sorry, I was using the wrong patch again Silly me! :-S
Created attachment 105021 [details] [review] 4.diff Compiles at least! I have restarted gdm for using debug but I only get this: Feb 12 11:12:29 belkin2 gdm[4165]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 11:12:29 belkin2 gdm[4165]: DEBUG: Test #3 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 11:12:29 belkin2 gdm[23987]: DEBUG: Test #4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share I don't find Tests 5 and 6. Test 1 was shown when I stopped gdm: ** (process:19056): DEBUG: Test #1 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share In all of them /usr/share/gdm/applications is missing :-(
Did you actually try to login to a user session while you were running GDM? If so, how did you log in? Did you type your username/password, are you using automatic or timed login, did you use the face browser? It should be impossible for a user session to get started withotu message #4 and #5 to be displayed. ---- It's a little odd that message #1 shows up when you exit. I suspect if you run gdm with the --nodaemon argument that this might cause it to display in different order. Reading over this bug report, I am a bit confused. --- In comment #1 you say: /usr/share/gdm/applications is not added to XDG_DATA_DIRS causing gdm menu entries not being shown However in comment #5 you say you run: export XDG_DATA_DIRS="/home/pacho" /usr/sbin/gdm I expected to get, after login in my session, get a value like XDG_DATA_DIRS="/home/pacho:/usr/share/gdm" but, instead of that, I always get XDG_DATA_DIRS="/usr/share:/usr/local/share:/usr/share/gdm", seems that it simply ignores my export ---- So, which is it? Is /usr/share/gdm/applications not being added, or is your initial export of XDG_DATA_DIRS which you set before running GDM being ignored? At any rate, based on your debug statements, it looks like GDM keeps track of the old value at least as far as message #4 in gdm_slave_start.
(In reply to comment #22) > Did you actually try to login to a user session while you were running GDM? Sorry, I didn't login to any user, now tests 5 and 6 are shown > It's a little odd that message #1 shows up when you exit. I suspect if you run > gdm with the --nodaemon argument that this might cause it to display in > different order. I am simply running "gdm" :-/ (after stopping previous process of course) > In comment #1 you say: > > /usr/share/gdm/applications is not added to XDG_DATA_DIRS causing gdm menu > entries not being shown Yes, this is the problem, seems that /usr/share/gdm/applications is not being appended to XDG_DATA_DIRS > > However in comment #5 you say you run: > > export XDG_DATA_DIRS="/home/pacho" > /usr/sbin/gdm > > I expected to get, after login in my session, get a value like > XDG_DATA_DIRS="/home/pacho:/usr/share/gdm" but, instead of that, I always get > XDG_DATA_DIRS="/usr/share:/usr/local/share:/usr/share/gdm", seems that it > simply ignores my export > This is because I also tested under Fedora and openSUSE for trying to exclude a Gentoo problem (my main system runs under Gentoo), and I saw that on these distributions simply my export is ignored :'(, then, I cannot find a way for trying to test it on these distros > So, which is it? Is /usr/share/gdm/applications not being added, or is your > initial export of XDG_DATA_DIRS which you set before running GDM being ignored? > The problem that I am suffering is /usr/share/gdm/applications not being added to XDG_DATA_DIRS (yes, reading again I didn't explained it too well, sorry :-( ) > At any rate, based on your debug statements, it looks like GDM keeps track of > the old value at least as far as message #4 in gdm_slave_start. > Yes, now that I have login into my account (simply typing my username and password and clicking return) seems that the variable is lost in Test 6: # grep -r XDG /var/log/messages Feb 12 21:32:41 belkin2 gdm[17031]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 21:32:41 belkin2 gdm[17031]: DEBUG: Test #3 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 21:32:41 belkin2 gdm[17032]: DEBUG: Test #4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 21:32:44 belkin2 gdm[17031]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 21:32:49 belkin2 gdm[17050]: DEBUG: Test #5 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 21:32:49 belkin2 gdm[17050]: DEBUG: Test #6 - The XDG_DATA_DIRS value is (null) Thanks a lot
Looking at your code, it seems you haven't applied the patch I propose in comment #6. Please test with that patch. Note this patch moves the setting of old_system_data_dirs to before the ve_clearenv() call. Also please move your call to print g_debug Test #6 to before the ve_clearenv call. I'd also add a g_debug message after the setting of new_system_data_dirs to see what it is being set to. Something like this: { char *new_system_data_dirs; new_system_data_dirs = g_build_path (":", old_system_data_dirs, DATADIR "/gdm/", NULL); g_debug ("Test #7 - new value is %s", new_system_data_dirs); g_setenv ("XDG_DATA_DIRS", new_system_data_dirs, TRUE); g_free (new_system_data_dirs); } Are you still seeing the problem with the patch in comment #6 applied? Brian
(In reply to comment #24) > Are you still seeing the problem with the patch in comment #6 applied? Yes, I forgot to apply it when started adding "gdm_debug" lines but, before that, I also tried patch in comment #6 with no success :-/ I am now trying to add test 7 and moving 6 One minute please
Created attachment 105090 [details] [review] 5.diff Now Test 6 works, but seems that Test 7 is not shown :-/
Try using gdm_debug instead of g_debug for Test #7. Yes, I understand that the patch in comment #6 didn't seem to work for you, but I'd like you to try again, if you don't mind. I think the code shouldn't work without that patch, and should work with it. Note if your gdm_debug lines show that we are actually setting new_system_data_dirs properly, and we are calling g_setenv with that value, then the problem is likely elsewhere. Note that when you login that the /etc/gdm/Xsession (or maybe /etc/X11/gdm/Xsession) script sources a few files like /etc/profile, /etc/xprofile, and $HOME/.profile. I don't suppose you are resetting the value to something in one of these files causing the value set by GDM to get stomped are you? Also check this script /etc/gdm/PreSession/Default
Created attachment 105092 [details] [review] 5.diff Also with "gdm_log" I can't find test 7: Feb 12 22:27:54 belkin2 gdm[3333]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:28:50 belkin2 gdm[3805]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:28:50 belkin2 gdm[3805]: DEBUG: Test #3 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:28:50 belkin2 gdm[3806]: DEBUG: Test #4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:28:53 belkin2 gdm[3805]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:29:00 belkin2 gdm[3825]: DEBUG: Test #5 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 12 22:29:00 belkin2 gdm[3825]: DEBUG: Test #6 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share
That's really odd. Looking at my code, there is no returns, gotos or if-blocks that would cause Test #7 to not get printed. Could you share with me your slave.c file as an attachment so I can take a look at it? Perhaps your distro patches the file in some odd way?
Reading gdm ebuild seems that it's not patched but I can attach it of course
Created attachment 105094 [details] slave.c This is the file
Very strange. you can see the code as well as I that there is nothing between test #6 and test #7 that should cause the code to avoid getting to test #7. Perhaps you could add some more gdm_debug print statements between these two tests to see what is happening. Try adding them at these points where I mark with ####HERE####: gdm_debug ("Test #6 - The XDG_DATA_DIRS value is %s", g_getenv ("XDG_DATA_DIRS")); ve_clearenv (); /* Prepare user session */ g_setenv ("XAUTHORITY", d->userauth, TRUE); g_setenv ("DISPLAY", d->name, TRUE); if (d->windowpath) g_setenv ("WINDOWPATH", d->windowpath, TRUE); g_setenv ("LOGNAME", pwent->pw_name, TRUE); g_setenv ("USER", pwent->pw_name, TRUE); g_setenv ("USERNAME", pwent->pw_name, TRUE); g_setenv ("HOME", home_dir, TRUE); #ifdef WITH_CONSOLE_KIT if (ck_session_cookie != NULL) { g_setenv ("XDG_SESSION_COOKIE", ck_session_cookie, TRUE); } #endif ####HERE#### g_setenv ("PWD", home_dir, TRUE); g_setenv ("GDMSESSION", session, TRUE); g_setenv ("DESKTOP_SESSION", session, TRUE); g_setenv ("SHELL", pwent->pw_shell, TRUE); if (d->type == TYPE_STATIC) { g_setenv ("GDM_XSERVER_LOCATION", "local", TRUE); } else if (d->type == TYPE_XDMCP) { g_setenv ("GDM_XSERVER_LOCATION", "xdmcp", TRUE); } else if (d->type == TYPE_FLEXI) { g_setenv ("GDM_XSERVER_LOCATION", "flexi", TRUE); } else if (d->type == TYPE_FLEXI_XNEST) { g_setenv ("GDM_XSERVER_LOCATION", "flexi-xnest", TRUE); } else if (d->type == TYPE_XDMCP_PROXY) { g_setenv ("GDM_XSERVER_LOCATION", "xdmcp-proxy", TRUE); } else { /* huh? */ g_setenv ("GDM_XSERVER_LOCATION", "unknown", TRUE); } ###HERE#### if (gnome_session != NULL) g_setenv ("GDM_GNOME_SESSION", gnome_session, TRUE); /* Special PATH for root */ if (pwent->pw_uid == 0) g_setenv ("PATH", gdm_daemon_config_get_value_string (GDM_KEY_ROOT_PATH), TRUE); else g_setenv ("PATH", gdm_daemon_config_get_value_string (GDM_KEY_PATH), TRUE); ###HERE#### /* * Install GDM desktop files to a non-default desktop file * location (/usr/share/gdm/applications) and GDM appends * this directory to the end of the XDG_DATA_DIR environment * variable. This way, GDM menu choices never appear if * using a different display manager. */ { char *new_system_data_dirs; new_system_data_dirs = g_build_path (":", old_system_data_dirs, DATADIR "/gdm/", NULL); gdm_debug ("Test #7 - new value is %s", new_system_data_dirs); g_setenv ("XDG_DATA_DIRS", new_system_data_dirs, TRUE); g_free (new_system_data_dirs); } ###HERE####
Created attachment 105145 [details] [review] 6.diff OK, now I get the following: Feb 13 15:12:46 belkin2 gdm[4155]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:12:46 belkin2 gdm[4155]: DEBUG: Test #3 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:12:46 belkin2 gdm[21416]: DEBUG: Test #4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:12:51 belkin2 gdm[4155]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:07 belkin2 gdm[22717]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:07 belkin2 gdm[22717]: DEBUG: Test #3 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:07 belkin2 gdm[22718]: DEBUG: Test #4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:10 belkin2 gdm[22717]: DEBUG: Test #2 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #5 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #6 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #6.1 - The XDG_DATA_DIRS value is (null) Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #6.2 - The XDG_DATA_DIRS value is (null) Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #6.3 - The XDG_DATA_DIRS value is (null) Feb 13 15:13:24 belkin2 gdm[26504]: DEBUG: Test #6.4 - The XDG_DATA_DIRS value is /usr/share:/usr/kde/3.5/share:/usr/local/share:/usr/share/gdm/ Thanks
It's pretty odd that Test message #7 isn't showing up for some reason. However, it seems that GDM is seeting XDG_DATA_DIRS correctly. In comment #27 I highlight that perhaps the session startup scripts might be stomping the value? Did you look into this? If that's not the problem, then I guess we should start putting echo statements into the /etc/gdm/Xsession start up script to track down where the value is getting changed.
At least found! :-D Seems that this is caused by /etc/gdm/Xsession, that is sourcing /etc/profile, look at first: echo "$0: Beginning session setup..." echo "Test #1 $XDG_DATA_DIRS" >> /tmp/log -> I have added this, still the value is ok # First read /etc/profile and .profile test -f /etc/profile && . /etc/profile echo "Test #2 $XDG_DATA_DIRS" >> /tmp/log -> HERE is the value lost But I don't know how could this problem be fixed :-/ Thanks (Sorry for the delay, but I have had no time at all in the last days for replying)
If the problem is introduced by the sourcing of /etc/profile, then this is a bug with your distro, and not with GDM. GDM is not responsible for your system's /etc/profile file. I would think /etc/profile should not stomp the setting of XDG_DATA_DIRS. It should either append or prepend whatever values it wants to the existing setting. For a workaround you can probably edit /etc/profile on your system and fix it to set the value properly. I'd file a bug with your distro about this issue. However, I think we need to fix GDM with the patch in comment #6 to make sure we don't lose any existing setting of XDG_DATA_DIRS, and then close this bug. Does this make sense?
Yes, seems reasonable apply this patch. I already sent a bug report in gentoo: http://bugs.gentoo.org/show_bug.cgi?id=204310 Anyway, Is impossible source /etc/profile before gdm appends its XDG_DATA_DIRS? The problem is that I don't know where could be XDG_DATA_DIRS exported instead :-/ I will post this problem in downstream bug report Thanks a lot
Does /etc/profile (or anything sourced by /etc/profile) set or change the value of XDG_DATA_DIRS? If so, could you share information about how it changes the value? If you have trouble tracking this down, perhaps add further debug statements to the /etc/profile file so that we can see what line of /etc/profile is causing the value to get lost.
Does /etc/profile (or anything sourced by /etc/profile) set or change the value of XDG_DATA_DIRS? If so, could you share information about how it changes the value? If you have trouble tracking this down, perhaps add further debug statements to the /etc/profile file so that we can see what line of /etc/profile is causing the value to get lost. Also, note /etc/profile on your system may source files in your $HOME directory. Try running this: grep "XDG_DATA_DIRS" $HOME/.* does that command show up anything? If so, you might be changing the value improperly. Note, when you update the value of XDG_DATA_DIRS, this is a good way: export XDG_DATA_DIRS="$XDG_DATA_DIRS:/my/new/value1:/my/new/value2" and this is a bad way: export XDG_DATA_DIRS="/my/new/value1:/my/new/value2" It should be obvious that resetting the value the 1st (good) way will retain the exsting values and append new values to the end, while the 2nd (bad) way stomps the old value and resets it to a new value.
(In reply to comment #39) > Does /etc/profile (or anything sourced by /etc/profile) set or change the value > of XDG_DATA_DIRS? If so, could you share information about how it changes the > value? > Yes, this is the exact line: XDG_DATA_DIRS="/usr/share:/usr/kde/3.5/share/:/usr/local/share" This is used for adding /usr/kde/3.5/share/ to default XDG_DATA_DIRS. Do you know other way for adding /usr/kde/3.5/share/ ? > > Note, when you update the value of XDG_DATA_DIRS, this is a good way: > > export XDG_DATA_DIRS="$XDG_DATA_DIRS:/my/new/value1:/my/new/value2" > I have tried also this, but, after modifying it, I only get: # echo $XDG_DATA_DIRS $XDG_DATA_DIRS:/usr/share:/usr/kde/3.5/share/:/usr/local/share And /usr/share/gdm/ is still missing > It should be obvious that resetting the value the 1st (good) way will retain > the exsting values and append new values to the end, while the 2nd (bad) way > stomps the old value and resets it to a new value. > The problem, I think, is that XDG_DATA_DIRS is exported before gdm is started, later, gdm appends /usr/share/gdm, but Xsession re-reads XDG_DATA_DIRS from /etc/profile Thanks
Does it work better if you put the export on a second line like this? XDG_DATA_DIRS="$XDG_DATA_DIRS:/usr/share:/usr/kde/3.5/share/:/usr/local/share" export XDG_DATA_DIRS does removing the quotes (") from the line make a difference?
(In reply to comment #41) > Does it work better if you put the export on a second line like this? > > XDG_DATA_DIRS="$XDG_DATA_DIRS:/usr/share:/usr/kde/3.5/share/:/usr/local/share" > export XDG_DATA_DIRS > > does removing the quotes (") from the line make a difference? > Both ways fix the problem :-O The only "problem" (but I don't know if it will cause any unexpected behavior) is that XDG_DATA_DIRS repeats sometimes the dirs: ~ $ echo $XDG_DATA_DIRS :/usr/share:/usr/kde/3.5/share/:/usr/local/share:/usr/share:/usr/kde/3.5/share/:/usr/local/share:/usr/share:/usr/kde/3.5/share/:/usr/local/share:/usr/share/gdm/:/usr/share:/usr/kde/3.5/share/:/usr/local/share:/usr/share:/usr/kde/3.5/share/:/usr/local/share But I finally get /usr/share/gdm also :-)
It is a little odd that there are so may duplicate entries in your XDG_DATA_DIRS after making this fix. It sort of seems like your /etc/profile might be getting sourced more than once. That might be worth looking into, or mentioning to Ubuntu. At any rate, I think we've concluded (after all this discussion) that the problem isn't with GDM at all, but with the /etc/profile script that Ubuntu ships. I'd update the bug report with them to explain the changes you made to /etc/profile to fix the problem. They really shouldn't be stomping the value in /etc/profile, but appending or prepending the values they want onto the list. I'll close this bug now, and you can take up this issue with them. In the meantime, you have a workaround by simply editing your /etc/profile to fix this problem as you have done.
OK, thanks a lot :-) Did you finally applied patch from comment #6?
Yes, the patch in comment #6 is in the GDM 2.20 branch. It will be included in the next GDM 2.20 release (2.20.4). I will probably release this around the same time as GDM 2.22 is released just to make sure people have the latest GDM fixes for the 2.22 cycle.