Bugzilla Bug 45593

Hello,

I put together this init script, which initializes the kernel laptop_mode. I used the init script which is provided with the laptop_mode patch for the linux kernel 2.6.3, and gentooized it.

The script needs hdparm installed, linux kernel 2.4 or 2.6 with the laptop_mode patch applied (I think for the later 2.4 kernels it is official), and the directory /var/lib/laptop_mode created.

For my notebook it works like a charm.

Maybe someone would like to make an ebuild for it.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.



Expected Results:

Created an attachment (id=27911) [edit]
The init script

Created an attachment (id=27912) [edit]
The patch which I used

this is more than just an init script, it's also a kernel patch

> this is more than just an init script, it's also a kernel patch

actually, since kernel 2.4.something, the patch became part of the official kernel. I forgot in which release it was included first. a kernel patch is therefore only required for the 2.6 series and for older 2.4 kernels. as far as i know, the patch is expected to be included in one of the coming 2.6 releases, too.

so the development of this script may be a little ahead of time, but the functionality it provides is definitely worth it (at least for mobile users)

FYI: laptop mode got integrated into 2.6.6
http://kerneltrap.org/node/view/3070?PHPSESSID=f3d088276600ec6e5949261fd5f680be

Created an attachment (id=32076) [edit]
laptop-mode-20040403.ebuild

Ebuild to install the init script

Created an attachment (id=32077) [edit]
files/laptop-mode.conf

/etc/conf.d/laptop-mode

Created an attachment (id=32078) [edit]
files/laptop-mode.init

/etc/init.d/laptop-mode

I updated Johannes work on the init script 
(integrated the changes that come with kernel-2.6.6_rc1).

It would be nice to have this in the Portage tree. Quite a few kernel sources
include the laptop_mode patch today, and gentoo-dev-sources will do it with the
2.6.6. release, too.

gentoo-dev-sources-2.6.7 is out for some time now. Does anyone care to
integrate laptop-mode into portage? I want to finish bug #52109 now, so if
there'll be no progress on this I'll have to find another way.

Created an attachment (id=34630) [edit]
laptop-mode.conf

The init script that ships with 2.6.7 contains some minor changes (although the
last changed date was not updated).

Created an attachment (id=34631) [edit]
laptop-mode.init

as above

I would like to try the ebuild by putting it in my overlay dir, but I don't
know where it should go. Is sys-apps/ the correct place? And does it matter?

i personally put it in app-laptop

Okay, CCing the base-system guys. This script itself is relatively ugly, and
has a few pretty nasty hacks. What's your take on this? I'm wary of having an
ebuild just for one script like this. Can we integrate either this or something
like this into base-layout maybe? Please either comment here, or catch me on
IRC.

*bump* I'm still trying to reach "FIXED" or "WONTFIX" :)
Does the init script need to be rewritten, or do parts of it have to be changed (like remounting /)?

I don't see baselayout as being an appropriate target for this.  Single-script
ebuilds are just fine, though it would be better if it could be grouped with
some other laptop stuff.  sys-apps/acpi comes to mind since it makes more sense
to have this script triggered by AC power events than an init script.

I looked through the script.  I agree that it looks pretty shaky, though I
don't know that there's actually anything *wrong* with it.  A bunch of the sed
stuff is overdone and could be accomplished with a few bash expressions (or at
least a single invocation of sed!)

Thanks for looking through it. sys-apps/acpi is a good candidate for a
dependency (as it makes little sense without it). IMHO the init-script 
style is fine. It can easily be placed in a battery runlevel this way 
(and let acpi events switch runlevels).

> I don't see baselayout as being an appropriate target for this.
Who is an appropriate target then? (aka bump ;-)

What about this? 

http://www.xs4all.nl/~bsamwel/laptop_mode/tools/index.html

The /usr/sbin/laptop-mode script (actually a modified version of the init
script) could be extracted from this.

Just tried it on my Dell D600. Haven't done any battery testing but I have
confirmed that it does at least return the values in /proc back to the kernel
defaults. This could be very useful in the mainline tree. Is there really any
reason why it is not in there anymore?

i recently took the latest laptop mode init script from linux kernel and 
make a crappy init script out of it and made it so it loads right after localmount
now i dont think my ver is any better than whats here but i would like to see
the script included in baselayout  the script is good for desktop computers
also on desktop just dont enable the hdparm sleeping and it helps your compiles
as it prevents a bunch of small writes all the time this of course would help
on slower IO systems even more i dont have numbers for you but 
genlop -t somepackage and laptop mode being enabled and disabled can show you

Created an attachment (id=39036) [edit]
laptop-mode.conf

Created an attachment (id=39037) [edit]
laptop-mode.init

Here is the one from kernel 2.6.8.1, dated 2004-06-10
There are some code improvements and new features added. 
Please test and post if it works.

Created an attachment (id=39477) [edit]
laptop-mode-tools.package.tar.gz

This is a new full ebuild for laptop-mode-tools. It can go inside app-laptop.

Latexer, Here is what we talked about.

Thanks Adrian for attaching this.
I played around with it the last hour, but there are some questionable things left.
First, the ebuild has some problems (unpack is never called, chmod too early, init file needs some clean-up as well) but that can be fixed easily.
What I really don't like is all that file creation in /etc/acpi (or /etc/apm). While CONFIG_PROTECT will prevent damage, it will still be messy if someone wants to merge the files.

Yeah i know the ebuild can be improved a lot, but its 1000 times easier to
maintain if the original package have big changes or anything than writing
everytime a new init script.

The file creation in /etc/apm and /etc/acpi only gets done if the user has in
USE apm and/or acpi. Its included in the original package. Also, in the
install.sh in the original package, there is a part that talk about installing
on Gentoo and it recommends or better it deletes all in /etc/acpi and /etc/apm.

Sorry but packages should be installed the standard way, just adjusting to only
the strictly necessary.

> Yeah i know the ebuild can be improved a lot, but its 1000 times easier to
> maintain if the original package have big changes or anything than writing
> everytime a new init script.
Agreed. 

> Sorry but packages should be installed the standard way, just adjusting to
> only the strictly necessary.
That's a weak argument, if any. By not using the install.sh script, you are
violating "the standard way" yourself - which is IMHO really fine as it's a
rather ugly install script.
Maybe we can agree on putting the files somewhere in /usr/share/doc and ask the
user to run ebuild ... config in case he wants /etc/a* to be screwed up, eh
configured. pkg_config() has to be created, of course.

>> Sorry but packages should be installed the standard way, just adjusting to
>> only the strictly necessary.
> That's a weak argument, if any. 

It's a perfectly reasonable stance to take: stick closely to the standard installer's behavior unless there's good reason to do otherwise.

Changing install locations and behavior can make support a pain. As the author of Product X, if an end-user reports a bug, configuration issue, etc., it potentially makes support that much more onerous if installation and configuration differ from the standard source or binary package I distribute.

This isn't to argue against customized packaging for Gentoo. Hardly. But in this case, I think Adrian is starting from the correct base assumption: stick closely to the default, by default. Then, adapt the ebuild to fit Gentoo requirements and customs.

Don't mean to rant; and certainly not against Dennis--I'm very appreciative of everyone who already worked on this. I was just about to make an ebuild for laptop-mode tools if I didn't find it here (precisely because I think in this case, install.sh is a bit messy).

>>> Sorry but packages should be installed the standard way, just adjusting to
>>> only the strictly necessary.
>> That's a weak argument, if any. 
>It's a perfectly reasonable stance to take: stick closely to the standard
> installer's behavior unless there's good reason to do otherwise.

I guess you got me wrong (looking at the point you chose to cut the quote). Nevertheless, I think we all agree on your point and don't need a general discussion here. If you're going to fix the ebuild that would be really awesome, if not I'm going to do it in the next days (yeah! finally I'll have more time soon)

Created an attachment (id=41295) [edit]
laptop-mode-tools-1.02.ebuild

Ebuild for the new version 1.02, even using install.sh to make maintaining it
as easy as possible (this screams for integration into portage, doesn't it? :)
)
Someone running apm (USE=apm) please confirm it works.

Created an attachment (id=41296) [edit]
files/laptop-mode.init

init script necessary for the ebuild. Put in files directory.

Rename the ebuild to laptop-mode-tools-1.03 to get the new version.

I tested and it worked for me, installation is flawless (not tested apm,
though)

This is somehting that realy should go in portage in
app-laptop/laptop-mode-utils or somthing..

working very well here. except that apparently my laptop does not send ac
events, but when i change the related config in the configuration file it works
perfectly. this should really be in portage... as well as the
hibernate-script...

Does laptop mode support reiser4 file system?

Works well for me on a Dell Inspiron 8600c with laptop-mode-tools 1.04 by
renaming the ebuild.

(From update of attachment 41295 [edit])
bump

Mobile herd, can you dedicate a few minutes of your time to verify this ebuild
and the accompanying files?

It's blocking a documentation update that's getting more and more requested
(regarding powermanagement guide).

I'm currently working on improving the current laptop-mode-tools package -
latexer and I have been discussing the state of laptop-mode-tools; we do not
feel it is production ready yet.

I'll keep you posted.

*** Bug 73308 has been marked as a duplicate of this bug. ***

If its not production ready yet, can it be added to the portage tree with
testing status, or is it still a step below testing?

One thing that should be patched in the 1.04 version is the syslog support. The
laptop mode script currently has a line that says 

"killall -HUP syslogd".

However, I think most gentoo users (at least if they go through installation
guide) are using syslog-ng.

Also, I think there should be a notification that (maybe) the best way to split
the syslogs is to use otherwise identical files, but add "sync(20);" to the
options{}-section - that is, the log is written only now and then on batteries,
not after every message. Another possibility might be and idea of additional
filters, ie. remove all the non-essential messages, like this:

log { source(src); filter(f_important); destination(messages); };
log { source(src); destination(console_all); };
filter f_important { level(emerg,alert,crit,err,warn,notice); };

This does not save debug and info-level messages to /var/log (it still saves
them to tty 12). 

Take these into consideration when you prepare the "production-ready"
laptop-mode..

Created an attachment (id=48913) [edit]
laptop-mode-tools-1.04.ebuild  (alternative version)

Errr... i should have searched bugzilla before writing my own ebuild. Bah, i'll
attach it anyway, because there are a few differences: 

 - i've not installed acpi or apm events handlers, but instead put them in the
documentation, just as it is in the ibm-acpi package for instance. Really, i
don't like package which install events handlers: it can interfere badly with
user's configuration (it would with mine), and etc-update won't be of any help
to prevent that since they are new files. From the moment the package is
installed, there are things that will start getting executed without any
agreement from user's side.

 - i've not used the makefile (to sed changes to do, especially since i also
move scripts to documentation dir), but instead rewrote it in src_install. But
i don't have strong arguments on that point, i don't really care.

Apart from that, my init script was 100% similar to the one in this bug (also
adapted from the one in the source package), so i won't submit it. 

Oh, i forgot to comment about testing if kernel actually supports laptop mode. 
I personally did not put a test in the ebuild. If the kernel does not support
it, then the script will fail, but that won't hurt. 

The point is that testing the running kernel is not really relevant (what if
i'm installing in a non-"/" $ROOT, etc.). If there must really be a test, it
must be done on ${ROOT}/usr/src/linux sources. As it has been said, the kernel
version is not really relevant, but a trick may be to test if a given file is
there. Something like that:

pkg_setup() {
        if [ ! -f ${ROOT}usr/src/linux/Documentation/laptop-mode.txt ] ; then
                eerror "Your kernel does not support laptop mode."
                eerror "Try 2.4.23 and above or 2.6.6 and above."
                die "Kernel too old."
        fi
}

That said, that introduces a DEPEND on virtual/linux-sources for a very small
benefit imho.

Created an attachment (id=51525) [edit]
laptop-mode-tools-1.04.ebuild (merged)

I have merged and cleaned up both ebuild version commited here earlier.

Changes to ebuild:
 - merge DEPEND and instalation of certain bits depending on use-flags
 - fixed typos
 - added pkg_setup() as suggested by TGL, but changed errors to warnings only

People could boot into a laptop_mode enabled kernel any time, so this should
not prevent the package from installing on non-laptop_mode kernels. That's why
I changed the init-script to check if it is available on the current running
kernel, when invoked.

Changes to init-script:
 - add checkconfig()

Created an attachment (id=51527) [edit]
laptop-mode.init

The merged ebuild has a bug in DEPEND:
--- attachment.cgi?id=51525     2005-03-22 17:59:22.498246700 +0200
+++ laptop-mode-tools-1.04.ebuild       2005-03-22 17:59:58.156839244 +0200
@@ -10,9 +10,10 @@
 SLOT="0"
 KEYWORDS="~x86"
 IUSE="acpi apm doc"
-DEPEND=        "acpi?  ( sys-apps/acpid )
-        apm?   ( sys-apps/apmd )
-        virtual/linux-sources"
+
+DEPEND=" acpi?( sys-power/acpid )
+                apm? ( sys-apps/apmd )
+                virtual/linux-sources"

There should be no space after DEPEND and sys-apps/acpid is now sys-power/acpid

Someone should mark the old attachments as obsolete. 

I've added this to app-laptop/laptop-mode-tools. Thank you to all who commented
on this bug report.

Laptop-mode-tools 1.05 is out..

... and it was added to portage two days ago:

*laptop-mode-tools-1.05 (11 Apr 2005)

  11 Apr 2005; <brix@gentoo.org> +files/laptop-mode-tools-1.05.init,
  +laptop-mode-tools-1.05.ebuild:
  Version bump.