From jeroen@dekkers.cx Mon Mar 18 16:23:19 2002
Do you want to know the way Debian works? You fix it yourself and tell the patch to the maintainer about it. The maintainer intergrates it and all users get the fix. As soon as the Debian maintainer intergrates the patch it's available in Debian unstable. Debian maintainers must forward patches upstream, so the upstream developers
Sorry, but I am forced to repeat me:
The Debian Bug list is badly managed (at least for cdrecord) and it does not help to keep cdrecord bug-free. Tehy never removed remarks for bugs that never exists but are a result of missunderstood or unread documentation.
If you patch is right it won't be difficult to convince the maintainer if the maintainer isn't an asshole!!
So you just made a statement anbout the GNU make maintainer. I send him a description for an algorithm that fiyes the problem and would allow somebody who knows the program to create a fix in less than 3 hours.
It works perfect if you use a limited set of features.=20
It doesn't work if you try to use a feature which it does *NOT* have.
Again: we are talking about dcumented features!
before they were able to reproduce a problem using my smake.
Is the thing which doesn't work in GNU make a documented feature?
Y E S
What is wrong with this way and why do you constantly tell people to do things that won't work in real world?=20
If it works for you, then stop complaining about the bugs in GNU make. I only tell that if you have problems with GNU make you should fix them yourself. If you want to use another piece of software, happily do so. Just don't promote non-free software on this list which goes about free software.
You again start to reverse facts:
I stopped complaining about GNU make 3 years ago and don't take GNUmake for serious anymore.
YOU are the person who asked me to use the buggy GNU make and thus forced me to explain why I don't like this.
What do you mean with "multi-platform environment"? According to my experience developping glibc parts the build system works fine. If you have suggestions to improve it you're always welcome of course.
READ the schily makefile documentation!
I am talking about features of this system (e.g. untar the archive and then fire up a 'make' on all supported platforms simultaneously whithout the need to di more than just call 'make'):
What's difficult to understand about this?
YOu have difficulties to understand, so you need to answer this question yourself.
Well the authors of GDB restrict me because it is the only debugger avail=
able=20
on Linux and because I cannot do the things I expect a debugger to do.
Don't redefine restrict.
I don't do it sorry but you sesm to fail to understand the meaning of the word. GDB _is_ a restricted debugger because it has a limited set of features that restrict me when I try to use it.
If you have a system when there isn't a limit on the path and PATH_MAX doesn't exist, realpath() doesn't work correctly then. You've no way to be sure the buffer doesn't overflow, it's even a security risk.
If PATH_MAX does not exist, then pathconf() must work to return the needed value.
Many GNU users have this wrong assumption, this is why I am more and more angry with the people who wrote documentation tha makes users believe untrue things about the GNU programs...
I hope you aren't in the group of people who just named and can give an example of the POSIX incompatible thing when using tar with the --posix option.
All information you need is in the star distribution. I am sorry, but I am at CeBIT and it takes too much time to constantly repeat facts known and described since (at least) 1993....
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) If you don't have iso-8859-1 schilling@fokus.gmd.de (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
FOKUS at CeBIT Hall 11, A14 - BerliOS at CeBIT Hall 11 D11 (Future Market)
Meet me at CeBIT in Hall 11 D11 on the BerliOS booth - www.berlios.de
Joerg Schilling schilling@fokus.gmd.de wrote:
The Debian Bug list is badly managed (at least for cdrecord) and it does not help to keep cdrecord bug-free. Tehy never removed remarks for bugs that never exists but are a result of missunderstood or unread documentation.
Did they accept your claim that these bugs "never exist[ed]"? If so, have you asked the maintainer andersee@debian.org why the bugs are not closed? If there was no answer, have you asked debian-qa about it? Now, maybe I'm missing something, but the BTS doesn't show any entries from you on any of the important bugs, nor on a random sample of normal bugs.
Also, I note that there are bugs filed against your documentation. Maybe it is not as good as it could be. Have you considered getting someone else to review and improve it?
I send him a description for an algorithm that fiyes the problem and would allow somebody who knows the program to create a fix in less than 3 hours.
We're only getting one side of the story here, I know, but what was the response? You've already hinted elsewhere that the fix would take severe internal restructuring. I assume other things would break, at least temporarily.
On Tue, Mar 19, 2002 at 09:28:11AM +0100, Joerg Schilling wrote:
If you have a system when there isn't a limit on the path and PATH_MAX doesn't exist, realpath() doesn't work correctly then. You've no way to be sure the buffer doesn't overflow, it's even a security risk.
If PATH_MAX does not exist, then pathconf() must work to return the needed value.
Yes, it returns -1 on the Hurd, as it should.
I have never seen a non-GNU program that does deal with this correctly, except the examples in Stevens.
Thanks, Marcus