On Mon, Sep 04, 2006 at 04:57:54PM +0200, martin f krafft wrote:
> also sprach Sjoerd Simons <[EMAIL PROTECTED]> [2006.09.04.1622 +0200]:
> > It already does that, it first tries the proc interface, then the socket.
> > The
> > problem is that afaik /var/run might be empty on boot, so checking for
also sprach Sjoerd Simons <[EMAIL PROTECTED]> [2006.09.04.1622 +0200]:
> It already does that, it first tries the proc interface, then the socket. The
> problem is that afaik /var/run might be empty on boot, so checking for
> /var/run/acpid.socket then doesn't really help.
It should first try the
Am Montag 04 September 2006 15:36 schrieb Sjoerd Simons:
> On Tue, Aug 22, 2006 at 12:54:54PM -0700, Steve Langasek wrote:
> > It's clear that hald has the means to work whether acpid is started in
> > advance or not, but that acpid has no such mechanism to cope with hald
> > blocking its access to
also sprach Sjoerd Simons <[EMAIL PROTECTED]> [2006.09.04.1536 +0200]:
> I don't want hal depending on acpid. I will patch the hal acpi addon to not
> directly use the proc interface iff /usr/sbin/acpid exists.
Doesn't acpid provide access to the data through
/var/run/acpid.socket ?
I'd say hal s
On Mon, Sep 04, 2006 at 04:07:59PM +0200, martin f krafft wrote:
> also sprach Sjoerd Simons <[EMAIL PROTECTED]> [2006.09.04.1536 +0200]:
> > I don't want hal depending on acpid. I will patch the hal acpi addon to not
> > directly use the proc interface iff /usr/sbin/acpid exists.
>
> Doesn't acpi
On Tue, Aug 22, 2006 at 12:54:54PM -0700, Steve Langasek wrote:
> It's clear that hald has the means to work whether acpid is started in
> advance or not, but that acpid has no such mechanism to cope with hald
> blocking its access to /proc/acpi/event. Nor should it, AFAICT.
>
> If we want reliab
Processing commands for [EMAIL PROTECTED]:
> reassign 380520 hal,acpid
Bug#380520: acpid and hald conflict
Bug reassigned from package `acpid' to `hal,acpid'.
> quit
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debi
reassign 380520 hal,acpid
quit
On Tue, Aug 22, 2006 at 02:51:14PM -0400, Filipus Klutiero wrote:
> reassign 380520 acpid
> thanks
> >But hald is started by udev, so it's hard to control that order sensibly.
> ^^ dbus
> It's not so hard. By default it wor
reassign 380520 acpid
thanks
But hald is started by udev, so it's hard to control that order sensibly.
^^ dbus
It's not so hard. By default it works fine after reboot.
This means that *hal* is breaking *acpid*, not vice versa.
Right, so acpid is "b
reassign 380520 hald
thanks
I believe that acpid has the prior claim on
/proc/acpi/events.
Furthermore, if acpid starts first, hald runs.
But if hald starts first, acpid doesn't run. This
means that *hal* is breaking *acpid*, not vice
versa. So, hal's bug.
--
Nathanael Nerode <[EMAIL PROTEC
10 matches
Mail list logo
