Glibc-2.3.3 tarball

[Greg Schafer]

Hi

Ok, here is the current status:

I'm going to place these commands into Ch 4 which have been used to create
our unofficial tarball that will hopefully be mirrored by our LFS mirror
sites that agree to it. (I'm counting on Gerard to sort out this mirroring
aspect).

cvs -z 9 -d :pserver:***@sources.redhat.com:/cvs/glibc \
export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc

tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202

Notice I've used "export" instead of "checkout" which means we miss out on
all the "CVS" cruft. Notice also that the chosen name indicates clearly that
this is an unofficial tarball which I think is important. But a downside to
this name is that some aesthetics may be lost e.g. the headings in the Glibc
sections will be:

"Installing Glibc-2.3.3-20031202"

which looks a little unsightly but I suppose we could always hack around it
in the LFS XML source with some entity-fu.

Notice also that "2003-12-02 UTC" is equivalent to "2003-12-02 00:00:00
UTC". There is no point in stuffing about with hours, minutes and seconds
when YMD notation works fine for our purposes here (think about it -- the
next commit after the 2.3.3 cutoff at "2003-12-01 08:29:33 UTC" was at
"2003-12-02 07:37:29 UTC").

The Glibc build commands will need to be modified slightly. Either we change
"--enable-add-ons" to "--enable-add-ons=linuxthreads" or we simply slot in a
"rm -r nptl*", which is probably easier. Also, if we want to avoid a
spurious and harmless warning about a missing autoconf, we might want to add
"--without-cvs".


IMPORTANT
=========
Of course, there is a catch to all of this and that is -- by using the new
Glibc we are bringing on the pain of the Coreutils POSIX compliance madness.
IMNSHO we have no choice but to adopt the stance that at least Debian and
RedHat have taken and that is to patch coreutils so that the old behaviour
is preserved. I know there will be folks who object to this. Fine, your
distro your rules. But for the LFS book there is really no choice. I have
thought about this long and hard and have come to the conclusion that
patching is the correct way to go for the general case. For those who want
pain, the new "reject old syntax" behaviour can still be had by setting an
environment variable, or you can just elect not to use the patch and deal
with the consequences yourself.

Here is the proposed patch:

http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-5.0-posixver-1.patch

There are still plenty of ongoing heated discussions happening around the
place where diehard toolchain developers think the coreutils maintainers
have done the wrong thing with this whole affair. I tend to agree with them.

In the meanwhile, if there are keen testing folks out there who want to test
all of the above before it goes into the book, please feel free and don't
forget to report your experiences.

Essentially, I'd like to have our unofficial tarball available for download
from the mirrors before putting all of the above into the book.

Greg

[Ken Moffat]

On Sat, 10 Jan 2004, Greg Schafer wrote:

> Hi
>
> Ok, here is the current status:
>
> I'm going to place these commands into Ch 4 which have been used to create
> our unofficial tarball that will hopefully be mirrored by our LFS mirror
> sites that agree to it. (I'm counting on Gerard to sort out this mirroring
> aspect).
>

Sounds good for CVS, but I hope somebody is going to branch it before
5.1 heads for release ?

Ken
--
This is a job for Riviera Kid!

[Greg Schafer]

On Sat, Jan 10, 2004 at 01:33:48PM +0000, Ken Moffat wrote:
> Sounds good for CVS, but I hope somebody is going to branch it before
> 5.1 heads for release ?

No, the plan is to get Glibc in before we branch. Otherwise there is little
value in a 5.1 release at all IMHO. A few upgraded minor pkgs and few bugfixes?
Big deal! We need to get the new Glibc in now so that the big 6.0 upheavals
are more bearable. It's the smart thing to do.

All reports of new Glibc use are positive. Anyone who follows Glibc
development will agree. They didn't give me this toolchain manintainers job
for nothing! :-)

[Ken Moffat]

On Sun, 11 Jan 2004, Greg Schafer wrote:

> On Sat, Jan 10, 2004 at 01:33:48PM +0000, Ken Moffat wrote:
> > Sounds good for CVS, but I hope somebody is going to branch it before
> > 5.1 heads for release ?
>
> No, the plan is to get Glibc in before we branch. Otherwise there is little
> value in a 5.1 release at all IMHO. A few upgraded minor pkgs and few bugfixes?
> Big deal! We need to get the new Glibc in now so that the big 6.0 upheavals
> are more bearable. It's the smart thing to do.

Call me pessimistic, but I'd put the recent kernel security issues as a
major reason to issue an "errata", if we were a distro. Which means I'd
like to see a release ASAP. Unless I've misunderstood you, people have
been testing bleeding-edge lfs-derived builds with 2.3.3 and 2.6
kernels, but 2.3.3 hasn't made it into our CVS yet. To me, that
suggests it needs wider testing before it is promoted to an LFS release.

>
> All reports of new Glibc use are positive. Anyone who follows Glibc
> development will agree. They didn't give me this toolchain manintainers job
> for nothing! :-)
>

Yep, your call on whether it goes in. If you're happy then release
away. The thought of people using a 2.4.22 kernel and putting public
services onto it scares me.

Ken
--
This is a job for Riviera Kid!

