On Tue 15. Nov - 04:38:57, Michael Biebl wrote:
> Hi all,
>
> I've been working on packages for Debian and (K)Ubuntu and work is
> progressing nicely. I've already been in contact with Danny and Holger
> so I hope they forgive me if I repeat myself.
> As the Debian packages for hal/dbus are outdated I packaged
> powersave-0.9.25/kpowersave-0.4.5 and these packages have just been
> uploaded to the official Debian archive. They are currently in the NEW
> queue and if everything goes right will be accepted the next days.
> For (K)Ubuntu I packaged powersave-0.10.19/kpowersave-0.5.0 and uploaded
> them to my private archive at:
> http://www.teco.edu/~biebl/ubuntu
> There is a short instruction how people can add this repository to their
> sources.list. If you want you may link to this page.
> I will however get in touch with the (K)Ubuntu people to get
> (k)powersave officially into their archive. But for now you can use my
> private repository as an interim solution.
Thanks a lot for your efforts and comments.
>
> So much for the good news ;-) During the packaging I encountered some
> problems/inconsistencies that I'm now going to itemise. I'll try to
> always specify the version and package in question.
>
> kpowersave:
>
> 1.) [0.4.5/0.5.0] Please distribute the autotools generated files with
> the tarball. The easiest way to achieve that is to use "make dist".
This should be no problem because make dist should work with newer
versions of kpowersave
>
> For this
> 2.) [0.4.5] set the correct version in configure.in.in (AM_INIT_AUTOMAKE)
>
> 3.) [0.4.5/0.5.0] build path != source path not possible (make install
> fails). Fix: See attachement absolute_build_path_fix.diff
Thanks for the patch.
>
> 4.) [0.5.0] Please specifiy the mininum required versions of hal/dbus in
> configure.in.in. Does it really have to be 0.33/0.5.4 or is an older
> version sufficient?
It _has_ to be dbus >0.3x, but IMO the hal version does not matter
mutch. Kpowersave even does not need hal at all, only for linking with the
powersave library.
>
> 5.) [0.4.5/0.5.0] Dependency to old Qt1/Qt2 headers, e.g. qvector.h.
> Imo it would be a good idea to use the Qt3 counterparts.
>
> 6.) [0.4.5/0.5.0] Path to sound files in settings dialog is hard coded
> to /opt/kde. Please use @prefix@ and respect the path that is already
> set, i.e. if the use has set e.g. /usr/share/sounds/bla/blub.ogg start
> with path /usr/share/sounds/bla/ and *not* the default path.
>
> 7.) [0.4.5/0.5.0] Use KDialogBase for settings dialog. That way the user
> settings are used (icons on buttons etc.)
>
> 8.) [0.4.5/0.5.0] If battery runs out I get xmessages that a powersaved
> event was received with no further informations. That is pretty useless
> imo.
Do you look at these issues danny?
>
> powersave:
> 9.) [0.9.25] No autotools generated files in tarball, fixed in 0.10.19
We won't do this for older versions, sorry.
>
> 10.) [0.9.25/0.10.19] AUTHORS, ChangeLog, TODO, NEWS empty or missing.
I will add contents to the AUTHORS file.
NEWS? We have none ;-) We try to file news items to sourceforge or
forge.novell.com regulary. I think it is pretty useless to have them
multiple times at different locations.
A todo file is there, but it is called Todo.
Nevertheless, missing should be none.
>
> 11.) [0.9.25/0.10.19] /etc/acpi/events.ignore/events.ignore is installed
> with mode 744, should be 644.
Will correct that.
>
> 12.) [0.9.25] /etc/sysconfig/powersave/disk has a shebang line at the
> beginning of the config file but is no bash script.
Does this make any problems? If not, I would say it is sufficcient that it
is fixed in newer versions.
>
> 13.) [0.9.25/0.10.19] wttyhx installed to @prefix@/bin, why not to
> @prefix@/powersave/scripts?
Good question ;-) I also vote for installing it in
@prefix@/powersave/scripts.
>
> 14.) [0.9.25/0.10.19] so versioning: so version is pretty high. Is the
> API really that unstable? Did you really follow [1] for library
> versioning? I read a CVS commit saying that the so version was bumped
> to follow the package version increase. That is normally not the way to
> do it.
It is not that unstable. I know that the versioning was made wrong in the
past, but I see no need to correct it afterwards.
> 15.) [0.9.25/0.10.19] rcpowersaved: For Debian I don't install this
> script/link as this is not Debian style. If powersaved is not running
> kpowersave displays a warning message saying that you should use
> "/usr/sbin/rcpowersaved start". Maybe this error message could be
> rephrased.
Maybe we use no path at all. Just giving a hint to start the daemon should
be enough because it should run anyway.
>
> 16.) [0.9.25/0.10.19] Many scripts in /usr/lib/powersave have hard coded
> paths, e.g /opt/kde or /usr/bin. Either use binaries without path or
> determine correct path during ./configure (see Makefile.am/bin_SCRIPTS)
Trying to find the binaries in $PATH should be the better solution,
otherwise we would have to add a script.in file for every script.
>
> 17.) [0.9.25/0.10.19] There is no grubonce in Debian. So changing the
> default bootentry is not working yet. Still looking for a good solution.
>
> 18.) [0.10.19] pam_console: Debian has not enabled pam_console support
> so the default dbus-1/system.d/powersave.conf is not working. I added a
> section similar to <policy at_console="true">..</policy> and replaced
> the policy with <policy group="plugdev">.
As you already did, I think such things should be done by the distribution
maintainer himself. But I will think about an universal solution here.
>
> 19.) [0.9.25/0.10.19] Dependency on /proc/acpi/sleep. If
> /proc/acpi/sleep support is disabled in kernel (deprecated since 2.6.13)
> powersave doesn't provide the suspend_to_ram option. If /proc/acpi/sleep
> is not found try /sys/power/state. Affected file: libpower/sleep.c
Will do that.
>
> 20.) [0.9.25/0.10.19] on_ac_power binary: name clash with powermgmt_base
> package. I don't know if this package exist in SuSE. For Debian I don't
> install on_ac_power from powersaved but add a Run-Dependency to
> powermgmt_base. I'm not sure if it has the same interface/output. How
> does on_ac_power have to behave?
Usage: on_ac_power [-q]
returns 0 if on AC power or unable to determine ac state
returns 1 if on battery power
-q: quiet mode
We did not know that there is a name clash. I will rename it. As far as I
can see, it is used only at one point in helper_functions.
>
> 21.) [0.9.25/0.10.19] function keyword in init script is a bashism. Do
> you really need bash specific features? Otherwise it would be good to
> use #!/bin/sh in script header and check the scripts with
> "checkbashisms". That way you can replace the default shell with
> something lighter like dash.
This would IMO be also good. But I'm not sure how much work this will
cause. Stefan, can you estimate if there are many bash specific features
in our scripts?
>
> 22.) [0.10.19] Typo in restore_after_suspend_to_disk line 44: "init.de"
Fixed in cvs.
>
> 23.) [0.10.19] What is the minimum required version for hal
> (configure.ac only checks the min version for dbus)
I'm not exactly sure about this. But 0.5x is not mandatory needed IMHO. I
hope Danny can tell us when the api changed the last time. If there are
unsupported information in ealier version, this should not matter because
then the information would simply not be available.
>
> 24.) [0.10.19] --enable-hal disables hal support ;-)
> Obviously not what you'd expect if you have a --disable-hal switch.
Ups ;-)
>
> 25.) [0.9.25/0.10.19] Dependency on apmd: The powersaved script
> complains and exits if apmd is running. Is it safe to enforce the
> removal of the apmd if powersaved gets installed or are there
> applications that need apmd and its tools? I intended to add "Conflicts:
> apmd" to the powersaved package so that apmd gets deinstalled if you
> want to install powersaved. Is that the Right Way(TM) in your opinion?
IMHO yes. On SUSE there are no tools that need apmd, or at least no tools
installed by default that need it. I never used it, so maybe Stefan can
tell us his opinion ;-)
>
> 26.) [0.10.19] sleep_helper_functions: Detect if pccardctl or cardctl is
> installed and use the found binary. Do not expect a user to edit
> sleep_helper_functions and set the correct binary.
Will do that.
>
> Ideas:
> 27.) Enable/Set power management for wireless cards. Wireless cards
> demands lots of power. For working cards enable low power modes when on
> battery.
Runtime powermanagement for devices supporting the pci powersaving states
is nearly finished. A first version was checked in to cvs already that
supports suspending of usb, sound, lan and wlan devices. But I still have
to check if how to integrate the wlan powersaving features.
>
> 28.) Restore console resolution/state with vbetool. Don't know if it is
> safe to enable this but I find it quite annoying to switch to X and back
> to the console to restore the correct resolution of the console. 0.10.19
> seems to have a script in contrib.
>From what I know, vbetool can be dangerous sometimes. Seife?
>
> 29.) Provide emulation for apmd. See point 25 for that. Would it be
> feasible to provide wrapper scripts like "apm" which provide the same
> interface as the original apm tools and call the corresponding powersave
> methods?
I first have to check how much work this would be. If you like to do it,
go ahead ;-)
>
> 30.) DB for working combinations of hardware (laptop), used
> framebuffer(vesa,vga16,..), possible suspend states, needed boot parameters.
> It would be great if we would start to collect data of known working
> settings. For my case (HP nx7000) I had to disable radeonfb and use
> vesafb and set the boot parameter acpi_sleep=s3_bios,s3_mode in order to
> get suspend_to_ram working. We could use this data during postinst to
> preset the values in @sysconfdir@/powersave.
> Maybe we could set up a web form where user can enter there working
> setup. What would be needed then:
> - hardware
> - kernel revision
> - used framebuffer
> - boot flags
> - suspend2disk working
> - suspend2ram working
> Anything else?
>
> That would mean a great benefit imo for users if they don't have to
> experiment with different bootflags etc. and just get a working setup.
There is a list for suspend to ram in the linux kernel documentation in
Documentation/power/video.txt and something similar at
http://www.opensuse.org/HCL/Laptops. But you are right that there should
be an easy way to get users to integrate their own experiences. Have to
think about it a little more...
Thomas is already working on some kind of post install script to adapt
some configurations. Maybe these things can be integrated...
>
>
> I know the list got quite long and I've surely missed some points I
> wanted to address. Nevertheless I hope you all read till the end and
> give me some feedback on this points.
Yes, thank you again for your feedback. One of our problems is that we do
not get in touch with other distributions that often, so there might be
some SUSE-specific things which we did not notice at all. So feedback from
other distribution users/maintainers is one important sources we have to
extend the package.
>
> Last but not least kudos to you all! I think (k)powersave is great
> software, let's try to make it better ;-)
That's what we are trying to do ;-)
>
> Cheers,
> Michael
>
> [1] http://sources.redhat.com/autobook/autobook/autobook_91.html
Thanks,
Holger
_______________________________________________
powersave-devel mailing list
[email protected]
http://forge.novell.com/mailman/listinfo/powersave-devel
