Bugzilla Bug 216984

I am using current ~amd64 versions of seahorse and gdm. I am using a custom
.xsession script, so in gdm, I select "custom" as a session. The
/etc/X11/gdm/Xsession script accepts "custom" as a parameter, however the file
/etc/X11/xinit/xinitrc.d/70-seahorse-agent changes the parameter from "custom"
to "seahorse-agent --execute custom". As this line does not work (because there
is no binary called "custom" on my system), the "custom" XSession is rendered
unusable.

Reproducible: Always

Steps to Reproduce:
1. Have gdm and seahorse in the versions mentioned above installed
2. Choose "custom" Xsession and try to log in

Actual Results:  
Nothing. Just a warning that my session lasted shorter than 10 seconds...

Expected Results:  
Execution of my ~/.xsession script

Created an attachment (id=149176) [edit]
Patch to fix Xsession problems with seahorse-agent

The problem is caused because the value of $command in /etc/X11/gdm/Xsession is
changed from "custom" to "$HOME/.xsession" *after* the xinitrc.d scripts are
run. So the command is set incorrectly by 70-seahorse-agent

The attached patch to the custom gentoo Xsession in
gdm-2.8-gentoo-files-r2.tar.bz2 fixes the problem.

The change made by the patch also fixes another problem I just noticed: the
modifications done to $command by seahorse-agent are erased right afterwards,
and hence seahorse should not have worked at all anyway.

(In reply to comment #1)
> Created an attachment (id=149176) [edit]
> Patch to fix Xsession problems with seahorse-agent
[snip]
> The attached patch to the custom gentoo Xsession in
> gdm-2.8-gentoo-files-r2.tar.bz2 fixes the problem.

Note: I've not tested this patch, so this is all theory :)


> The change made by the patch also fixes another problem I just noticed: the
> modifications done to $command by seahorse-agent are erased right afterwards,
> and hence seahorse should not have worked at all anyway.
> 

Correction, it's not that seahorse would not work, but that things should break
weirdly since $command would be "default"...

in fact, the current xinitrc.d thing is inspired from what ubuntu does. As it
is, it works well with anything not being custom session so when I get time,
I'll check what needs fixing.

The current patch is a no go because it launches custom commands before the X
environment is ready. By X environment, I mean everything that is started by
/etc/X11/xinitrc.d/* and that sets env variable.

> The current patch is a no go because it launches custom commands before the X
> environment is ready. By X environment, I mean everything that is started by
> /etc/X11/xinitrc.d/* and that sets env variable.

Sorry, I do not understand this comment. The patch just replaces "custom" by
"$HOME/.xsession" before the environment is ready. It does not launch anything.
So what exactly is wrong with it?

(In reply to comment #4)
> Sorry, I do not understand this comment. The patch just replaces "custom" by
> "$HOME/.xsession" before the environment is ready. It does not launch anything.
> So what exactly is wrong with it?
> 

Ah, right, I forgot to comment back. eva and I talked on #-desktop, and the
patch is fine. I've tested it as well, and it works. 

The rest is upto eva now. He will probably try to confirm that this is an
acceptable solution and patch the Xsession :)

commited with 2.20.5. Thanks for reporting.