[Daniel Baumann]

Ken Moffat wrote:

>Call me pessimistic, but I'd put the recent kernel security issues as a
>major reason to issue an "errata", if we were a distro. Which means I'd
>like to see a release ASAP. Unless I've misunderstood you, people have
>been testing bleeding-edge lfs-derived builds with 2.3.3 and 2.6
>kernels, but 2.3.3 hasn't made it into our CVS yet. To me, that
>suggests it needs wider testing before it is promoted to an LFS release.
>
>
Imho the security-fixed-only lfs-5.0 should be 5.01, with upgraded glibc
5.1.

--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
E-mail: ***@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/

[unknown]

Greg Schafer <***@zip.com.au> writes:

> cvs -z 9 -d :pserver:***@sources.redhat.com:/cvs/glibc \
> export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc
>
> tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202

> http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-5.0-posixver-1.patch

> Essentially, I'd like to have our unofficial tarball available for download
> from the mirrors before putting all of the above into the book.


So we want to test the new glibc tarball and the coreutils patch with
what's in HEAD now?

Billy

[Greg Schafer]

On Sat, Jan 10, 2004 at 09:10:53AM -0500, Billy O'Connor wrote:
> Greg Schafer <***@zip.com.au> writes:
>
> > cvs -z 9 -d :pserver:***@sources.redhat.com:/cvs/glibc \
> > export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc
> >
> > tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202
>
> > http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-5.0-posixver-1.patch
>
> > Essentially, I'd like to have our unofficial tarball available for download
> > from the mirrors before putting all of the above into the book.
>
>
> So we want to test the new glibc tarball and the coreutils patch with
> what's in HEAD now?

Yes, if possible. But because the new unofficial tarball is not yet
mirrored for download, only if the cvs download is an option. Thanks.

[Bruce Dubbs]

Greg Schafer wrote:

>IMPORTANT
>=========
>Of course, there is a catch to all of this and that is -- by using the new
>Glibc we are bringing on the pain of the Coreutils POSIX compliance madness.
>
Greg,
I have not been keeping up with this. Can you give a summary or a
pointer to the issues?

>IMNSHO we have no choice but to adopt the stance that at least Debian and
>RedHat have taken and that is to patch coreutils so that the old behaviour
>is preserved. I know there will be folks who object to this. Fine, your
>distro your rules. But for the LFS book there is really no choice. I have
>thought about this long and hard and have come to the conclusion that
>patching is the correct way to go for the general case. For those who want
>pain, the new "reject old syntax" behaviour can still be had by setting an
>environment variable, or you can just elect not to use the patch and deal
>with the consequences yourself.
>
>Here is the proposed patch:
>
>http://www.linuxfromscratch.org/patches/downloads/coreutils/coreutils-5.0-posixver-1.patch
>
>There are still plenty of ongoing heated discussions happening around the
>place where diehard toolchain developers think the coreutils maintainers
>have done the wrong thing with this whole affair. I tend to agree with them.
>
>
Again, what is "the wrong thing"?

-- Bruce

[Greg Schafer]

On Sat, Jan 10, 2004 at 04:26:00PM -0600, Bruce Dubbs wrote:
> Greg Schafer wrote:
>
> >IMPORTANT
> >=========
> >Of course, there is a catch to all of this and that is -- by using the new
> >Glibc we are bringing on the pain of the Coreutils POSIX compliance
> >madness.
> >
> Greg,
> I have not been keeping up with this. Can you give a summary or a
> pointer to the issues?

This thread should cover it:

http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00082.html

[Bruce Dubbs]

Greg Schafer wrote:

>On Sat, Jan 10, 2004 at 04:26:00PM -0600, Bruce Dubbs wrote:
>
>
>>Greg Schafer wrote:
>>
>>
>>
>>>IMPORTANT
>>>=========
>>>Of course, there is a catch to all of this and that is -- by using the new
>>>Glibc we are bringing on the pain of the Coreutils POSIX compliance
>>>madness.
>>>
>>>
>>>
>>Greg,
>> I have not been keeping up with this. Can you give a summary or a
>>pointer to the issues?
>>
>>
>
>This thread should cover it:
>
>http://mail.gnu.org/archive/html/bug-coreutils/2003-09/msg00082.html
>
>
Thanks for the pointer. That explains the problem.

Now, the issue is how LFS should handle it. IMHO we should include a
patch that enables the old functionality. We should also explain the
issue in the text and let the user decide whether to use the patch or not.

-- Bruce

[Greg Schafer]

On Sat, Jan 10, 2004 at 08:26:36PM -0600, Bruce Dubbs wrote:
> Thanks for the pointer. That explains the problem.
>
> Now, the issue is how LFS should handle it. IMHO we should include a
> patch that enables the old functionality. We should also explain the
> issue in the text and let the user decide whether to use the patch or not.

Yes, that's basically what the proposal is. Except with one major difference
-- the LFS book must take a default stand, and that stand is to apply the
patch. Leaving it optional will most certainly lead to grief. We cannot
leave that avenue open. But I suppose we could word it in such a way where
the consequences of not patching are clear.

[Bruce Dubbs]

Greg Schafer wrote:

