Hi, > Command for what?
For building the Brasero that was downloaded as source. dpkg-buildpackage seems to be the right one. > But as George put, the problems are about Data projects, that > means - as far as I understand - to choose some files from your disk and > burn them directly to a CD/DVD medium. Sure. I clicked on a directory with about 350 MB underneath. The installed brasero burns this to disk file, to DVD+RW and to CD-RW. All three results can be mounted and show most of the files from the chosen directory tree. Only those files are missing, whose names begin by '.'. (Not the fault of libisofs, i am quite sure.) I will try to clean the system from my own libburn installation. Then it should be possible to link brasero with a Debian-provided libburn. (Whatever "relocation R_X86_64_32 against `.rodata.str1.8'" might mean.) Nevertheless, i expect to be miserably successful with burning. The timestamps look as if the already installed brasero and the source are of exactly the same revision. The test machine is amd64. Can it be that the problems appear only on i386 ? Maybe we have a size mismatch of off_t ? That can produce about any weird effect. libisofs applications must obey this prescription from libisofs.h: * Applications must use 64 bit off_t. * E.g. on 32-bit GNU/Linux by defining * #define _LARGEFILE_SOURCE * #define _FILE_OFFSET_BITS 64 * The minimum requirement is to interface with the library by 64 bit signed * integers where libisofs.h or libisoburn.h prescribe off_t. * Failure to do so may result in surprising malfunction or memory faults. A little change in Brasero's build system could bring this out of sync on 32 bit systems. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
