Pure LFS Hint - good to go

[Greg Schafer]

LFS'ers

It's not quite finished yet but there is enough here for anyone to utilise
the new method and build a complete system. There are still some FIXME's in
there.

If this ever gets integrated into the book, it will drastically reduce the
amount of things that can go wrong and thus reduce the level of cluelessness
on the support list. As mentioned earlier, it should also dramatically
increase the range of hosts capable of building LFS from.

I'm still tempted to write a shorter version which doesn't go into as much
detail and doesn't take as much care, but still utilises all the same
principles. This shorter version could go into the book in a snap and would
instantly be a huge win over current LFS.

I'll tidy up some remaining stuff then submit to the hintmaster for
inclusion with the rest of the hints. I still need to write some paragraphs
about installing gcc-2.95.3 into /opt and using it to build kernels.

I'd just like to publically thank Ryan for the amount of work he's put into
this. You really have no idea how hard he's been at it. The final result
might not look like lots of work, but trust me, it's massive.

Anyhow, enjoy.

Greg

http://www.zipworld.com.au/~gschafer/pure_lfs.txt

[Bruce Dubbs]

Post by Greg Schafer
LFS'ers
It's not quite finished yet but there is enough here for anyone to utilise
the new method and build a complete system. There are still some
FIXME's in there.
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

Starting to look at it now. Looks nice, but I'm not yet implementing.

A note. In the Chapter 5 section you say:


Also, don't forget to do the chown bit:-

chown lfs $LFS/stage1

The next step is to create a "/stage1" directory on the host system. Then we
symlink it to the $LFS/stage1 directory we just created on the LFS
partition:-

mkdir /stage1
ln -s /mnt/lfs/stage1 /stage1
--------
Shouldn't the link be:

ln -s $LFS/stage1 /stage1
--------

In the Setting up the environment section, I'd suggest putting the
export and set instructions in /home/lfs/.bashrc and then doing:

su - lfs

Also s/comamnds/commands/

-- Bruce

[Greg Schafer]

Post by Bruce Dubbs
mkdir /stage1
ln -s /mnt/lfs/stage1 /stage1
--------
ln -s $LFS/stage1 /stage1

Good point. Fixed.

Post by Bruce Dubbs
In the Setting up the environment section, I'd suggest putting the
su - lfs

That was the implied intent. I'll make it clearer though,

Post by Bruce Dubbs
Also s/comamnds/commands/

Thanks Bruce.

Greg

[Jules Colding]

Hi,

Good work!

But I have a small question.. I have now build a few ch 6 packages. The
only modification to the environment that I did, was to "sed" the ch 5
gcc spec file immediately after having installed the ch 6 glibc. Using
ldd to inspect the ch 6 binaries shows that they all link against the ch
6 glibc and that they are all using /lib/ld-linux.so.2.

So, is it really necessary to do anything else to get a pure and correct
ch 6 build?
--
jules

Post by Greg Schafer
LFS'ers
It's not quite finished yet but there is enough here for anyone to utilise
the new method and build a complete system. There are still some FIXME's in
there.
If this ever gets integrated into the book, it will drastically reduce the
amount of things that can go wrong and thus reduce the level of cluelessness
on the support list. As mentioned earlier, it should also dramatically
increase the range of hosts capable of building LFS from.
I'm still tempted to write a shorter version which doesn't go into as much
detail and doesn't take as much care, but still utilises all the same
principles. This shorter version could go into the book in a snap and would
instantly be a huge win over current LFS.
I'll tidy up some remaining stuff then submit to the hintmaster for
inclusion with the rest of the hints. I still need to write some paragraphs
about installing gcc-2.95.3 into /opt and using it to build kernels.
I'd just like to publically thank Ryan for the amount of work he's put into
this. You really have no idea how hard he's been at it. The final result
might not look like lots of work, but trust me, it's massive.
Anyhow, enjoy.
Greg
http://www.zipworld.com.au/~gschafer/pure_lfs.txt
--
and put 'unsubscribe lfs-dev' in the subject header of the message

[Greg Schafer]

Post by Jules Colding
Hi,
Good work!
But I have a small question.. I have now build a few ch 6 packages. The
only modification to the environment that I did, was to "sed" the ch 5
gcc spec file immediately after having installed the ch 6 glibc. Using
ldd to inspect the ch 6 binaries shows that they all link against the ch
6 glibc and that they are all using /lib/ld-linux.so.2.
So, is it really necessary to do anything else to get a pure and correct
ch 6 build?

Sort of. We also adjust the ldscripts. Though if you don't, everything
should still be ok. I believe what will happen is that ld will link against
the libs in /stage1 but but because you've told gcc to use the dynamic
linker in /lib, runtime linking will link against /lib. The end result
shouldn't really matter as the glibcs in /stage1 and /lib should be pretty
much identical by this stage.

The abridged version of the hint will work as you describe.

Greg

[Seth W.Klein]

Post by Greg Schafer
LFS'ers
It's not quite finished yet but there is enough here for anyone to utilise
the new method and build a complete system. There are still some FIXME's in
there.
[....]

Yippee! ;) I'm throwing my ***@133 at it now and will likley do
the same on my iBook when it gets its rebuilds in the not _too_
distant future.

My comments'll likely be in several pieces since this machine's slow.

[Frank Gore]

(I think) i know where to get the binutils patch from reading the
lists, but (unless i'm blind, which is possible) the Hint doesn't
give the location.

Quoted from the hint:

============
Where to get the patches
------------------------
The patches used in this hint can be obtained from:-

http://www.zipworld.com.au/~gschafer/patches/pure_lfs/
============

Frank

[Greg Schafer]

Post by Seth W.Klein
the same on my iBook when it gets its rebuilds in the not _too_
distant future.
My comments'll likely be in several pieces since this machine's slow.

[Seth W.Klein]

Post by Greg Schafer

Post by Seth W.Klein
the same on my iBook when it gets its rebuilds in the not _too_
distant future.
My comments'll likely be in several pieces since this machine's slow.

[....]

Post by Seth W.Klein
(I think) i know where to get the binutils patch from reading the
lists, but (unless i'm blind, which is possible) the Hint doesn't
give the location.

No, it's there, look harder :-)

I _knew_ blindness was a possibility :) Here's something more useful:

hint> SPECFILE=/stage1/lib/gcc-lib/i686-pc-linux-gnu/*/specs
hint> [....]

Not all of us live in the modern age :) Or the ix86 world, for that
matter. I use an i586-pc-linux-gnu and a powerpc-unknown-linux-gnu.
So maybe:

SPECFILE=/stage1/lib/gcc-lib/*-*-linux-gnu/*/specs


I get the impression Ryan's script supports NLS. I would be interested
in seeing that in the hint.

On a related note, can anyone give me a quick instructions for testing
basic NLS functionality? I'm a clueless American ;) so i don't know
what i'm talking about, but i'm thinking of something like
``LANG=fr ls --help'' or some such.

cheers,
Seth W. Klein

[Tushar Teredesai]

It would be good to adjust the instructions, if possible, so that
/stage1 can be readonly.

Following are some of my thoughts, I have not yet tested them so take
the suggestions with a grain of salt.

* Perl can be installed in Chapter 5. If dynamic version is too
troublesome, maybe a static one.
* The reinstallation of ld (binutils) after installing Ch 6 can be
avoided by adding /stage1/lib to then end of LIB_PATH and then
installing ld just before entering chroot.
* Changing the gcc spec file after Ch 6 glibc could be avoided by
changing the spec file before entering chroot and the making a
symlink after entering chroot "ln -s /stage1/lib/ld-linux.so.2
/lib/ld-linux.so.2"

[Greg Schafer]

Post by Tushar Teredesai
It would be good to adjust the instructions, if possible, so that
/stage1 can be readonly.

But /stage1 is a single symlink now so not applicable I feel (unless I've
missed your point which is highly probable :-)

Post by Tushar Teredesai
Following are some of my thoughts, I have not yet tested them so take
the suggestions with a grain of salt.
* Perl can be installed in Chapter 5. If dynamic version is too
troublesome, maybe a static one.

/me reaches for the salt :-). Dude, give me some feedback when you've
actually had a play with it. I spent a full day farking around with the perl
stuff and I'm still not happy with it. Perl's assumptions about where /libc
is located are truly mind boggling.

Post by Tushar Teredesai
* The reinstallation of ld (binutils) after installing Ch 6 can be
avoided by adding /stage1/lib to then end of LIB_PATH and then
installing ld just before entering chroot.

Possibly. Doesn't feel as neat to me though.

Post by Tushar Teredesai
* Changing the gcc spec file after Ch 6 glibc could be avoided by
changing the spec file before entering chroot and the making a
symlink after entering chroot "ln -s /stage1/lib/ld-linux.so.2
/lib/ld-linux.so.2"

Yeah, I thought about stuff like this. Haven't tested it tho'. The thing
that stopped me from testing it is, glibc seems to have an ingrained
"awareness" of where it is installed. Playing little tricks like this may
slighty upset the apple cart and not produce the exact desired results.

Thanks for the feedback dude.

Greg

[Tushar Teredesai]

Post by Greg Schafer

Post by Tushar Teredesai
It would be good to adjust the instructions, if possible, so that
/stage1 can be readonly.

But /stage1 is a single symlink now so not applicable I feel (unless I've
missed your point which is highly probable :-)

:)To be more precise, there should be no need to change anything in
/stage1 after chrooting in Chapter 6. That way once the /stage1
directory is prepared, it can be burned to a CD and reused.

Post by Greg Schafer

Post by Tushar Teredesai
Following are some of my thoughts, I have not yet tested them so take
the suggestions with a grain of salt.
* Perl can be installed in Chapter 5. If dynamic version is too
troublesome, maybe a static one.

