PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))
ej.lfs at xs4all.nl
Tue Apr 22 16:03:25 PDT 2003
Ryan.Oliver at pha.com.au 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
> 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 &&
mount $CANDIDATE_PARTITION temp &&
It should test if $CANDIDATE_PARTITION is set...
> Anyway, discussion is open on this one, ideas people?
I'm firing up a new build in a few moments, so tomorrow I'll have some
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