I have two comments regarding point 1 (FreeBSD issues):
1. "tput setaf ..." returns with exit code 1 on FreeBSD. Combined with
"set -e" in bin/tests/system/cds/setup.sh, this causes cds test
setup to be silently interrupted when bin/tests/system/conf.sh is
sourced. However, note that the Jenkins FreeBSD slave seems to have
no problems with running the cds test. I logged into the slave, ran
"tput setaf 1" and it returned with exit code 1, just like the VM I
checked earlier. I have no idea what is happening here. I think we
should drop "set -e" from bin/tests/system/cds/setup.sh as it does
not seem to be widely used in bin/tests/system:
$ git grep "set -e" bin/tests/system/
bin/tests/system/cds/setup.sh:set -eu
bin/tests/system/rpz/ckdnsrps.sh:set -e
bin/tests/system/rpz/setup.sh:set -e
bin/tests/system/rpzrecurse/setup.sh:set -e
Nevertheless, fixing bin/tests/system/conf.sh also would not hurt.
2. The cds test is overly optimistic about execution times. The
checkmtime.pl script expects it will not take more than 2 seconds to
set the test up and run the first 14 checks. This might be a
reasonable assumption on a modern physical machine; my laptop
usually runs the whole cds test in under a second. However, our
FreeBSD VM is a lot slower, usually taking about 6 seconds to run
the whole cds test. Not to mention our SPARC machine with Solaris
10, which consistently takes about 30 seconds (!) to complete the
test.
Given the timestamps used as input for the relevant checks (there
are three of them and each one is an hour apart from the next), I
think there is no harm in reducing the resolution of these checks to
a minute, e.g. like this:
diff --git a/bin/tests/system/cds/checkmtime.pl b/bin/tests/system/cds/checkmtime.pl
index ea3fa5d27a..3a1347f7be 100644
--- a/bin/tests/system/cds/checkmtime.pl
+++ b/bin/tests/system/cds/checkmtime.pl
@@ -10,4 +10,4 @@ my $target = shift;
my $file = shift;
my $mtime = time - (stat $file)[9];
die "bad mtime $mtime"
- unless abs($mtime - $target) < 3;
+ unless ($mtime - $target >= 0 && $mtime - $target < 60);
This will ensure the test passes even on extreme laggards without
making it moot. If this looks good to you, we should merge the above
change with no CHANGES note to make Jenkins happy again.
As a side note, checkmtime.pl currently uses abs(), which allows the
test to pass when file modification time is *less* than an hour (or
two hours for the second check) in the past. I do not think this
should ever be possible and thus I removed abs() from the condition
checked by checkmtime.pl.