Bug#1067103: libisoburn1t64: should not depend on libburn4 nor libisofs6 after time_t transition
Hi, being the one who usually prepares the releases, i am currently standing in hands-off position until the time_t change is completed. The package tracker is still complaining bitterly about the current intermediate state. Consider to re-open https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062380 "libisoburn: NMU diff for 64-bit time_t transition" and/or to contact its submitter. Have a nice day :) Thomas
Bug#1062380: libisoburn: NMU diff for 64-bit time_t transition
Hi, i'm the upstream and help with preparing the Debian packages. So i assume that any needed action in this case is up to my sponsor Dominique Dumont (Cc'd). But: Are you aware that the effort to switch to 64 bit time_t is not worth much in a ISO 9660 producing software, even on amd64, as long as https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h has int as return type of the ISO-9660-to-Unix-time function extern int iso_date(u8 *, int); (implemented in fs/isofs/util.c) ? I once made a successful attempt to get the attention of parts of the kernel community: https://lore.kernel.org/all/20221024135517.7d40b96a206020eca03e3...@linux-foundation.org/t/ But as it looks, it never made it into the torvalds repo. Have a nice day :) Thomas
Bug#1062381: libisofs: NMU diff for 64-bit time_t transition
Hi, i'm the upstream and help with preparing the Debian packages. So i assume that any needed action in this case is up to my sponsor Dominique Dumont (Cc'd). But: Are you aware that the effort to switch to 64 bit time_t is not worth much in a ISO 9660 producing software, even on amd64, as long as https://github.com/torvalds/linux/blob/master/fs/isofs/isofs.h has int as return type of the ISO-9660-to-Unix-time function extern int iso_date(u8 *, int); (implemented in fs/isofs/util.c) ? I once made a successful attempt to get the attention of parts of the kernel community: https://lore.kernel.org/all/20221024135517.7d40b96a206020eca03e3...@linux-foundation.org/t/ But as it looks, it never made it into the torvalds repo. Have a nice day :) Thomas
Bug#982746: live-build: autopkgtest failure on arm64, armhf and ppc64el: Failed to prepare session write run
Hi, this could be a bug in live-build. It seems to use "xorriso -as mkisofs" option -isohybrid-mbr on systems which have no PC-BIOS firmware and thus get no ISOLINUX BIOS bot equipment in the ISO. Line 69 in https://sources.debian.org/src/live-build/1:20210122/scripts/build/binary_iso/ adds -isohybrid-mbr to the options without checking that LB_BOOTLOADER_BIOS is set to "syslinux". But only with this setting, the option -b isolinux/isolinux.bin is used, which is a precondition for using -isohybrid-mbr. (Option -partition_offset 16 would be ok without "syslinux".) Long story: I am the developer of libisofs. The error message is sparse, i have to confess. Code study shows three occasions where libisofs: MISHAP : Cannot patch isolinux boot image can be emitted without more explanation. 1: The size of the El Torito boot image file isolinux.bin is less than 64 bytes. So it cannot take a Boot Info Table. 2: There was no isolinux.bin submitted at all. (option -b in mkisofs emulation, or command -boot_image isolinux dir=/isolinux in native command mode.) 3: is like 2 in a different code path. I can provoke the sparse message by omitting -b and its subordinates: xorriso -as mkisofs -o /dev/null -isohybrid-mbr "$HOME"/x "$HOME"/xx with "$HOME"/x and "$HOME"/xx being some small dummy files: ... xorriso : NOTE : Copying to System Area: 36 bytes from file '[...]/x' libisofs: MISHAP : Cannot patch isolinux boot image xorriso : FAILURE : Failed to prepare session write run ... That would be occasion 3. Now why should there be no -b isolinux/isolinux.bin ? Do i get it right, that the xorriso run is started by https://sources.debian.org/src/live-build/1:20210122/scripts/build/binary_iso/ ? (Would it be possible to let the script report the actual xorriso arguments ?) My best guess is that variable LB_BOOTLOADER_BIOS is not set to "syslinux". It controls in line 110 ff. which BIOS boot equipment is to be submitted by option -b. The option -isohybrid-mbr is used if LB_IMAGE_TYPE is "iso-hybrid" (line 66 ff.). This seems wrong, because it is used even if no ISOLINUX is selected by LB_BOOTLOADER_BIOS. So if amd64 and i386 succeed, it is most probably the inappropriate option -isohybrid-mbr which spoils the runs for the others. Have a nice day :) Thomas
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Hi, Antoine Beaupré wrote: > Severity set to 'grave' from 'normal' This is really overdone. See jigdo as a peculiar way of downloading the ISO with a MD5 check where e.g. wget has none at all. And as said, for now jigdo seems indispensible for the fat ISO sets. > If the ISO image generation is broken, it should be fixed. My bug report does not say that ISO production is broken or that jigdo is the reason for any of the checksums in the package management. I doubt both theories. > In the meantime, I think it's perfectly acceptable to remove MD5sums > from the archive, at the cost of breaking jigdo. I agree to this plan, if you afterwards verify that debian-cd still can produce a pair of .jigdo and .template which jigdo-lite then can use to create the identical ISO by help of a package mirror. I place my bet on no problems, but i may be wrong. > Or, to put it another way, it's completely unacceptable that jigdo uses > MD5 to authenticate checksums, It does so for cross-table key matching, where MD5 suffices by all means of hash table theory. It does so for verifying internally what can be verified externally by the best means which Debian offers for its ISOs. I advise to do the external check of .jigdo and .template before the run of jigdo-lite and the external check of .iso afterwards. There is bug #887837 where i propose to add a reminder message at the end of the jigdo-lite run. Debian could really need a end-user comprehensable description of the credible verification from GPG to SHA512 to ISO. This is completely independent of jigdo and applies to all download methods for ISOs. Have a nice day :) Thomas
Bug#887831: jigdo-file: Jigdo .template file and resulting ISO are only verified by MD5
Hi, Daniel Kahn Gillmor wrote: > If jigdo would use the SHA256sum entries instead of the MD5 entries when > it is doing ISO assembly, then everyone could still fetch full DVD sets > or BD sized installation ISOs I am kindof the second-last jigdo export, but not at all with .deb entrails. Are you sure that Debian package management is involved other than maybe with generating the input file for xorrisofs option -md5-list ? In the .jigdo file, which controls the package download operations of jigdo-lite, the MD5 is a key which connects the package file path with a matchable descriptor entry in the .template file bearing the same MD5. A gunzipped .jigdo file bears for example FexKzYyIVG2rRb1UjUKj8Q=Debian:pool/contrib/b/biomaj-watcher/biomaj-watcher_1.2.2-4_all.deb which is the MD5 as base64, "=Debian:" representing the individual part of the mirror URL chosen at download time, and "pool/.../...deb" to depict the invariant package path part on the mirror server. The matching descriptor entry in .template bears the same MD5 and by its position marks the place where to patch the .deb file into the .iso. Maybe Steve McIntyre can say more about how the -md5-list file gets created before xorrisofs is run. > AFAICT, jigdo's last maintenance release (debian version) was nearly two > years ago. Steve seems busy with other stuff. > The last upsteam release (0.7.3) was produced in 2006. This one is dead. At that time, the .jigdo and .template files were generated from existing .iso images by matching the submitted MD5 list against block sequences in the ISO. Steve then taught genisoimage how to produce .jigdo and .template on the fly while producing the .iso image. Before xorriso could take over the job, George Danchev and i extracted Steve's jigdo code into a library named libjte which is then used by xorriso to produce the desired companion files of the .iso. For restoring .iso from jigdo, only jigdo-lite from package jigdo-file is left. Because there is no supported tool for Mac or MS-Windows, i began to describe a jigdo download procedure via a Debian Live ISO: https://wiki.debian.org/JigdoOnLive Main open questions are about how to get a Debian Live connected to the internet if there is non-free firmware needed, and how to access the foreign OS'es filesystems for writing the .jigdo, .template, and .iso files. (I am neither sysadmin nor MS/Mac user.) > Do you have any suggestions to offer to make jigdo work using a modern > cryptographic digest? We would have to team up with Steve to fix the remaining moderate security concerns about the jigdo download process. There are no security concerns about the matching of .template block ranges with package paths, because no man-in-the-middle can alter this mapping, once .jigdo and .template files are verified. MD5 with its 128 bits should be very safe against false identifications if the file count in a .jigdo file stays well below 2 exp 30. The resolution of bug #887830 fixed the most dangerous security gap of using a totally untrusted .jigdo file and a then only MD5-checked .template file. A cautious user can now verify both files before running jigdo-lite. (jigdo-lite will not download again if it finds the files already in the current work directory.) This bug here, #887831, only tries to bring the internal checks of jigdo-lite on the downloaded .template and resulting .iso to the security standard which is recommended but not enforced for download of .jigdo or direct download of .iso. Steve once announced to publish a straightforward instruction of the verification steps from SHA512SUMS.sign, to SHA512SUMS and then to possibly .jigdo and always .iso. I hope he still knows where the draft for this is ... :)) Have a nice day :) Thomas
Bug#929381: needs cdrecord binary which isn't in Debian
Hi, Debian's simpleburn depends among others on cdrskin. If it asks for cdrecord, then it has not been properly adapted to this dependency. A simple workaround would be to create a symbolic link sudo ln -s /usr/bin/cdrskin /usr/bin/cdrecord cdrskin understands many cdrecord options as of year 2006. It has capabilities and options added for DVD and BD. If you need all CD burning features of cdrecord (at the expense of DVD and BD burning), then install wodim and use it as cdrecord: sudo ln -s /usr/bin/wodim /usr/bin/cdrecord wodim understands all cdrecord options as of year 2006. The only occasion in https://sources.debian.org/src/simpleburn/1.8.0-1/src/simpleburn.sh/ where this might be neccessary is in line 204: cdrecord -v -eject speed=$WRITESPEED gracetime=3 dev=$device -audio -pad -useinfo -text *.wav This expects for any X.wav file a file X.inf with CD-TEXT info. cdrskin will ignore this option. wodim will try to obey. The .inf files are probably created by runs of cdda2wav in simpleburn.sh. For them you need wodim's companion icedax and create a link sudo ln -s /usr/bin/icedax /usr/bin/cdda2wav -- The simpleburn package urgently needs a patch to adapt to cdrskin or wodim instead of cdrecord and to icedax instead of cdda2wav. It should also be checked whether other cdrtools programs need to be replaced by cdrkit programs. It should be quite easy for an end user to adapt simpleburn.sh to the programs of cdrkit (wodim, icedax, ...). cdrskin would be of interest only if you plan to burn DVD or BD media and if simpleburn is prepared to handle these media types at all. The difference between adapted and not adapted script would constitute a patch that should be added to the packages debian/patches directory. https://sources.debian.org/src/simpleburn/1.8.0-1/debian/patches/ Have a nice day :) Thomas
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, I'm not sure we want to continuously give it back until it builds (which it might on schroeder, since it didn't fail there yet)... I would assume the problem is deterministic and depends on the exact tree of file names which is given to genisoimage as input. So adding a few names of empty files here and there might help. But why is that mini.iso produced by genisoimage at all ? debian-7.2.0-sparc-netinst.iso was produced by xorriso. @Thomas: Probably due to historical reasons. Not sure I want to be touching that since I know nothing about architecture/image-specific settings. :/ Debian-cd uses xorriso's compatibility command -as mkisofs. If you have the opportunity to just exchange every occurence of genisoimage by xorriso -as mkisofs or, if a single word is needed, by its symbolic link alias xorrisofs then this might well be worth a try. It should work with xorriso-1.3.2 from sid, and most probably also with 1.2.2 from stable. debian-7.4.0-sparc-netinst.iso was built by xorriso-1.2.6, probably from http://www.gnu.org/software/xorriso/xorriso-1.2.6.tar.gz If you can point me to the code which controls the genisoimage run, then i will inspect it for problematic options. 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
Bug#732717: growisofs - TRACKING SERVO FAILURE - Input/output error
Hi, (For some reason my subscription to this bug does not work. Better Cc: me.) I guess this backup tool creates iso's witch are not compattible with DVD file system. (Universal Disk Format (UDF), ISO/IEC 13346 and/or ECMA The error message originally stems from the drive's firmware. It is specified in SCSI part MMC as key 4, asc 0x09, ascq 0x01, but regrettably not much background info is given. The error name suggests that the laser beam lost its way while writing its spiral track. This should not be related to the data content of the blocks written. Regardless whether ISO 9660, UDF, ext3, tar or whatever format is represented in those blocks. UDF is prescribed only for Video DVD and Video Blu-ray, so that the player devices know where to find the movies. But it is perfectly ok to write ISO 9660 to DVD or Blu-ray. I do this every day by my own program xorriso. And after all, the name growisofs stems from a close affinity of dvd+rw-tools to ISO 9660 resp. program mkisofs. That said, if you really can reproduce that only this one filesystem image fails, and that this happens with any DVD you try, then your drive's firmware has a flaw. I could not find out what filesystem format is written by mondorescue. Well, if it has the suffix .iso ... What do shell commands file and isoinfo tell about it ? file /media/DEBIAN-BACKUP-2/Mondo-ISO/mondorescue-1.iso isoinfo -d -i /media/DEBIAN-BACKUP-2/Mondo-ISO/mondorescue-1.iso (Universal Disk Format (UDF) [...] ECMA-167 Additionally to ECMA-167 one needs UDF-2.60 specs. Both are available for free. For DVD-RW: ISO 9660 ISO 9660 specs are available for free as ECMA-119. 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
Bug#732717: growisofs - TRACKING SERVO FAILURE - Input/output error
Hi, isoinfo gave me this.. Looks like quite a normal bootable ISO 9660 filesystem image. Much like the Debian and Ubuntu ISOs which get burned to DVD all over the world. Still hard to believe that the problem should sit in this image and not in burner drive and medium. How much evidence do you have for your theory ? (How often did it not work with that image, how often did it work with others ? How many media did you try ?) 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
Bug#732717: growisofs - TRACKING SERVO FAILURE - Input/output error
Hi, :-[ WRITE@LBA=538f0h failed with SK=4h/TRACKING SERVO FAILURE]: This is a problem between drive and medium. It does not necessary mean that either of them is bad. But at least the combination does not work properly. Try other media. If the problem persists, get another drive. 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
Bug#731806: debian-installer: FTBFS on sparc: genisoimage errors
Hi, Cyril Brulebois wrote: genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and './tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''. [...] Probably some FS-dependent fun? Anyone would have a clue about it? Looks like an internal error of genisoimage. '.' should be mapped to a 0x00-byte in ECMA-119, '..' to 0x01. See ECMA-119, 6.8.2.2 Identification of directories. These names are reserved for that purpose. Any other colliding ECMA-119 names should be handled by mangling. But why is that mini.iso produced by genisoimage at all ? debian-7.2.0-sparc-netinst.iso was produced by xorriso. 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
Bug#718151: libburn: FTBFS: Failed to install docs
Hi, Matthias Klose wrote: fix it in libburn or disable building the docs. upstream did tell you that they didn't want to update that for newer doxygen versions. If you mean me, as upstream of libburn, then you got me wrong. I am willing to help Debian packaging in any way. Just give me clear instructions (and be open to objections and negociations if those instructions show undesirable side effects). If you mean the upstream of doxygen, which obviously stalls 60 minutes if it has problem with input data, then i must say that this would be a disappointing attitude. I myself have given up on doxygen. Stable interfaces are a must-have. How shall i prepare code for old and new doxygens alike ? So i join your proposal to just not use doxygen. Not because i think this is the right way to handle the problems, but because i have given up hope that anybody cares for fixing them where they have their origins. 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
Bug#718151: doxygen loops when passing foo(0) to findParameterList
Hi, Helmut Grohne wrote: As for the libburn maintainers, I suggest to change the comment in the header to not include the verbatim string burn_abort(0) in order to not confuse doxygen. Done by http://www.libburnia-project.org/changeset/5122 Do you have more advise for me ? E.g. for this snippet from the message log: /«PKGBUILDDIR»/libburn/libburn.h:3515: Warning: explicit link request to 'if' could not be resolved In my source of libburn-1.2.2, line 3515 is the last one of /** Control queueing and stderr printing of messages from libburn. Severity may be one of NEVER, ABORT, FATAL, FAILURE, SORRY, WARNING, HINT, NOTE, UPDATE, DEBUG, ALL. @param queue_severity Gives the minimum limit for messages to be queued. Default: NEVER. If you queue messages then you must consume them by burn_msgs_obtain(). @param print_severity Does the same for messages to be printed directly to stderr. Default: FATAL. @param print_id A text prefix to be printed before the message. @return 0 for success, =0 for error @since 0.2.6 */ int burn_msgs_set_severities(char *queue_severity, char *print_severity, char *print_id); What am i doing wrong ? I do not send this to doxygen-deve...@lists.sourceforge.net because i expect them to be interested in bug fixing and not in user education. 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
Bug#718151: libburn: FTBFS: Failed to install docs
Hi, i am the upstream programmer of libburn. If i can do anything to help fixing the problem, please tell me. About the doxygen complaints (of which i am unsure whether they are the reason for the stalled build process): libburn release does not build doxygen stuff any more since several years. The doxygen.conf.in file is part of the makefile, target doc is still defined in the makefile, but it is not required by target all. So Debian seems to call make doc explicitly, or do something else that triggers doxygen. doxygen is a recurring source of problems. I would advise to remove it from the Debian build process for libburn. I'd remove it from the release if that was not a potential way to break the distro builds. I corrected most of the complained items in libburn.h now (release 1.3.2 will come soon). But this one riddles me: /«PKGBUILDDIR»/libburn/libburn.h:3515: Warning: explicit link request to 'if' could not be resolved There is a word If in the comment text. But there are lots of similar occasion where doxygen raises no protest. Have anice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, I am also going to print out the sector size. (Or just use GDB.) The loop condition (read_bytes == sector_size) suggests that it must be 2048. Only this alignment is guaranteed for the output of libisofs. (Actually it would be a good reason for the 50 % bug if libisofs would not obey this alignment. But i am sure it does.) BraseroBurn: (at burn-libburn-common.c:218) BraseroLibburn Premature end of input encountered. Missing: 2048 bytes This is a message of libburn. Obviously the image size was pre-announced to libburn and it noticed a shortage when the input stream ended. Regrettably the number 2048 might not be an indication of the exact missing amount. It should be exact if libburn-1.2.4 is in use. Earlier versions always reported 2048. Fixed by http://libburnia-project.org/changeset/4762 Libburn version can be inquired by cdrskin -version libburn-1.2.4 should be installed as libburn.so.4.77.0 $ dd if=/tmp/my_emulated_drive bs=2048 skip=16 count=1 | od -c 000 377 330 377 340 \0 020 J F I F \0 001 001 001 \0 H This looks like the data start of a JPEG file. The data blocks of file content come after the trees. So this time the burn seems to have skipped even more blocks than with the original run. $ dd if=/tmp/my_emulated_drive bs=30720 count=1 | od -c 004 002 C D 0 0 1 001 \0 \0 \0 \0 \0 This is the Joliet Volume Descriptor. It should sit at block 17. So it looks like we lose 17 blocks at start. If the image does not contain only very few files, then we seem to lose further blocks inbetween. 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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, i have to correct myself: 004 002 C D 0 0 1 001 \0 \0 \0 \0 \0 i wrote: It should sit at block 17. So it looks like we lose 17 blocks at start. Well, it sits now at block 8. So we lost 9 blocks before it. 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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi,
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size);
while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size) ==
sector_size) {
... process block that was read by while() statement ...
read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
}
This would well explain why block 17 ends up at block 8.
It is tempting to also claim victory over the 50 % bug, but i
cannot yet make up a plausible explanation. With the 50% bug
https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/780117
it is libisofs which reports 50 % progress, when loop or libburn
close the shop.
The many CD complaints in this Ubuntu bug could well be caused
by above killer loop, though.
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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi,
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, 000 001 C D 0 0 1 001 \0 Yes. That is the start of a Primary Volume Descriptor block. Please mount the medium and use diff to compare the files in the image with their originals on hard disk. Just to be sure. (Mounting does not check all blocks in the image for sanity.) Hmm, it encodes the name in there. To all whistle blowers out there: Do not use Brasero without configuring beforehand. ;-) (Who told your computer your full name on the first hand ?) ECMA-119 says about that field in the PVD: 8.4.21 Data Preparer Identifier (BP 447 to 574) This field shall specify an identification of the person or other entity which controls the preparation of the data to be recorded on the Volume Group of which the volume is a member. I would rather use it to identify the image generating program. (I do so in xorriso. E.g.: XORRISO-1.2.5 2012.09.15.170346, LIBISOBURN-1.2.5, LIBISOFS-1.2.5, LIBBURN-1.2.5 ) Brasero mentions itself as: 8.4.20 Publisher Identifier (BP 319 to 446) This field shall specify an identification of the user who specified what shall be recorded on the Volume Group of which the volume is a member. I would deem this field more appropriate to rat out Paul Menzel. :)) mkisofs has a third opinion on that. It advertises itself in: 8.4.22 Application Identifier (BP 575 to 702) This field shall specify an identification of the specification of how the data are recorded on the Volume Group of which the volume is a member. PS: Thomas, reading the libburnia start page [1], I see you take donations. If some users, benefiting from this patch want to donate something, I would like the libburnia project to have it. So it would be great if you could give me the necessary instructions. If you would like to donate, please mail us: mario.danic [at] gmail [dot] com, Cc: scdbackup [at] gmx [dot] net. I personally can accept donations only by my german bank account. Possibly this is feasible within the EU even with smaller amounts. Our project founder Mario Danic has a paypal account, afaik. I understand he has to pay money for the web hoster. 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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, Paul Menzel wrote in his patch: Substituting this command with the variable fixes the problem reported in GNOME Bugzilla bug 655601. I have to stress that the found bug does _not_ explain the original report of https://bugzilla.gnome.org/show_bug.cgi?id=655601 (which is what i call the 50 % bug). I would explain several of the follow-up comments in this bug report. Especially it would explain http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617409 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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi, The log shows some Growisofs message and not the one I have. Although, could it be that it is dependent on the libburn version? The libburn plugin was not used. Only the libisofs one. A run with growisofs as burn engine would also suffer from the bug we found in the libisofs plugin. But the found bug would not cause libisofs or growisofs to abort after libisofs generated about 50 percent of the image. GNOME bug 655061 is the same initial bug report as Ubuntu 780117. Both took a long tail of me-toos which mostly match our found bug. There we find the hints about direct burning (which fails) and burning of previously stored ISO images (which succeeds). Since when does libburn return if all data was written or not? Quite some while. But it depends on whether the size of the track was announced by the application. I understand Brasero creates its own struct burn_source implementation. So it depends on whether burn-libburn.c:brasero_libburn_src_get_size() returns non-zero. Whether this changed in the past is a matter of Brasero history. It might have been a libburn provided burn_source object in the past which would have been created by libburn call struct burn_source *burn_fd_source_new(int datafd, int subfd, off_t size); Here it would matter whether size is non-zero, resp. on the result of fstat(datafd, ...). I am not so sure on this one anymore as it is reported against 2.30.3-2 which does not have the offending patch. I can imaging that it is caused by the problem the faulty patch wanted to fix [1]. But thinking about this the original reporter wrote, that his medium could be mounted. I see. But the follow-up by Simon Wenner was with a higher Brasero version. I would deem this field more appropriate to rat out Paul Menzel. :)) Very much more appropriate. ;-) Are you doing that in xorriso? I do not even know how to get your full name from your computer. You would have to rat out yourself by xorriso command -publisher 'Paul Menzel' Interesting. Though I know of no such specifications. ECMA-119 is the freely available form of ISO 9660 specs. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf The contract between image producers and image readers. It describes on byte level how an ISO image has to look like. 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
Bug#688229: Burning data DVD looks successful but mounting fails
Hi,
i think i can spot a byte eating problem in
http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
resp. the master-branch commit
http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
-
@@ -200,6 +198,7 @@ brasero_libisofs_write_image_to_fd_thread
(BraseroLibisofs *self)
brasero_job_get_fd_out (BRASERO_JOB (self), fd);
BRASERO_JOB_LOG (self, Writing to pipe);
+ read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size) ==
sector_size) {
if (priv-cancel)
break;
-
Variable read_bytes is set by a call of libisofs' resp. libburn's
burn_source.read_xt() which consumes data (one sector ?) into buf.
The call in the while() statement consumes another sector and thus
overwrites the previously read buffer without having done anything else
with that first buffer content.
Further down i see a similar change that looks more plausible
to me:
-
@@ -254,7 +261,8 @@ brasero_libisofs_write_image_to_file_thread
(BraseroLibisofs *self)
priv = BRASERO_LIBISOFS_PRIVATE (self);
brasero_job_start_progress (BRASERO_JOB (self), FALSE);
- while (priv-libburn_src-read_xt (priv-libburn_src, buf, sector_size) ==
sector_size) {
+ read_bytes = priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size);
+ while (read_bytes == sector_size) {
if (priv-cancel)
break;
-
It appears to me that this information is not yet known in
https://bugzilla.gnome.org/show_bug.cgi?id=630651
Feel free to add my technical opinion to that bug report.
I will try to contact Philippe Rouquier directly on this issue.
Swallowing the first sector is enough to make the image not mountable.
But regrettably a single lost sector does not yet explain the fact
that we find Joliet data at block 16.
The normal layout of an ISO 9660 image with Joliet (and no
El Torito boot equipment) would be
Block 16: ISO (660/ECMA-119 Primary Volume Descriptor
Block 17: Joliet Volume Descriptor (which would not contain
names of payload files like IMG_2428.JPG)
Block 18: Volume Descriptor Set Terminator
libisofs will then pad up to 64 KB and first write the
ISO 9660 + Rock Ridge tree. Several blocks to be expected.
Only then comes the Joliet directory tree with those entries
which we found at block 16.
So we look for a byte eater that swallows at least a few dozen
sectors and not only the first one.
Nevertheless, the code pieces, where above change was made,
look much like the place where the emerging damage of an
ISO 9660 image can be watched ... if it is not caused there.
A very good starting point for debugging, i'd say.
Telling from the function names, i would say the change which
i deem bad is in charge for writing to optical media, whereas
the good one is in charge for writing image to a file in hard
disk.
An according difference in success can be found in several
Brasero bug reports of the last years.
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
Bug#688229: 688229: hack to emulate drive
Hi, + res = burn_drive_convert_fs_adr (stdio:/tmp/my_emulated_drive, libburn_device); Isn't there a quotation mark missing before the comma ? 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
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, Could you please CC me I will try to remember. :) But maybe you better subscribe by a mail to 688229-subscr...@bugs.debian.org Is there some way to simulate a burner to find out what happened? libburn would accept burner addresses like stdio:/tmp/my_emulated_drive which would behave like DVD-RAM or DVD+RW. I.e. quite different from DVD-R or DVD+R. Nevertheless such an emulated drive would allow to exercise the communications between libisofs and libburn, as done by Brasero. I do not know how to make Brasero use such a drive address. Probably one would have to hack its source. Another way to exercise DVD-R is to use DVD-RW. They need to get blanked before re-use. E.g. by xorriso -outdev /dev/sr1 -blank deformat -eject all This lasts as long as writing the full capacity of 4.7 GB. (Fast blanking is possible but the DVD-RW would afterwards refuse to perform the write type Incremental which is used by Brasero.) Some numbers from your reports are against my theory of a missing start piece: libisofs reported: brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) dvd+rw-mediainfo and xorriso -toc report a track size of 1059568*2KB The overall sizeis of image and track would match. 2 * 1059568 - 2119108 = 28 The track size is aligned to a DVD ECC block of 32 KiB. The track was written by write type Incremental. I.e. it is supposed to bear only the bytes which were actually written, rounded up to the next multiple of 16 blocks (= 32 KiB). If a start piece of the image would be missing, then the track would have to be shorter. Gr. I assume you too live in Germany. If so: Would the images on the DVD be non-private enough and would you want to invest 1.45 Euro into a mail stamp in order to send me that DVD-R for closer inspection ? Or do you have 2 GB of internet storage from where i could download a copy of the medium made by dd if=/dev/sr1 bs=2048 of=/tmp/copy_of_dev_sr1 ? Everything worked fine with `xorriso`. $ xorriso -md5 on -outdev /dev/sr1 -map ~/test / Well ... Yay and G at the same time. Yay for xorriso and the drive, Grrr for my inability to explain what went wrong with the Brsaero DVD-R. The only thing I noticed, that another DVD drive, the Toshiba DVD-ROM SD-M1712, needed more than 25 seconds to recognize the disc. This might be due to the fact that the medium is still appendable, unlike the one from Brasero. I.e. you could add more files by xorriso or growisofs. How is recognition time with the burner ? In order to get a closed DVD-R, you would have to use command -close on E.g. with the now appendable DVD-R medium $ mkdir ~/test2 $ cp ...a...few...files... ~/test2 $ xorriso -md5 on -dev /dev/sr1 -map ~/test2 /test2 -close on (Note that this run uses command -dev rather than -outdev in order to load the existing directory tree of the image and to merge it with the newly added file tree.) Maybe it will then be recognized faster by the DVD-ROM. 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
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, Paul Menzel wrote: $ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c ... 000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 + 020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 060 8 \0 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 100 224 ! 001 \0 \0 001 ! 224 @ 276 + \0 \0 + 276 @ 120 p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001 034 \0 140 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0 9 \0 160 . \0 J \0 P \0 G \0 ; \0 1 \0 \0 \f ' This does not look like an ISO 9660 Primary Volume Descriptor but rather like a snippet from a Joliet directory tree. Read as 16 bit characters one can recognize IMG_2428.JPG and IMG_2429.JPG. They are announced to start at blocks 72752 (decimal) and 74132 (decimal). Sizes are 2825286 and 2866752 bytes. ... if i decoded these little endian 32-bit numbers correctly: 0 034 001 \0 IMG_2428.JPG, Location of Extent F 034 + \0 IMG_2428.JPG, Data Length 224 ! 001 \0 IMG_2429.JPG, Location of Extent @ 276 + \0 IMG_2429.JPG, Data Length (The layout of directory records is documented in ECMA-119, 9.1. Joliet deviates from this layout mainly by using 16-bit characters for File Identifier.) I really wonder how this could get to block 16 of the medium. Brasero did order libisofs to produce a Joliet tree. But it should be stored several blocks after block 16. Before Joliet there should be volume descriptors and the ISO 9660 + Rock Ridge tree. It is clear that no reader software wants to accept this as ISO 9660 filesystem. Guessing from this single block content, i would expect that a few hundred kilobytes of the image start have not been written onto the medium. Most simple explanation for this would be that they were not transmitted from libisofs to libburn. But i riddle how this could be possible. PS: Is there any way to rescue the broken media, that means to correctly finish the burning process? The medium is irreversibly closed. The problem seems to be in lost data blocks. (One could try to retrieve the JPEGs. If the loss is only about data at the image start, then it should be possible to guess names from the remaining part of the Joliet tree.) $ dvd+rw-mediainfo /dev/sr1 The output looks totally normal. Medium is ok. I think I forgot to add that the burner and the same DVD medium were used successfully with for example K3b and I also think xorriso. We have no special indication of any malfunction of burner or medium. There are just not the right bytes stored at the right block addresses. A further test with xorriso would be welcome. Just to be sure. 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
Bug#688229: Burning data DVD looks successful but mounting fails with ISOFS: Unable to identify CD-ROM format.
Hi, brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %) It went well, at least as far as libisofs was involved. So this is not the problem with premature end after 50 %. And it is not the riddling CD problem, where Brasero CDs are unreadable, whereas xorriso burned CDs are ok. BraseroLibburn Async SYNCHRONIZE CACHE succeeded after 0.8 seconds ... BraseroLibburn Closing track 01 (absolute track number 1) BraseroLibburn Async CLOSE TRACK SESSION succeeded after 0.4 seconds BraseroLibburn Closing session BraseroLibburn Async CLOSE TRACK SESSION succeeded after 5.3 seconds These messages stem from libburn. They indicate that it saw no severe error message from the drive and that it finished the burn run. I cannot tell, though, how many data were passed through libburn. [ 9103.816252] ISOFS: Unable to identify CD-ROM format. What do you get from dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c With a valid ISO image, the output should begin by 000 001 C D 0 0 1 and consist of up to 128 lines of text. What do you get from dvd+rw-mediainfo /dev/sr1 (Have medium and tray already loaded. It will not pull in the tray.) $ xorriso -outdev /dev/sr1 -check_media what=disc use=outdev ... Media current: DVD-ROM Media status : is written , is closed A Media summary: 1 session, 1059568 data blocks, 2069m data, 0 free ... xorriso : UPDATE : 1059568 of 1059568 blocks read in 265 s = 5.9xD Media checks :lba , size , quality Media region : 0 ,192 , + good Media region :192 , 16 , + slow Media region :208 ,1059360 , + good This xorriso command did not judge whether the medium bears an ISO 9660 filesystem. It only inspected the medium state. The medium is reported by the drive as DVD-ROM, which is permissible if it is closed. (Is it a DVD-R ?) Further the drive did not report any errors when reading the data blocks. The average reading speed of 5.9x is not overly high but does not yet indicate a large number of re-tries. No long pauses were perceived while reading, except the small speed glitch at block 192 which is quite normal. The following xorriso run would tell more about the recognizability of ISO 9660 content on the medium: xorriso -outdev /dev/sr1 -toc This run would try to load the directory tree of the ISO image and issue error messages if there is no proper ISO 9660 on the medium: xorriso -indev /dev/sr1 It has to be feared that it will bail out similarly to the mount attempts. 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
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-rc-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-rc-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-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
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-rc-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-rc-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-rc-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, 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-rc-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-rc-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-rc-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-rc-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-rc-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: 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-rc-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-rc-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-rc-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-rc-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-rc-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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
