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

Erik-Jan ej.lfs at
Tue Apr 22 16:03:25 PDT 2003

Ryan.Oliver at wrote:
> Bill Maltby wrote:
> > Although set +h has no nasty effect if we run the script
> > Anyway, I've added set +h into my local copy so if I do this again, I
> > won't get shafted by this.
> It **SHOULD** go into the init script...
Phew, luckily i did set it in my scripts... :))

> Firstly the new scripts (which BTW will be 2.3.0, version info is being
> split from the init script) create a temporary plfstest user (group users,
> also added to temporary group plfstest) with no home directory ( -M in
> useradd, same as erik's, but so far has no check to see if the user already
> exists or not )


> What it seems we need to rectify is (for everybody)
> a) the permissions issue for non-root user running tests.
>    I haven't had an issue but it seems you and erik have, so it needs
> fixing.
>    a chmod -R o+wx tests would do it... (IIRC that had to be done anyway
>    on earlier versions of coreutils)

I will start a new build tonight... 

> b) proper evaluation of the non-root user having a valid shell during the
See my answer to your own answer to this mail: find a user with a valid
shell, but run the rm-test with --shell=/bin/sh

> c) <snip>  The CANDIDATE_TMP_DIRS stuff <snip>
What I've done (but it's also a bit hackey, and I'm not too sure about
it, I incidentally removed my logs, will check later): export
CANDIDATE_PARTITION = /dev/hda7 in build-init. Then after cd-ing in the
mkdir temp &&
chown plfstest:plfstest temp &&
export CANDIDATE_TMP_DIRS=`pwd`/temp

It should test if $CANDIDATE_PARTITION is set...

> Anyway, discussion is open on this one, ideas people?
> Regards
> Ryan

I'm firing up a new build in a few moments, so tomorrow I'll have some

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

More information about the lfs-dev mailing list