>On Sat, Jan 10, 2004 at 08:26:36PM -0600, Bruce Dubbs wrote:
>
>
>>Thanks for the pointer. That explains the problem.
>>
>>Now, the issue is how LFS should handle it. IMHO we should include a
>>patch that enables the old functionality. We should also explain the
>>issue in the text and let the user decide whether to use the patch or not.
>>
>>
>
>Yes, that's basically what the proposal is. Except with one major difference
>-- the LFS book must take a default stand, and that stand is to apply the
>patch. Leaving it optional will most certainly lead to grief. We cannot
>leave that avenue open. But I suppose we could word it in such a way where
>the consequences of not patching are clear.
>
>
Thats what I meant. Probably in the part that explains the patch.
Something like: "This patch restores compatability with many scripts of
several programs (e.g. head, tail, et al.) by restoring an option of
-<number> instead of -n <number>. This capability has been declared
obsolete, but the traditional behavior is so pervasive that we recommend
the patch."

Personally, I think the new behavior is more consistent and I won't put
it in _my_ personal builds.

-- Bruce

[Steve Martin]

On Sun, 2004-01-11 at 22:57, Bruce Dubbs wrote:
<snip>
> Thats what I meant. Probably in the part that explains the patch.
> Something like: "This patch restores compatability with many scripts of
> several programs (e.g. head, tail, et al.) by restoring an option of
> -<number> instead of -n <number>. This capability has been declared
> obsolete, but the traditional behavior is so pervasive that we recommend
> the patch."
>
> Personally, I think the new behavior is more consistent and I won't put
> it in _my_ personal builds.
Nor shall I be including it in mine, the attached script takes the pain
out of the LFS build when you don't use the patch; I have this included
as two functions in my main build scripts which get called after each
package is unpacked and before applying any patches. So far so good.

And Greg, there are many of us who really appreciate what you do!

--
Steve Martin <***@netcomuk.co.uk>

Still can't think of anything witty to write here.

[Zack Winkles]

[Steve Martin]

On Tue, 2004-01-13 at 22:34, Zack Winkles wrote:
> Decent piece of work, but Ryan's script catches a lot more cases, almost
> all of them as a matter of fact. Use his instead.

You mean like this?

Actually I haven't seen Ryan's script; unless you mean his build scripts
which, again, I do not use. I've been building LFS with my own scripts
for too long to change them now....Ryans stuff is excellent though! ;-)

--
Steve Martin <***@netcomuk.co.uk>

Still can't think of anything witty to write here.

[Zack Winkles]

[Steve Martin]

On Wed, 2004-01-14 at 21:36, Zack Winkles wrote:
> Jacked straight from Ryan's scripts, of course.

Thanks, that'll save me having to work out the other stuff; although my
original is all you need for the base LFS build.
--
Steve Martin <***@netcomuk.co.uk>

Still can't think of anything witty to write here.

[Greg Schafer]

On Tue, Jan 13, 2004 at 10:27:07PM +0000, Steve Martin wrote:
> On Sun, 2004-01-11 at 22:57, Bruce Dubbs wrote:
> > Personally, I think the new behavior is more consistent and I won't put
> > it in _my_ personal builds.
> Nor shall I be including it in mine, the attached script takes the pain
> out of the LFS build when you don't use the patch; I have this included
> as two functions in my main build scripts which get called after each
> package is unpacked and before applying any patches. So far so good.

The main problem with this approach of automated fixage is that you're not
fixing the problems at the core. i.e. the upstream packages need to be fixed
eventually so someone needs to be sending patches upstream.

It could well be argued that those distros and folks like us who use the
"behaviour restoring" coretils patch are not assisting this effort to get
all the old usage updated. But I would counteract that argument by saying we
are not here to save the world from Posix stupidity. We are here to get on
with our job of building LFS.

> And Greg, there are many of us who really appreciate what you do!

Cheers cobber :-)

[Justin Knierim]

On Behalf Of Greg Schafer
>> On Sat, Jan 10, 2004 at 09:10:53AM -0500, Billy O'Connor wrote:
>> > Greg Schafer <***@zip.com.au> writes:
>> >
>> > > cvs -z 9 -d :pserver:***@sources.redhat.com:/cvs/glibc \
>> > > export -d glibc-2.3.3-20031202 -D "2003-12-02 UTC" libc
>> > >
>> > > tar jcvf glibc-2.3.3-20031202.tar.bz2 glibc-2.3.3-20031202
>> >
>> > >
>> http://www.linuxfromscratch.org/patches/downloads/coreutils/co
>reutil
>> > s-5.0-posixver-1.patch
>>
>> > Essentially, I'd like to have our unofficial tarball available for
>> > download from the mirrors before putting all of the above into the
>> > book.
>>
>>
>> So we want to test the new glibc tarball and the coreutils patch with

>> what's in HEAD now?
>
>Yes, if possible. But because the new unofficial tarball is not yet
>mirrored for download, only if the cvs download is an option. Thanks.

Hello,

I used your instructions for pulling the CVS of glibc. Could you please
check:

ftp://ftp.lfs-matrix.de/cvs-testing/cvs-output.txt

