_AM_FILESYSTEM_TIMESTAMP_RESOLUTION incorrect result (was Re: make check(s) pre-release problems)

[Zack Weinberg]

On Thu, Oct 6, 2022, at 4:19 PM, Zack Weinberg wrote:
> On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote:
>> On 2022-10-04 6:58 PM, Karl Berry wrote:
>>> Perhaps easier to debug: there are two targets to be run before making a
>>> release, check-no-trailing-backslash-in-recipes and check-cc-no-c-o,
>>> to try to ensure no reversion wrt these features. A special shell and
>>> compiler are configured, respectively (shell scripts that check the
>>> behavior).
>>
>> I'm running these targets now and will report what I get.
>
> No errors on RHEL7+autoconf2.71 (same environment I used for the Python fixes)
> from a serial "make check-no-trailing-backslash-in-recipes".  The other one is
> running now.

One failure from a serial "make check-cc-no-c-o":

FAIL: t/aclocal-autoconf-version-check
==

Running from installcheck: no
Test Protocol: none
...
configure: error: newly created file is older than distributed files!
Check your system clock
make: *** [config.status] Error 1

This doesn't appear to have anything to do with "make check-cc-no-c-o" mode, 
the problem is that the filesystem timestamp resolution was incorrectly 
detected:

configure:1965: checking whether sleep supports fractional seconds
configure:1979: result: true
configure:1982: checking the filesystem timestamp resolution
configure:2020: result: 0.1
configure:2024: checking whether build environment is sane
configure:2079: error: newly created file is older than distributed files!
Check your system clock

The filesystem I'm working in only records timestamps at second granularity. (I 
don't know why ls is printing .1 instead of .0 but it's always 
.1.)

$ touch A && sleep 0.1 && touch B && ls --full-time -t A B
-rw-r--r-- 1 zweinber users 0 2022-10-07 11:20:05.1 -0400 A
-rw-r--r-- 1 zweinber users 0 2022-10-07 11:20:05.1 -0400 B

I *think* this is a bug in _AM_FILESYSTEM_TIMESTAMP_RESOLUTION where, if it 
starts looping at *just the wrong time*, the first 0.1-second sleep will 
straddle a second boundary and we'll break out of the loop immediately and 
think we have 0.1-second timestamp resolution.

zw

Re: make check(s) pre-release problems

[Zack Weinberg]

On Thu, Oct 6, 2022, at 4:25 PM, Karl Berry wrote:
> No errors on RHEL7+autoconf2.71
>
> Puzzling. Can you easily try RHEL8 or one of its derivatives?
> It surprises me that that is the culprit, but it seems possible.

Unfortunately, no.  CMU is mostly an Ubuntu shop these days.  It's only dumb 
luck that I happen to have access to a machine that hasn't had a major system 
upgrade since 2012 (and with my day-job hat on I'm actively trying to *get* it 
upgraded -- to Ubuntu.)

zw

Re: make check(s) pre-release problems

[Jim Meyering]

On Thu, Oct 6, 2022 at 1:28 PM Karl Berry  wrote:
>
> No errors on RHEL7+autoconf2.71
>
> Puzzling. Can you easily try RHEL8 or one of its derivatives?
> It surprises me that that is the culprit, but it seems possible.
>
> I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am
> using the OS-provided coreutils. I think I'll try compiling that from
> source.

My problem, at least on F36 was that I'd been using a version of GNU
make I probably built from git around July 11, 2021(!) -- "-v" reports
4.3.90, which is not helpful - I would have preferred to know the
commit.
Once I installed the official 4.3.90, that made it so all of HACKING's
pre-release commands pass for me:
make bootstrap
make -j12 check keep_testdirs=yes
make maintainer-check
make -j12 distcheck# regular distcheck
make -j12 distcheck AM_TESTSUITE_MAKE="make -j$j"  # parallelize makes
make -j12 check-no-trailing-backslash-in-recipes
make -j12 check-cc-no-c-o

FTR, using autoconf (GNU Autoconf) 2.72a.57-8b5e2