Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On Thu,16.Jul.09, 08:04:31, Yves-Alexis Perez wrote: Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Ok, it wasn't my imagination, it showed up again today (with gdm). Unfortunately it was totally unexpected and I don't have the output of list-ck-sessions and polkit-auth. I'll set an hourly cronjob. Hmhm, ok, what's the status on this? Consolekit package has been fixed to work in most cases, and anyway gdm was supposed to work at first. So it looks very weird you still have issues here. Could you update us? Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? The interesting thing is that the bug doesn't show up with kdm. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On jeu, 2009-08-06 at 21:27 +0300, Andrei Popescu wrote: Sorry for the late reply, but wanted to gather more data. The shutdown worked for a while, but then it broke again. Unfortunately it's hard to reproduce since, immediately after a reboot it always works. The system has to stay on for a while before the shutdown will fail. Any ideas on how to diagnose this? Not really sure. Maybe using ck-list-session and polkit-auth. Check just after boot, and later, when it fails, see if it's different. The interesting thing is that the bug doesn't show up with kdm. Hmhm, so it might be related to gdm? Or maybe to some other gnome stuff. I wonder if stuff like gnome-screensaver (do you run it?) might deprecate ck tokens after a while. Or gnome-keyring. Not really sure how to help anyway. Atm I'm using gdm on two boxes, which I basically boot on the morning, do some work, and put to hibernation at night. Not sure about their respective uptime, but some days at least, and they both work fine (I can hibernate, at least). So not exactly sure how to debug this. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On dim, 2009-05-03 at 09:17 +0300, Andrei Popescu wrote: On Wed,29.Apr.09, 11:49:24, Andrei Popescu wrote: On Wed,29.Apr.09, 08:35:18, Yves-Alexis Perez wrote: On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu 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 :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Mmm, can't reproduce anymore. Maybe something was wrong with libpam-ck-connector and purging/installing it fixed it? Ok, it wasn't my imagination, it showed up again today (with gdm). Unfortunately it was totally unexpected and I don't have the output of list-ck-sessions and polkit-auth. I'll set an hourly cronjob. Hmhm, ok, what's the status on this? Consolekit package has been fixed to work in most cases, and anyway gdm was supposed to work at first. So it looks very weird you still have issues here. Could you update us? Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On mer, 2009-04-29 at 09:11 +0300, Andrei Popescu 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 :) Actually, I don't get a working shutdown with gdm and libpam-ck-connector installed. That's definitely a bug. Check you didn't mess with your PolicyKit.conf, and check what you have in polkit-auth and ck-list-sessions. Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On 04/28/09 15:15, Yves-Alexis Perez wrote: On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: On 04/28/09 14:29, Yves-Alexis Perez wrote: 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: [...] 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. Right, sorry, I won't. I mis-interpreted your wording asking for a summary on how to reproduce as asking for it in the other bug report. 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. It could be as simple as: BASESTARTUP=`basename $STARTUP | cut -d\ -f1` if [ $BASESTARTUP = xfce4-session -o \ \( $BASESTARTUP = x-session-manager -a \ `readlink /etc/alternatives/x-session-manager` = \ /usr/bin/xfce4-session \) ]; then STARTUP=/usr/bin/startxfce4 fi However, this may be as undesirable as pointing x-session-manager at /usr/bin/startxfce4. Obviously, you and others can make the best decision in this regard. -- Scott Barker sc...@mostlylinux.ca Linux Consultant http://www.mostlylinux.ca/scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
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
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On mar, 2009-04-28 at 14:56 -0600, Scott Barker wrote: On 04/28/09 14:29, Yves-Alexis Perez wrote: 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). […] 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. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X - either the 90consolekit shouldn't prevent ck-launch What do you think? -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#526009: [Pkg-xfce-devel] Bug#526009: Attempt to summarize
On 04/28/09 15:47, Yves-Alexis Perez wrote: Ok. I've tested and we have indeed propagation problems. I'm not sure how it's supposed to be handled, but I think it's a bug in consolekit. I don't exactly know how it should be done, but: - either the authentication propagates from console to X - either the 90consolekit shouldn't prevent ck-launch What do you think? I think someone who has more intimate knowledge of consolekit should be consulted to clarify the propagation issue. If, in fact, propagation does not occur, then it may be best to leave libpam-ck-connector uninstalled, unless there is some pressing reason it would be needed in a text terminal-only environment. However, I also found this method to fix the issue: - libpam-ck-connector can be installed or not, doesn't matter - don't use a $HOME/.xsession file - put the following in $HOME/.config/xfce4/xinitrc: #!/bin/sh exec ck-launch-session /etc/xdg/xfce4/xinitrc - chmod +x $HOME/.config/xfce4/xinitrc Now you can start xfce with 'startxfce4' instead of 'startx', and everything works fine, regardless of libpam-ck-connector. This method just over-rides the default exec at the very end of /usr/bin/startxfce4, inserting ck-launch-session before calling /etc/xdg/xfce/xinitrc. I'm sure that the upstream xfce developers will run across this consolekit problem soon (if they haven't already), and may patch /usr/bin/startxfce4 appropriately anyway. So, that makes two fairly simple methods which work fine (one for the 'debian way' and one for the 'xfce way'), but you and the other maintainers will need to determine which is best. -- Scott Barker sc...@mostlylinux.ca Linux Consultant http://www.mostlylinux.ca/scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
