! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
(FreeBSD) xfburn blocks access to USB drive and vice versa
Status:
RESOLVED: INVALID

Comments

Description markus.hoenicka 2009-07-06 11:08:51 CEST
xfburn 0.4.1 running on FreeBSD 7.2 and XFCE 4.6.1 shows a strange interaction with USB which prevents burning data directly from USB drives.

How to reproduce:

Method 1:

Plug in and mount the USB drive, then attempt to start xfburn (from
a console, to see extra output). xfburn (or a library loaded by
xfburn) prints the message "** Message: Using Thunar-VFS 1.0.1", but
the xfburn main window never shows up. There is no core file btw.

Method 2:

Start xfburn, which comes up just fine. Then plug in the USB
drive. The system does not recognize the drive (no entry shown by
dmesg or on the console), and there is no way to mount it. This odd
situation persists even after closing xfburn. It is only after a reboot
that the drive shows up again.

To the best of my knowledge, hal is not used ('dmesg|grep hal' returns nothing).
Comment 1 David Mohr 2009-07-08 18:38:14 CEST
Hi,
please update to current SVN, which will output a message on the console if HAL is used.

Also have a look at the README, which explains how to generate a backtrace when xfburn is stuck.

Debugging this might be a bit painful, because I think the issue is (Free)BSD specific - on my Linux box it works just fine. But, if you have the patience, I'm sure we can fix it.
Comment 2 markus.hoenicka 2009-07-08 21:00:44 CEST
I'm afraid I'll need a little guidance here. I usually use FreeBSD's ports collection to install XFCE and goodies. I'm sufficiently familiar with building apps from sources, but I have no experience with building XFCE apps whatsoever.

I pulled the sources from svn:

svn co http://svn.xfce.org/svn/goodies/xfburn/trunk xfburn

Then ran ./autogen.sh which told me to install the xfce4-dev-tools. I did so using the FreeBSD port. I ran ./autogen.sh again, which finished ok with just a few odd test results:

checking dynamic linker characteristics... /libexec/ld-elf.so.1: Shared object "libc.so.6" not found, required by "f77"
freebsd7.2 ld.so

This may be due to recent 6.4 -> 7.2 upgrade hassles, but I doubt that this is relevant for the problem at hand.

test: xyes: unexpected operator

??

The hal-related tests look like this:

checking for hal-storage >= 0.5.7... 0.5.11
checking HAL_CFLAGS... -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/local/include/hal -I/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include  
checking HAL_LIBS... -L/usr/local/lib -lhal-storage -lhal -ldbus-1  
checking whether LIBHAL_DRIVE_CDROM_CAPS_DVDPLUSRWDL is declared... yes

Running make results in the following error:

make  all-recursive
Making all in desktop-integration
make: don't know how to make thunar-sendto-xfburn.desktop. Stop
*** Error code 1

How can I make this work?

regards,
Markus
Comment 3 David Mohr 2009-10-13 03:46:59 CEST
Sorry I never followed up on this.

By now 0.4.2 has been released, which I assume is in freebsd. Please try that, which has has the commits I was talking about earlier in this bug.

For the record, you are probably missing the 'desktop-file-utils' package (at least that's what it's called in debian) to compile from source.
Comment 4 Skunnyk editbugs 2017-11-11 20:19:25 CET
I close this old bug (hal is not used anymore). Please reopen if needed.

Bug #5530

Reported by:
markus.hoenicka
Reported on: 2009-07-06
Last modified on: 2017-11-11

People

Assignee:
Xfburn Bug Triage
CC List:
2 users

Version

Attachments

Additional information