On Fri, 2020-06-19 at 16:26 +0100, Ken Moffat via lfs-dev wrote:
> I've now been through my test logs for the new build (on my i7
> haswell).
>
> Here are a few comments (in order of testing)
>
> glibc-2.31.0
> ------------
>
> We say "misc/tst-ttyname is known to fail in the LFS chroot
> environment." But for me it was skipped (I'm running a 5.7.2
> kernel, with 5.7.2 headers and 5.7 iproute2).
>
> But my log says
> 5102 PASS
> 44 UNSUPPORTED
> 16 XFAIL
> 2 XPASS
>
> And misc/tst-ttyname is now among the unsupported -
> UNSUPPORTED: misc/tst-ttyname
I have quite different results (was with 5.6.15 kernel and headers, and
iproute2-5.6):
1 FAIL
5177 PASS
22 UNSUPPORTED
17 XFAIL
2 XPASS
with
FAIL: misc/tst-ttyname
I cannot tell why it has run more tests for me than for you (I mean the
22 less UNSUPPORTED cannot explain the 75 more PASS)
Note that in a VM with an old debian 8 system (kernel 3.16), I have 24
UNSUPPORTED and 5175 PASS, otherwise identical.
>
> I'm also now wondering about the comment on the rt/tst-cputimer
> tests. I don't have any systems running kernels older than 5.4, but
> the detail suggests that "mid-period" 4.14 and 4.19 stable kernels,
> as well as some or all of 4.20, failed here. Could we not just say
> that some kernels before linux-5.0 cause these tests to fail ?
Don't remember, so I trust you. This test passed on the 3.16 debian
kernel, though. But some fixes may have been backported.
>
> gcc-10.1.0
> ----------
>
> I seem to be getting rather more failures than the book implies,
> although I don't think they are either serious or unexpected.
>
> First, 14 failures i nthe torture test, variants of
> FAIL: gcc.c-torture/compile/limits-exprparen.c
Isn't it the one that fails when ulimit is not increased?
>
> Second, as wel las the 6 locale/get_time test failures I also had
> FAIL: 20_util/unsynchronized_pool_resource/allocate.cc execution test
> FAIL: 22_locale/numpunct/members/char/3.cc execution test
Never seen those ones
Most often, I have only the 6 22_locale/get_time failures on the
Haswell or 64 bit VM's.
On the i686 VM, I had 13 errors for libstdc++, but not the same as the
ones you report.
>
> bison-3.6.3
> -----------
>
> Here, I strongly disagree that the tests need to be run with -j1.
>
> On my i3 Skylake last December I had to use -j1 to get the package
> to compile, and therefore I also used -j1 on that machine if I ran
> the tests. But on other machines I'm using -j8 both for the compile
> and for the tests (and no failures).
Could be changed I guess
>
> python-3.8.3
> ------------
>
> "The test named test_normalization fails because network
> configuration is not completed yet." I assume that the work on
> /etc/hosts has solved this, I have:
>
> 0:01:42 load avg: 6.94 [369/423] test_normalization passed --
> running: test_concurrent_futures (1 min 38 sec),
> test_multiprocessing_spawn (1 min 33 sec)
>
> and at the end it reported SUCCESS before listing the skipped tests.
>
Not run those since the book tells not to run them
> acl-2.2.53 (tested after coreutils)
> ----------
>
> In the past I'd assumed that the two failures I was seeing
> [test/root/permissions.test and test/root/setfacl.test ] were because
> I didn't use ACLs (although ext4 supports them), but that was
> probably a mistaken assumption. Anyway, now I don't have any
> failures in acl.
Not run either
>
> util-linux-2.35.2
> -----------------
>
> I have to admit that this is my first build with this version, I'd
> managed to miss the change to it. I see that we use 'make -k check'
> in the expectation that things may fail. And I do get one failure:
>
> FAILED (column/invalid-multibyte)
>
> ISTR that has happened in the past, and I had the impression that
> the cross- changes had fixed it, but maybe I'm mistaken.
For me they now all pass (on all my machines). Note that I do not use
any special CFLAGS. Those are all jhalfs builds. The cpu is exactly the
same as yours.
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
