Bug#328118: /usr/sbin/laptop_mode: line 199: [: yes: integer expression expected
Martin Michlmayr wrote: * Bart Samwel [EMAIL PROTECTED] [2005-11-06 21:26]: FYI, the bug is fixed in the 1.11 version of laptop-mode-tools, which you can download at the laptop-mode-tools homepage: http://www.xs4all.nl/~bsamwel/laptop_mode/tools Is your sponsor still busy? If so, I can probably sponsor this upload. Well, I've since switched sponsors because of this, but my new sponsor seems just as busy. I'd be delighted if you'd do the upload. The source package is here: http://www.xs4all.nl/~bsamwel/laptop_mode/tools/downloads/debian/src Thanks very much for helping me out! (BTW, if you're less busy than the other guys, would you mind sponsoring some more uploads afterwards?) --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341057: laptop-mode-tools: CPU frequency governor not set
Chung-chieh Shan wrote: Package: laptop-mode-tools Version: 1.11-1 Severity: normal Tags: patch THIS_CPU_GOVERNOR is misspelled as THIS_GOVERNOR in /usr/sbin/laptop_mode. Thanks for reporting, I'll have it fixed in the next version. BTW, if this bug is marked patch, where's the patch? ;-) --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341322: laptop-mode-tools thinks my / is not ext3 or not mountet as ext3
Andreas Pakulat wrote: since the last upgrade of laptop-mode-tools (to version 1.11-1) laptop-mode-tools always issues a BIG FAT WARNING during boot and when I restart it manually. The problem seems to be that it cannot remount / setting another commit-timeout. Now my Kernel has ext3 support built into it, it mounts / as ext3 and I do not see any option indicating a specific kernel option to disable the commit Option. I have other ext3 partitions that don't seem to issue any warning. Hmmm, if it issues this warning then your root filesystem probably *isn't* mounted as ext3 for some reason. Otherwise laptop-mode-tools would be able to remount with a different commit interval. You say that your kernel has ext3 support built-in, but are you sure ext3 is not built as a module? Could you do the following: 1. Show me the entries for your root fs in /proc/mounts, /etc/mtab and /etc/fstab? 2. Do a mount / -o remount,commit=600 and show me the output. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341322: laptop-mode-tools thinks my / is not ext3 or not mountet as ext3
Hi Andreas, Andreas Pakulat wrote: I guess I should have put some evidence into the report, now here it comes: [EMAIL PROTECTED]:~mount | grep hda2 /dev/hda2 on / type ext3 (rw,errors=remount-ro) Ah, mount thinks it's ext3. :) Unfortunately, mount simply copies this from fstab at bootup, as it can't determine it from the kernel. [EMAIL PROTECTED]:/bootuname -r 2.6.14-cherry+radeon+ipw2100+ieee80211 [EMAIL PROTECTED]:/bootgrep EXT3 config-2.6.14-cherry+radeon+ipw2100+ieee80211 CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set You say that your kernel has ext3 support built-in, but are you sure ext3 is not built as a module? see above. OK, it sure looks right. (BTW, a more direct way of checking this is by looking in /proc/config.gz.) Could you do the following: 1. Show me the entries for your root fs in /proc/mounts, /etc/mtab and /etc/fstab? [EMAIL PROTECTED]:~cat /etc/mtab /dev/hda2 / ext3 rw,errors=remount-ro 0 0 [EMAIL PROTECTED]:~cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext2 rw,nogrpid 0 0 Is this right? The output of proc mounts seems a bit strange to me... It does. The kernel doesn't lie, and I know /etc/mtab does lie about the root fs -- it simply mimics fstab, regardless of the actual mounted fstype. 2. Do a mount / -o remount,commit=600 and show me the output. [EMAIL PROTECTED]:~mount / -o remount,commit=600 mount: / not mounted already, or bad option That's ext2, definitely. Hmm, now it gets interesting... Aaah, Ok found this in the kern.log: Nov 29 23:11:51 morpheus kernel: fill_kobj_path: path = '/block/hda/hda2' Nov 29 23:11:51 morpheus last message repeated 2 times Nov 29 23:11:51 morpheus kernel: VFS: Mounted root (ext2 filesystem) readonly. Why the hell is it mounted as ext2, when it really is ext3? I recently removed the journal via tune2fs -O ^has_journal /dev/hda2 and later I added it again using tune2fs -O has_journal /dev/hda2. Maybe that got something to do with it... Do you have any idea? If not please close this bug report as invalid and I'll try to find some help und debian-user-german. You added the option but probably didn't recreate the journal file itself. Try tune2fs -J /dev/hda2. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341322: laptop-mode-tools thinks my / is not ext3 or not mountet as ext3
Andreas Pakulat wrote: On 30.11.05 13:18:04, Bart Samwel wrote: You added the option but probably didn't recreate the journal file itself. Try tune2fs -J /dev/hda2. It's a small j, but anyway it's ok now. But this leads to the following: Why did laptop-mode-tools try to remount my / with commit? Does it rely on /etc/fstab for the FS type? If this is the case, could it be improved to use /proc/mounts instead, so that it checks the real FS type and not the declared one? Hmmm, when I developed this /proc/mounts didn't show the real type. Of the lines in your /proc/mounts: rootfs / rootfs rw 0 0 /dev/root / ext2 rw,nogrpid 0 0 I got only the first one at the time. Perhaps it's time to fix that now. However, usually a mismatch between /etc/fstab (or /etc/mtab) and /proc/mounts is something that people would actually want to *fix*. You were unknowingly running your root fs without journalling, and this seems to be the general case: I've only really heard about the BIG FAT WARNING from people who were *really surprised* that their root fs was mounted as ext2 instead of ext3. For that reason I'm not really in a hurry to remove the warning. :) --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341322: laptop-mode-tools thinks my / is not ext3 or not mountet as ext3
Andreas Pakulat wrote: On 01.12.05 13:46:21, Bart Samwel wrote: Andreas Pakulat wrote: On 30.11.05 13:18:04, Bart Samwel wrote: You added the option but probably didn't recreate the journal file itself. Try tune2fs -J /dev/hda2. It's a small j, but anyway it's ok now. But this leads to the following: Why did laptop-mode-tools try to remount my / with commit? Does it rely on /etc/fstab for the FS type? If this is the case, could it be improved to use /proc/mounts instead, so that it checks the real FS type and not the declared one? Hmmm, when I developed this /proc/mounts didn't show the real type. Of the lines in your /proc/mounts: rootfs / rootfs rw 0 0 /dev/root / ext2 rw,nogrpid 0 0 I got only the first one at the time. Perhaps it's time to fix that now. However, usually a mismatch between /etc/fstab (or /etc/mtab) and /proc/mounts is something that people would actually want to *fix*. You were unknowingly running your root fs without journalling, and this seems to be the general case: I've only really heard about the BIG FAT WARNING from people who were *really surprised* that their root fs was mounted as ext2 instead of ext3. For that reason I'm not really in a hurry to remove the warning. :) Hmm,in that case leaving the Warning is probably best, but you could remove the mount -o remount,commit in the case where an ext3 is mounted as ext2. Also I think the warning could mention something like only /proc/mounts shows the real fstype, mount and /etc/mtab lie in the case of / I'll do the latter, and add something like configure the filesystem with its actual type in /etc/fstab to remove this warning. Thanks. --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]
Bug#345808: laptop-mode-tools: do not mount with noatime by default
Clemens Buchacher wrote: Package: laptop-mode-tools Version: 1.11-1 Severity: wishlist Hi, Some applications (mutt, for example) depend on file access time updates so I think the CONTROL_NOATIME option should be disabled by default. Not knowing where to look I only found out by chance why mutt did not behave correctly. Hi Clemens, This question _is_ in the FAQ. However, I can see that you probably didn't know which FAQ to look in. :) I agree that it should be disabled by default, it doesn't save much: it prevents a spinup every 10 minutes, but only if NOBODY modified ANY file within that time. A very unlikely situation. Thanks! --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345521: laptop-mode-tools: Wrong path in /etc/acpi/actions/lm_battery.sh
Daniel Maier wrote: Package: laptop-mode-tools Version: 1.11-1 Severity: minor Wrong path to lm_battery.sh mentioned in line /etc/acpi/actions/lm_battery.sh:52. Should be '/etc/acpi/actions/lm_battery.sh' instead of '/etc/acpi/lm_battery.sh'. Ah, you're right. Will be fixed in the next version. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345523: laptop-mode-tools: typo in config
Daniel Maier wrote: Package: laptop-mode-tools Version: 1.11-1 Severity: minor In /etc/laptop-mode/laptop-mode.conf:107 'Shoudl' should be 'Should'. Thanks! --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#343967: laptop-mode-tools: CONTROL_DPMS_STANDBY doesn't work
Chung-chieh Shan wrote:
Package: laptop-mode-tools
Version: 1.11-1
Severity: normal
The DPMS control feature in laptop-mode doesn't work. One problem is
that the command
who |grep \:[0-9].*\: |awk '{print $1;$2}'
in /usr/sbin/laptop_mode does not generate a list of users and displays.
(By the way, xwindows in laptop-mode.conf should spelled X Window.)
I'll look into it, thanks!
--Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335493: laptop-mode-tools: VERBOSE might be set to yes by /etc/default/rcS
Hi Luca, Luca Capello wrote: On Mon 24 Oct 2005 09:52 +0200, Guido Guenther wrote: by laptop-mode-tools on every boot. I'd suggest simply removing $VERBOSE from the tests since this is an old config option anyway: Well, the problem is that /usr/sbin/laptop_mode has that check specifically for old config options: = [EMAIL PROTECTED]:~$ grep -n old /usr/sbin/laptop_mode 89: # Support for old config settings [EMAIL PROTECTED]:~$ = So, removing the check can create some glitches (not real a problem) to peopel who still have an old /etc/laptop-mode/laptop-mode.conf, i.e. laptop-mode-tools 1.10-1, so sarge (1.05-1). Not really, actually. If you check the change log, you can see that the VERBOSE option was introduced in version 1.06 on July 28, and renamed to VERBOSE_OUTPUT in version 1.07 on July 29. I'm not even sure whether 1.06 was ever uploaded into the Debian archive -- my sponsor doesn't usually respond within a day. I also distinctly remember having to close some bugs manually because one of the uploads never made it in, and when you skip an upload the Debian bug tracking system doesn't process the (Closes: #NN) items in the intervening releases. It might well have been the 1.06 release that was skipped. A solution different from that Steve Langasek proposed [1] should be to save the Debian $VERBOSE at the top of the script and unset it. Then, if an old conf script is present and it contains $VERBOSE, this one is used. At the end, read the saved Debian $VERBOSE and set it again :-D The recently released version 1.11 does an unset. The reset to the old value doesn't need to be done, because the init script is called as a subprocess, which only inherits the environment and doesn't share it. BTW, the 1.11 package wasn't uploaded into Debian yet at this moment, as I am not a Debian Developer myself, and I am dependent on a sponsoring DD for the upload. You can download the package at the laptop mode tools homepage, if you so desire: http://www.xs4all.nl/~bsamwel/laptop_mode/tools --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335493: laptop-mode-tools: VERBOSE might be set to yes by /etc/default/rcS
Luca Capello wrote: Hello Bart! On Thu 03 Nov 2005 21:35 +0100, Bart Samwel wrote: Luca Capello wrote: So, removing the check can create some glitches (not real a problem) to peopel who still have an old /etc/laptop-mode/laptop-mode.conf, i.e. laptop-mode-tools 1.10-1, so sarge (1.05-1). Not really, actually. If you check the change log, you can see that the VERBOSE option was introduced in version 1.06 on July 28, and renamed to VERBOSE_OUTPUT in version 1.07 on July 29. Sorry, my fault. I based my words on reports that the first time the bug appeared was in 1.10-1, without checking for correctness. Anyway, thank you for the clarification :-) No problem! A solution different from that Steve Langasek proposed [1] should cut The recently released version 1.11 does an unset. The reset to the old value doesn't need to be done, because the init script is called as a subprocess, which only inherits the environment and doesn't share it. Again, thank you for the clarification, very useful (I'm still missing some basics *nix aspects, especially when they are too technical). You can download the package at the laptop mode tools homepage, if you so desire: Done ;-) And, does it work? ;) --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328118: /usr/sbin/laptop_mode: line 199: [: yes: integer expression expected
Le0n_84 debianized wrote: i've solve this problem editing /usr/sbin/laptop_mode and changing if [ $VERBOSE_OUTPUT -ne 0 ] ; then with if [ $VERBOSE_OUTPUT != 0 ] ; then next time i've reboot the machine it told me Sun Nov 6 18:38:17 2005: Enabling laptop mode: Laptop Mode Tools 1.10 Sun Nov 6 18:38:17 2005: On AC power: Setting action to stop because ENABLE_LAPTOP _MODE_ON_AC is not set. instead of /usr/sbin/laptop_mode: line 199: [: yes: integer expression expected Thank you for your contribution. Unfortunately, your solution is not correct: it only hides the symptoms instead of fixing the problem. In bash script, the != operator means string comparison, while the -ne operator indicates integer comparison. The value of VERBOSE_OUTPUT, at the point where the error occurs, is yes, which is completely wrong, unexpected by the design of laptop-mode-tools. Changing -ne into != hides this fact (as indeed yes != 0), but does not fix the cause of the problem -- the wrong value of VERBOSE_OUTPUT. In fact, as Steve Langasek noted earlier in the comments of this bug report, the value of VERBOSE_OUTPUT came from a completely different place, which set it to yes/no and not to 0/1: the Debian init system sets a variable called VERBOSE, which laptop-mode-tools interprets as equivalent to VERBOSE_OUTPUT because of backward compatibility with an earlier config version. The correct solution is to ignore the setting of VERBOSE, not to change the style of comparison. FYI, the bug is fixed in the 1.11 version of laptop-mode-tools, which you can download at the laptop-mode-tools homepage: http://www.xs4all.nl/~bsamwel/laptop_mode/tools It has not been uploaded yet because my sponsor has been busy. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328118: /usr/sbin/laptop_mode: line 199: [: yes: integer expression expected
Le0n_84 debianized wrote: as you can see i don't know too much shell scripting :-D in fact after i've modified and rebooted the machine i saw many messages about the option PARTITION in laptop-mode.conf, so i thought that this solution was wrong... i've installed the 1.11-1 version now...thank you for that link and for the explanation about the difference! No problem, hope it works for you now! --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#249501: Debian bug 249501
Hi Matthias, I would actually _love_ to have a way of detecting the lid state from pbbuttonsd. My package laptop-mode-tools can enable laptop mode when the lid is closed, but only on ACPI currently. I would like to extend this functionality to pbbuttonsd as well! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333203: laptop-mode-tools: Laptop-mode complains when hdparm is not installed
Thomas Petazzoni wrote: Package: laptop-mode-tools Version: 1.10-1 Severity: normal Hi, laptop-mode-tools only Recommands: hdparm. However, the /usr/sbin/laptop_mode script complains that hdparm cannot be found at line 892 when runned at system startup. I'll move it to depends:. Thank you. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325186: laptop-mode-tools crasher: hda: DMA timeout error
I'm sorry to add this so late, the discussion with the submitter was not recorded in the bug report. My original response was: - The FAQ (http://www.xs4all.nl/~bsamwel/laptop_mode/tools/faq.html) has an entry on this, titled I experience system freezes every once in a while, is this normal?. The answer currently reads: This is a bug in the Linux kernel, introduced in version 2.6.11, which is triggered by something laptop mode tools does. Try setting CONTROL_HD_POWERMGMT=0. This fixes the freezes for some people. Otherwise, for now, downgrade to a kernel 2.6.10 or earlier. Do any of the suggested solutions help? - To which submitter replied: - I will try them and let you know. I do worry that it will crash again as it crashed with laptop-mode-tools using kernels 2.6.9 thru 2.6.12. - The conversation ended as follows: - Yeah... though it's possible that was a random crash. I have ndiswrapper and some dell driver with that kernel so it's not clean enough for me to say for *certain* it was laptop-mode. I'm trying the HD Pwrmgmt = 0 setting currently. I haven't had any crashes since I turned this option off. I suggest making it the default... Yeah, I'll do that. Better safe than sorry. :/ - --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336294: laptop-mode-tools: dmesg complains hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
This will be fixed in the next release. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328432: laptop-mode-tools: why hasn't this bug been fixed yet?
Luis Mondesi wrote: [...] Yet I wonder why it hasn't been fixed yet. This is a very minor cosmetic bug in a pretty new feature (the status command was introduced in version 1.06, on July 28). It'll be fixed in the next release, which I have planned for somewhere in the next month. --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#240388: Does pasting from kate into konsole still give garbage?
Hi Josh, Josh Metzler wrote: I just tried the experiment you suggested at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=240388 with kde 3.5.5, and got the expected result - what I had selected was now pasted into my new file. I am using kde as my desktop enviroment, though. Could you verify if you still get garbage in your file or not? I'll have to check it out, I don't think I have a running Gnome install at the moment. I'll get back to you on this! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398179: laptop-mode-tools: laptop-mode needs to be reinitialized on resume
John Wright wrote: Package: laptop-mode-tools Version: 1.32-1 Severity: normal Tags: patch On my iBook, if I suspend and then resume, laptop-mode no longer works. Running '/etc/init.d/laptop-mode restart' does the trick, so I've included a patch to etc/power/scripts.d/laptop-mode that makes it recognize a 'resume' argument and run the above command. (This might need to happen on other architectures as well; I don't have another laptop that actually suspends properly so I'm not sure.) Hi John, Thanks for the patch! BTW, what kind of suspending do you use, do you use the hibernate script? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394557: laptop-mode-tools: LVM partitions not supported
Hi Mikko, Mikko Rapeli wrote: The problem is quite simple, though I don't understand the reasons for the laptop_mode coding style with environment variables. With the fix below I get LVM partitions remounted: I see, thanks for reporting this! Unfortunately adding the spaces to the beginning and end is somewhat necessary, because otherwise (for instance) the partition /dev/automatic_thingummy will be found using grep auto. I think the trick would be to do something like: if ( (echo -n ; echo -n $PARTITIONS ; echo -n ) | grep $DEV /dev/null ) ; then Does it work for you that way? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394557: laptop-mode-tools: LVM partitions not supported
Mikko Rapeli wrote: On Sun, Oct 22, 2006 at 08:14:58AM +0200, Bart Samwel wrote: [...] grep auto. I think the trick would be to do something like: if ( (echo -n ; echo -n $PARTITIONS ; echo -n ) | grep $DEV /dev/null ) ; then Does it work for you that way? I didn't try, since I found a cleaner way to do the shell wild card expansion. What do you think? Expansion is postprocessing and all the comparisons and white space additions are left as they are: [...] +# Expand shell wild cards +PARTITIONS=$( echo $PARTITIONS ) Yeah, _that_ is the way to go. Nice small patch, thanks -- it'll be in the next version, with kudos in the release notes! :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389218: laptop-mode-tools: CPU settings only hit CPU #0
John Goerzen wrote: My Macbook Pro has a Core Duo CPU. Each core can run at its own frequency and have its own governor. laptop-mode-tools, though configured to automatically switch the system to the conservative governor when running on battery power, only actually manages to switch CPU #0 to the conservative governor. CPU #1 stuck with the performance governor. The tool should be adjusting *BOTH* CPUs. Hi John, Sorry for the late response. I've looked at the code and it looks like it should do the right thing. Could you set VERBOSE_OUTPUT=1 in laptop-mode.conf, then run /etc/init.d/laptop-mode restart and send me the output? That'll help me figure out what's wrong here. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348923: VERBOSE_OUTPUT destroys /var/log/acpid
Philippe Teuwen wrote: Package: laptop-mode-tools Version: 1.11-1 Severity: normal Tags: patch When setting VERBOSE_OUTPUT=1 it truncated /var/log/acpid and only the last few lines are present. This is due to the /dev/stdout redirections. This is solved by changing them to /dev/stdout Hyper-compressed patch :-) sed -i 's/ \( \?$OUTPUT\)/ \1/g;' laptop_mode BTW maybe this should be notified to the acpid maintainer as well as this is not normal that a simple client handler can kill all the logfile of acpid! Just for fun because it puzzled me: $ echo one /tmp/t; ( echo two /dev/stdout ) /tmp/t;cat /tmp/t two So you can indeed destroy a file even with the operator! Wow. This is REALLY weird. Apparently simply attaches the output file descriptor to the given file, and the operator simply does the same but it truncates the output file after attaching. Nice find. :-) And apparently the logging of acpid is not handled by any syslog daemon. I agree that we should report this to the acpid maintainer as well. As you reported the bug, would you like to take care of this? --Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: still reproducable for me
Hi Dave, The gnome-power-manager actually does some stuff and then forwards the request to HAL, which then forwards it to pm-utils. Acpi-support (in your configuration) actually forwards to gnome-power manager (that's what the dbus-pm suspend method does), so that's why acpi-support doesn't work. So it goes like this: acpi-support - gnome-power-manager - hal - pm-utils HAL doesn't add anything AFAIK, and if pm-suspend works, then the problem must be in the stuff that gnome-power-manager adds. I'll reassign the bug to gnome-power-manager then. Cheers, Bart Dave O wrote: It does seem to, yes. Looks like the problem happens for me when suspending through gnome-power-manager. I didn't see anything in gconf about suspend method for that program, so I'm not sure what to do next. On Thu, 9 Oct 2008, Bart Samwel wrote: Hi Dave, I see that you are using pm-utils for suspend (the dbus-pm and dbus-hal methods eventually go to pm-utils as well). Does your laptop suspend and resume correctly when you issue the command pm-suspend (as root)? Cheers, Bart Dave O wrote: I have the same issue, since the upgrade to this version, using an x61. It occurs more frequently than described in the original report for me, in fact nearly every time. Here's the non-comment lines from the config file: SUSPEND_METHODS=dbus-pm dbus-hal pm-utils ACPI_SLEEP=true ACPI_HIBERNATE=true ACPI_SLEEP_MODE=mem MODULES= MODULES_WHITELIST= SAVE_VBE_STATE=true VBESTATE=/var/lib/acpi-support/vbestate POST_VIDEO=true USE_DPMS=true HIBERNATE_MODE=shutdown LOCK_SCREEN=true STOP_SERVICES= RESTART_IRDA=false SKIP_INTERFACES=dummy qemu Please let me know if I can provide more detail for you. Thanks! Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502246: Duplicate
Merwok wrote: My quick search before posting was obviously too quick: this bug is a duplicate of #495364. Sorry. I don’t send a message with “merge” because I’m unfamiliar with the system. Oh, I was too quick to reply -- thanks anyway for the report, I'll do the merge. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502246: laptop-mode-tools: inconsistency in conf file hal-polling
Merwok wrote: Hello. I was poking around in /etc/laptop-mode/conf.d on Lenny and tweaking thinks when I noticed this contradiction in hal-polling.conf, lines 29-30: # Enable HAL polling on AC AC_DISABLE_HAL_POLLING=1 I don’t know whether to follow the comment or the variable name for the last setting; I guess the name is right, since the default value is true, but can’t be sure. The comment should be corrected then. Thanks for the report, will fix! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Marc Haber wrote: On Tue, Jul 29, 2008 at 08:35:10PM +0200, Bart Samwel wrote: Marc Haber wrote: On Tue, Jul 29, 2008 at 04:45:23PM +0200, Bart Samwel wrote: Marc Haber wrote: Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Can this behavior of laptop-mode-tools be disabled by configuration? Well, you can set CONTROL_MOUNT_OPTIONS to 0 in laptop-mode.conf. But that does mean that laptop mode won't work anymore. If you're going to do that, you might as well uninstall it... So this option will completely disable all features of laptop-mode, not only the remount upon power loss? Wee... not quite. It will not disable all features of laptop-mode-tools, but it will disable the remount on power loss, yes. And that will make the spin-down-the-hard-drive option (a.k.a. laptop mode) fail to work, because changing the mount options is required if the hard drives need to spin down. You can still use the other modules. Anyway, you could try and report this for the upstream kernel at: http://bugzilla.kernel.org/ They should be able to debug and fix this! I could do it myself BTW, but since I can't reproduce the problem it's better if you report it and help them find out what's going on. Keep me posted -- I want to know what happens with this, because it definitely isn't nice. :-/ Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496911: additional information
Michael Marsh wrote: I'm seeing this same bug, I believe. I've tried running # /etc/acpi/sleepbtn.sh # /etc/acpi/sleep.sh # /usr/share/acpi-support/suspendorhibernate suspend and all three have no effect. By adding a call to the syslogger to suspendorhibernate, I was able to confirm that Fn-F4 on my Thinkpad T23 *is* ultimately calling this (and sleep.sh, as well). I also added +x to the shell invocation, which gives me: + . /etc/default/acpi-support ++ SUSPEND_METHODS='dbus-pm dbus-hal pm-utils' ++ ACPI_SLEEP=true ++ ACPI_HIBERNATE=true ++ ACPI_SLEEP_MODE=mem ++ MODULES= ++ MODULES_WHITELIST= ++ SAVE_VBE_STATE=true ++ VBESTATE=/var/lib/acpi-support/vbestate ++ POST_VIDEO=true ++ USE_DPMS=true ++ HIBERNATE_MODE=shutdown ++ LOCK_SCREEN=true ++ STOP_SERVICES= ++ RESTART_IRDA=false ++ SKIP_INTERFACES='dummy qemu' + . /usr/share/acpi-support/power-funcs ++ umask 022 ++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 ++ POWERSTATE=/var/lib/acpi-support/powerstate ++ HDPARM='/sbin/hdparm -q' ++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/device-funcs + . /usr/share/acpi-support/policy-funcs ++ . /usr/share/acpi-support/power-funcs +++ umask 022 +++ PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/bin/X11 +++ POWERSTATE=/var/lib/acpi-support/powerstate +++ HDPARM='/sbin/hdparm -q' +++ LIDSTATE=/var/lib/acpi-support/lidstate + . /usr/share/acpi-support/key-constants ++ KEY_RESERVED=0 ++ KEY_ESC=1 ++ KEY_1=2 ++ KEY_2=3 ++ KEY_3=4 ++ KEY_4=5 ++ KEY_5=6 ++ KEY_6=7 ++ KEY_7=8 ++ KEY_8=9 ++ KEY_9=10 ++ KEY_0=11 ++ KEY_MINUS=12 ++ KEY_EQUAL=13 ++ KEY_BACKSPACE=14 ++ KEY_TAB=15 ++ KEY_Q=16 ++ KEY_W=17 ++ KEY_E=18 ++ KEY_R=19 ++ KEY_T=20 ++ KEY_Y=21 ++ KEY_U=22 ++ KEY_I=23 ++ KEY_O=24 ++ KEY_P=25 ++ KEY_LEFTBRACE=26 ++ KEY_RIGHTBRACE=27 ++ KEY_ENTER=28 ++ KEY_LEFTCTRL=29 ++ KEY_A=30 ++ KEY_S=31 ++ KEY_D=32 ++ KEY_F=33 ++ KEY_G=34 ++ KEY_H=35 ++ KEY_J=36 ++ KEY_K=37 ++ KEY_L=38 ++ KEY_SEMICOLON=39 ++ KEY_APOSTROPHE=40 ++ KEY_GRAVE=41 ++ KEY_LEFTSHIFT=42 ++ KEY_BACKSLASH=43 ++ KEY_Z=44 ++ KEY_X=45 ++ KEY_C=46 ++ KEY_V=47 ++ KEY_B=48 ++ KEY_N=49 ++ KEY_M=50 ++ KEY_COMMA=51 ++ KEY_DOT=52 ++ KEY_SLASH=53 ++ KEY_RIGHTSHIFT=54 ++ KEY_KPASTERISK=55 ++ KEY_LEFTALT=56 ++ KEY_SPACE=57 ++ KEY_CAPSLOCK=58 ++ KEY_F1=59 ++ KEY_F2=60 ++ KEY_F3=61 ++ KEY_F4=62 ++ KEY_F5=63 ++ KEY_F6=64 ++ KEY_F7=65 ++ KEY_F8=66 ++ KEY_F9=67 ++ KEY_F10=68 ++ KEY_NUMLOCK=69 ++ KEY_SCROLLLOCK=70 ++ KEY_KP7=71 ++ KEY_KP8=72 ++ KEY_KP9=73 ++ KEY_KPMINUS=74 ++ KEY_KP4=75 ++ KEY_KP5=76 ++ KEY_KP6=77 ++ KEY_KPPLUS=78 ++ KEY_KP1=79 ++ KEY_KP2=80 ++ KEY_KP3=81 ++ KEY_KP0=82 ++ KEY_KPDOT=83 ++ KEY_103RD=84 ++ KEY_ZENKAKUHANKAKU=85 ++ KEY_102ND=86 ++ KEY_F11=87 ++ KEY_F12=88 ++ KEY_RO=89 ++ KEY_KATAKANA=90 ++ KEY_HIRAGANA=91 ++ KEY_HENKAN=92 ++ KEY_KATAKANAHIRAGANA=93 ++ KEY_MUHENKAN=94 ++ KEY_KPJPCOMMA=95 ++ KEY_KPENTER=96 ++ KEY_RIGHTCTRL=97 ++ KEY_KPSLASH=98 ++ KEY_SYSRQ=99 ++ KEY_RIGHTALT=100 ++ KEY_LINEFEED=101 ++ KEY_HOME=102 ++ KEY_UP=103 ++ KEY_PAGEUP=104 ++ KEY_LEFT=105 ++ KEY_RIGHT=106 ++ KEY_END=107 ++ KEY_DOWN=108 ++ KEY_PAGEDOWN=109 ++ KEY_INSERT=110 ++ KEY_DELETE=111 ++ KEY_MACRO=112 ++ KEY_MUTE=113 ++ KEY_VOLUMEDOWN=114 ++ KEY_VOLUMEUP=115 ++ KEY_POWER=116 ++ KEY_KPEQUAL=117 ++ KEY_KPPLUSMINUS=118 ++ KEY_PAUSE=119 ++ KEY_KPCOMMA=121 ++ KEY_HANGUEL=122 ++ KEY_HANJA=123 ++ KEY_YEN=124 ++ KEY_LEFTMETA=125 ++ KEY_RIGHTMETA=126 ++ KEY_COMPOSE=127 ++ KEY_STOP=128 ++ KEY_AGAIN=129 ++ KEY_PROPS=130 ++ KEY_UNDO=131 ++ KEY_FRONT=132 ++ KEY_COPY=133 ++ KEY_OPEN=134 ++ KEY_PASTE=135 ++ KEY_FIND=136 ++ KEY_CUT=137 ++ KEY_HELP=138 ++ KEY_MENU=139 ++ KEY_CALC=140 ++ KEY_SETUP=141 ++ KEY_SLEEP=142 ++ KEY_WAKEUP=143 ++ KEY_FILE=144 ++ KEY_SENDFILE=145 ++ KEY_DELETEFILE=146 ++ KEY_XFER=147 ++ KEY_PROG1=148 ++ KEY_PROG2=149 ++ KEY_WWW=150 ++ KEY_MSDOS=151 ++ KEY_COFFEE=152 ++ KEY_DIRECTION=153 ++ KEY_CYCLEWINDOWS=154 ++ KEY_MAIL=155 ++ KEY_BOOKMARKS=156 ++ KEY_COMPUTER=157 ++ KEY_BACK=158 ++ KEY_FORWARD=159 ++ KEY_CLOSECD=160 ++ KEY_EJECTCD=161 ++ KEY_EJECTCLOSECD=162 ++ KEY_NEXTSONG=163 ++ KEY_PLAYPAUSE=164 ++ KEY_PREVIOUSSONG=165 ++ KEY_STOPCD=166 ++ KEY_RECORD=167 ++ KEY_REWIND=168 ++ KEY_PHONE=169 ++ KEY_ISO=170 ++ KEY_CONFIG=171 ++ KEY_HOMEPAGE=172 ++ KEY_REFRESH=173 ++ KEY_EXIT=174 ++ KEY_MOVE=175 ++ KEY_EDIT=176 ++ KEY_SCROLLUP=177 ++ KEY_SCROLLDOWN=178 ++ KEY_KPLEFTPAREN=179 ++ KEY_KPRIGHTPAREN=180 ++ KEY_F13=183 ++ KEY_F14=184 ++ KEY_F15=185 ++ KEY_F16=186 ++ KEY_F17=187 ++ KEY_F18=188 ++ KEY_F19=189 ++ KEY_F20=190 ++ KEY_F21=191 ++ KEY_F22=192 ++ KEY_F23=193 ++ KEY_F24=194 ++ KEY_PLAYCD=200 ++ KEY_PAUSECD=201 ++ KEY_PROG3=202 ++ KEY_PROG4=203 ++ KEY_SUSPEND=205 ++ KEY_CLOSE=206 ++ KEY_PLAY=207 ++ KEY_FASTFORWARD=208 ++
Bug#496911: additional information
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! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497345: laptop-mode-tools should recommend psmisc
And thanks for reporting again! Cheers, Bart Daniel Moerner wrote: Package: laptop-mode-tools Version: 1.45-1 Severity: normal If I had noticed I would have filed this along with bug #497343. The configuration-file controller requires killall to function. killall is in psmisc, which is not priority required, and thus is not installed by default. Since laptop-mode-tools actually spits out an error message without killall, I think it might be better for laptop-mode-tools to depend on psmisc, instead of just recommend it. Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.6-10 Utilities for using ACPI power man ii hal 0.5.11-3 Hardware Abstraction Layer ii hdparm8.9-1 tune hard disk parameters for high pn sdparmnone (no description available) laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497343: laptop-mode-tools should recommend ethtool
Thanks for reporting, will fix! Daniel Moerner wrote: Package: laptop-mode-tools Version: 1.45-1 Severity: normal /etc/laptop-mode/conf.d/ethernet.conf uses ethtool to manipulate the wol and speed settings of ethernet devices. Other parts of laptop-mode-tools that use commands not in the package, like hdparm, have the package listed as a Recommend of laptop-mode-tools. I think the same should apply to ethtool. Thanks. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages laptop-mode-tools depends on: ii lsb-base 3.2-20 Linux Standard Base 3.2 init scrip ii util-linux2.13.1.1-1 Miscellaneous system utilities Versions of packages laptop-mode-tools recommends: ii acpid 1.0.6-10 Utilities for using ACPI power man ii hal 0.5.11-3 Hardware Abstraction Layer ii hdparm8.9-1 tune hard disk parameters for high pn sdparmnone (no description available) laptop-mode-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: acpi-support: suspend fails after upgraed from 0.109-5 to 0.109-6
Hi Christian, Christian Gogolin wrote: Package: acpi-support Version: 0.109-6 Severity: important After upgrading acpi-support and acpi-support-base from 0.109-5 to 0.109-6 my Samsung x20 notebook no more enters suspend mode when calling /etc/acpi/sleep.sh. Before the update everything worked fine. Downgrading to 0.109-5 resolved the problem. Below you find a trace of what happens when /etc/acpi/sleep.sh is called. If you tell me what information you need to resolve this problem I'd be happy to help you. I think this is the same problem as one that has already been reported, but I need to be sure. Could you run it using bash -x sleep.sh And show us the output? Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497570: acpi-support: suspend fails after upgraed from 0.109-5 to 0.109-6
Hi Christian,
Christian Gogolin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The requested output is:
$ bash -x /etc/acpi/sleep.sh
+ test -f /usr/share/acpi-support/policy-funcs
+ . /usr/share/acpi-support/policy-funcs
++ . /usr/share/acpi-support/power-funcs
+++ umask 022
+++
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
+++ POWERSTATE=/var/lib/acpi-support/powerstate
+++ HDPARM='/sbin/hdparm -q'
+++ LIDSTATE=/var/lib/acpi-support/lidstate
++ CheckPolicy
++ getXuser
+++ finger
+++ grep -m1 ': '
+++ awk '{print $1}'
++ user=
++ '[' x = x ']'
+++ finger
+++ grep -m1 :
+++ awk '{print $1}'
++ user=cgogolin
++ '[' xcgogolin = x ']'
++ '[' xcgogolin '!=' x ']'
+++ getent passwd cgogolin
+++ cut -d: -f6
++ userhome=/home/cgogolin
++ export XAUTHORITY=/home/cgogolin/.Xauthority
++ XAUTHORITY=/home/cgogolin/.Xauthority
++ export XUSER=cgogolin
++ XUSER=cgogolin
++ pidof gnome-power-manager kpowersave
++ test cgogolin '!=' ''
++ pidof dcopserver
++ echo 1
+ '[' 1 '!=' 0 ']'
+ /usr/share/acpi-support/suspendorhibernate suspend
Thanks! This output matches my expectations. Now could you send in the
output of:
bash -x /usr/share/acpi-support/suspendorhibernate suspend
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: $ bash -x /usr/share/acpi-support/suspendorhibernate suspend [...] + for METHOD in '$SUSPEND_METHODS' + case $METHOD in + '[' -x /usr/bin/dbus-send ']' + /usr/bin/dbus-send --session --dest=org.freedesktop.PowerManagement --type=method_call --print-reply --reply-timeout=2000 /org/freedesktop/PowerManagement org.freedesktop.PowerManagement.Suspend + grep -q ' org.freedesktop.DBus.Error.' + exit It's starting to look more and more like the other problem. Could you now try running this command (on a single line): /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 us the output? If it's this one: ---snip--- Failed to open connection to session message bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. ---snip--- then it's the same problem as #496911. If not, then we have a similar but slightly different problem. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500751: acpi-support ships file and deletes it in postinst
Hi Paul, Paul Wise schreef: acpi-support ships /etc/modprobe.d/thinkpad_acpi.modprobe and deletes it in postinst when upgrading from versions before 0.109-1 or just installing from scratch. I detected this because I occasionally run the cruft program. Ohhh, this may actually be a problem for lenny, because the version of acpi-support in the previous release was before 0.109-1. I'll have to check once I get back to my own computer... Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481766: pm-utils: Please fix this before lenny becomes stable!
Hi Michael, Michael Biebl wrote: Michael Biebl wrote: The problem is, that the bug is about adding support for laptop-tools, but I am missing proper justification, why this is necessary, what the underlying problem is and why laptop-mode-tools is the correct solution. Bart, can you elaborate a bit on this. The linked launchpad bug is a bit hard to digest. Sorry about the delay, I've just returned from some scheduled downtime (aka a holiday). I understand that you can't read the launchpad thing, but it's not all that important really. Let me try to explain the situation. The basic problem is the following combination of things: 1. Laptop mode tools tweaks hardware settings. Most of these are lost over suspend. So, on resume, it must re-tweak them. The settings that are lost over suspend include the ones that are required for the basic functionality of laptop mode, i.e., spinning down the hard drive. So it is *very* important that laptop mode tools is restarted on resume, or else it is entirely broken on resume. This is especially important since suspending is used most frequently on laptops which are running on battery power, exactly the target audience of laptop mode tools. 2. Until recently, the package acpi-support handled suspend itself. It has a directory of on-resume scripts in /etc/acpi/resume.d. This directory contains a script that restarts laptop mode tools. 3. The package acpi-support has since been changed to delegate suspend to pm-utils instead (by default -- the old functionality is still present). 4. The pm-utils suspend functionality does not contain a script that restarts laptop mode tools on resume. So technically: a) This is not a regression in pm-utils when viewed in isolation. The pm-utils package has never supported this. b) This is not a regression in laptop-mode-tools. Laptop mode tools has never cared about suspend. c) This IS a regression in acpi-support, because it used to do this in sarge, and now it doesn't in lenny. So it's all a bit strange -- an important regression in the functionality of acpi-support, which can only be fixed by changing pm-utils. BTW, in an earlier mail you suggested that this should actually be fixed in laptop-mode-tools. While I understand the reasoning behind this policy, and while I support this design concept in general, there are simply too many suspend methods in Linux to support, each of which have their own set of scripts which have to be tweaked. The ones I know of are hibernate, pm-utils, pmud, pbbuttonsd, and acpi-support. I'm afraid this situation needs to be resolved before such scripts can be put in the resume-action-requiring packages. :-/ On a side note, I've just received another bug report (#501804) for laptop-mode-tools mentioning exactly this -- indicated priority by the submitter as important. I've CC'ed the submitter, as he may want do some advocacy as well. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: acpi-support: resume from suspend to RAM unreliable on ThinkPad X61s
Hi Anton, Anton Ekblad wrote: Laptop does not wake up from suspend to RAM reliably anymore but freezes completely about one time in three. Worked fine before the last update to acpi-support. Thanks for reporting. I will ask you some questions to debug this problem. First of all, could you send me the contents of /etc/default/acpi-support? That will help me determine which suspend method is being used, and it determines the next questions that I will need to ask. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500983: still reproducable for me
Hi Dave, I see that you are using pm-utils for suspend (the dbus-pm and dbus-hal methods eventually go to pm-utils as well). Does your laptop suspend and resume correctly when you issue the command pm-suspend (as root)? Cheers, Bart Dave O wrote: I have the same issue, since the upgrade to this version, using an x61. It occurs more frequently than described in the original report for me, in fact nearly every time. Here's the non-comment lines from the config file: SUSPEND_METHODS=dbus-pm dbus-hal pm-utils ACPI_SLEEP=true ACPI_HIBERNATE=true ACPI_SLEEP_MODE=mem MODULES= MODULES_WHITELIST= SAVE_VBE_STATE=true VBESTATE=/var/lib/acpi-support/vbestate POST_VIDEO=true USE_DPMS=true HIBERNATE_MODE=shutdown LOCK_SCREEN=true STOP_SERVICES= RESTART_IRDA=false SKIP_INTERFACES=dummy qemu Please let me know if I can provide more detail for you. Thanks! Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: when I wake up my notebook from Hibernation, it sometimes happens that laptop-mode tries to remount /usr and the mount wedges itself in kernel space: Eats 90 % CPU and is unkillable: acpid,4115 -c /etc/acpi/events `-lm_battery.sh,19925 /etc/acpi/actions/lm_battery.sh battery C137 0080 0001 `-laptop_mode,19926 /usr/sbin/laptop_mode auto `-laptop-mode,19982 /usr/share/laptop-mode-tools/modules/laptop-mode `-laptop-mode,19986 /usr/share/laptop-mode-tools/modules/laptop-mode `-laptop-mode,20007 /usr/share/laptop-mode-tools/modules/laptop-mode `-mount,20008 /dev/mapper/usr /mnt/usr -t ext3 -o remount,rw,commit=600 I do not have the slightest clue what happens here, so I am reporting this bug against the package which has the most scripts in the process tree in the hope that somebody with more clue can reassign. fwiw, it's reboot time in these cases :-( Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? (If it is, it's the same bug as the other one. If it isn't, then it's also a kernel bug, but perhaps a different one.) Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: On Tue, Jul 29, 2008 at 09:09:08AM +0200, Bart Samwel wrote: Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? Tried it for like three hours this morning, didn't happen. Even a few minutes is not acceptable Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? I had it happen without hibernation this morning when unplugging the power. So it does not look hibernation related. Then it's a kernel bug, there's nothing I can do about this. :-/ I'll reassign it (tonight). Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Marc Haber wrote: On Tue, Jul 29, 2008 at 04:33:56PM +0200, Bart Samwel wrote: Marc Haber wrote: On Tue, Jul 29, 2008 at 09:09:08AM +0200, Bart Samwel wrote: Thanks for reporting. I've recently had a report where remounts would hang for 20 minutes at 90% CPU before completing. Firstly, could you try letting it hang for very long (perhaps even several hours) to see if it eventually finishes? Tried it for like three hours this morning, didn't happen. Even a few minutes is not acceptable Also, could you check when exactly it hangs? Is it only when you resume in a different power state (plugged vs. unplugged) than when you hibernated? I had it happen without hibernation this morning when unplugging the power. So it does not look hibernation related. Then it's a kernel bug, there's nothing I can do about this. :-/ I'll reassign it (tonight). The kernel team is just going to close this since I do not use a Debian kernel. Ahhh, that's an important fact. If you are not running a Debian kernel, then you should report this to the kernel upstream. It is definitely not a bug in laptop-mode-tools -- it's not doing anything unexpected, and the kernel should be able to handle this just fine. Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492808: laptop-mode-tools: tries to remount /usr after waking up from hibernation
Hi Marc, Marc Haber wrote: On Tue, Jul 29, 2008 at 04:45:23PM +0200, Bart Samwel wrote: Marc Haber wrote: Why is laptop-mode-tools trying to remount the file systems in the first place? Let me try to explain. Ext3 file systems (and some other journalling file systems) write to disc periodically, to flush its journal transactions. When laptop mode is enabled, laptop mode tools must tweak the mount options for ext3 to make the flush intervals larger, so that the disc doesn't spin up every 30 seconds. At resume time, some of the settings are forgotten by the hardware and/or the kernel, so laptop mode tools has to forcibly reapply all settings, including the mount options. Can this behavior of laptop-mode-tools be disabled by configuration? Well, you can set CONTROL_MOUNT_OPTIONS to 0 in laptop-mode.conf. But that does mean that laptop mode won't work anymore. If you're going to do that, you might as well uninstall it... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495208: laptop-mode-tools: Auto-hibernation not working on ThinkPad X40
Hi Soenke, Soenke wrote: it seems that the auto-hibernation feature of laptop-mode-tools (configurable via /etc/laptop-mode/conf.d/auto-hibernate.conf) does not work with my laptop (ThinkPad X40) any more. It worked a while ago, but as I have not used this option for some time, I am not sure when it stopped working. I tried several settings for AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT (as high as 20) and also enabling AUTO_HIBERNATION_ON_CRITICAL_BATTERY_LEVEL. Regardless of these settings, the system does not exectute the command set in HIBERNATE_COMMAND but just turns off (no regular shutdown, just switched off) as the battery runs down. If I remember correctly, laptop-mode is called via acpid when a battery event is caught, checks the battery state and acts accordingly. So I tried running acpid in debug mode (for about 20 minutes, on battery), but I only got battery events when (un)plugging the AC-adapter. During normal system operation, I did not see any battery events at all. When I unplug the AC-adapter while the battery is below AUTO_HIBERNATION_BATTERY_CHARGE_PERCENT, I get a battery event and HIBERNATE_COMMAND is executed. When just running on battery, it does not seem to work. Is there a way of triggering the battery events without plugging in the AC-adapter? I recently got a new battery for this system, maybe the problem is related to that? I cannot test the old battery as it does not work anymore. If more information is required, I will gladly supply it. H. These events are actually hardware dependent, and if the new battery does not send them, there's not much you can do about it except perhaps polling. I will consider adding a polling feature to laptop mode tools; it would be something like a cron job that runs every minute or so. It's a pretty heavyweight solution though. :-/ If you install a cron job that runs /usr/sbin/laptop_mode auto every minute, I expect it works again? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495364: laptop-mode-tools: AC_DISABLE_HAL_POLLING has wrong default value
Daniel Moerner wrote: In /etc/laptop-mode/conf.d/hal-polling.conf, the comments state that the default is to Disable HAL polling on battery and Enable HAL polling on AC. The default value for HAL polling on AC is: AC_DISABLE_HAL_POLLING=1 Either this or the comment should be changed to reflect that it HAL polling is by default disabled on AC power. Thanks Quite right, that should be fixed. I vote for changing the comment -- if people have to enable this module manually, they know where to change it back if they want it. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495208: laptop-mode-tools: Auto-hibernation not working on ThinkPad X40
Soenke wrote: Hi Bart, thanks for the quick reply. H. These events are actually hardware dependent, and if the new battery does not send them, there's not much you can do about it except perhaps polling. I was afraid that this might be the case. I checked again with acpid in debug mode, there is a battery event every 60 - 70 minutes. :( I will consider adding a polling feature to laptop mode tools; it would be something like a cron job that runs every minute or so. It's a pretty heavyweight solution though. :-/ If you install a cron job that runs /usr/sbin/laptop_mode auto every minute, I expect it works again? The cron job works fine, so a polling feature would be nice. For now, I just put a new entry into the system crontab, but I will try to find a somewhat more elegant (and perhaps configurable via the laptop-mode config files) solution for the problem over the weekend. At the moment I am not sure how to get a polling behaviour without using cron, but I might have time to look into that as well. If you are interested, I can send you my solution when it is finished. That might take a few days, though. Hi Soenke, I think this might be related to bug #491396 which I just noticed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491396 Could you perhaps try an older kernel to confirm whether you are experiencing this problem? 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#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#488937: setting package to acpi-support acpi-support-base, tagging 488937
# Automatically generated email from bts, devscripts version 2.10.35 # via tagpending # # acpi-support (0.109-6) unstable; urgency=high # # * Incorrect D-BUS HAL call in dbus-hal suspend method (Closes: ##488937) # package acpi-support acpi-support-base tags 488937 + 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: acpi-support: /etc/acpi/battery.d is ignored on newer kernels
Hi Jeff, Jeff King wrote: Package: acpi-support Version: 0.109-5 Severity: normal Tags: patch Newer kernels have disabled the /proc interface to power management, leaving only the /sys. However, the /etc/acpi/power.sh script makes a decision about running the scripts in battery.d by looking for ac adapters in /proc (this also affects the running of scripts in ac.d). The patch below fixes it for me (but this is the first time I have ever done anything with the /sys power interface, so I don't know how correct the method for finding ac adapters is). Looks good to me! I'll try to keep support for the old stuff as well, but I'll use the stuff in your patch for the new. Thanks for contributing! 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
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#497801: acpi-support: scripts in /etc/acpi test files from acpi-support-base instead of acpi-support
Package: acpi-support Version: 0.109-6 Severity: important The acpi-support scripts in /etc/acpi test for the existence of files in /usr/share/acpi-support to check if they should run. However, a lot of them check for power-funcs or policy-funcs, which are now in acpi-support-base. That means that the scripts will continue to run even though acpi-support is no longer installed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497801: 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#497377: not clear how to have scripts run on suspend
Hi Frederik, Let me see if I can answer your questions. Frederik Eaton wrote: I am sorry to be trouble, there is probably an easy solution but I couldn't find it after some time, so I am submitting this as a documentation bug, hopefully the situation can be improved for future users even if my question is addressed. I just want to turn of my network interfaces on suspend (maybe this happens automatically with some desktop environment or using /etc/network/interfaces but I don't use those), so I looked around and found /etc/acpi/suspend.d/ and put a script in there. It doesn't seem to run on suspend, which I do with acpitool -s A... acpitool is a low-level tool which runs *nothing* on suspend. It is not really intended for end user usage, because it doesn't integrate with the system at all. So that explains it. If you want to use the suspend method as specified in /etc/default/acpi-support, you need to run /etc/acpi/sleep.sh. The trouble here is that suspend on Linux is an absolute mess. There is confusion between layers: acpitool is a low-level hardware tool while acpi-support and pm-utils both deliver a high-level suspend system integrated with the system. There is no central place to put scripts (acpi-support and pm-utils both have their own systems for this, and there are even more suspend systems!). The only way to fix this is for the various authors to get together and make arrangements. I haven't had much success cooperating with the pm-utils folks in the past, and the acpi-support upstream is not too cooperative either. All in all, I've given up. I've deprecated the acpi-support suspend system in favor of the pm-utils one so that there's at least *some* semblance of a single suspend system (especially since gnome-power-manager forces the use of pm-utils and we like to keep behaviour consistent with that). Anyway, I might be able to add some docs, but it's going to remain a mess whatever I do... 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:
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#489465: changes from 0.109-5 to -6 disabled sleep button
Hi Krunoslav, Krunoslav Sever wrote: Today I upgraded to -6 which disabled the sleep button on my (old) HP Omnibook 6000, at least on console. Haven't tested if it still works from X, though (xfce Desktop). With -5 the sleep button functioned perfectly from console and from the xfce Desktop. After downgrading to -5 again, everything works fine again, so it must be the changes between these two versions. Before downgrading I tried to revert the change in /etc/acpi/events/sleepbtn manually and and stop/start /etc/init.d/acpi-support, but that didn't have any effect, so I guess there have been some more changes (or I forget to restart something else?). The changelog led me to this bug number which I guess is the culprit, so I hope this is the right place to post this issue. Maybe you can provide a workaround, otherwise I will be staying with -5 for now. This is a fairly basic lenny installation, just base and some selected additional packages, nothing custom. If you should need more details, I can provide them later (at work right now). Sorry about the delay, I've been a bit busy. Could you try replacing the contents of /usr/share/acpi-support/suspendorhibernate by the contents of the attached file and tell me the results? This change will be included to fix another suspend problem in 0.109-6, and if this fixes it for you, then you are experiencing the same problem and I don't have to change anything else. For more info, see bugs #496911 an d #497570: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496911 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497570 If this doesn't fix things for you, we need to do do some debugging on your setup. But we'll wait with that until we know that it's necessary! 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
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#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#489465: changes from 0.109-5 to -6 disabled sleep button
Hi Krunoslav, Krunoslav Sever wrote: On Sun, Sep 07, 2008 at 10:26:13AM +0200 wrote Bart Samwel [EMAIL PROTECTED]: Hi Krunoslav, Krunoslav Sever wrote: On Thu, Sep 04, 2008 at 08:36:03PM +0200 wrote Bart Samwel [EMAIL PROTECTED]: Hi Krunoslav, Krunoslav Sever wrote: Today I upgraded to -6 which disabled the sleep button on my (old) HP Omnibook 6000, at least on console. Haven't tested if it still works from X, though (xfce Desktop). With -5 the sleep button functioned perfectly from console and from the xfce Desktop. After downgrading to -5 again, everything works fine again, so it must be the changes between these two versions. Before downgrading I tried to revert the change in /etc/acpi/events/sleepbtn manually and and stop/start /etc/init.d/acpi-support, but that didn't have any effect, so I guess there have been some more changes (or I forget to restart something else?). The changelog led me to this bug number which I guess is the culprit, so I hope this is the right place to post this issue. Maybe you can provide a workaround, otherwise I will be staying with -5 for now. This is a fairly basic lenny installation, just base and some selected additional packages, nothing custom. If you should need more details, I can provide them later (at work right now). Sorry about the delay, I've been a bit busy. Could you try replacing the contents of /usr/share/acpi-support/suspendorhibernate by the contents of the attached file and tell me the results? This change will be included to fix another suspend problem in 0.109-6, and if this fixes it for you, then you are experiencing the same problem and I don't have to change anything else. For more info, see bugs #496911 an d #497570: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=496911 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497570 If this doesn't fix things for you, we need to do do some debugging on your setup. But we'll wait with that until we know that it's necessary! Cheers, Bart No sweat about the delay, since I have a working setup for now, there is no real urgency. Anyway, replaced the file, sleep button didn't work (console). Replacing back, enabled it again. Let me know what you need for debugging the setup. I did no manual changes, so it is the setup established by apt, though I suppose there are local settings involved. OK, then let's debug this. I would like to see the output of: bash -x /usr/share/acpi-support/suspendorhibernate suspend Okay, following occurred: with version -5 I obtained out-5 in the attachment and notebook suspended. Then I replaced the file you provided earlier and rerun. I obtained out-7 in the attachment (a few lines differ, may be of help) and the notebook suspended again (but the button does not work): button assignment? I haven't retested but I think I tried something like this command to obtain a manual suspend command with version -6 and it did not suspend. May be I will retry later. For now I am quite optimistic the current results will help you. Yes, this helps. It must be a button handler problem. Could you show me the output of: bash -x /etc/acpi/sleepbtn.sh and also tell me if the laptop suspends when you do this? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489465: changes from 0.109-5 to -6 disabled sleep button: SOLVED!
Hi Krunoslav, Krunoslav Sever wrote: [...] I haven't retested but I think I tried something like this command to obtain a manual suspend command with version -6 and it did not suspend. May be I will retry later. For now I am quite optimistic the current results will help you. Yes, this helps. It must be a button handler problem. Could you show me the output of: bash -x /etc/acpi/sleepbtn.sh and also tell me if the laptop suspends when you do this? Gak. Okay, I found the problem myself after this output, i.e. your patched file works! I just forgot to make it executable (the output showed me that I had no permission to run your file). Now button works with patch from console and X again. That means version 7 will likely fix this for me: have you an ETA for upload already? Thank you for the help and I hope you don't mind me having been a little stupid there. I actually did watch for reading rights when replacing but totally ignored execution somehow. Well, at least the solution didn't require serious work :) Version 7 is actually already uploaded -- it's in unstable (or actually, version 8 is), I still need to get a release exception from the release managers so that it still goes into Lenny, I'll do that tonight. 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#458787: hdparm -B 254 applied to disks that don't support that command
[EMAIL PROTECTED] wrote: Unfortunately none of my drives 'hdparm -i' report: AdvancedPM=yes Some report no, others are flash card readers that don't return anything. They all get this error. For a workaround, I edited '/etc/acpi/start.d/90-hdparm.sh'. Setting DO_HDPARM=n Grepping hdparm -i for the string above on each drive would probably be a good fix. Something like this might work, but would need to be tested on machines that support AdvancedPM if [ $DO_HDPARM = y ] ; then AC_POWER=$( /usr/bin/on_ac_power; echo $? ) for dev in /dev/sd? /dev/hd? ; do if [ -b $dev ] ; then if hdparm -i $dev |grep AdvancedPM=yes - /dev/null ; then if [ $AC_POWER -eq 1 ] ; then hdparm -B 128 $dev else hdparm -B 254 $dev fi fi fi done fi Looks interesting, I'll give it some thought. I'm considering some other improvements to this functionality as well, I'll let you know what happens! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461311: acpi-support: reinstalls user modified events
On Thu, January 17, 2008 18:35, Hramrach wrote: It looks like acpi-support either changed the name of events or reinstals events modofied by user under new name. I have modified /etc/acpi/powerbtn.sh to do hibernate instead of shutdown. However, after an update I get /etc/acpi/events/powerbtn-acpi-support and /etc/acpi/powerbtn-acpi-support.sh that do shutdown anyway. Quite bad in my view as I wanted my system to hibernate but withiut any warning it would poweroff. Hi Hramrach, The powerbtn.sh file was recently removed from acpid. In order to make things work again, we re-added it to acpi-support, but to avoid conflicts with the original we had to give it a different name. We should probably detect the existence of powerbtn.sh in powerbtn-acpi-support.sh, and call it if it exists, instead of doing the processing ourselves. AFAIK, if people didn't modify the file it should go away when they install an acpid upgrade that no longer includes the file, so this would only apply to people who actually modified this file. (Note to self: must perform an actual check that this is the case!) Cheers, Bart
Bug#461441: acpi-support: /etc/init.d/vbesave should have an empty Default-Stop
Hi Rémi, Rémi Vanicat wrote: vbesave contain the following: stop|restart|force-reload) # Doesn't make sense (and shut up lintian) ;; but have a non empty Default-Stop header. An empty Default-Stop header would seem logical. Thanks for the patch! Cheers, Bart
Bug#453706: acpi-support: Fn-F5 (start/stop WLAN) does not work with atheros based cards
Stefan Pampel wrote: how can i help to forward this issue and maybe close this bug? Hi Stefan, I'm sorry I haven't been too responsive lately, I've had a bit too much on my mind lately. I'll implement the fix you suggested (or something equivalent) soon. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463432: laptop-mode-tools: does not recognize new /sys power interface
Michael Ekstrand wrote: laptop-mode-tools does not recognize the AC adapter status information in /sys/class/power_supply/AC provided in newer kernels. Since the Debian packages of kernel 2.6.24, at least on AMD64, disable the legacy /proc/acpi power interface, this renders laptop-mode-tools nonfunctional on that platform, unless a kernel is recompiled with the ACPI folders in /proc. Good point, that needs to be fixed. Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459328: acpi-support: Wireless hotkey wrongly interpreted as display brightness key on Eee PC
Tomaz Solc wrote: On Asus Eee PC (model 701) the wireless hotkey (Fn - F2) triggers ACPI events hotkey ATKD 0011 and hotkey ATKD 0010. However the file /etc/acpi/events/asus-brightness-up identifies a 0011 event as brightness up key: event=hotkey ATKD 001[123456789abcdef] I suggest changing this line so that it no longer matches 0011 (in case of course that no other laptop actually uses 0011 event for brightness up): event=hotkey ATKD 001[23456789abcdef] Hmmm, I don't know why the brightness keys were specified like this. And I don't have access to any other Asus laptops to check what their actual brightness up keys are... perhaps some archive digging will expose why these keys were specified like this. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459326: acpi-support: Support for volume hotkeys on Asus Eee PC
Tomaz Solc wrote: Attached are three files containing acpid configuration that add support for volume up/volume down/mute hot keys on Asus Eee PC (model 701). Thanks, I'll take a look at them! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#459422: laptop-mode-tools debian package
Package: laptop-mode-tools Version: 1.35-1 Tags: upstream Cleber Paiva de Souza wrote: Hi Bart, In file /etc/init.d/laptop-mode in line 47 there is a ^M that I think is a typo error. Just to inform you. I'm using the version 1.35-1 in a debian Sid. Hmmm, if that's there, than that's definitely a typo. :-) Thanks for the report. Note that I'm submitting this as a regular bug report, please don't include the [EMAIL PROTECTED] address when you reply! :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410918: acpi-support depends on nvclock
graziano wrote: Package: acpi-support Version: 0.103-5 Followup-For: Bug #410918 Hello there, thanks for the good work for acpi-support! I noticed that acpi-support depends on nvclock, and from today nvclock depends on libqt3-mt, a bit more than 318k I have to say. Looking in /etc/acpi it looks like nvclock is only used in sonybright.sh and there is already a check for the existence of the binary. Thus I think nvclock should be a suggested or recommended package instead of a depended on. This is not currently possible. (That's why this bug report is tagged wontfix.) We are considering possibilities of fixing it, and if we find something that will work, we will implement it. Thanks for notifying us of the changed dependencies, it does change the relative importance of the problem a bit. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452489: acpi-support: Broken test for hdparm and laptop-mode
Christophe Combelles wrote: in /etc/acpi/resume.d/90-hdparm.sh The expression below if grep -q CONTROL_HD_POWERMGMT=1 is not enough, since the following will return true instead of false: #CONTROL_HD_POWERMGMT=1 and the following will return false instead of true: CONTROL_HD_POWERMGMT = 1 A better regexp would be: if grep -q '^ *CONTROL_HD_POWERMGMT *= *1' Agreed, will fix. Thanks for reporting! Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448673: acpi-support: ACPI system causes the HDD to cycle every 5-9 seconds
Francisco Aguilera wrote: Package: acpi-support Version: 0.103-4 Followup-For: Bug #448673 I've installed a brand new HDD (Fujitsu MHV2120AH) on my laptop and it cycles every 5-9 seconds. Bug #448710 fixing method won't work on my system. If you manually do hdparm -B 254 /dev/hda or hdparm -B 254 /dev/sda (depending on where your device is) Does it stop cycling? And if no, if you do hdparm -S 0 /dev/hda does that help? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448673: acpi-support: ACPI system causes the HDD to cycle every 5-9 seconds
Hi Fran,
I guess your workarounds did interfere with the fix built into
acpi-support. If it works now, great! If it ever stops working again,
let me know. :-)
Cheers,
Bart
Fran Aguilera wrote:
Hi again Bart,
I don't know what happened but now, the HDD led lights the same way
before rebooting but the disc doesn't do the noise before it did.
I don't know if it is because of some of the commands executed before :|
So, a this moment it seems to be solved (that's I hope :P).
Thanks again and sorry if there is some misstake in my English.
Greetings from Spain,
Fran Aguilera
PS: If the problem appears again, don't doubt I'll make your time waste
again :D
2007/11/28, Bart Samwel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Hi Fran,
To begin with, I would suggest completely removing the fixes you've done
before. Acpi-support 0.103-4 should fix the problem, and your other
fixes will only interfere with that. If it doesn't work after you
uninstall these fixes and reboot, there's something else going on. I'll
think a bit more about what could cause this. For now, please remove
your custom fixes!
Cheers,
Bart
Fran Aguilera wrote:
Hello, thanks for answering so quickly.
No, I've tried:
hdparm -B 255 /dev/hda
and
hdparm -B 254 /dev/hda
and now you've told it to me
hdparm -S 0 /dev/hda
and the disk is still cycling.
As I said in the bug report, I've done what it's said on #448710,
that's
to say:
- Adding to /etc/hdparm.conf
/dev/hda {
apm = 255
}
- Creating 99-fix-disk.sh with
#!/bin/bash
hdparm -B 255 /dev/hda
- Chmod +x 99-fix-disk.sh and copying it to /etc/acpi/suspend.d,
/etc/acpi/resume.d and /etc/acpi/start.d
I was just wondering if chmod should be a+x instead +x and I was
doing
it when your mail has arrived.
I hope you can help me and everyone whit this problem. Again,
thanks for
answering so quickly.
2007/11/28, Bart Samwel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Francisco Aguilera wrote:
Package: acpi-support
Version: 0.103-4
Followup-For: Bug #448673
I've installed a brand new HDD (Fujitsu MHV2120AH) on my
laptop
and it
cycles every 5-9 seconds.
Bug #448710 fixing method won't work on my system.
If you manually do
hdparm -B 254 /dev/hda
or
hdparm -B 254 /dev/sda
(depending on where your device is)
Does it stop cycling?
And if no, if you do
hdparm -S 0 /dev/hda
does that help?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453478: acpi-support: 90-hdparm.sh causes resume.sh to abort
[EMAIL PROTECTED] wrote: Package: acpi-support Version: 0.103-4 Severity: important /etc/acpi/90-hdparm.sh contains the line exit 0. This exits also resume.sh, which sources 90-hdparm.sh. This can lead to uncomplete wakeup from sleep Youch! Thanks for reporting, I'll fix this right up... Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453706: acpi-support: Fn-F5 (start/stop WLAN) does not work with atheros based cards
On Fri, November 30, 2007 18:39, Stefan Pampel wrote: wifi cards based on atheros chips running with madwifi-drivers[1] can't diabled by pressing Fn-F5. This comes through a different structure in /sys/class/net/[DEVICE]/* . The script /etc/acpi/ibm-wireless.sh calls a function called toggleAllWirelessStates in the file /usr/share/acpi-support/state-funcs which normaly does the on/off switch. The function gather information out of /sys/class/net/[DEVICE]/device/power/state or /sys/class/net/[DEVICE]/device/rf_kill '0' for off and '1' for on. The madwifi-driver puts the power in fo in a different place /sys/class/net/[DEVICE]/operstate with 'up' and 'down' . Changing the function toggleAllWirelessStates can help to fix this, see the attached patch. Hi Stefan, Thanks for contributing. Next time when you send a patch, please make sure you don't change any whitespace (tabs!) on the lines that you don't touch, I had to rediff this to be able to properly review the patch! As for the patch, do I understand it correctly that with madwifi the ifup/ifdown state corresponds to killing the wireless radio? Cheers, Bart
Bug#448673: acpi-support: excessively load cycles some hard drive
Daniel Rode wrote: Seems to work fine now. Thanks. Great. There's a bug in the current version of acpi-support, it doesn't actually apply hdparm -B 254, while it was intended that it would. A fixed version will be uploaded somewhere within the next day. When this upload comes through you will not have to do this manually anymore. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#448673: acpi-support: excessively load cycles some hard drive
Daniel Rode wrote: After executing: hdparm -B 255 /dev/sda and hdparm -S 0 /dev/sda Load_Cycle_Count still grows. I'm using Debian Lenny, acpi-support (0.103-4), hard drive is TOSHIBA MK1637GSX. And after hdparm -B 254 /dev/sda? Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453856: acpi-support: asus wifi led diode is just brighted
Hi Ivan,
Ivan wrote:
setLEDAsusWireless()
{
action=`test $1 -ne 0 (echo 1 || echo 0)`
test -w /proc/acpi/asus/wled echo -n $action
/proc/acpi/asus/wled
}
Thanks for reporting. I'm considering changing it to:
setLEDAsusWireless()
{
if [ -w /proc/acpi/asus/wled ] ; then
if [ $1 -ne 0 ] ; then
echo -n 1 /proc/acpi/asus/wled
else
echo -n 0 /proc/acpi/asus/wled
fi
fi
}
It's much easier to read like this. Could you confirm that this works
for you?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453861: acpi-support: Fn+F2 (wireless on/off) stopped working with upgrade to 0.103-4 on ASUS A6J
Arnout Boelens wrote: Package: acpi-support Version: 0.103-4 Severity: normal With the upgrade from acpi-support 0.103-1 to 0.103-4 switching wireless on/off with Fn+F2 stoppen working on my ASUS A6J Laptop. I could not figure out what was the cause that it stoped working and downgraded back to 0.103-1 again. Thanks for reporting. I'll look into it as soon as I find some time. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456778: acpi-support: suggestion for ibm-videobtn
Hi Csillag, Csillag Tamas wrote: I think I have an idea what to include in ibm-videobtn: -action=/bin/true +action=xrandr --auto Just checking, does it work if you replace it by action=/etc/acpi/videobtn.sh ? This is what all other video buttons do, and I am of course hoping that we can consolidate this. :-) However this does not best way to do it, but it works and maybe it is better than /bin/true. This will only switch on the second display if is already connected, it won't switch off unless disconnected. Some further ideas: Make an external script which toggles between: switch off VGA: xrandr --output VGA --off switch off internal display: xrandr --output LVDS --off Detect if a xrandr aware video card is present (works with intel, not sure about the others). I think xrandr --auto is simple and safe enought. If this is needed, I think the switch explicitly option is probably better, because I can think of some real use cases where you don't want to disconnect the external monitor but you _do_ want to keep your display to yourself. For instance, if you have a TV that automatically switches to a certain input if it detects a signal (mine does that). Or if you're preparing for a presentation, you might want to connect and test the output and then switch back to only the internal display until you've finished preparing. Furthermore, if you want xrandr --auto, you really make users expect real autodetection, which we can't do. Better to keep it with the usual behaviour for these kinds of buttons. :-) If someone have the resources to write the external script, the better. I'd definitely move this to an external script. Not much resources required, but testing would be nice if it's implemented. If you would like to help, I'd much appreciate it. Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457090: laptop-mode-tools: please use laptop_mode or laptop-mode consistently
Eric Cooper wrote: The program is laptop_mode, but the conf file is /etc/laptop-mode/laptop-mode.conf. There is also already a laptop-detect program, so I'd suggest making the command laptop-mode. If you make this change, you'd probably want to have both names for a while for compatibility. Hi Eric, Thanks for the suggestion. I'm tagging this wontfix. I'll give you the reasons: First of all, it's extremely cosmetic and will cause *way* more trouble than it's worth. Basically, I'll never be able to get rid of the old name because somebody *might* be using it. Worse: the script is used from config files shipped with laptop-mode-tools. If I ever get rid of the /usr/sbin/laptop_mode name, all of the old config files will suddenly stop working -- very bad for people who have adapted them. No point in breaking people's systems for cosmetic reasons only. Secondly, the /usr/sbin/laptop_mode is an internal command, not really intended to be used externally (you should use invoke-rc.d laptop-mode reload), and not in the path of anybody except root. If anything, it should be moved to a /usr/share location, which I won't do because it will break backward compatibility just as hard. In short, it's *way* too much breakage for something as cosmetic as this. But thanks for reporting. :-) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457386: acpi-support: hard disk load cycle fix is problematic for optical drives
Hi Michael,
Michael Gilbert wrote:
the fix for the load cycling error gets applied to optical drives as well
as hard disks. this leads to somewhat scary kernel log errors such as
Dec 21 21:56:48 kernel: hdb: drive_cmd: status=0x51 { DriveReady
SeekComplete Error }
Dec 21 21:56:48 kernel: hdb: drive_cmd: error=0x04 { AbortedCommand }
Dec 21 21:56:48 kernel: ide: failed opcode was: 0xef
this is because the optical drives are not differentiated from hard disks
in ac.d/90-hdparm.sh. i've written a patch for the issue (see attached)
using hdparm and keying in on Removeable to differentiate hard disks
from optical disks. this works for my system, but i'm not sure if it is
a general enough approach to the problem.
Probably not. :-) There's a pretty large chunk of code in
laptop-mode-tools to detect the media type of a hard drive, I'll see if
I can port that over. Thanks for reporting!
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457387: acpi-support: should radeontool, nvclock, and toshset be recommends rather than depends?
Michael Gilbert wrote: acpi-support ends up getting removed if the user tries to remove either radeontool, toshset, or nvclock. these dependencies seem more like recommends since all users don't necessarily have the specific hardware supported by those packages. so the user shouldn't need to install those packages to get acpi support to work. i think that these depends on should probably be changed recommends. This has been reported a number of times now, please check the other dicussions to see why it's not possible right now. (The title of the other bug report is acpi-support should not depend on toshset / radeontool. Did you check for duplicates before reporting?) Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#457387: acpi-support: should radeontool, nvclock, and toshset be recommends rather than depends?
Michael Gilbert wrote: This has been reported a number of times now, please check the other dicussions to see why it's not possible right now. (The title of the other bug report is acpi-support should not depend on toshset / radeontool. Did you check for duplicates before reporting?) oops. i had done a quick scan of the bug reports, but somehow missed it. it should be possible to fix the problem now that apt installs recommends by default (since version 0.7.7). The problem is not apt, it's tasksel. The Debian installer doesn't currently install recommends, and to make laptops work out of the box we _must_ have these packages available. We're considering a fix (trust me), but until that happens, this goes into the not really fixable category. :-/ Cheers, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458437: acpi-support and laptop-mode-tools interaction broken
Hi, Kapil Hari Paranjape wrote: Let me apologise in advance for the vague-ness of the following bug report --- suspend/resume still seems to be a bit of black-magic :-) Thanks for reporting! I'll look into this tomorrow. I can write down a quick note for now: acpi-support is *not* supposed to do anything to laptop-mode anymore, and if it does, that's a bug. Removing the laptop-mode handling from acpi-support was done as a patch on top of the upstream's (Ubuntu's, that is) acpi-support, and it may very well be that they added a reference to laptop-mode somewhere that I failed to patch away again... BTW, could you attach a tarball with the contents of your /etc/acpi, for reference? That way I can check that it's not some weird upgrade problem. :-) Cheers a happy new year, Bart -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
