cant burn a cd iso

[Joerg Schilling]

"Rick C. Petty" <rick-freebsd2008 at kiwi-computer.com> wrote:

> > It is not a big deal if this version is installed by default ;-)
>
> What do you mean "by default"?  sysutils/cdrtools is not part of the base
> installation of FreeBSD, that's why it's a port.  At some point down the
> line you installed sysutils/cdrtools.  I'm just suggesting that you should
> have installed sysutils/cdrtools-devel instead.

If pepole who try to install cdrtools are guided to the outdated versions, this 
is not a good idea.

> > As I mentioned before: stable means dead -> no longer taken care of.
>
> Yes, we all know your interpretation of the world "stable", which is not the
> expected meaning that FreeBSD folks generally intend when they use that
> term.  I certainly would not call RELENG_7 "dead".  When someone sees one
> link that says "stable" (not one stating "dead"), they assume that the
> opposite means "unstable".  I suspect the port maintainer for cdrtools made
> this assumption and choose "stability" over "possibly not tested as much".

I did not talk about FreeBSD but about cdrtools. You are confusing unrelated 
information.


> > During the past 5 years, I fixed dozens of bugs in mkisofs from the early days
> > of mkisofs. A bug that matches your description did never exist.
>
> That's a pretty far-fetched statement.  I will assume that you mean that

No, this is a statement that is aligned with reality. Your claim however is 
far-fetched.... You tell me that there was a problem but such a problem
has never been reported nor fixed. 

> this was not a bug that you fixed or that you did an exhaustive search
> through the reported bugs and did not find such a report.  I can assure you
> that such a bug did exist around the FreeBSD 5.0 or 5.1 timeframe (six

So may it be a bug in FreeBSD 5.0 or 5.1?

> years ago).  I had two vanilla machines building release images and one
> machine's ISOs sometimes failed.  The two boxes had slightly different
> cdrtools versions installed.  I downgraded the one and things worked
> correctly.  I'm not 100% positive, but looking at my distfiles archive from
> around that time, I believe the working version was 2.00.3 and the broken
> version was 2.01a31.  I can't be too sure because I lost a number of
> distfiles in my archive.

As I mentioned already, such a problem has never been reported nor fixed.
If you were right, the problem still must be in mkisofs. Do you have a command 
chain to repeat the problem?


> My test case to prove the cause of the issue was something like:
>
> # mkisofs -v -pad -r -hide-rr-moved -o test.iso /5.1/R/cdrom/disc1/
> # mdconfig -au0 -f test.iso
> # mount -t cd9660 /dev/md0 /cdrom
> # find /cdrom -type f -exec dd if='{}' of=/dev/null bs=1m \;
>
> When it worked, the find generated no output.  When it was broken, I would
> see I/O errors IIRC.

If there really was a problem, why didn't sou send a bug report?

Your problems could have many causes:

-	a general bug in FreeBSD

-	a buf in the "md" driver

-	a bug introduced by other peoople in your local copy of mkisofs.

If you give me the chance to repeat it on Solaris, I am willing to believe that 
there is a problem and I will fix it as soon as possible. For now: I did never 
see any related problem, so I tend to believe that such a problem did never 
exist.

> > If you did observe such problems, you did not use mkisofs but something else.
> > Did you use the defective fork from Debian? Did someone else modified your 
> > local version?
>
> Nope, just a vanilla FreeBSD install and some ports needed to build a
> release, including cdrtools.

??? You don't need "some ports" to build cdrtools. Cdrtools come with a 
makefile system that allows it to compile out of the box on aprox. 30 platforms
without any manual help by just typing "make" (better "smake").

Did you use an unmodified original cdrtools source?


> Note that my statements were not intended to criticize cdrtools, just that
> I sympathize with port maintainers' desire to keep a more "stablized"
> version around for things that are essential, such as ports used for
> building a release.  Pardon the pun, but when you've been *burned* once,
> you're more careful to avoid any repeats.  And I burned a lot of coasters
> that day before I downgraded my cdrtools installation.

So try to find the real reason for your problem.....

The way cdrtools is developed gives you the grant that you get constantly 
evolving and less buggy bug still compatible version if you upgrade to the 
latest source in:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

There are a few exceptions, and in such a case, there is a marker in the 
announcement file. The last time this happened was between 2.01.01a12 and 
2.01.01a27 when the buggy GNU getopt_long() was replaced by the more mature 
getargs() and thousands of lines of code have been changed.

The general rule for creating a new cdrtools release is to either only fix bugs 
or to add new features without adding bugs to previously working parts. This 
allows you to upgrade to the latest source, _anytime_ there is not a warning 
message in the AN* files.


> > I was and I am still very friendly and explained the meaning of the word 
> > "stable". What is your problem?
>
> It seemed like you were being demanding from people who are volunteering
> their time.  Certainly your previous email seemed to me that you were being
> somewhat arrogant as well.  However I will give you the benefit of the
> doubt that you are attempting to be civil and I fully retract my statement.

If you call a person "arrogant" just because he knows what he is talking about,
you need to fix your view on the world. If you did not notice this fact: the 
oldest source parts in cdrtools that I wrote are more than 25 years old. I am 
not an OSS newbie... 

BTW: I am contributing _my_ time for you and I thus expect that people who use 
my software are collaborative with reporting bugs and discussions in general.

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily