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.