/me reaches for the salt :-). Dude, give me some feedback when you've
actually had a play with it. I spent a full day farking around with the perl
stuff and I'm still not happy with it. Perl's assumptions about where /libc
is located are truly mind boggling.

:-) Yep, those were my first impressions, am still working thru it one
by one, perl is at the far end, and considering the horsepower of my
CPU, the word "far" really means "far":) BTW, I install perl statically
using the following configure options.

./Configure -d -e -s -Doptimize="$CFLAGS" -Dprefix=/static
-Dldflags="-s -static" -Dso=none -Uinstallusrbinperl -Uusedl

Post by Greg Schafer

Post by Tushar Teredesai
* The reinstallation of ld (binutils) after installing Ch 6 can be
avoided by adding /stage1/lib to then end of LIB_PATH and then
installing ld just before entering chroot.

Possibly. Doesn't feel as neat to me though.

Yep, but it will only be used till the Ch 6 binutils is compiled which
is immediately after glibc.

Post by Greg Schafer

Post by Tushar Teredesai
* Changing the gcc spec file after Ch 6 glibc could be avoided by
changing the spec file before entering chroot and the making a
symlink after entering chroot "ln -s /stage1/lib/ld-linux.so.2
/lib/ld-linux.so.2"

Yeah, I thought about stuff like this. Haven't tested it tho'. The thing
that stopped me from testing it is, glibc seems to have an ingrained
"awareness" of where it is installed. Playing little tricks like this may
slighty upset the apple cart and not produce the exact desired results.

The only affected package would be glibc, since in the hint, the spec
file is changed immediately after glibc is installed. glibc anaways uses
its own linker flags to use /lib/ld-linux.so.2 even though gcc specifies
/stage1/lib/ld-linux.so.2. So, it would be non-issue.

Post by Greg Schafer
Thanks for the feedback dude.

Thanks to you and Ryan for the hint and giving us the opportunity to
have some fun:) I will be trying the suggestions I mentioned, especially
the last one.

[unknown]

Post by Greg Schafer

Post by Tushar Teredesai
* Perl can be installed in Chapter 5. If dynamic version is too
troublesome, maybe a static one.

/me reaches for the salt :-). Dude, give me some feedback when you've
actually had a play with it. I spent a full day farking around with the perl
stuff and I'm still not happy with it. Perl's assumptions about where /libc
is located are truly mind boggling.

Now that I have played with it, here is how I got perl to compile
against the glibc in /stage1 in Chapter 5:-)

perl_version=5.8.0 &&
glibc_version=2.3.1 &&
b_prefix=/stage1 &&
tar -xvzf perl-$perl_version.tar.gz &&
cd perl-$perl_version &&
./Configure -d -E -s -Doptimize="-O2 -pipe -w" \
-Dprefix=$b_prefix -Dldflags="-s" -Uinstallusrbinperl \
-Uusedl -Dlibpth=$b_prefix/lib &&
cp config.sh config.sh.orig &&
l=`find $b_prefix/lib -name "libc\-*.so" -type f` &&
sed -e "s@/usr/@$b_prefix/@g" -e "s:^libc=.*:libc=\'$l\':g" \
-e "s:^gnulibc_version=.*:gnulibc_version=\'$glibc_version\':g"\
config.sh.orig > config.sh &&
rm -f config.sh.orig &&
unset l &&
./Configure -d -e -r &&
make &&
make install &&
rm -rf $b_prefix/man &&
cd .. &&
rm -rf perl-$perl_version

The output of FindLibraries (a home-brew script that determines the
dependencies using ld):

/stage1/lib/ld-linux.so.2
/stage1/lib/libc.so.6
/stage1/lib/libcrypt.so.1
/stage1/lib/libdl.so.2
/stage1/lib/libm.so.6
/stage1/lib/libnsl.so.1
/stage1/lib/libutil.so.1

[Cynthia]

----- Original Message -----
From: "Tushar Teredesai" <***@linuxfromscratch.org>
To: <lfs-***@linuxfromscratch.org>
Sent: Monday, February 17, 2003 9:42 PM
Subject: Re: Pure LFS Hint - good to go

Post by Greg Schafer

Post by Tushar Teredesai
* Perl can be installed in Chapter 5. If dynamic version is too
troublesome, maybe a static one.

/me reaches for the salt :-). Dude, give me some feedback when you've
actually had a play with it. I spent a full day farking around with the perl
stuff and I'm still not happy with it. Perl's assumptions about where /libc
is located are truly mind boggling.

Now that I have played with it, here is how I got perl to compile
against the glibc in /stage1 in Chapter 5:-)

perl_version=5.8.0 &&
glibc_version=2.3.1 &&
b_prefix=/stage1 &&
tar -xvzf perl-$perl_version.tar.gz &&
cd perl-$perl_version &&
./Configure -d -E -s -Doptimize="-O2 -pipe -w" \
-Dprefix=$b_prefix -Dldflags="-s" -Uinstallusrbinperl \
-Uusedl -Dlibpth=$b_prefix/lib &&
cp config.sh config.sh.orig &&
l=`find $b_prefix/lib -name "libc\-*.so" -type f` &&
sed -e "s@/usr/@$b_prefix/@g" -e "s:^libc=.*:libc=\'$l\':g" \
-e "s:^gnulibc_version=.*:gnulibc_version=\'$glibc_version\':g"\
config.sh.orig > config.sh &&
rm -f config.sh.orig &&
unset l &&
./Configure -d -e -r &&
make &&
make install &&
rm -rf $b_prefix/man &&
cd .. &&
rm -rf perl-$perl_version

The output of FindLibraries (a home-brew script that determines the
dependencies using ld):

/stage1/lib/ld-linux.so.2
/stage1/lib/libc.so.6
/stage1/lib/libcrypt.so.1
/stage1/lib/libdl.so.2
/stage1/lib/libm.so.6
/stage1/lib/libnsl.so.1
/stage1/lib/libutil.so.1

--
Tushar Teredesai
http://www.linuxfromscratch.org/~tushar/
http://www.geocities.com/tushar/

_____________________________________

I tried this and I get a sed error and it doesn't write the config.sh.

Post by Greg Schafer
glibc_version=2.3.1 &&
b_prefix=/stage1 &&
tar -xvzf ../usr/tarballs/perl-$perl_version.tar.gz &&
cd perl-$perl_version &&
./Configure -d -E -s -Doptimize="-O2 -pipe -w" \
-Dprefix=$b_prefix -Dldflags="-s" -Uinstallusrbinperl \
-Uusedl -Dlibpth=$b_prefix/lib &&
cp config.sh config.sh.orig &&
l=`find $b_prefix/lib -name "libc\-*.so" -type f` &&
-e "s:^gnulibc_version=.*:gnulibc_version=\'$glibc_version\':g"\
config.sh.orig > config.sh &&
rm -f config.sh.orig &&
unset l &&
./Configure -d -e -r

Stripping down executable paths...

Creating config.sh...

sed: -e expression #3, char 50: Unknown option to `s'

***@ace:/lfs/stage1/perl-5.8.0$



Cynthia

[Greg Schafer]

Post by unknown
Now that I have played with it, here is how I got perl to compile
against the glibc in /stage1 in Chapter 5:-)
perl_version=5.8.0 &&
glibc_version=2.3.1 &&
b_prefix=/stage1 &&
tar -xvzf perl-$perl_version.tar.gz &&
cd perl-$perl_version &&
./Configure -d -E -s -Doptimize="-O2 -pipe -w" \
-Dprefix=$b_prefix -Dldflags="-s" -Uinstallusrbinperl \
-Uusedl -Dlibpth=$b_prefix/lib &&
cp config.sh config.sh.orig &&
l=`find $b_prefix/lib -name "libc\-*.so" -type f` &&
-e "s:^gnulibc_version=.*:gnulibc_version=\'$glibc_version\':g"\
config.sh.orig > config.sh &&
rm -f config.sh.orig &&
unset l &&
./Configure -d -e -r &&
make &&
make install &&
rm -rf $b_prefix/man &&
cd .. &&
rm -rf perl-$perl_version

Tush, far out man! Was hoping for something a bit more "user-friendly" :-/
That sed is equivalent in hack value to my miniperl thing :)

For the life of me, I cannot figure out how to disable the building of the
extensions automatically. If I go through the Configure interactively, it
gives me the option to enter in "none" so that no extensions get built. Bah,
it's a fk'n nightmare.. I give up.

Greg

[Tushar Teredesai]

Post by Greg Schafer
Tush, far out man! Was hoping for something a bit more "user-friendly" :-/
That sed is equivalent in hack value to my miniperl thing :)

Over the years (well ok one year;), I have reached the conclusion that
the only reliable way to get the perl build to obey your commands is "to
sed it out", even though the sed's turn out to be a little hairy:-) The
Configure script does accept some options from the command line, but
ignores some of them (like the libc setting). Same is the case with the
extensions.

My aim is to build the entire /stage1 before chrooting and then not have
to change anything in /stage1 one you chroot.

Post by Greg Schafer
For the life of me, I cannot figure out how to disable the building of the
extensions automatically. If I go through the Configure interactively, it
gives me the option to enter in "none" so that no extensions get built. Bah,
it's a fk'n nightmare.. I give up.

Yep, it is a nightmare. Tried many things before I finally settled for
sed as the optimal solution.

My aim is to build the complete /stage1 before 'chrooting' so that there
is no need to mess with it after chroot (similar to the current /static
scenario).

[Greg Schafer]

Post by Tushar Teredesai
Yep, it is a nightmare. Tried many things before I finally settled for
sed as the optimal solution.
My aim is to build the complete /stage1 before 'chrooting' so that there
is no need to mess with it after chroot (similar to the current /static
scenario).

Agreed. Thats why I'm not happy with current hint. We might just do the
miniperl thing in Ch 5 and be done with it.

Sidenote: I also found this other thing called microperl which is even
tinier than miniperl but it's a 3rd party package and not appropriate here I
feel.

Greg

[Tushar Teredesai]

Post by Greg Schafer
Sidenote: I also found this other thing called microperl which is even
tinier than miniperl but it's a 3rd party package and not appropriate here I
feel.

It may be official:-) Try make -f Makefile.micro in the perl-5.8.0
directory. But I dunno how complete it is.

[Greg Schafer]

Post by Tushar Teredesai

Post by Greg Schafer
Sidenote: I also found this other thing called microperl which is even
tinier than miniperl but it's a 3rd party package and not appropriate here I
feel.

It may be official:-) Try make -f Makefile.micro in the perl-5.8.0
directory. But I dunno how complete it is.

Heh, well spotted!

Official maybe. But not very well supported..

"You can now build a really minimal perl called microperl.
Building microperl does not require even running Configure;
C<make -f Makefile.micro> should be enough. Beware: microperl makes
many assumptions, some of which may be too bold; the resulting
executable may crash or otherwise misbehave in wondrous ways.
For careful hackers only."

and

"All this is experimental. If you don't know what to do with microperl
you probably shouldn't. Do not report bugs in microperl; fix the bugs."


***@tigers-lfs:~/src/temp1/perl-5.8.0$ ./microperl -V
Can't locate Config.pm in @INC (@INC contains: /usr/local/lib/perl5/5.7 .).
BEGIN failed--compilation aborted.


***@tigers-lfs:~/src/temp1/perl-5.8.0$ ./microperl -V -I
/usr/lib/perl5/5.8.0/i686-linux -I /usr/lib/perl5/5.8.0
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
<cut>

So it does work, but needs all the stuff in lib just like the miniperl
solution. The miniperl thing looks a better bet at this stage.

Keep'em coming dude! :-)

Greg

[Greg Schafer]

Post by Greg Schafer
Keep'em coming dude! :-)

Tush, I noticed in the perl "hints/linux.sh" this little snippet:-

if test -L /lib/libc.so.6; then
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
libc=/lib/$libc
fi

So you could possibly simplify your sed a bit by using something like that?

Greg

[Tushar Teredesai]

Post by Greg Schafer

Post by Greg Schafer
Keep'em coming dude! :-)

Tush, I noticed in the perl "hints/linux.sh" this little snippet:-
if test -L /lib/libc.so.6; then
libc=`ls -l /lib/libc.so.6 | awk '{print $NF}'`
libc=/lib/$libc
fi
So you could possibly simplify your sed a bit by using something like that?

Yeah I had looked that up, but then a sed for config.sh will be
converted into a sed/patch for hints/linux.sh.

[Greg Schafer]

Post by Tushar Teredesai
Yeah I had looked that up, but then a sed for config.sh will be
converted into a sed/patch for hints/linux.sh.

Yep agreed. Ok, fsck it. Here's a patch which appears to do the right thing.
I think I'll still stick with miniperl even though a full perl will actually
build in Ch 5 with this patch applied.

Greg

[Tushar Teredesai]

Post by Greg Schafer

Post by Tushar Teredesai
Yeah I had looked that up, but then a sed for config.sh will be
converted into a sed/patch for hints/linux.sh.

Yep agreed. Ok, fsck it. Here's a patch which appears to do the right thing.
I think I'll still stick with miniperl even though a full perl will actually
build in Ch 5 with this patch applied.

The problem with a patch is that the location is fixed to /stage1. Makes
it difficult to test out alternatives.

[Greg Schafer]

Post by Tushar Teredesai
The problem with a patch is that the location is fixed to /stage1. Makes
it difficult to test out alternatives.

Yes, but it solves my immediate problem neatly, unless I've missed your
point.. I'll stick with this patch for the pure_lfs hint. It's easy enough
to change in the future if ever /stage1 is changed to something else.

Thanks for your help with this Tush. It definitely steered me in the right
direction :-)

Greg

[Tushar Teredesai]

Post by Greg Schafer
So it does work, but needs all the stuff in lib just like the miniperl
solution. The miniperl thing looks a better bet at this stage.
Keep'em coming dude! :-)

:-) I think I will stick with the current "hodgy-podgy" seds for now.
Its a one time hack anyways and it goes in a script so I don't have to
see the ugliness.

[Alex Groenewoud]

Greg Schafer wrote:
[things are shaping up]

One suggestion: instead of using "/stage1" as the name for the
directory with temporary stuff, use "/scaffolding". It is a nice
long name that sticks out, just like good scaffolding does.

Also, "stage1" to me suggests that there might be a "stage2" and a
"stage3", as with gcc. "Scaffolding" implies that the next step is
the finished product.

Alex

[Tushar Teredesai]

Post by Alex Groenewoud
One suggestion: instead of using "/stage1" as the name for the
directory with temporary stuff, use "/scaffolding". It is a nice
long name that sticks out, just like good scaffolding does.
Also, "stage1" to me suggests that there might be a "stage2" and a
"stage3", as with gcc. "Scaffolding" implies that the next step is
the finished product.

/bootstrap?

[Frank Gore]

Excellent hint, I'll be tackling it this evening :)

I did notice one other slight issue other than the ones brought up by other
people. In most cases, the commands are generalized enough so that they can
be used with different versions of gcc without having to modify them. For
example, this line:

CFLAGS="-O2 -pipe" ../gcc-3*/configure --prefix=/stage1 \
--with-local-prefix=/stage1 --enable-languages=c \
--disable-nls --enable-shared &&

Would work on any version of gcc 3 that the user is installing without having
to edit the command. However there's one instance:

SPECFILE=/stage1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs

where version 3.2.1 is explicitly called. This is a silly little detail, but I
thought I'd point it out in the name of "anality", since that's the whole
driving force behind Pure LFS :) I probably wouldn't even have noticed it,
except that the line immediately following this command block specifically
states:

"We recommend you cut'n'paste the above rather than type it all in..."

but when I did that, it didn't work since I was installing gcc 3.2.2.

Frank

[Jules Colding]

Post by Frank Gore
SPECFILE=/stage1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
where version 3.2.1 is explicitly called. This is a silly little detail, but I
thought I'd point it out in the name of "anality", since that's the whole
driving force behind Pure LFS :) I probably wouldn't even have noticed it,
except that the line immediately following this command block specifically
"We recommend you cut'n'paste the above rather than type it all in..."
but when I did that, it didn't work since I was installing gcc 3.2.2.

I would recommend you to let gcc specify its own spec file. I am using:

gcc_spec ()
{
if [ -z "$1" ]; then
echo "No gcc executable in argument list for function, exiting..." 1>&2
return 1
fi
local gcc_bin=$1
readonly gcc_bin

if [ -z "$2" ]; then
echo "No sed executable in argument list for function, exiting..." 1>&2
return 1
fi
local sed_bin=$2
readonly sed_bin

local ver_str=$($gcc_bin -v 2>&1 | $sed_bin -n 1p)
local head="Reading specs from "
local spec=${ver_str##$head}

echo "$spec"

return 0
}
SPEC=$(gcc_spec gcc sed)

to do the trick.

[Greg Schafer]

Post by Frank Gore
Excellent hint, I'll be tackling it this evening :)
I did notice one other slight issue other than the ones brought up by other
people. In most cases, the commands are generalized enough so that they can
be used with different versions of gcc without having to modify them. For
CFLAGS="-O2 -pipe" ../gcc-3*/configure --prefix=/stage1 \
--with-local-prefix=/stage1 --enable-languages=c \
--disable-nls --enable-shared &&
Would work on any version of gcc 3 that the user is installing without having
SPECFILE=/stage1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
where version 3.2.1 is explicitly called. This is a silly little detail, but I
thought I'd point it out in the name of "anality", since that's the whole
driving force behind Pure LFS :) I probably wouldn't even have noticed it,
except that the line immediately following this command block specifically
"We recommend you cut'n'paste the above rather than type it all in..."
but when I did that, it didn't work since I was installing gcc 3.2.2.

my my, we are picky aren't we? :-)

But you're right. I'll change it to an asterix coz it works fine and solves
the problem you mention.

Thanks
Greg

[Greg Schafer]

Post by Alex Groenewoud
[things are shaping up]
One suggestion: instead of using "/stage1" as the name for the
directory with temporary stuff, use "/scaffolding". It is a nice
long name that sticks out, just like good scaffolding does.
Also, "stage1" to me suggests that there might be a "stage2" and a
"stage3", as with gcc. "Scaffolding" implies that the next step is
the finished product.

Thanks Alex for the suggestion. It also occurred to me there may be some
confusion with the gcc stage1 bootstrap. But we've already changed it once
and and will probably leave as is for now. 'Tis only a hint afterall. If it
(or some permutation of it) ever makes it into the book then Gerard may want
to use a new name at that point.

Greg

[Alex Groenewoud]

Post by Greg Schafer

Post by Alex Groenewoud
One suggestion: instead of using "/stage1" as the name for the
directory with temporary stuff, use "/scaffolding".

Thanks Alex for the suggestion. It also occurred to me there may
be some confusion with the gcc stage1 bootstrap.

Especially since STAGE1_CFLAGS is being used.

Post by Greg Schafer
But we've
already changed it once and and will probably leave as is for
now.

Well, as it has to improve, better give Gerard something good to
improve upon. How about "/thetools"?

If not that, then maybe "/framework", or "/staging", or "/trellis",
or simply "/stuff"?

Post by Greg Schafer
'Tis only a hint afterall.

Only a hint!? My, are you being modest. It is *the* hint since
Matthias' keeping-separate and package-users.

