Re: rhel8 test failure confirmation?

[Bogdan]

Karl Berry <karl@freefriends.org>, Mon Apr 03 2023 02:08:23 GMT+0200 
(Central European Summer Time)
>      I modified my autom4te using the attached patch,
>
> Thank you very very much for finding this, Bogdan.


 :) Hope it saved some headaches :)


> I'm glad that Paul has already installed it in Autoconf.
> I can't easily confirm it for myself right now, but I'm hopeful.
> (Maybe Frederic or others can try with the development autoconf.)
>
>     What can we do about this?
>
> As for automake: can we (you :) somehow modify the computation of the
> sleep value to determine if autom4te can handle the HiRes testing or not
> (i.e., has the patch installed)? And then use the longer sleep in
> automake testing if needed.


 Perhaps. If not possible to call the autom4te's routine/module 
directly, it could be possible to make a loop similar to the one 
already in place (the filesystem timestamp resolution). But this loop 
would require calling autom4te the number of times needed to establish 
the result, which could make just this testing longer than the gain...


> In fact, I wonder about autom4te providing an explicit way to test
> whether it's been patched, because I suspect that a functionality test
> (run autom4te a bunch of times on a bunch of newly-created files) would
> be highly susceptible to wrong results. Checking the autom4te
> --version number might be the easiest and best thing to do.


 Until autoconf/autom4te has a '--has=some-feature-name' option, 
checking the version number would probably be the best, as you say. 
Best, not easy :). Compare '2.71' to '2.72-beta1-snapshot-12345678' or 
vice versa with the suffixes :). Some nice Perl one-liner should do 
the trick.


> I think it's pretty crucial that the automake (or autoconf) tests not
> spuriously fail due to filesystem timing, even for people that have the
> "old" (unpatched) autom4te. People will certainly keep using current and
> older releases of autoconf for years to come.


 I agree, so it would be best to have a workaround or a plan "B" for 
those unpatched, for some reasonable time, at least. What would the 
plan be is the question. Force '-f'? Run an initial pre-test for 
autom4te and generate the $AUTOCONF variable? Run an initial pre-test 
for autom4te and force the timeout in the tests (like set an 
environment variable, check for that in the sanity test and assume 1 
second sleep if present)?
 But, fortunately, these are still "just tests".


> It seems to me that using autoconf -f or similar is papering over the
> problem, so that the tests are no longer testing the normal behavior.
> Which does not sound desirable.
>
> Wdyt? --thanks again, karl.


 On one hand - yes, you're right. On the other - we're working around 
an issue with SOME OTHER TOOL. Just like #ifdef/#endif with C 
compilers, Perl's 'eval' at runtime, or whatever.

 I think we're allowed to do whatever workaround we find suitable to 
make Automake work or make its tests pass. Obviously, it would be best 
if autoconf/autom4te we patched (preferably from the beginning), but 
if we can't have everything else perfect, we do our best, including 
the old 'sleep 1' in the sanity test (and probably other things).

 Bogdan

P.S. Sorry for not replying earlier. I wanted to come back with some 
results, but apparently, it will take a bit more time.


--
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