[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Pkg-xfce-devel] Bug#526009: Attempt to summarize



On 04/28/09 14:29, Yves-Alexis Perez wrote:
> From a display manager, /etc/X11/Xsession.d/90consolekit will always be
> run, and position correctly the ck stuff. This is the simple case :)
> 
> From the console:
> - either libpam-ck-connector is installed
> - either it's not
> 
> If it's installed, consolekit stuff will be positionned at login, and
> should be propagated to any desktop run from there. And that's why
> 90consolekit should _not_ be run, and why the pam module sets a variable
> to be sure.

That makes sense, except that the consolekit stuff appears to not be 
propagated. Perhaps the true cause of these problems is a bug in 
consolekit? Although from my readings on consolekit, it is not intended 
to propagate sessions across changing ttys (as in text login tty -> 
xinit tty).

> If it's not installed, the console login won't have consolekit stuff,
> and if we want a complete desktop experience, we _need_ to use
> 90consolekit, and so run stuff in /etc/X11/Xsession.d (and still run
> startxfce4).
> 
> The only way to do that (that I know) is to put:
> exec startxfce4
> in .xsession, and run:
> startx
> 
> (no .xinitrc, no startx /usr/bin/startxfce4 or anything else).

There are other ways (* see below), but that is by far the easiest and 
cleanest at the moment.

> So, if we document that in README.Debian, everything should work fine
> for most user, wether they use a DM (case 1) or not, and have
> libpam-ck-connector installed (2a) or not (2b).
> 
> But we have a problem with 2a because in some cases which you exposed in
> I don't remember which bug, that the ck session on console wasn't
> propagated to the desktop session. Could you give (on that bug) a
> summary of how to reproduce this?

Reproducing it appears to be straight-forward:

   0) remove .xsession, .xinitrc, and other similar X customization files
   1) install libpam-ck-connector
   2) kill all /sbin/login processes (so login reloads the pam stack)
   3) log out and log back in
   4) run polkit-auth (all necessary permissions will be present)
   5) run startxfce4
   6) run polkit-auth from a terminal (most permissions are now missing)

Alternatively:

   0) - 4) same as above
   5) ensure /etc/alternatives/x-session-manager links to xfce4-session
   6) run startx
   7) run polkit-auth from a terminal, and most permissions are missing

I will put this information in the thunar bug as well.

* Other ways I have found that work:

   - symlink /etc/alternatives/x-session-manager to /usr/bin/startxfce4 
(but this defeats the true purpose of alternatives in this case)

   - custom $HOME/.config/xfce4/.xinitrc or $HOME/.xinitrc with 
ck-launch-session in an appropriate place (but this prevents the user 
from benefitting from future improvements to the Debian X startup 
process in /etc)

I'm sure there are other ways, but they will probably all be messy and 
non-Debian-standard.

I did have another thought - if there is stuff that startxfce4 does that 
xfce4 requires, maybe that stuff, or a call to startxfce4 itself, should 
be integrated somehow into /etc/X11/Xsession.d/*? Something like what is 
done in /etc/X11/Xsession.d/55gnome-session_gnomerc? Then the 
alternative just needs to be pointed to xfce4-session, and no .xsession 
in the home dir is required - seamless for the user.

-- 
Scott Barker       scott at mostlylinux.ca
Linux Consultant   http://www.mostlylinux.ca/scott






Reply to: