Bill Davidsen <[EMAIL PROTECTED]> wrote: > >>The full set of Debian patches against cdrecord are: > >> > >>02_cdrecord_default_conf.dpatch: > >> Set up reasonable default values in the cdrecord config > >> > >> > > > >It is unreasonable to deviate from a standard OS independen default. > >---> rejected > > > > > Do you not see you look like a fool on this? You put in Linux dependent > stuff which is totally WRONG (see below) but you say configuration which > SHOULD be how the program learns about the environment must not contain > useful information about the execution environment.
Calm down and try to get informed about what we are talking. > >>06_dautipps.dpatch: > >> Little patch to extend error information > >> > >> > > > >This patch causes incorrect output > >---> rejected > > > > > You spelled "useful" wrong, s/incorrect/useful/ Try to have a look at the patch in question and try to understand the result before answering. > >17_argv0_beautify.dpatch: > > Remove the Debian specific suffix from the executable filename > > > > > > > >A patch caused by the fact that Debian is missing fundamental knowledge on > >version incompatibility and is uneducatable! > > > >You cannot expect a cdrecord compiled on Linux version N to run on Linux > >version N - X > > > > > You can if the person who designed the build system is competent. If you are competent, please try to help me to educate the Debian people to set up a correct build system. Meanwhile you seem to agree that this patch is nonsense! > >>18_donotopen_hda.dpatch: > >> dev=ATA:1,0,0 uselessly opens /dev/hda, breaking non-root > >> access. See #228215 > >> > >> > > > >Trying to patch a problem caused by incorrecty usage (the man page clearly > >states which provilleges you need to run cdrecord). > >---> rejected > > > > > So the program needs extra permissions because you aren't competent > enough to avoid doing something not needed? Well I am competent enough but I am not sure if you are... Maybe it helps if you try to first understand the duty of a platform and device independent SCSI generic transport library. .... [unrelated whening removed] ... > >>22_linux_rawio_capability.dpatch: > >> Add linux specific rawio capability allocation to work with > >> kernels > 2.6.8 > >> > >> > > > >Needed only because fine grained privileges are not yet ready for general > >use. It is a general rule to wait until a newe feature has grown up from > >the experimental state. > >---> rejected > > > > > Again, this is the correct way to get capabilities, programmers who are > living in the past don't know about it. Try to inform yourself about how fine grained privileges work and how to run programs like cdrecord root-less. You are correct, it seems that you are living in the past and still need to understand some basics in fine grained privileges. > >>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 > > > > > That's stupid, you can't fix or even IDENTIFY all programs ever written > to prevent problems. Shows a total understanding of how the real world > works. Well, it is stupid to try to patch cdrecord in a way that causes cdrecord to fail in documented use cases. It seems that you did not yet understand how to reliably maintain larger systems. > Another case of not having the skill to adapt the application to fixes > in the O/S. Try to understand documented interfaces and try to understand that an OS that partially implements interfaces not to follow the documented way needs to be called broken. > Unfortunately it's clear that you learned how to interface with the > kernel a decade ago and are not longer able to keep up with the > technology. Symtpoms of alzheimer's include inability to adapt to change > and being argumentative. Time to find a version of the tools which are > maintained to work as things are, rather than as someone would like them > to be. Thanks for the work you did in your prime. Well, it is obviously you who did not learn during the last years. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]