Bug#714941: wodim: Wodim fails to burn DVD-DL (dual layer)
Wodim is a cdrecord version from September 2004, with DVD support ripped off and with SCSI specific bugs from Debian added. There was no development in the project since May 2007. I recommend you to upgrade to recent original software from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ to get DVD and BluRay support. Note that since the original software is under constant improvement, the features available in cdrkit currently just cover 30-40% of the features in the original software. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580615: cdrkit: Port on MacOS X is broken
cdrkit has been created with the intention to harm users on Linux and by people who have no clue on portability and even on SCSI on Linux. While the majority of platforms does not even allow to send SCSI commands to a file descriptor that was derived from a device sprcific special file, the people behind cdrkit tried to prevent people from using the platform independent SCSI address syntax with dev=. Given the fact that any serious work on cdrkit stopped on May 7th 2007, and the fact that cdrkit represents the development state from September 2004 (with some features like DVD support removed), I don't know why someone would be interestred to use cdrkit instead of recent original software. In special on Mac OS X, you would also suffer from various bugs in genisoimage and from the fact that genisoimage does not include Mac OS X specific UDF extensions. cdrkit misses more than 60% of the features found in the current original software. Would you be interested to run an operating system from 2004 today? Be clever and don't try to ride a dead horse... remember that you did not even get a reply to your bug report. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Josselin Mouette j...@debian.org wrote: Le jeudi 23 avril 2009 à 15:39 +0200, Joerg Schilling a écrit : It may make sense to talk to the brasero maintainers/authors directly. Note that Solaris decided not to include cdrdao at all and that Solaris tries to use brasero, so there is a need to implement decent brasero support for cdrtools. According to your own sayings, this is not possible: http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/03441.html In this mail you explain that cdrecord does not work correctly with HAL. However, HAL is one of the dependencies of brasero, it is also now a dependency of the X server. Zero points! I recommend you to learn English in hope that you in future understand things. Hald on Linux is known to be broken and to cause many problems with burning CDs. Hald on Solaris does not have these problems ;-) If you change directly after they have no reason, not work that has how do not to find a social problem with me the Debian or Sun legal risk to this years. You some basic concepts in the broken nearly this mail is no way. Too many OS exception definitely not part of sevreral independent work correctly is a mistake. The fork on the original right: to do is non serious that is in violation understanding the dispute? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
The mail above (sent at Sun, 26 Apr 2009 10:08:18 +0200 from a malicious account at malsain.org) is spam, it hast been sent by a faker! Please remove this junk from the bugtracking system. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522684: File is not larger than 4GiB-1
Hi, genisoimage is just a 4+ year old version of mkisofs. Genisoimage does not support large files. If you like to use large files, you need to use the original mkisofs from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Make sure to use mkisofs -iso-level 3 or above. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
You wrote: My original problem was that I could not get brasero to burn an ISO (with TOC) image of an audio CD. Eventually I discovered that it works if cdrdao is installed (but only v 1.2.2-16, no later, but I think that's a bug in cdrdao's drivers and my particular hardware). Without cdrdao installed, the burn button was simply greyed out, with no info as to why. This is relevant: Re: what is the internal priority for brasero when select between cdrecord/cdrdao/cdrttool http://mail.gnome.org/archives/brasero-list/2008-July/msg00017.html just a note: The best audio quality is achived when using cdrecord (cdrtools). The second best choice may be cdrdao but note that cdrdao is not maintained anymore since 5 years. There have been a few bug fixes since then but no nore. libburnia has other problems: 1) It is non-portable and thus limits portability of brasewro 2) It depends on a Linux privileges problem and will force other platforms to run brasero as root if it may be ported. cdrecord is the best way to deal with this as it implements a clean separation between the privileged task of sending SCSI commands and a complex and thus hard to review GUI code. wodim is unmaintained, just represents an old (4+ years old) state of cdrtools and wodim cannot be legally distributed because of Copyright and GPL problems. wodim should have the lowest priority. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
Josselin Mouette j...@debian.org wrote: Le jeudi 23 avril 2009 à 12:50 +0200, Joerg Schilling a écrit : just a note: The best audio quality is achived when using cdrecord (cdrtools). Jason, please ignore any communications from Jörg Schilling. The problem with brasero is that it is somehow outdated. I recommend using nautilus-cd-burner instead until we have packaged 2.26. Jason, I am sorry but I have the impression that Josselin Mouette is not intersted in a fact oriented discussion. If this persists, you would need to ignore him. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
Jason Heeris jason.hee...@gmail.com wrote: Joerg Schilling wrote: just a note: The best audio quality is achived when using cdrecord (cdrtools). [...] wodim is unmaintained, just represents an old (4+ years old) state of cdrtools ...But the description of the Debian cdrecord package says: This is a dummy package to ease the transition to wodim, the fork of cdrecord. It provides a cdrecord symlink to wodim for compatibility purposes. Please use wodim instead of cdrecord. ...which is a bit confusing. At any rate, I know that without the cdrdao package installed, I cannot select any of the options for burning (eg. simulate, overburning, etc); whereas I can with it installed. This may be a deficit of brasero or your brasero version. It may make sense to talk to the brasero maintainers/authors directly. Note that Solaris decided not to include cdrdao at all and that Solaris tries to use brasero, so there is a need to implement decent brasero support for cdrtools. The drive is a Samsung SATA SH-S223F (the device manager says it's an SCSI connection, /dev/scd0), by the way. All CD writers are SCSI, they may just use a different SCSI transport media. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525140: [brasero] Should recommend or depend on 'cdrdao'
Josselin Mouette j...@debian.org wrote: Le jeudi 23 avril 2009 à 15:39 +0200, Joerg Schilling a écrit : It may make sense to talk to the brasero maintainers/authors directly. Note that Solaris decided not to include cdrdao at all and that Solaris tries to use brasero, so there is a need to implement decent brasero support for cdrtools. According to your own sayings, this is not possible: http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/03441.html In this mail you explain that cdrecord does not work correctly with HAL. However, HAL is one of the dependencies of brasero, it is also now a dependency of the X server. Zero points! I recommend you to learn English in hope that you in future understand things. Hald on Linux is known to be broken and to cause many problems with burning CDs. Hald on Solaris does not have these problems ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#405644: Change dependency on cdrecord to wodim
I further noticed that the perl script mp3burn calls cdrecord, hence that dependency is actually needed. What needs to be done is to modify the program itself to call wodim instead of cdrecord. Given that wodim has the same command line syntax as cdrecord you simply have to replace all occurences of cdrecord by wodim to solve the problem. Please make sure that the assumption is true and correct then the dependency. Cdrecord will soon be available again on Debian. Why do you like to change something? Changing the text cdrecord to wodim will create more problems that you might believe to to solve with such a change. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#488482: rules violation
Please do not forward private mail to public mailing lists! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488482: genisoimage: does not handle deep directory structures even though manpage says it does
Hi, Debian uses an extremely outdated version of mkisofs and in addition added new bugs. The official mkisofs correctly handles deep directory relocation in all cases since 2 years. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475918: star: new stable upstream version 1.5 available
PLEASE FINALLY FIX YOUR MAILER This is the third time you destroyed the mail address for Mika (Michael Prokop) and this is the third time I had to manually insert the correct address for Mika. Pawel Wiecek [EMAIL PROTECTED] wrote: On Apr 16, 1:19pm, Joerg Schilling wrote: You seem to forget that the binaries names are changed so they do not clash with other packages. I see no name clashesplease explain! Various versions mt and rmt are provided in tar, star and mt-st. None of them can claim the names mt or rmt. Alternatives system will provide a symlink to one of them, usually the one from tar. I don't suppose you intend to refer to the other mt in star's manual, don't you? You are either confused or you write in miracles Debian does not provide _THE_ tar command, which is here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/tar/tar.c Debian could include _A_ tar implementation but currently it does not really do so. This is because Debian installs GNU tar (gtar) as tar. If you have a look at the relevent SUSv2 standard which is here: http://www.opengroup.org/onlinepubs/007908799/xcu/tar.html you will see that GNU tar neither correctly follows the CLI definitions of the standard nor does it write a standard compliant TAR archive format by default. Star is 100% compliant to the SUSv2 tar standard, so it would be a good idea to install a link from /bin/tar to star to get a standard compliant tar on Debian. Anyway: thinking on whether a implementation could rightfully use a specific name seems to be a bit wrong Unless you provide the original implementation of a program (in which case you would be allowed to talk about _THE_ xxx command), you could only provide one of several clone implementations (_A_ xxx implementation). But thinking this way, you are still wrong when talking about the star man page: The star man page _mentiones_ mt(1) but it does not mention the extended features that are available with the mt(1) implementation that is part of the star distribution. For this reason, the reference to mt(1) is OK unless Debian ships a broken mt command that does not support the basic mt features mentioned in the star man page. The star man page mentiones rmt(1) but it also describes the differences between the avaliablee implementations. There is absolutely no need to change names in the star man page for above reasons. Also note: Debian would do a favor to it's users if it did deliver the rmt implementation from star as the default. The star rmt implementation is the only implementation that correctly talks to _all_ rmt client implementations and that includes a complete abstraction from platform, cpu and byteorder differences between the server and the client machine. ... [some other missunderstood parts removed] Are you referring to some problems created by the buildprocess you have created yourself? The file star_fat.c is _not_ part of the source. If you create it (as you No Joerg, *I* did not create it. Your makefiles did. And they did not clean it. You are wrong: *you* did create a patch that is repsonsible for the fact that your build environment for star uses a broken star_fat.c Please do not try to blame others for problems you caused. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#475918: star: new stable upstream version 1.5 available
Pawel Wiecek [EMAIL PROTECTED] wrote: [ personal attacks removed...] You are wrong: *you* did create a patch that is repsonsible for the fact that your build environment for star uses a broken star_fat.c Stop talking about packaging if you do not understand related procedures. Instead go and fix your buildprocess that doesn't clean what it built. If you like to create a non-working version of star, go ahead and do it like you intend. It seems that you do not lilke to get help... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#475918: star: new stable upstream version 1.5 available
Pawel Wiecek [EMAIL PROTECTED] wrote: PLEASE FIX YOUR MAILER! Your mailer repeatedly bastardizes the mail address for Mika On Apr 15, 11:18pm, Joerg Schilling wrote: Ehm, no, manpage naming binaries differently than they are named in filesystem is not actually correct. The star man page names the binaries the same way they are in the filesystem. Where do you see problems? You seem to forget that the binaries names are changed so they do not clash with other packages. I see no name clashesplease explain! Yeah, particularily the one where you suggested to use tooling from outside distribution. Do i have to dig it up? I have no idea what you are talking about. Then I'll have to dig this up in my archives. If you believe that you are clever enough to write a working make clean for the schily makefilesystem - please send a patch, you are welcome! You could make No, I'm not going to fix either your makefilesystem nor automake, bjam or any other buildprocess I consider unnecessarily complicated. Also because doing Good point, but why then do you create unneeded complex wrappers around a simple and easy to use make system like the Schily Makefilesystem? Just a note: Do not complain claim that you know better if you really don't (I asume that you would be able to share your ideas in case you had a solution). If you have no solution, simply stop telling me that I am wrong. Obviously this works much better when the upstream author's attitude is far from telling everyone and everywhere that everything they do is wrong. Sorry, I am just telling you how to do things right. You may follow this advise No, not at all. Just a few samples: | I recommend to through away the sources I send this advise to you after you appeared unwillling to fix a bug you created with a bad patch made by you. The way you then replied looks rude to me and I hope that you will not continue your rude habbit. If you do not intend to be rude, please read the mail you write before you send it and rewrite it. Please relax and note that the kind of problems you created when calling gdiff -urN old new file could be simply avoided if you just had a look into the resultant file before using it. NOTE: If you do not throw away your current source tree and then start with the clean star-1.5 source, you will definitely end up in a source tree that is not working correctly. The file star_fat.c is _not_ part of the source. If you create it (as you currently do), bypassing the official make rules, you hose up the build process. The Schily makefilesystem has been designed to allow a compilation _without_ manual configuration on a large number of different platforms. This includes Linux (Linux has been explicitely tested). If you believe you need to change or patch something, you should blame your build environment instead of blaming the star source. I am willing to help you to find what you are doing wrong and to fix your build environment, but I cannot do that if you are not open to listen to me. In general, try to be more relaxed. I am always open to anyone who is open to new experiences Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#475918: star: new stable upstream version 1.5 available
Pawel Wiecek [EMAIL PROTECTED] wrote: Let me see... star/star.1 Obviously using Joerg's version would very quickly get me a lot of bug reports. Why do you expect to get bugreports for a correct man page? Looking at the current Debian Bug list shows that all bug reports that are not related to packaging will go away if you upgrade to the current star-1.5 version. anyway (as suggested by Jörg regarding star_fat.c). I'd prefer to be really careful before applying anything that Joerg suggests. His suggestions are sometimes very, very bad. My suggestions are always correct. The problem is that you did missunderstand things several times. I suspect that you did not try to understand how the compilation works and as a result created a buggy patch Please read this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310662 to understand that your incorrect source handling caused massive problems. Also note that some tim eago, I told you why a makefilesystem that includes a complete dependency list and that controls the calling of ./configure has problems to iplement make clean from the makefile system (except if there is a way to reverse the action order for a specific target). For this reason, all distributions come with a .clean shell script. In order to avoid such missunderstandings, it is good practice to foster good relations with the author and just ask in case things are not 100% clear. This is how Mika was able to get things running quickly ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#475918: star: new stable upstream version 1.5 available
Pawel Wiecek [EMAIL PROTECTED] wrote: On Apr 15, 11:03am, Joerg Schilling wrote: Why do you expect to get bugreports for a correct man page? Ehm, no, manpage naming binaries differently than they are named in filesystem is not actually correct. The star man page names the binaries the same way they are in the filesystem. Where do you see problems? If you are _missing_ software at Debian, you may like to check out the schily source consolidation at: ftp://ftp.berlios.de/pub/schily/ the latest currently is: ftp://ftp.berlios.de/pub/schily/schily-2008-04-07.tar.bz2 My suggestions are always correct. The problem is that you did missunderstand Yeah, particularily the one where you suggested to use tooling from outside distribution. Do i have to dig it up? I have no idea what you are talking about. ... if you are talking about the fact that Debian only offers an extremely outdated version of smake, then this is obviously not a problem caused by me. I am updating my software on a regular base. I might also point out that with a well written buildprocess the clean target is as simple as doing a SINGLE rm. No need to trace anything. If you believe that you are clever enough to write a working make clean for the schily makefilesystem - please send a patch, you are welcome! You could make a new friend. In order to avoid such missunderstandings, it is good practice to foster good relations with the author and just ask in case things are not 100% clear. Obviously this works much better when the upstream author's attitude is far from telling everyone and everywhere that everything they do is wrong. Sorry, I am just telling you how to do things right. You may follow this advise or not, but please do not try to make me responsible if you fail because you make things differently from what I proposed. In general, try to be more relaxed. I am always open to anyone who is open to new experiences Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#475918: star: new stable upstream version 1.5 available
Hi, I recommend to through away the sources at http://hg.svartech.com/debian/star/ and cleanly start with the official source. The reason for a clean start is: 1) your source includes a broken star_fat.c, but it sould not contain this file at all. Seeing star_fat.c makes me asume that there might be other problems that are best handled by a clean new setup. 2) The source has been cleaned up past 1.5a89 to only use a clean libfind. If you do not start cleanly, you will most likely keep outdated files. 3) you should get help from Mika for the correct make wrapper from cdrtools that uses the right values for INS_BASE= and DESTDIR= Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#457308: CD: missing files and corrupt filenames
Vincent Lefevre [EMAIL PROTECTED] wrote: I've attached an archive containing a directory dir (all the files are empty, but what's important is their filename and if they are present or not), the corresponding ISO image obtained on Mac OS X with: What happens if you mount this filesystem on Linux with Rock Ridge enabled? hdiutil makehybrid -o test.iso dir and a ReadMe file with the full isoinfo output with -lJ and -lR. I haven't tried to mount the image (I don't know how to do that) to see if all the files are present with mount + ls, but with -lR, there are two BAD RRVERSION errors and the first dot of foo.tar.bz2 is missing. Also, all the filenames are in uppercase letters. Thank you for the data, it confirms my asumptions! The original Author of the Linux iso-9660 filesystem is the same person as the original Author of mkisofs. The linux kernel seems to have inherited the same bugs as I inherited in mkisofs.. If I mount the filesystem on Solaris, I get the following listing from the mount point: Gesamt 0 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200309.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200310.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200311.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200312.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200401.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200402.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200403.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200404.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200405.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200406.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200407.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200408.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200409.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200410.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200411.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200412.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200501.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200502.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200503.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200504.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200505.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200506.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200507.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200508.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200509.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200510.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200511.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200512.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200601.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:10 access_log-200602.bz2 -r-xr-xr-x 1 root sys0 Dec 25 18:09 foo.tar.bz2 /var/adm/messages contains: Dec 25 19:10:41 opt hsfs: [ID 196000 kern.notice] NOTICE: hsfs: Warning: file system mounted on /mnt does not use Rock Ridge version = 1.12: Dec 25 19:10:41 opt hsfs: [ID 260047 kern.notice] hard linked files disabled Dec 25 19:10:41 opt hsfs: [ID 674684 kern.notice] Due to this error, the file system may not be correctly interpreted. Dec 25 19:10:41 opt hsfs: [ID 532498 kern.notice] Other such errors in this file system will be silently ignored. This is only a hint on the fact that the filesystem follows an _outdated_ Rock Ridge standard. This is the same outdated Rock Ridge standard that is implemented by genisoimage (Note that genisoimage is just a frozen outdated mkisofs). The main problem with the outdated Rock Ridge version is that hard links do not work, but the Linux kernel implementation does not support correct hardlinks on iso-9660 either. There is no problem with the correctness of the Rock Ridge structure. Solaris accepts it! Conclusion: 1) I need to fix isoinfo and mkisofs to deal correctly with the Apple extensions. 2) The Linux kernel implementation for Rock Ridge is broken and needs to be fixed. Once I am done, you should upgrade to the new cdrtools release. This will be another reason not to use the fork called cdrkit. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#457308: CD: missing files and corrupt filenames
Vincent Lefevre [EMAIL PROTECTED] wrote: The log messages just say: Dec 25 21:01:32 vin kernel: loop: module loaded Dec 25 21:02:01 vin kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 Dec 25 21:02:01 vin kernel: ISO 9660 Extensions: IEEE_P1282 Dec 25 21:03:46 vin kernel: ISO 9660 Extensions: Microsoft Joliet Level 1 So, no warnings or errors. Solaris warns if the filesystem code does not like the filesystem, Linux is quiet. This is only a hint on the fact that the filesystem follows an _outdated_ Rock Ridge standard. This is the same outdated Rock Ridge standard that is implemented by genisoimage (Note that genisoimage is just a frozen outdated mkisofs). The main problem with the outdated Rock Ridge version is that hard links do not work, Do you mean do not work or are not available? i.e. when creating an ISO-9660 image, the software must not try to include hard links because they are not supposed to be supported? They look like hard linked in the first attempt, but the files have different inode numbers. but the Linux kernel implementation does not support correct hardlinks on iso-9660 either. I hope that the user would get some warning or error if he tries to mount an ISO-9660 image using a new RR version. Linux ignores the extra data. Conclusion: 1) I need to fix isoinfo and mkisofs to deal correctly with the Apple extensions. 2) The Linux kernel implementation for Rock Ridge is broken and needs to be fixed. OK. So, I suppose that this bug should be cloned and reassigned to both genisoimage/cdrkit (since Debian chose to fork, this is their problem to fix it for their fork) and linux-2.6 (hoping that maximilian attems won't complain again about this bug not being a kernel bug). It is most unlikely that you will get a fix for cdrkit from Debian unless they chose to steal my code ;-) There is much more hope for Linux and the real mkisofs... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#457308: CD: missing files and corrupt filenames
Apple may or may not follow the standards here... Your primary problem seems to be Linux kernel related and it seems to be important to verify the filesystem image for standard compliance. If the filesystem is not standard compliant, you need to send a bug report to Apple. If the filesystem is standard compliant, you need to send a Linux kernel bug report. Not all problems seen in cdrkit are present with the original software, so it may be helpful to check therecent original cdrtools first. ftp://ftp.berlios.de/pub/cdrecord/alpha/ The old mkisofs code definitely did not handle Apple extensions correctly. Unfortunately I am not sure whether I fixed all related problems already. I know that the Solaris hsfs kernel filesystem driver correctly ignores Apple extensions, so you may like to test the CD on a recent Solaris version to verify whether there is a Linux kernel problem. Testing on Rock Ridge unaware platforms does not help. I am interested in the filesystem image to check mkisofs and fix it if needed. Could you please send a small example? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#457308: CD: missing files and corrupt filenames
Vincent Lefevre [EMAIL PROTECTED] wrote:
On 2007-12-24 12:17:42 +0100, Joerg Schilling wrote:
Apple may or may not follow the standards here...
Since isoinfo detect errors (or do you mean that isoinfo may be
isoinfo is based in mkisofs technology.
The original Author of the Apple extensions did missinterpret the
way the Apple extensions are expected to fit into the ISO-9660 and Rock Ridge
framework.
Somebugs are fixed when the problem in the code is obvious and others are not
fixed before a testcase exists
buggy?), it seems that Apple does not follow the standards here
(unless their interpretation is ambiguous). But the important
point is that this can be detected, but it isn't detected when
using mount + {ls or cp or whatever software that tries to read
the file}.
Whether or not Apple follows the standard cannot be said before I see the
filesystem image or before you report results from a mount attempt on Solaris.
Your primary problem seems to be Linux kernel related and
This is what I thought first. The bug is in the code that reads
the RR index but doesn't check that it is valid. But I don't know
if it is mount that reads the data and passes it to the kernel,
or if it is the kernel that reads the data directly (according to
Maximilian Attems, the bug is not in the kernel).
It is unrelated to mount but if the filesystem follows the standard, it is
a result of a bug in the Linux filesystem code.
Now, if an error can be detected on the Linux side (and isoinfo, if
not buggy, shows that this can be detected), the software should at
least output a warning or an error message when the RR index is read.
Whether there is a bug or not in the filesystem produced by Apple depends
on the strucure inside the Rock Ridge part of the filesystem.
I won't have the Linux machine in question in front of me until
early January... There's another Linux machine here with a working
CD drive, I'll try it.
OK
The old mkisofs code definitely did not handle Apple extensions
correctly.
Could this explain the errors returned by isoinfo?
Yes
Unfortunately I am not sure whether I fixed all related problems
already. I know that the Solaris hsfs kernel filesystem driver
correctly ignores Apple extensions, so you may like to test the CD
on a recent Solaris version to verify whether there is a Linux
kernel problem.
Unfortunately I don't have physical access to Solaris machines.
You don't need to, you may just scp a small filesystem image.
Well, you need to have root privileges or someone who helps.
It is also possible to run a life CD and check from this code.
I am interested in the filesystem image to check mkisofs and fix it
if needed. Could you please send a small example?
This iso image contains private data, but I could try to build another
one when I come back home.
Please do.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#457308: CD: missing files and corrupt filenames
Vincent Lefevre [EMAIL PROTECTED] wrote: On 2007-12-24 12:17:42 +0100, Joerg Schilling wrote: Not all problems seen in cdrkit are present with the original software, so it may be helpful to check therecent original cdrtools first. ftp://ftp.berlios.de/pub/cdrecord/alpha/ I could compile cdrtools 2.01.01a36 on the Debian etch machine here. Same problem: titine:/home/vincent# ~vincent/cdrtools/bin/isoinfo -R -i /dev/hdc **BAD RRVERSION (14) **BAD RRVERSION (114) **BAD RRVERSION (78) **BAD RRVERSION (10) **BAD RRVERSION (116) **BAD RRVERSION (82) **BAD RRVERSION (4) titine:/home/vincent# ~vincent/cdrtools/bin/isovfy /dev/hdc Root at extent 29, 4096 bytes [0 0] 2b: 212 2dc3b 2438527 RRlen=170 [AA,PX,TF,**BAD SUSP 0 80] 2b: 148 2fc22 1459310 RRlen=102 [AA,PX,TF,**BAD SUSP 0 80] 2b: 254 2feeb 12976541 RRlen=208 [AA,PX,TF,**BAD SUSP 0 80] 29: 150 2359e34561 RRlen=106 [AA,PX,TF,**BAD SUSP 0 80] 29: 254 235af 70726288 RRlen=206 [AA,PX,TF,**BAD SUSP 0 80] 30: 228 39ad4 1531300 RRlen=174 [AA,PX,TF,**BAD SUSP 0 80] 30: 150 3c448 1936021 RRlen=96 [AA,PX,TF,**BAD SUSP 0 80] OK, then I need to look into a similar filesystem image. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#451578: genisoimage segfaults when using -J
$ gdb genisoimage (gdb) set args -C 312032,365680 -M /dev/cdrom -v -v -print-size -JR -uid 0 -gid 0 -graft-points users/ivan/archives/=/.../users/ivan/archives/ Nothing strange (AFAICT) in /.../users/ivan/archives/. I may specify another directory and it will segfault, too. The problem vanishes if I omit `-J'. I believe it's a long-standing bug. (I've just get my hands on building a recent cdrkit with `noopt nostrip' to trace it.) Many bugs in genisoimage have never been in mkisofs and many bugs that appear as old bugs in genisoimage have been fixed in mkisofs long time ago. I cannot reproduce your problem with mkisofs and I recommend you to just switch to a recent maintained original from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ the latest versionis currently 2.01.01a36 Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#447910: cdrecord: fails to re-write a DVD-RW disc error message cannot write medium
Hi, you are not using cdrecord but a bastardizd variant that does not really support to write DVDs. To verify a real problem, you would first need to upgrade to a recent version of the official source: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Make sure to install cdrecord suid root. Further hints: - Do not use dev=/dev/sr0, this is unsupported and deprecated usage. Cdrecord usually does not need dev= at all. If you have more than one drive call cdrecord -scanbus for proper dev= parameters. - If you continue to see problems, start with calling: cdrecord -v blank=full If the medium is in an unclean state, the drive may not like it. - If you still have problems, call cdrecord -atip to check the manufacturer and other information from the medium. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#446632: genisoimage: unable to merge images
This bug has been introduced by Debian. Upgrade to a recent original version from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ and it will go away. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#446668: genisoimage: Please add option to not cross filesystems
The original mkisofs includes the feature you like via the build in find(1) since 1.5 years: Get a recent original from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ and call mkisofs -find . -xdev Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#439296: brasero doesn't format fresh dvd+rw before burning
Brent S. Elmer, Ph.D. [EMAIL PROTECTED] wrote: I replaced wodim and family and made symbolic links to cdrecord and mkisofs as can be seen here: [EMAIL PROTECTED]:~$ wodim -version Cdrecord-ProDVD-ProBD-Clone 2.01.01a33 (i686-pc-linux-gnu) Copyright (C) 1995-2007 Jörg Schilling [1]+ Doneemacs brasero-session.log [EMAIL PROTECTED]:~$ genisoimage -version mkisofs 2.01.01a33 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2007 Jörg Schilling Looks like you did not replace mkisofs/genisoimage You did not use cdrecord! You did however still use other buggy software from the debian cdrkit package. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#439296: brasero doesn't format fresh dvd+rw before burning
Brent S. Elmer, Ph.D. [EMAIL PROTECTED] wrote: I'm not sure what you mean. Are these not the versions of cdrecord and mkisofs I should be using? I got them from the link in your email. Cdrecord-ProDVD-ProBD-Clone 2.01.01a33 (i686-pc-linux-gnu) Copyright (C) 1995-2007 Jörg Schilling mkisofs 2.01.01a33 (i686-pc-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2007 Jörg Schilling As can be seen from my wodim -version and genisoimage -version output, these are what wodim and genisoimage point to. I figured I had to do it this way with symbolic links since brasero would be explicitly calling wodim and genisoimage. If you definitely use a recent mkisofs, then your problem with Error: '/home/brent/backup/2007-09-04_12.30.05.790229.VTdebian.ful/ver' and '/home/brent/backup2/2007-09-04_12.00.03.243951.VTdebian.ful/ver' have the same Rock Ridge name 'ver'. is caused by inapropriate CLI parameters. If you merge more than one directory tree, you need to make sure that the merge will have different names for all files that go into the merge. The genisoimage that comes with wodim may give this message even in correct use cases. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#439296: brasero doesn't format fresh dvd+rw before burning
Ond??ej Surý [EMAIL PROTECTED] wrote: Joerg, please stop filling our BTS with comments which are useless for debian users. Please do not try to create confusion. I am helping people who believe that they use my software. This of course needs to include to inform people about bugs that are specific to forks found in some distributions but not in the original software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#439296: brasero doesn't format fresh dvd+rw before burning
Just upgrade to a original cdrtools version. Cdrecord auto-formats maiden dvd+rw since April 2004. Cdrecord does not have the bugs from wodim.. http://cdrecord.berlios.de/ If you are looking for a debian compatible package, look here: http://cdrecord.berlios.de/old/private/linux-dist.html#packages Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#436299: wodim: Simple way to get media type / maximum size
The feature you are looking for is available since a November 2006:
cdrecord dev=4,0,0 -minfo
Cdrecord-ProDVD-ProBD-Clone 2.01.01a32 (i386-pc-solaris2.11) Copyright (C)
1995-2007 Jörg Schilling
scsidev: '4,0,0'
scsibus: 4 target: 0 lun: 0
Warning: Using USCSI interface.
Using libscg version 'schily-0.9'.
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities :
Vendor_info: 'MATSHITA'
Identifikation : 'BD-MLT SW-5582 '
Revision : 'BDB2'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc-3 BD-R driver (mmc_bdr).
Driver flags : BD DVD MMC-3 SWABAUDIO BURNFREE
Supported modes: PACKET SAO LAYER_JUMP
Mounted media class: BD
Mounted media type: BD-R sequential recording
Disk Is not erasable
data type:standard
disk status: empty
session status: empty
BG format status: none
first track: 1
number of sessions: 1
first track in last sess: 1
last track in last sess: 1
Disk Is unrestricted
Disk type: DVD, HD-DVD or BD
Track Sess Type Start Addr End Addr Size
==
1 1 Blank 0 12219391 12219392
Next writable address: 0
Remaining writable size:12219392
Just call
cdrecord -minfo | grep Remaining writable size | awk '{ print $4 }'
Use a recent free original from:
http://cdrecord.berlios.de/
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#434742: a quick hack seems to work...
Peter Samuelson [EMAIL PROTECTED] wrote: [Joerg Schilling] Please do not try to ignore reality. The user I was responding was interested in cdrecord and not in a defective fork. Maybe you call it trying to convince our users to use your product instead; I call it spam. We don't do it to your users. Please stop doing it to our users. It is up to you: just stop using Debian channels to spread dissinformation on free original software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#434742: a quick hack seems to work...
Hi, it seems that you are a victim of a missunderstanding. You cannot expect support from a dead fork that did never do own code development. The official support mailing list for cdrecord is here: [EMAIL PROTECTED] and BTW: cdrecord supports the the feature you are intereested for a long time, just read the man page for cdrecord. There is no need to add a hack. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#434742: a quick hack seems to work...
Peter Samuelson [EMAIL PROTECTED] wrote: [Joerg Schilling] You cannot expect support from a dead fork that did never do own code development. Please stop spamming our users and our bug tracking system. We don't advertise our efforts on _your_ support channels. Kindly do us the same favor. Please just ignore us. If your theory is correct, we will eventually go away and you won't have to worry. Please do not try to ignore reality. The user I was responding was interested in cdrecord and not in a defective fork. You should not patronize your users but instead respect your users. Users like to have supported working software. Debian denies this to it's users. People from Debian still spread a lot of incorrect claims on the original software and as long as this disinformation continues, I need to inform people about reality. See also: http://cdrecord.berlios.de/old/private/linux-dist.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#434355: mkisofs recommendation is correct
mkisofs is the actively maintained original software. It makes no sense to advertize for defective forks like genisoimage that are based on obsolete code. Look into the debian bug tracking system to find a list of genisoimage bugs that are not present in the original. Here is the official program: http://cdrecord.berlios.de/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#429244: invalid Joliet table (was: genisoimage creates invalid iso images)
Julian Andres Klode [EMAIL PROTECTED] wrote: Am Samstag, den 14.07.2007, 22:13 +0200 schrieb Joerg Schilling: Hi, do not expect to get any useful answer/help for your Debian bugreport. The projct is dead. At least it does not violate against the GPL. BTW: I cannot see any problems with your data using a recent original software: Your software violates against the GPL, because it uses libscg which is under CDDL. And as a Fellow of the Free Software Foundation Europe and a proud Debian user, I will never use software which violates against the GPL. These kind of lies are boring! Get informed and do not spread lies that have been created by people with commercial interests. IF _you_ repeat the lies from a small numbers of OSS haters in Debian, _you_ are actively part of the defamation campaign. Cdrtools do not have any license problem. Inform yourself about the term work that the GPL is based on and read GPLv2 § 2 last paragraph. Also do NOT believe the incorrect GPL FAQ from the FSF that is completely based in the irrelevent term linking which does not appear anywhere in the GPL. The Debiam speudofork has been created out of hate and hate cannot create free software. BTW: YOU dod break a law by pulling a private mail into the public! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#426898: cpio can't extract files from the cpio -H crc archive
Hi, the cause for your problem is that the archive has not been written by cpio but most likely by GNU cpio. It seems that this archive ignores the fact that the official cpio program, see: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cpio/ always writes lower case letters for hex numbers. I added a workaround and released a new version of star: ftp://ftp.berlios.de/pub/star/alpha/ Please keep in mind that it is pure luck to report a bug to a Debian packet if the Debian maintainer did not update anything during the past 2 years. Better report it to the project itself. The current version of star is 1.5a82 Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#416270: star: segfault when using -data-change-warn option
Using this option in any way, even alone, causes star to crash. Backtrace follows : (gdb) run -data-change-warn Starting program: /bin/star -data-change-warn Program received signal SIGSEGV, Segmentation fault. 0x080704e0 in errflags () (gdb) bt #0 0x080704e0 in errflags () #1 0x08070755 in errconfig () #2 0x080503c2 in gargs () #3 0x080508ce in main () I cannot repeat this problem with a recent version of star: ftp://ftp.berlios.de/pub/star/alpha/ Note that the latest releast of star is 1.5a82. If you are able to repeat the problem with 1.5a82, compile the source with -g (see README.compile) and send the line number of the fault. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#306819: cdrecord: Problem with CUE files
DaVinci [EMAIL PROTECTED] wrote: El miércoles 13 de diciembre, Joerg Schilling escribió: Hi, your problem has been fixed! Check out the latest official cdrtools at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Thank you. But I don't know how this affect to Debian branch. Is that problem fixed too in woodim? The problem has originally been reported to cdrecord and it has been fixed in cdrecord. Wodim seems to be a dead end from an old cdrecord version. For this reason, it is not expected that the problem will be fixed in wodim. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Stephen Gran [EMAIL PROTECTED] wrote: I am aware of what the strings are used for. Can you point out the section of the license that says that copyright must be conveyed as a char string in the binary? I only see that it should be kept in the source file, which it is. Can you please demonstrate copyright breach, instead of continuing to repeat your wishes? It is interesting to see that Debian people on one side publish unsubstancial claims against my software and on the other side ignore explanations. You are mot allowed to remove Copyright notices that are part of the work. I recommend you to read the related law: http://transpatent.com/gesetze/urhg.html In special UrhG §13: § 13 Anerkennung der Urheberschaft Der Urheber hat das Recht auf Anerkennung seiner Urheberschaft am Werk. Er kann bestimmen, ob das Werk mit einer Urheberbezeichnung zu versehen und welche XX Bezeichnung zu verwenden ist. X and read the GPL (note that GPL §2 (c is also ignored by Debian..). And please do not try to have an endless discussion, I don't have the time to have endless discussions. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Stephen Gran [EMAIL PROTECTED] wrote: This one time, at band camp, Joerg Schilling said: You do not need to understand the background. You just need to remember that you are not allowed to remove Copyright information. This is a week sence I did inform you about the Copyright violation. Note that today, you have to either remove your project from the server or to undo the deletion of the copyright information. Please supply either an interdiff or a useable svn command tha shows that your copyright claims have been abused. svn diff -r1:2 /path/ would be fine. I am not sure what you mean.. If you did read the previous text yu did find this: http://svn.debian.org/wsvn/debburn/?rev=591sc=1 Is this what you like? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Stephen Gran [EMAIL PROTECTED] wrote: http://svn.debian.org/wsvn/debburn?op=comp[EMAIL PROTECTED][EMAIL PROTECTED] http://tinyurl.com/y9ld8g So, if this is in fact the problem that Joerg is talking about, there is no problem. No copyright notices have been removed. Some conditionally #defined static char's have been removed, but the copyright notices are intact. Unless someone can demonstrate copyrights have been removed, Could you please first inform yourself about what the code does? Please only continue this discussion if you understand the background. As I did already write several times, Copyright information has been removed that is intended to be compiled into the resulting binaries. I do not allow users to remove this kind of information. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
It turns out that I'd overlooked relevant sections in the documentation (Linux Notes in Chapter 4) and there is (or at least was) a way to use ATAPI interface. Still it doesn't work for me, and (thanks to Joerg pointing that out to us) it can be seen as a minor bug in wodim --- because it says, albeit in somewhat nondeterminate language, in its manpage wodim (1) that Looks like you did not check the recent cdrtools.. libscg now maps ATAPI (SCSI over ATA) to SCSI bus numbers 1000 ... 1025 Have a look at the latest cdrtools at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Note that recent mkisofs versions (part of cdrtools) include libfind and thus allow you to use the find(1) command line syntax in the mkisofs command line and that mkisofs now for the first time has backup stability and allows to create 100% accurate copies (the first time in the existence of mkisofs). Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Eduard Bloch [EMAIL PROTECTED] wrote: Developers can retrieve the copyright information in cdrkit easily. Users can retrieve the copyright information in cdrkit easily. Have I forgotten someone? You had the chance to ask me for the permission to remove this code. Instead, you decided to ignore the Copyright and removed Copyright related code without permission. You are not in the situation that allows you to discuss this topic, you simply don't have the right to remove Copyright notes. If you don't like to continue your Copyright violation, you need to undo this deletion. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
You do not need to understand the background. You just need to remember that you are not allowed to remove Copyright information. This is a week sence I did inform you about the Copyright violation. Note that today, you have to either remove your project from the server or to undo the deletion of the copyright information. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#403546: cedar-backup2: no way to configure cedar-backup to use ATAPI CD-RW recorder
Hi, the best way to deal with your problem is to just install an original version of cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ recent versions include a workaround to include the ATA drives in the SCSI namespace. This allows cdrecord to again find all drives via cdrecord -scanbus and to implement an auto-target mode that lets cdrecord/readcd/cdda2wav find the drive automagically if you omit dev= and if there is only one CD/DVD drive in the system. The original software did fix dozens of bugs in the close past and added many interesting features you might be interested in. ftp://ftp.berlios.de/pub/cdrecord/alpha/ is where active development and maintenance takes place. Wodim is just a frozen version from the past. Why make another program incompatible instead of using the software it was designed for? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Don Armstrong [EMAIL PROTECTED] wrote: I did already explain recisely what the problem is. I've read the logs, and I still have no idea what you're talking about. What information do you need? Let me spell it out the process even more clearly: 1) Send mail explaining precisely what the problem is. I already did this. 2) If the maintainer disagrees, appeal to the tech ctte to override the maintainer. The maintainer does not seem to be interested in the problem. If you believe you've done #1 then your only recourse is #2. At no point does this involve reopening bugs. Are you going to tell me that Debian has no way to deal with malicious or unwilling maintainers? Note that this is the only reason for the cdrtools dispute from Debian. See http://lists.debian.org/debian-devel/2006/12/msg00303.html for a recent post ex cathedra. The current problem is related to this piece of text from you: Maintainers, of course, should not capriciously close bugs or tag or block them nonsensically, and should attempt to explain why they are closing bugs or altering states wherever possible, but regardless of whatever inequities the maintainer has committed, using the control interface to argue with them will only result in your exclusion from it. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Peter Samuelson [EMAIL PROTECTED] wrote: [Joerg Schilling] I did give an example: use what(1) on a binary compiled from the source before and after the change to see the difference. If you did look at the SVN, if you did have a look at the most recent changes. it would be easy to understand what happened. We have removed a lot of _duplicate_ copyright notices from source files, as a cleanup. We have not removed copyright information from source files; it is still there, just not repeated 2 or 3 times per file, as it was in some cases before. This is wrong: You did remove _code_ that is intended to keep Copyright/version information in binaries. The removed text is needed in order to allow people to check the original version information and Copyright for all relevent files using the what(1) command. I am not aware of a single case in the past 25 years where someone did try to remove this kind of information. Users typically look for copyright notices in documentation and other materials that come with a package. (I note that the manpage we got Do not reason from your behavior on others. And speaking of my local Linux system, let me check for copyright notices in SCCS strings. The only user binaries aside from yours that embed copyright notices in that way are: iputils ping, netkit telnet, tcsh, aumix, vixie cron, gprof, lsof, util-linux pg, xdaliclock, and the ncftp suite. That is 11 packages (counting yours) out of over 1200 installed packages -- about 1%. By number of binaries it's on the order of 25 out of 2600 -- again, 1%. Noce to see that wou admit that nobody tries to remove this information in case it is present! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Sune Vuorela [EMAIL PROTECTED] wrote: On Saturday 16 December 2006 12:44, Joerg Schilling wrote: The removed text is needed in order to allow people to check the original version information and Copyright for all relevent files using the what(1) command. Until this bug, I had no clue about that what(1) existed. It does also only exist on a very few unix-derivatives. (some commercial ones and some of the bsd's) It is not my fault if you don't know enough about the POSIX standard. What is present on every commercial UNIX system and it is present on OpenSolaris. And if you did look a bit around you did find this: http://www.die.net/doc/linux/man/man1/what.1.html Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402456: Serious Copyright violation in cdrkit
Don Armstrong [EMAIL PROTECTED] wrote: On Sun, 10 Dec 2006, Joerg Schilling wrote: Stop abusing the Debian Bug tracking system! First and foremost, the maintainer(s) of a Debian Package are wholy responsible for determining the state of bugs assigned to their packages in the BTS unless overridden by the tech-ctte. If they did act in a responsible way, they would not remove copyright information and they would definitely not close a bug that has not been dealt with yet. Note that in former times, when claims against my software have been in the BTS that have been proven to be incorrect, the bug was still not closed. So it seems that some people at Debian abuse the BTS to act against certain people. Continuing to reopen bugs after they have been closed by the relevant maintainer will result in an exclusion from utilizing the BTS control interface. So please exclude Joerg Jaspert from the BTS who did close the bug many times although he knows that there are unhandled issues. If you believe the bug is being closed in error, then you should respond to the bug explaining precisely why there's a bug and what should be done to fix it, *without* reopening the bug. If you are unable to convince the maintainer(s) then your only recourse is to attempt to convince the tech-ctte to override the maintainer(s). I did already explain recisely what the problem is. What information do you need? As a final note, the Debian BTS is for reporting issues in Debian packages, not unpackaged or versions not distributed by Debian. Those issues should be brought up with the people responsible for the packages using whatever mechanism they utilize, not the BTS. This looks like a cheap excuse. Please note that we are talking about a Copyright violation on svn.debian.org Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402187: CUE is not broken
I was running in the same problem as described here, but mine is a bit different. After trying Mr. Schilling's last cdrecord version, things improved, but now I have this instead: [snip] 2005.cue: line 1: TITLE: command not found 2005.cue: line 2: SONGWRITER: command not found 2005.cue: line 3: PERFORMER: command not found 2005.cue: line 4: FILE: command not found 2005.cue: line 5: TRACK: command not found 2005.cue: line 6: PERFORMER: command not found 2005.cue: line 7: SONGWRITER: command not found 2005.cue: line 8: TITLE: command not found 2005.cue: line 9: INDEX: command not found 2005.cue: line 11: FILE: command not found 2005.cue: line 12: TRACK: command not found 2005.cue: line 13: PERFORMER: command not found 2005.cue: line 14: SONGWRITER: command not found 2005.cue: line 15: TITLE: command not found 2005.cue: line 16: INDEX: command not found [snip] Well, you cannot write CDs using /bin/sh or similar programs :-( The messages from above are error messages from bash, they are definitely not from cdrecord! Here is the command I used: /opt/schily/bin/cdrecord -pad -tao -driveropts=burnfree,audiomaster,hidecdr -speed=1 cuefile=2005.cue -eject -v If you really use this command line, you get the following error message from cdrecord: cdrecord: The cuefile= option only works with -sao/-raw. Usage: cdrecord [options] track1...trackn Use cdrecord -help to get a list of valid options. Use cdrecord blank=help to get a list of valid blanking options. Use cdrecord dev=b,t,l driveropts=help -checkdrive to get a list of drive specific options. Use cdrecord dev=help to get a list of possible SCSI transport specifiers. Here are the contents of the file 2005.cue: TITLE XXX SONGWRITER XXX PERFORMER XXX FILE 1.wav WAVE TRACK 01 AUDIO PERFORMER XXX SONGWRITER XXX TITLE XXX INDEX 01 00:00:00 FILE 2.wav WAVE TRACK 02 AUDIO PERFORMER XXX SONGWRITER XXX TITLE XXX INDEX 01 00:00:00 [snip] This is a valid CUE file since I used it under demo version of CDRWIN and it worked fine. This CUE file works fine with cdrecord too! I recommend you to fetch the latest source archive from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ compile it and use this binary instead of bash... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#369676: cdrtools: [mkisofs] option `-rJf' is ambiguous (but accepts -frJ)
Eduard Bloch [EMAIL PROTECTED] wrote: This is not related to my text above and mkisofs _does_ give an error message. The problem I was referring to above will cause that string options will silently get wrong parameters. And BTW: getargs allows you to contol the behavior - GNU getopt_long does not ;-) Bullshit. Try a random program, eg. Looks like you start with your usual fecal diction as you always do when your subconsciousness already knows that you lost the case. $ ls --color=asdf ls: invalid argument `asdf' for `--color' Valid arguments are: - `always', `yes', `force' ... $ ls --color-opt-does-not-exist=asdf ls: unrecognized option `--color-opt-does-not-exist=asdf' As I already told you: I did never asume that you know CLI basics. This is completely unrelated to the supposed problem you found with mkisofs. Instead of abusing the Debian Bug tracking System for your personal flame wars, you should try to learn how CLI parsers work e.g. by reading the getopt/getargs related section in: ftp://ftp.berlios.de/pub/star/STARvsGNUTAR Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#289479: cdrecord: burning the same audio track twice fails
Hi, your problem has been fixed some time ago Try out the latest official cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#306819: cdrecord: Problem with CUE files
Hi, your problem has been fixed! Check out the latest official cdrtools at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#267233: cdrecord: Only -dao and -sao accepted when using cuefile
Hi, a lot of new features have been added to cdrtools during the past two years. RAW mode writing for the CDRWIN CUE file mode has been added recently and supports already nearly all sector types. Please test the latest cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ and report whether your case is now working. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#369676: cdrtools: [mkisofs] option `-rJf' is ambiguous (but accepts -frJ)
Package: mkisofs Version: 4:2.01+01a03-5 Severity: normal There is bug in options handling. It should not matter in which order the options are given. See below for demonstation. -rJf ERROR -frJ ok Hi Jari, your problem is caused by a bug in the option parser (GNU getopt_long). The mkisofs version you are using is very old ( 1.5 years). Three months ago, mkisofs has been converted to use the more mature and older (starting 1982) getargs(). This change fixed your problem and many other conceptional bugs from GNU getopt_long. GNU getopt_long is e.g. unable to correctly deal with miss-spelled long options in case that the miss-spelling occurs after the shortest common part of the option name. Check out the recent version of mkisofs in cdrtools at: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#369676: cdrtools: [mkisofs] option `-rJf' is ambiguous (but accepts -frJ)
Eduard Bloch [EMAIL PROTECTED] wrote:
your problem is caused by a bug in the option parser (GNU getopt_long).
The mkisofs version you are using is very old ( 1.5 years). Three months
ago, mkisofs has been converted to use the more mature and older (starting
1982)
getargs(). This change fixed your problem and many other conceptional bugs
from GNU getopt_long. GNU getopt_long is e.g. unable to correctly deal
with
miss-spelled long options in case that the miss-spelling occurs after the
shortest common part of the option name.
Maybe. Or maybe not. The big wrapper added by somebody (most likely you)
around getopt action needs to be examined to say that for sure.
But what does your superiour stuff do with miss-spelled options?
$ mkisofs/OBJ/i686-linux-cc/mkisofs
-input-charset-deliberate-mistake-but-with-correct-parameter iso8859-1 -o
/dev/null .
I was never expecting that you understand CLI basics
This is not related to my text above and mkisofs _does_ give an error message.
The problem I was referring to above will cause that string options will
silently get wrong parameters. And BTW: getargs allows you to contol the
behavior - GNU getopt_long does not ;-)
Just check:
{{input-charset*, icharset },
---
{{input-charset* , icharset },
And the encoding beeing default on Linux nowadays (UTF-8) is
still not in the list. Those who want an isofs generator that cares about
the user's setup (eg. detecting the charset encoding and supporting
Unicode/UTF-8 input) can use genisoimage from http://www.cdrkit.org/.
It makes sense to not have a broken feature and to wait for a correct solution.
It is being worked on decent and correct UTF-8 support for mkisofs. This will
come soon. The UTF-8 implementation that is used in cdrkit has been rejected
for mkisofs because of serious bugs and because it's creators did refuse to
fix these bugs.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402199: burn: Please replace cdrecord with wodim
The burn package has dependencies on packages of cdrecord. It would be best if burn's dependencies were changed to wodim | cdrecord and genisoimage | mkisofs to allow it to work with the DFSG-compliant cdrkit fork. Presumably no changes to the actual code would be necessary. Please inform, yourself and then judge again The original (cdrtools) is doubtlessly free software and even Debian did recently did admit this fact, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350624 The fork you are talking about, on the other side repeatedly violates Copyright laws. Do you still like Debian to switch from Free original Software to a questionable fork? As a note: The fork maintainers just started another attempt to remove Copyright notices without permission from the Author. Debian should not depend on a fork whose maintainers did not yet grok the rules of OSS. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#402187: cdrecord: Only one FILE allowed on line 5 in 'zeta.cue'.
Hi, check the latest 2.01.01a23-pre in ftp://ftp.berlios.de/pub/cdrecord/alpha/. It contains an enhanced CUE sheet parser that allows you to write the Zeta CD. Note that it is pure luck that I did see your report. Sending Bugs reports to Debian is a bad idea as Debian does not forward these reports and as there is no development/maintenance at Debian. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#401553: gnomebaker: Fails when directory depth is greater than 6
Goedson Teixeira Paixao [EMAIL PROTECTED] wrote: Em Qua, 2006-12-06 Ã s 00:37 +0100, Joerg Schilling escreveu: Applying the patch in the attachment is all that's needed to (always) use -iso-level 4. I'll work on a better patch that will adapt the options used according to the depth of the tree, so that we have an image as backward compatible as possible, without limiting the the kind of data the user adds to the disc. This is a bad idea as not all OS properly deal with ISO-9660:1999 (not only DOS). Using -D should be an exception. What I intend to do is use -iso-level 4 when the tree is deeper than allowed by ISO9660:1988 and -iso-level 3 otherwise. Is this right? Or is there an option to produce ISO9660:1988 compatible CDs with deeper trees? It is unclear what you like to do. If you use pure ISO-9660, the only way to handle deep trees is ISO-9660:1999. But people usually use Rock Ridge extensions. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#401553: gnomebaker: Fails when directory depth is greater than 6
Goedson Teixeira Paixao [EMAIL PROTECTED] wrote: Em Ter, 2006-12-05 Ã s 14:45 +0100, Joerg Schilling escreveu: Before you sare starting to guess about possible reasons, I recommend to upgrade to a recent mkisofs ftp://ftp.berlios.de/pub/cdrecord/alpha/ and test again ;-) Hi Joerg, Thank you for your input. But I believe it won't be necessary to upgrade to a newer mkisofs and I'm not sure it would produce any different output. The current mkisofs in Debian is capable of creating ISO images with deeper trees. The problem here is our selection of options we pass to mkisofs when creating the ISO image. If we used -iso-level 4 or -D there would not be this problem, but we would be risking compatibility with older ISO9660 implementations (MS-DOS?). Applying the patch in the attachment is all that's needed to (always) use -iso-level 4. I'll work on a better patch that will adapt the options used according to the depth of the tree, so that we have an image as backward compatible as possible, without limiting the the kind of data the user adds to the disc. This is a bad idea as not all OS properly deal with ISO-9660:1999 (not only DOS). Using -D should be an exception. Please note that future k3b versions will not use -D anymore if they detect a recent mkisofs. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#401553: gnomebaker: Fails when directory depth is greater than 6
Before you sare starting to guess about possible reasons, I recommend to upgrade to a recent mkisofs ftp://ftp.berlios.de/pub/cdrecord/alpha/ and test again ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#395010: k3b: failure to write audio cdr's
Yor problem is caused by either a Linux kernel bug or by a defective libscg in the Debian fork of cdrtools. I recommend to first uograde to a recent version of cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ if the error /usr/bin/cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 02 1C 00 00 1B 00 status: 0x0 (GOOD STATUS) persists, you need to talk to the Linux kernel maintainers as GOOD STATUS is an impossible return code for a non-buggy kernel in your case. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#401556: DVD Burn Fails with strange behavior
If you are having problems with DVD writing, I recommend to upgrade to a programt hat supports DVD writing: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#397478: sdd: FTBFS: /bin/sh: incs/x86_64-linux-cc/Inull: No such file or directory
Daniel Baumann [EMAIL PROTECTED] wrote: Joerg Schilling wrote: Please read the DFSG, if you believe that you cannot do this, then the License that might prevent it is not a free license acording to DFSG. this is not the place to discuss this again. cdrtools are purged from Debian, you can't influence the decission anymore. please note that i kindly requested a new sdd release with updated build-system. you can relicense the whole thing to CDDL as you did with sfind, we have no problem with that. I did try to tell you where you are wrong It was not my decision to start a discusion based on incorrect claims, but it is ibvious that I need to correct them. Maybe this helps: The GPL was called non-free by the OSI (opensource.org) until a few years just exactly because ot this missinterpreting of the GPL. Then the FSF did aproach OSI and verified that the GPL definitely does not have the requirements to put everything under GPL. It is not my fault that a few people at Debian did not yet get this. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#397478: sdd: FTBFS: /bin/sh: incs/x86_64-linux-cc/Inull: No such file or directory
Daniel Baumann [EMAIL PROTECTED] wrote: Joerg Schilling wrote: The program 'sdd' and The Schily Makefile system are independent projects (GPL speech: works). As the GPL is an OSI aproved license, it must not contaminate other projects like The Schily Makefile system, so there is no problem with taking a recent makefilesystem and combine it with an old sdd. As you know, this is not possible in Debian. Why? Because some strange people decided to ignore Debian rules? You (yourself) did take the project independend make code from a different project's tarball. Maybe, you should just educate those people inside Debian who did not understand DFSG § 9. Note that your problem would not be present if you did use smake to compile as smake includes auto make features that allow compilation on previously unknown platforms. It seems, that we'd like to get rid of smake, hence I did intentionally not using it. The problem with GNU make is that it is de-facto unmaintained. A bug that I reported in 1999 and that has been accepted as very important bug still has not been fixed in GNU make! This is why I cannot rely on GNU make and need a working and highly portable make program. This is smake. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#397478: sdd: FTBFS: /bin/sh: incs/x86_64-linux-cc/Inull: No such file or directory
Daniel Baumann [EMAIL PROTECTED] wrote: Joerg Schilling wrote: You (yourself) did take the project independend make code from a different project's tarball. Maybe, you should just educate those people inside Debian who did not understand DFSG § 9. for a patch, there is nothing problematic with it. but including it into another project with another, incompatible license, isn't ok. Please read the DFSG, if you believe that you cannot do this, then the License that might prevent it is not a free license acording to DFSG. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#392342: Release critical
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Martin Vlk [Fri, Nov 10 2006, 12:18:15PM]: Hi, I wonder should this bug's priority be rised so that it is fixed before etch? The tool is unusable like that so it is a pretty serious bug. Why do you ask us? Ask Joerg Schilling, he does want that shit to be printed, even sabotaging the program. He has the copyright and he does not allow to remove the problematic parts. Nobody except Eduard Bloch and his Friends are sabotaging cdrtools. At Debian, a working build system has been recently replaced by something that does definitely not work (*), the code Mr. Bloch complains abut looks like a useful hint to the users that something might be wrong. *) Most of the (autoconf/configure) tests have been replaced by static defines that may be valid on Mr. Bloch's home system but are wrong on the majority of the systems out in the world. Instead of using the broken Debian speudofork, you still have the choice to use the working free original software: Just fetch the latest source from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ compile and install (suid root as documented) and you have an installation that lacks all Bugs listed on the Debian bugtracking system that are not a result of Linux kernel bugs. Note that the code, Mr. Bloch complains about has been negotiated with Debian (in order to protect cdrtools users) in 2001 after a similar speudo fork appeared (initiated by a former Redhat employee). The current speudo fork found on Debian so far seems to replicate all problems seen in 2001: 1) The working official build sytstem has been replaced by a defective one 2) The initator spend some months in trying to fix the self caused problems 3) The project became catatonic after ~ 6 months. No own intellectual creation has ever been added to this project. The Debian speudo fork is currently in stage 2) ... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#381783: star: gnutar does not handle -C dir option
The option -C dir is not processed by star_fat, may its a good idea not to create the link from /bin/gnutar to /bin/star_fat unless this option works. Gnutar is often used in Makefiles and if -C source won't work the make failed. This is not true: star of course handles the -C option. The -C option works with normal tar. Normal tar implements -C only in create mode, star allows to use -C also in extract mode. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#397478: sdd: FTBFS: /bin/sh: incs/x86_64-linux-cc/Inull: No such file or directory
Daniel Baumann [EMAIL PROTECTED] wrote: the attached patch adds the needed rules to build succesfully on amd64. However, I took it from sfind which ships a more updated rules-set. Unfortunately, it is licensed under CDDL only, and sdd is GPL only, hence the patch is incompatible. Don't be afraid: The program 'sdd' and The Schily Makefile system are independent projects (GPL speech: works). As the GPL is an OSI aproved license, it must not contaminate other projects like The Schily Makefile system, so there is no problem with taking a recent makefilesystem and combine it with an old sdd. Note that your problem would not be present if you did use smake to compile as smake includes auto make features that allow compilation on previously unknown platforms. Joerg, could you please release an updated version of sdd (if GPL or CDDL doesn't matter)? I am currently worting in a fix for a star bug that has a higher priority. I'll see what I can do. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#396599: wodim: ..conflicts with cdrecord on /usr/share/man/man1/readcd.1.gz
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Joerg Schilling [Thu, Nov 02 2006, 10:49:41AM]: Hi, Debian now has the chance to verify whether they intend to create a fork or whether they just like to do malicious agression If they like to create a true fork, they should finally rename _all_ The top priority while creating a true fork is getting rid of confusing contents and potential lies in the visible program output. Then I encourage you to first remove the lies against cdrtools that are spread on the wodim web page and in the archives. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#396599: wodim: ..conflicts with cdrecord on /usr/share/man/man1/readcd.1.gz
Hi, Debian now has the chance to verify whether they intend to create a fork or whether they just like to do malicious agression If they like to create a true fork, they should finally rename _all_ programs from cdrtools. If this doesn't happen, it is obvious that there never was an intention to create a fork and the intention was rather agression. The names in question are at least: libscg, cdrecord, mkisofs, isoinfo, isodump, isodebug, readcd, cdda2wav, scgcheck. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#389033: xcdroast: no more dvd burning
The title says it all. After a Sid dist-upgrade I burned 3 coasters. Thought it was a bad batch of disks, got a new pack, another coaster: -- Device returns wrong startsec -- Burn-free switched on, later off -- trying to mount the coaster gives wrong fstype If you like to get a working cdrecord with DVD support, you need to get the original from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Compile it yourself and install it suid-root. Suid-root is needed in order to make cdrecord work correctly on newer Linux kernels. This probably has something to do with the conflict between the open source community and Joerg Schilling. He may be a difficult person, but at least As I am a member of the Open Source community, it is obvious that there cannot be such a conflict. There is however a conflict between the Open Source community and Debian caused by the fact that Debian does not like to accept decisions made by the Open Source community... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#389033: xcdroast: no more dvd burning
Jan Willem Stumpel [EMAIL PROTECTED] wrote: Joerg Schilling wrote: As I am a member of the Open Source community, it is obvious that there cannot be such a conflict. There is however a conflict between the Open Source community and Debian caused by the fact that Debian does not like to accept decisions made by the Open Source community... Interesting.. I wonder how this will work out. This kind of conflict (legal hair-splitting in the absence of any real legal problems) is getting a little bit too frequent to my taste, nowadays. It has already killed dosemu. I do not know which side is right. It is just a pity that good work goes to waste. I don't know why as I only made my code more free What I see is that people get confused by the current dispute and that many people will have to live with an outdated version of cdrtools on Debian. In the meantime, I'll continue to use your old version (in Debian Sarge) which works well. Many thanks for writing it. I still recommend to use a recent original version as Debian did not update cdrtools since mid-2005 and a lot of things did change since then. cdda2wav has been overhouled and a lot of small bugs have been fixed. readcd has a reed-solomon correction lib inside cdrecord: DVD-Support now OSS Supporting DVD+R/DL with layer break Supporting DVD-R/DL Work around NEC DVD speed reporting bugs Work around Pioneer DVD+ fixaton bugs Comming soon: DVD multi session And mkiksofs now support the find(1) syntax (including mkisofs graft point syntay) to the right of a -find option and a lot fo smaller bugs have been fixed. All this has been done since May. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#382578: cdrecord: possible file I/O operation without error checking
Your report is not really useful as it does not mention what hapens. For a real bug report, you need to report the problem in a tracable way: http://cdrecord.berlios.de/old/private/problems.html Trying to guess what you may want so say. If your problem is that there is an error condition without an error, file a bug report against the fread(3) implementation on your OS. fread() is not allowed to set the ferror() condition in case that there is no read error. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377421: cdrecord in sid fails to burn cds via the /dev/cd... interface
Michelle Konzack [EMAIL PROTECTED] wrote: Am 2006-07-09 13:48:14, schrieb Joerg Schilling: Eduard Bloch [EMAIL PROTECTED] wrote: ftp://ftp.berlios.de/pub/cdrecord/alpha/ have been verified to work correctly when installed suid-root on Linux and Linux definitely requires cdrecord to be run with root privileges in order to be able to use all needed SCSI commands. I do not like wars under Developers, but on my System I was not able to get the Debian version running as under Woody. I am just a vitim of this war too. I cannot influence the fact that interfaces are mofified. Not with my Teac CD-R55S not with my ASUS Combo CD/DVD. With the nonstandard SCSI commands the CDR-55S needs, there is a big chance that te Linux Kernel filters them out if sou are not root. Now I will try your original version... The last time I checked this kind of drives is 5 years ago Inform me if you have problems. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#374685: Debian bug #374685: cdrecord and suid privs
Kapil Hari Paranjape [EMAIL PROTECTED] wrote: I think I understand what you are saying: The problem is that changes in the Linux interface force you to ask Linux users to install the program setuid in order to be sure to test all the possible difficulties that may arise when writing a CD/DVD. As a result of your work on this program, CD/DVD writing has become dependable on a huge number of different platforms and drives. You do not want this achievement to be watered down in any way. So, what I would like is that the Debian version of cdrecord be (re)patched minimally so that it: (a) Produces behaviour essentially identical to your upstream version in case the program is installed suid or is run as root. (b) *Can* be installed and run non-setuid root---for the paranoid amongst us. Such system administrators should be WARNED that they *may* produce coasters and that the better way is to install the program as you have suggested. This is not a solution do you believe that you don't need door in the elevator shaft because sometimes when you step in, there is an elevator at your storey? If you like to make cdrecord work, you _need_ to install it suid root or to make it 0700 owned by root, so only root may call it. I believe such a patch is possible and is essentially available in the BTS. I also understand that you might consider (b) to be a watering down of your work and thus unacceptable to you. I did not see any patch that makes sense, only some patches that try to hide the problems and thus create more problems than already present. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#310689: cdrecord -dev=ATA: -scanbus
Maximiliano Curia [EMAIL PROTECTED] wrote: I was unable to reproduce with the latest version of the Debian cdrecord package. Be careful, the Debian package is rottemn in many aspects. It contains several Debian introduced bugs that _partially_ cancel each other. I recommend to test the original: ftp://ftp.berlios.de/pub/cdrecord/alpha/ latest version is 2.01.01a11, it also contains the features that Debian likes to hide from its users Note that you _need_ to install cdrecord suid root! If _cannot_ work correctly otherwise. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#374685: Debian bug #374685: cdrecord and suid privs
Kapil Hari Paranjape [EMAIL PROTECTED] wrote: Here is my understanding of the situation of cdrecord with Linux 2.6.x. Please correct me if I am wrong. cdrecord will (perhaps with minor modifications) be able to write CD's without root privileges for a user with access to rw the relevant drive. However this will lead to greater chances of errors in the CD's written. I am not sure if I understand you the right way, but the facts are: - On previous Linux versions, it was possible to make cdrecord work without root-privs in case you did compromize security on that system and in case you did not care about coasters or write quality. - With Linux 2.6.x, it is impossible to run cdrecord without root provs. Do not believe single persons who claim otherwise as Linux-2.6.x filters away random SCSI commands when cdrecord does not have root-privs and as cdrecord heavily depends on the fact that the SCSI protocol depends on SCSI commands that fail because they are not supported by the actual drive in order to correctly support the features of the actual drive. It is definitely impossible to support correct DVD writing without having root-privs. - Recent cdrecord versions (see ftp://ftp.berlios.de/pub/cdrecord/alpha) include workarounds for the incompatible interface changes on recent Linux versions and allow you to use cdrecord in case it has been installed suid-root. - The latest cdrecord version on Debian is definitely broken. My suggestion is: - get a recent copy of the original cdrtools source from ftp://ftp.berlios.de/pub/cdrecord/alpha and compile it. - Install the cdrecord/cdda2wav/readcd binaries suid root. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#329843: [Bug-tar] Check nano seconds (nsec) to accurate; extract of sym-links fails
Paul Eggert [EMAIL PROTECTED] wrote: Joerg Schilling [EMAIL PROTECTED] writes: While it is no problem to set time stamps from the nsec fields in the archive, it is unclear how to deal with them when doing time stamp compares. Surely the best currently-practical answer is to truncate the full-resolution time stamps to the file system resolution before doing the comparison. But there is no practial solution to get the file system time resolution. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#329843: [Bug-tar] Check nano seconds (nsec) to accurate; extract of sym-links fails
Paul Eggert [EMAIL PROTECTED] wrote: That sounds too strong. Sometimes 'tar' should ignore the nanoseconds, and sometimes not. That is why CVS tar has both a timespec_cmp function and a tar_timespec_cmp function, for example. I have no good idea how to deal with nanoseconds correctly since I introduced them 10 years ago in star. Nsecs have been activatd 5 years ago with POSIX.1-2001 support While it is no problem to set time stamps from the nsec fields in the archive, it is unclear how to deal with them when doing time stamp compares. The main problem seems to be missing feature in POSIX as you need to know the time stam granularity of the local filesystem if you like to implement comparisons correctly. Note that the low-carb (aehm... FAT) filesytem only implements a granularity of 2 seconds, so it is not even correct to believe in a one second granularity. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377109: Bug#350739: #350739: cdrecord status?
Joerg Schilling [EMAIL PROTECTED] wrote: You started this thread and you have been unable to prove your claims. I ask you to either prove your claims or to close the bugs #350739 #350739 within one week. Thank you for admitting that your previsous claims are wrong. Not that you did admit that your claims have been pointless, I urge you to close the bugs #350739 #350739 within 2 days. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377109: Bug#350739: #350739: cdrecord status?
Joerg Schilling [EMAIL PROTECTED] wrote: You again make the wrong conclusions and I get the impression that you need to read the GPL more thoroughly in order to understand the way I interpret it. The main missunderstanding seems to be caused by reading GOL §2 b) too quickly. this is why I try to explain it to you in detail below. Hi Don, you did not reply to my last mail, so it is obvious that you have no arguments to prove the claim that cdrtools has license problems or may be undistributable by Debian. As you did start the current discussion, I believe that you should draw the conclusions and close the Debian bugs 350739 and 377109 as soon as possible. Best regards Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
** You should start to learn about the nettiquette and not shorten the Cc: list! Otherwise people will believe that you have something to hide ** Don Armstrong [EMAIL PROTECTED] wrote: On Tue, 11 Jul 2006, Joerg Schilling wrote: you did not reply to my last mail, so it is obvious that you have no arguments to prove the claim that cdrtools has license problems or may be undistributable by Debian. I have not responded because they do not raise any issues which are of any interest to me, nor do they adequately address the crux of the argument as presented in the two paragraphs in [EMAIL PROTECTED]. [1] I did reply to you and tell you why your claims are wrong. You are continuously completely missinterpreting the GPL: You are mixing different parts of the GPL and incorrectly claim that a restriction that applies to a specific part of the GPL also applies to other parts of the GPL. This is obviously wrong! Only restrictrions that are explicitly mentioned in a specific paragraph are applicable to this specific paragraph... I do not have copious amounts of time to spend discussing oversimplificiations of the licenses with you; if you can distill your arguments into a short, well formulated message that precisely explains why the clauses I have identified do not conflict with appropriate verbatim inclusions of the clauses and why you interpret them that way, and citations of case law,[1] I will respond. YOU did start this thread and you forced me to spend a lot of time with it. YOU have been unable to prove any of you claims so far. YOU need to either continue this thread and prove your claims or admit that your claims are wrong. If you do not prove your claims, we need to asume that you admit that your claims are not true. You seem to completely missunderstand this case: It is not me who need to prove that there is no problem but YOU need to prove that there _is_ a problem. 2: This means court cases which illustrate the point that you're trying to prove, preferably in the US, not websites that claim German law actually applies to the US without case law indicating the precise depth thereof. I told you more than once that German law applies to cdrtools. US courts are obviouisly not relevent. But again: this is irrelevent. You started this thread and you have been unable to prove your claims. I ask you to either prove your claims or to close the bugs #350739 #350739 within one week. Best regards Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
George Danchev [EMAIL PROTECTED] wrote: Why do you say that ? This main problem is the distribution of the binary (Executable Versions) form! There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... CDDL 1.0 says: 3.5. Distribution of Executable Versions. ... the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. So someone must decide the license of the distribution of the Covered Software in Executable form. Also this sort of indemnification is insane, but that is perfectly clear. I don't think Debian can fulfil the requirements of this License (CDDL 1.0) because of indemnification mentioned above (at least) for the Executable form of the Covered Software (1.4. Executable means the Covered Software in any form other than Source Code.) You have been very unclear with your text, so I may only comment the part where you have been unambiguous. If Debian is in fear of the last two sentences from CDDL §3.5, then I see only one possible reason: Debian is planning to distribute the binary in a way that causes harm to the original developer or contributors. This gives a deep look inside Debian. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
First an important note: you seem to like to manipulate things as you intentionally shorten the Cc: list. Please don't do this anymore, it is very bad practice George Danchev [EMAIL PROTECTED] wrote: There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... You must give the licensee a copy of GPL: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. You make the same mistake as many other people do This part of the GPL is not related to binary distributions, otherwise it would mention binary distribution. Binary distribution is only mentioned in §3 of the GPL. As I pointed out previously, the CDDL does not enforce any additional restriction on the GPLd source code. But CDDL imposes further restrictions which are incompatible with GPL. This is wrong, see above. You are changing your positions way too fast. In a previous message you said: cite1Both, the CDDL and the GPL are _source_ licenses. /cite1 You are wrong here too I do not change my position but I present a clear line of arguments. On the other side, I am constantly whiping out wrong claims and I am treatened with hourly changing strange positions from people in this list. Now you write: There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... Which is correct and you did not prove the converse. Your only sane choice is to dual license the whole projects of yours under CDDL and GPL. Thus licensees either accept the CDDL and ignore GPL, or accept GPL and ignore CDDL for both the source code and executables. This is what people like you like, but fortunately this is not needed. CDDL 1.0 says: 3.5. Distribution of Executable Versions. ... the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. So someone must decide the license of the distribution of the Covered Software in Executable form. Also this sort of indemnification is insane, but that is perfectly clear. I don't think Debian can fulfil the requirements of this License (CDDL 1.0) because of indemnification mentioned above (at least) for the Executable form of the Covered Software (1.4. Executable means the Covered Software in any form other than Source Code.) You have been very unclear with your text, so I may only comment the part where you have been unambiguous. You imply that CDDL is unclear and ambiguous (since my text was being parts quoted from the CDDL and I think it has very clear wording. Wrong again and I suspect that you opnly like to deflect people from the main problem. If Debian is in fear of the last two sentences from CDDL §3.5, then I see only one possible reason: Debian is planning to distribute the binary in a way that causes harm to the original developer or contributors. It boils down to how this hypothetical harm would be claimed and interpreted in your jurisdiction after user accepts your CDDL choice-of-venue-patched license. That's it is not acceptable for me as an end user. This is complete nonsense! This gives a deep look inside Debian. Fix your baseless squint looking then. You seem to have very strange ideas. The CDDL §3.5 does nothing in the last two sentences but to inform possible distributors of binaries about the lawful rights of the author. It requires a redistributor to accept these lawful rights in advance to a distribution. This makes it easier for the author to defend against evil-minded distributors. Unless you _are_ such a evil-minded distributor, you have nothing to frear from this clause Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
Joerg Schilling [EMAIL PROTECTED] wrote: George Danchev [EMAIL PROTECTED] wrote: There is no problem with distributing executables as the CDDL and the GPL do not require contradictory conditions... You must give the licensee a copy of GPL: 6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Let me add some notes to avoid further confusion and missunderstandings: - You cannot take arbritary words from one part of a license and combine them with arbitrary words from other parts of the license to create the license you like to read. - You need to carefully read a license exactly the same way it has been written, sentence by sentence, word by word. - Any case not mentioned explicitly in the license is either covered by more permissive parts of the license or (if not applicable) by the law - in our case the German Urheberrecht. - The GPL §1 is a permissive clause that nearly catches all conditions. CDDL 1.0 says: 3.5. Distribution of Executable Versions. ... the Source Code form from the rights set forth in this License. If You distribute the Covered Software in Executable form under a different license, You must make it absolutely clear that any terms which differ from this License are offered by You alone, not by the Initial Developer or Contributor. You hereby agree to indemnify the Initial Developer and every Contributor for any liability incurred by the Initial Developer or such Contributor as a result of any such terms You offer. A similar clause (although less clearly written) is in the Preamble of the GPL. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377109: Bug#350739: #350739: cdrecord status?
Erast Benson [EMAIL PROTECTED] wrote: Joerg position is clear: It may be the main point that people fear that compiling cdrtools creates unredistibutable binaries. I see no reason why binaries may be unredistibutable as I don't see any contradictory requirements from CDDL/GPL. Both licenses are source licenses and require to make the source available in case a binary is distributed. This is no contradiction but just the same requirement. I would like to hear FSF position on this matter and somehow I have a feeling their interpretation of GPL license is different from what is claimed here. Eben Moglen, General Counsel for the Free Software Foundation, noted that he always believed that GPLv2 should be interpreted in the way GPLv3 now makes explicit. Thank you Erast for pointing this out. The main problem that prevents people to understand the GPL correctly, is that there are too many wrong interpretations in the net and even the FAQ from the FSF is not 100% correct. The main weapon of a lawyer or person who works on contracts is the word. If you like to play in that league, you need to be able to deal with that weapon! In other words, you need to read the GPL carefully and thoroughly many times until you understand every corner of the text. Sometimes I get the impressuion that native English speakers don't do that because they believe that they understand what they read in the first attempt. It is obvious that the FSD does (at least internally) not have a different understanding of the GPL [1]. It may however be wrong to ask e.g. RMS because he is known to reply in unusable ways on similar questions. He either points to the FSF GPL FAQ (which is not 100% correct) or even answers in a oracle. The best idea is to ask Eben Moglen, he is university professor on law and I know from previous private conversations with him that he answers in a useful way when asked specifically. [1] Note that in case that the FSF would not agree with my interpretation of the GPL (the GPL is a asymmetric license that allows GPL projects to use non-GPL code), the FSF would definitely sue Veritas. Veritas does the same with GNU tar since many years and as it seems that RMS believes that GNU tar is some kind of crown jewels of the FSF. It is most unlikely that the FSF would tolerate a GPL vilolation for GNU tar. I am in hope that people from Debian read the GPL several times thoroughly before we continue the discussion. I am sure that they then agree with me. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377421: cdrecord in sid fails to burn cds via the /dev/cd... interface
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Joerg Schilling [Sun, Jul 09 2006, 01:41:04AM]: Hi, your problem is caused by the fact that the Linux kernel is made incompatible to itself faster than Debian updates cdrtools (Debian did not update cdrtools for more than 14 months). The last thing has another reasons and not some assumed Linux kernel incompatibilites with itself. You know the reasons, stop claiming something else please. Eduard, you are uninformed! Stop your bashing and inform yourself before writing nonsense. The relevent incompatible interface changes in recent Linux kernels are: - Instead of fixing the bug that allowed anyone to send arbitrary SCSI commands to CD/DVD-recorders (caused by not requiring write permission on the node), the behavior of SCSI generic was changed (in 2.6.8.1). Old behavior: open device as root and send commands as user. New behavior: open device as user and send commands as root. - Some time between January 2006 and 2004, a new rlimit RLIMIT_NOFILE was added and implemented in a way that is not compatible to previous kernel behavior. Old behavior: mlockall(MCL_CURRENT|MCL_FUTURE) done as root was honored for the same process if later continued as user. New behavior: mlockall(MCL_CURRENT|MCL_FUTURE) done as root is no longer honored for the same process if later continued as user. Just use a recent _original_ cdrtools version (that knows about Linux self-incompatibilities) from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ and install it suid root. It does not have the problems you mention. ^ That is not the scenario we are talking about. The original version fails as well. It works as root, sure. It does NOT work as NON-ROOT. And it does not need to be root after simple modifications. Vincent, this verifies my statements from yesterday night: Eduard is not a programmer and he does not know how cdrecord works. For this reason, he e.g. incorrectly believes that cdrecord is able to work correctly when run without root privileges. A simple test with the original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ verifies that the original version works correctly. Please don't believe him, you will end up with strange problems because cdrecord will not be able to send all needed SCSI commands if not run with root privileges. The first thing is bullshit and the second is half-true. I am CS student and beginning the diploma thesis RSN, and I coded lots of C/C++ code in the past years. And I can follow the control flow in your code long enough to find where it does unneccessary things that the kernel does not allow. YOU YOURSELF marked the suspicious code telling doubts about its usefullness. If you think that is a kernel issue then it is a very natural issue, there is no point in giving non-root users more permissions than they need. If Eduard would be able to follow cdrecord's control flow, he would not write such a nonsense! If not run with root privileges, cdrecord is unable to send all needed SCSI commands and then fails in strange ways and it is hard to understand why this was a permission problem. His patch does not do the right thing [1] and is illegal because it tries to change the license of the code although Eduard is not the copyright holder of the code! That was a patch for the version of cdrtools that YOU YOURSELF have distributed under the GPL license. You know pretty well that it permits modifications. This patch does not even change the library interfaces and repairs broken things. I cannot understand what you are talking about. Edurard did already write a lot of nonsense, he does not understand the basics of licensing. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
You again make the wrong conclusions and I get the impression that you need to read the GPL more thoroughly in order to understand the way I interpret it. The main missunderstanding seems to be caused by reading GOL §2 b) too quickly. this is why I try to explain it to you in detail below. /*--*/ The main weapon of a lawyer or person who works on contracts is the word. If you like to play in that league, you need to be able to deal with that weapon! In other words, you need to read the GPL carefully and thoroughly many times until you understand every corner of the text. Sometimes I get the impressuion that native English speakers don't do that because they believe that they understand what they read in the first attempt. /*--*/ Don Armstrong [EMAIL PROTECTED] wrote: The CDDL definitely does not have any requirements on other code as it is a clearly file based license. For this rerason, your statements (below) on the CDDL are wrong. Neither license has anything to do with files. The licenses work the same regardless of whether you have a single file with sections under multiple licenses or multiple files each under a single license. You need to read the licenses. The CDDL _explicitly_ mentiones the fact that it is file based. Regarding the GPL: If you don't think about the possibility of using separate files, you obviously missunderstand the possibilities that GPL §2 b) gives you. Other claims often made about the GPL when talking about the GPL cannot be found in the original GPL text, viloate the law and thus are void. Violate which law(s)? Realize of course, that we're talking about distribution in multiple countries here, of which Germany is just one. Cdrtools is a work that is covered by German Urheberrecht http://www.gesetze-im-internet.de/urhg/index.html If you don't read and understand it, you are probably the wrong person to discuss this issue. You need e.g. definitely read this: http://www.gesetze-im-internet.de/urhg/BJNR012730965.html#BJNR012730965BJNG003601377 Since 1993, even US judges need to follow these rules or they are acting illegally. The GPL includes no text that is related to GPL projects that include/use non-GPLd code. As the GPL in general permits to use the code, this is a permitted use. The direction is irrelevant. It's just as valid to say that you've taken the Schilly makefile project (CDDLed) and added to it GPLed code. If what you're saying where actually the case, it would make the GPL meaningless. Of yourse, the direction is relevent! Your statement about the Schily makefilesystem does not apply at all because the GPL requires to include build scripts but does not mention a specific license. The fact that you believe this may be relevent, verifies that you need to re-read the GPL until you understand that you cannot mix claims from unrelated sentences in the license with claims from other sentences. GPL §2b) b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Some hints for understanding this text: - The Schily makefilesystem is a separate work and not part of the work cdrecord. The Schily makefilesystem does not appear in the resulting binaries and it is possible to compile everything manually without using the Schily makefilesystem. - The term contains _definitely_ describes a _direction_ - If you like to understand the text above, you need to understand the term derived. The fact that mkisofs _uses_ libscg, definitely does not make libscg software that is derived from mkisofs. If at all, is just the other way round: mkisofs is a program derived from libscg. If you still believe that _the_ _way_ _I_ _combine_ CDDL and GPL is not allowed, you would need to write a very detailled description with quotes in order to proof your claims. In case you did not get it correctly. I am not saying that _every_ combination of CDDL and GPL code is legal, but it is obvious that the combination I am using is legal. Note that you simply cannot create a license that tries to enforce conditions on other people's code because this would be illegal. You missunderstand what the GPL (and to a lesser extent the CDDL) does. It doesn't *force* you to satisfy the conditions; it *prohibits* you from distributing the GPLed code when you cannot. You are missunderstanding the GPL and the CDDL in many ways. Cdrtools word by word follow the rules in both licenses! You of course need to read both licenses word by word in order to understand why cdrtools does nothing illegal. Many people
Bug#377109: Bug#350739: #350739: cdrecord status?
People who cut off ompirtant people from the list of mail recipients cannot be taken for serious. You are obvuiously not interested in a solution but in lighting a fire :-( Steve Langasek wrote: To my knowledge, Eben Moglen's *beliefs* on how the GPLv2 should be interpreted are not a binding legal precedent in any jurisdiction; nor is this post hoc interpretation binding on any copyright holders other than the FSF. It may not even be binding on the FSF itself. What is your intention for this writing? Regardless, Joerg Schilling's amply demonstrated animosity towards the maintainers of the Debian cdrecord package has been such that I no longer You seem to completely missunderstand the background. One specific Debian maintainer (Edurard Bloch) is completely uninformed and arrogant. He does cause harm to the Debian project the way he acts. His arrogance is so big that he even claims that he knows better how cdrecord works than me the author. He fails to inform himself about the way cdrecord works and repeatedly writes nonsense to Debian users. believe the text of the licenses is the principal issue before us. Anyone so happy to threaten Debian developers with defamation lawsuits is not what You should not believe beople like Eduard Bloch who is a convinced lier in many cases. I consider a good-faith contributor to the Free Software community, and I think it's unwise for Debian to distribute software of such provenance regardless of license terms. The power of a license lies in it's written down terms and not in what someone think's it says, or in their personal opinion or point of views. To put things right: My only interest with Mr. Bloch is to put his discussion on facts and terms of the GPL and not on his personal opinion and thoughts. He bends information until it fit's his opinion and personal point of view, leaving the intended message far behind. Not to speak about personal offenses he often puts in between his words. I told him twice that I do not threaten him, but he either did not read my mails completly or bended them to his personal comfort. He accused me of violating the GPL. When I asked him to cite the paragraphs of the GPL that he claims to be violated, he in return send his personal opinions. After repeatedly reasking him for facts and cites of paragraphs he claims I violate, he found out that there is no evidence on his claims. So I asked him to close the bug but still keep it readable for public interest. And that is where we are right now: He now says that there is no GPL violation that he can claim, but he will leave the bug open for no reason. Right now the bug has been closed and moved out of public sight. It looks to me as if Mr. Bloch holds a grudge against me, but that does not belong in the Debian bugtracking system. It is a misuse of that platform. Wasn't the GPL invented as a safeguard for users of software and not as an instrument for softwareusers against the authors and to waste the time of those authors keeping alive the idea of publicly available software by writing it and putting it in the public on base of free licenses? If users are misusing the GPL as an instrument against programers, why should a programmer then put it's software under such a license. This kind of misuse has the power of underminig and destroying the system of free software. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377421: cdrecord in sid fails to burn cds via the /dev/cd... interface
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Joerg Schilling [Sun, Jul 09 2006, 11:52:35AM]: Vincent, this verifies my statements from yesterday night: Eduard is not a programmer and he does not know how cdrecord works. That's bullshit. The competent way you are replying says all... For this reason, he e.g. incorrectly believes that cdrecord is able to work correctly when run without root privileges. A simple test with the original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ verifies that the original version works correctly. Believe what you want. I believe what I see (in strace output) and what the users do report. People who do not understand enough like you often oversee important issues like you do in this case... The recent official cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ have been verified to work correctly when installed suid-root on Linux and Linux definitely requires cdrecord to be run with root privileges in order to be able to use all needed SCSI commands. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377421: cdrecord in sid fails to burn cds via the /dev/cd... interface
Eduard Bloch [EMAIL PROTECTED] wrote: | That is not the scenario we are talking about. The original version | fails as well. It works as root, sure. It does NOT work as NON-ROOT. And | it does not need to be root after simple modifications. I refrain from answering to other stuff until you understand and respect the difference between root and non-root usage. And correctness does not really have much to do with that, so measuring correctness depends on the personal POV. As long as you fail to understand the difference between it works and it _seems_ to work in a particular case, it does not make sense to continue the discussion with you. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
Andreas Barth [EMAIL PROTECTED] wrote: * Joerg Schilling ([EMAIL PROTECTED]) [060707 17:50]: You seem not to understand how a constitution works If you do not follow written rules, you end up in arbitraryness. Actually, I'm a debian officer while you are not. It seems that my peer developers actually have some trust in me that I do my work correct. And all other developers are actually satisfied by the decision that CDDL doesn't meet the DFSG. The only one always barking and whining are you. So isn't the chance quite good that you are wrong, and all other people are right? As you are unable to prove your claims by quoting related parts of written down rules, you are obviously not trustworthy. I am not sure if this is just because you are unable to cooperate/interact with other people or because you like to have arbitraryness at Debian. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377109: Bug#350739: #350739: cdrecord status?
Don Armstrong [EMAIL PROTECTED] wrote: On Fri, 07 Jul 2006, Joerg Schilling wrote: Andreas Barth [EMAIL PROTECTED] wrote: Also, as usual, you are ignoring the vital fact that the combination of CDDL and GPL is something between legally dubious and illegal. Of course, you ca distribute whatever you want, but Debian is bound to legal behaviour. It seems that you did never read the GPL and the CDDL in depth enough in order to under stand either of them... The GPL explicitely allows to use the code and it only forbids to use GPL code in non-GPL projects. So it is obvious that the GPL allows to use non GPL code in a GPL project. The GNU GPL only allows this when it is possible to satisfy the conditions of the GPL for the distributed work. For example, this is why it is possible to combine MIT licensed works with GPLed works. Your assumption is made on wrong general prerequisites. The CDDL definitely does not have any requirements on other code as it is a clearly file based license. For this rerason, your statements (below) on the CDDL are wrong. What you mention about the GPL is only true in case you put GPLd code or parts of GPLd code into a non-GPL project. The relevent part of the GPL is: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Other claims often made about the GPL when talking about the GPL cannot be found in the original GPL text, viloate the law and thus are void. The GPL includes no text that is related to GPL projects that include/use non-GPLd code. As the GPL in general permits to use the code, this is a permitted use. Before writing more, it seems to be iomportant to mention a common missconception: Both, the CDDL and the GPL are _source_ licenses. They both _allow_ binary redistribution under certain conditions but it is definitely wrong to even think about: under what license might the resultant binary be. There is no binary license for the project but there is a permission to distribute/use binaries under certain conditions. The CDDL enforces contidions under which the resultant binary may be distributed but it does not enforce _anything_ on the non-CDDL source. The GPL enforces other contidions under which the resultant binary may be distributed but it does not enforce _anything_ on the non-GPL source. Note that you simply cannot create a license that tries to enforce conditions on other people's code because this would be illegal. Many people forget about the law and about the original intention of the FSF when talking about the GPL. Unless you asume that the FSF is acting like Microsoft, it is obvious that the intention of the FSF it only to prevent the GPLd code from disappearing in CSS projects and to keep it free. Both do not apply to code under the CDDL because the CDDL is a free license that itself tries to prevent the code from being made non-free. Allow me to make it abundantly clear why the CDDL and GPL are incompatible:[1] CDDL 3.1 requires that the Source Code of Covered Works made available in Executable form be distributable only under the CDDL; CDDL 3.4 disallows additional restrictions. CDDL 6.2 (patent retaliation) is a restriction not present in the GPL. See above: The text is correct, the conclusion is wrong. The CDDL is a file based license and does not enforce any restrictions on non-CDDL code. GPL 2 requires all of the work when distributed together to apply to the GPL. GPL 6 dissallows additional restrictions. GPL 2c is a requirement not present in the CDDL. See above: The GPL (see GPL § 2b) only requires the whole work to be distributed under the GPL in case that a non-GPL project tries to use GPL code. The GPL does not contain any text that could cause the assumption the GPL tries to enforce restrictions on non-GPL code. As you can see, they're incompatible with eachother in either As you see, you just did make the wrong conclusions direction. Indeed, I've been told by those involved in the drafting of the CDDL that this was done by design. [See the video of the Solaris discussion at Debconf 6 if you want to see someone talk about it; you can also see me discussing this issue and others as well in the same video.] This is of course wrong - sorry. Please stop distributing wrong claims. I have been involved with the creation of the CDDL and I know that your claim is wrong. The reason for not using the GPL for OpenSolaris is simple: The GPL (if used for OpenSolaris) would not allow Sun to create the Sun Solaris Distribution from the OpenSolaris sources. I had a 1.5 hour phone conference with the lawyer who created the CDDL and the Solaris chief engineer and we did discuss all aspects of the CDDL and most of the changes found in the second CDDL contribution
Bug#350739: #350739: cdrecord status?
Andreas Barth [EMAIL PROTECTED] wrote: Please see Don's reply. It contains all useful information. Even though you behave like a Kindergarte would be the right place for you, I'm not doing total mouthfeeding for you now. As you continue to send irrelevent rants, you are obviously not able or willing to have a fruitful discussion. Please stay off this discussion unless you have anything relevent to say! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
Andreas Barth [EMAIL PROTECTED] wrote: * Joerg Schilling ([EMAIL PROTECTED]) [060708 12:28]: The GPL enforces other contidions under which the resultant binary may be distributed but it does not enforce _anything_ on the non-GPL source. Well, but it might result in the binary being unredistributable at all. This is the case here. As Debian provides binaries for anything in main, and this is not possible with your combination, your package cannot go to main. You still seem to prefer to write claims without a proof, so it is obvious that your claims are wrong. Could we please have a fact based discussion? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#350739: #350739: cdrecord status?
Andreas Barth [EMAIL PROTECTED] wrote: * Joerg Schilling ([EMAIL PROTECTED]) [060708 12:32]: Andreas Barth [EMAIL PROTECTED] wrote: Please see Don's reply. It contains all useful information. Even though you behave like a Kindergarte would be the right place for you, I'm not doing total mouthfeeding for you now. As you continue to send irrelevent rants, you are obviously not able or willing to have a fruitful discussion. Please stay off this discussion unless you have anything relevent to say! Obviously you seem to totally misinterpret the status. I'm a Debian officer, and it is my duty to protect people who use Debian ressources from lies. You are a random troll. You send 5 trollish posts in a row. It is obvious that you are the poor troll... It seems that I need to ignore your fruitless rants until you proove that you are willing to have a fruitful discussion based on proovable facts. You could do other people a favor by stopping your useless rants to this list. In case you did not get it: this is the End of discussion with _you_ but I am still in hope to talk to people from _Debian_ who are interested in a fact based discussion. I know that there are people (e.g. Don Armstrong) who are able to have a fact based discussion. I did send a long fact based reply to Don Armstrong today noon and I am still interested in getting a fact based reply on that mail. To Don Armstrong: It may be the main point that people fear that compiling cdrtools creates unredistibutable binaries. I see no reason why binaries may be unredistibutable as I don't see any contradictory requirements from CDDL/GPL. Both licenses are source licenses and require to make the source available in case a binary is distributed. This is no contradiction but just the same requirement. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Bug#377109: Bug#350739: #350739: cdrecord status?
Don Armstrong [EMAIL PROTECTED] wrote: Don, I see that you again seem to make wrong conclusions from the facts you mention. Answering your mail will take a long time in case you like to get useful quotes for my claims.I will do this later. For this reason, I like to send you a question that you could answer before I answer your last mail. The main question seems to be whether resulting binaries may be redistributed. You did not give any reason why you believe that cdrtools binaries may not be redistributable by Debian. It would help a lot if you did asume that the GPL allows a GPLd project to use non-GOL code. I will explain you later why this is legal, but you need to send your questions as precise as possible to allow me to answer efficiently. Now tell me why you believe that Debian dannot redistribute binaries. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