To see if the cvs pull was ok. I believe it was. If you agree it is,
then if anyone would like to start testing, the package is available for
download here:

ftp://ftp.lfs-matrix.de/cvs-testing/glibc-2.3.3-20031202.tar.bz2

MD5 Checksum:

ftp://ftp.lfs-matrix.de/cvs-testing/glibc-2.3.3-20031202.md5

The coreutils posix patch is also mirrored here:

ftp://ftp.lfs-matrix.de/cvs-testing/coreutils-5.0-posixver-1.patch

I host one of the official mirrors for LFS, so distribute to whomever
you want, or announce it to the list. If something is wrong or you do
not want it publicly hosted yet, let me know, and I will pull it off.

--
Mit freundlichen Grüßen,

Justin R. Knierim
Lfs at jrknierim dot de

[Greg Schafer]

On Sat, Jan 10, 2004 at 11:47:48PM +0100, Justin Knierim wrote:
> I used your instructions for pulling the CVS of glibc. Could you please
> check:
>
> ftp://ftp.lfs-matrix.de/cvs-testing/cvs-output.txt

No, viewing some output doesn't prove anything.

> To see if the cvs pull was ok. I believe it was. If you agree it is,
> then if anyone would like to start testing, the package is available for
> download here:
>
> ftp://ftp.lfs-matrix.de/cvs-testing/glibc-2.3.3-20031202.tar.bz2
>
> MD5 Checksum:
>
> ftp://ftp.lfs-matrix.de/cvs-testing/glibc-2.3.3-20031202.md5
>
> The coreutils posix patch is also mirrored here:
>
> ftp://ftp.lfs-matrix.de/cvs-testing/coreutils-5.0-posixver-1.patch
>
> I host one of the official mirrors for LFS, so distribute to whomever
> you want, or announce it to the list. If something is wrong or you do
> not want it publicly hosted yet, let me know, and I will pull it off.

Anyone can pull the code from CVS and make their own tarball. That's why I
posted the instructions :-) But for the LFS unofficial tarball that will
hopefully be mirrored by kind mirror admins like yourself, I think it would
be best if a "blessed" tarball is the one gets mirrored. Like I said, I'm
working with Gerard to try and make this happen. But in reality, the blessed
tarball should be identical to what one would pull down by following the
instructions.

[Justin Knierim]

On Behalf Of Greg Schafer
> No, viewing some output doesn't prove anything.

Ok, no problem. Just want to cover my ass in case it did not work. ;)

> Anyone can pull the code from CVS and make their own tarball.
> That's why I posted the instructions :-) But for the LFS
> unofficial tarball that will hopefully be mirrored by kind
> mirror admins like yourself, I think it would be best if a
> "blessed" tarball is the one gets mirrored. Like I said, I'm

Also no problem. I will host that blessed tarball when Gerard or
whoever makes it. If you would rather I wait and remove the tarball, i
can do that also. It is no big deal.

--
mfg,

Justin R. Knierim
Lfs at jrknierim dot de

[Vyrl Sutton]

----- Original Message -----
From: "Greg Schafer" <***@zip.com.au>
Newsgroups: lfs.dev
To: <lfs-***@linuxfromscratch.org>
Sent: Saturday, January 10, 2004 06:52
Subject: Glibc-2.3.3 tarball


> Hi
>snip<
> Greg

I am having some compile problems. I am using
lfs-book-cvs-html-2004-01-10. I am using optimizations
CFLAGS="-Os -march=athlon-xp" and HJ's binutils-2.14.90.0.7. I
followed the instructions and used "--enable-add-ons=linuxthreads"
and "--without-cvs". The configuration portion runs clean and during
make I get:

