Re: rhel8 test failure confirmation?

Jacob Bachmeyer <[email protected]>, Mon Apr 03 2023 06:16:53 
GMT+0200 (Central European Summer Time)
> Karl Berry wrote:
>> [...]
>>    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.
> 
> If you can locate Autom4te::FileUtils, grepping it for "Time::HiRes" 
> will tell you if autom4te supports sub-second timestamps, but then you 
> need more checks to validate that the filesystem actually has 
> sub-second timestamps.
> 
> A simple check:
> 
> if $PERL -I${autom4te_perllibdir:-/usr/share/autoconf} 
> -I/usr/local/share/autoconf \
>         -MAutom4te::FileUtils -e 'exit defined $INC{q[Time/HiRes.pm]} 
> ? 0 : 1'; then
>     # autom4te uses Time::HiRes
> else
>     # autom4te does not use Time::HiRes
> fi
> 
> This method also has the advantage of implicitly also checking that 
> $PERL has Time::HiRes installed by determining if loading 
> Autom4te::FileUtils causes Time::HiRes to be loaded.  (In other words, 
> this will give the correct answer on Perl 5.6 if Time::HiRes was 
> installed from CPAN or on later Perls if a distribution packager has 
> unbundled Time::HiRes and the user has not installed its package.)


  Nice. The 0 and 1 may not be portable to each OS in the Universe 
(see EXIT_SUCCESS and EXIT_FAILURE in exit(3)), but should be 
good/portable enough for our goals. Or maybe some other simple solution.

  As I understand, this could even be used to actually call the sub 
which checks the timestamps, so we'd have a read-to-use test. Only a 
matter of where to put it... Is there some code that runs *before* all 
tests that could set some environment variable passed to the tests, 
create a file, or whatever?



>> [...]
>> 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.
> 
> The Automake testsuite is supposed to test Automake, not Autoconf, so 
> working around Autoconf issues is appropriate.


  I agree with this one, too. Don't do workarounds in tests to fix 
Automake issues, just fix the issue in Automake :). But workarounds, 
conditional code, skipping tests, etc. are allowed when using other 
tools in Automake tests.


>  In this case, if 
> always using "autoconf -f" allows us to eliminate the sleeps entirely 
> (and does not expand the running time of Autoconf too much), we should 
> do that, at least in my view.


  Yes, that could be the simplest. I (or someone) just need to find 
out how to time individual tests (or maybe I'll just run 'time make 
check TESTS=...') and do the actual measurements :).
  I was hoping to have more time for this, but unfortunately, I got 
busy with other things and this may have to wait a bit. Maybe this 
week, maybe the next...


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