I'm cc:ing Frederic on this bug since he implemented the new background feature.    I'm hoping he might be able to look into this and fix the code so that it continues to work as it did previously when background isn't available in the theme.

I've just tested again 2.19.1 with a theme without background property and GraphicalThemedColor is working correctly. 

Sebastien - any ideas why you are seeing this problem but Frederic is not?  Perhaps the problem is with a distro patch?  Are you using the GraphicalThemedColor configuratin property to set your color to use?  

I had to change config/PreSession.in to make it work for us.

The change has been made to the Default BACKCOLOR value which was not required using 2.18

Daniel, can you share the change you had to make to PreSession.in to make this work?

Also, Sebastien, I don't really understand how your comment applies to this bug. Do you believe Daniel's problem is expected and what do you think the right way to fix this is?  I suspect the right fix for Daniel isn't to modify PreSession, but perhaps to modify the configuration in another way?  I know that gdmlogin and gdmgreeter use separate keys to control background color.  Perhaps in changing this we modified the code so that it used to default to use the gdmlogin background color if there wasn't a gdmgreeter color specified and this went away or something?

diff -Nur gdm-2.19.1/config/PreSession.in gdm-2.19.1.new/config/PreSession.in
--- gdm-2.19.1/config/PreSession.in     2007-05-14 04:08:25.000000000 +0200
+++ gdm-2.19.1.new/config/PreSession.in 2007-06-04 18:02:15.000000000 +0200
@@ -62,7 +62,7 @@
 
        # Default value
        if [ "x$BACKCOLOR" = "x" ]; then
-               BACKCOLOR="#76848F"
+               BACKCOLOR="#dab082"
        fi
 
        "$XSETROOT" -cursor_name left_ptr -solid "$BACKCOLOR"

This looks a bit odd to me.  Note that before the change you mention, the PreSession does the following logic (if using gdmgreeter).

      BACKCOLOR=`gdmflexiserver --command="GET_CONFIG 
         greeter/GraphicalThemedColor $DISPLAY"`

Could you run the above command and tell me what the gdmflexiserver command
returns?  I'd bet it is not returning the value you want "#dab082".

I'd recommend updating your configuration file so that the 
greeter/GraphicalThemedColor key has the value you want rather than hacking 
PreSession script to change the default value it uses if it couldn't get the 
value via gdmflexiserver.

$ gdmflexiserver --command="GET_CONFIG greeter/GraphicalThemedColor $DISPLAY"
OK #dab082

We do modify the configuration, that doesn't work with 2.19 which is what the bug is about

This is odd.  Would you mind doing some work debugging the PreSession script?  If  the code change you show above makes a difference, then there must be an odd bug in the way the script is working.  Note the following:

1) The GDM_GREETER_TYPE variable is checked and BACKCOLOR only gets set properly
   if it is equal to THEMED or PLAIN.  Is it possible this is unset?  It should
   be set to THEMED if you are using gdmgreeter.

2) Note sed is used to try and parse the output of gdmflexiserver.  Perhaps
   sed is causing a problem on your platform.  Perhaps verify that the
   if [ x$CHECKBACKCOLOR = xOK" ] test is passing.

In other words, add echo statements to the script and redirect the output to a file like /tmp/gdmtest.out and this way we can get an idea why BACKCOLOR is not being set when the gdmflexiserver GET_CONFIG command is returning a valid value.

If you can track down where the problem is happening, it will be easier to figure out how to approach fixing it. 

The bug seems to be due to:

"(process:24197): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+."


http://bugzilla.gnome.org/show_bug.cgi?id=431044 might be the change creating the bug

Reverting http://svn.gnome.org/viewcvs/gdm2/trunk/gui/gdmflexiserver.c?r1=4812&r2=4846 make the color being set correctly again

If you want to provide a patch that fixes the issue in bug #431044 and also fixes this bug, I'd be happy to accept it.  You'll notice all commands that require -a don't work after you revert that bug, which is probably a more serious problem.

For example, try:

   gdmflexiserver -a --command="SET_SAFE_LOGOUT_ACTION REBOOT"

It should be easy to fix.  Just revert the previous fix for #431044 and fix the code so it also calls gtk_init when --command is used and -a is used.  In other words it should not call gtk_init when --command is used and -a is not used.

Unless William has a better idea for a fix.  I'll cc: him since he wrote the original fix for #431044 which created this bug.

Any update on this?

William, would you be interested in looking into fixing this, since your patch broke gdmflexiserver?

distribution comment

"First fix was only working when already authenticated (gdmflexiserver): the following fix should work for EVERYONE :-)

Affected File (in gutsy):
/etc/gdm/PreSession/Default

Reason:
Authentication missing

Fix:
replace every "gdmflexiserver" whith "gdmflexiserver -a"

Comment:
This could be a problem in other places besides this file also (leading possibly to other bugs).

regards Jürgen"

I tried this fix (add "-a" to all gdmflexiserver calls) in Ubuntu Gutsy, but
it doesn't work.  Excerpt of output from script when running with -x:

+ [ xPLAIN = xTHEMED ]
+ [ xOK != xOK ]
+ [ xPLAIN = xPLAIN ]
+ gdmflexiserver -a --command=GET_CONFIG greeter/BackgroundType :0

(process:6691): Gtk-WARNING **: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.
+ BACKTYPE=
+ [ x = xOK 1 ]
+ [ x = xOK 2 ]
+ [ x = x ]
+ BACKCOLOR=#dab082
+ /usr/bin/xsetroot -cursor_name left_ptr -solid #dab082
+ exit 0

So this looks like a false lead and a proper fix is needed...

Let me explain more clearly.

This problem is caused because gdmflexiserver is used for two very different things:

1) For switching VT's, which can pop-up a UI
2) For commands which never pop-up a UI.

We currently call gtk_init now all the time, even though we really don't need
to for case #2.  The code should be fixed so that gtk_init is only called in situation #1.

One hassle for this is that William changed the code so that gtk_init is now used for parsing the options.  As I said before, we probably need to revert to the mechanism of parsing options to the way it was before the code was cleaned up via patch for bug #431044.

I'm building a custom Ubuntu distro and want to change the GraphicalThemedColor. I've changed the value in the gdm.conf-custom file but it doesn't work on Gutsy (it works on Feisty). Is it related to this bug? It there a workaround?

In comment #12, Sebastien points out that backing out a previous change fixes the problem for him.  Does it also fix your problem?  Or does fixing gdmflexiserver as described in comment #18 fix the problem?

I don't know how to test comment #12, and adding "-a" to all gdmflexiserver calls doesn't work ; So I've just replaced the default backcolor value in /etc/gdm/PreSession/Default... quite ugly :(

Created attachment 97747 [details]
patch to revert gdmflexiesrver to revision 4812.


Attached please find the gdmflexiserver.c file that you can use to replace the one in gui/gdmflexiserver.c.

This is the old version that reverts the code to before I think the problem was introduced.  

I believe the problem is that we need to revert back to using the g_option style of parsing the arguments and go back to calling gtk_init only when --command is not used.  Although using GTK+ may be "cleaner", it doesn't work when you want to run the command with setuid/setgid.  

Does using this version fix the problem?  If so, then perhaps someone could provide a patch that would convert the SVN head version of gdmflexiserver to use the old g_option style of parsing the arguments and calling gtk_init only when --command is not used.  I'd prefer to not simply revert back to using this version of gdmflexiserver since we'd lose other fixes to the file.

But it would be useful if you could test this, and this might also provide you with a temporary workaround until this issue is resolved in the 2.20 branch.

Oops.  I mean "perhaps someone could provide a patch that would convert the 2.20 branch version of gdmflexiserver to use the old g_options style of parsing the arguments and calling gtk_init onloy when --command is not used."

Obviously SVN head is the D-Bus rewrite and doesn't even contain gdmflexiserver at the moment.

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

Created attachment 100709 [details] [review]
patch to fix problem

the attached patch should fix this problem.  This is now fixed in the 2.20 branch.  Using the old g_option_context* functions works better with setuid/setgid than gtk_init* functions even though it might not be so pretty.

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