#include <hallo.h> * Joerg Schilling [Sun, Apr 09 2006, 03:08:15PM]: > 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... > Let it repeat it for your convenience: ... for your convenience I will comment them. > 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). > 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. > 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. > 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. > 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. > 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. > 20_rsh-bugfix.dpatch Unneeded, may break things I don't remember who introduced it and why. Steve: any hints? > 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."...). > 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. > 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. > 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. > 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? > 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. > 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. > 31_gnu-kfreebsd.dpatch Does not do the right things > and rather > breaks things It solved problems. How does your proper solution look like? > 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. > 34_JTE.dpatch Looks like something that breaks > mkisofs There is no smoke, no core file, so I cannot see anything breaking. > 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. > 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. I cannot see much there (except of the locking patch related). Maybe you meant http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cdrtools&archive=yes ? > For the rest of the problems I encourage you to read the official > manual pages and the official documentation for cdrtools. 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. > 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. Please stop using terms "incorrectly" and "problem" if your definition of those terms is based purely on your personal views. Eduard. -- <frobnic> zXalfiSh: du willst Emacs und Gnus. <zXalfiSh> emacs? ich will n newsreader, kein betriebssystem... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
