Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Ambrose Li wrote: On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote: True -- *but*, it must be pointed out that this is historic! In a modern GNU/Linux distribution, /usr/include/linux should *not* be a symlink to anything at all. It should be a plain directory containing the kernel header files with which the GNU libc was built. If this is true, I must respectfully point out that the real problem is libc6. I upgraded my system to libc6 by hand, and I *never* saw any advice (or "instruction" should be a better word) to make /usr/include/linux a real directory, nor any advice to keep the libc6-compile-time kernel header files anywhere, nor any advice where to put the current kernel header files. Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is "there is a standard." If such a drastic change in convention had taken place and I have never read about it when I did my upgrade (which was not very long ago -- I put off upgrading to libc6 until very recently, and I did google for advice for fear of breaking my system), then I have to agree with Joerg that Linux is being very inconsistent, but I will say that the greatest problem is not in the kernel, but in libc6. Without getting into a flame war, he is saying that and then depending on installs to behave in some predictable manner which seems to be blaming Linux (which does have a standard) rather than doing defensive programming. This also implies that cross compilation seems to need source edits, since having /usr/src/linux is optional and would point to the running kernel on the source system if present. It would make life easier for both Joerg and users to state that if the /usr/include/linux headers are not correct for the kernel on which the application will run, then the user must provide the information. As an example: CDRTOOLS_KERNEL_INC=/root/my_2.6_includes make Joerg is willing to put the responsibility for reading the multitude of README files on the user; many times he will point out that someone didn't follow README.multi or similar, and I think he is right. But he doesn't put the responsibility on the user to provide include pointers, and I think that's wrong. cdrtools should use /usr/include/linux unless told otherwise. Trying to guess which headers to use frustrates both the developer and the users, as the endless threads show. Another approach would be to require the user to create a symlink to the includes in the cdrtools directory. And just don't compile until that's done. It not only gives the user a way to get it right, it forces the user to think, which is probably a good thing. Odd distributions are a fact of life, and old distributions which have been updated are, too. I think we have proven that the build system can't correct for all the things people do, so why not make the user supply the information? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Thanos Kyritsis wrote: On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? If FHS is the "right" one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. That's not at all what you need! You need to compile with the headers for the target kernel, where the application will run, not for the host machine. Now in most cases thay are the same, but you will continue to have problems unless you inderstand this point. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Incs not at all what you need, you need the Doing interesting things with small computers since 1979
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Actually that info is in the Linux file standard, which has been available for some years. There are some distributions which don't follow that, all I can say is there is a standard. Absolutely. Adhering to the standard should be primary concern, the rest is secondary. cdrtools should use /usr/include/linux unless told otherwise. Yes Odd distributions are a fact of life I maintain that it's the user's responsibility to supply correct headers for the kernel the binary *is being compiled for*. As said before, who said I'm compiling for the running kernel? Users who don't have the clue for this should either use a distro which works, or a pre-compiled binary. Apps should be able to be told where those headers are. Apps saying the headers must be in /usr/src/include aren't all that smart, but it's usable. I return, this also means that software maintainers can't expect everyone to be able to compile the latest alpha^5 version. Saying come back once you've compiled and tried this alpha^5 is unrealistic. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Wed, Jan 28, 2004 at 02:58:45PM +1300, Volker Kuhlmann wrote:
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
J?rg's problem.
Sorry, _what_ remains Debian's problem and responsibility? Debian has
always been among the first of the distros to follow FHS, and it has
been a long-established feature of Debian that
/usr/include/{linux,asm} are _not_ just sym-links to potentially wrong
kernel source...
--
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
We don't need no education.
We don't need no thought control.
pgp0.pgp
Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi,
It may be a little tricky on distributions not coming from a commercial
source, like Debian.
Maybe, but it remains entirely Debian's problem and responsibility to
sort out. It's by no means impossible. In any case, as you say, not
J?rg's problem.
Sorry, _what_ remains Debian's problem and responsibility? Debian has
always been among the first of the distros to follow FHS, and it has
been a long-established feature of Debian that
/usr/include/{linux,asm} are _not_ just sym-links to potentially wrong
kernel source...
Debian was a hypothetical example. Nowhere did we say it had a problem
today. I can see that on my Woody box /usr/include/(linux,asm) are not
symlinks. Debian is good in that it is one of the few distributions
which discuss their policies toward reaching compliance out in the open.
The point being made was that it may be harder for non-commercial
distributions to comply with emerging standards, and if so, it really
should not be app developers' responsibility to kludge around.
I propose we end this thread as it has seriously diverged from anything
relating to cd/dvd writing. We can discuss these things all day but
for now it is Joerg who will decide how and whether cdrtools mainline
supports the varying Linux distributions.
pgp0.pgp
Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
I have a very high respect for Joerg. But please let me comment a little on this. Back in the former times (I started using GNU/Linux back when the only distros were SLS and Slackware), apps assumed that the kernel header files are in a linux directory in the system include path (the /usr/include/linux symlink, unless the user has a very strange setup). They need not assume there is anything in /usr/src/linux, though /usr/include/linux is likely a symlink to /usr/src/linux/include/linux. And I have never heard of anyone hard-coding /usr/src/sys (nor have I heard of such a directory at all) in their makefiles. I have never encountered any app that has such an elaborate setup to detect where the kernel include files are; I would tend to say that such elaborate setup is unnecessary. If the system in question is so broken as to not make the kernel include files accessible via a simple #include linux/some-file.h, it will have problems compiling all kernel-dependent software, not just cdrtools: Systems that are broken to such an extent do not deserve to be supported by an elaborate makefile system; a simple FAQ entry would suffice. On Sun, Jan 25, 2004 at 07:30:48PM +0100, Joerg Schilling wrote: You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tue, Jan 27, 2004 at 09:01:56AM -0500, Ambrose Li wrote:
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the /usr/include/linux symlink, unless the
user has a very strange setup). They need not assume there is
anything in /usr/src/linux, though /usr/include/linux is likely
a symlink to /usr/src/linux/include/linux.
True -- *but*, it must be pointed out that this is historic! In a
modern GNU/Linux distribution, /usr/include/linux should *not* be
a symlink to anything at all. It should be a plain directory containing
the kernel header files with which the GNU libc was built.
Every once in a while, someone comes along with a seriously broken
Debian system because they followed the advice in some old Slackware
HOWTO document from 1997, and made /usr/include/{linux,asm} symlinks
to some kernel source tree they happened to find somewhere. The
only fix for it is to remove the symlinks they made by hand, and
reinstall the libc6-dev package. (And in unstable now, the
linux-kernel-headers package.)
And I have never
heard of anyone hard-coding /usr/src/sys (nor have I heard of
such a directory at all) in their makefiles.
That's where BSD keeps its kernel source tree. BSD is dramatically
more consistent than GNU/Linux.
I have never encountered any app that has such an elaborate
setup to detect where the kernel include files are; I would tend
to say that such elaborate setup is unnecessary.
Not quite true. As has already been pointed out in this discussion,
there are different kinds of applications, and they need to use
different kinds of header files.
Most applications (like hello, world) just use #include stdio.h
and so on. These headers come from the libc development package. This
case is easy.
Kernel modules need kernel headers -- specifically, they need the exact
kernel headers for the kernel that the module is going to be loaded into.
But there's no way of knowing exactly *where* the correct set of kernel
headers can be found, unless the sysadmin takes action when compiling
the module. With Linux 2.4.x, there's a build symlink under the
/lib/modules tree which (theoretically) points back to /usr/src/linux-2.4.x
or wherever the kernel source tree was configured. Failing that, the
kernel headers may be in a package (e.g. kernel-headers-2.4.18-bf2.4 in
Debian), which when installed will put them in a directory such as
/usr/src/kernel-headers-2.4.18-bf2.4/. Or they may be in /usr/src/linux/.
Or they may be in /home/fred/kernels/. There's no way to be sure,
so in the worst case the sysadmin who's building the module *WILL*
have to supply a -I flag to gcc.
Then there's a funky kind of application which seems to be in both user
space (like hello, world) *and* kernel space at the same time. It
uses normal libc headers, but it also uses kernel headers. cdrecord
seems to be one of these kinds of applications. I don't know *what*
the right way to build these kinds of applications is -- and I don't
think there's any concensus among the various developers either.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tue, Jan 27, 2004 at 10:06:46AM -0500, Greg Wooledge wrote: True -- *but*, it must be pointed out that this is historic! In a modern GNU/Linux distribution, /usr/include/linux should *not* be a symlink to anything at all. It should be a plain directory containing the kernel header files with which the GNU libc was built. On Tue, Jan 27, 2004 at 12:04:29PM -0500, Ambrose Li wrote: If such a drastic change in convention had taken place and I have never read about it when I did my upgrade (which was not very long ago -- The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: usr/include : Header files included by C programs These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc. /usr/include/asm - /usr/src/linux/include/asm-arch /usr/include/linux - /usr/src/linux/include/linux I read this as saying if you're using glibc at all you should no longer have or use the symlinks. Most modern distributions will both be using glibc and striving for LSB/FHS compliance. (I'm pretty sure if you dig around you'll find older PRs from RedHat/SuSE/Mandrake/Debian regarding LSB 1.0 compliance). -Robert pgp0.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Yes, myself is to blame for not checking the updated FHS. But why would anyone upgrading from libc5 to libc6 suspect that a change in the FHS should affect the upgrade (esp. if the libc6 docs do not refer to the FHS)? So my main complaint will be that I'll need to dig around per se, in unknown places for random upgrades. If upgrading to libc6 means I should rm the symlink, the libc6 docs should point this out, or at least refer me to the LHS. I didn't see either when I did the upgrade. On Tue, Jan 27, 2004 at 10:39:15AM -0800, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: usr/include : Header files included by C programs These symbolic links are required if a C or C++ compiler is installed and only for systems not based on glibc. /usr/include/asm - /usr/src/linux/include/asm-arch /usr/include/linux - /usr/src/linux/include/linux I read this as saying if you're using glibc at all you should no longer have or use the symlinks. Most modern distributions will both be using glibc and striving for LSB/FHS compliance. (I'm pretty sure if you dig around you'll find older PRs from RedHat/SuSE/Mandrake/Debian regarding LSB 1.0 compliance). -Robert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tue 27 January 2004 21:41, Robert S. Dubinski wrote: On Tue, Jan 27, 2004 at 03:10:42PM -0500, Ambrose Li wrote: Yes, myself is to blame for not checking the updated FHS. But why would anyone upgrading from libc5 to libc6 suspect that a change in the FHS should affect the upgrade (esp. if the libc6 docs do not refer to the FHS)? So my main complaint will be that I'll need to dig around per se, in unknown places for random upgrades. If upgrading to libc6 means I should rm the symlink, the libc6 docs should point this out, or at least refer me to the LHS. I didn't see either when I did the upgrade. The standard response to that is, Leave it to your friendly distribution vendor to take care of. If you're interested in upgrading libc yourself, then you're usually at the point of rolling your own distribution, and might want to concern yourself with LSB/FHS. Yeah, locating all these docs can be a bear, but if you don't do things by hand and instead use a major distribution vendor, you really shouldn't have to worry. But how is the vendor supposed to know that GNU libc6 requires the files to be oriented according to the FHS? That should be in the glibc docs, period. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? If FHS is the right one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. -- Kyritsis Athanasios djart at linux.gr Studying Electrical Computer Engineering @ Univ. of Patras, Greece -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. Yes, I agree with Jörg on this one. Header files are there for a reason, and that is for programs which need them to pick up the definitions contained in them. Doing away with them because someone isn't able to handle the resulting mess is just incredbily bad design, and something which one could conceivably call a Microsoft solution. Users who need to recompile programs are required to have a minimum of programming knowledge. If they don't, they ought to be using an out of the box distro (which will have correct headers in the correct place), or else put up with their own mess themselves. I have no sympathy with users who do otherwise, there are much more important things to do. -- You use a broken system, your problem. Distributions exist for those who can't handle doing things manually (or don't want to). Whether headers in XYZ match the running kernel is technically also irrelevant. I may have 3 different kernels installed and be running a 4th one, while compiling a program for kernel 2. It is my responsibility to ensure the compile environment (gcc supports many of those) I am using is consistent for kernel 2. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, But how is the vendor supposed to know that GNU libc6 requires the files to be oriented according to the FHS? That should be in the glibc docs, period. Who said glibc requires the files be arranged a certain way according to FHS? The original statement I responded to a few posts ago was: GW In a modern GNU/Linux distribution, /usr/include/linux should GW *not* be a symlink to anything at all. If glibc really requires things a certain way, that's not a very flexible package. I don't think we proved that yet (though I admittedly follow the threads loosely). The distribution vendors know what to do because they have a person or team which subscribe to the Standards orgs and go over the guideline docs for changes which conflict with their current way of doing things. Looking at the membership list of the Free Standards Group (which promotes LSB and FHS), you'll see both RedHat and SuSE (among others) are Gold members. You typically don't invest to become a Gold member of some organization unless you're serious about it. Consider that their recent distributions have been LSB certified...so obviously they found out somewhere sometime how things are supposed to be laid out. Indeed, the /usr/include/linux and /usr/include/asm on my RedHat AS/ES/WS 3.0 machines are actual directories and not symlinks as used to be done in the Good Ol' Days. It would be nice for glibc to give a Release Note about the change in the symlinks, but to say it *must* be there relies on three things: 1) that the Standard came out before the glibc package was released. 2) that the chosen Standard is The One and Only Standard that doesn't ever compete with some alternate FooStandard 3) that glibc is a linux-only package and has some specific tie to Linux kernel headers My intent in mentioning LSB/FHS in my first post was to not really take any side of this particular argument, but to point out that they exist to attempt to bring some order to the chaos that's been Linux distribution layouts. Once that order is adopted by the big fish in the Linux world, any workarounds cdrtools or others have employed should be unnecessary. I don't agree or disagree what's the proper way to do things, but I do take exception to some commonly seen viewpoints on this mailing list that Linux will forever remain an unorderly pile of goo compared to say, oh, Solaris. -Robert pgp0.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, On Tue, Jan 27, 2004 at 11:32:37PM +0200, Thanos Kyritsis wrote: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? Well, that one appears to be a compilation from various sources. Unfortunately it neglects the linux-specific section in FHS doc about kernel headers. The doc to consider is that linked from the official LSB site. Docs on tldp are not always on-target and unbiased (the former PHP HOWTO) or up-to-date (such as my own contribution there). We need to consider what big players might be certifying against, which at this time appears to be LSB and FHS. If FHS is the right one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, probably because it's supposed to be very broad at first to try to rein in the big distro makers. Once enough players have taken care of the big chunks, work can begin on nailing the nitty-gritty details. Also, remember FHS is but one part of the whole LSB. It'll get more accurate with time, surely. But it has to start somewhere. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. Yes, I agree. -- - Robert S. Dubinski * [EMAIL PROTECTED] * http://dubinski-family.org Note to Anonymous: That virus I sent you is actually what is called a Digital Signature. Please look the term up and get educated before making more an ass of yourself. - Random Quote for you: Two farmers are fighting over a cow. One grabs the cow's tail and pulls while the other farmer grabs the cow's head and pulls. This last for a long time. While all this pulling is going on, the two farmers' lawyers sit in the middle and milk it. pgp0.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, On Wed, Jan 28, 2004 at 12:41:17PM +1300, Volker Kuhlmann wrote: Users who need to recompile programs are required to have a minimum of programming knowledge. If they don't, they ought to be using an out of the box distro (which will have correct headers in the correct place), or else put up with their own mess themselves. I agree. It should be assumed headers are in the correct place, once that correct place is properly defined. As this thread has brought up, there are Standardization efforts (LSB/FHS) to work that out. I have no sympathy with users who do otherwise, there are much more important things to do. -- You use a broken system, your problem. Distributions exist for those who can't handle doing things manually (or don't want to). If one configures their system in such a strange way that things break, it should not be the responsibility of developers like Joerg to try and cater to. It may be a little tricky on distributions not coming from a commercial source, like Debian. But again, this shouldn't be Joerg's problem to deal with. Those distributions or roll-your-own configurations that don't follow an emerging Standard should learn to live with their Brokenness. Whether headers in XYZ match the running kernel is technically also irrelevant. I may have 3 different kernels installed and be running a 4th one, while compiling a program for kernel 2. It is my responsibility to ensure the compile environment (gcc supports many of those) I am using is consistent for kernel 2. Agreed. And for Some Big Enterprise going through a commercial Linux distribution vendor, they're probably not going to muck around with incompatible kernels anyways. If they do so and break things, their fault again. -Robert pgp0.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
It may be a little tricky on distributions not coming from a commercial source, like Debian. Maybe, but it remains entirely Debian's problem and responsibility to sort out. It's by no means impossible. In any case, as you say, not Jörg's problem. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
I have a very high respect for Joerg. But please let me comment a little on this. Back in the former times (I started using GNU/Linux back when the only distros were SLS and Slackware), apps assumed that the kernel header files are in a linux directory in the system include path (the /usr/include/linux symlink, unless the user has a very strange setup). They need not assume there is anything in /usr/src/linux, though /usr/include/linux is likely a symlink to /usr/src/linux/include/linux. And I have never heard of anyone hard-coding /usr/src/sys (nor have I heard of such a directory at all) in their makefiles. I have never encountered any app that has such an elaborate setup to detect where the kernel include files are; I would tend to say that such elaborate setup is unnecessary. If the system in question is so broken as to not make the kernel include files accessible via a simple #include linux/some-file.h, it will have problems compiling all kernel-dependent software, not just cdrtools: Systems that are broken to such an extent do not deserve to be supported by an elaborate makefile system; a simple FAQ entry would suffice. On Sun, Jan 25, 2004 at 07:30:48PM +0100, Joerg Schilling wrote: You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster.
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tue, Jan 27, 2004 at 09:01:56AM -0500, Ambrose Li wrote:
Back in the former times (I started using GNU/Linux back
when the only distros were SLS and Slackware), apps assumed
that the kernel header files are in a linux directory in the
system include path (the /usr/include/linux symlink, unless the
user has a very strange setup). They need not assume there is
anything in /usr/src/linux, though /usr/include/linux is likely
a symlink to /usr/src/linux/include/linux.
True -- *but*, it must be pointed out that this is historic! In a
modern GNU/Linux distribution, /usr/include/linux should *not* be
a symlink to anything at all. It should be a plain directory containing
the kernel header files with which the GNU libc was built.
Every once in a while, someone comes along with a seriously broken
Debian system because they followed the advice in some old Slackware
HOWTO document from 1997, and made /usr/include/{linux,asm} symlinks
to some kernel source tree they happened to find somewhere. The
only fix for it is to remove the symlinks they made by hand, and
reinstall the libc6-dev package. (And in unstable now, the
linux-kernel-headers package.)
And I have never
heard of anyone hard-coding /usr/src/sys (nor have I heard of
such a directory at all) in their makefiles.
That's where BSD keeps its kernel source tree. BSD is dramatically
more consistent than GNU/Linux.
I have never encountered any app that has such an elaborate
setup to detect where the kernel include files are; I would tend
to say that such elaborate setup is unnecessary.
Not quite true. As has already been pointed out in this discussion,
there are different kinds of applications, and they need to use
different kinds of header files.
Most applications (like hello, world) just use #include stdio.h
and so on. These headers come from the libc development package. This
case is easy.
Kernel modules need kernel headers -- specifically, they need the exact
kernel headers for the kernel that the module is going to be loaded into.
But there's no way of knowing exactly *where* the correct set of kernel
headers can be found, unless the sysadmin takes action when compiling
the module. With Linux 2.4.x, there's a build symlink under the
/lib/modules tree which (theoretically) points back to /usr/src/linux-2.4.x
or wherever the kernel source tree was configured. Failing that, the
kernel headers may be in a package (e.g. kernel-headers-2.4.18-bf2.4 in
Debian), which when installed will put them in a directory such as
/usr/src/kernel-headers-2.4.18-bf2.4/. Or they may be in /usr/src/linux/.
Or they may be in /home/fred/kernels/. There's no way to be sure,
so in the worst case the sysadmin who's building the module *WILL*
have to supply a -I flag to gcc.
Then there's a funky kind of application which seems to be in both user
space (like hello, world) *and* kernel space at the same time. It
uses normal libc headers, but it also uses kernel headers. cdrecord
seems to be one of these kinds of applications. I don't know *what*
the right way to build these kinds of applications is -- and I don't
think there's any concensus among the various developers either.
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On Tuesday 27 January 2004 20:39, Robert S. Dubinski wrote: The Filesystem Hierarchy Standard document version 2.3 of the Linux Standard Base project (http://www.linuxbase.org/) lists the following: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? If FHS is the right one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. -- Kyritsis Athanasios djart at linux.gr Studying Electrical Computer Engineering @ Univ. of Patras, Greece
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, But how is the vendor supposed to know that GNU libc6 requires the files to be oriented according to the FHS? That should be in the glibc docs, period. Who said glibc requires the files be arranged a certain way according to FHS? The original statement I responded to a few posts ago was: GW In a modern GNU/Linux distribution, /usr/include/linux should GW *not* be a symlink to anything at all. If glibc really requires things a certain way, that's not a very flexible package. I don't think we proved that yet (though I admittedly follow the threads loosely). The distribution vendors know what to do because they have a person or team which subscribe to the Standards orgs and go over the guideline docs for changes which conflict with their current way of doing things. Looking at the membership list of the Free Standards Group (which promotes LSB and FHS), you'll see both RedHat and SuSE (among others) are Gold members. You typically don't invest to become a Gold member of some organization unless you're serious about it. Consider that their recent distributions have been LSB certified...so obviously they found out somewhere sometime how things are supposed to be laid out. Indeed, the /usr/include/linux and /usr/include/asm on my RedHat AS/ES/WS 3.0 machines are actual directories and not symlinks as used to be done in the Good Ol' Days. It would be nice for glibc to give a Release Note about the change in the symlinks, but to say it *must* be there relies on three things: 1) that the Standard came out before the glibc package was released. 2) that the chosen Standard is The One and Only Standard that doesn't ever compete with some alternate FooStandard 3) that glibc is a linux-only package and has some specific tie to Linux kernel headers My intent in mentioning LSB/FHS in my first post was to not really take any side of this particular argument, but to point out that they exist to attempt to bring some order to the chaos that's been Linux distribution layouts. Once that order is adopted by the big fish in the Linux world, any workarounds cdrtools or others have employed should be unnecessary. I don't agree or disagree what's the proper way to do things, but I do take exception to some commonly seen viewpoints on this mailing list that Linux will forever remain an unorderly pile of goo compared to say, oh, Solaris. -Robert pgpkQm3Ojz24b.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, On Tue, Jan 27, 2004 at 11:32:37PM +0200, Thanos Kyritsis wrote: As a matter of fact, there is also this document: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html Now, which one is the right one ?? Well, that one appears to be a compilation from various sources. Unfortunately it neglects the linux-specific section in FHS doc about kernel headers. The doc to consider is that linked from the official LSB site. Docs on tldp are not always on-target and unbiased (the former PHP HOWTO) or up-to-date (such as my own contribution there). We need to consider what big players might be certifying against, which at this time appears to be LSB and FHS. If FHS is the right one, it's obvious it's not complete, but on the contrary it's too general and fails to set a suitable standard for modern Linux distros. Well, probably because it's supposed to be very broad at first to try to rein in the big distro makers. Once enough players have taken care of the big chunks, work can begin on nailing the nitty-gritty details. Also, remember FHS is but one part of the whole LSB. It'll get more accurate with time, surely. But it has to start somewhere. Well, I think what Joerg wants to say is clear: Some standard needs to finally direct everyone as to where the running kernel sources are. There are many applications that need the running kernel sources and not /usr/include/linux. Yes, I agree. -- - Robert S. Dubinski * [EMAIL PROTECTED] * http://dubinski-family.org Note to Anonymous: That virus I sent you is actually what is called a Digital Signature. Please look the term up and get educated before making more an ass of yourself. - Random Quote for you: Two farmers are fighting over a cow. One grabs the cow's tail and pulls while the other farmer grabs the cow's head and pulls. This last for a long time. While all this pulling is going on, the two farmers' lawyers sit in the middle and milk it. pgpq3sv359Yy4.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Hi, On Wed, Jan 28, 2004 at 12:41:17PM +1300, Volker Kuhlmann wrote: Users who need to recompile programs are required to have a minimum of programming knowledge. If they don't, they ought to be using an out of the box distro (which will have correct headers in the correct place), or else put up with their own mess themselves. I agree. It should be assumed headers are in the correct place, once that correct place is properly defined. As this thread has brought up, there are Standardization efforts (LSB/FHS) to work that out. I have no sympathy with users who do otherwise, there are much more important things to do. -- You use a broken system, your problem. Distributions exist for those who can't handle doing things manually (or don't want to). If one configures their system in such a strange way that things break, it should not be the responsibility of developers like Joerg to try and cater to. It may be a little tricky on distributions not coming from a commercial source, like Debian. But again, this shouldn't be Joerg's problem to deal with. Those distributions or roll-your-own configurations that don't follow an emerging Standard should learn to live with their Brokenness. Whether headers in XYZ match the running kernel is technically also irrelevant. I may have 3 different kernels installed and be running a 4th one, while compiling a program for kernel 2. It is my responsibility to ensure the compile environment (gcc supports many of those) I am using is consistent for kernel 2. Agreed. And for Some Big Enterprise going through a commercial Linux distribution vendor, they're probably not going to muck around with incompatible kernels anyways. If they do so and break things, their fault again. -Robert pgps3qiXj8YpL.pgp Description: PGP signature
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
It may be a little tricky on distributions not coming from a commercial source, like Debian. Maybe, but it remains entirely Debian's problem and responsibility to sort out. It's by no means impossible. In any case, as you say, not Jörg's problem. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Joerg Schilling wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. 2) The include files under /usr/src/linux are definitely more recent resp. closer to the currently run kernel than what typically is under /usr/include That's what everyone is trying to tell you, there is no guaranty that those files are correct for the current running kernel. Or that they even exist! 3) I am writing portable software. This means that it is portable even between different Linux versions. 4) What people like Linus Torvalds tell me on how I should compile, is definitely much much more incorrect than what I am currently doing. 5) The problems are a result of _inconsistent_ unclude files in /usr/src/linux, which I call a clear Bug that needs to be fixed. Which is why all the kernel people keep telling you (and everyone else) not to use these files, every distribution and many users do something different. And other applications do run fine even if there is no kernel source at /usr/src/linux. Having *anything* at /usr/src/linux is not required, so you are complaing that something which is random is inconsistent. Yes it is, because you're not supposed to use it! Got it? 6) If you did ever try to write a program that uses interfaces that need /usr/src/linux to compile and run correctly you would probably never repeat the wrong statements from people from LKML. I would never write a program which depends on something random, it isn't reliable. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: [EMAIL PROTECTED] On 23. January 2004 at 5:40PM +0100, Joerg Schilling [EMAIL PROTECTED] wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. I don't have /usr/src/linux and I'm able to build cdrtools from source. What am I missing (Debian)? You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster. If you have /usr/src/linux, then there is a 99% chance that it is the source for the surrently running kernel. People who deviate from this rule need to know what they are doing. The main problem with Linux is a result of the fact that a lot of people believe that it is possible to replace the Kernel with a different version without creating problems with the interfaces to the applications. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From [EMAIL PROTECTED] Sun Jan 25 14:49:03 2004 Please don't comment things you obviously don't really understand. 1)The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. 2)The include files under /usr/src/linux are definitely more recent resp. closer to the currently run kernel than what typically is under /usr/include That's what everyone is trying to tell you, there is no guaranty that those files are correct for the current running kernel. Or that they even exist! See below... 3)I am writing portable software. This means that it is portable even between different Linux versions. 4)What people like Linus Torvalds tell me on how I should compile, is definitely much much more incorrect than what I am currently doing. 5)The problems are a result of _inconsistent_ unclude files in /usr/src/linux, which I call a clear Bug that needs to be fixed. Which is why all the kernel people keep telling you (and everyone else) not to use these files, every distribution and many users do something different. And other applications do run fine even if there is no kernel source at /usr/src/linux. Having *anything* at /usr/src/linux is not required, so you are complaing that something which is random is inconsistent. Yes it is, because you're not supposed to use it! Got it? Yes, it is really hard to take you for serious as you constantly prove that you are not aware on how the compilation of cdrtools in Linux works :-( Your notes obviously don't aply. Before you write another reply to this thread, it would really help if you first try to understand how the compilation is done on Linux systems. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-announces] Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: Joerg Schilling [EMAIL PROTECTED] Subject: [Cdrecord-announces] Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible Date: Sun, 25 Jan 2004 19:40:20 +0100 (CET) OH, yeah. give me more more more of this !!! I like this kind of conversione, where everyone is telling of being the only one knowing the truth!!! Please DONT STOP THIS! MORE THREADFIGHTS ! :) More seriously: How often had this kind of fight has taken place? How much enlightment has been spread under all those, who have any other not so enriched knowledge ? How often did Joerg really know all bachgrounds, standards, real ways of programming and ways to set up things ? It is really regardless. Stop fight and come back to daily work. I have a submitted a -- corrected -- patch. Poeple who wants to use it: Use it -- it is yours. And Joerg is free not to use it -- for what reason ever. PLEASE DONT EXPLAIN WHY OR WHY NOT ANY MORE! Stop this thread at a point, when everyone involved can still be taken serious... Slightly amused, Meino -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
Joerg Schilling wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. 2) The include files under /usr/src/linux are definitely more recent resp. closer to the currently run kernel than what typically is under /usr/include That's what everyone is trying to tell you, there is no guaranty that those files are correct for the current running kernel. Or that they even exist! 3) I am writing portable software. This means that it is portable even between different Linux versions. 4) What people like Linus Torvalds tell me on how I should compile, is definitely much much more incorrect than what I am currently doing. 5) The problems are a result of _inconsistent_ unclude files in /usr/src/linux, which I call a clear Bug that needs to be fixed. Which is why all the kernel people keep telling you (and everyone else) not to use these files, every distribution and many users do something different. And other applications do run fine even if there is no kernel source at /usr/src/linux. Having *anything* at /usr/src/linux is not required, so you are complaing that something which is random is inconsistent. Yes it is, because you're not supposed to use it! Got it? 6) If you did ever try to write a program that uses interfaces that need /usr/src/linux to compile and run correctly you would probably never repeat the wrong statements from people from LKML. I would never write a program which depends on something random, it isn't reliable. -- E. Robert Bogusta It seemed like a good idea at the time
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: [EMAIL PROTECTED] On 23. January 2004 at 5:40PM +0100, Joerg Schilling [EMAIL PROTECTED] wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. I don't have /usr/src/linux and I'm able to build cdrtools from source. What am I missing (Debian)? You miss that in former times most Linux distributions in most cases did not include the needed include files at all in case the Linux kernel sources have not been installed at /usr/src/linux. The files in /usr/include/sys/ have been sysmlinks pointing to /usr/src/linux. Newer Linux systems tend to have real files in /usr/include. Some systems have neither symlinks nor files in /usr/include/sys. This is completely chaotic and the setup for Linux in the makefile system tries to do its best from this desaster. If you have /usr/src/linux, then there is a 99% chance that it is the source for the surrently running kernel. People who deviate from this rule need to know what they are doing. The main problem with Linux is a result of the fact that a lot of people believe that it is possible to replace the Kernel with a different version without creating problems with the interfaces to the applications. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: [Cdrecord-video] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From [EMAIL PROTECTED] Sun Jan 25 14:49:03 2004 Please don't comment things you obviously don't really understand. 1)The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. 2)The include files under /usr/src/linux are definitely more recent resp. closer to the currently run kernel than what typically is under /usr/include That's what everyone is trying to tell you, there is no guaranty that those files are correct for the current running kernel. Or that they even exist! See below... 3)I am writing portable software. This means that it is portable even between different Linux versions. 4)What people like Linus Torvalds tell me on how I should compile, is definitely much much more incorrect than what I am currently doing. 5)The problems are a result of _inconsistent_ unclude files in /usr/src/linux, which I call a clear Bug that needs to be fixed. Which is why all the kernel people keep telling you (and everyone else) not to use these files, every distribution and many users do something different. And other applications do run fine even if there is no kernel source at /usr/src/linux. Having *anything* at /usr/src/linux is not required, so you are complaing that something which is random is inconsistent. Yes it is, because you're not supposed to use it! Got it? Yes, it is really hard to take you for serious as you constantly prove that you are not aware on how the compilation of cdrtools in Linux works :-( Your notes obviously don't aply. Before you write another reply to this thread, it would really help if you first try to understand how the compilation is done on Linux systems. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On 23. January 2004 at 5:40PM +0100, Joerg Schilling [EMAIL PROTECTED] wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. I don't have /usr/src/linux and I'm able to build cdrtools from source. What am I missing (Debian)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
On 23. January 2004 at 5:40PM +0100, Joerg Schilling [EMAIL PROTECTED] wrote: Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. I don't have /usr/src/linux and I'm able to build cdrtools from source. What am I missing (Debian)?
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From [EMAIL PROTECTED] Fri Jan 23 14:07:13 2004 attached there is a patch to make cdrtools 2.01 compatible to Linux 2.6.1. If the patch is not needed for some distros, which are assembled somehow, it does not harm anything... Why should I add a wrong definition that would _break_ compilation once the Linux kernel include files are fixed? If you like to get a fix, go to the Linux Kernel people and request a fix for their bugs! Problems may be caused by common user errors like using kernel include files, particularly if it's done wrong by assuming that /usr/src/linux points to the running kernel instead of the distribution kernel. It also results silly end-user issues, such as generating an executable which will only run on a single kernel series, like 2.0, 22, 2.4, 2.6, but doesn't have kernel detection built in or include the kernel series in the executable name so the user can select the correct version. Please don't comment things you obviously don't really understand. 1) The include files on /usr/src/linux have been absolutely needed for a long time to be able to compile at all. 2) The include files under /usr/src/linux are definitely more recent resp. closer to the currently run kernel than what typically is under /usr/include 3) I am writing portable software. This means that it is portable even between different Linux versions. 4) What people like Linus Torvalds tell me on how I should compile, is definitely much much more incorrect than what I am currently doing. 5) The problems are a result of _inconsistent_ unclude files in /usr/src/linux, which I call a clear Bug that needs to be fixed. 6) If you did ever try to write a program that uses interfaces that need /usr/src/linux to compile and run correctly you would probably never repeat the wrong statements from people from LKML. !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html Keinen HTML Muell bitte! No HTML junk please! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: Meino Christian Cramer [EMAIL PROTECTED] Hi, attached there is a patch to make cdrtools 2.01 compatible to Linux 2.6.1. If the patch is not needed for some distros, which are assembled somehow, it does not harm anything... Why should I add a wrong definition that would _break_ compilation once the Linux kernel include files are fixed? If you like to get a fix, go to the Linux Kernel people and request a fix for their bugs! Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-announces] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: Joerg Schilling [EMAIL PROTECTED] Subject: [Cdrecord-announces] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible Date: Tue, 20 Jan 2004 14:18:41 +0100 (CET) From: Meino Christian Cramer [EMAIL PROTECTED] Hi, attached there is a patch to make cdrtools 2.01 compatible to Linux 2.6.1. If the patch is not needed for some distros, which are assembled somehow, it does not harm anything... Why should I add a wrong definition that would _break_ compilation once the Linux kernel include files are fixed? If you like to get a fix, go to the Linux Kernel people and request a fix for their bugs! Jörg a) The patch isn't wrong. b) Didn't you say, that your experience shows, that linux people never get anything fixed...as long as I understood your endless complaints about linux, Linus and such ... what was it? (has forgotten the details...if I heard the same thing over and over, I forgot it usually...saves me to get things fixed) c) this list ist open for anyone, who subscribed. So let decide the rest of the gang, whether to apply the patch or not... d) you are allowed not to apply it -- this is GPL. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Re: [Cdrecord-announces] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: Meino Christian Cramer [EMAIL PROTECTED] Why should I add a wrong definition that would _break_ compilation once the Linux kernel include files are fixed? If you like to get a fix, go to the Linux Kernel people and request a fix for their bugs! Jörg a) The patch isn't wrong. It is, because if ever, it needs to be unsigned char b) Didn't you say, that your experience shows, that linux people never get anything fixed...as long as I understood your endless complaints about linux, Linus and such ... what was it? (has forgotten the details...if I heard the same thing over and over, I forgot it usually...saves me to get things fixed) Well, if I give up too early, there is a big chance that things become worse in future. c) this list ist open for anyone, who subscribed. So let decide the rest of the gang, whether to apply the patch or not... d) you are allowed not to apply it -- this is GPL. Of course, you may do so but this is nothing that should make it into a release. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Cdrecord-developers] Re: [Cdrecord-announces] Re: [Cdrecord-developers] Cdrtools-2.01a25: Patch to make cdrtools 2.01a25 Linux compatible
From: Meino Christian Cramer [EMAIL PROTECTED] Why should I add a wrong definition that would _break_ compilation once the Linux kernel include files are fixed? If you like to get a fix, go to the Linux Kernel people and request a fix for their bugs! Jörg a) The patch isn't wrong. It is, because if ever, it needs to be unsigned char b) Didn't you say, that your experience shows, that linux people never get anything fixed...as long as I understood your endless complaints about linux, Linus and such ... what was it? (has forgotten the details...if I heard the same thing over and over, I forgot it usually...saves me to get things fixed) Well, if I give up too early, there is a big chance that things become worse in future. c) this list ist open for anyone, who subscribed. So let decide the rest of the gang, whether to apply the patch or not... d) you are allowed not to apply it -- this is GPL. Of course, you may do so but this is nothing that should make it into a release. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am Jorg Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily
