Cc-ing debian-bsd, else they may simply not be aware of the thread...
Michael Biebl, le Thu 31 Mar 2011 14:30:06 +0200, a écrit :
> Am 31.03.2011 07:26, schrieb Reinhard Tartler:
> > On Wed, Mar 30, 2011 at 19:51:17 (CEST), Michael Biebl wrote:
> >> HAL removal is already in progress, see . Actually I've been working on that
> >> for some time already. I wouldn't object obviously making that a release goal.
> > How well does kFreeBSD cope with HAL gone missing? AFAIUI udev isn't
> > available there.
> I ran apt-cache rdepends on an up-to-date kfreebsd sid VM.
> Attached are the rdeps for libhal1, libhal-storage1 and hal.
> As you can see, xserver-xorg still uses hal on kfreebsd, but iirc KiBi did some
> work in that regard.
AFAIK, it was agreed that hal is needed for now. FreeBSD's devd should
be a long-term replacement.
> Then there is GNOME/gvfs/gnome-mount using hal on kfreebsd: I don't know if hal
> support can be disabled in gvfs for kfreebsd and what consequences that would
> have. Most likely stuff like automounting wouldn't work anymore.
> Xfce 4.8 (for the most part) doesn't rely on hal anymore, at least on Linux.
> Yves-Alexis, what is the fallback on kfreebsd? Does Xfce 4.8 on kfreebsd still
> require hal or will it just have reduced functionality?
> KDE 4.6 respectively Solid in KDE SC 4.6 will use the newer interface like
> upower on Linux.
> I don't know what the KDE team plans for the kfreebsd ports. Will Solid still
> use hal there?
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Archive: 20110331133345.GT10438@const.bordeaux.inria.fr">ht tp://lists.debian.org/20110331133345.GT10438@const.bordeaux.inria.fr
03-31-2011, 02:57 PM
Samuel Thibault <email@example.com> (31/03/2011):
> Michael Biebl, le Thu 31 Mar 2011 14:30:06 +0200, a écrit :
> > As you can see, xserver-xorg still uses hal on kfreebsd, but iirc
> > KiBi did some work in that regard.
> AFAIK, it was agreed that hal is needed for now. FreeBSD's devd
> should be a long-term replacement.
That it stalled for now. Need to check with xorg developers whether
doing book keeping in the server (rather than in a separate daemon,
which indeed sounds bad) would be appropriate. Last activity is
Guillem's suggestion, as mentioned on .