PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))

Ryan.Oliver at pha.com.au Ryan.Oliver at pha.com.au
Tue Apr 22 16:52:26 PDT 2003


Greetings all,

Erik-Jan wrote:
> 3) sending the bash-error in the valid-shell test to /dev/null like
> this:
>     retname=`su -c 'id -un' $name 2>/dev/null`

Ooops ;-) didn't count on that

>     and doing the rm-test with --shell=/bin/sh, because then you know for
> sure how the shell behaves.

Hmmm except on most linux systems /bin/sh is a symlink to bash, unless I'm
missing something...

> >
> > Of course wont work on solaris unless you use /usr/xpg4/bin/id.
> > The coreutils guys would have to sort that one out ;-) (shouldn't be
too
> > hard)
> >
> I don't know much about solaris, but the su and id-commands are all in
> the coreutils, and the newly built commands are being used in the tests
> (try echo `su --version` or echo `su -c 'id --version' $name` inside the
> loop, it should give coreutils5.0) so maybe it just goes ok.

Here's hoping... ;-) but I am not game to build it on a host here ;-)

Bill Maltby wrote:
> 4) *If* my tests (in an admittedly uncertain environment at the time)
> are any indication, rearranging the su statement will also suppress the
> reading of the /root/.bashrc. I'll know for sure late tonight when my
> new test with a known-good environment. The sed that modifies
> fail-2eperm in the junk I sent earlier implements this and did work in
> the environment at that time.

I'll have to take a look at it, I'm not voting for anything yet till I see
how you guys go ;-)

> BTW, I would have done a patch, but RO has expressed a preference for
> sed, so that's what I did.

Ok, I better state my position on the seds vs patches.
If the fix applies to all versions of a package (or a large proportion) I
prefer seds to go into the script, but do supply a patch for the source for
the list (not everyone uses the scripts ;-) my last build I did by hand,
see below)

If the fix is only a bugfix for a single release of the package which is
going to be fixed upstream a patch is generally better.

Either way a patch is always good (plus we can get everyone else testing
it).

/me thinks we'll need a 2.2.9 release of the scripts ( ie: patches against
the current ones ) whenever we decide which way we are going.

On a side note, managed to get a 2.5.66 kernel booted on a cvs glibc (w
NPTL)with cvs gcc 3.3 (both from 20030404) from a redhat 6.1 system ( don't
ask, it was the only CD I could find ;-/ )
You don't want to use the scripts for this, basically you have to pretty
much rebuild all the host system tools (gcc, make, bison, flex, automake,
autoconf, bash, grep, sed and awk ) and swap out your kernel and module
handlers before you even begin.
Even then glibc couldn't determine the size of a long double (hack slash
configure script to return 12)

After I have gone through all of this I find Zach's hint this morning
(DOH!).
Mate, did you post that you were doing that to the list? :-) Wish I had
seen it if you did ;-)

Anyhoo, back to Slowlaris land
Regards
Ryan


-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list