xfburn crashes when hal isn't running

See also here:

http://ubuntuforums.org/showthread.php?p=8289988

Has already been reported upstream. I've read somewhere (sorry, I don't remember where) that the xfce project has no intention to move to udev.

http://bugzilla.xfce.org/show_bug.cgi?id=5965

Hi,

Thanks for your bug report.
Indeed, Xfburn is still relying on hal, but this is expected, not a bug.

Could you paste here the results of the following commands?
LANG=C apt-cache policy hal
LANG=C status hal

Thanks!

Ok.

totty@Kapitaen:~$ LANG=C apt-cache policy hal
hal:
  Installed: 0.5.13-1ubuntu8
  Candidate: 0.5.13-1ubuntu8
  Version table:
 *** 0.5.13-1ubuntu8 0
        500 http://de.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

totty@Kapitaen:~$ LANG=C status hal
Command 'status' is available in '/sbin/status'
The command could not be located because '/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative priviledges associated with your user account.
status: command not found

totty@Kapitaen:~$ sudo LANG=C status hal
[sudo] password for totty:
hal stop/waiting

So hal is not runnig. If I start hal, then xfburn starts, too.

totty@Kapitaen:~$ sudo /etc/init.d/hal restart
Rather than invoking init scripts through /etc/init.d, use the service(8)
utility, e.g. service hal restart

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the restart(8) utility, e.g. restart hal
hal start/running, process 16008
totty@Kapitaen:~$ sudo LANG=C status hal
hal start/running, process 16008
totty@Kapitaen:~$ xfburn
** Message: Using Thunar-VFS 1.0.1
** Message: Using HAL
** Message: Using gstreamer transcoder.

Cheers
Torsten

Ok, thanks for the feedback. You might want to file another bug against hal now, because it shouldn't have crashed/it should be started automatically in the first place.

This bug was fixed in the package xfburn - 0.4.2-2ubuntu1

---------------
xfburn (0.4.2-2ubuntu1) lucid; urgency=low

  * Merge from Debian testing, remaining Ubuntu changes:
    - debian/patches/01_fix-infinite-dialog-spawn.patch: fix Xfburn asks an
    unlimited number of times to erase disk. LP: #434031

  * debian/patches/02_keep-the-devlist-around.patch: do not crash when there is
    a property change in a drive. LP: #410716
  * debian/patches/03_uint-screwed-up-the-1-return.patch: do not crash if hald
    isn't running. LP: #480704

xfburn (0.4.2-2) unstable; urgency=low

  * debian/control:
    - switch section to xfce.
    - update standards version to 3.8.3.
    - promote hal to Depends: since xfburn will crash without.
  * debian/watch edited to track Xfce archive reorganisation.
 -- Lionel Le Folgoc <email address hidden> Sun, 22 Nov 2009 18:20:56 +0100

ACK

I don't fully understand this bit:

-Suggests: hal
+Recommends: hal

Isn't hal instlaled by default anyway? In karmic, without hal you would not even get X up and running, after all. Also, it won't change anything if the hal package is installed, but hald is not running (it might have crashed, or people might simply stop it). What was the actual intent of this?

I came across this after an 8.10-9.04-9.10 update. X was up and hal was not running. I don't know why as hal is now started automatically. But whatever happens xfburn should not segfault.

> In karmic, without hal you would not even get X up and running, after all.

Oops, yeah, I got tricked by all this halsectomy stuff. You can reject it, I'll reupload a new package without this change.

Lionel Le Folgoc [2009-12-03 18:38 -0000]:
> Oops, yeah, I got tricked by all this halsectomy stuff. You can reject
> it, I'll reupload a new package without this change.

I don't mind having it, I just wondered whether the intent of this was
a different one. The program shouldn't crash either way if hal is not
running, but I don't consider it a major SRUable bug if it crashes
only if hal is not running (since for karmic, hal is still pretty much
"must have").

Well, here, in karmic, hal very unstable. I have to respawn it very often, because it has crashed, with no good reason (I've not had time to look into this issue, I only noticed it often crashes when I install something udev related in a pbuilder).

Moreover, this bug report is about a crash with xfburn when hald isn't running. Although the real bug is in hal, there is a bug in xfburn, which should handle this gracefully (this is fixed by the patch), so better safe than sorry. If you don't think this is suitable for a SRU, please reject the package and close this bug report (and probably Bug #410716 as well).

Accepted xfburn into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Now I get a message box telling me that there is no drive for burning available. This means it works as expected. Doesn't it?

totty [2009-12-08 14:02 -0000]:
> Now I get a message box telling me that there is no drive for burning
> available. This means it works as expected. Doesn't it?

I guess so. If it uses hal for detecting drives, and hal is not
running, that's probably the best you can get.

This bug was fixed in the package xfburn - 0.4.2-1ubuntu1.1

---------------
xfburn (0.4.2-1ubuntu1.1) karmic-proposed; urgency=low

  * debian/patches/02_keep-the-devlist-around.patch: do not crash when there is
    a property change in a drive. LP: #410716
  * debian/patches/03_uint-screwed-up-the-1-return.patch: do not crash if hald
    isn't running. LP: #480704
  * debian/control: promote hal to recommends, as xfburn tries to use it first
    (and falls back to libburn after).
 -- Lionel Le Folgoc <email address hidden> Tue, 01 Dec 2009 15:06:51 +0100