On 30/09/2011 00:44, Bruce Dubbs wrote: > The help-version test is doing: > > for i in $built_programs; do > v=$(env $i --version | sed -n '1s/.* //p;q') > break > done > > And failing with 'env: cd: No such file or directory' > > $built_programs is returning: > > cd ..&& /bin/sh ./config.status src/Makefile depfiles config.status: > creating src/Makefile config.status: executing depfiles commands [ > base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit > cut date dd df dir dircolors dirname du echo env expand expr factor > false fmt fold ginstall groups head hostid id join link ln logname ls > md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc od paste pathchk > pinky pr printenv printf ptx pwd readlink rm rmdir runcon seq sha1sum > sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat > stdbuf stty sum sync tac tail tee test timeout touch tr true truncate > tsort tty uname unexpand uniq unlink users vdir wc who whoami yes
Ah yes, that all rings a bell now. It's triggered by the call to 'make NON_ROOT_USERNAME=nobody check-root'. The root cause appears to be the fact that the coreutils build machinery expects automake-1.11a (where is this I wonder, it's not on gnu.org!), and won't regenerate the tests/Makefile from the patched tests/Makefile.am without it. That leads to the automake related rules appearing in the .built_programs file. I've just tested a coreutils-8.13-i18n-2.patch that patches tests/Makefile.in as well as tests/Makefile.am, therefore avoiding the automatic automake calls, resulting in a correctly generated .built-programs file. I'll commit that change tomorrow. Given that you can't reproduce the 3rd test failure, it looks again to be caused by my woefully memory constrained VM environment. That bug may just be fixed by Mrs Claus in a few months though! Thanks, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
