On Sun, 2008-01-13 at 21:51 -0600, Aren Olson wrote:
> In gutsy I believe the chain is this:
>
> gnome-power-manager -> hal
> (/usr/lib/hal/scripts/hal-system-power-suspend) -> acpi-support
> (/etc/acpi/sleep.sh)
> most of the actual work occurs in acpi-support.
>
> hal may call a different too
In gutsy I believe the chain is this:
gnome-power-manager -> hal
(/usr/lib/hal/scripts/hal-system-power-suspend) -> acpi-support
(/etc/acpi/sleep.sh)
most of the actual work occurs in acpi-support.
hal may call a different tool than acpi-support if it is available
though, see /usr/lib/hal/script
hi,
just upgraded to hardy and suspend-to-ram is broken again (as in feisty
& other releases) i'm trying to figure out, again, how to track down
this bug but i'm not entirely sure what the current chain of events is
in the suspend process. can someone point me to a location where the
process is
I use an amd64 system, but some applications are only available for the i386
architecture. Some prominent examples are Adobe Flash, Google Earth, and
zsnes (which is written in assembly language, so I don't reckon to see it
ported EVER.)
I can usually get these i386 programs to run, but they requi
Stephan Hermann wrote the following on 13.01.2008 20:20
Hi Stephan
>> according to packages.ubuntu.com cdrtools isn´t in the archive since edgy and
>> even in edgy it is only a transitional package only iirc.
>
> This is not correct...according to soyuz:
> https://edge.launchpad.net/ubuntu/+sour
Hi,
On So, 2008-01-13 at 17:29 +0100, Thilo Six wrote:
> Stephan Hermann wrote the following on 13.01.2008 15:17
>
> > Dear Colleagues,
> >
> > as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I
> > really wonder what way we should go.
> >
> > Regarding the non-freeness of cdrt
Am 13.01.2008 um 02:45 schrieb Bryan Quigley:
> I don't believe either is implemented yet:
> Torrents check files in pieces so if some of the pieces have not
> changed they won't need to be redownloaded.
While this sounds good in theory, it rarely works in practice: Remove
a byte from the fi
Stephan Hermann wrote the following on 13.01.2008 15:17
> Dear Colleagues,
>
> as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I
> really wonder what way we should go.
>
> Regarding the non-freeness of cdrtools, we should concentrate on getting
> the cdrkit binaries to the upst
Dear Colleagues,
as I wrote on http://www.sourcecode.de/content/cdrkit-vs-cdrtools I
really wonder what way we should go.
Regarding the non-freeness of cdrtools, we should concentrate on getting
the cdrkit binaries to the upstream projects.
Most of the apps I found in debian/ubuntu, which are us
