[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rhel8 test failure confirmation?
From: |
Bogdan |
Subject: |
Re: rhel8 test failure confirmation? |
Date: |
Fri, 3 Mar 2023 11:21:25 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 |
Karl Berry <karl@freefriends.org>, Wed Mar 01 2023 20:01:26 GMT+0100
(Central European Standard Time)
Does anyone have access to an RHEL 8-based machine? Alma Linux, Rocky Linux,
original RHEL, or even (sort of) CentOS 8? It would be nice if someone
could run a make check there (from automake dev).
git clone -q git://git.savannah.gnu.org/automake.git
cd automake
./bootstrap
./configure && make >&cm.out
make -j8 VERBOSE=1 check keep_testdirs=yes >&ch8.out
(choose whatever -j value you like)
Confirmed here as well (OpenMandriva with Autoconf 2.71). Tested
Automake at the current 'master' and a little older branch.
Even in a pristine environment, on a different physical machines, I find
that a few tests fail, usually taken from the list below. Not always
the same tests fail, but I don't think it's directly related to
parallelism.
It's not. I run tests sequentially and also get failures. Randomly
in time, but always in the same test (and just one).
In the one I've looked into most, t/nodef.sh, it seems to be about disk
writes not taking effect. That test runs the usual autotool sequence
twice, both times writing to the same file named `output' and then
grepping it, e.g.:
grep 'DEFS.*-DVERSION=\\"UnIqUe' output && exit 1
If I put a sleep 1 between the two autotool invocations, it passes. If I
don't, it fails, because the second grep reads the `output' file written
by the first. Or so it seems. Which is crazy.
Certainly looks that way, but for me, it's more like
Autoconf/configure/config.status NOT updating the right files
(config.h in my case).
I could chalk it up to weird (extremely broken) hard disk behavior on
one machine, but not two different machines with completely dissimilar
hardware (including disks). It seems it must be in the os, in my case
Alma Linux:
$ grep ^VERSION= /etc/os-release
VERSION="8.7 (Stone Smilodon)"
(But I'd be very surprised if it is Alma-specific.)
All the tests pass fine on CentOS 7.
This, along with my observation (below), MAY actually point to some
issue with Autoconf. Old systems work, new don't.
Sigh. --thanks, karl.
Approximate lists of tests that "usually" fail:
FAIL: t/backcompat2.sh
FAIL: t/backcompat3.sh
FAIL: t/get-sysconf.sh
FAIL: t/lex-depend.sh
FAIL: t/nodef.sh
FAIL: t/remake-aclocal-version-mismatch.sh
FAIL: t/subdir-add2-pr46.sh
FAIL: t/testsuite-summary-reference-log.sh
When I run
make check TESTS='t/nodef.sh t/backcompat2.sh t/backcompat3.sh
t/get-sysconf.sh t/lex-depend.sh t/remake-aclocal-version-mismatch.sh
t/subdir-add2-pr46.sh t/testsuite-summary-reference-log.sh'
I get failures in t/backcompat2.sh. Sometimes, like once-twice in
ten runs.
I've added a simple 'debug' in the form of the 'stat' command and:
--------------
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating config.h
config.status: config.h is unchanged
+ cat config.h
/* config.h. Generated from config.h.in by configure. */
/* #undef PACKAGE */
/* #undef VERSION */
+ LC_ALL=C
+ stat ./configure
File: ./configure
Size: 106382 Blocks: 208 IO Block: 4096 regular file
Device: 8,6 Inode: 6328331 Links: 1
Access: (0700/-rwx------) Uid: ( 1000/ bogdan) Gid: ( 1006/ bogdan)
Access: 2023-03-02 21:42:36.138654005 +0100
Modify: 2023-03-02 21:42:36.251653430 +0100
Change: 2023-03-02 21:42:36.252653424 +0100
Birth: 2023-03-02 21:42:36.138654005 +0100
+ LC_ALL=C
+ stat config.h
File: config.h
Size: 101 Blocks: 8 IO Block: 4096 regular file
Device: 8,6 Inode: 6328337 Links: 1
Access: (0600/-rw-------) Uid: ( 1000/ bogdan) Gid: ( 1006/ bogdan)
Access: 2023-03-02 21:42:32.677671613 +0100
Modify: 2023-03-02 21:42:32.683671582 +0100
Change: 2023-03-02 21:42:32.693671531 +0100
Birth: 2023-03-02 21:42:32.677671613 +0100
+ grep '^ *# *define *PACKAGE *"pkgname" *$' config.h
+ am_exit_trap 1
--------------
Note that 'config.h' is older (4 seconds) than './configure', which
shouldn't be the case as it should get updated with new values.
What's funny, when I run just the failing test alone, it works 10
times in a row. A "Schroedinger bug" - when you try to observe, you
change the environment and the bug disappears :).
I'll try to do some more digging later.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux): http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org