Re: cdrtools cdrecord/cdrecord.c
Steve McIntyre <steve@einval.com> wrote:
> >> 06_dautipps.dpatch:
> >> Little patch to extend error information
> >
> >This patch causes incorrect output
> >---> rejected
>
> What, you're claiming extra output that may help a user diagnose a
> problem "incorrect"?
1) cdrecord The output is wrong for 30 - 1 platforms.
2) mkisofs This is something that may be useful.
> >> 07_noadvertising.dpatch:
> >> Remove advertising for cdrecord-ProDVD.
> >
> >Replaces generally useful infomation by Debian advertising
> >---> rejected
>
> "generally useful infomation" being advertising for a non-free
> product. Yeah, whatever.
Well, it seems that you are unable to understand that Debian is just a small
fraction of the world.....
The hint that is removed by Debian prevents people from learning where to find
working DVD support for cdrecord.
> >> 21_makefile_fix_for_kernel.dpatch:
> >> Fix problems with kernel include doing wrong things.
> >
> >Unneded at all at least if the Linux kernel include files are non-buggy.
> >In addition, the autoconf utility already tests for known Linux kernel bugs.
> >---> rejected
>
> All this patch removes is /usr/src/linux/include from the include
> search path. That's a standard thing to do - there's no guarantee at
> all that /usr/src/linux/include contains include files that match the
> current kernel. This is standard advice.
Looks like you do not understand how Linux works/is compiled.
Linux is a kernel only and as I explained _many_ times before, the only way to
get correct access to Linux kernel interfaces is by accessing the linux kernel
include files.
It is _impossinble_ to compile cdrecord on Linux-2.2 or older after this
patch has been applied and it is impossible to compile correctly with more
recent versions of Linux.
Note that Linux is a kernel only and as not all Linux distributions behave
identical there is no way to treat a single distribution as a whole OS
nor is it possible to correctly identify them by autoconf.
What the makefile system does is to go the way that has the highest probability
for success.
> <snip>
>
> >> 23_o_excl.dpatch:
> >> Open devices with O_EXCL to stop other programs from interrupting
> >> writes
> >
> >general rule: Fix the other programs that are broken
> >---> rejected
>
> If cdrecord needs exclusive access to a device, then it's up to
> cdrecord to ask for that exclusive access. That's a simple enough
> rule...
Cdrecord does not like/need exclusive access to the devices.
It however may not work correctly if other software missbehaves.
Which software missbehaves in what way is largely Distribution dependent.
It therefore is counterproductive to take care of specific Distribution
specific bugs.
> <snip>
>
> >> 35_ultra_speed_media.dpatch:
> >> Simple bug fix for ultra high speed RW media detection
> >
> >This problem has been fixed in cdrecord more than a month before Debian
> >---> rejected
>
> In which release version, precisely? That patch was a backport of your
> fix to the previous cdrecord release, as forwarded to the Debian BTS
> by a user; it'll be dropped when we move forward to your latest
> release...
2.01.01a04 Checking SCCS, it seems that the patch has been published and
integrated more than 2 months ago.
> >So you see: not a single patch is senseful.
>
> By your reckoning, clearly everybody else is _always_ wrong. That
> might explain why you get so few people attempting to help you develop
> cdrtools...
Well, I did integrate plenty of patches from other people before.
If you are a member of the community and sensefully talk with me, you have a
bonus. If you verify your skills by making useful proposals you get another
bonus.
The Debian people failed on all these things for a long time. Debian did
the following things wrong in the last 3 years:
- They make Eduard Bloch a cdrecord maintainer.
This guy has no clue. He did e.g. fail to understand that a patch
he send would fail on any compiler that is not bug compatible to GCC.
When trying to explain him the facts he did refuse to educate himseln
but started to send personal infringements against me.
- They failed to stay in contact with me and did not forward
bugs to me.
- They rejected to move problems caused by obvious linux kernel bugs
to the list of Linux kernel bugs.
- In general, they seem to prefer to add patched to cdrtools instead of
fixing the programs that cause the problems - even if the patch
in cdrtools is more then 10x of the size than the fix on the other
programs would be and even if the patch in cdrecord causes other
problems.
Example: the bug / non-compliance in the Silo boot loader.
Instead of fixing silo (10 lines) to be fully sparc boot compliant,
they preferred to add a > 400 line patch to mkisofs and this
patch is not even byteorder independent, so it fails on non
Big-endian machines.
I am always open to a mind change, but the people who like to get my help
should be able to cooperate and to accept usual basic knowledge on computer
science.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: