This sounds really odd to me.  Are you sure it isn't already the default value?  Note that GDM saves your user's default setting in $HOME/.dmrc.  Try removing this file and then changing the setting and see if the pop-up appears.

Does it only fail to show the dialog asking if you want it to be the default when you pick KDE or does it also fail when you pick other sessions?  If you pick a different default and then go back to KDE does it ask?

Note that GDM doesn't ask you whether you want it to be your default until after you actually authenticate and just before it actually starts up your session.  So don't expect it to ask you to change the default immediately when you pick the setting in the sessions menu.

Any update?  I will close this bug if more information isn't provided.  I don't see this problem.

The bug still happens using 2.19.5 on my gutsy installation, I've choosed wmaker in the session list, entered my username and password and gdm didn't ask if that should be made the default. There is no .dmrc in the user directory

Thanks for responding.  Does it make a difference if you set RelaxPermissions to a higher level, such as 2?  GDM has some logic where it will not read/write to the user's $HOME directory if the permissions or ownership aren't what GDM considers sane.  You may need to set RelaxPermissions to let GDM know you want to not be so strict (or fix the permission/owernship issues).

It might help if you were able to share debug information, especially if the problem is with RelaxPermissions.  Turn on debug in your configuration, restart GDM with gdm-restart, and share the gdm related debug messages from the end of your syslog after you do a login.

Changing the RelaxPermissions doesn't make a difference and the permissions are set correctly I think. The debug log has nothing special out of the assertions mentionned on bug #451989

"gdm[12466]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
gdm[12466]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
gdm[12466]: GLib-CRITICAL: g_key_file_free: assertion `key_file != NULL' failed"

When selecting window maker gdm doesn't ask if the default session should be changed. When choosing a different language the dialog is displayed but no dmrc is written and there is nothing which look revelant in the log

I'm a bit confused about your "debug log".  The above GLib-Critical messages are not syslog messages but messages that are echoed to the terminal when you run the program.  If you turn on debug in GDM, it should spit out a *lot* (hundreds of lines) of debug output to your syslog (/var/log/messages or /var/adm/messages).  Are you sure there is nothing interesting in those log files.

If the GDM debug isn't providing us with any interesting information, then I'm completely at a loss as to why this would be failing for you.  I've not heard any non-Gutsy users complain about this problem, so it might be something unique with your environment.  You might need to add some gdm_debug messages to the code and see if you can track down why the failure is happening.

Note in gdm_slave_session_start it has this code:

        if G_LIKELY (home_dir_ok) {
                /* Sanity check on ~user/.dmrc */
                usrcfgok = gdm_file_check ("gdm_slave_session_start", 
                                           pwent->pw_uid,
                                           home_dir, ".dmrc", TRUE, FALSE,
                                           gdm_daemon_config_get_value_int 
                                           (GDM_KEY_USER_MAX_FILE),
                                           gdm_daemon_config_get_value_int 
                                          (GDM_KEY_RELAX_PERM));
        } else {
                usrcfgok = FALSE;
        }

Note it will only write the .dmrc file if the gdm_file_check function (in daemon/filecheck.c) passes okay.  Note gdm_file_check also sends output to the syslog on failure, so if it is failing it should already be echoing debug messages.

Or perhaps the problem is in gdm-daemon-config.c in a function like gdm_daemon_config_set_user_session_lang or gdm_daemon_config_get_user_session_lang.  This might be more likely since these functions aren't sending debug messages, though the code looks okay to me. 

Perhaps home_dir isn't set properly in your environment causing the .dmrc file check to fail?  That would be odd.

Could you look into this a bit?  I can't reproduce this problem, so I need help from someone who can see it.

gdm_daemon_config_set_user_session_lang() returns NULL for the session and the language, the warning mentionned before seem to have something to do with it

"gdm[4391]: DEBUG: Attempting to parse key string: Desktop/Session 
gdm[4391]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed 
gdm[4391]: DEBUG: Attempting to parse key string: Desktop/Language 
GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
GLib-CRITICAL: g_key_file_free: assertion `key_file != NULL' failed"

Could you add some debug to the gdm_daemon_config_set_user_session_lang?

It would be useful to know what values are being passed in as save_session and save_lang.  It would also be useful to know what cfgstr is set to after the g_build_filname call.

Looking at the warning it seems that the value we are passing into the first argument of g_key_file_set_string is somehow NULL.  This seems odd to me since in gdm_daemon_config_set_user_session_lang we call gdm_common_config_load and verify the value is not NULL before go ahead and try to call the g_key* functions to actually try and save the value.

Or do you mean the function gdm_daemon_config_get_user_session_lang() function?  
If so, I'd be interested to know what the cfg value is set to after the g_build_filename call.  I'm guessing you might be referring to this function since you say that the function "returns NULL for the session and the language and the getter function does this.  Also, this function isn't so careful about checking to see if the cfg value isn't NULL.

I note the code is freeing the cfgfile variable right after setting the cfg variable.  Perhaps the free should not happen until the end of the gdm_daemon_config_get_user_session_lang function?  Does this make a difference?

Sebastian, isn't this the same bug as bug #451989?  If so, could you please close the other bug?  I suspect this isn't a problem with the circles theme, but a problem with all logins?

cfgfile is set to /home/username/.dmrc, the "cfg = gdm_common_config_load (cfgfile, NULL);" call return NULL though. 

The warning comes from "gdm_common_config_get_string (cfg, "Desktop/Session", &session, NULL);" and "gdm_common_config_get_string (cfg, "Desktop/Language", &lang, NULL);".

The other bug is likely the same issue, that doesn't depend of the theme and happen for a stock user but not for an another one which has a .dmrc configuration on the installation

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

Could you attach the problematic .dmrc file that this user has.  Is it in proper keyfile format?  Some users might have old .dmrc files that are in older formats and backwards support may have got lost in the code cleanup.

I'm assuming the /home/username/.dmrc file actually exists and is readable?

So I'm assuming the g_key_file_load_from_file function is failing.  Any ideas why?  Does the local_error argument that is passed back from this function provide any clues?

Is it possible that the file got corrupted, or that it is possible to corrupt the file by doing something in GDM?

The user is a stock one, there is no .dmrc, gdm_common_config_load() returns NULL since g_key_file_load_from_file() is used on a filename which is not there, which leads to cfg issue described before

Okay, if there is no .dmrc file, then it is probably not an error that GDM can't read the file.  GDM could probably be smarter about not trying to read the file if the file doesn't exist and avoid the warnings.  It should probably just return "" for both the default session and language if the gdm_common_config_load returns NULL.

So, I'm guessing the problem is in the gdm_daemon_config_set_user_sesson_lang the function just returns if it can't load the file and doesn't bother saving anything.  It should create the file if it doesn't exist.

One big difference between the old vicious-extensions and the new keyfile approach is that vicious-extensions would create a file automatically for you if it were missing. 

It would probably be okay to check if the file exists and, if not, then just create a blank file between the g_build_filename and the gdm_common_config_load calls in gdm_daemon_config_get_user_session_lang.  

Can you see if these suggestions fix your problem?

not sure of what is the suggestion. Creating an empty file using touch doesn't work, adding an empty line to it make the session being written, then the question is asked normally

I think that when GDM calls gdm_daemon_config_set_user_session_lang, the code needs to check if the file is present.  If not, GDM should create it and insert an empty line.  Then things should work.

The getter function should also just return "" for both the user's default session and language when the file isn't found instead of generating warnings.

This should fix the problem.  If you could provide a patch, then that I will put that upstream.

When Jon cleaned up the code, he probably didn't test this situation.  The .dmrc file is unique in the sense that it's the only configuration file that GDM is expected to create.  All other configuration files GDM uses are normally present and should contain valid data in a clean install.

I am seeing this bug too, whenever I login as a user (not root) either at the console or via VNC.

This is a fresh installation of SuSE 10.3beta1 straight off the web site
with all the defaults.  I would imagine that if you installed from that
distribution, it would be repeatable. Here is the syslog data of what happens:


