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.
>
> "obvious"? Please, stay on topic and avoid trolling. There is no point
> in sending this list again. But...
An interesting trollish claim....
> > 02_cdrecord_default_conf.dpatch Introduces unsupported dev=
> > syntax
> > and definitely makes cdda2wav behave
> > in an unwanted way.
>
> This hint is not constructive. Unwanted by whom? As already pointed out,
> you refuse to admit the existence of real problems fixed by our patches
> and you blame others instead. Unfortunately, the others are kernel
> developers, or just users (in short: a vast majority of people out
> there).
I know that you are unable to be contructive and please don't try
to point to uninformed people to defend your claims.
> > 02_paths.dpatch Intruduces unneded "Silo" patch
>
> We had this discussion in the past. People have been using this
> functionality and one of the debian-sparc people promised to maintain
> it. Untill it breaks something, I fail to see a reason to remove it.
Please do not try to reverse previous discussion results.
You (Debian) did agree on removing this patch for the "next release" and
this has been discussed around Y 2001.
A rule of thumb:
- Do not try to duplicate existing code (mkisofs did have Sparc compliant
sparc
boot support before this anachronism was added.
- If you don't know how to create a correct sparc boot, just have a look
at: http://cvs.opensolaris.org/source/
> > 08_privacy.dpatch Introducing useless "privacy" (onviously
> > from people who did not yet look at the
> > "privacy leaks" found in Debian packages
>
> Apples and oranges. Show a similar program (something mastering data for
> export to customers) that needs to keep fingerprints in the data.
tar and nobody complains about tar
And in case you like to know a nearly identical program: the ISOFS creator
program from Young Minds.
> > May cause future versions of Solaris to
> > fail dealing correctly with hard linked
> > files of zero size!
>
> What's the point? Missing mkisofs version tag in the image info makes it
> fail? Sounds like problematic software design to me.
This version tag will be used to identify mkisofs specific extension that will
be needed for 100% hard link support in OpenSolaris hsfs.
> > 14_mkisofs_iconv.dpatch Half hearted patch that does
> > not address
> > the needs of a portable program.
>
> This hint is not constructive. See above, and portability is not
> everything. Modern systems use UTF-8 and your mkisofs extensions fail to
> provide support for it. And I cannot remember when the last bug report
> related to this patch appeared.
You are correct: your patch and your behavior was not constructive.
If you like that a patch will be integrated in the mainstram program,
do it in a decent way and not in a way that would take more time for proper
integration than to write it from scratch.
> > 18_donotopen_hda.dpatch Prevents libscg from seeing all
> > possible SCSI devices
>
> This is an old workaround for a fundamental problem with
> cdrecord/libscg. If you understand what the patch was indended to do,
> have you got an idea to fix it in a proper way? Unless the answer is
> yes, your comment is not constructive.
The problem is that the Linux Kernel folks are not constructive.
I will not add workarounds for Linux kernel bugs in case these workarounds
will not give 100% functionality.
Try to be constructive and not destructive as usual....
> > 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
> >
> > Should rather fix the kernel....
>
> This hint is not constructive. If we cannot fix the kernel, we fix the
> problem here (you know "Berg, Prophet, etc."...).
Well, the problem is that the Linux kernel developer are uneducated troll
regarding this problem.
I did try to educate them many times - it seems to be imporssible :-(
We could find a solution if someone did fix the Linux kernel include files
to allow proper compilation of user space programs. Note that this fix needs to
be done in sync with _each_ Linux kernel.
Make sure to install these fixed kernel include files in /usr/src/linux/include
This is the location that has been chosen by the Linux kernel developers and
cannot be changed for many reasons:
- it would break compilation on older Linux releases
- /usr/include/ does come with the glibc packet and is not in sync with
the kernel interfaces. For this reason, /usr/include may only be used by
"simple programs".
There are of course many more reasons.
> > 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.
>
> The portability is sufficient for our needs.
Try to look at OpenSolaris to understand the problem.
Please don't try to judge on problems you did not understand.
If you like to understand this problem you need to know how a fully
integraded and user _ready_ implementaion of fine grained privs looks.
> > It is unclear whether this patch causes
> > problems rather than giving benefits.
>
> It solved http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267273 and
> partially http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=266009 -
> please see there for details.
If I kill you, you will never have any headachkes in future, but does this
solve your headache problem?
> > 23_o_excl.dpatch Causes libscg to fail and is the reason
> > for 3 bugs in the cdrtools Debuan bug
> > list.
>
> Patch 36 fixes that and possibly obsoleting 18_donotopen_hda.
>
> Unfortunately it changes the interfaces of libscg a bit, and at this
> point I run into the another infamous dispute with you, so the problem
> cannot be solved easily.
This is a hald bug.
Rule of thumb: if hald is broken, fix hald.
> > 24_debug_tmpfile.dpatch Unneeded iin case that
> > /etc/default/rscsi is installed with
> > the right permissions
>
> What does a safe open method have to do with /etc/default/rscsi's
> permissions?
Why do you need a method that breaks debugging in case that
debugging is only possible to be switched on by the sysadmin?
The problem with many Debian patched is that they are halfhearted and
do not fit to a proper planned development.
You will convince me with any decently planned and revied patch.
You will never convince me with quick and dirty hacks.
> > 27_scsi_buffer_size.dpatch Breaks the interface of libscg
> > it is completely unneeded!
>
> Please explain why it is unneeded. It solved
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343666 and I still
> cannot see which alternative fix has been created by you in a03.
It does not solve the propblem correctly and it breaks compatibility.
In addition it is not needed!
> > 28_cdda2wav_interface.dpatch Patch with unclear target....
> > People should rather educated by Debian
> > how to correctly specify dev= arguments
> > for libscg
>
> The original cdda2wav did not force its users to use special syntax,
> alienating the usual device access method via /dev/* files. From my POV
> the patch restores the compatibility that you have broken a while ago.
This is of course complete nonsense. Please educate yourself by reading
the cdda2wav man page.
The behavior we are talking about has been introduced more than 6 years
ago while starting to implement proper DAE support that is not limited by
kernel quality.
If you like to go back to the stone age of cdda2wav, check for cdparanoia.
This is cdda2wav from 1998.
> > 31_gnu-kfreebsd.dpatch Does not do the right things
> > and rather
> > breaks things
>
> It solved problems. How does your proper solution look like?
It is in the latest source.
The patch you havbe is known to break things.
> > 33_extra_arch_boot_support.dpatch Introducing this code would cause a lot
> > of testing in order to maintain
> > quality....
>
> Yes, ... and? IMO Steve has enough skills to maintain it.
If Steve has the needed skills, why is he unable to have a decent
fact based conversation?
We did have this discussion already in January or Februaray and Steve did write
a lot of wrong things. After I did ask him to prove his claims, he did not
reply anymore.
I am willing to integrate useful things as long as they follow some rules.
See:
ftp://ftp.berlios.de/pub/cdrecord/CONTRIBUTING
for more information
> > 34_JTE.dpatch Looks like something that
> > breaks
> > mkisofs
>
> There is no smoke, no core file, so I cannot see anything breaking.
In case this would make sense for integration, there would be sufficient
documentation and white papers as well as code review....
The current code definitely violates §5 and §6 from:
ftp://ftp.berlios.de/pub/cdrecord/CONTRIBUTING
> > 36_ATA_scanbus_ignore_locked.dpatch See 23_o_excl
>
> See answer to 23_o_excl. Show your proper solution - and removing device
> locking or breaking the functionality of other established software
> (your bug report #361643) is not a such one.
>
> Summary: 15 of 16 of claimed "problems" are not real problems, one is a
> pending fix to eliminate the 16th problem.
See above:
Show me a proper solution and it may have a chance fopr an integration....
> Why? "Official documentation" are papers where you try to create facts
> (eg. making the syntax of cdda2wav options incompatible and sell this as
> "correct" syntax). We (developers, users) are existing facts.
You are not a developer - sorry.
If you fail to read the official documentation, you are not even a user.
If you prove to ignore to read the documentation for more than 6 years,
you are obviously an ig*****t
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