sed > /mnt/lfs/sources/glibc-build/param.h.dep-t \
-e 's@/usr/include/sys/param.h@@' \
-e 's@^.*:@@' \
-e 's@/mnt/lfs/sources/glibc-build/param.h.c@@g'
\
-e 's@/usr/include/*@@g' \
-e 's@\\$@@' \
-e 's@^@sys/param.h-includes := $(sys/param.h-includes) @'
mv /mnt/lfs/sources/glibc-build/param.h.dep-t
/mnt/lfs/sources/glibc-build/param.h.dep
gawk 'BEGIN { subdirs = ""; inhibit = "" }; \
/^#/ { next }; \
/^[^-]/ { subdirs = subdirs " " $0 }; \
/^-/ { inhibit = inhibit " " substr($0, 2) }; \
END { printf "sysdep-subdirs =%s\n", subdirs; \
printf "sysdep-inhibit-subdirs =%s\n", inhibit; \
print "sysd-dirs-done = t" }' \
/dev/null linuxthreads/sysdeps/pthread/Subdirs
sysdeps/unix/inet/Subdirs sysdeps/unix/Subdirs >
/mnt/lfs/sources/glibc-build/sysd-dirs-tmp
mv -f /mnt/lfs/sources/glibc-build/sysd-dirs-tmp
/mnt/lfs/sources/glibc-build/sysd-dirs
make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.3.3-20031202'
make[1]: Entering directory `/mnt/lfs/sources/glibc-2.3.3-20031202'
{ echo '#include "posix/bits/posix1_lim.h"'; \
echo '#define _LIBC 1'; \
echo '#include "misc/sys/uio.h"'; } | \
gcc -B/tools/bin/ -E -dM -MD -MP -MF
/mnt/lfs/sources/glibc-build/bits/stdio_lim.dT -MT
'/mnt/lfs/sources/glibc-build/bits/stdio_lim.h
/mnt/lfs/sources/glibc-build/bits/stdio_lim.d' \
-Iinclude -I. -I/mnt/lfs/sources/glibc-build -Ilibio -I/mnt/lf
s/sources/glibc-build -Isysdeps/i386/elf -Ilinuxthreads/sysdeps/unix/s
ysv/linux/i386 -Ilinuxthreads/sysdeps/unix/sysv/linux -Ilinuxthreads/s
ysdeps/pthread -Isysdeps/pthread -Ilinuxthreads/sysdeps/unix/sysv -Ili
nuxthreads/sysdeps/unix -Ilinuxthreads/sysdeps/i386/i686 -Ilinuxthread
s/sysdeps/i386 -Isysdeps/unix/sysv/linux -Isysdeps/gnu -Isysdeps/unix/
common -Isysdeps/unix/mman -Isysdeps/unix/inet -Isysdeps/unix/sysv/i38
6 -Isysdeps/unix/sysv -Isysdeps/unix/i386 -Isysdeps/unix -Isysdeps/pos
ix -Isysdeps/i386/i686/fpu -Isysdeps/i386/i686 -Isysdeps/i386/i486 -Is
ysdeps/i386/fpu -Isysdeps/i386 -Isysdeps/wordsize-32 -Isysdeps/ieee754
/ldbl-96 -Isysdeps/ieee754/dbl-64 -Isysdeps/ieee754/flt-32 -Isysdeps/i
eee754 -Isysdeps/generic/elf -Isysdeps/generic -nostdinc -isystem
/tools/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include -isystem
/tools/include -xc - -o /mnt/lfs/sources/glibc-build/bits/stdio_lim.hT
In file included from
linuxthreads/sysdeps/pthread/bits/pthreadtypes.h:23,
from posix/sys/types.h:266,
from include/sys/types.h:1,
from misc/sys/uio.h:24,
from <stdin>:3:
sysdeps/generic/bits/sched.h:22:3: #error "Never include
<bits/sched.h> directly; use <sched.h> instead."
make[1]: *** [/mnt/lfs/sources/glibc-build/bits/stdio_lim.st] Error 1
make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.3.3-20031202'
make: *** [all] Error 2

I tried googling the LFS site and recieved no results. Any Ideas?

Thanks Vyrl

[Bruce Dubbs]

Vyrl Sutton wrote:

>I am having some compile problems.
>

Wrong list. Try lfs-support.
-- Bruce

[Vyrl Sutton]

----- Original Message -----
From: "Bruce Dubbs" <***@swbell.net>
Newsgroups: lfs.dev
To: "LFS Development List" <lfs-***@linuxfromscratch.org>
Sent: Sunday, January 11, 2004 11:38
Subject: Re: Glibc-2.3.3 tarball


> Vyrl Sutton wrote:
>
> >I am having some compile problems.
> >
>
> Wrong list. Try lfs-support.
> -- Bruce
>
>
I am having problems with Glibc-2.3.3 using Greg's instructions. The
last time I looked LFS 5 was using Glibc-2.3.2. Where do I post for
problems with the CVS book?

Vyrl

[Greg Schafer]

On Sun, Jan 11, 2004 at 11:49:00AM -0500, Vyrl Sutton wrote:
> I am having problems with Glibc-2.3.3 using Greg's instructions. The
> last time I looked LFS 5 was using Glibc-2.3.2. Where do I post for
> problems with the CVS book?

You're also using HJL binutils, non-standard CFLAGS and gawd knows what
else. Bruce is right, wrong list. lfs-hackers may also be appropriate.

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

Greg Schafer wrote:
> On Sun, Jan 11, 2004 at 11:49:00AM -0500, Vyrl Sutton wrote:
> > I am having problems with Glibc-2.3.3 using Greg's instructions. The
> > last time I looked LFS 5 was using Glibc-2.3.2. Where do I post for
> > problems with the CVS book?

> You're also using HJL binutils, non-standard CFLAGS and gawd knows what
> else. Bruce is right, wrong list. lfs-hackers may also be appropriate.

IIRC there were some BIG warnings about stuffing with optimizations et al
with glibc in the book.
They were there for a reason, don't mess with it.

There's no issues using HJL Binutils though...

[R]

[James Robertson]

Greg Schafer wrote:
> Hi

[Snip...]

Hi Greg and all.

Please forgive any potential ignorance on this subject, but why do we
_want_ to bring upon ourselves the coreutils problem and the need for a
non-official tarball release that we have to manage? I am confused. Is
Glibc 2.3.2 not good enough? I know (I think) that 2.3.3 has NPTL in it
and 2.3.2 does not, but you only need that if you are running linux
2.6.x right? What else is in there that requires us to upgrade and ring
trouble on ourselves. We are not a distro and so do not do things like
the distros do - rememeber? With this coreutils issue coming to light I
think it would be prudent to wait until the dust settles some more (even
more?). I know we want to be on the edge, but some things can wait
until they stablize some. Greg, I know you are the resident expert on
the toolchain and Glibc is well within your area of control, but I am
skeptical as to the need for this change at this time. Can't we wait
until we decide to get linux 2.6.x into the book? I am still not sure
if the whole "headers" thing got settled, which also effects Glibc and
all the rest of the userland packages we install.

Thanks
James

[Robert Day]

On Mon, 2004-01-12 at 14:39, James Robertson wrote:

> Please forgive any potential ignorance on this subject, but why do we
> _want_ to bring upon ourselves the coreutils problem and the need for a
> non-official tarball release that we have to manage? I am confused. Is
> Glibc 2.3.2 not good enough? I know (I think) that 2.3.3 has NPTL in it
> and 2.3.2 does not, but you only need that if you are running linux
> 2.6.x right? What else is in there that requires us to upgrade and ring
> trouble on ourselves. We are not a distro and so do not do things like
> the distros do - rememeber? With this coreutils issue coming to light I
> think it would be prudent to wait until the dust settles some more (even
> more?). I know we want to be on the edge, but some things can wait
> until they stablize some. Greg, I know you are the resident expert on
> the toolchain and Glibc is well within your area of control, but I am
> skeptical as to the need for this change at this time. Can't we wait
> until we decide to get linux 2.6.x into the book? I am still not sure
> if the whole "headers" thing got settled, which also effects Glibc and
> all the rest of the userland packages we install.

The simple answer is that the glibc team does not plan on releasing
anymore tarballs, period. So sooner or later we are going to have no
choice but to either make our own tarball, or show users how to get the
version from CVS (most likely a tiomestamped release from teh cvs
repository that was used to build the LFS they are following)

The more complex answer, well, if there is one, it's beyond my knowlege
;)

Rob Day (BOFH)

[Greg Schafer]

On Mon, Jan 12, 2004 at 01:39:01PM -0600, James Robertson wrote:
> Please forgive any potential ignorance on this subject, but why do we
> _want_ to bring upon ourselves the coreutils problem and the need for a
> non-official tarball release that we have to manage?

James, you need to stay abreast of the issues. If you can't, then you need
to respect the judegement of those that sre doing so i.e. me :-)

> I am confused. Is
> Glibc 2.3.2 not good enough?

No. There are apparent security issues (dunno how serious, but they are
there). There also compiler issues. Glibc-2.3.2 is better matched with
gcc-3.2.x. This is evidenced by the bazillion inlining failed type warnings
that are not present in 2.3.3. There are numerous other code improvements
worthy of calling it 2.3.3. Other distros are running much newer Glibc code
than us. Part of the LFS appeal is that it is up to date. In short, 2.3.2 is
now so old it ain't funny.

> I know (I think) that 2.3.3 has NPTL in it
> and 2.3.2 does not, but you only need that if you are running linux
> 2.6.x right?

NPTL has nothing to do with this upgrade.

> What else is in there that requires us to upgrade and ring
> trouble on ourselves. We are not a distro and so do not do things like
> the distros do - rememeber?

Wow, that is an extremely vague and unhelpful comment and almost insulting
to me.

> With this coreutils issue coming to light I
> think it would be prudent to wait until the dust settles some more (even
> more?).

Huh? This issue has been known about for half a year at least. See my para
at start of this mail.

> I know we want to be on the edge, but some things can wait
> until they stablize some. Greg, I know you are the resident expert on
> the toolchain and Glibc is well within your area of control, but I am
> skeptical as to the need for this change at this time.

Your opinion, not mine.

> Can't we wait
> until we decide to get linux 2.6.x into the book?

2.6 has nothing to do with this upgrade.

> I am still not sure
> if the whole "headers" thing got settled, which also effects Glibc and
> all the rest of the userland packages we install.

In summary, James, I think it wrong for otherwise mostly dormant folks to
pop up out of the blue and cast judgement on matters they clearly have not
been paying attention to. This is open source. Those who do the work get to
make the calls. In this case, it is clear to me that it's a more than
appropriate upgrade. Consider this.. if the Glibc dev's had made a 2.3.3
tarball then folks like yourself probably wouldn't have batted an eyelid!
Ironic isn't it?

[Bill's LFS Login]

On Tue, 13 Jan 2004, Greg Schafer wrote:

> On Mon, Jan 12, 2004 at 01:39:01PM -0600, James Robertson wrote:
> ><snip>

> In summary, James, I think it wrong for otherwise mostly dormant folks to
> pop up out of the blue and cast judgement on matters they clearly have not
> been paying attention to. This is open source. Those who do the work get to
> make the calls. In this case, it is clear to me that it's a more than
> appropriate upgrade. Consider this.. if the Glibc dev's had made a 2.3.3
> tarball then folks like yourself probably wouldn't have batted an eyelid!
> Ironic isn't it?

Dissenting opinion: he was only asking and posing arguments to support
his feelings. I saw nothing "casting judgement".

That said, >:-> he didn't check the archives first - all of us (well, at
least *I*) have probably been guilty of that occasionally. So I think
all of us can forgive this occasional transgression.

--
NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
lfsbillATearthlinkDOTnet
Fix line above & use it to mail me direct.

[James Robertson]

Greg Schafer wrote:
> On Mon, Jan 12, 2004 at 01:39:01PM -0600, James Robertson wrote:
>
>>Please forgive any potential ignorance on this subject, but why do we
>>_want_ to bring upon ourselves the coreutils problem and the need for a
>>non-official tarball release that we have to manage?
>
> James, you need to stay abreast of the issues. If you can't, then you need
> to respect the judegement of those that sre doing so i.e. me :-)

I could take offense to that, but will not. I am simply asking
questions. I have been reading a lot of the emails. I may not
understand all of them, hence the questions.

>
>>I am confused. Is
>>Glibc 2.3.2 not good enough?
>
> No. There are apparent security issues (dunno how serious, but they are
> there).

OK. One good reason.

> There also compiler issues. Glibc-2.3.2 is better matched with
> gcc-3.2.x.

OK, another good reason. We have upgraded to GCC 3.3.x. That matches.
Thank you.

> This is evidenced by the bazillion inlining failed type warnings
> that are not present in 2.3.3. There are numerous other code improvements
> worthy of calling it 2.3.3. Other distros are running much newer Glibc code
> than us. Part of the LFS appeal is that it is up to date. In short, 2.3.2 is
> now so old it ain't funny.

I don't care what the other distros do. We have never followed like
lemmings what the other distros do. Why should we start now? OK, so
Glibc 2.3.2 is considered old. Your reasons above are good ones. LFS
may need to be up to date, but not bleeding edge.

>
>>I know (I think) that 2.3.3 has NPTL in it
>>and 2.3.2 does not, but you only need that if you are running linux
>>2.6.x right?
>
> NPTL has nothing to do with this upgrade.

Ok, thank you. Evidenced above.
>
>>What else is in there that requires us to upgrade and ring
>>trouble on ourselves. We are not a distro and so do not do things like
>>the distros do - rememeber?
>
> Wow, that is an extremely vague and unhelpful comment and almost insulting
> to me.

Not meant to be. This was meant as a catch-all. "What have I missed?"
So, of course, it was vague. The main point was "trouble" if we upgrade
we have to maintain our own tarball and now this coreutils issue.
Again, we are not a distro and do not have full time paid folks to worry
about such things.

>
>>With this coreutils issue coming to light I
>>think it would be prudent to wait until the dust settles some more (even
>>more?).
>
> Huh? This issue has been known about for half a year at least. See my para
> at start of this mail.

But has not been solved, really by the development team. Who cares if
it has been on the table for 6 months. That is irrelevant. The problem
still exists and if we upgrade we still have to deal with it. This is
part of my post.

>
>> I know we want to be on the edge, but some things can wait
>>until they stablize some. Greg, I know you are the resident expert on
>>the toolchain and Glibc is well within your area of control, but I am
>>skeptical as to the need for this change at this time.
>
> Your opinion, not mine.

"Opinions are like assholes. Everyone has one and most of them smell."
- Author Unknown

>
>>Can't we wait
>>until we decide to get linux 2.6.x into the book?
>
> 2.6 has nothing to do with this upgrade.

I see that as part of the NPTL deal. Thanks.

>
>>I am still not sure
>>if the whole "headers" thing got settled, which also effects Glibc and
>>all the rest of the userland packages we install.
>
> In summary, James, I think it wrong for otherwise mostly dormant folks to
> pop up out of the blue and cast judgement on matters they clearly have not
> been paying attention to. This is open source. Those who do the work get to
> make the calls. In this case, it is clear to me that it's a more than
> appropriate upgrade. Consider this.. if the Glibc dev's had made a 2.3.3
> tarball then folks like yourself probably wouldn't have batted an eyelid!
> Ironic isn't it?

OK, so clearly I ruffled a few feathers. I would not call myself
dormant. I have been watching all the threads on the whole Glibc thing.
I am following generally accepted netiquette; don't say anything
unless you need to or have something to add. Lurking is not a crime,
don't make it sound like one! I did not cast a single judgment. I only
asked more questions. I will admit that I failed to review the archives
before I posted my questions (which is also good netiquette). I do
apologize for that oversight.

You only gave three reasons to upgrade - security patches, age of Glibc
2.3.2 and compatibility with GCC 3.3.x. We incur other problems by
doing the upgrade. Namely having to maintain a tarball and the
coreutils issue. This is probably not all the issues relating to the
upgrade. The tarball maintenance is a big shift in our way of handling
things in the past.

In response to your last sentence, there is no irony. You are not a
glibc developer now are you? If the Glibc developers released a 2.3.3
tarball like normal, you are right, one of my issues would be
irrelevant. I was under the impression from your and other posts that
the final decision on the matter was still in the air as it was only one
of the team members pushing for no more tarballs, but the other ones did
not agree (or something close to that). We are making big decisions on
a loosely coupled collection of information spread across a whole slew
of emails. You are probably the only one who completely understands all
of it. No coherrent thread on all the issues has been presented by you
on why we need to upgrade. I could care less what Red Hat and the
others are up to. We are not a distro. Why should we act like one?

Instead of attacking my questions, why not answer them? I was never
attacking your decision nor making judgments. I was just looking for
more info. Getting mad and attacking me is not what I would consider
good form.

Thanks
James

[Greg Schafer]

On Mon, Jan 12, 2004 at 04:34:13PM -0600, James Robertson wrote:
> I don't care what the other distros do. We have never followed like
> lemmings what the other distros do.

This "other distro" thing comes up often. Some folks generalise the point
far too much. The facts of the matter are, if we don't at least see what
the distros are up to then we are not doing our job properly. Otherwise
we're living in a blackhole and run the risk of falling by the wayside.

We generally do something because it is right, not because distro X does
such and such. If distro X does something because it is right then we will
do the same. We don't go out of our way to be unlike distros so I wish folks
would stop quoting this bogus "distro" argument.

> But has not been solved, really by the development team. Who cares if
> it has been on the table for 6 months. That is irrelevant. The problem
> still exists and if we upgrade we still have to deal with it. This is
> part of my post.

Gasp. Clearly still not paying attention. The problem is solved! That's what
the patch is for. It's even recommended by the coreutils maintainers as a
transitionary aid!

> You only gave three reasons to upgrade - security patches, age of Glibc
> 2.3.2 and compatibility with GCC 3.3.x.

This is another bogus argument that gets up my nose. LFS *upgrades* packages
all the time! It's an integral part of LFS! It's part of the LFS ethos! A
new package gets released - we use it! (Within reason - some major things
like 2.6 kernels take time to integrate). Face it, LFS likes to use the
latest released packages where ever possible and has done so for years!. So
again, please stop this bogus "reason to upgrade" argument. If new stuff is
broken then of course we have a reason *not* to upgrade.

> No coherrent thread on all the issues has been presented by you
> on why we need to upgrade.

Ok, now I AM offended. If I wanted to, I could just shut the fuck up and not
say a word on this list. Instead, I often go out of my way and post updates
to keep folks informed and share my knowledge. Why do I even bother? I'd
suggest the lack of coherency is somewhere else.

> Instead of attacking my questions, why not answer them? I was never
> attacking your decision nor making judgments. I was just looking for
> more info. Getting mad and attacking me is not what I would consider
> good form.

Yeah, well, when one puts as much effort into LFS as I do then gets this
sort of crap in return, you should expect it.

[Joel Miller]

On Tue, 13 Jan 2004 10:04:22 +1100, Greg Schafer <***@zip.com.au>
wrote:

> On Mon, Jan 12, 2004 at 04:34:13PM -0600, James Robertson wrote:
>> I don't care what the other distros do. We have never followed like
>> lemmings what the other distros do.
>
> This "other distro" thing comes up often. Some folks generalise the point
> far too much. The facts of the matter are, if we don't at least see what
> the distros are up to then we are not doing our job properly. Otherwise
> we're living in a blackhole and run the risk of falling by the wayside.
>
> We generally do something because it is right, not because distro X does
> such and such. If distro X does something because it is right then we
> will
> do the same. We don't go out of our way to be unlike distros so I wish
> folks
> would stop quoting this bogus "distro" argument.
>

+1 to that. As one of my teachers used to tell me "Developemnt does not
happen in a vacuum."

<snip>
--
Registered LFS User 6929
Registered Linux User 298182

[Dennis J Perkins]

> On Mon, Jan 12, 2004 at 04:34:13PM -0600, James Robertson wrote:
> > I don't care what the other distros do. We have never followed like
> > lemmings what the other distros do.
>
> This "other distro" thing comes up often. Some folks generalise the point
> far too much. The facts of the matter are, if we don't at least see what
> the distros are up to then we are not doing our job properly. Otherwise
> we're living in a blackhole and run the risk of falling by the wayside.
>
> We generally do something because it is right, not because distro X does
> such and such. If distro X does something because it is right then we will
> do the same. We don't go out of our way to be unlike distros so I wish folks
> would stop quoting this bogus "distro" argument.
>
> > But has not been solved, really by the development team. Who cares if
> > it has been on the table for 6 months. That is irrelevant. The problem
> > still exists and if we upgrade we still have to deal with it. This is
> > part of my post.
>
> Gasp. Clearly still not paying attention. The problem is solved! That's what
> the patch is for. It's even recommended by the coreutils maintainers as a
> transitionary aid!
>

My vote is do it.

[unknown]

Steve Martin <***@netcomuk.co.uk> said:
[snip script]

Decent piece of work, but Ryan's script catches a lot more cases, almost
all of them as a matter of fact. Use his instead.

[unknown]

Steve Martin <***@netcomuk.co.uk> said:
> On Tue, 2004-01-13 at 22:34, Zack Winkles wrote:
> > Decent piece of work, but Ryan's script catches a lot more cases,
> > almost all of them as a matter of fact. Use his instead.
>
> Actually I haven't seen Ryan's script; unless you mean his build
> scripts which, again, I do not use. I've been building LFS with my
> own scripts for too long to change them now....Ryans stuff is
> excellent though! ;-)

www.linuxfromscratch.org/~winkie/downloads/posix2fix.sh

Jacked straight from Ryan's scripts, of course.