On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: > 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).
I need more testing on this, but this could definitely bite us :/ > > 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) Ok, thanks, I'll check on that. > > 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 Yeah, this is the same stuff as just above. > > I will put this information in the thunar bug as well. Please don't. It's _really_ messy. Thunar needs a correctly setup consolekit, xfce4-session too. For most Xfce users this will be documented in xfce4-utils:README.Debian and/or xfce4:README.Debian. And this is the bug where we discuss it. Not the other ones, please. > > * 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. Yeah and we definitely won't advertise them :) We'll recommend one way for console users (and the display manager stuff), and other users will do their stuff based on that. > > 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. Yeah, it's been quite some time since I first though of putting all startxfce4 stuff into /etc/X11/Xsession.d and only keep a stub. But I don't really want to divert too much from upstream and other distros. -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part