Karmic, Lucid: /etc/gdm/Xsession fails to apply ~/.Xresources

Confirming on xubuntu karmic.

I see that /etc/gdm/Xsession does run the scripts in /etc/X11/Xession.d/, one of which probably sourced $HOME/.xsessionrc at some time in the past. However, that script currently sources "$USERXSESSIONRC", which is not set by gdm's scripts. (It gets set in /etc/X11/Xession, which never gets run by gdm.) The same situation exists for $HOME/.Xresources .

To be clear, the ~/.xsessionrc and ~/.Xresources were sourced (or in the latter case, merged) in Jaunty. The breakage started in Karmic.

Confirmed on Ubuntu karmic.

Right so the new GDM runs all the scripts in /etc/X11/Xsession.d/*
_BUT_, it doesn't run /etc/X11/Xsession which sets up the USERXSESSIONRC variable.
So my workaround was to simply add
USERXSESSIONRC=$HOME/.xsessionrc
to the beginning of
/etc/X11/Xsession.d/40x11-common_xsessionrc

While setting the variables in etc/X11/Xsession.d/40x11-common_xsessionrc does work it is generally better to leave the Ubuntu maintained files alone and set the variables in .xprofile and/or /etc/xprofile instead. If you edit a Ubuntu packaged file the file won't be automatically upgraded by the system. This could be an issue if there is a bug in the orginal file. Although in this case there is so little 40x11-common_xsessionrc that it is likely not an issue.

Bumping the importance and setting a milestone, because this is a regression: admins expecting for /etc/X11/Xresources/* to be set will get disappointed unless this is fixed in gdm/Xsession.

Can this not be patched sooner? It looks like a simple fix and right now with Karmic running Fluxbox I need to work a lot harder than normal to pick up settings that should just work, and for some time now in *nix environments.

patch that adds the missing variables.

thank you for the patch.

Timo, please feel free to grab the bug if you want to push this further. Otherwise I'll try to get to it in the next two weeks, while I'm still in the platform team. :-)

is that the same issue than bug #465349? the other bugs has some interesting comments too and suggest the issue is due to the xorg scripts too and one other way would be to drop those, or to change the gdm one

These have the same root cause, yes. /etc/X11/Xsession.d is shared with other *dm's though, so it's the gdm Xsession script that needs to remove duplicate functionality which is already set in Xsession.d (the script is from redhat anyway, no?).

Adding these variables would essentially fix both bugs. Debian now has 2.30 in unstable, maybe I should have a look at that too..

Sebastien, Timo,

at this point I'm unsure how things should behave. With Timo's patch, an user who creates an ~/.xsession file would always get that, and the chosen session in gdm would be ignored (this would make bug 398300 obsolete).

OTOH, with a separate "user session" as proposed in bug 398300 gdm's session chooser would continue to work (this is also the approach upstream recommends).

So perhaps we should confine this bug to setting {SYS,USR}RESOURCES and strip down the patch for those two, and add a separate "user-defined session" .desktop file as in bug 398300?

Oh, forgot: Personally I favor a separate "User defined session" entry, too.

I would be in favor of the user defined session too, having the selection not respected when there is a .xsession would be weird and confusing, gdm could still source Xressources in any case I guess?

Discussed with Seb, and he agrees to my proposal in comment 13. So I'll devote this bug to the Xresources problem, while bug 398300 deals with ~/.xsession.

I just tried this on current lucid:

echo "XTerm*reverseVideo: on" > ~/.Xresources

then logged out and back in (with the GNOME session), and I indeed get:

$ xrdb -query
XTerm*reverseVideo: on
[...]

and xterm is white-on-black now. /etc/gdm/Xsession in lucid has code to handle custom resources:

userresources="$HOME/.Xresources"
[...]
if [ -f "$userresources" ]; then
    xrdb -nocpp -merge "$userresources"
fi

Martin, did you intend to drop ~/.xsessionrc from this bug, or did you confuse it with ~/.xsession? Obviously ~/.xsession needs to be handled differently so it will only be used when requested, but ~/.xsessionrc needs handling similar to ~/.Xresources. Did this get included in the fix? Why was it removed from the summary?

It was removed from the summary because this bug is about Xresources, not ~/.xsession. Bug 398300 is for xsession. But both of the SRU bugs are verification-failed, so it'll need another update anyway. So I'll add ~/.xsessionrc here.

Do you have an example ~/.xsessionrc? (Argh, X just has way too many configuration files)

Ah, no, since this bug is already closed (lucid does apply .Xresources already), please followup on bug 398300.