Re: rhel8 test failure confirmation?

[Karl Berry]

    jb> The test also guesses the location of autoconf's Perl libraries; 

I'm skeptical that any "guessing" of library locations would be reliable
enough.

    jb> a more thorough test would locate the autom4te script and grep it
    for the perllibdir that was substituted when autoconf was
    configured.

I guess that would work. A simpler option would be to run
  autom4te --version
and if it's "ge" 2.72, the patch is applied.

Unless there is another pretest with the patch, granted, in which case
there would be need to be some finagling. But dealing with pretest
versions will become irrelevant as soon as the release is made.

Although ordinarily we would not want to test version numbers instead of
features, in this particular case I don't see a problem with it. If, for
instance, RH patches an autoconf with a lesser version and so the check
gives the "wrong" answer, the only result is that the sleep will be
1 sec, as long as it's been in every released automake ever. Hence, not
our problem. RH can patch the test too if they want to.

    bd> [version number comparison] Best, not easy :). 

Comparing version numbers in complete generality is hard. In the
particular case of autom4te, it doesn't seem problematic to me.

    Compare '2.71' to '2.72-beta1-snapshot-12345678' or 
    vice versa with the suffixes :). 

I think ge gives the right answer for our particular question ("is
autom4te patched") until autom4te reaches version 10.  I don't think we
need to protect against that, but if you feel the need to do so, not too
hard.

    it could be possible to make a loop similar to the one 

I was not imagining running the same sort of loop to somehow try to
infer if autom4te is patched. That doesn't sound right. Determining if
autom4te is patched should be as definitive as possible, not just a
heuristic. And I don't think it's any harder to accomplish that.

    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. 

The workaround I think is (by far) the best is: set the sleep to 1 if
autom4te is not patched. That's it. Thus:
  if (<autom4te_is_patched>) then
    <compute fractional sleep as is done now>;
  else
    sleep = 1 second;  # as it always was before
  fi

    Only a matter of where to put it... 

I was imagining at the beginning of _AM_FILESYSTEM_TIMESTAMP_RESOLUTION
in m4/sanity.m4. I.e., when computing the sleep to use.

    an issue with SOME OTHER TOOL.

Automake and autoconf are not two independent tools. Automake completely
relies on autoconf.

It's not for me to hand down any final pronouncements, but personally I
feel strongly that the tests should not paper over this problem by
changing the way tests work in general. With rm -rf of the cache, or
autoconf -f, etc. That is not what users do, so that's not what the
tests should do, either. Such global changes could have all kinds of
other unknown/undesirable effects on the tests.

In contrast to setting the sleep value "as appropriate", which is what
is/should be already done, so changing the conditions under which it is
set is unlikely to cause any unforeseen additional problems.

My $0.02 FWIW. Unfortunately I still have other projects I must attend
to, so can't dig into the actual code any time soon. But you guys are
doing that perfectly well anyway :). --thanks, karl.