GNOME Bugzilla – Bug 377100
[PATCH] Add FreeBSD support to nautilus-cd-burner
Last modified: 2009-08-20 14:22:03 UTC
Please describe the problem: Now that n-c-b relies on HAL to obtain a list of available drives, FreeBSD support is broken. The cdrtools (e.g. cdrecord, cdrdao, readcd, etc.) do not yet support opening device files on FreeBSD. Thus, when these tools are called with -dev=/dev/cd0, they fail. FreeBSD still requires the old x,x,x notation. Not to worry. Our HAL backend knows about this, and provides properties. However, n-c-b needs to be taught to use these properties. To that end, I have added a new private drive struct member: cdrecord_device. On non-FreeBSD platforms, this will be a dup of device. However, on FreeBSD, this will be the old bus,target,lun string. The attached patch adds FreeBSD functionality while preserving Linux and Solaris functionality. Steps to reproduce: 1. Try to burn a CD on FreeBSD using n-c-b 2. 3. Actual results: Expected results: Does this happen every time? Other information: Note: we cannot simply but the x,x,x string in device since this will break applications like sound-juicer which can handle opening the device file.
Created attachment 76856 [details] [review] Fix n-c-b's FreeBSD support
Wouldn't it be better to have a "block.cdrecord_device" property in HAL, rather than special-casing in the applications?
See my extra note at the bottom. If I did this, then applications like sound-juicer that also use n-c-b will fail since x,x,x is meaningless to them. They prefer to open the actual device. Sounds n-c-b needs to be able to tell the difference between the cdrecord device and the regular block device. You can call it whatever you want in HAL (we called it block.freebsd.cam_path), but either way, n-c-b needs extra logic to know when to use this property vs. the actual device.
Unfortunately we'll have to figure out a better way than exposing cdrecord details through the API. I don't want to have a cdrecord_device property.
Joe, is this still valid? http://www.freebsd.org/gnome/docs/faq2.html#q15 makes me belive that n-c-b usually works well on FreeBSD.
It does only because I have been maintaining the patches in this bug locally. n-c-b does not work out-of-the-box on FreeBSD since our cdrecord implementation does not support the dev= notation.
Note that there is a GStreamer plugin for sound-juicer that is based on cdda2wav. It gives better quality and it avoids the license problems from using libcdio. I did write this library together with Sun, check it.... it of course supports the offcial dev= syntax instead of the deprecated dev=/dev/* syntax.
nautilus-cd-burner has been replaced by Brasero in the GNOME 2.26 release. If your bug still applies to Brasero, please feel free to re-open the bug, and reassign it to brasero itself.
This is not a problem that goes away woth Brasero. You would need to use the official cdrtools software instead of the broken fork wodim and you need to implement support to deal with the results from a cdrecord -scanbus output. This is a method that is portable to a lot more platforms than the method brasero currently uses. Note tha cdrtools offers a de-facto platform independence and ports to many more plaforms than Brasero currently does. By using the methods from cdrtools to get the needed information, Brasero would become more portable.
Stop spamming bugzilla with your cdrtools adverts.
Please stop sending your anti-social spam. I am giving real help to the Authors of brasero. If you don't understand this help, this is your problem.
This isn't a forum, and it's not appropriate for you to spam every bug with block assertions that so and so's software is broken. Work with distributions on getting your tools in their distros if you actually want to do something. And for what it's worth, I know how to behave on the GNOME bugzilla, seeing as I posted more than 16 thousand comments on it.
Posting 16 thousand reports does not verify that you have the needed skills. If you don't understand that I am helping with understanding a specific bug, please contact me offline. A bug tracking system is not the appropriate place to allow you to understand things that are unrelated to this bug nor to send your propaganda that looks very anti-social to me. If you carefully read my comments on the various bugs here, you will see that I only comment bugs that are based on well known bugs from specific versions of a software. Giving hints on more up-to date versions of the software is one of the basic ideas for a bug tracking system.
Joerg: You've been banned from GNOME Bugzilla. Please refrain from using any GNOME resources, thanks.