Aug 20 09:44:31 petabox gdm[7993]: WARNING: Request for invalid configuration key greeter/ShowDomain
Aug 20 09:44:31 petabox gdm[7993]: WARNING: Request for invalid configuration key greeter/ShowDomain
Aug 20 09:44:31 petabox gdmgreeter[9961]: CRITICAL: Could not access configuration key <greeter/ShowDomain=false>
Aug 20 09:44:31 petabox gdmgreeter[9961]: CRITICAL: Using compiled in value <FALSE> for <greeter/ShowDomain=false>
Aug 20 09:44:33 petabox gdmgreeter[9961]: GLib-CRITICAL: g_str_has_prefix: assertion `str != NULL' failed
Aug 20 09:44:36 petabox syslog-ng[7833]: last message repeated 108 times
Aug 20 09:44:50 petabox gdm[9963]: Gtk-WARNING: Ignoring the separator setting
Aug 20 09:44:55 petabox gdm[9949]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
Aug 20 09:44:55 petabox gdm[9949]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
Aug 20 09:44:55 petabox gdm[9949]: GLib-CRITICAL: g_key_file_free: assertion `key_file != NULL' failed
Aug 20 09:44:58 petabox kernel: BUG: unable to handle kernel paging request at virtual address 415e26f0
Aug 20 09:44:58 petabox kernel:  printing eip:
Aug 20 09:44:58 petabox kernel: c01ca276
Aug 20 09:44:58 petabox kernel: *pde = 00000000
Aug 20 09:44:58 petabox kernel: Oops: 0000 [#3]
Aug 20 09:44:58 petabox kernel: SMP 
Aug 20 09:44:58 petabox kernel: last sysfs file: /block/sda/sda1/stat
Aug 20 09:44:58 petabox kernel: Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq ip6t_LOG nf_conntrack_ipv6 st ide_disk ide_cd joydev ip6t_REJECT xt_tcpudp xt_pkttype ipt_REJECT ipt_LOG xt_limit xt_state iptable_mangle iptable_nat nf_nat ip6table_mangle nf_conntrack_ipv4 nf_conntrack nfnetlink iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 af_packet dock battery ac fuse loop raid0 sr_mod cdrom usb_storage parport_pc vt8623fb ide_core svgalib parport vgastate rtc_cmos rtc_core rtc_lib i2c_viapro i2c_core via_ircc via_rhine irda mii snd_via82xx gameport snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device e1000 snd shpchp soundcore pci_hotplug crc_ccitt via_agp agpgart ohci1394 ieee1394 button sg linear dm_snapshot sd_mod ehci_hcd uhci_hcd usbcore edd dm_mod ext3 mbcache jbd fan pata_via libata scsi_mod thermal processor
Aug 20 09:44:58 petabox kernel: CPU:    0
Aug 20 09:44:58 petabox kernel: EIP:    0060:[<c01ca276>]    Tainted: G      N VLI
Aug 20 09:44:58 petabox kernel: EFLAGS: 00210046   (2.6.22.1-16-default #1)
Aug 20 09:44:58 petabox kernel: EIP is at radix_tree_lookup+0x38/0x50
Aug 20 09:44:58 petabox kernel: eax: 00000000   ebx: 000005fa   ecx: ee019bfa   edx: 00000100
Aug 20 09:44:58 petabox kernel: esi: 00000000   edi: 415e26e0   ebp: 00000000   esp: e1fd9d50
Aug 20 09:44:58 petabox kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Aug 20 09:44:58 petabox kernel: Process python (pid: 10024, ti=e1fd8000 task=e1429030 task.ti=e1fd8000)
Aug 20 09:44:58 petabox kernel: Stack: 00000000 00000000 f2a46794 c0155d04 00008000 f2a46798 e1409960 f2a467a4 
Aug 20 09:44:58 petabox kernel:        00000009 00000000 c017aa92 e1fd9e00 0000000e f13bd19e c19ad026 f13bd19e 
Aug 20 09:44:58 petabox kernel:        f13bd19e f2a4ac28 c19ad026 c01721df e1fd9e0c e1fd9e00 e1fd9f30 ef6d26c0 
Aug 20 09:44:58 petabox kernel: Call Trace:
Aug 20 09:44:58 petabox kernel:  [<c0155d04>] __do_page_cache_readahead+0x8f/0x1e7
Aug 20 09:44:58 petabox kernel:  [<c017aa92>] __d_lookup+0x96/0xd9
Aug 20 09:44:58 petabox kernel:  [<c01721df>] do_lookup+0x4f/0x140
Aug 20 09:44:58 petabox kernel:  [<c0155ea8>] blockable_page_cache_readahead+0x4c/0x9f
Aug 20 09:44:58 petabox kernel:  [<c015605e>] page_cache_readahead+0xc5/0x198

I think that we have identified that the problem is fixed if we update the code to create a $HOME/.dmrc file if one is missing in the gdm_daemon_config_set_user_session_lang function.  If someone would create a patch and verify it works, then I'd happily patch this upstream to fix the problem.

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

Created attachment 95906 [details] [review]
Patch to save the newly selected language is default for the current and future sessions

Attached is a patch to fix the problem of saving the newly selected language as default during login

Thanks, Brady.  This patch is now in 2.20 branch and SVN head.

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