The test hang issue is not related to partial environment. It's just a
known issue (for eg https://github.com/python/cpython/issues/91155) and
happens when we are unlucky.
So just run the test suite with a timeout. 1 SBU should be enough: it's
approximately 4 times of the time used by the slowest test case, on both
an old Athlon 64 3000+ and a Core i5-11300H.
I've not seen any test failure on a complete system (the expat-related
failure seems fixed by expat-2.6.2 or 2.6.1). TODO: really test this
with LFS chroot and document failures if any.
Update to iana-etc-20240318.
Update to zstd-1.5.6.
Update to util-linux-2.40.
Update to shadow-4.15.1.
Update to pkgconf-2.2.0.
Update to linux-6.8.2.
Update to coreutils-9.5.
Vladimir has reported that the link target of this <ulink> is wrong.
Note that the link target and the displayed text should be the same,
thus use <ulink ... /> instead of <ulink ...> ... </ulink> to simplify
it.
Update to wheel-0.43.0.
Update to setuptools-69.2.0 (Python module).
Update to meson-1.4.0.
Update to expat-2.6.2 (Security fix).
Update to iana-etc-20240305.
Update to vim-9.1.0161.
Update to xz-5.6.1.
Update to shadow-4.15.0.
Update to psmisc-23.7.
Update to kmod-32.
Update to elfutils-0.191.
Update to iana-etc-20240222.
Update to vim-9.1.0145.
Update to xz-5.6.0.
Update to tcl-8.6.14.
Update to shadow-4.14.6.
Update to setuptools-69.1.1.
Update to linux-6.7.7.
Update to libffi-3.4.6.
Update to gettext-0.22.5.
Update to expat-2.6.1.
The incompatibilty between systemd and CONFIG_AUDIT has been fixed since
Linux kernel 3.14, thus there is no reason to disable it on LFS. And we
are referring to pam_loginuid.so from /etc/pam.d in BLFS, which is
completely useless if CONFIG_AUDIT is disabled.
Link: https://github.com/systemd/systemd/commit/db999e0f923c
So if a test times out, it will be noted in jhalfs log.
Also remove "-l" so the output will be something like
./nptl/tst-thread-affinity-pthread: Timed out ...
instead of just a puzzling "./nptl/tst-thread-affinity-pthread".
As we've already concluded, overwriting a shared object can crash
running processes using code or data from this shared object. For
example if gdm is crashed, we may leave the system unusable :(.
I spent some time investigating the difference of vim test results from
different editors. It turns out the value of TERM can affect the test
results in a deterministic way: when TERM=xterm-256color all tests pass,
when TERM=linux one test fails, and when TERM=vt100 20+ tests fail.
As we are redirecting the output to a file, the actual type of the
terminal does not matter and we can just specify a value known to work.
