Your message dated Tue, 06 Jan 2009 09:02:05 +
with message-id e1lk7p7-0004y7...@ries.debian.org
and subject line Bug#502140: fixed in pam 1.0.1-5
has caused the Debian Bug report #502140,
regarding cannot unlock screen during etch - lenny transition
to be marked as done.
This means that you
On Sun, 28 Dec 2008 00:57:22 -0600, Steve Langasek vor...@debian.org
wrote:
The issue is that, in order to reliably ensure that a user (such as the
admin) is not locked out by xscreensaver or xlockmore in the middle of an
upgrade,
The release notes strongly suggest not doing the upgrade from
On Mon, Dec 29, 2008 at 05:01:45PM -0500, Michael Gilbert wrote:
- I have no idea why this loop is here, anyway. Why would the -restart
command ever fail?
-restart will fail whenever a screensaver is active. this allows the
process to wait for the user to unlock the screen before
]] Steve Langasek
(Not wearing any particular hat here)
[...]
| Is it ok to make libpam-modules Pre-Depends: debconf (= 0.5) | debconf-2.0
| for lenny?
Yes, I think this sounds reasonable (and your analysis looks good to me).
[...]
| So is it ok to also make libpam-modules Pre-Depends:
On Sun, 28 Dec 2008, Steve Langasek wrote:
Therefore I think it's neither necessary nor appropriate for libpam-modules
to avoid a pre-dependency on debconf.
Is it ok to make libpam-modules Pre-Depends: debconf (= 0.5) | debconf-2.0
for lenny?
I think so. We already have many predependencies
On Sat, 27 Dec 2008 23:54:56 -0600 Steve Langasek wrote:
- the release of the dpkg lock does not guarantee that the upgrade
completed; any number of other packages could cause dpkg to exit before
all of libpam-runtime's deps have been unpacked, leading to the same
problem when the
after the update from etch to lenny i have the same problem.
i updatet the described libs but i cannot log in after a screen-lock.
what i did:
/etc/init.d/gdm stop
apt-get install --reinstall libpam-0g
apt-get install --reinstall libpam-modules
apt-get install --reinstall libpam-gnome-keyring
On Sun, Dec 28, 2008 at 10:44:34PM +0100, Richard Schweizer wrote:
after the update from etch to lenny i have the same problem.
i updatet the described libs but i cannot log in after a screen-lock.
what i did:
/etc/init.d/gdm stop
apt-get install --reinstall libpam-0g
apt-get install
On Mon, Dec 08, 2008 at 06:41:51PM -0500, Michael Gilbert wrote:
This is not a patch that I'll accept, stylistically and in terms of intent.
I'm working on fixing this in the way I earlier indicated it should be
fixed.
just trying to help. it works, and its automatic. but yes, it does
On Sat, Dec 13, 2008 at 04:18:41PM -0500, Sam Hartman wrote:
So, I've been thinking about this issue. I'm not sure I have great
solutions for the etch-lenny case. However it seems like we could do
better for the future.
Here's a possibility. When libpam failes to be able to dlopen a
Hi folks,
I'm attempting to solve bug #502140 in pam, which is marked as
release-critical for lenny. Unfortunately, the only ways to solve this all
involve fiddling around with preinsts of transitively essential packages, so
per Policy 3.5 I'm asking here about my proposed solution to add Pre
So, I've been thinking about this issue. I'm not sure I have great
solutions for the etch-lenny case. However it seems like we could do
better for the future.
Here's a possibility. When libpam failes to be able to dlopen a
module, it could look at a version epoch stored somewhere in s/etc.
On Sun, Dec 07, 2008 at 12:10:12AM -0500, Michael Gilbert wrote:
tag 502140 patch
thank you
i have developed a preinst for libpam-modules that will wait for
xscreensaver to be deactivated before allowing it to begin its
upgrade. then to prevent the screensaver from reactivating, it will
This is not a patch that I'll accept, stylistically and in terms of intent.
I'm working on fixing this in the way I earlier indicated it should be
fixed.
just trying to help. it works, and its automatic. but yes, it does
leave the screen unlocked during all of the upgrade (although, this
tag 502140 patch
thank you
i have developed a preinst for libpam-modules that will wait for
xscreensaver to be deactivated before allowing it to begin its
upgrade. then to prevent the screensaver from reactivating, it will
send the deactivate command every 30 seconds until dpkg is unlocked
On Sat, Nov 15, 2008 at 11:55:55PM -0800, Steve Langasek wrote:
On Wed, Oct 22, 2008 at 08:49:27AM +0200, Thomas Viehmann wrote:
probably I'm just dense, but why would (the admittedly gross hack) of
looking at /proc/$XSCREENSAVER-PID/environ (for DISPLAY and XAUTHORITY),
getting uid for
On Thu, Nov 20, 2008 at 11:47:49PM +0100, Moritz Muehlenhoff wrote:
On Sat, Nov 15, 2008 at 11:55:55PM -0800, Steve Langasek wrote:
On Wed, Oct 22, 2008 at 08:49:27AM +0200, Thomas Viehmann wrote:
Well, that sounds better than the current state, but a) the code for it
isn't written and I'm
On Wed, Oct 22, 2008 at 08:49:27AM +0200, Thomas Viehmann wrote:
probably I'm just dense, but why would (the admittedly gross hack) of
looking at /proc/$XSCREENSAVER-PID/environ (for DISPLAY and XAUTHORITY),
getting uid for that process, trying xscreensaver-command -exit, if the
screensaver
Hi Steve,
thanks for your input on this.
Steve Langasek wrote:
Well, that sounds better than the current state, but a) the code for it
isn't written and I'm not familiar enough with xscreensaver to be confident
of getting it right on the first try myself, b) we have to cover more than
just
if a sufficiently detailed note about this (and a recommendation to
disable the screensaver) is added to the release notes, then i believe
that this bug can be closed. btw, where can i review the release
notes at?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
the previous suggestion also seems like it would work pretty well.
some python-like pseudo code:
while $ xscreensaver-command -exit fails (indicating screensaver active):
present dialog indicating that an active xscreensaver was detected
wait for user to unlock screen and respond to
or even better:
while $ xscreensaver-command -exit fails (indicating screensaver active):
sleep 5 seconds
perform pam and xscreensaver installation
restart xscreensaver daemon
which eliminates any need for user intervention.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Hi,
probably I'm just dense, but why would (the admittedly gross hack) of
looking at /proc/$XSCREENSAVER-PID/environ (for DISPLAY and XAUTHORITY),
getting uid for that process, trying xscreensaver-command -exit, if the
screensaver exited, start xscreensaver again with that uid and environ,
Quoting Steve Langasek ([EMAIL PROTECTED]):
The one thing I would note is that, in the rare case that there are no
system-level daemons running on your system that use PAM, the message will
not be shown. Michael, before the screensaver locked up on you, did you see
the debconf warning that
The one thing I would note is that, in the rare case that there are no
system-level daemons running on your system that use PAM, the message will
not be shown. Michael, before the screensaver locked up on you, did you see
the debconf warning that Christian quotes above?
I do not recall
I very much suspect that bug #502140 is related to the upgrade of pam.
While looking at PAM debconf templates, I see this:
Description: Services to restart for PAM library upgrade:
Most services that use PAM need to be restarted to use modules built for
this new version of libpam. Please
reassign 502140 pam
thanks
On Sun, Oct 19, 2008 at 03:21:51PM +0200, Christian Perrier wrote:
I very much suspect that bug #502140 is related to the upgrade of pam.
While looking at PAM debconf templates, I see this:
Description: Services to restart for PAM library upgrade:
Most services
Package: xscreensaver
Version: 5.05-3
Severity: grave
i just tested the etch - lenny transition on two of my systems, and
xscreensaver ended up locking me out of both of them.
version 4.24 of the xscreensaver daemon was running when i started the
upgrade. i went off to work on some other
28 matches
Mail list logo
