bug#14528: remake-configure-dependencies test fails on fast systems without subsecond timestamps

[Stefano Lattarini]

tags 14528 + patch
severity 14528 minor.
stop

Hi Colin, thanks for the report

On 06/01/2013 01:20 PM, Colin Watson wrote:
> Automake 1.13.2 failed t/remake-configure-dependencies.sh in two
> consecutive attempts on Ubuntu autobuilders.  On inspection I found that
> our autobuilder network happened to pick the same backend machine each
> time, which was a relatively old one still using ext3.  (Our newer
> builders use ext4.)  On running this test in a loop-mounted ext3
> filesystem on my laptop, I reproduced the failure first time:
> 
>   Running from installcheck: no
>   Test Protocol: none
>   PATH = 
> /home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2/t/wrap:/home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2/t/ax:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
>   ++ pwd
>   
> /home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2/t/remake-configure-dependencies.dir
>   + cat
>   + cat
>   + cat
>   + echo '#!/bin/sh'
>   + echo 'printf %s 1.0'
>   + chmod a+x print-version
>   + aclocal-1.13 -Werror
>   + autoconf
>   + automake-1.13 --foreign -Werror -Wall
>   + ./configure
>   checking for a BSD-compatible install... /usr/bin/install -c
>   checking whether build environment is sane... yes
>   checking for a thread-safe mkdir -p... /bin/mkdir -p
>   checking for gawk... no
>   checking for mawk... mawk
>   checking whether make sets $(MAKE)... yes
>   checking whether make supports nested variables... yes
>   checking that generated files are newer than configure... done
>   configure: creating ./config.status
>   config.status: creating Makefile
>   + make test-1
>   test 1.0 = 1.0
>   + echo '#!/bin/sh'
>   + echo 'printf %s 2.1'
>   + using_gmake
>   + case $am__using_gmake in
>   + make --version -v
>   + grep GNU
>   GNU Make 3.81
>   + am__using_gmake=yes
>   + return 0
>   + make test-2
>    cd . && /bin/bash 
> /home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2/t/remake-configure-dependencies.dir/missing
>  automake-1.13 --foreign
>   CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash 
> /home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2/t/remake-configure-dependencies.dir/missing
>  autoconf
>   test 1.0 = 2.1
>   make: *** [test-2] Error 1
>   + am_exit_trap 2
>   + exit_status=2
>   + set +e
>   + cd /home/cjwatson/src/ubuntu/automake1.13/tmp/t/automake1.13-1.13.2
>   + test none = tap
>   + case $am_explicit_skips in
>   + test 2 -eq 0
>   + keep_testdirs=yes
>   + am_keeping_testdirs
>   + case $keep_testdirs in
>   + return 0
>   + set +x
>   remake-configure-dependencies: exit 2
> 
> I think perhaps a sprinkling of $sleep is called for in this test?
>
You are perfectly right.  I thought the sleeps implicit in configure
invocations were enough to avoid this kind of issues, but after a more
careful consideration I realized I was mistaken (see commit message in
the patch below for an extended rationale).

Can you confirm the patch works for you?

Thanks,
  Stefano

---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ----

>From b4eefc79759fcb2c5941a65759d242488af8ed1a Mon Sep 17 00:00:00 2001
Message-Id: <address@hidden>
From: Stefano Lattarini <address@hidden>
Date: Mon, 3 Jun 2013 11:27:49 +0200
Subject: [PATCH] tests: fix spurious failure due to missing sleeps

Fixes automake bug#14528.

* THANKS: Give credit to that bug's original reporter.

* t/remake-configure-dependencies.sh: Add few missing '$sleep'
invocations.  I thought that the sleeps implicit in the configure
invocation were enough, but they were not, actually.  Here is what
can happen:

  1. The config.status script is generated by a configure run.
  2. ./config.status and make are run.
  3. The 'print-version' script is modified.
  4. Since that script is listed in $(CONFIGURE_DEPENDENCIES),
     autoconf is re-run.
  5. On a fast-enough machine, the three steps 2-4 above, even
     combined, might have taken less than a second to run;
  6. If the filesystem doesn't have a sub-second timestamp
     resolution, that means the newly-generated configure has
     the same timestamp of the old config.status;
  7. So, config.status is not re-run, and the Makefiles are
     not updated.
  8. Spurious failure!

So we really need more explicit sleeps.

Signed-off-by: Stefano Lattarini <address@hidden>
---
 THANKS                             | 1 +
 t/remake-configure-dependencies.sh | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/THANKS b/THANKS
index dbcb1ab..c5c7c49 100644
--- a/THANKS
+++ b/THANKS
@@ -67,6 +67,7 @@ Christian Cornelssen            address@hidden
 Christina Gratorp               address@hidden
 Claudio Fontana                 address@hidden
 Clifford Wolf                   address@hidden
+Colin Watson                    address@hidden
 Dagobert Michelsen              address@hidden
 Daiki Ueno                      address@hidden
 Dalibor Topic                   address@hidden
diff --git a/t/remake-configure-dependencies.sh 
b/t/remake-configure-dependencies.sh
index 2e5df88..d81d881 100644
--- a/t/remake-configure-dependencies.sh
+++ b/t/remake-configure-dependencies.sh
@@ -61,6 +61,7 @@ $AUTOMAKE
 ./configure
 $MAKE test-1

+$sleep
 (echo '#!/bin/sh' && echo 'printf %s 2.1') > print-version
 using_gmake || $MAKE Makefile
 $MAKE test-2
@@ -70,6 +71,8 @@ mkdir build
 cd build
 ../configure
 $MAKE test-2
+
+$sleep
 (echo '#!/bin/sh' && echo 'printf %s 3.14') > ../print-version
 using_gmake || $MAKE Makefile
 $MAKE test-3
-- 
1.8.3.rc3.8.g5e49f30