zarniwhoop73 at googlemail.com
Sun Sep 13 14:45:15 PDT 2009
2009/9/13 Guy Dalziel <krendoshazin at dementedfury.org>:
> It seems that every time I compile cdrtools a new problem arises, once
> again the glibc patch seems to be failing to do the job. I grabbed the
> beta of cdrtools (2.01.01) from the site, and it compiled straight out
> of the box with no patches required. I propose that we upgrade cdrtools
> to the beta and get rid of the patches, vanilla code is always more
> desirable. I know we're not in the habit of including development
> releases, but I feel that the situation of 2.01 warrents the use of it.
People still use the original cdrtools ?
I got fed up trying to build cdrtools when I moved beyond Herr
Schilling's supported architectures (neither pure64 nor multilib
ppc64 were easy there), and went for dvdrtools which is a fork
from before cdrtools was relicensed.
Meanwhile, distros have been bitten by the license change
(see e.g. the old summary at http://lwn.net/Articles/199061/ )
and are using different things (typically, cdrkit/wodim).
The license change itself is not a problem for us, because we
don't distribute binaries, but I think most modern distros only
provide something called 'cdrecord' as a compatability symlink,
and the underlying program is not cdrtools.
OTOH, perhaps recent versions of cdrtools are better on the
supported architectures such as x86, and certainly I lost some
speed autosensing improvements when I left the true cdrecord.
Or do you still get warning messages when you point it to what
is supposedly a disk instead of the scsi triplet returned by scanbus
(assuming, that is, that you don't have a real SCSI burner) ?.
After tragedy, and farce, "OMG poneys!"
More information about the blfs-dev