possible buildsystem bug

[Enrico Weigelt]

Hi,

while hacking in the sources, I've recognize that make doesn't
stop if some targets fail.

Is this intented or an bug ?

cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: [phone]   email: info@...   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Enrico Weigelt <weigelt@...> wrote:

>
> Hi,
>
> while hacking in the sources, I've recognize that make doesn't
> stop if some targets fail.
>
> Is this intented or an bug ?

You are on Linux and this is a well known bash bug :-(

        bash sometimes ignores the "-e" option.

It is unfortunately even impossible to find a workaround for _this_ bug.
Smake already includes workarounds for _other_ bash bugs....

One way to fix the problem is to fetch the schily source consolidation

ftp://ftp.berlios.de/pub/schily

install "sh" as "/bin/bosh" and edit smake/make.c to call "/bin/bosh"
instead of "/bin/sh".

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Enrico Weigelt]

* Joerg Schilling <Joerg.Schilling@...> schrieb:

> You are on Linux and this is a well known bash bug :-(
>
> bash sometimes ignores the "-e" option.
>
> It is unfortunately even impossible to find a workaround for _this_ bug.

Meanwhile I've fixed it. It's caused by those lines:

    echo ... ; gcc ...
   
The trick is to just replace ; by &.
Works fine for me.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: [phone]   email: info@...   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Enrico Weigelt <weigelt@...> wrote:

> * Joerg Schilling <Joerg.Schilling@...> schrieb:
>
> > You are on Linux and this is a well known bash bug :-(
> >
> > bash sometimes ignores the "-e" option.
> >
> > It is unfortunately even impossible to find a workaround for _this_ bug.
>
> Meanwhile I've fixed it. It's caused by those lines:
>
>     echo ... ; gcc ...
>    
> The trick is to just replace ; by &.
> Works fine for me.

Looks like you are mistaken. Problems in this area are unknown.

Are you using gmake instead of smake and thus probably hit by gmake bugs?

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Enrico Weigelt]

* Joerg Schilling <Joerg.Schilling@...> schrieb:

> > Meanwhile I've fixed it. It's caused by those lines:
> >
> >     echo ... ; gcc ...
> >    
> > The trick is to just replace ; by &.
> > Works fine for me.
>
> Looks like you are mistaken. Problems in this area are unknown.

This *was* my problem here, and using & fixed it. Period.
IMHO, this should cause no problems elswhere, unless echo
returns an error ;-o

> Are you using gmake instead of smake and thus probably hit by gmake bugs?

Yes, I'm using gmake. Maybe there's a bug, but I suspect a shell
problem, since (IMHO) gmake just passes the command lines
directly to the shell.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: [phone]   email: info@...   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Enrico Weigelt <weigelt@...> wrote:

> * Joerg Schilling <Joerg.Schilling@...> schrieb:
>
> > > Meanwhile I've fixed it. It's caused by those lines:
> > >
> > >     echo ... ; gcc ...
> > >    
> > > The trick is to just replace ; by &.
> > > Works fine for me.
> >
> > Looks like you are mistaken. Problems in this area are unknown.
>
> This *was* my problem here, and using & fixed it. Period.
> IMHO, this should cause no problems elswhere, unless echo
> returns an error ;-o
>
> > Are you using gmake instead of smake and thus probably hit by gmake bugs?
>
> Yes, I'm using gmake. Maybe there's a bug, but I suspect a shell
> problem, since (IMHO) gmake just passes the command lines
> directly to the shell.

The problem you describe is unknown with smake.

The real problem with bash happens in the shell loop that is part of the
SSPM (Slottable Source Plugin Module) system that allows to add sources to
compile into an existing source tree without the need to modify makefiles.

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Michael Shell]

On Tue, 8 Jul 2008 15:41:49 +0200
Enrico Weigelt <weigelt@...> wrote:

> * Joerg Schilling <Joerg.Schilling@...> schrieb:
>
> > You are on Linux and this is a well known bash bug :-(
> >
> > bash sometimes ignores the "-e" option.
> >
> > It is unfortunately even impossible to find a workaround for _this_ bug.
>
> Meanwhile I've fixed it. It's caused by those lines:
>
>     echo ... ; gcc ...
>    
> The trick is to just replace ; by &.
> Works fine for me.

 I think Joerg is referring to:

http://www.faqs.org/docs/bashman/bashref_76.html

specifically "28. Subshells spawned to execute command substitutions
inherit the value of the `-e' option from the parent shell. When not
in POSIX mode, Bash clears the `-e' option in such subshells."

It is possible to enable bash's POSIX mode at run time.

But, I can see some reasons why POSIX mode of bash can be such a
problem with existing systems:

"7. The POSIX 1003.2 startup files are executed ($ENV) rather than the
    normal Bash files."

Although I can't say the /etc/profile and .bashrc approach is totally
sane.

Which UNIXes use bash in POSIX mode by default?

Or, is there a bug with bash in that it does not follow its own
documentation? That most certainly would be a bug.

Why is that && isn't what is required rather than & to be able
to see an exit 1 status?


  Mike Shell
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Michael Shell <list1@...> wrote:

>  I think Joerg is referring to:
>
> http://www.faqs.org/docs/bashman/bashref_76.html
>
> specifically "28. Subshells spawned to execute command substitutions
> inherit the value of the `-e' option from the parent shell. When not
> in POSIX mode, Bash clears the `-e' option in such subshells."
>
> It is possible to enable bash's POSIX mode at run time.

Interesting to see that it is now documented.

How is the mode enable at run time?
If this works by setting a shell var, it will not influence other shells and
yould be added.



> But, I can see some reasons why POSIX mode of bash can be such a
> problem with existing systems:
>
> "7. The POSIX 1003.2 startup files are executed ($ENV) rather than the
>     normal Bash files."

For sh -ce this should not be significant.

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Michael Shell]

On Tue, 08 Jul 2008 18:30:48 +0200
Joerg.Schilling@... (Joerg Schilling) wrote:

> How is the mode enable at run time?

They (in the previous URL I gave) mentioned two ways:

"Starting Bash with the `--posix' command-line option or executing
`set -o posix' while Bash is running will cause Bash to conform more
closely to the POSIX 1003.2 standard by changing the behavior to
match that specified by POSIX in areas where the Bash default differs."


  Mike
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Joerg.Schilling@... (Joerg Schilling) wrote:

> Michael Shell <list1@...> wrote:
>
> >  I think Joerg is referring to:
> >
> > http://www.faqs.org/docs/bashman/bashref_76.html
> >
> > specifically "28. Subshells spawned to execute command substitutions
> > inherit the value of the `-e' option from the parent shell. When not
> > in POSIX mode, Bash clears the `-e' option in such subshells."
> >
> > It is possible to enable bash's POSIX mode at run time.
>
> Interesting to see that it is now documented.

Well I tested it and it does not work:

ksh -ce 'for i in 1 2 3; do  ( echo $i; if [ -d . ]; then (false; echo 4);  fi ) ; done'              
1

bash -ce 'set -o posix; for i in 1 2 3; do  ( echo $i; if [ -d . ]; then (false; echo 4);  fi ) ; done'
1
2
3


BTW: if you use GNU make, failing comands will _always_ be ignored with respect
to commands that follow in the same shell call. This is because GNU make calls:

sh -c "cmd ..."

while UNIX make and smake call:

sh -ce "cmd ..."

Another reason why I recommend not to use gmake.

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Enrico Weigelt <weigelt@...> wrote:

> > Are you using gmake instead of smake and thus probably hit by gmake bugs?
>
> Yes, I'm using gmake. Maybe there's a bug, but I suspect a shell
> problem, since (IMHO) gmake just passes the command lines
> directly to the shell.

see my other mail, this is a gmake problem. Gmake calls the shell the wrong
way.

In order to make thing work correctly you need a shell that correctly abort a
"pipeline" (not a pipe ;-) if told to do so. You _also_ need a make program
that correctly calls the shell:

make -i ---> sh -c "cmd ...."
make ---> sh -ce "cmd ...."

gmake always calls sh -c "cmd ...." which is the reason for your problem.

Unfortunately POSIX itself is buggy here in the make man page :-(

This is why smake allows to configure any possible behavior.

Smake defines the followwing macros:

     MAKE_SHELL_FLAG
          This macro contains the shell flags used  when  calling
          commands  from  smake.   The default value is -ce, When
          smake in in POSIX mode, the default value is  -c.   The
          MAKE_SHELL_FLAG   allows   to   overwrite  the  default
          behavior.

     MAKE_SHELL_IFLAG
          This macro contains the shell flags used  when  calling
          commands  from smake -i.  The default value is -c.  The
          MAKE_SHELL_IFLAG  allows  to  overwrite   the   default
          behavior.

You should really rethink whether you continue to use gmake.
Gmake still did not fix a bug that I reported in 1997 although it has been
accepted to be a bug by the gmake "crew". Gmake in addition does not work
correctly on several "DOS like" platforms like e.g. Win-32. This is because
the makefile parser from gmake does not correctly handle white space and the
quote character '\\'.

As a result, smake is the only make program that allows you to compile software
using the schily makefilesystem on the complete set of supported platforms.

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Enrico Weigelt]

* Joerg Schilling <Joerg.Schilling@...> schrieb:

Hi,

> In order to make thing work correctly you need a shell that correctly abort a
> "pipeline" (not a pipe ;-) if told to do so. You _also_ need a make program
> that correctly calls the shell:
>
> make -i ---> sh -c "cmd ...."
> make ---> sh -ce "cmd ...."
>
> gmake always calls sh -c "cmd ...." which is the reason for your problem.
>
> Unfortunately POSIX itself is buggy here in the make man page :-(

Well, I could also turn the whole thing around and claim that you
just realy on an false assumption ;-P

Actually, using && intead of ; trivially fixed it and reflects what
one expects from an interactive shell - in fact, I didn't ever tried
your way within a makefile (at least, can't rember ;-o).

> You should really rethink whether you continue to use gmake.

Already did. But at that point I did a bit research with a completely
different approach: http://treebuild.metux.de/index.php/Main_Page
It's actually a completely different paradigm: modeling the package's
structure instead of build rules (model- instead of process-driven).
Not an Ultime Solution (tm), but fine for simply structured packages.

> Gmake still did not fix a bug that I reported in 1997 although it has been

URL ?

> accepted to be a bug by the gmake "crew". Gmake in addition does not work
> correctly on several "DOS like" platforms like e.g. Win-32. This is because
> the makefile parser from gmake does not correctly handle white space and the
> quote character '\\'.

Yep, the tab/whitespace issue is an ugly thing. Back when I was learning
(g)make, it caused me some headache ;-o


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: [phone]   email: info@...   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Joerg Schilling-3]

Enrico Weigelt <weigelt@...> wrote:

> > make -i ---> sh -c "cmd ...."
> > make ---> sh -ce "cmd ...."
> >
> > gmake always calls sh -c "cmd ...." which is the reason for your problem.
> >
> > Unfortunately POSIX itself is buggy here in the make man page :-(
>
> Well, I could also turn the whole thing around and claim that you
> just realy on an false assumption ;-P

No, see below

> Actually, using && intead of ; trivially fixed it and reflects what
> one expects from an interactive shell - in fact, I didn't ever tried
> your way within a makefile (at least, can't rember ;-o).

Well, you did replace ; by && only at a place whete the left side would never
fail. Your change is obviously not related to the problem I describe. There may
be another bash bug in your case.


> > You should really rethink whether you continue to use gmake.
>
> Already did. But at that point I did a bit research with a completely
> different approach: http://treebuild.metux.de/index.php/Main_Page
> It's actually a completely different paradigm: modeling the package's
> structure instead of build rules (model- instead of process-driven).
> Not an Ultime Solution (tm), but fine for simply structured packages.

Reading this, I understand that you don't know David Korn ;-)

First, you should read this:

ftp://ftp.berlios.de/pub/smake/PortableSoftware.ps.gz

It explains how highly portable software may be build.


When I first saw imake 20 years ago, I understood that this is the wrong way
and just a big machine to wast CPU cycles.

Later, the FSF started with autoconf which usually does two jobs:

- create a include file with config data that contain results from
        fine grained platform tests. This is an implemtation of the ideas
        of the pioneers of the openSource movement Larry Wall and Rich $alz
        from around 1980.

- create modified makefiles. This is not a good idea.

This is why I only use the first part from autoconf. BTW: stay with the working
old portable autoconf as the new autoconf is based on the existence of bash.

David Korn in 1991 decided to believe that he needs a "make" replacement
and wrote "nmake". I (together with a friend) found in 1992 that any halfway
modern make supports "include" and allows to write object oriented make rules
in case a portable solution to implement if/then/else was found.

The result is funny: David Korn's "leaf nmakefiles" look _very_ similar to my
makefiles. They are just a table that lists the source files and the options.
The rest is done by the build system.

I believe that your idea of using xml for this task is "inhumane" ;-)

BTW: bootstrapping my build system is simple as any even brain dead "make"
could build the bootstrap-smake and as there is even a way to compile the first
stage of smake using portable shell scripts. How do you port your software to a
new unknown platform?


> > Gmake still did not fix a bug that I reported in 1997 although it has been
>
> URL ?

There was a mail exchange 11 years ago. I know of no URLs, you may search for
it.

GNU make has a design bug. It does not follow the rule "try to 'make' anything
before you try to use it". gmake does this for top the level "makefile" but not
for included make files. As a result gmake prints error messages that should
never appear. In this area gmake is a piece of junk. It tries to hide this bug
with the following strategy:

- start gmake and continue on failed include statements _although_ the
        files are missing.

- execute rules including the ones to create the include files

- restart (re-exec) gmake with the saved args

I did even allow the gmake authors to use the correct algorithm from smake, so
it would not be hard to fix the bug.

3 years ago, I reported a bug in the way gmake examines it's environment. This
causes gmake to dump core under certain conditions. This bug could be fixed
with a 2 line change that I send. The bug is still present in recent gname
releases. I consider gmake to be an "unmaintained program" for this reason.

> > accepted to be a bug by the gmake "crew". Gmake in addition does not work
> > correctly on several "DOS like" platforms like e.g. Win-32. This is because
> > the makefile parser from gmake does not correctly handle white space and the
> > quote character '\\'.
>
> Yep, the tab/whitespace issue is an ugly thing. Back when I was learning
> (g)make, it caused me some headache ;-o

There is no way to work around this gmake bug unless you like to make the
makefile to fail on correct make implementations.

Rule of thumb: better try to fix the defective program instead of trying to
work around the bugs.

Jörg

--
 EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
       js@...                (uni)  
       schilling@...     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Thommy M.]

Joerg Schilling wrote:
> Enrico Weigelt <weigelt@...> wrote:
>
>  


Boys, this pissing contest starts smelling like urine. If you take it
off line, everyone would feel better.

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Enrico Weigelt]

* Joerg Schilling <Joerg.Schilling@...> schrieb:

> > Already did. But at that point I did a bit research with a completely
> > different approach: http://treebuild.metux.de/index.php/Main_Page
> > It's actually a completely different paradigm: modeling the package's
> > structure instead of build rules (model- instead of process-driven).
> > Not an Ultime Solution (tm), but fine for simply structured packages.
>
> Reading this, I understand that you don't know David Korn ;-)

Besides I know and had several talks about ksh w/ him, what does David
have to do with my buildsystem ?
 
> First, you should read this:
>
> ftp://ftp.berlios.de/pub/smake/PortableSoftware.ps.gz
>
> It explains how highly portable software may be build.

It explains *your* view. On a first look it seems quite fine, but I
already mentioned that you buildsystem isn't without problems.
 
> Later, the FSF started with autoconf which usually does two jobs:
>
> - create a include file with config data that contain results from
> fine grained platform tests. This is an implemtation of the ideas
> of the pioneers of the openSource movement Larry Wall and Rich $alz
> from around 1980.
>
> - create modified makefiles. This is not a good idea.

In general: ack.

But: the whole autotools stuff is anything but robust. You need to be
very careful. Your paper already mentions several problems.

> I believe that your idea of using xml for this task is "inhumane" ;-)

If you just don't like xml, you could also use any other way for storing
hierachies, bracked expressions (lisp), C-struct style, filesystem,
whatever you like.

The major idea behind is that you have an hierachy of classified objects.
One object type, for example, is a library node. It consists of things
like source nodes (eg. .c), header nodes (which might be either public
or private - that affects installing) or import nodes (import other libs).
Then it's up to the buildsystem only (!) how to pull things together.
As the application developer, these details are completely out of your
scope, intentionally.

For lot's of packages this is approach is fine, for others not. Well,
you've got the choice :P

> BTW: bootstrapping my build system is simple as any even brain dead "make"
> could build the bootstrap-smake and as there is even a way to compile the first
> stage of smake using portable shell scripts.

I absolutely dislike the idea of some package bringing its own make tool,
this causes a lot of headache, at least w/ crosscompiling.
Instead just clearly state which tools are required and leave that job
to the user.

> How do you port your software to a new unknown platform?

Port the buildsystem to that platform and then just use it.
In the treebuild model, there are no platform specifics visible to
the application (besides some symbols which might be set or not).
For example, there is exactly one way to declare the structure of
certain package. Note: you just give the structure, the actual build
process is out of scope then.

> > > Gmake still did not fix a bug that I reported in 1997 although it has been
> >
> > URL ?
>
> There was a mail exchange 11 years ago. I know of no URLs, you may search for
> it.

Could you please bounce these mails to me ?

> GNU make has a design bug. It does not follow the rule "try to 'make' anything
> before you try to use it". gmake does this for top the level "makefile" but not
> for included make files. As a result gmake prints error messages that should
> never appear.

Could you please give an detailed example ?

> In this area gmake is a piece of junk. It tries to hide this bug
> with the following strategy:
>
> - start gmake and continue on failed include statements _although_ the
> files are missing.

It runs through, even includes are missing ? ugh!

> - execute rules including the ones to create the include files
> - restart (re-exec) gmake with the saved args

Ah, that's probably because it should be able to create certain includes
by itself, eg. autogenerated dependencies.
Actually, I don't like that approach - better use separate makefiles,
a toplevel one which creates the deps and then calls the 2nd level one.

> 3 years ago, I reported a bug in the way gmake examines it's environment. This
> causes gmake to dump core under certain conditions. This bug could be fixed
> with a 2 line change that I send. The bug is still present in recent gname
> releases. I consider gmake to be an "unmaintained program" for this reason.

URL ?

> > Yep, the tab/whitespace issue is an ugly thing. Back when I was learning
> > (g)make, it caused me some headache ;-o
>
> There is no way to work around this gmake bug unless you like to make the
> makefile to fail on correct make implementations.

More precisely ?
 
> Rule of thumb: better try to fix the defective program instead of trying to
> work around the bugs.

ACK. That's exactly why I prefer certain fixes to be done within the
toolchain instead of working around in each single app.

For example, win32's (IMHO meanwhile deprecated behaviour) of using
backlash instead of slash as directory delimiter can be handled
within libc, so no more thousands of #ifdef's are needed anymore.

An more tricky example is the mmap() behaviour differing between
OS'es. This can't really fixed, since there is no standard you can
use as reference. IMHO, we should create one:

* write some "libmmap" (or at least an include file) which either
  sets appropriate symbols and maybe introduces some wrappers for
  specific cases.
* this lib has to be ported once per target platform
* packages which want to use mmap then exclusively use that new
  lib instead of the (then deprecated) mmap() call directly.

This can also be done with lots of similar problems.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: [phone]   email: info@...   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

[Quey]

Top posting because I know it will piss people off, but no more then  
your mines biger then yours contest between you too, we know Jorgs st  
in his ancient ways  of his way ios always right regardless of it  
being right or wrong, and will never change.

So I agree with Thommy take it to private.

We will ac