Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Hi, Moritz Muehlenhoff wrote (31 Oct 2012 17:15:28 GMT) : intrigeri, since you could reproduce the problem, could you test, whether this patch fixes the problem for you? I confirm I cannot reproduce the bug anymore with brasero 3.4.1-4. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
On Sat, Oct 20, 2012 at 10:27:54AM +0200, Thomas Schmitt wrote: Hi, a Brasero flaw was found in the course of Debian bug 688229. It would provide an explanation for the problems which are described here. Especially it is involved when burning directly to optical media and not involved when writing ISO filesystems to hard disk. The problem was introduced in october 2012 by http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39 A patch is provided by http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=124;filename=0001-Libburnia-plugin-Fix-while-loop-in-brasero_libisofs_.patch;att=1;bug=688229 Have a nice day :) intrigeri, since you could reproduce the problem, could you test, whether this patch fixes the problem for you? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Hi, i see i made a mistake when writing: The problem was introduced in october 2012 by It was introduced in october 2010, not 2012. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Hi, a Brasero flaw was found in the course of Debian bug 688229. It would provide an explanation for the problems which are described here. Especially it is involved when burning directly to optical media and not involved when writing ISO filesystems to hard disk. The problem was introduced in october 2012 by http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39 A patch is provided by http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=124;filename=0001-Libburnia-plugin-Fix-while-loop-in-brasero_libisofs_.patch;att=1;bug=688229 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
found 617409 3.4.1-3 thanks Hi, I can reproduce this bug in my up-to-date Wheezy system with Burn the image directly enabled, and I can't if I disable this feature. What may I do to help fixing this bug for Wheezy? Is the please try with that patch thing up-to-date for Wheezy's Brasero 3.x? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Am Sonntag, den 23.09.2012, 15:29 +0200 schrieb intrigeri: found 617409 3.4.1-3 thanks Dear intrigeri, thank you for following up on this report without breaking threading. ;-) I can reproduce this bug in my up-to-date Wheezy system with Burn the image directly enabled, and I can't if I disable this feature. Interesting. What may I do to help fixing this bug for Wheezy? Is the please try with that patch thing up-to-date for Wheezy's Brasero 3.x? Could you please take a look at #688229 [1]. Maybe you can provide similar information (exact error, log files, …). Thomas helped me quite a lot and maybe we can save him some time. Maybe even open a separate bug report first. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688229 signature.asc Description: This is a digitally signed message part
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, on the risk to discourage Simon from testing SAO, i have to report a fact that weakens my TAO/SAO theory in his special case. Brasero writes TAO too, when copying an image from hard disk to CD, or when storing a newly generated image intermediately on hard disk. I had hoped to find the final prove by seeing it using SAO in that situation. Bummer (to quote xv). Alain's reports are still matching my theory. Did you yet have any successful burns with CD-R and Brasero ? But Simon's observation and those of some others in the Gnome and Ubuntu bug reports indicate that there is still an ingredient missing. Nevertheless i cannot see how intermediate storing would help improving write success. Only my first CD burners of 1999 and 2000 had no underrun protection and needed a CPU fast enough to continously transfer the data at the burner's speed. Since 2003 all my burners can stand pauses in the data stream. So please, both make a try with SAO. Ask our friendly Debian hosts for help with patching and installing Brasero, if needed. (That's a thing where i myself can only spread confusion.:)) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, for the records: I managed to get my changes in burn-libburn.c into effect by copying from brasero-2.30.3/plugins/libburnia/.libs/libbrasero-libburn.so to /usr/lib/brasero-0/plugins/libbrasero-libburn.so I assume it is better to achieve this the Debian way. At least i could verify that it is possible to change the write type from TAO to SAO by hardcoding it in brasero-2.30.3/plugins/libburnia/burn-libburn.c Re-iterated for convenience: Change all occurences of BURN_WRITE_TAOto BURN_WRITE_SAO BURN_BLOCK_MODE1 to BURN_BLOCK_SAO I advise to issue a loud message on stderr which tells you that the change is really in effect. I have added at file start: #include stdio.h and where i changed the parameters, i added: fprintf(stderr, Brasero libburn-plugin: * brasero_libburn_start_record : Write type is SAO\n); resp. fprintf(stderr, Brasero libburn-plugin: * brasero_libburn_start_erase : Write type is SAO\n); The resulting CDs can be examined by xorriso -outdev /dev/sr0 -check_media what=disc use=outdev If it is TAO, then you get two read errors at the end. If it is SAO, then you get an inappropriate warning that your image is larger than the CD track. A little bug in libburn's CD inspection code. It will be fixed by the next release. The image should be usable anyway. Images from wodim -no-pad show the same effect. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Hi On 06.07.2012 20:18, Thomas Schmitt wrote: But anyway, I updated to brasero 3.4.1 and I can still reproduce the bug. How did you do that ? My squeeze only fetches 2.30.3. I'm running Wheezy (testing). The version diff to unstable is very small. [22796.601067] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 02 00 00 02 00 [22796.605520] sr 0:0:0:0: [sr0] Sense Key : Not Ready [current] [22796.605525] sr 0:0:0:0: [sr0] Add. Sense: Medium not present The medium is bad. At least after having been written. The drive does not even acknowledge its existence. What do you get from this command while the bad medium is in /dev/sr0 ? xorriso -outdev /dev/sr0 -toc Maybe it is still blank and usable. We'll see. Neither Brasero, Nautilus or K3B recognizes the CD as blank. I created a new CD-RW a small number of pdf files on it. It can not be read. simon@beutelteufel:~$ xorriso -outdev /dev/sr0 -toc xorriso 1.2.2 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Disc status unsuitable for writing Drive current: -outdev '/dev/sr0' Media current: CD-RW Media status : is written , is closed Media summary: 1 session, 3822 data blocks, 7644k data, 0 free Drive current: -outdev '/dev/sr0' Drive type : vendor 'PLEXTOR' product 'DVDR PX-800A' revision '1.00' Media current: CD-RW Media product: 97m10s00f/79m59s74f , TDK / Ritek Media status : is written , is closed Media blocks : 3822 readable , 0 writable , 359847 overall TOC layout : Idx , sbsector , Size , Volume Id Other session: 1 , 0 , 3820s , Media summary: 1 session, 3822 data blocks, 7644k data, 0 free Let's try to just burn one directory to CD with MD5 checksums. This here has the right size: $ du -s /usr/bin 230980 /usr/bin du -s /usr/bin 596872/usr/bin $ xorriso -md5 on -outdev /dev/sr0 -map /usr/bin /usr/bin This will fail if the medium is not blank. For CD-RW you may let xorriso decide whether to blank before burning. $ xorriso -md5 on -outdev /dev/sr0 \ -blank as_needed \ -map /usr/bin /usr/bin Burning happens automatically when the program is about to end. simon@beutelteufel:~$ xorriso -md5 on -outdev /dev/sr0 \ -blank as_needed \ -map /usr/bin /usr/bin xorriso 1.2.2 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Disc status unsuitable for writing Drive current: -outdev '/dev/sr0' Media current: CD-RW Media status : is written , is closed Media summary: 1 session, 3822 data blocks, 7644k data, 0 free Beginning to blank medium in mode 'fast'. xorriso : UPDATE : Blanking ( 1.0% done in 1 seconds ) xorriso : UPDATE : Blanking ( 1.0% done in 2 seconds ) xorriso : UPDATE : Blanking ( 3.1% done in 3 seconds ) xorriso : UPDATE : Blanking ( 5.2% done in 4 seconds ) xorriso : UPDATE : Blanking ( 5.2% done in 5 seconds ) xorriso : UPDATE : Blanking ( 7.9% done in 6 seconds ) xorriso : UPDATE : Blanking ( 10.0% done in 7 seconds ) xorriso : UPDATE : Blanking ( 12.3% done in 8 seconds ) xorriso : UPDATE : Blanking ( 14.3% done in 9 seconds ) xorriso : UPDATE : Blanking ( 16.8% done in 10 seconds ) xorriso : UPDATE : Blanking ( 18.9% done in 11 seconds ) xorriso : UPDATE : Blanking ( 21.0% done in 12 seconds ) xorriso : UPDATE : Blanking ( 22.9% done in 13 seconds ) xorriso : UPDATE : Blanking ( 25.0% done in 14 seconds ) xorriso : UPDATE : Blanking ( 27.1% done in 15 seconds ) xorriso : UPDATE : Blanking ( 29.4% done in 16 seconds ) xorriso : UPDATE : Blanking ( 31.4% done in 17 seconds ) xorriso : UPDATE : Blanking ( 33.5% done in 18 seconds ) xorriso : UPDATE : Blanking ( 35.6% done in 19 seconds ) xorriso : UPDATE : Blanking ( 37.7% done in 20 seconds ) xorriso : UPDATE : Blanking ( 39.8% done in 21 seconds ) xorriso : UPDATE : Blanking ( 41.9% done in 22 seconds ) xorriso : UPDATE : Blanking ( 44.0% done in 23 seconds ) xorriso : UPDATE : Blanking ( 46.0% done in 24 seconds ) xorriso : UPDATE : Blanking ( 48.1% done in 25 seconds ) xorriso : UPDATE : Blanking ( 50.2% done in 26 seconds ) xorriso : UPDATE : Blanking ( 52.3% done in 27 seconds ) xorriso : UPDATE : Blanking ( 54.4% done in 28 seconds ) xorriso : UPDATE : Blanking ( 56.5% done in 29 seconds ) xorriso : UPDATE : Blanking ( 58.5% done in 30 seconds ) xorriso : UPDATE : Blanking ( 60.6% done in 31 seconds ) xorriso : UPDATE : Blanking ( 62.7% done in 32 seconds ) xorriso : UPDATE : Blanking ( 64.8% done in 33 seconds ) xorriso : UPDATE : Blanking ( 66.9% done in 34 seconds ) xorriso : UPDATE : Blanking ( 69.0% done in 35 seconds ) xorriso : UPDATE : Blanking ( 71.1% done in 36 seconds ) xorriso : UPDATE : Blanking ( 73.1% done in 37 seconds ) xorriso : UPDATE : Blanking ( 75.4% done in 38 seconds ) xorriso : UPDATE : Blanking ( 77.5% done in 39 seconds ) xorriso : UPDATE : Blanking ( 79.6% done in 40 seconds ) xorriso : UPDATE : Blanking ( 81.7% done in 41 seconds ) xorriso : UPDATE :
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Le 6 juillet 2012, Thomas Schmitt a écrit : xorriso works fine for me with CD-RW and CD-R. This weakens said theory. There might be a difference in CD write mode between xorriso and Brasero. SAO versus TAO. Sometimes the one still works whereas the other is already failing. What xorriso commands did you use exactly ? xorriso -outdev /dev/sr0 -add myfiles Medias are CD-RW. lshw -class disk [...] *-cdrom:0 description: DVD writer product: DVD_RW ND-3540A vendor: _NEC physical id: 2 bus info: scsi@1:0.0.0 logical name: /dev/cdrom logical name: /dev/cdrw logical name: /dev/dvd logical name: /dev/dvdrw logical name: /dev/scd0 logical name: /dev/sr0 logical name: /media/Disque-5 version: 1.04 serial: [_NECDVD_RW ND-3540A 1.0406020900 capabilities: removable audio cd-r cd-rw dvd dvd-r configuration: ansiversion=5 mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500 state=mounted status=ready *-medium physical id: 0 logical name: /dev/cdrom logical name: /media/Disque-5 configuration: mount.fstype=iso9660 mount.options=ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500 state=mounted *-cdrom:1 description: SCSI CD-ROM physical id: 3 bus info: scsi@1:0.1.0 logical name: /dev/cdrom1 logical name: /dev/scd1 logical name: /dev/sr1 capabilities: audio configuration: status=nodisc -- Alain Rpnpif -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Simon Wenner wrote: xorriso seems to work as expected. Your report and the one of Alain Rpnpif support the theory that your drives dislike CD write type TAO with your particular CD media or in general. I failed to force Brasero into using the other write type. (Details below.) I see in Brasero 2.30.3 source code in file ./plugins/libburnia/burn-libburn.c if (flags BRASERO_BURN_FLAG_DAO) burn_write_opts_set_write_type (opts, BURN_WRITE_SAO, BURN_BLOCK_SAO); else { burn_write_opts_set_write_type (opts, BURN_WRITE_TAO, BURN_BLOCK_MODE1); If you can modify that code, so that both become BURN_WRITE_SAO, BURN_BLOCK_SAO); then you cripple it for appendable CD and some DVD, but would force it to use SAO on blank CDs. I am willing to bet 1 eurocent on this CD being readable. George or Paul: Can you provide Simon and Alain with a patch that does this to the Debian source of Brasero in Wheezy ? Just change all calls of burn_write_opts_set_write_type() to send the same parameters as the one with BURN_WRITE_SAO. (Program will be usable just for testing with blank CD, not for production. A proposal for a better remedy would follow in case of success.) Lengthy reasoning and experiments: The version distributed by Debian is based on the same libburn and the same libisofs as Brasero. But better check this by ldd: $ ldd /usr/bin/xorriso | grep libisofs $ ldd /usr/lib/brasero-0/plugins/libbrasero-libisofs.so | grep libisofs $ ldd /usr/bin/xorriso | grep libburn $ ldd /usr/lib/brasero-0/plugins/libbrasero-libburn.so | grep libburn If those are indeed pointing to the same .so files, then your report supports the theory that your drive dislikes write type TAO with these media. (NB: TAO is the default write type of wodim and cdrecord. Option -sao enables the other CD write mode SAO.) From the unreadable medium burned by Brasero: Media current: CD-RW Media product: 97m10s00f/79m59s74f , TDK / Ritek Media status : is written , is closed Media blocks : 3822 readable , 0 writable , 359847 overall TOC layout : Idx , sbsector , Size , Volume Id Other session: 1 , 0 , 3820s , Media summary: 1 session, 3822 data blocks, 7644k data, 0 free These 2 extra sectors after the ISO image end look like CD TAO. Your xorriso run on a blank CD was with write type SAO. A TAO track ends by 2 non-data sectors. One cannot recognize them easily before one tries to read them. This can be confirmed by: $ xorriso -outdev /dev/sr0 -check_media what=disc use=outdev -- ... xorriso : UPDATE : 63632 of 64064 blocks read in 44 s , 23.6xC libburn : SORRY : SCSI error on read_10(64062,1): [5 64 00] Illegal request. Illegal mode for this track. libburn : SORRY : SCSI error on read_10(64063,1): [5 64 00] Illegal request. Illegal mode for this track. xorriso : UPDATE : 64064 of 64064 blocks read in 44 s = 19.3xC Media checks :lba , size , quality Media region : 0 , 64062 , + good Media region : 64062 , 2 , - unreadable (NB: Brasero does it wrong when it does not add padding to a TAO track. But that would not hamper mountability but rather produce I/O errors when you try to read the content of the last files in the image. Other drives report other errors with these blocks. E.g.: [3 11 05] Medium error. L-EC uncorrectable error. When Linux encounters these blocks while loading a cache tile, then it marks the whole tile (128 kB ?) as unreadable. ) I experimented with ~/.gconf/apps/brasero/drives/*/data_CD-RW/%gconf.xml by trying to carry some info from Brasero source to .gconf debian/libbrasero-media-dev/usr/include/brasero/brasero-enums.h BRASERO_BURN_FLAG_NO_TMP_FILES = 1 7, BRASERO_BURN_FLAG_DAO = 1 13, I see in .../data_CD-RW/%gconf.xml entry name=flags mtime=1341679063 type=int value=128/ and change to entry name=flags mtime=1341679063 type=int value=8320/ thus setting bit 13. (Bit 7 has an effect on the checkbox for direct writing.) Now i start Brasero and burn. Hmmm ... the finalizing lasts long. Rather a sign for TAO. SAO lasts long before progress begins. Let's see: ISO session : 1 , 0 ,241408s , Data disc (05 Jul 12) Media summary: 1 session, 241410 data blocks, 472m data, 0 free Damn. Still TAO. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Saturday 07 July 2012 19:28:53 Thomas Schmitt wrote: Hi, Simon Wenner wrote: xorriso seems to work as expected. Your report and the one of Alain Rpnpif support the theory that your drives dislike CD write type TAO with your particular CD media or in general. I failed to force Brasero into using the other write type. (Details below.) I see in Brasero 2.30.3 source code in file ./plugins/libburnia/burn-libburn.c if (flags BRASERO_BURN_FLAG_DAO) burn_write_opts_set_write_type (opts, BURN_WRITE_SAO, BURN_BLOCK_SAO); else { burn_write_opts_set_write_type (opts, BURN_WRITE_TAO, BURN_BLOCK_MODE1); If you can modify that code, so that both become BURN_WRITE_SAO, BURN_BLOCK_SAO); then you cripple it for appendable CD and some DVD, but would force it to use SAO on blank CDs. I am willing to bet 1 eurocent on this CD being readable. Let's see :) George or Paul: Can you provide Simon and Alain with a patch that does this to the Debian source of Brasero in Wheezy ? Just change all calls of burn_write_opts_set_write_type() to send the same parameters as the one with BURN_WRITE_SAO. get the source package (apt-get source) and just edit plugins/libburnia/burn-libburn.c then george@sid:/tmp/brasero-3.4.1$ dpkg-source --commit dpkg-source: info: local changes detected, the modified files are: brasero-3.4.1/plugins/libburnia/burn-libburn.c Enter the desired patch name: libburn-cd-sao dpkg-source: info: local changes have been recorded in a new patch: brasero-3.4.1/debian/patches/libburn-cd-sao The modification is already applied, thus build with: george@sid:/tmp/brasero-3.4.1$ dpkg-buildpackage (Program will be usable just for testing with blank CD, not for production. A proposal for a better remedy would follow in case of success.) Lengthy reasoning and experiments: The version distributed by Debian is based on the same libburn and the same libisofs as Brasero. But better check this by ldd: On my sid, these are as expected: $ ldd /usr/bin/xorriso | grep libisofs # ldd /usr/bin/xorriso | grep libisofs libisofs.so.6 = /usr/lib/libisofs.so.6 (0x7f913488b000) $ ldd /usr/lib/brasero-0/plugins/libbrasero-libisofs.so | grep libisofs # ldd /usr/lib/brasero3-1/plugins/libbrasero-libisofs.so | grep libisofs libisofs.so.6 = /usr/lib/libisofs.so.6 (0x7f2945053000) $ ldd /usr/bin/xorriso | grep libburn # ldd /usr/bin/xorriso | grep libburn libburn.so.4 = /usr/lib/libburn.so.4 (0x7fa403dc2000) $ ldd /usr/lib/brasero-0/plugins/libbrasero-libburn.so | grep libburn # ldd /usr/lib/brasero3-1/plugins/libbrasero-libburn.so | grep libburn libburn.so.4 = /usr/lib/libburn.so.4 (0x7fa6810c) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, get the source package (apt-get source) and just edit plugins/libburnia/burn-libburn.c Does it still have that name ? Are there other occasions of burn_write_opts_set_write_type() in 3.4 ? (Meanwhile i stirred up the system enough to get this: Message from syslogd@debian2 at Jul 7 21:32:25 ... kernel:[34537.006023] Oops: [#1] SMP Now brasero starts as dull grey window. I better reboot. Ok. It lives again. The re-start plague spreads from GUI to kernel. Owee ! ) - I try to exercise the procedure in my squeeze: $ vi ./plugins/libburnia/burn-libburn.c There are two occasions of burn_write_opts_set_write_typ() with three calls. Strangely the porcessing path with erasing of CD-RW does not obey (flags BRASERO_BURN_FLAG_DAO) but sets TAO unconditionally. $ dpkg-source --commit dpkg-source: need a command (-x, -b, --before-build, --after-build, --print-format) ... usage instructions ... $ I make a backup of the altered source file and try $ dpkg-buildpackage ... dpkg-source: info: local changes stored in brasero-2.30.3/debian/patches/debian-changes-2.30.3-2, the modified files are: brasero-2.30.3/libbrasero-burn/burn-process.c brasero-2.30.3/plugins/libburnia/burn-libburn.c dpkg-source: info: building brasero in brasero_2.30.3-2.debian.tar.gz ... It is addicted to my upstream installation in /usr/local/lib now. Refuses to link if there is no /usr/local/lib/libburn.so. # dpkg -i brasero_2.30.3-2_amd64.deb But brasero still produces TAO. Gr ... I added fprintf(stderr, Brasero libburn-plugin: Write type is SAO\n); and fprintf(stderr, Brasero libburn-plugin: Write type is TAO\n); but none of them show up in the terminal. I doubt that i really installed my change. What am i doing wrong ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, i had a look at brasero build logs and have to drop the appealing theory of sizeof(off_t) == 4. The compiler gets a sufficient macro to avoid this: -D_FILE_OFFSET_BITS=64 I now managed to build Brasero brasero-2.30.3-2 from the Debian sources. It shows no differences to the previously installed one. The installed libisofs and libburn are very old now. Is there a way to test again with the current versions in Debian sid ? -- Summary for now: I am unable to reproduce the described problems about partially or completely written CD or DVD which are unreadable afterwards. If burning starts here, then it completes up to the moment when Brasero should recognize that it successfully ejected the medium. The resulting media are mountable and bear the correct content for all files which are recorded. Missing are only files of which the name begins by a dot .. Note well: George's patch is not yet applied. -- Realtime recorded details of my brasero adventures: So i continue trying to build brasero from source on my libburnia-upstream infested system. It says libburn is installed. But brasero refuses to link to it when built by dpkg-buildpackage. So i do # rm /usr/local/lib/libburn.a # rm /usr/local/lib/libisofs.a # apt-get purge libburn4 (brasero and others get de-installed, too) # apt-get purge libisofs6 # apt-get install libburn4 # apt-get install libisofs6 # apt-get install libburn-dev # apt-get install libisofs-dev This has installed antique libburn-0.8.0 and libisofs-0.6.32. Released in spring 2009 ! Now i get warnings about the failure to sign $ dpkg-buildpackage ... dpkg-buildpackage: binary and diff upload (original source NOT included) dpkg-buildpackage: warning: Failed to sign .dsc and .changes file $ echo $? 1 I continue with George's instructions: Remove any previous brasero package you might have: # apt-get --purge remove brasero (seems to have been removed already when i removed libburn4) install yours: # ls -l brasero_2.30.3-2_amd64.deb -rw-r--r-- 1 thomas thomas 677008 Jul 6 11:49 ../brasero_2.30.3-2_amd64.deb # dpkg -i brasero_2.30.3-2_amd64.deb ... dpkg: dependency problems prevent configuration of brasero: brasero depends on libbrasero-media0 (= 2.30.3-2); however: Package libbrasero-media0 is not installed. dpkg: error processing brasero (--install): dependency problems - leaving unconfigured ... # apt-get install libbrasero-media0 ... # dpkg -i brasero_2.30.3-2_amd64.deb $ brasero It starts. It remembers my data disc project and annoys me by popping up with the usual protest about deep directories. Loaded is a DVD+RW. (This type is reported to get spoiled and then needing some kind of re-vitalization. I suspect that growisofs warns about an existing ISO-9660 superblock. This could be silenced e.g. by overwriting the first 64 kB of the medium with zeros.) Maximum speed, Burn the image directly ... ... Burn. It asks whether i want to blank the current disc. (That would probably be such an overwrite with zeros.) libisofs DEBUG messages appear ... 55 % ... 100 %. I abort the integrity check in favor of my own means. The media ejection is then as broken as was with the originally installed brasero. Let's see what we got. Today the burner is /dev/sr0 : # mount /dev/sr0 /mnt $ diff -r libburn_dir /mnt/libburn_dir yields complaints about missing .files. (Is that a bug or a feature ?) No messages about differing file content. The same positive result with $ xorriso -indev /dev/sr0 -compare_r libburn_dir /libburn_dir 21 \ | fgrep -v ' : st_' | fgrep -v 'annot find' Well. For completeness the same with a CD-RW: I get asked whether i want to blank the disc. I confirm. libisofs reports about colliding dumb-ISO names (which is normal) ... Oops ? The Burning data DVD window says Ejecting Medium while libisofs says that it is still writing parts of the directory tree: brasero (libisofs)DEBUG : Writing ISO Path tables After a timeout i get asked to eject manually. I confirm and get a window Error while burning. MEDIA: closed or not recordable,. I take the opportunity to save the log. ... BraseroLibisofs called brasero_job_get_action BraseroLibisofs Finished track successfully BraseroLibisofs stopping BraseroLibburn called brasero_job_get_action BraseroLibburn creating input ... BraseroLibburn Precheck failed MEDIA: closed or not recordable, BraseroLibisofs stopping BraseroLibburn stopping BraseroLibburn closing connection for BraseroLibburn Session error : MEDIA: closed or not recordable, (brasero_burn_record brasero-burn.c:2839) This is reproducible again on a second try. It did work yesterday. Regrettably not the problem i am hunting for. $ xorriso -outdev /dev/sr0 -blank fast ... 30 seconds of pacifier messages ... Media
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, in order to apply George's patch anyway, i have tried to disable libburn so that growisofs would be used with DVD. No success. Both, growisofs and libburn are enabled but also greyed, so that i cannot change their checkboxes. Whatever, just in case it brings any new insight: $ cd brasero-2.30.3 $ mv ~/check-child-status debian/patches/check-child-status $ echo check-child-status debian/patches/series $ dpkg-buildpackage ... time enough for a tea break ... # apt-get --purge remove brasero # apt-get install libbrasero-media0 # dpkg -i brasero_2.30.3-2_amd64.deb $ brasero Well, it still burns readable DVD. How to get a log file ? Just try burning another DVD, fail, and get offered to save a log. Life is so easy ... :)) It still uses libburn, not growisofs. But no further insight: + BRASERO_JOB_LOG (data, process exited with status %d, WEXITSTATUS (status)); + BRASERO_JOB_LOG (data, process killed by signal %d, WTERMSIG(status)); + BRASERO_JOB_LOG (data, process stopped by signal %d, WSTOPSIG(status)); The word process does not appear in the log of the failed run. It did not get that far, i assume. + printf(process exited, status=%d\n, WEXITSTATUS(status)); + printf(process killed by signal %d\n, WTERMSIG(status)); + printf(process stopped by signal %d\n, WSTOPSIG(status)); Nothing to see of those in xterm where i started brasero. Not with the successful runs either. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Paul Menzel wrote: Until then I suggest to not bother anymore with that problem. It gives libisofs a bad name. Probably the squeeze Brasero is two notches too old. This comment could explain why: https://bugzilla.gnome.org/show_bug.cgi?id=655601#c5 ... Nico Zanferrari 2012-01-16 10:15:30 UTC: ... - the bug started on Brasero version 2.32.1 and it's still ...present in 3.2.x. It was not present in version 2.32.0. ... - it happens on all hw, and all current distros ... - it happens only with on-the-fly burning, which is the ...default option by the way. Mine is 2.30.3 I need instructions how to get into this range of versions. I suggest to split up the Debian bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 could well be just a classical 100%-run-but-unreadable problem. Usually caused by bad compatibility of drive and media. The 30%-to-50%-early-burn-end problem in Launchpad is probably the one for which one needs the newer Brasero. It would thus still lurk in Debian sid, rather than in squeeze. So actually one should just deprecate to follow the Launchpad link. I apologize for having fueled that branch. But Debian will possibly get affected by its next release, anyway. https://bugzilla.gnome.org/show_bug.cgi?id=655601 https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 Be careful with believing in me too confirmations. E.g. https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/788300 is very understandable to me after two days with Brasero. Its flaws together with bad compatibility of drive and media can cause any kind of urban legends. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Friday 06 July 2012 16:43:07 Thomas Schmitt wrote: Hi, Thomas, thank you performing these tests. I think you've done enough already :) in order to apply George's patch anyway, i have tried to disable libburn so that growisofs would be used with DVD. No success. Both, growisofs and libburn are enabled but also greyed, so that i cannot change their checkboxes. Hm, did you try to mess up with gconf-editor (package of the same name)? You can start it, and search for brasero string, that is Ctrl+F... then find brasero/config/priorities and adjust the weights of growisofs and libisofs plugins, so these being higher than the rest. It is not like I'm an expert in this particlar area:P Whatever, just in case it brings any new insight: $ cd brasero-2.30.3 $ mv ~/check-child-status debian/patches/check-child-status $ echo check-child-status debian/patches/series $ dpkg-buildpackage ... time enough for a tea break ... # apt-get --purge remove brasero # apt-get install libbrasero-media0 # dpkg -i brasero_2.30.3-2_amd64.deb $ brasero Well, it still burns readable DVD. How to get a log file ? Just try burning another DVD, fail, and get offered to save a log. Hm, uses libburn and libisofs and you observed a fail? Life is so easy ... :)) It still uses libburn, not growisofs. But no further insight: + BRASERO_JOB_LOG (data, process exited with status %d, WEXITSTATUS (status)); + BRASERO_JOB_LOG (data, process killed by signal %d, WTERMSIG(status)); + BRASERO_JOB_LOG (data, process stopped by signal %d, WSTOPSIG(status)); The word process does not appear in the log of the failed run. It did not get that far, i assume. + printf(process exited, status=%d\n, WEXITSTATUS(status)); + printf(process killed by signal %d\n, WTERMSIG(status)); + printf(process stopped by signal %d\n, WSTOPSIG(status)); Nothing to see of those in xterm where i started brasero. Not with the successful runs either. As I get it from the code brasero_process_watch_child() routine, containing those prints, would only be called when external applications like growisofs are being started in the child process (there are also routines to read their stdout and stderr). Hence, there is no chance to see them in your libburn+libisofs test above. OTOH, in the log file [1] where growisofs was engaged you can see: BraseroGrowisofs process finished with status 0 which is spitted by the original routine brasero_process_watch_child() ... if (waitpid (priv-pid, status, WNOHANG) = 0) return TRUE; priv-return_status = WEXITSTATUS (status); priv-watch = 0; priv-pid = 0; BRASERO_JOB_LOG (data, process finished with status %i, WEXITSTATUS (status)); ... and where is it not actually wait()'ed properly, since the waitpid() could have returned positive value (child's pid) due to the child's change of state, e.g. child being signalled for any (obscure) reason (SIGPIPE, SIGKILL, etc), and also child's exit status is being blindly examined by flat WEXITSTATUS(status), instead of first checking WIFEXITED(status) for returning true, i.e. that the child has actually exited. Thus, the above log message of process finished with status 0 is pretty much bogus in this particular case shown in the log with the burn failure halfway around ~49-50%. (see the tail of waitpid(2) for a good example of a diligent parent waiting for their possibly naughty child) [1] https://launchpadlibrarian.net/71440716/brasero_log.txt -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Hi Sorry I'm overstrained by the Debian infrastructure. ;-) I hit all the reportbug crasher bugs too... But anyway, I updated to brasero 3.4.1 and I can still reproduce the bug. I used a CD-RW and created a data project with one folder with two files in it (about 300MB). I enabled on-the-fly burning (see screen shot). It burned, reported success and failed to eject the CD. The CD contains no valid file system and it can not be mounted. Brasero is also unable to clear the CD. I have to use K3B to format it (strange!). Notes: - Disabling the option Burn the image directly without saving to disc (see screen shot) creates a working CDs (that can be ejected automatically too). - Burning ISO images with brasero works fine. Just today I burned a Debian and an Ubuntu image without problems. - Kernel: Linux 3.2.0-2-amd64 I hope this helps. I will have a look at xorriso... the manpage looks horrible. Any specific parameters I should test? Cheers Simon simon@beutelteufel:~$ brasero brasero (libisofs)DEBUG : Creating low level ECMA-119 tree... brasero (libisofs)DEBUG : Matching hardlinks... brasero (libisofs)DEBUG : Sorting the low level tree... brasero (libisofs)DEBUG : Mangling names... brasero (libisofs)DEBUG : Creating low level Joliet tree... brasero (libisofs)DEBUG : Sorting the Joliet tree... brasero (libisofs)DEBUG : Mangling Joliet names... brasero (libisofs)DEBUG : Computing position of dir structure brasero (libisofs)DEBUG : Computing length of pathlist brasero (libisofs)DEBUG : Computing position of Joliet dir structure brasero (libisofs)DEBUG : Computing length of Joliet pathlist brasero (libisofs)DEBUG : Starting image writing... brasero (libisofs)DEBUG : Write volume descriptors brasero (libisofs)DEBUG : Write Primary Volume Descriptor brasero (libisofs)DEBUG : Write SVD for Joliet brasero (libisofs)DEBUG : Writing ISO Path tables brasero (libisofs)DEBUG : Writing Joliet Path tables brasero (libisofs)DEBUG : Writing Files... brasero (libisofs)DEBUG : Processed 5180 of 103584 KB (5 %) brasero (libisofs)DEBUG : Processed 10360 of 103584 KB (10 %) brasero (libisofs)DEBUG : Processed 15538 of 103584 KB (15 %) brasero (libisofs)DEBUG : Processed 20718 of 103584 KB (20 %) brasero (libisofs)DEBUG : Processed 25896 of 103584 KB (25 %) brasero (libisofs)DEBUG : Processed 31076 of 103584 KB (30 %) brasero (libisofs)DEBUG : Processed 36256 of 103584 KB (35 %) brasero (libisofs)DEBUG : Processed 41434 of 103584 KB (40 %) brasero (libisofs)DEBUG : Processed 46614 of 103584 KB (45 %) brasero (libisofs)DEBUG : Processed 51792 of 103584 KB (50 %) brasero (libisofs)DEBUG : Processed 56972 of 103584 KB (55 %) brasero (libisofs)DEBUG : Processed 62152 of 103584 KB (60 %) brasero (libisofs)DEBUG : Processed 67330 of 103584 KB (65 %) brasero (libisofs)DEBUG : Processed 72510 of 103584 KB (70 %) brasero (libisofs)DEBUG : Processed 77688 of 103584 KB (75 %) brasero (libisofs)DEBUG : Processed 82868 of 103584 KB (80 %) brasero (libisofs)DEBUG : Processed 88048 of 103584 KB (85 %) brasero (libisofs)DEBUG : Processed 93226 of 103584 KB (90 %) brasero (libisofs)DEBUG : Processed 98406 of 103584 KB (95 %) brasero (libisofs)DEBUG : Processed 103584 of 103584 KB (100 %) simon@beutelteufel:~$ sudo mount -t iso9660 -r /dev/cdrom /media/cdrom0 mount: wrong fs type, bad option, bad superblock on /dev/sr0, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so [22295.543931] ISO 9660 Extensions: Microsoft Joliet Level 3 [22295.597809] ISO 9660 Extensions: RRIP_1991A [22796.601042] sr 0:0:0:0: [sr0] Device not ready [22796.601048] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [22796.601054] sr 0:0:0:0: [sr0] Sense Key : Not Ready [current] [22796.601060] sr 0:0:0:0: [sr0] Add. Sense: Medium not present [22796.601067] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 02 00 00 02 00 [22796.601079] end_request: I/O error, dev sr0, sector 8 [22796.601086] Buffer I/O error on device sr0, logical block 1 [22796.605512] sr 0:0:0:0: [sr0] Device not ready [22796.605515] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [22796.605520] sr 0:0:0:0: [sr0] Sense Key : Not Ready [current] [22796.605525] sr 0:0:0:0: [sr0] Add. Sense: Medium not present [22796.605532] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 02 00 00 02 00 [22796.605544] end_request: I/O error, dev sr0, sector 8 [22796.605553] Buffer I/O error on device sr0, logical block 1 [22796.606436] sr 0:0:0:0: [sr0] Device not ready [22796.606439] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [22796.606449] sr 0:0:0:0: [sr0] Sense Key : Not Ready [current] [22796.606454] sr 0:0:0:0: [sr0] Add. Sense: Medium not present [22796.606462] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 02 00 00 02 00 [22796.606474] end_request: I/O error, dev sr0, sector 8 [22796.606482] Buffer I/O error on device sr0, logical block 1 [22796.607453] sr
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Alain Rpnpif wrote: This works fine for CR-RW only but not with CD-R (I have crashed 2 CD-R to confirm). With CD-R, some files are full of 00H. This supports the theory of poor compatibility of drive and media. Blank CD-RW and CD-R are handled identically by burn software. They make no difference to the ISO-9660 software either. xorriso works fine for me with CD-RW and CD-R. This weakens said theory. There might be a difference in CD write mode between xorriso and Brasero. SAO versus TAO. Sometimes the one still works whereas the other is already failing. What xorriso commands did you use exactly ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Hm, did you try to mess up with gconf-editor Not yet. But i try now:. I do not see an alternative to apps|brasero|config|priority|libisofs-image Well i now set apps|brasero|config|priority|growisofs-burn 1 This did not change anything. Now growisofs process to see while the DVD burn is going on. I try: apps|brasero|config|priority|libburn-burn 2 (At the second try the setting becomes persistent.) No growisofs process to spot. Sigh. apps|brasero|filter|hidden could be to blame for the missing dot-files. Yes. It is. So my results now pass diff -r without much complaints. But it is not flawless yet. An empty directory is still missing on the DVD: libburn_dir/hurd-git/gnumach/.git/refs/tags Hm, uses libburn and libisofs and you observed a fail? A failure to properly recognize the state of the loaded medium after a first run succeeded and ended in the well-known Brasero failure to eject. After this, the program is quite unusable and has to be ended. I purposely did try another burn, just to get offered the log. Regrettably i cannot provoke a log with a successful run. I roughly understand your theory about WEXITSTATUS. It would explain why Brasero stops to transfer more data. But without being able to engage growisofs, it will be hard to examine. So how do i upgrade libisofs, libburn and Brasero to sid ? How do i enable use of growisofs ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, - Disabling the option Burn the image directly without saving to disc (see screen shot) creates a working CDs (that can be ejected automatically too). I will have to try at least the eject aspect. But anyway, I updated to brasero 3.4.1 and I can still reproduce the bug. How did you do that ? My squeeze only fetches 2.30.3. brasero (libisofs)DEBUG : Processed 103584 of 103584 KB (100 %) So this is not the 50-percent-bug where growisofs is involved and where George's patch might be of help. [22796.601067] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 00 02 00 00 02 00 [22796.605520] sr 0:0:0:0: [sr0] Sense Key : Not Ready [current] [22796.605525] sr 0:0:0:0: [sr0] Add. Sense: Medium not present The medium is bad. At least after having been written. The drive does not even acknowledge its existence. What do you get from this command while the bad medium is in /dev/sr0 ? xorriso -outdev /dev/sr0 -toc Maybe it is still blank and usable. We'll see. I will have a look at xorriso... the manpage looks horrible. Yes, it has grown during the years. The commands allow to manipulate an ISO 9660 image quite thoroughly. If you are familiar with mkisofs and cdrecord, there are emulation commands. For getting started, see the examples section: http://www.gnu.org/software/xorriso/man_1_xorriso.html#EXAMPLES Any specific parameters I should test? I have to emphasize that the -things are commands like with the shell, not parameters like with programs dd, ls or gcc. The sequence of commands matters, as they have to create preconditions for the commands which come after them. Let's try to just burn one directory to CD with MD5 checksums. This here has the right size: $ du -s /usr/bin 230980 /usr/bin $ xorriso -md5 on -outdev /dev/sr0 -map /usr/bin /usr/bin This will fail if the medium is not blank. For CD-RW you may let xorriso decide whether to blank before burning. $ xorriso -md5 on -outdev /dev/sr0 \ -blank as_needed \ -map /usr/bin /usr/bin Burning happens automatically when the program is about to end. This is supposed to copy /usr/bin from disk to /usr/bin on the CD-RW. You may then checkread with the recorded MD5s $ xorriso -md5 on -indev /dev/sr0 \ -check_md5_r FATAL /usr/bin -- Or compare directly with the disk directory $ xorriso -indev /dev/sr0 \ -compare_r /usr/bin /usr/bin Before mounting the medium you should eject and manually reload. This is to let the CD-ROM driver learn about the new state of the medium. You can let xorriso burn and eject by having as its last command -commit_eject all You can combine burn, checkread and eject. Command -commit triggers an intermediate burn. There will be no final burn because there will be no image changes pending after the checkread. $ xorriso -md5 on -outdev /dev/sr0 \ -blank as_needed \ -map /usr/bin /usr/bin \ -commit \ -check_md5_r FATAL /usr/bin -- \ -md5 off \ -compare_r /usr/bin /usr/bin \ -eject all For the case of MD5 mismatch, -check_md5_r is set to throw a FATAL error and thus to abort the program run immediately. The tray will not eject in this case. The command -check_md5_r SORRY /usr/bin -- \ would not abort the program run in case of mismatch. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Friday 06 July 2012 20:09:10 Thomas Schmitt wrote: Hi, I roughly understand your theory about WEXITSTATUS. It would explain why Brasero stops to transfer more data. But without being able to engage growisofs, it will be hard to examine. Ahem, and looking at http://fy.chalmers.se/~appro/linux/DVD+RW/ I get that growisofs is not recommended for burning CD-R[W]... hence it might fail quite miserably when faced with CD-* media; it is however quite good for handling DVD+RW and DVD-RW media. A. Yes. It should be explicitly noted that growisofs is a front-end to mkisofs, i.e. invokes mkisofs to perform the actual ISO9660 file system layout. Secondly, the DVD burners available on the market can burn even CD-R[W] media and cdrecord is the tool for this job. So how do i upgrade libisofs, libburn and Brasero to sid ? Upgrading to the versrions of sid would be a different round (if you're willing to upgrade to - completely or whatever is also dragged to as dependencies from sid). I still think your squeeze version of brasero is prone to the growisofs failure others are observing. How do i enable use of growisofs ? from zless /usr/share/doc/brasero/README I can see two ways: configuration and removal. Notes on plugins for advanced users 1. configuration From the UI you can only configure (choose to use or not to use mostly) non essential plugins; that is all those that don't burn, blank, or image. If you really want to choose which of the latters you want brasero to use, one simple solution is to remove the offending plugin from brasero plugin directory (install_path/lib/brasero/plugins/) if you're sure that you won't want to use it. You can also set priorities between plugins. They all have a hardcoded priority that can be overriden through Gconf. Each plugin has a key in /apps/brasero/config/priority. If you set this key to -1 this turns off the plugin. If you set this key to 0 this leaves the internal hardcoded priority - the default that basically lets brasero decide what's best. If you set this key to more than 0 then that priority will become the one of the plugin - the higher, the more it has chance to be picked up. So set all burning plugins to -1, except growisofs, which should be set to 1 or 2 as well as libisofs one should be set to. Btw, /usr/lib/brasero3-1/plugins is where my brasero plugins are found. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, I get that growisofs is not recommended for burning CD-R[W] It flatly refuses: :-( /dev/sr0: media is not recognized as recordable DVD: A The growisofs runs were surely with DVD or BD. simple solution is to remove the offending plugin from brasero plugin directory (install_path/lib/brasero/plugins/ I will try that tomorrow. You can also set priorities between plugins. I tried. Regardless whether the priority of growisofs was a higher or a lower number, it always used libburn. If you set this key to -1 this turns off the plugin. This i did not try yet. I still think your squeeze version of brasero is prone to the growisofs failure others are observing. There is this report that the 50-percent-bug started with version 2.32.1 and was not present in 2.32.0. Looks like neat bi-section work. But the reporters of this bug ticket here quite surely suffer from a different problem. The youngest report of Alain Rpnpif looks much like works-with-wodim- but-not-with-libburn reports which finally turned out to be about CD SAO and CD TAO. Here it is works-with-libburn-but-not-with-libburn. Even more reason to suspect different burn parameters. Such effects only show up when drive and media are balancing on the edge of failure anyway. I will soon upload a GNU xorriso development snapshot which allows the user to choose between TAO and SAO. So we don't have to introduce cdrskin here. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, i am currently the developer of libburn and libisofs. https://bugzilla.gnome.org/show_bug.cgi?id=655601 I know about such problems, but i do not know how to get into a discussion with Brasero developers. My impression is that the libisofs plugin causes libisofs to end prematurely. libburn is less of a suspect here. I have seen burn logs where burning ends after about 50 % of the expected output was produced by libisofs. I.e. libisofs would want to write more, but for some reason libburn is urged to finish burning (or falsely decides that burning is done). https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 https://launchpadlibrarian.net/71440716/brasero_log.txt have: BraseroLibisofs Finished track successfully BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs ... BraseroGrowisofs stdout: 3866984448/7761410048 (49.8%) @4.0x, remaining 12:06 RBU 40.9% UBU 100.0% BraseroGrowisofs called brasero_job_get_action BraseroGrowisofs called brasero_job_set_current_action BraseroGrowisofs stderr: /dev/sr0: flushing cache ... BraseroGrowisofs stderr: HUP Note that libburn is not involved here. Only libisofs. Burning is done via growisofs. Further it seems that BraseroLibisofs is the one which decides when the connection between both shall end. But in http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344 the work of libisofs seems to get completed. brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %) So this might be two different problems. (In this run, libburn was indeed in charge of writing to media.) - I am not aware of any changes in libisofs or libburn which about a year ago could have introduced such problems. The combination of libisofs and libburn works fine in xorriso. xorriso does several backups per day for me, which then get thoroughly checked for readability and correct content. If somebody shows up who understands the code of the libisofs plugin and could make experiments, then i would be glad to help with finding the cause of the problem. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Le jeudi 05 juillet 2012 à 08:47 +0200, Thomas Schmitt a écrit : Hi, i am currently the developer of libburn and libisofs. https://bugzilla.gnome.org/show_bug.cgi?id=655601 I know about such problems, but i do not know how to get into a discussion with Brasero developers. That would be brasero-list: https://mail.gnome.org/mailman/listinfo/brasero-list Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
On Thursday 05 July 2012 08:47:15 Thomas Schmitt wrote: Hi, Hi All, i am currently the developer of libburn and libisofs. https://bugzilla.gnome.org/show_bug.cgi?id=655601 I know about such problems, but i do not know how to get into a discussion with Brasero developers. My impression is that the libisofs plugin causes libisofs to end prematurely. libburn is less of a suspect here. I have seen burn logs where burning ends after about 50 % of the expected output was produced by libisofs. I.e. libisofs would want to write more, but for some reason libburn is urged to finish burning (or falsely decides that burning is done). https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 https://launchpadlibrarian.net/71440716/brasero_log.txt have: BraseroLibisofs Finished track successfully BraseroLibisofs disconnecting BraseroLibisofs from BraseroGrowisofs ... BraseroGrowisofs stdout: 3866984448/7761410048 (49.8%) @4.0x, remaining 12:06 RBU 40.9% UBU 100.0% BraseroGrowisofs called brasero_job_get_action BraseroGrowisofs called brasero_job_set_current_action BraseroGrowisofs stderr: /dev/sr0: flushing cache ... BraseroGrowisofs stderr: HUP Note that libburn is not involved here. Only libisofs. Burning is done via growisofs. Further it seems that BraseroLibisofs is the one which decides when the connection between both shall end. But in http://bugzilla-attachments.gnome.org/attachment.cgi?id=205344 the work of libisofs seems to get completed. brasero (libisofs)DEBUG : Processed 138390 of 138390 KB (100 %) So this might be two different problems. (In this run, libburn was indeed in charge of writing to media.) - I am not aware of any changes in libisofs or libburn which about a year ago could have introduced such problems. The combination of libisofs and libburn works fine in xorriso. xorriso does several backups per day for me, which then get thoroughly checked for readability and correct content. If somebody shows up who understands the code of the libisofs plugin and could make experiments, then i would be glad to help with finding the cause of the problem. Same issue already reported long ago at: https://mail.gnome.org/archives/brasero-list/2011-July/msg4.html actors: libisofs and growisofs brasero plugins symptoms: 50% finished at ~49% Looking at the logs and the brasero plugins code, the main suspect most likely hidden at: 1) erroneous read of growisofs std out, wrt written data, and buffer filling, hence a premature leave might occur: plugins/growisofs/burn-growisofs.c static BraseroBurnResult brasero_growisofs_read_stdout (BraseroProcess *process, const gchar *line) { int perc_1, perc_2; int speed_1, speed_2; long long b_written, b_total; /* Newer growisofs version have a different line pattern that shows * drive buffer filling. */ if (sscanf (line, %10lld/%lld (%4d.%1d%%) @%2d.%1dx, remaining %*d: %*d, b_written, b_total, perc_1, perc_2, speed_1, speed_2) == 6) { BraseroJobAction action; brasero_job_get_action (BRASERO_JOB (process), action); if (action == BRASERO_JOB_ACTION_ERASE b_written = 65536) { /* we nullified 65536 that's enough. A signal SIGTERM * will be sent in process.c. That's not the best way * to do it but it works. */ brasero_job_finished_session (BRASERO_JOB (process)); return BRASERO_BURN_OK; } 2) premature ending of the libisofs thread: static gpointer brasero_libisofs_thread_started (gpointer data) { ... if (brasero_job_get_fd_out (BRASERO_JOB (self), NULL) == BRASERO_BURN_OK) brasero_libisofs_write_image_to_fd_thread (self); ... Nothing more concrete norrowed down yet -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: [Pkg-libburnia-devel] Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, I'd suggest the attached patch to be applied, so we can better see what happens to the growisofs child process. The code unconditinally calls WEXITSTATUS (status) without making sure that WIFEXITED has returned true. This is undefined... but whatever - a separate issue. (also I don't actually like brasero_process_watch_child() to be utilized like that: g_timeout_add (500, brasero_process_watch_child, process); but this could be tweaked later) Reporters, could you please do the following: apt-get source brasero apt-get build-dep brasero put the attached patch in debian/patches/ echo check-child-status debian/patches/series dpkg-buildpackage and install this one... then try to reproduce the promlem, and get us the logs so we can better see what is going on with our beloved growisofs process. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu --- brasero-3.4.1.orig/libbrasero-burn/burn-process.c +++ brasero-3.4.1/libbrasero-burn/burn-process.c @@ -294,12 +294,27 @@ brasero_process_watch_child (gpointer da * brasero_job_finished/_error is called before the pipes are closed so * as to let plugins read stderr / stdout till the end and set a better * error message or simply decide all went well, in one word override */ - priv-return_status = WEXITSTATUS (status); +/* + priv-return_status = WEXITSTATUS (status); +*/ priv-watch = 0; priv-pid = 0; - + if (WIFEXITED(status)) { /* WEXITSTATUS macro should only be used if WIFEXITED returned true */ + printf(process exited, status=%d\n, WEXITSTATUS(status)); + priv-return_status = WEXITSTATUS (status); + BRASERO_JOB_LOG (data, process exited with status %d, WEXITSTATUS (status)); + } + else if (WIFSIGNALED(status)) { + printf(process killed by signal %d\n, WTERMSIG(status)); + BRASERO_JOB_LOG (data, process killed by signal %d, WTERMSIG(status)); + } + else if (WIFSTOPPED(status)) { + printf(process stopped by signal %d\n, WSTOPSIG(status)); + BRASERO_JOB_LOG (data, process stopped by signal %d, WSTOPSIG(status)); + } +/* BRASERO_JOB_LOG (data, process finished with status %i, WEXITSTATUS (status)); - +*/ result = brasero_process_finished (data); if (result == BRASERO_BURN_RETRY) { GError *error = NULL;
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Paul Menzel wrote: So unfortunately it looks like there is no list for Brasero and you need to use the GNOME Bugzilla bug tracker. Well, there is a list, the last entry is of january 2012, and it complains about the burn errors which seem to have emerged in spring 2011. https://mail.gnome.org/archives/brasero-list/2012-January/thread.html I tried to contact Brasero developers in december 2011 when i finally had implemented CD-TEXT, a feature which they missed in libburn when they adopted it. No reaction. We'd need somebody who wants to maintain at least the plugins for libisofs and libburn. I myself am a command-line guy and thus heavily unsuitable for that job. rpnpif hinted in his original message, that the media was corrupted because the wrong write speed was used. I doubt, but cannot completely outrule this for the runs which report libisofs progress up to 100 %. The drives take the speed instructions only as a hint. Then they decide what speed to use. Of course, the drive can still do it wrong, when it gets the speed request. But that would be an individual firmware flaw. Those are often related to particular types of media (brands, manufacturers). One can find out the media producer by xorriso -outdev /dev/sr0 -toc | grep 'Media product' which will tell something like CD: Media product: 97m15s35f/79m59s74f , Nan-Ya Plastics Corporation DVD: Media product: RITEK/004/48 , Ritek Corp BD: Media product: VERBATIM/IM0/0 , Mitsubishi Kagaku Media Co. If there is suspicion, that the drive does not like the media brand, then try to get some which shows a different Media product:. This might be not easy because most brands sell media from varying manufacturers. (Hint: Verbatim only sells Mitsubishi media. So if the current media are not Verbatim or Mitsubishi Kagaku then Verbatim media will surely be different from those ones. The same is mostly true vice versa.) Surely speed or media incompatibility is not the reason for those runs where libisofs progress reached only about 50 %. libisofs and libburn were not free of bugs during the last year. But none of the resolved ones would explain what Brasero users report. Thanks for that offer. Hopefully, rpnpif and Simon can chime in so that this release critical bug can be resolved. I hate to say it, but it seems to be easiest to just disable the libisofs plugin. I understand that Ubuntu already moves into that direction. xorriso could step in by its emulation of mkisofs and cdrecord (single data track only). cdrskin could step in as a more versatile emulation of cdrecord (audio, multiple tracks in one session). This would of course not have the advantages of using the two libraries with their message queues and well definded APIs. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, Josselin Mouette wrote: That would be brasero-list: https://mail.gnome.org/mailman/listinfo/brasero-list Is there a chance that we could work together to find out what's wrong ? If not George Danchev's patch already brings insight, that is. Released libisofs-1.2.2 would be a good test bed. Of course we could also use libisofs SVN which currently is moving towards the next release 1.2.4 and already got some testing. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, George Danchev wrote: Thomas (or anyone else), could you please try brasero on your squeeze box (I currently don't have any burners at reach), Ok, for once ... :)) I will cry on your shoulder if it freezes my good old fvwm display. Actually i avoided trying myself because i do not want to become the maintainer of Brasero. If it is really orphaned, then so be it. -- Ok. First what i can do by comfortable harmless ssh: $ su # apt-get source brasero (warns keyblock resource `/root/.gnupg/trustedkeys.gpg': file open error) # apt-get build-dep brasero (Lots of activities) # mv check-child-status debian/patches/ mv: cannot move `check-child-status' to `debian/patches/': No such file or directory # mv check-child-status /debian/patches/ mv: cannot move `check-child-status' to `/debian/patches/': No such file or directory # ls check-child-status check-child-status Well, i need advise for the patching. Unchanged Brasero as installed after above activities: $ export DISPLAY=...my.machine...:0.0 $ brasero At least the screen does not burn down ... Brasero 2.30.3 Urm. That is not 2.30.3-2. The binary is of November 2010. I really could need some help with Debian specifics here. But as we are already at it: ... clicki-di-clonk ... ... scratching head ... if i use the shell to learn about the existing files then i can operate the file browser ... I choose burn, windows vanish, i see messages from libisofs: ... brasero (libisofs)DEBUG : Processed 366022 of 366022 KB (100 %) ** (brasero:7846): WARNING **: Failed to restore the system power manager: The name org.gnome.SessionManager was not provided by any .service files The big window appears again. In the directory where i started Brasero is as file -rw-r--r-- 1 thomas thomas 374806528 Jul 5 18:57 brasero.iso # mount -o loop brasero.iso /mnt Comparing with the original tree $ diff -r /mnt/libburn_dir libburn_dir | less shows that 322 files are missing of which the names begin by '.'. This must be due to the way how Brasero traverses the input tree. My xorriso backups contain every file with all their attributes. Well, elsewise the image seems ok. So how do i choose a burner ? The system is a bit sparsely equipped: 0 -dev '/dev/sr0' rwrw-- : 'TSSTcorp' 'DVD-ROM SH-D162C' 1 -dev '/dev/sr1' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' The help text promises 7. The Disc burning setup dialog will be shown I get a vanished main window (one could believe it crashed) and a tiny dialog which offers me to edit Name: brasero-0.iso, to browse by Save in folder:, a Cancel button and a Create Image button. Shutting down Brasero, chmod a+rw /dev/sr1, re-starting Brasero. Now i get a different dialog. (The device is group cdrom to which the user belongs who runs Brasero. It is heavily unplausible that Brasero need o+rw.) I choose: maximum speed, Burn the image directly, but not Leave the disc open. Inserted is a DVD+RW. I see libisofs DEBUG messages ... 70 % ... 100 % Now it is checking file integrity. Let me wander to the room with the machine ... the poor drive is blinking and clonking. Random access pattern. i'd say. (libisofs can tell file addresses and one could sort the files by that address to get a smooth sequential read pattern.) I stop the checkread. Will let xorriso do xorriso -indev /dev/sr1 -compare_r libburn_dir /libburn_dir Grrr ... all ownership and permissions differ. Filtering away those messages 21 | fgrep -v ' : st_' | fgrep -v 'annot find' i get no other differences. Another try with CD-RW: I click Burn, it asks whether i really want to blank the disc. Well, i know what is meant. But wouldn't that confuse novice users ? It burns ... (i do not know whether libburn is active, but ps shows no wodim or cdrecord) ... 100 % ... Finalizing ... Success ... i abort checkreading, the drive ejects and Brasero is stuck in Ejecting medium. I put it back in. A window pops up and asks me to remove it manually. I kill Brasero. Enough for today. Checkreading by xorriso shows only the differences which seem unavoidable with Brasero. George: Your shoulder will stay dry. My display survived. All: Is my Brasero 2.30.3 2005-2010 too old for being buggy ? If so, could one revert the changes of 2.30.3-2 to see whether it helps ? In general: How to get the new buggy Brasero ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, PS: Somehow the Debian bug report address was not in CC but it was archived [1] anyway. Did you put it in BCC? Anyway, I added it back to the CC list. I thought i addressed my mails To: 617...@bugs.debian.org Cc: all others. but To: shows up with rpn...@free.fr. I am using a halfways self-written mail client which makes it easy to shoot my foot. SMTP-wise the bug report was on the list of recipients: 250 mail.gmx.net GMX Mailservices {mp028} ... RCPT TO:617...@bugs.debian.org 250 2.1.5 ok {mp028} ... 617...@bugs.debian.org is added to Cc: now. No need to be root. Only when you install it with `dpkg -i ../*brasero*deb`(?). I should remember. I use that Debian installation mainly for daring experiments. I guess you are missing `cd brasero...` you download with the first command. # find . -name patches ./brasero-2.30.3/debian/patches # cd brasero-2.30.3 # chmod -R ... ; chgrp -R ... # exit $ cd brasero-2.30.3 Well, that's not brasero-2.30.3-2 either. $ ls -lt * */* */*/* */*/*/* */*/*/*/* ... -rw-r--r-- 1 thomas thomas 33109 Jul 5 18:39 src/Makefile.in -rw-r--r-- 1 thomas thomas4942 Nov 6 2010 debian/control -rw-r--r-- 1 thomas thomas 17375 Nov 6 2010 debian/changelog -rw-r--r-- 1 thomas thomas 894 Oct 2 2010 debian/patches/50_checksum.patch -rw-r--r-- 1 thomas thomas 114 Oct 2 2010 debian/patches/series -rw-r--r-- 1 thomas thomas 82332 Sep 5 2010 debian/patches/90_relibtoolize.patch -rw-r--r-- 1 thomas thomas 2343865 Aug 30 2010 ChangeLog ... Looks quite like the one that is installed $ ls -l /usr/bin/brasero -rwxr-xr-x 1 root root 470776 Nov 6 2010 /usr/bin/brasero But ./brasero-2.30.3 seems not built yet. What command next (before patching) ? There is not much use in diagnostic messages before we can reproduce the problem. I am about the contrary of a typical Brasero user. So maybe i just lack of the bad luck which comes with frequent use of clickicolorful GUIs ? :)) Pun aside. There are too many problem reports with Debian and Ubuntu, for just a few users being out of luck. Even if we subtract 50 percent for people whose burners mishandle the media. So there must be a way to get a bad Brasero by means of Debian and/or Ubuntu. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
Hi, George Danchev wrote: $ dpkg-checkbuilddeps # to check you have all build-dependencies installed $ dpkg-buildpackage Ok. The messages from remnant root-owned result files tell me that this is indeed 2.30.3-2. dpkg-source: error: cannot write brasero_2.30.3-2.dsc: Permission denied After a long build process i run into a problem with the local installation of libburn: libtool: relink: gcc -shared .libs/burn-libburn.o .libs/burn-libburn-common.o -L/home/thomas/brasero-2.30.3/debian/tmp//usr/lib -L/usr/lib -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -L/usr/local/lib -L/home/thomas/brasero-2.30.3/debian/tmp//usr/local/lib -lburn -lisofs -lbrasero-burn -pthread -pthread -Wl,-soname -Wl,libbrasero-libburn.so -o .libs/libbrasero-libburn.so /usr/bin/ld: /usr/lib/libburn.a(async.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /usr/lib/libburn.a: could not read symbols: Bad value collect2: ld returned 1 exit status libtool: install: error: relink `libbrasero-libburn.la' with the above command before installing it It is compiled and installed from my upstream release source. It works fine with the upstream release of libisoburn and xorriso. libburn.so.4 = /usr/local/lib/libburn.so.4 (0x7f55f4768000) Why does Brasero want libburn.a ? Aren't static libs out of fashion ? Shall i try something like apt-get install libburn ? Do i have to clean up beforehand ? How ? I will try further tomorrow. Yeah, someone uses a naughty mailer :) Ja, ja. Just make fun of old people and their IT equipment ... Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning (was: additional info)
forwarded 617409 https://bugzilla.gnome.org/show_bug.cgi?id=655601 tags upstream moreinfo quit Dear rpnpif, dear Simon, Am Mittwoch, den 15.02.2012, 00:21 +0100 schrieb Simon Wenner: Here are very similar bug reports in other BTs. Many people are affected: https://bugzilla.gnome.org/show_bug.cgi?id=655601 https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117 Simon, thanks for finding these upstream entries. I set the BTS tags accordingly. rpnpif, can you confirm that this is the issue you are seeing? ... and K3B works without any issues. My drive is not broken. Reading the listed reports, it looks like this is an error with the usage of or an error in libburn4 or libisofs6. I am therefore putting the libburnia folks into CC. Maybe they have an idea. rpnpif, Simon, could you try using `xorriso` [1], which also utilizes `libburn4`, to find out if that is a problem with `libburn4`. If it is, the bug needs to be reassigned and marked as affecting `brasero` or `libbrasero-media3-1`. Thanks, Paul PS: Simon, in the future could you please CC people from the bug report since I guess rpnpif after reporting that bug almost a year before your reply does not even know, that you replied. (Of course that could be wrong.) In my opinion the best practice is to do the following. Since you use a MUA/mail program that should work for you easily. Use $ bts show --mbox 617409 from the package `devscripts` to get all the messages in mbox format. Then import this mbox file from ~/.devscripts_cache/bts/ into your mail program from and reply to the appropriate message (reply to all). This keeps threading, saves time and you can quote. To answer to messages you sent, go to your Sent folder and use »Reply to all« on that message. [1] http://packages.debian.org/sid/xorriso signature.asc Description: This is a digitally signed message part
Bug#617409: brasero: Brasero corrupts all blank CD-R when burning
Package: brasero Version: 2.30.3-2 Severity: grave Justification: causes non-serious data loss Brasero does not take account of the options such max speed and simulating request. Simulation seems to be too short in time. Speed is set to the maximum for the hardware but not conformed to my request. None CD-R are usable after burning. The directory filenames are writed in the media but file contents are not readable (corrupted with all to 00). K3B works fine. -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages brasero depends on: ii brasero-common 2.30.3-2 Common files for the Brasero CD bu ii gnome-icon-theme 2.30.3-2 GNOME Desktop icon theme ii gstreamer0.10-plugins- 0.10.30-1 GStreamer plugins from the base ii gvfs 1.6.4-3 userspace virtual filesystem - ser ii libatk1.0-01.30.0-1 The ATK accessibility toolkit ii libbrasero-media0 2.30.3-2 CD/DVD burning library for GNOME - ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra ii libdbus-1-31.2.24-4 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libfontconfig1 2.8.0-2.1 generic font configuration library ii libfreetype6 2.4.2-2.1 FreeType 2 font engine, shared lib ii libgconf2-42.28.1-6 GNOME configuration database syste ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgstreamer-plugins-b 0.10.30-1 GStreamer libraries from the base ii libgstreamer0.10-0 0.10.30-1 Core GStreamer libraries and eleme ii libgtk2.0-02.20.1-2 The GTK+ graphical user interface ii libice62:1.0.6-2 X11 Inter-Client Exchange library ii libnautilus-extension1 2.30.1-2 libraries for nautilus components ii libpango1.0-0 1.28.3-1+squeeze1 Layout and rendering of internatio ii libsm6 2:1.1.1-1 X11 Session Management library ii libtotem-plparser172.30.3-1 Totem Playlist Parser library - ru ii libtracker-client-0.8- 0.8.17-1 metadata database, indexer and sea ii libunique-1.0-01.1.6-1.1 Library for writing single instanc ii libxml22.7.8.dfsg-2 GNOME XML library brasero recommends no packages. Versions of packages brasero suggests: ii libdvdcss2 1.2.10-0.3 Simple foundation for reading DVDs ii vcdimager0.7.23-4+b2 A VideoCD (VCD) image mastering an -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org