gparted-0.3.7 requires sys-apps/hal to be installed and /etc/init.d/hald to be started. If you do not do that, the gparted wrapper script (that executes gpartedbin) will complain about the HAL. You should add "sys-apps/hal" to RDEPEND, and we must be sure that /etc/init.d/hald is stated. Reproducible: Always
if you could actually paste or attach the output. It it's not fatal I'd say it's not a bug. Ask upstream to make the output clearer.
If I stop the hald service on my system, I have the following error: # /etc/init.d/hald stop # gparted Could not initialise connection to hald. Normally this means the HAL deamon (hald) is not running or not ready. So I just think GParted-0.3.7 cannot work without the HALD daemon.
(In reply to comment #2) [...] > So I just think GParted-0.3.7 cannot work without the HALD daemon. This is confirmed. From the ChangeLog: * gparted.in: Added new calling script gparted - This is to permit using hal-lock to acquire device locks to prevent automounting prior to executing gpartedbin. - Closes GParted bug #324220 - Thanks to Deji Akingunola for the hal-lock invocation idea I've asked upstream to document and add a configure-time check on the bug mentioned above (b.gnome.o).
there is no need for a configure time check, the script should just be smart and detect hal presence at runtime. Please paste the upstream bug link in the URL field.
(In reply to comment #4) > there is no need for a configure time check, the script should just be smart > and detect hal presence at runtime. Please paste the upstream bug link in the > URL field. Didn't think of that. Looks like it's already been added as a dependency. Further dialogue with developers required, I guess. Bug: http://bugzilla.gnome.org/show_bug.cgi?id=324220 (I can't edit the URL field)
integrated upstream change in r1.