Alex

[Greg Schafer]

Post by Alex Groenewoud
Well, as it has to improve, better give Gerard something good to
improve upon. How about "/thetools"?
If not that, then maybe "/framework", or "/staging", or "/trellis",
or simply "/stuff"?

Wow! I actually like "/staging". I'll vote for that if the opportunity
arises :-)

Greg

[Tushar Teredesai]

Post by Greg Schafer
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

At the end of "Chapter 5 - Installing binutils - Pass 2 (shared)", when
recompilng ld, the LDFLAGS passed to make are "-all-static -s". Is the
-all-static a typo or does ld needs to be statically compiled?

[Greg Schafer]

Post by Tushar Teredesai

Post by Greg Schafer
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

At the end of "Chapter 5 - Installing binutils - Pass 2 (shared)", when
recompilng ld, the LDFLAGS passed to make are "-all-static -s". Is the
-all-static a typo or does ld needs to be statically compiled?

Cut'n'pasto :)

Luckily, we only need the ldscripts at that stage so it's inconsequential.

Now I know how Gerard feels when people report bugs in his book :-)

Thanks.
Greg

[Bill's LFS Login]

Post by Greg Schafer
LFS'ers
It's not quite finished yet but there is enough here for anyone to utilise
<snip>
Greg
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

In your recent pure-lfs, 'Last Modified: Sat Feb 15 03:43:25 UTC 2003',
'Chapter 6 - Kernel' compilation should be Chapter 8?

Other than that, I know *nothing*. But I have been running some build
scripts, buildch5-8-3.sh from Ryan (1 fail, 1 successful) and now a
modified one incorporating the changes listed in the above doc of yours
and some local "adjustments".

Chapter 5 goes pretty good except for the following three items.
== Item 1 ======================================================
### Glibc - initial - Sat Feb 15 12:18:46 EST 2003 ###
o Configure OK
o Build OK
XXXXXX glibc make check NOT OK - CHECK LOGS (glibc-init.log) XXXXXX
-Installing Glibc
o install OK
o ALL OK

Which is a math (double) failure. I modified the script to keep running,
based on some memory of posts that said those types were not critical,
IIRC. Probably because I'm running versions of something out-of-sync
with your testing. At least I hope that's all it is. I know this will need
to be resolved later.

== Item 2 ======================================================
### Make initial - (shared) - Sat Feb 15 17:22:41 EST 2003 ###
o Configure OK
o Build OK
o Test OK
o ALL OK
chgrp: changing group of `/stage1/bin/make': Operation not permitted

Since I am not running as root, I'm not surprised. I'll look into this
later and try and get some detail/fix.

== Item 3 ======================================================
### Gettext initial - (shared) - Sat Feb 15 17:31:32 EST 2003 ###
o Configure OK
o Build OK
XXXXXX NOT OK - CHECK LOGS (gettext-init.log) XXXXXX

Haven't checked this one yet. Going to let that ol' 6x86-II PR-300
(233.862 MHz) keep rolling until end of chapter 5 and then check it.

== End of Items ================================================

The Chapter 5 script includes Ryan's mods for zlib, bison, flex etc.
I had to guess at the sequencing of these items as the LFS book leaves
some doubt when matched to your doc's list. It's almost done, in bison
(the last thing before Ch 6, IIRC).

I have saved copies of all logs and dirs if y'all want them for
anything. I am intentionally running with things blended with the latest
LFS CVS book stuff. Glibc 2.2.5, gcc 3.2.1. Plus LFS CVS 20021006
upgraded to CVS 20021025 and some Blfs stuff. More detail available if
there is need/interest.

Currently setting up to try a chapter 6. Given the above, any concerns
about that? I am going to try everything, including kernel, with the
gcc/glibc/binutils et al installed in the Ch 5/6 Pure-lfs hint and
Ryan's scripts even though the gcc 2.95.3 is recommended. This is only
to see what will happen, can I boot/run with it. I'm hoping that it will
deliver all of us some benefits later.

Chapter 5 just finished. Dinner now and tomorrow I'll track stuff down.

[Greg Schafer]

Post by Bill's LFS Login
In your recent pure-lfs, 'Last Modified: Sat Feb 15 03:43:25 UTC 2003',
'Chapter 6 - Kernel' compilation should be Chapter 8?

You are correct... again! :) Fixed.

Post by Bill's LFS Login
Chapter 5 goes pretty good except for the following three items.
== Item 1 ======================================================
### Glibc - initial - Sat Feb 15 12:18:46 EST 2003 ###
o Configure OK
o Build OK
XXXXXX glibc make check NOT OK - CHECK LOGS (glibc-init.log) XXXXXX
-Installing Glibc
o install OK
o ALL OK
Which is a math (double) failure. I modified the script to keep running,
based on some memory of posts that said those types were not critical,
IIRC. Probably because I'm running versions of something out-of-sync
with your testing. At least I hope that's all it is. I know this will need
to be resolved later.

The Ch 5 glibc is not as critical as the one in Ch 6. If that still fails
then definitely need to investigate. Could be processor or arch specific.
Should be more clues in the *.out file e.g. test-double.out. It may be
explained if you are using glibc-2.2.5 instead of 2.3.1.

Post by Bill's LFS Login
== Item 2 ======================================================
### Make initial - (shared) - Sat Feb 15 17:22:41 EST 2003 ###
o Configure OK
o Build OK
o Test OK
o ALL OK
chgrp: changing group of `/stage1/bin/make': Operation not permitted

That is a bug in current LFS CVS. The chgrp thing is no longer req'd with
latest make. Additionally, Ryan seems to have used the Ch 6 instructions for
Ch 5 in his script. I wouldn't have done it that way :-/

Post by Bill's LFS Login
Since I am not running as root, I'm not surprised. I'll look into this
later and try and get some detail/fix.
== Item 3 ======================================================
### Gettext initial - (shared) - Sat Feb 15 17:31:32 EST 2003 ###
o Configure OK
o Build OK
XXXXXX NOT OK - CHECK LOGS (gettext-init.log) XXXXXX
Haven't checked this one yet. Going to let that ol' 6x86-II PR-300
(233.862 MHz) keep rolling until end of chapter 5 and then check it.
== End of Items ================================================
The Chapter 5 script includes Ryan's mods for zlib, bison, flex etc.
I had to guess at the sequencing of these items as the LFS book leaves
some doubt when matched to your doc's list. It's almost done, in bison
(the last thing before Ch 6, IIRC).
I have saved copies of all logs and dirs if y'all want them for
anything. I am intentionally running with things blended with the latest
LFS CVS book stuff. Glibc 2.2.5, gcc 3.2.1. Plus LFS CVS 20021006
upgraded to CVS 20021025 and some Blfs stuff. More detail available if
there is need/interest.
Currently setting up to try a chapter 6. Given the above, any concerns
about that? I am going to try everything, including kernel, with the
gcc/glibc/binutils et al installed in the Ch 5/6 Pure-lfs hint and
Ryan's scripts even though the gcc 2.95.3 is recommended. This is only
to see what will happen, can I boot/run with it. I'm hoping that it will
deliver all of us some benefits later.
Chapter 5 just finished. Dinner now and tomorrow I'll track stuff down.

Ryan may be able to comment on some of the above as I haven't been using his
script directly. The kernel compiled with gcc-3 will definitely boot and
run, afterall this is how current LFS has been for ages. But AC may not be
too happy :-)

Thanks Bill for your testing and feedback.

Greg

[R***@pha.com.au]

Greetings all,

Post by Greg Schafer

Post by Bill's LFS Login
o ALL OK
chgrp: changing group of `/stage1/bin/make': Operation not permitted

That is a bug in current LFS CVS. The chgrp thing is no longer req'd with
latest make. Additionally, Ryan seems to have used the Ch 6 instructions

for

Post by Greg Schafer
Ch 5 in his script. I wouldn't have done it that way :-/

Cut'n'pasto ;-) Works for me :-) will stare at it again some more ;-)

Beat me with a wet lettuce for being a cowboy, but I build the whole dang
lot as root ( and to hell with the consequences ;-) ).

The scripts are out of sync now after my four day hiatus due to moving,
will get them in order by tomorrow sometime...

Regards
Ryan

[R***@pha.com.au]

Greetings Again,

[R***@pha.com.au]

Post by Frank Gore
SPECFILE=/stage1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
thought I'd point it out in the name of "anality", since that's the whole
driving force behind Pure LFS :) I probably wouldn't even have noticed

it,

Post by Frank Gore
except that the line immediately following this command block

<SNIP>

Post by Frank Gore
gcc_spec ()
{
if [ -z "$1" ]; then
echo "No gcc executable in argument list for function, exiting..." 1>

&2

Post by Frank Gore
return 1
fi
local gcc_bin=$1
readonly gcc_bin
if [ -z "$2" ]; then
echo "No sed executable in argument list for function, exiting..." 1>

&2

Post by Frank Gore
return 1
fi
local sed_bin=$2
readonly sed_bin
local ver_str=$($gcc_bin -v 2>&1 | $sed_bin -n 1p)
local head="Reading specs from "
local spec=${ver_str##$head}
echo "$spec"
return 0
}
SPEC=$(gcc_spec gcc sed)
to do the trick.

Not quite anal enough :-)

You still wont have the architecture though, what if we ain't building on
an i686, some of us have old sparcs lying around (damn noisy powerhungry
old bastards, but god bless'em they just keep on running ;-) )

This from the script... ( we already know the version of gcc )

TGT_TRIPLE=`/stage1/bin/gcc -dumpmachine`
SPECFILE=/stage1/lib/gcc-lib/${TGT_TRIPLE}/${GCC_VER}/specs
cp ${SPECFILE} ./XX
sed 's@/lib/ld-linux.so.2@/stage1/lib/ld-***@g' ./XX > ${SPECFILE}
rm -f ./XX

Regards
Ryan

[Jules Bjørn Colding]

But the architecture is embedded in the SPEC string that is returned
from my gcc_spec() function, no?
--
jules

Post by R***@pha.com.au
Not quite anal enough :-)
You still wont have the architecture though, what if we ain't building on
an i686, some of us have old sparcs lying around (damn noisy powerhungry
old bastards, but god bless'em they just keep on running ;-) )
This from the script... ( we already know the version of gcc )
TGT_TRIPLE=`/stage1/bin/gcc -dumpmachine`
SPECFILE=/stage1/lib/gcc-lib/${TGT_TRIPLE}/${GCC_VER}/specs
cp ${SPECFILE} ./XX
rm -f ./XX
Regards
Ryan

[Frank Gore]

Post by Greg Schafer
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

Any chance the hint could be hosted somewhere that's actually up and running?
:( I never thought to make a local copy. I've been trying to connect to
zipworld.com.au all day long without any success. I volunteer my own site if
necessary (it's never gone down).

Frank

[unknown]

Post by Frank Gore

Post by Greg Schafer
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

Any chance the hint could be hosted somewhere that's actually up and running?
:( I never thought to make a local copy. I've been trying to connect to
zipworld.com.au all day long without any success. I volunteer my own site
if necessary (it's never gone down).
Frank

its working here - might be a problem with your dns (i used to have the same
problems accessing sourceforge)

-----
Jay

[unknown]

Post by Frank Gore
Any chance the hint could be hosted somewhere that's actually up and running?

It works for me at the moment. If it's still an issue there is always the LFS
server that can be used to store it (even as a temp place until it's moved
into the hints archive)

[James Iwanek]

[Tushar Teredesai]

[R***@pha.com.au]

Post by unknown
Now that I have played with it, here is how I got perl to compile
against the glibc in /stage1 in Chapter 5:-)

<SNIP>
Mate, that rocks :-) Will have a play with it tonight :-)

[Bill's LFS Login]

Post by unknown

Post by Frank Gore

Post by Greg Schafer
http://www.zipworld.com.au/~gschafer/pure_lfs.txt

Any chance the hint could be hosted somewhere that's actually up and
running?
:( I never thought to make a local copy. I've been trying to connect to
zipworld.com.au all day long without any success. I volunteer my own site
if necessary (it's never gone down).

I had the same problem. Not dns. Getting request refused. Tried links and
even the .com site says that. It is working again now.

Post by unknown

Post by Frank Gore
Frank

its working here - might be a problem with your dns (i used to have the same
problems accessing sourceforge)
-----
Jay

[R***@pha.com.au]

Excellent fellas :-)
will update the ch5 script tonight with a horrible sed to mimic the patch ;
-)

Time to knock the last few outstanding issues on their head ;-)

[Bill's LFS Login]

Post by Greg Schafer

Post by Greg Schafer
<snip>
Chapter 5 goes pretty good except for the following three items.
== Item 1 ======================================================
### Glibc - initial - Sat Feb 15 12:18:46 EST 2003 ###
o Configure OK
o Build OK
XXXXXX glibc make check NOT OK - CHECK LOGS (glibc-init.log) XXXXXX
-Installing Glibc
o install OK
o ALL OK
Which is a math (double) failure. I modified the script to keep running,
based on some memory of posts that said those types were not critical,
IIRC. Probably because I'm running versions of something out-of-sync
with your testing. At least I hope that's all it is. I know this will need
to be resolved later.

The Ch 5 glibc is not as critical as the one in Ch 6. If that still fails
then definitely need to investigate. Could be processor or arch specific.
Should be more clues in the *.out file e.g. test-double.out. It may be
explained if you are using glibc-2.2.5 instead of 2.3.1.

These results do not include your very latest changes. The system is
essentially from your Saturday hint.

Well, the math errors are still there, same ones as before, IIRC. If we
need to confirm if they differ, I have the chap 5 stuff tarred up. Since
you said you would have concern if they still existed in chapter 6, I
thought I would post.

Googled for a couple minimal combinations of glibc and "... math ...
ldouble". A short thread involving Roland McGrath (looks like it might
apply, but I lack enough understanding, v 2.1.94?) and H. J. Liu(sp?)
about ia64. Since I'm on an IBM 6x86-II PR-300, the latter seemed to be
not applicable. I've attached math/test-ldouble.out.

In one of those threads they mentioned a new ulp(?) file, which I
surmise are the expected results to act as comparands. I wonder if that
is what I need.

As I said before, these are very small differences with which I have
little concern (no scientific or math apps) and I can live with them
AFAIK. I am dropping the '&&' from the make check invocation and
proceeding.

If you've some major concerns, or words of wisdom/patch, just holler. If
you now feel it is not an issue, silence is understood.

OH! BTW, I'm using the gcc-core, gcc-g++ archives rather than the unified
gcc archive, if it makes any difference.

A couple of displays from w/i chroot environ:

root:/# gcc -v
Reading specs from /stage1/lib/gcc-lib/i686-pc-linux-gnu/3.2.1/specs
Configured with: ../gcc-3.2.1/configure --prefix=/stage1
--with-local-prefix=/stage1 --enable-languages=c,c++ --disable-nls
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 3.2.1

On the following, I'm still doing make localedata/install-locales
and so the info is from the end of Chap 5 (Ryan's scripts).

root:/# /lib/libc-2.3.1.so
GNU C Library stable release version 2.3.1, by Roland McGrath et al.
<snip>
Compiled by GNU CC version 3.2.1.
Compiled on a Linux 2.4.20 system on 2003-02-18.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
<snip>

readelf -a /stage1/bin/gcc|grep nterpret
[Requesting program interpreter: /stage1/lib/ld-linux.so.2]

root:/# cat /proc/cpuinfo
processor : 0
vendor_id : CyrixInstead
cpu family : 6
model : 2
model name : M II 3.5x Core/Bus Clock
stepping : 8
cpu MHz : 233.862
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 pge cmov mmx cyrix_arr
bogomips : 466.94

Post by Greg Schafer

Post by Greg Schafer
<snip>

Greg

[Greg Schafer]

Post by Bill's LFS Login
Well, the math errors are still there, same ones as before, IIRC. If we
need to confirm if they differ, I have the chap 5 stuff tarred up. Since
you said you would have concern if they still existed in chapter 6, I
thought I would post.

<snip>

Post by Bill's LFS Login
As I said before, these are very small differences with which I have
little concern (no scientific or math apps) and I can live with them
AFAIK. I am dropping the '&&' from the make check invocation and
proceeding.

You might need "make -k check" there otherwise the tests halt and don't
continue on to the end of the test suite. Of course "make -k check" may
cause folk to not notice errors so I'll leave the plain version in the hint.
Another thought, grep a log file for errors using for e.g.:-

grep "\*\*\*" check.log

or whatever.

Post by Bill's LFS Login
If you've some major concerns, or words of wisdom/patch, just holler. If
you now feel it is not an issue, silence is understood.

Only 10 out of 2520 failed and they do indeed seem minor. The math tests are
a bit of a grey area but I'm sure they are sensitive to CPU specifics. The
right thing to do (if it is a major concern) is to recheck with the latest
CVS glibc and if failures are still present, create a new ULP file as per
the instructions then submit for inclusion in the next release. But it may
not be worth it for such a boutique (and bit outdated) CPU :-)

Post by Bill's LFS Login
OH! BTW, I'm using the gcc-core, gcc-g++ archives rather than the unified
gcc archive, if it makes any difference.

Real men use the full archive :-)
/me runs..

Greg

[R***@pha.com.au]

Post by Seth W.Klein
I get the impression Ryan's script supports NLS. I would be interested
in seeing that in the hint.
On a related note, can anyone give me a quick instructions for testing
basic NLS functionality? I'm a clueless American ;) so i don't know
what i'm talking about, but i'm thinking of something like
``LANG=fr ls --help'' or some such.

You just hit on why it isn't in the hint yet :-) Haven't worked out a way
to test it fully and properly yet ( we're clueless aussies ;-) )

[Bill's LFS Login]

Post by Greg Schafer

Well, the math errors are still there, [...]

You might need "make -k check" there otherwise the tests halt and don't
continue on to the end of the test suite. Of course "make -k check" may

I'll do this on the next pass and post if there are any new items.

Post by Greg Schafer
cause folk to not notice errors so I'll leave the plain version in the hint.
Another thought, grep a log file for errors using for e.g.:-
grep "\*\*\*" check.log
or whatever.

The only '.log' in glibc is config.log. Nothing in there with stars or
Error. My console log had the Error and *** only right after the make
check detected the math errors. Also, no name check.* looked like that
either. I check each console log for each step run for 'Error' or '***'
(with backslashes ). So I'm clean on that score I think. I normally only
look at config.log files if I see one of he other two in the console
log or something catches my eye.

Post by Greg Schafer

If you've some major concerns, or words of wisdom/patch, just holler. If
you now feel it is not an issue, silence is understood.

Only 10 out of 2520 failed and they do indeed seem minor. The math tests are
a bit of a grey area but I'm sure they are sensitive to CPU specifics. The

That was my suspicion.

Post by Greg Schafer
right thing to do (if it is a major concern) is to recheck with the latest
CVS glibc and if failures are still present, create a new ULP file as per
the instructions then submit for inclusion in the next release. But it may

I'll wait until I feel I can't do more pure-lfs testing. Consistency is
useful during these types of activities.

Post by Greg Schafer
not be worth it for such a boutique (and bit outdated) CPU :-)

He-he! Well, I'm sitting on a K6-III 380 Mhz that will replace the
"boutique" CPU when I get another full install done (including some
Blfs) and a wild hair in the appropriate anatomical location. Will that
still qualify as "boutique", albeit a *much* faster one?

[Gerard Beekmans]

[unknown]

Post by unknown

Post by Greg Schafer
If this ever gets integrated into the book, it will drastically reduce the

I'm actually hoping to add it to CVS very soon now. It will wait for a few
more weeks for logistic reasons (the prime one being that I'm moving in a
few days and won't have an Internet connection for about week after I
move. More on this in a separate email).

Post by Greg Schafer
I'm still tempted to write a shorter version which doesn't go into as
much detail and doesn't take as much care, but still utilises all the
same principles. This shorter version could go into the book in a snap
and would instantly be a huge win over current LFS.

Ok that doens't sit well with me. It sounds to me as though that shorted
document would cut some corners (you actually uses that phrase (shorter
doc will cut corners)a while ago). What will be the impact of the shorter
version? If the short version goes in the book, would people still be
interested in the longer version in the form of a hint?

Can I reinforce that!

The educative power of the full hint is superb. I have learnt a whole lot
building Chapter 5/pure today, and I don't know how else I would have got
this info. BTW: works OK with HJ's binutils (no patch, but a fiddle with
configure, documented elsewhere), coreutils-4.1.7. So far as I can tell as
I start Chapter 6...

[Tushar Teredesai]

Post by unknown

Post by Greg Schafer
I'm still tempted to write a shorter version which doesn't go into as much
detail and doesn't take as much care, but still utilises all the same
principles. This shorter version could go into the book in a snap and would
instantly be a huge win over current LFS.

Ok that doens't sit well with me. It sounds to me as though that shorted
document would cut some corners (you actually uses that phrase (shorter doc
will cut corners)a while ago). What will be the impact of the shorter
version? If the short version goes in the book, would people still be
interested in the longer version in the form of a hint?

I agree, the hint is excellent as is. The only two shortcuts that could
be taken are not recompilng binutils and gcc dynamically after compiling
glibc in Ch 5, but don't think it is good avoiding it.

(For Greg) The hint mentions that the Pass 1 static gcc compilation can
be skipped if the host gcc is atleast 3.2. But it is not optional, coz
if someone skip's that step, they will be unable to adjust the gcc spec
file to lock in the newly compiled glibc. Though the gcc recompile
immediately after adjusting the spec file ensures that the new glibc is
used. So maybe adjusting the spec file after the glibc compile is redundant.

[unknown]

Just a thought that occured to me while reading the various "Pure LFS"
threads. Now that everyone seems convinced we're building a more
reliable toolchain using this method do you think that any of the LKML
or toolchain guys would be interested in taking a look at the proposed
method and provide feedback. Or are they too adamant to remain on their
high-horse and continue to discredit LFS?

Matt.

[Justin Hibbits]

Post by unknown
Just a thought that occured to me while reading the various "Pure LFS"
threads. Now that everyone seems convinced we're building a more
reliable toolchain using this method do you think that any of the LKML
or toolchain guys would be interested in taking a look at the proposed
method and provide feedback. Or are they too adamant to remain on their
high-horse and continue to discredit LFS?
Matt.

Haven't you learned by now that if it doesn't come from redhat, the LKML dudes
don't want anything to do with it? :)

-Justin

[Matt Reppert]

On Thu, 20 Feb 2003 12:40:45 -0500

Post by Justin Hibbits

Post by unknown
Just a thought that occured to me while reading the various "Pure LFS"
threads. Now that everyone seems convinced we're building a more
reliable toolchain using this method do you think that any of the LKML
or toolchain guys would be interested in taking a look at the proposed
method and provide feedback. Or are they too adamant to remain on their
high-horse and continue to discredit LFS?
Matt.

Haven't you learned by now that if it doesn't come from redhat, the LKML dudes
don't want anything to do with it? :)

No. And as a reader and occasional contributor to lkml, and someone who only
uses Debian and LFS, I think you're wrong, even though you're joking -_^

Actually, Rusty Russell, the new modules system maintainer in 2.5, is a Debian
guy. Also, the Gentoo release manager used to hang out in the offtopic IRC channel
associated with #kernelnewbies.

Matt

[Matt Reppert]

On Thu, 20 Feb 2003 17:33:17 -0000

Post by unknown
Just a thought that occured to me while reading the various "Pure LFS"
threads. Now that everyone seems convinced we're building a more
reliable toolchain using this method do you think that any of the LKML
or toolchain guys would be interested in taking a look at the proposed
method and provide feedback.

Possibly. I haven't had time to look at purelfs yet ... how close is it to
some of the established distro build sequences? And more importantly, what
sort of fixes against *known release bugs* are we incorporating? Not all
toolchain errors are due to compiling stuff wrong, after all.

If we're going to do this, I'd prefer to wait a while, but probably the best
person to ask would be someone who does release management (IMO).

Post by unknown
Or are they too adamant to remain on their high-horse and continue to
discredit LFS?

That's not really being fair. ^_^; If something is buggy, it's buggy. Currently,
realtime signals are unusable in LFS' glibc 2.3.1 due to a glibc bug that's
already patched in Debian unstable. (At least, they are on my ia32 system.
I'm going to go out and get another drive to stick in my test box so I can play
around with experimental stuff more ... )

Rather than be bitter towards people who are pointing out our mistakes, it
would be better to learn from them and improve our system. No? (Yes, I know
that Alan never said anything here, but I think it was rather nice of Andries
to make the mtab suggestion a couple of months back.)

Matt

[Tushar Teredesai]

Post by Matt Reppert
Possibly. I haven't had time to look at purelfs yet ... how close is it to
some of the established distro build sequences? And more importantly, what
sort of fixes against *known release bugs* are we incorporating? Not all
toolchain errors are due to compiling stuff wrong, after all.

I agree. There are many patches against the released versions
incorporated by redhat, mandrake, gentoo and debian which never make it
to the released versions or are incorporated very late.

Maybe we could have a lfs-patches list and/or
patches.linuxfromscratch.org site that would collect patches that are
significant. something similar to the hints.

[unknown]

Post by Matt Reppert
Rather than be bitter towards people who are pointing out our

mistakes, it

Post by Matt Reppert
would be better to learn from them and improve our system. No? (Yes, I know
that Alan never said anything here, but I think it was rather nice of Andries
to make the mtab suggestion a couple of months back.)

But that's the point - they don't point out our mistakes. They claimed
there are mistakes in the current method, but not what those mistakes
were - and because it's all fairly low level toolchain stuff some of the
mistakes may not be too obvious. There is a distinction between slating
something and providing constructive criticism - IMO it was the former
that was provided. I'm just glad there are several willing volunteers
(Greg, Ryan, et al.) that are trying to improve the build method to get
these guys off our backs. It actually works out better for both parties
(the LFS community and the LKML) as once our build method is deemed good
enough, when we provide bug reports, etc. then they should be recognised
and reacted to. The only concern I have is that I'm not sure whether
the Pure LFS will result in a respected toolchain. Please don't get me
wrong - I have the utmost respect and admiration for the current work
that is going on and the level of commitment being shown, I just wonder
whether without toolchain & kernel guys/gurus on board the proposed
build method will be received kindly by anyone outside LFS.

Regards,

Matt.

[Jeroen Coumans]

Post by Matt Reppert
That's not really being fair. ^_^; If something is buggy, it's buggy. Currently,
realtime signals are unusable in LFS' glibc 2.3.1 due to a glibc bug that's
already patched in Debian unstable. (At least, they are on my ia32 system.
I'm going to go out and get another drive to stick in my test box so I can play
around with experimental stuff more ... )

Would that be the bug that attached patch fixes? (taken from the debian
diff) What other patches should we apply from them (I'm not expert
enough to find out myself :( )

Post by Matt Reppert
Rather than be bitter towards people who are pointing out our mistakes, it
would be better to learn from them and improve our system. No? (Yes, I know
that Alan never said anything here, but I think it was rather nice of Andries
to make the mtab suggestion a couple of months back.)

I agree with Tush that we should have an lfs-patches mailinglist where
patches from vendors can be evaluated and added. It scares me that
important things like the above aren't fixed. I assume it's something
that Alan also implied in his criticism against LFS's toolchain.

[unknown]

Post by Jeroen Coumans
I agree with Tush that we should have an lfs-patches mailinglist where
patches from vendors can be evaluated and added.

+1 here! It would also allow us to incorporate security related patches
(from bugtraq, et al.) in the event that an official release isn't
available at the time of a new LFS revision.

Post by Jeroen Coumans
It scares me that
important things like the above aren't fixed. I assume it's something
that Alan also implied in his criticism against LFS's toolchain.

Assumptions & implications...easily avoidable if Alan would have come
straight out and said something like "Until LFS fixes their toolchain
(it's broken because of X)..." then we'd all be the wiser.

Matt.

[Matt Reppert]

On Thu, 20 Feb 2003 19:38:55 +0100

Post by Jeroen Coumans

Post by Matt Reppert
That's not really being fair. ^_^; If something is buggy, it's buggy. Currently,
realtime signals are unusable in LFS' glibc 2.3.1 due to a glibc bug that's
already patched in Debian unstable. (At least, they are on my ia32 system.
I'm going to go out and get another drive to stick in my test box so I can play
around with experimental stuff more ... )

Would that be the bug that attached patch fixes? (taken from the debian
diff) What other patches should we apply from them (I'm not expert
enough to find out myself :( )

Exactly that, yes. *grumbles* I only found out about it by noticing some package
(lsof or tcpdump maybe, I don't remember) saying that glibc 2.3.1 would *not*
work, and then sorting through some of the Debian patches to see what they were.

It would probably be a good idea to have more lfs-dev folks subscribing to upstream
mailing lists, like Greg is doing now, and filter bug reports and fixes to us.
(A major reason I'm not volunteering to do so right now for glibc is because I'm
not sure I'd have the time to do it right. But, I'm getting another drive to stick
in my Alpha box soon, and I'll be testing a whole bunch of stuff, eventually NPTL
on 2.5.)

Once I have my head screwed on more about what bugs are actually out there I'd
like to submit patches for some here, but not until we have some sort of
system to handle it. With stuff like this bug, and the strength-reduction bug in
gcc 2.95, I really don't think that just grabbing stuff from upstream is desirable.

On Thu, 20 Feb 2003 19:03:48 -0000

Post by Jeroen Coumans

Post by Matt Reppert
I agree with Tush that we should have an lfs-patches mailinglist where
patches from vendors can be evaluated and added.

+1 here! It would also allow us to incorporate security related patches
(from bugtraq, et al.) in the event that an official release isn't
available at the time of a new LFS revision.

Yeah. I agree too. It's an excellent idea, also since
1) If an LFSer finds a bug, it could make it easier to deal with sending
reports and patches upstream;
2) It gives us a place to put patches for known bugs in current releases.

Post by Jeroen Coumans

Post by Matt Reppert
It scares me that
important things like the above aren't fixed. I assume it's something
that Alan also implied in his criticism against LFS's toolchain.

Assumptions & implications...easily avoidable if Alan would have come
straight out and said something like "Until LFS fixes their toolchain
(it's broken because of X)..." then we'd all be the wiser.

True. I'm not sure if we determined if he was talking about LFS in specific
or just non-"traditional distro" people in general. But still, none of us
asked him about it after it came out (at least IIRC). I guess bearded,
Welsh-speaking[1] Britons with big hats are scary :3

It did strike me, though, when I read the first message on LKML that one of
the most important issues here was that LFS doesn't patch known bugs that
other distros do.

Matt

[1] Check out his portaloo recently.

[unknown]

Post by Matt Reppert

Post by unknown
Assumptions & implications...easily avoidable if Alan would have come
straight out and said something like "Until LFS fixes their

toolchain

Post by Matt Reppert

Post by unknown
(it's broken because of X)..." then we'd all be the wiser.

True. I'm not sure if we determined if he was talking about LFS in specific
or just non-"traditional distro" people in general. But still, none of us
asked him about it after it came out (at least IIRC). I guess bearded,
Welsh-speaking[1] Britons with big hats are scary :3
It did strike me, though, when I read the first message on LKML that one of
the most important issues here was that LFS doesn't patch known bugs that
other distros do.

This begs another question...when is it that the upstream developers
finally put patches like this in. Surely it would be better to fix the
problem at its source, rather than have to provide a cure for a symptom
caused by the original package? This is especially so if most if not
all the "regular" distros are having to include the same patch. I know
we don't live in a perfect world, but somewhere closer than this has got
to be achievable, no?

[Jeroen Coumans]

Post by unknown
This begs another question...when is it that the upstream developers
finally put patches like this in.

Just for the record: the rtsig.dpatch I attached was taken by Debian out
of glibc-CVS (prob. the 2.3.2 branch). So the problem is fixed, it's
just not released yet. But that doesn't give us an excuse for knowing
about bugs but not fixing them because there's no new release available.
In the past patching had been done on a "ad-hoc" basis: someone found a
patch and passed it on. A list as lfs-patches could be the
infrastructure needed to collect, test and discuss patches, just as
lfs-security. OTOH this will also cause more fragmentation, and people
can always send patches to lfs-dev... (I'm now wondering why everybody
thinks we need lfs-patches to discuss patches... ). I guess we just need
more people looking at those patches... :(
Well, here's hoping that after the pure_lfs method is implemented, the
build method is perfect so community efforts can target developer patches :)

Hmm isn't there allready a patch-list we can take advantage of? Like
Debian's or Gentoo's?

[unknown]

Post by Jeroen Coumans
Hmm isn't there allready a patch-list we can take advantage of? Like
Debian's or Gentoo's?

[Tushar Teredesai]

Post by unknown
This begs another question...when is it that the upstream developers
finally put patches like this in. Surely it would be better to fix the
problem at its source, rather than have to provide a cure for a symptom
caused by the original package? This is especially so if most if not
all the "regular" distros are having to include the same patch. I know
we don't live in a perfect world, but somewhere closer than this has got
to be achievable, no?

I think there was an article on slashdot(?) a few moons back on how the
patches by the distros are not sent back to the package maintainers and
hence never get incorporated into the mainstream. The article mentioned
linux kernel patches but indicated that it was the case for many other
packages.

[Greg Schafer]

Post by Jeroen Coumans
I agree with Tush that we should have an lfs-patches mailinglist where
patches from vendors can be evaluated and added.

Yes, but we need manpower to analyse, test, integrate and so forth. How many
programmers capable of doing this do we have on the list? Not many methinks.

Post by Jeroen Coumans
It scares me that
important things like the above aren't fixed. I assume it's something
that Alan also implied in his criticism against LFS's toolchain.

Don't be scared :-) No, thats not what he meant. For starters, only gcc and
binutils matter when compiling kernels. What you are talking about above is
a straight out bug in glibc. Now that the bug has been identified, we can
look at applying a patch in LFS if needed. The first thing that occurs to me
is how many folk are going to be affected by it? If not many, then do we
really need to worry? But if important then yes lets fix it. I'll say it
again, we are not a distro and are are not generally capable of catering
to the masses.

Greg

[Tushar Teredesai]

Post by Greg Schafer

Post by Jeroen Coumans
I agree with Tush that we should have an lfs-patches mailinglist where
patches from vendors can be evaluated and added.

Yes, but we need manpower to analyse, test, integrate and so forth. How many
programmers capable of doing this do we have on the list? Not many methinks.

I was hinting at just collecting the patches similar to how the hints
are collected. All the patches would be "use at your own risk". The
process for incorporating a patch into the book would still be the same
as it is currrently.

[unknown]

Post by Tushar Teredesai
I was hinting at just collecting the patches similar to how the hints
are collected. All the patches would be "use at your own risk". The
process for incorporating a patch into the book would still be the same
as it is currrently.

I don't think it's a bad idea. It could just be a dumping ground, but I don't
think anybody should expect a certain level of period checking, evaluating,
etc. We just don't have the resources. But at least it'd be a central place
where all kinds of patches can be sent to and you can pick and choose.

Would we want a separate blfs-patches too then (I know OT for this list, but
while I'm at it the BLFS core team can mull over it and bring it up on
blfs-dev if they see fit. I'm not going to cross-post it).

Let's give it some thought. At the earliest something like this can be setup
after March 1st.

[Ian Molton]

On Thu, 20 Feb 2003 17:48:21 +0000 (UTC)

Post by Matt Reppert

Post by unknown
Or are they too adamant to remain on their high-horse and continue
to discredit LFS?

That's not really being fair. ^_^

It damn well is.

Post by Matt Reppert
Rather than be bitter towards people who are pointing out our
mistakes, it would be better to learn from them and improve our
system. No?

Very few things mentioned by [those who will remain nameless] have been
constructive.

[Greg Schafer]

Post by Matt Reppert
Possibly. I haven't had time to look at purelfs yet ... how close is it to
some of the established distro build sequences?

It is not close at all. It currently cannot be, due to the very nature of
what makes LFS tick. Distros are package manager oriented. LFS is not. Their
build environments are completely different to ours.

Post by Matt Reppert
And more importantly, what
sort of fixes against *known release bugs* are we incorporating? Not all
toolchain errors are due to compiling stuff wrong, after all.

Don't start me :-) If we were a distro with real paid developers then we
might be able to keep up. And don't give me the Debian argument :) Over the
past 12 or 18 months LFS has done a fair job of keeping up with the critical
issues.

Post by Matt Reppert
Rather than be bitter towards people who are pointing out our mistakes, it
would be better to learn from them and improve our system. No? (Yes, I know
that Alan never said anything here, but I think it was rather nice of Andries
to make the mtab suggestion a couple of months back.)

Yes, but it wasn't niceness that brought him here. It was getting bogus bug
reports from LFS users methinks :)

Greg

[Greg Schafer]

Post by unknown
Just a thought that occured to me while reading the various "Pure LFS"
threads. Now that everyone seems convinced we're building a more
reliable toolchain using this method do you think that any of the LKML
or toolchain guys would be interested in taking a look at the proposed
method and provide feedback. Or are they too adamant to remain on their
high-horse and continue to discredit LFS?

I disagree with this. Senior Linux and open source "identities" are not
likely to give a "rats arse" about developing a new LFS build method. Sure,
the LFS project is becoming more widely known and the fact that the these
guys know about it is great, but I would rather "let the proof of the
pudding be in the eating". i.e. let reputation take its natural course.

Lets face it, as much as I'd like us to be, we are not a distro. We don't
have paid developers and proper infrastructure. Part of the appeal of LFS is
the "do it yourself" nature of it and this is always going to lead to some
folk going off the rails. My whole reason for working on improvements is to
get the basics right so that we have a solid foundation which will hopefully
shine through in a better reputation.

Greg

[Greg Schafer]

Post by Tushar Teredesai
(For Greg) The hint mentions that the Pass 1 static gcc compilation can
be skipped if the host gcc is atleast 3.2. But it is not optional, coz
if someone skip's that step, they will be unable to adjust the gcc spec
file to lock in the newly compiled glibc. Though the gcc recompile
immediately after adjusting the spec file ensures that the new glibc is
used. So maybe adjusting the spec file after the glibc compile is redundant.

Ahh, very good point! That shortcut dates back to the very beginning of
Ryan's and my discussions. It's not worth it so I think we'll flick it
(speak up Ryan if you don't agree :-)

Thanks Tush.

Greg

[Greg Schafer]

Post by unknown
I'm actually hoping to add it to CVS very soon now. It will wait for a few
more weeks for logistic reasons (the prime one being that I'm moving in a few
days and won't have an Internet connection for about week after I move. More
on this in a separate email).

Good, coz we need more time to get it finished :-)

Post by unknown
Ok that doens't sit well with me. It sounds to me as though that shorted
document would cut some corners (you actually uses that phrase (shorter doc
will cut corners)a while ago). What will be the impact of the shorter
version? If the short version goes in the book, would people still be
interested in the longer version in the form of a hint?

Gerard, have you had a good look at the hint yet? There are some possible
obstacles to getting it into the book. Number one, due to more rebuilds and
a few more Ch 5 packages, the whole process will take a lot longer. There is
also the "make check" stuff in there which really blows out the time even
more.

Everything we do in the hint is not absolutely essential. Some stuff is just
being super cautious and could be dropped. When the pure_lfs project first
started, I discussed with Ryan the possibility of using the shorter doc as a
"stepping stone" to full blown purity. It's still a possibility.

Here is a quick summation of how I envisaged the shorter doc would work:-

Ch 5:
- still use /stage1
- still put /stage1/bin at the head of the PATH
- binutils static
- gcc static
- glibc
- adjust the gcc specs
- rest of Ch 5 shared (only add ncurses, not gettext nor perl)

Ch 6:
- glibc (with the perl patch)
- readjust the gcc specs
- binutils
- gcc
- rest of normal Ch 6

It's not that different to current LFS. It should work, but definitely won't
be as anal as the hint, and it would instantly solve a lot of the current
LFS gripes.

Anyway, I prefer full blown purity so back to the hint for me :-)

Greg

[Tushar Teredesai]

Post by Greg Schafer
Gerard, have you had a good look at the hint yet? There are some possible
obstacles to getting it into the book. Number one, due to more rebuilds and
a few more Ch 5 packages, the whole process will take a lot longer. There is
also the "make check" stuff in there which really blows out the time even
more.

(IMO) It is ok if the build takes more time, it is more imporatant to
get it right and be super cautious. If the user is worried about the
time it takes to compile, then {,s}he should be be compiling packages
from the source in the first place:-)

The "make check" can be dropped from the book or should be marked as
optional in the book.

Also, the book could have shortcut alerts like the one you have in the
hint, but they should have the usual "Not Recommended" sign posted.

Post by Greg Schafer
Anyway, I prefer full blown purity so back to the hint for me :-)

Me 2:-)

[unknown]

Post by Greg Schafer
Gerard, have you had a good look at the hint yet? There are some possible
obstacles to getting it into the book. Number one, due to more rebuilds and
a few more Ch 5 packages, the whole process will take a lot longer. There
is also the "make check" stuff in there which really blows out the time
even more.

Yes I read the full hint as it appeared this morning.

I'm actually not worried about the fact that it takes a lot longer to compile.
We are doing all this work to improve the overall quality. If it means some
extra time compiling to get there, that's acceptable to me. I rather do it
perfectly right than compromise some of the purity out of build time
constraints.

What I would perfer at this point: The full hint in the book and the shorter
version as a hint. The book can then have a few sentences outlining what the
shorter version of the doc does differently, that it saves you some time (if
you build from an LFS system that was build from a full pure-lfs setup, you
can affort to be less anal because you can already trust your toolchain to be
perfect) but will be less thorough, or anal if you will.

Post by Greg Schafer
It's not that different to current LFS. It should work, but definitely
won't be as anal as the hint, and it would instantly solve a lot of the
current LFS gripes.
Anyway, I prefer full blown purity so back to the hint for me :-)

I think a lot of us agree with that sentiment. Time is a small price to pay
for the comfort of knowing it's done right and might even meet with aproval
from a technical point of view.

And lastly, that is possibly raises the bar a bit is not a huge deal either.

So: let's have it! (the full blown hint)

[unknown]

Post by Greg Schafer
If this ever gets integrated into the book, it will drastically reduce the

I'm actually hoping to add it to CVS very soon now. It will wait for a few
more weeks for logistic reasons (the prime one being that I'm moving in a few
days and won't have an Internet connection for about week after I move. More
on this in a separate email).

Post by Greg Schafer
I'm still tempted to write a shorter version which doesn't go into as much
detail and doesn't take as much care, but still utilises all the same
principles. This shorter version could go into the book in a snap and would
instantly be a huge win over current LFS.

Ok that doens't sit well with me. It sounds to me as though that shorted
document would cut some corners (you actually uses that phrase (shorter doc
will cut corners)a while ago). What will be the impact of the shorter
version? If the short version goes in the book, would people still be
interested in the longer version in the form of a hint?

[Gerard Beekmans]

[Richard A Downing]

[Matthew Burgess]

[Matthew Burgess]

[Matthew Burgess]

[Matthew Burgess]

[Matthew Burgess]

[Gerard Beekmans]

[R***@pha.com.au]

Post by Greg Schafer
Ahh, very good point! That shortcut dates back to the very beginning of
Ryan's and my discussions. It's not worth it so I think we'll flick it
(speak up Ryan if you don't agree :-)

hehehe I think you already know how anal I am :-)
[R]

[R***@pha.com.au]

Post by Greg Schafer

Post by Alex Groenewoud
Well, as it has to improve, better give Gerard something good to
improve upon. How about "/thetools"?
If not that, then maybe "/framework", or "/staging", or "/trellis",
or simply "/stuff"?

Wow! I actually like "/staging". I'll vote for that if the opportunity
arises :-)

Hehehe, now we have the minor stuff out of the way I see we are tackling
the big issues now ;-)

[unknown]

Post by R***@pha.com.au
Hehehe, now we have the minor stuff out of the way I see we are tackling
the big issues now ;-)

How about: /ryanandgregwerehere :-)

[Gerard Beekmans]

[R***@pha.com.au]

Post by unknown
I don't think it's a bad idea. It could just be a dumping ground, but I

don't

Post by unknown
think anybody should expect a certain level of period checking,

evaluating,

Post by unknown
etc. We just don't have the resources. But at least it'd be a central

place

Post by unknown
where all kinds of patches can be sent to and you can pick and choose.

I reckon its a good idea, just as long as the "Dumping Ground" is organised
by distro and package, preferably with a timestamp and link to postings
about its purpose soo we can track what their overall aim is...

Otherwise it is a recipe for disaster, mixing patches from different
distros who may be trying to achieve different ends... <shudder>

[unknown]

Post by R***@pha.com.au
I reckon its a good idea, just as long as the "Dumping Ground" is organised

That would require some dicipline from our end, the one sending a patch in.
We'd have to put up some guidelines what is an acceptable posting, that
includes where the patch is, who made it, what it does and other important
info.

Now, just having a mailinglist will make it easy to loose track of patches.
Maybe we should setup a new parent bug in Bugzilla under which we add new
bugs. If a patch to the lfs-patches list is accepted someboyd can go to
bugzilla and add it. That could be our official accepted patch list,
including notest here, test case reports.

[Richard A Downing]

[Bill's LFS Login]

Post by R***@pha.com.au

Post by Greg Schafer

Post by Alex Groenewoud
Well, as it has to improve, better give Gerard something good to
improve upon. How about "/thetools"?
If not that, then maybe "/framework", or "/staging", or "/trellis",
or simply "/stuff"?

Wow! I actually like "/staging". I'll vote for that if the opportunity
arises :-)

Hehehe, now we have the minor stuff out of the way I see we are tackling
the big issues now ;-)

No, it's called parallel development! Viewed in critical path or pert
chart terms, the software and presentation development occur
simultaneously and are completed at nearly the same time.

---- software refinement -----+\
---- presentation issues ----+ \
\__\____Completion
---- packaging created ----+/ /
---- other items needed -----+/

0----- +1 ----- +2 ----- +3 ----- +4 ----- Time (days/weeks/months)

You just overlooked the fact that maximaum utilization of resources is
occurring! ;)

[Gerard Beekmans]

[Tushar Teredesai]

Post by unknown

Post by R***@pha.com.au
I reckon its a good idea, just as long as the "Dumping Ground" is organised

That would require some dicipline from our end, the one sending a patch in.
We'd have to put up some guidelines what is an acceptable posting, that
includes where the patch is, who made it, what it does and other important
info.
Now, just having a mailinglist will make it easy to loose track of patches.
Maybe we should setup a new parent bug in Bugzilla under which we add new
bugs. If a patch to the lfs-patches list is accepted someboyd can go to
bugzilla and add it. That could be our official accepted patch list,
including notest here, test case reports.

It can be set similar to the hints section, people submt hints to the
list and it is posted to a website by some maintainer(s). There can be a
template defined similar to the hints template. Also, the list could
contain both lfs and blfs (so maybe the name could be just ***@lfs
or submit-***@lfs..).

I think the procedure for official patches should still be the same.
Only security related and other critical patches.

I would be happy to help in maintaining the patches list.

[unknown]

Post by Tushar Teredesai
It can be set similar to the hints section, people submt hints to the
list and it is posted to a website by some maintainer(s). There can be a
template defined similar to the hints template. Also, the list could

I thought about that, but patches may have a lot of meta-data associated with
them, such as test cases, more notes what a patch does, bugs in the patches
themselves, and so forth. It's easier and quicker to add a note to Bugzilla
rather than having to submit a patch-hint that has to be comitted to CVS
and/or website.

I think a WiKi style would work best for these patches, but I then prefer
Bugzilla over it. Gives us easier control of closing a patch (ie it's
invalid, or has been fixed in a package's next release)

[Gerard Beekmans]