[Pkg-xfce-devel] Bug#526009: Bug#526009: Attempt to summarize
corsac at debian.org
Tue Apr 28 21:15:25 UTC 2009
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.
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the Pkg-xfce-devel