|
Home > Archive > Debian Developers > September 2006 > Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#389817: ITP: pm-utils -- utilities and scripts usefull for power management
|
|
| Tim Dijkstra 2006-09-27, 7:38 pm |
| Package: wnpp
Severity: wishlist
Owner: "Tim Dijkstra" <tim@famdijkstra.org>
* Package name : pm-utils
Version : 0.0.1
Upstream Author : Bill Nottingham <notting@redhat.com>, Peter Jones
<pjones@redhat.com>, David Zeuthen <davidz@redhat.com>, Richard Hughes
<richard@hughsie.com>
* URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/
* License : GPL
Programming Lang: C, Shell
Description : utilities and scripts usefull for power management
Provides simple shell command line tools to suspend and hibernate
computer that can be used to run vendor or distro supplied scripts
on suspend and resume.
--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steinar H. Gunderson 2006-09-27, 7:38 pm |
| On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
> Provides simple shell command line tools to suspend and hibernate
> computer that can be used to run vendor or distro supplied scripts
> on suspend and resume.
This is something like the fifth package in Debian that attempts to do this.
What sets is apart from the ones already in Debian? Do we really need another
one?
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Gran 2006-09-27, 7:38 pm |
| This one time, at band camp, Tim Dijkstra said:
> Op Wed, 27 Sep 2006 23:41:01 +0200
> schreef "Steinar H. Gunderson" <sgunderson@bigfoot.com>:
>
>
> This will make all others obsolete;)
>
> More seriously, this will be a dependency of HAL and with that of the
> whole gnome power management stack. So I think we can't go around it in
> the future. I wanted to package it to make sure it plays nice with
> uswsusp (another package I maintain).
Not that I actually object to the package, but why can't HAL let acpid
manage acpi events? I am continually confused by the profusion of
packages that offer to work around acpid in order to provide the
functionality it could and should be providing.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
| |
| Michael Banck 2006-09-27, 7:38 pm |
| On Wed, Sep 27, 2006 at 11:41:01PM +0200, Steinar H. Gunderson wrote:
> On Wed, Sep 27, 2006 at 11:08:24PM +0200, Tim Dijkstra wrote:
>
> This is something like the fifth package in Debian that attempts to do this.
> What sets is apart from the ones already in Debian? Do we really need another
> one?
* Upstream Author : Bill Nottingham <notting@redhat.com>, Peter Jones
<pjones@redhat.com>, David Zeuthen <davidz@redhat.com>, Richard Hughes
<richard@hughsie.com>
* URL : http://webcvs.freedesktop.org/pm-utils/pm-utils/
I think this is the one to rule them all.
Michael
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Gran 2006-09-27, 7:38 pm |
| This one time, at band camp, Tim Dijkstra said:
> Op Thu, 28 Sep 2006 00:00:28 +0100
> schreef Stephen Gran <sgran@debian.org>:
>
>
> Note that this package is not really related to acpid, but I'll try to
> answer anyway. Acpid is just another deamon listening
> to /proc/acpi/event. It doesn't have a good way of communicating with
> a user.
> HAL is also able to listen to acpi events (by listening
> to /proc/acpi/event or acpid). The advantage HAL has over acpid, is
> that it is very well integrated in to the users (kde or gnome) session.
> That way it is able to notify the user (he, your battery is low!) get
> user feedback (should I suspend to ram, to disk?) and act on user
> configuration (suspend to ram when closing the lid, but only when on AC,
> else suspend to disk).
>
> Now acpid has technically nothing to do with bringing the machine in a
> sleep state. For that to work you have basically three options:
> 1) Patch your kernel with suspend2
> 2) Use swsusp build in kernel
> 3) Use uswsusp which is partly in kernel, partly user space.
> I think that with the profusion of packages you talk about are the
> packages (like pm-utils) the try to work around bugs in drivers and
> offer functionality before and after the actual sleep. Things like
> syncing the clock, stopping services, networks, fixing the state of
> the graphics card.
>
> I hope this clears it up a bit
Only a little. Perhaps I am just of the old skool 'do one job and do
it well' mind set, but all of those events appear to be acpi events
which acpid handles rather well, even in the brave new world of single
user linux on laptops that Ubuntu and others have brought us. You do
know that acpid can run arbitrary scripts on acpi events, like say,
lid close, right? I understand that this package is no different than
a dozen others, in that it tries to provide policy layers and cute
gui things on top of acpid, but it just seems like too many layers of
abstraction and replicated code bases to me.
But, as I say, whatever, one more won't hurt. I just feel a little
perturbed when I see some new project that needs HAL, dbus, and a half
dozen other things to handle something that can already be handled with
shell scripts and a very small daemon.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
|
|
|
|
|