Bug#507927: Fix suspend-resume in Thinkpad R50e (intel 855gm card)
Hi Raphael, I'm very much behind on everything, so if you could handle the upload I would be very grateful! Cheers, Bart Raphael Hertzog wrote: Hi Bart, do you have time to handle this bug report quickly or do you need someone else to do the upload? It seems that this change has been integrated in Ubuntu's acpi-support 0.111 and it looks fairly safe. Cheers, On Fri, 05 Dec 2008, Diego Escalante Urrelo wrote: Package: acpi-support Version: 0.109-9 Severity: serious Thinkpad R50e won't resume correctly (corrupted X) unless its acpi-support file contains this: # R50e 1834 - see LP: #40621, #211285 1834*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=true; POST_VIDEO=true; ;; 1842*|2670*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=false; POST_VIDEO=false; ;; instead of this: # R50e 1834*|1842*|2670*) ACPI_SLEEP=true; SAVE_VIDEO_PCI_STATE=true; SAVE_VBE_STATE=false; POST_VIDEO=false; ;; I confirmed this two days ago after a test Lenny install on my own R50e. Please apply this change so R50e users of Lenny have working out-of-the-box suspend/resume. greetings PD: I hope you don't mind that I set serious, but I considered that despite not being a negative thing it's an enhancement worth doing. Feel free to disagree obviously. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin,
Kevin Mitchell wrote:
Looks good, except that that doesn't stop after finding the first user
so that I get
$ displaynum=0
$ user=`w -hs | awk '{ if ($3 == :'$displaynum' || $2 ==
:'$displaynum' ) print $1; }'`
$ echo $user
kevmitch kevmitch kevmitch kevmitch kevmitch kevmitch kevmitch
The following seems to return a unique value however:
$ user=`w -hs | awk '{ if ($3 == :'$displaynum' || $2 ==
:'$displaynum' ) {print $1;nextfile}; }'`
$ echo $user
kevmitch
Not sure if that's necessarily the correct way to do it but it seems
to work in my case.
Seems fine to me. Alternatively I could pipe it through head -n 1. But
I'm actually interested why you have multiple lines that match :0 in
your w -hs output. What does w -hs show for you?
PS: When does displaynum appear in the tty column?
It turns out that with xdm, the displaynum appears in the TTY column,
while with gdm, it appears in the From column. Apparently xdm does the
right thing, but gdm doesn't register its session in wtmp. Or at least,
that was suggested by the reporters of the original bug which caused me
to change this code...
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin, Kevin Mitchell wrote: $ w 01:00:47 up 1 day, 23:51, 9 users, load average: 0.00, 0.04, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 Sun030.00s 8:36m 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 00:572.00s 0.22s 0.02s aterm kevmitch pts/2:0 00:555:01m 0.17s 0.17s bash kevmitch pts/4:0 13:273:07 0.77s 0.77s bash kevmitch pts/5:0 23:49 14:05m 3.51s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/6:0 18:486:12 0.26s 0.26s bash kevmitch pts/7:0 18:493:08 2.09s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/8:0 00:563:48m 0.19s 0.19s bash kevmitch pts/9:0.0 01:000.00s 0.19s 0.00s w All the pts's are the xterminals I have open. The ones without .0 are aterm's started via key bindings in Openbox. The lone :0.0 is one that I started by typing aterm on the command line of an already open xterminal. Don't ask me why that makes a difference :) Thanks for the info. I hadn't seen this type before -- all cases I've seen up till now showed one entry for :0 and all terminal entries for :0.0. What I'm wondering is if you can get it to show a different user name while still showing :0, for instance rootpts/4:0 13:273:07 0.77s 0.77s bash if you edit the Openbox config and edit the hotkey to start something like sudo aterm command line or something similar. Because then I'm getting *really* unhappy about how this looks... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin, Well, at least this *looks* a bit reassuring. And we always grabbed the first one in the past, so this will probably be fine in practice. Thanks for all of the extra info! Cheers, Bart Kevin Mitchell wrote: It looks like openbox (or whatever is logging the terminals) knows not to cause this sort of trouble. I added a sudo aterm shortcut and when I fire it up, I get USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 09:030.00s 13.38s 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 09:035:55m 0.02s 0.02s mutt kevmitch pts/0:0 09:035:55m 0.13s 0.13s bash kevmitch pts/2:0 09:033:47m 0.41s 0.04s /usr/bin/aterm -geometry 106x32-640-412 - kevmitch pts/3:0 09:051:32m 0.22s 0.22s bash root pts/5:0.0 09:071:33m 0.20s 0.20s bash root pts/6:0.0 09:090.00s 0.18s 0.00s w So it appends the extra .0 when it might cause confusion. In any case, it might have been all right even if this wasn't the case, since the real login TTY seems to always be the first in the list. Thus, truncating to just the first result would have prevented any root :0 from spoiling the pudding. That probably wouldn't be very reassuring though, because who knows if that ordering is set in stone. Kevin On Mon, Sep 8, 2008 at 1:20 AM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Kevin, Kevin Mitchell wrote: $ w 01:00:47 up 1 day, 23:51, 9 users, load average: 0.00, 0.04, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 Sun030.00s 8:36m 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 00:572.00s 0.22s 0.02s aterm kevmitch pts/2:0 00:555:01m 0.17s 0.17s bash kevmitch pts/4:0 13:273:07 0.77s 0.77s bash kevmitch pts/5:0 23:49 14:05m 3.51s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/6:0 18:486:12 0.26s 0.26s bash kevmitch pts/7:0 18:493:08 2.09s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/8:0 00:563:48m 0.19s 0.19s bash kevmitch pts/9:0.0 01:000.00s 0.19s 0.00s w All the pts's are the xterminals I have open. The ones without .0 are aterm's started via key bindings in Openbox. The lone :0.0 is one that I started by typing aterm on the command line of an already open xterminal. Don't ask me why that makes a difference :) Thanks for the info. I hadn't seen this type before -- all cases I've seen up till now showed one entry for :0 and all terminal entries for :0.0. What I'm wondering is if you can get it to show a different user name while still showing :0, for instance rootpts/4:0 13:273:07 0.77s 0.77s bash if you edit the Openbox config and edit the hotkey to start something like sudo aterm command line or something similar. Because then I'm getting *really* unhappy about how this looks... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin, I've uploaded a fix for this final problem, using a fix similar to what you suggested but using exit instead of nextfile. The reason is that nextfile is gawk-only, while exit is supported by both gawk and mawk, and it does the same thing in this situation. Let's just hope that it works now! Cheers, Bart Bart Samwel wrote: Hi Kevin, Well, at least this *looks* a bit reassuring. And we always grabbed the first one in the past, so this will probably be fine in practice. Thanks for all of the extra info! Cheers, Bart Kevin Mitchell wrote: It looks like openbox (or whatever is logging the terminals) knows not to cause this sort of trouble. I added a sudo aterm shortcut and when I fire it up, I get USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 09:030.00s 13.38s 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 09:035:55m 0.02s 0.02s mutt kevmitch pts/0:0 09:035:55m 0.13s 0.13s bash kevmitch pts/2:0 09:033:47m 0.41s 0.04s /usr/bin/aterm -geometry 106x32-640-412 - kevmitch pts/3:0 09:051:32m 0.22s 0.22s bash root pts/5:0.0 09:071:33m 0.20s 0.20s bash root pts/6:0.0 09:090.00s 0.18s 0.00s w So it appends the extra .0 when it might cause confusion. In any case, it might have been all right even if this wasn't the case, since the real login TTY seems to always be the first in the list. Thus, truncating to just the first result would have prevented any root :0 from spoiling the pudding. That probably wouldn't be very reassuring though, because who knows if that ordering is set in stone. Kevin On Mon, Sep 8, 2008 at 1:20 AM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Kevin, Kevin Mitchell wrote: $ w 01:00:47 up 1 day, 23:51, 9 users, load average: 0.00, 0.04, 0.07 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT kevmitch tty7 :0 Sun030.00s 8:36m 0.04s /bin/bash /home/kevmitch/.xsession kevmitch pts/1:0 00:572.00s 0.22s 0.02s aterm kevmitch pts/2:0 00:555:01m 0.17s 0.17s bash kevmitch pts/4:0 13:273:07 0.77s 0.77s bash kevmitch pts/5:0 23:49 14:05m 3.51s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/6:0 18:486:12 0.26s 0.26s bash kevmitch pts/7:0 18:493:08 2.09s 0.00s /bin/sh /usr/local/bin/matlab -nosplash - kevmitch pts/8:0 00:563:48m 0.19s 0.19s bash kevmitch pts/9:0.0 01:000.00s 0.19s 0.00s w All the pts's are the xterminals I have open. The ones without .0 are aterm's started via key bindings in Openbox. The lone :0.0 is one that I started by typing aterm on the command line of an already open xterminal. Don't ask me why that makes a difference :) Thanks for the info. I hadn't seen this type before -- all cases I've seen up till now showed one entry for :0 and all terminal entries for :0.0. What I'm wondering is if you can get it to show a different user name while still showing :0, for instance rootpts/4:0 13:273:07 0.77s 0.77s bash if you edit the Openbox config and edit the hotkey to start something like sudo aterm command line or something similar. Because then I'm getting *really* unhappy about how this looks... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: acpi-support: but there are bigger problems ...
Hi Kevin,
Kevin Mitchell wrote:
Looking a littler closer, there are more problems than just this typo.
*) This loop is attempting to match $displaynum rather than :$displaynum
*) Variables inside the | while read construct are only local to within the
loop (probably because it's executed in some sort of subshell or something),
so $user never actually gets set. I tried to export it, but that
didn't work eiither. Instead, the patch attached (again to be
applied to power-funcs file itself) reverts back to something
closer to the old method, but using w instead of finger as
this was noted to be more reliable.
Thanks for the scrutiny -- apparently I failed to test this batch of
changes, blindly trusting the fact that I copied most of it from
laptop-mode-tools. Stupid me. Anyway, the reason to go to the read
construct was also the fact that filtering for :0 would also match a
significant percentage of all logged in times (the fourth column in the
output of w, and also present in the finger output). And it also
matches entries which contain :0.0, which are present for terminal
emulators. We really need to check only the second and third columns for
display numbers, and we need to do exact matches only. So I think I'll
go for this awk-based solution:
user=`w -hs | awk '{ if ($3 == :'$displaynum' || $2 ==
:'$displaynum' ) print $1; }'`
Does that work for you?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497999: setting package to acpi-support acpi-support-base, tagging 497999
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-8) unstable; urgency=low # # * Fix broken getXuser (Closes: #497999) package acpi-support acpi-support-base tags 497999 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Hi Phil, Phil Endecott wrote: I am trying to get the lid event to suspend on my Eee 901 and have encountered the following problems: 1. getXuser() in /usr/share/acpi-support/power-funcs uses finger, but the package does not depend on finger (and I didn't have it installed). Thanks for reporting, added! 2. getXuser() is called from CheckPolicy() in /usr/share/acpi-support/policy-funcs and $displaynum is not set. Do you expect that $displaynum is set by the caller of CheckPolicy(), i.e. in this case eeepc-acpi-scripts' /etc/acpi/actions/lid.sh? Or should it be set to 0 in CheckPolicy()? (Most users won't notice this second problem as the grep in getXuser will look for ':' when displaynum is not set and match either the idle time or the login time. In fact, even with a valid display number, the pattern ':0' will frequently match the idle or login time in the second finger|grep|awk. You need to take care to match only in the Tty column of the finger output.) The way I see it, there are two issues here: First of all, the format provided by finger is (:$displaynum) or (:$displaynum.screennum). We filter by :$displaynumspace, which doesn't even find (:$displaynum). We then filter by just :$displaynum, which frequently gives unwanted matches, as you mention. I've replaced it by a filter for (:$displaynum) and then for (:$displaynum as a fallback. Secondly, the call from CheckPolicy() is completely incorrect. Like you say, the getXuser function is intended to be called when the display number has already been determined. CheckPolicy() should have called getXconsole, which gets the foreground X display and then calls getXuser for that display! I'll put fixes in for these issues. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: setting package to acpi-support acpi-support-base, tagging 497220
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Added finger to Depends of acpi-support-base (Closes: #497220) # package acpi-support acpi-support-base tags 497220 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Hi Phil,
Phil Endecott wrote:
I've just spotted detect_x_display() in
/usr/share/eeepc-acpi-scripts/functions.sh from package
eeepc-acpi-scripts which does a similar thing by parsing the output of
who, rather than finger. who has the advantage of being provided
by coreutils, which is a Priority: required package, while finger is
Priority: standard. There is also w from procps.
the format provided by finger is (:$displaynum) or
(:$displaynum.screennum).
Err, no; mine doesn't have the ():
$ finger
Login NameTty Idle Login Time Office Office
Phone
phil Phil Endecott *tty114:51 Sep 2 16:40
phil Phil Endecott pts/0 Sep 4 12:09 (egypt.chezphil.org)
phil Phil Endecott *:0 Sep 4 12:29
root root *tty213:02 Sep 3 21:40
Obviously yours does and I'm sure I've seem that notation somewhere or
other; I don't know if the () mean something or whether it's a finger
version thing, or what.
Mine actually only lists the display in the Office column:
$ finger
Login Name Tty Idle Login Time Office Office Phone
bsamwel bsamweltty7 Sep 4 11:36 (:0)
bsamwel bsamwelpts/2 Sep 4 11:37 (:0.0)
root root *tty11 Sep 4 14:17
root root *tty21 Sep 4 14:18
root root pts/1 25 Sep 4 11:37 (:0.0)
So that's a bit strange. I like the w approach, I've already got a bit
of code in laptop-mode-tools that uses w -hs. I've now got:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_DISPLAY DUMMY_REMAINDER;
do
if [ $THIS_DISPLAY = $displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
This does the trick for me. Does it work for you? If so, I'll use that.
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497125: setting package to acpi-support acpi-support-base, tagging 497801, tagging 497125
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Added missing 'policy-funcs' include to hibernatebtn.sh (Closes: ##497125) # * scripts in /etc/acpi no longer test files from acpi-support-base #to see if they should run (Closes: #497801) # package acpi-support acpi-support-base tags 497801 + pending tags 497125 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Phil Endecott wrote:
Bart Samwel wrote:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_DISPLAY
DUMMY_REMAINDER; do
if [ $THIS_DISPLAY = $displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
No this doesn't work for me. You're looking for :0 in the FROM column,
right? I have it in the TTY column:
$ w -hs
phil tty1 -17:19 -bash
root tty2 -15:31 -bash
phil pts/0egypt.chezphil.o 0.00s sshd: phil [priv]
phil pts/2egypt.chezphil.o 1:54 nano
libskyline/src/compute_skyline.cc
phil :0 -?xdm? -:0
Very peculiar. I'm not really sure what to suggest; I think that
understanding what w, who, finger etc. are really trying to tell us WRT
X sessions would be a good start. I doubt there's anything useful in
the man pages
Darn. I see that you use xdm, that might explain the difference. No clue
WHY this makes things different, but apparently it does. It's
interesting to note that your FROM column was dipslayed in the Office
column by finger, and I was getting my display from there as well.
Anyway, I can simply check both columns:
getXuser() {
w -hs | while read -r THIS_USER THIS_TTY THIS_FROM DUMMY_REMAINDER; do
if [ $THIS_TTY = $displaynum -o $THIS_FROM =
$displaynum ] ; then
user=$THIS_USER
break
fi
done
if [ x$user = x ]; then
startx=`pgrep -n startx`
if [ x$startx != x ]; then
user=`ps -o user --no-headers $startx`
fi
fi
if [ x$user != x ]; then
userhome=`getent passwd $user | cut -d: -f6`
export XAUTHORITY=$userhome/.Xauthority
else
export XAUTHORITY=
fi
export XUSER=$user
}
Does this version work for you?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497220: acpi-support-base: Needs to depend on finger
Phil Endecott wrote: Julien Cristau wrote: On Thu, Sep 4, 2008 at 15:04:14 +0100, Phil Endecott wrote: No this doesn't work for me. You're looking for :0 in the FROM column, right? I have it in the TTY column: $ w -hs phil tty1 -17:19 -bash root tty2 -15:31 -bash phil pts/0egypt.chezphil.o 0.00s sshd: phil [priv] phil pts/2egypt.chezphil.o 1:54 nano libskyline/src/compute_skyline.cc phil :0 -?xdm? -:0 Very peculiar. I'm not really sure what to suggest; I think that understanding what w, who, finger etc. are really trying to tell us WRT X sessions would be a good start. I doubt there's anything useful in the man pages Your wtmp entry comes from xdm, Bart's probably comes from a terminal emulator. I have this: USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT julien :0 -02:54 ?xdm? 14:13m 0.04s -:0 julien pts/0:0.0 02:54 25:03m 0.58s 0.58s bash (first xdm, then xterm) I'd say looking at the tty is the right thing to do. Ah yes; I did wonder about that. For some reason I'm not seeing lines in w, who or finger output for terminal emulators running inside my X session, though I have seen them in the past. If you did have them they could in principle be for different users than the user who owns the X session itself. The TTY=:0 line is the right one to use. But presumably Bart is not seeing a line like that, right? Nope. I use gdm, and I get: $ w -hs root tty1 - 2:19 -bash root tty2 - 2:19 -bash bsamwel tty7 :00.00s x-session-manager root pts/1:0.0 2:09m gnome-terminal bsamwel pts/2:0.0 0.00s w -hs The first two lines are from virtual terminals, the third one is for tty7 which is what my X is running on, and the final two ones are for terminals. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: requested output
Hi Christian, Christian Gogolin wrote: the output of $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend when run as root is: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. So I think I have a similar but slightly different problem. I don't know if that matters, but I am using xmonad as window manager, just like Nikolay A. Panov who reported #496911. My xorg version is 1:7.3+15. I guess the general problem is that I filter out the wrong kind of the error messages. I was hoping to be able to distinguish between local and remote errors other than I don't know how to suspend, and I was doing that by trying to filter for DBus related errors. Here's what I know: - All errors return an error code. - DBus connection errors do not start with Error org.freedesktop. - DBus interface mismatch errors do start with Error org.freedesktop, and return defined errors. - When I forcibly uninstall pm-utils I get: Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: General failure: No suspend method found - When I replace /usr/sbin/pm-suspend by a script that does exit 1, I get *no error message*, just like when it does exit 0, and I get a return code of 0. In effect, I think I should just take the return code of dbus-send instead of trying to filter error messages. If the message was received by pm-utils on the other end, even if it failed, I should look no further, and consider it a succeeded suspend attempt. I'll put this in. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496911: additional information
Hi Michael, Bart Samwel wrote: Michael Marsh wrote: On Sun, Aug 31, 2008 at 2:02 PM, Bart Samwel [EMAIL PROTECTED] wrote: Hi Michael, It seems to follow the right path, but the command is somehow detected as being successful without actually being successful. Could you manually run that last command: /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend and send me the output? That will tell us more about what's going wrong here. # /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend Failed to open connection to session message bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. If it matters, I boot into runlevel 2 and run startx from the console. A, that's an error I didn't anticipate. Thanks for the info, I'll try and still get a fix into lenny! I've got a potential fix. Could you try to replace /usr/share/acpi-support/suspendorhibernate with the attached file and see if it works then? If it does, I'll put that in! Cheers, Bart #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter suspend or hibernate. # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ $1 = suspend ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS=int32:0 elif [ $1 = hibernate ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo 'Usage: '$0' (suspend|hibernate)' fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ $SUSPEND_METHODS = ] [ $USE_HIBERNATE_PACKAGE = true ] [ -x $HIBERNATE_CMD ] ; then SUSPEND_METHODS=hibernate fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ $SUSPEND_METHODS = ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS=acpi-support fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It may have # failed (I tested this: if pm-suspend returns # exit code 1, then the return code of dbus-send # is still 0 and you get no errors), but that # doesn't matter: the first method in the list # that we can access is the one that has to do # it. exit fi # We got a DBUS error, which means that the other side # does not exist or we don't have access to it. We # continue by trying the next option. fi ;; dbus-hal) if [ -x /usr/bin/dbus-send
Bug#497570: requested output
Hi again Christian, Could you confirm that if you replace /usr/share/acpi-support/suspendorhibernate by the attached file, that it works? Cheers, Bart Bart Samwel wrote: Hi Christian, Christian Gogolin wrote: the output of $ /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend when run as root is: Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. So I think I have a similar but slightly different problem. I don't know if that matters, but I am using xmonad as window manager, just like Nikolay A. Panov who reported #496911. My xorg version is 1:7.3+15. I guess the general problem is that I filter out the wrong kind of the error messages. I was hoping to be able to distinguish between local and remote errors other than I don't know how to suspend, and I was doing that by trying to filter for DBus related errors. Here's what I know: - All errors return an error code. - DBus connection errors do not start with Error org.freedesktop. - DBus interface mismatch errors do start with Error org.freedesktop, and return defined errors. - When I forcibly uninstall pm-utils I get: Error org.freedesktop.DBus.GLib.UnmappedError.GpmControlError.Code0: General failure: No suspend method found - When I replace /usr/sbin/pm-suspend by a script that does exit 1, I get *no error message*, just like when it does exit 0, and I get a return code of 0. In effect, I think I should just take the return code of dbus-send instead of trying to filter error messages. If the message was received by pm-utils on the other end, even if it failed, I should look no further, and consider it a succeeded suspend attempt. I'll put this in. Cheers, Bart #!/bin/sh # # How we handle suspend/hibernate is a bit complicated: # # If gnome-power-manager or klaptopdaemon are running, we send a fake key # and that's it. The daemons may have policies that turn off suspend in # response to suspend keys etc., so we don't want to do anything ourselves. # # If not, we follow the SUSPEND_METHODS setting. # # # This script takes parameter suspend or hibernate. # . /etc/default/acpi-support . /usr/share/acpi-support/power-funcs . /usr/share/acpi-support/device-funcs . /usr/share/acpi-support/policy-funcs . /usr/share/acpi-support/key-constants DeviceConfig; # The difference between suspend and hibernate if [ $1 = suspend ] ; then KEY=$KEY_SLEEP HIBERNATE_CMD=/usr/sbin/hibernate-ram PM_UTILS_CMD=/usr/sbin/pm-suspend DBUS_METHOD=Suspend DBUS_PARAMS=int32:0 elif [ $1 = hibernate ] ; then KEY=$KEY_SUSPEND HIBERNATE_CMD=/usr/sbin/hibernate-disk PM_UTILS_CMD=/usr/sbin/pm-hibernate DBUS_METHOD=Hibernate DBUS_PARAMS= else echo 'Usage: '$0' (suspend|hibernate)' fi # # Backward compatibility # # Backward compatibility for setting USE_HIBERNATE_PACKAGE if [ $SUSPEND_METHODS = ] [ $USE_HIBERNATE_PACKAGE = true ] [ -x $HIBERNATE_CMD ] ; then SUSPEND_METHODS=hibernate fi # Backward compatibility for setups before SUSPEND_METHODS existed. if [ $SUSPEND_METHODS = ] ; then # Legacy configuration -- use the built-in legacy suspend support. We # can NEVER change this explicitly, because it will break people's # working suspend setups, especially ones that depend on custom scripts # in /etc/acpi/suspend.d and /etc/acpi/resume.d. SUSPEND_METHODS=acpi-support fi # # Try the SUSPEND_METHODS in order. # for METHOD in $SUSPEND_METHODS; do case $METHOD in none) exit ;; dbus-pm) if [ -x /usr/bin/dbus-send ] ; then # Call the power management daemon (which, if it is # running, we probably don't know about, since we send # keys if we detect one running that we know of). if /usr/bin/dbus-send --session \ --dest=org.freedesktop.PowerManagement \ --type=method_call \ --print-reply \ --reply-timeout=2000 \ /org/freedesktop/PowerManagement \ org.freedesktop.PowerManagement.$DBUS_METHOD ; then # The other side exists, we have access to it, # and it received the message. It may have # failed (I tested this: if pm-suspend returns
Bug#496911: setting package to acpi-support acpi-support-base, tagging 496911
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-7) unstable; urgency=low # # * Always consider a dbus-send call for a suspend method failed if #dbus-send returns an error code (Closes: #496911) # package acpi-support acpi-support-base tags 496911 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: attached file resolves the problem
Great! It's been uploaded as part of 0.109-7, so that should hit unstable soon. Cheers, Bart Christian Gogolin wrote: Hi, with the attached file suspension works with acpi-support 0.109-6 and acpi-support-base 0.109-6. Regards, Christian Bart Samwel wrote: Hi again Christian, Could you confirm that if you replace /usr/share/acpi-support/suspendorhibernate by the attached file, that it works? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. While working on a fix for this problem I noticed that acpi-support uses on_ac_power to find power state changes, and that has an unopened bug in this exact same area as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473629 Should we be tagging this one as serious as well? Since on_ac_power will simply not work on ACPI systems with the kernels that will ship with lenny, powermgmt-base will be badly broken. The acpi-support code is very interesting in other ways as well: it uses the broken on_ac_power to determine power state *changes* (to prevent calling scripts when nothing has changed), but then proceeds to use its own broken logic to determine the actual power state (to determine which scripts to call)... I'll have a fix ready tonight. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: setting package to acpi-support acpi-support-base, tagging 491396
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-6) unstable; urgency=high # # * /etc/acpi/battery.d is ignored on newer kernels (Closes: #491396) package acpi-support acpi-support-base tags 491396 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Bart Samwel wrote: Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. While working on a fix for this problem I noticed that acpi-support uses on_ac_power to find power state changes, and that has an unopened bug in this exact same area as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=473629 Should we be tagging this one as serious as well? Since on_ac_power will simply not work on ACPI systems with the kernels that will ship with lenny, powermgmt-base will be badly broken. The acpi-support code is very interesting in other ways as well: it uses the broken on_ac_power to determine power state *changes* (to prevent calling scripts when nothing has changed), but then proceeds to use its own broken logic to determine the actual power state (to determine which scripts to call)... I'll have a fix ready tonight. OK, a fix has been uploaded. I guess this should hang around in unstable for a couple of days before I send it as a proposed update to the release team, right? (My experience with this process is limited, so hints are appreciated. ;-) ) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Raphael, Raphael Hertzog wrote: severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? The bug is in acpid, right? I don't think I can do much else other than bug the acpid maintainer. Unless I want to go and NMU of course. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Raphael Hertzog wrote: On Mon, 18 Aug 2008, Bart Samwel wrote: Agreed. Bart, can you handle that? The bug is in acpid, right? Why? /etc/acpi/power.sh is part of acpi-support and needs to be updated to use /sys/class/power_supply/ instead of /proc/acpi/ac_adapter/ which has been removed in recent kernels (2.6.26 in Debian sid, intended for lenny)... I don't see what concerns acpid here. Oh, aaargh, I've done some bad reading here. Will get this fixed. BTW, if I fix anything for this, do I need to make a special update containing *only* a fix for this bug, or can I piggyback some other nasty bug fixes onto the update? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491396: This bug is affecting lenny and should be fixed
Hi Christian, Christian Perrier wrote: Quoting Raphael Hertzog ([EMAIL PROTECTED]): severity 491396 serious thanks On Sat, 16 Aug 2008, Christian Perrier wrote: Therefore, I think this deserves to be fixed for lenny, unless we want to release with a non-working ACPI support. I should even have tagged the bug as release critical, imho. Leaving that up to the maintainer. Agreed. Bart, can you handle that? Well, I'm indeed really sorry for putting such pressure but this is the only way to handle these things after the very very annoying decision taken by the Kernel Team when disabling /proc/acpi so close to the release. Yeah, that is a very annoying decision. IMO Work without /proc/acpi is something that should go in as a general release goal like the bash transition -- don't change the default in the first release, but file bugs against anything that breaks if you do. Then change the default in the next release. I'm still pondering raising an RC issue on linux-2.6 for /proc/acpi to be back. I know that bugs have been reassigned to various packages when they were reported but I think I would then go up to CTTE as an attempt to revert to /proc/acpi support to be reintroduced in the kernel. There may be much more breakage waiting to be found, and there's no time to fix it all. These kind of changes need months of testing! I only regret not doing that much earlier when I noticed that 2/3 of my power management utilities had been broken without prior notice. Of course, when it comes at acpi-support itself, I think that supporting /sysfs would be good anyway. Definitely, and it was already planned for a future update -- I just wasn't aware that this default had changed already. :-/ Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489226: acpi-support: Upgrading to 109-5 fails on an HP nx9420
Marcus Lundblad wrote: When running aptitude safe-upgrade in Lenny it gets stuck when configuring acpi-support: Checking battery state... /dev/sda: setting Advanced Power Management level to 0xfe (254) Then it hangs there... Hi Marcus, Grave indeed... No clue why this happens, so I'll look at it this evening. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#485564: acpi-support: please go back to legacy mode by default
Lucas Nussbaum wrote: Package: acpi-support Version: 0.109-3 Severity: serious Justification: renders package unusable Hi, For the last two years, acpi-support worked perfectly fine for me. My laptop suspended and resuming very reliably. But recently, with version 0.109-3, my laptop stopped resuming, because you switched to using pm-utils when there's no dbus/hal app. Changing SUSPEND_METHODS back to acpi-support solves the problem. Please revert to the upstream behaviour, and use the legacy mode, that benefits from years of development on the Ubuntu side. If I install acpi-support, it's because I want to benefit from that, so it's totally counter-productive to use pm-utils instead of the scripts that acpi-support ships. If you want to do that, please package that separately. Unfortunately the Ubuntu implementation is deprecated and receives not nearly as much testing as it used to, since their default install does suspend/resume using hal (which delegates to pm-utils). All their development efforts go into pm-utils nowadays. So I *really* want to move to pm-utils for new installs. I guess I'll move the default back to acpi-support for existing installs, but as far as I'm concerned that's as far as it should go. Perhaps I will split off the acpi-support suspend functionality into a separate package. The acpi-support package has two distinct and very different functions, one is to make special buttons/keys on laptops work, and the other is to do suspend. The two functionalities are in fact largely independent, so it would be very easy to make an acpi-support-suspend package containing only the suspend support, and an acpi-support package containing only the button/key support. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475926: Suggestion: a threshold to prevent similar problems
Francois Marier wrote: I was just thinking about this bug and I was wondering whether there should be a threshold under which any value is considered invalid. For example, a value of 0% left on battery is likely to be invalid (as in improperly reported) since it makes little sense. So in the case where the battery status is under the threshold, a warning could be printed to the logs, but the action (shutdown) would be ignored. Of course, the real fix for the bug reported by Nigel is to check for the existence of the file before reading from it, but I was thinking about adding an extra sanity check to prevent similar problems in the future. Sounds like a good plan to do both. I'll whip up a fix today. Nigel, thanks for reporting, and my apologies for breaking your system... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475926: Suggestion: a threshold to prevent similar problems
Bart Samwel wrote: Francois Marier wrote: I was just thinking about this bug and I was wondering whether there should be a threshold under which any value is considered invalid. For example, a value of 0% left on battery is likely to be invalid (as in improperly reported) since it makes little sense. So in the case where the battery status is under the threshold, a warning could be printed to the logs, but the action (shutdown) would be ignored. Of course, the real fix for the bug reported by Nigel is to check for the existence of the file before reading from it, but I was thinking about adding an extra sanity check to prevent similar problems in the future. Sounds like a good plan to do both. I'll whip up a fix today. Nigel, thanks for reporting, and my apologies for breaking your system... The fix is ready in the upstream. That means I'll have to do an upstream release first and then I'll get my sponsor to do the Debian upload immediately afterwards. This will have to wait until tomorrow though -- I have to get some sleep first. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451748: acpi-support-base: trying to overwrite `/usr/share/acpi-support/policy-funcs', which is also in package acpi-support
Rémi Vanicat wrote: Package: acpi-support-base Version: 0.103-3 Severity: grave Justification: renders package unusable When upgrading today, aptitude faile to install acpi-support-base because it is trying to overwrite `/usr/share/acpi-support/policy-funcs', which is also in package acpi-support. Please, add a Replace/Conflict as needed. Thanks for reporting. Raphael, I've committed a potential fix which adds a few conflicts. I'm hoping this will get the package managers to do the right thing -- uninstall all acpi-support before installing the new versions. Do you think this will work? I don't know enough about how smart these tools are nowadays... Cheers, Bart
Bug#448710: acpi-support: On notebooks the ACPI system causes the drive to retract every minute and thus decreases disk life by a high amount.
Marco Schuster wrote: Package: acpi-support Version: 0.103-1 Severity: critical Justification: causes serious data loss (See also https://launchpad.net/bug59695.html for corresponding Ubuntu bug!) On a notebook with ACPI enabled, in battery mode the disk is retracted after 1 minute of idling. This leads to ~7000 retracts in only 100 hrs total runtime - and a notebook disk can handle only up to 600.000 retracts; this decreases the total life of a dsik to ~138 days, which is not even a half year. This is a dupicate, merging. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447571: Bug #447571
Hi Eddy, Are there any scripts in /etc/acpi/suspend.d that are not executable? If so, does making them executable (and also the scripts in /etc/acpi/resume.d) fix hibernation for you? Cheers, Bart
Bug#350280: Issue with latest laptop-mode-tools deb
Package: laptop-mode-tools Version: 1.21-1 Severity: critical Torsten Wolf wrote: Hi! As I'm not sure whether the following is intended, I contact you on this way instead of submitting a bug report. Today, apt-get updated laptop-mode-tools to version 1.21-1 (debian unstable). An ls / as well as the output of dpkg -L laptop-mode-tools yields: [...] /laptop-mode /laptop-mode/batt-start /laptop-mode/batt-stop /laptop-mode/lm-ac-start /laptop-mode/lm-ac-stop /laptop-mode/nolm-ac-start /laptop-mode/nolm-ac-stop Looking into /usr/sbin/laptop_mode indicates, that the correct location for these directories would be /etc/laptop-mode/ . Did I get something wrong or is there a bug in the current package? WTF? That's not right at all! I'm submitting this to the BTS as critical so that there's a record of the problem, and I'm going to fix this up right away... --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345417: laptop-mode-tools: Purging leaves an invalid symlink for syslog.conf - /etc/syslog-on-battery.conf behind.
Francesco Paolo Lovergine wrote: It would be better avoiding completely to upset user configuration in that way IMHO. I agree that it would be nice -- but it's impossible. :/ Anyway, this configuration modification is only done on the administrator's request (lm-syslog-setup), so he must have agreed to the modification. The problem here is that the original config is not restored on uninstall, as would be expected. Thanks for reporting, I'll have it fixed in the next release! If the same problem exists in sarge as I suspect, managing a proposed-update and patching to save poor users of stable would be nice, too. I'm not so sure about that. The problem only occurs on a very rare combination where people have run lm-syslog-setup and then PURGE laptop-mode-tools. This is the first time I've ever heard about the problem, so I don't think it's common enough to warrant an update in sarge. Is there a Debian policy for what warrants an update on stable? --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345417: laptop-mode-tools: Purging leaves an invalid symlink for syslog.conf - /etc/syslog-on-battery.conf behind.
Francesco P. Lovergine wrote: Package: laptop-mode-tools Severity: serious Justification: causes user configuration loss After purging the package, I discovered my syslog ceased to work. I found a dangling symlink /etc/syslog.conf - /etc/syslog-on-battery.conf This causes sysklog stop working at restart and user unable to restore again his old configuration file in anyway. At least keep the user original configuration in a safe place is mandatory. Agreed. This is definitely a problem. It would be better avoiding completely to upset user configuration in that way IMHO. I agree that it would be nice -- but it's impossible. :/ Anyway, this configuration modification is only done on the administrator's request (lm-syslog-setup), so he must have agreed to the modification. The problem here is that the original config is not restored on uninstall, as would be expected. Thanks for reporting, I'll have it fixed in the next release! --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
