Eduard Bloch <[EMAIL PROTECTED]> wrote:
> > If you did read my information, you would find that the named patches
> > _create_ problems.
>
> You keep saying that but you don't tell which problems _exactly_ are
> created, ie. how the actual symptoms look like. Unless you proove that
> and show us _real_ bug reports from _real_ users with problems created
> by _our patches_, this talk about "new problems" is pure speculation.
If you claim that I "don't tell which problems _exactly_ are created", then
you obviously did not read my text..... well, you deleted it, so it is obvious.
Let it repeat it for your convenience:
---->
Here is a list of buggy patches applied by Debian on cdrtools:
02_cdrecord_default_conf.dpatch Introduces unsupported dev= syntax
and definitely makes cdda2wav behave
in an unwanted way.
02_paths.dpatch Intruduces unneded "Silo" patch.
Code for a correct sparc boot can be
found here:
http://cvs.opensolaris.org/source/xref/on/usr/src/stand/
08_privacy.dpatch Introducing useless "privacy" (obviously
from people who did not yet look at the
"privacy leaks" found in Debian packages
May cause future versions of Solaris to
fail dealing correctly with hard linked
files of zero size!
14_mkisofs_iconv.dpatch Half hearted patch that does not address
the needs of a portable program.
18_donotopen_hda.dpatch Prevents libscg from seeing all
possible SCSI devices
20_rsh-bugfix.dpatch Unneeded, may break things
21_makefile_fix_for_kernel.dpatch ONLY applicable on Debian Linux with
Linux kernel version 2.4 or newer.
Breaks cdrtools with all other Linux
versions
You should rather fix the kernel....
22_linux_rawio_capability.dpatch Linux should rather introduce user level
support for fine grained privs than
forcing applications to add highly
non-nportable code.
It is unclear whether this patch causes
problems rather than giving benefits.
23_o_excl.dpatch Causes libscg to fail and is the reason
for 3 bugs in the cdrtools Debuan bug
list.
24_debug_tmpfile.dpatch Unneeded in case that
/etc/default/rscsi is installed with
the right permissions
27_scsi_buffer_size.dpatch Breaks the interface of libscg
it is completely unneeded!
28_cdda2wav_interface.dpatch Patch with unclear target....
People should rather educated by Debian
how to correctly specify dev= arguments
for libscg
31_gnu-kfreebsd.dpatch Does not do the right things and rather
breaks things
33_extra_arch_boot_support.dpatch Introducing this code would cause a lot
of testing in order to maintain
quality.... The code needs a code review
and some testing in order to get added
to the official source.
34_JTE.dpatch Looks like something that breaks
mkisofs
36_ATA_scanbus_ignore_locked.dpatch See 23_o_excl
<---
Iy you stil don't understand the text, I recommend you to read the complete list
of bugs on the Debian bug tracking system:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cdrtools
It has proofs most of the problems described above.
For the rest of the problems I encourage you to read the official
manual pages and the official documentation for cdrtools.
One important cause of problems introduced by Debian is that Debian
ignores the documentation and tries to find "solutions" for "problems" people
have, that incorrectly use one of the tools. As an example: The most common
missusage is to call something like "cdrecord dev=/dev/hdc ..."
Another frequent missusage is calling cdrecord with insufficient privileges.
Conclusion: someone who likes to maintain cdrtools at Debian should first
read the documentation and learn correct usage before looking at bugreports.
> The only exception I can see is the problem with the locking patch and
> the "special" behaviour of libscg when doing the scanbus operation - and
> even this problem will be _solved_ by the patch 36 which just waits for
> the next release of cdrtools packages and has also been confirmed as
> beeing effective by a user in bug report 360295.
>
> > > > 23_o_excl.dpatch Causes libscg to fail and is
> > > > the reason
> > > > for 3 bugs in the cdrtools
> > > > Debuan bug
> > > > list.
> > > ...
> > > > 36_ATA_scanbus_ignore_locked.dpatch See 23_o_excl
> > >
> > > Yes, it solves that problem. The alternative would be a fundamental
> > > change of libscg which you would unlikely agree with.
> >
> > If you did read the bug list from Debian, you would see that the patches
> > above
> > cause cdrecord to fail completely while an unpatched version works at the
> > same
> > time.
>
> 23 makes trouble, 36 fixes that again -> problem solved. Yes, unmodified
> version works under laboratory conditions and on many systems with
> "good" environment but IRL things may become more complicated. As said,
The real problem is a bug in "hald", it still has not been fixed. See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=361643
If there is a broken application like "hald", this broken applicaion needs to
be fixed. It is never a good idea to add workarounds in other applications.
As you see in several bug reports, the workaround for the "hald" bug did not
help but rather made the problem less visible.
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
