Testsuite suddenly failing with different timestamps

[bernhardschmidt]

A bug was reported against 1.7.4 in Debian (reproduced with 1.7.5) that the testsuite is suddenly failing. The testsuite is run on every build, it did not fail when I initially uploaded to Debian on July 12th.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086366

make[5]: Entering directory '/<<PKGBUILDDIR>>/src/test'
PASS: nftest
FAIL: runprepare.sh
PASS: runlzo.sh
PASS: runlz4.sh
PASS: runbz2.sh
PASS: runzstd.sh
FAIL: runtest.sh
===========================================
   nfdump 1.7.5: src/test/test-suite.log
===========================================

# TOTAL: 7
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: runprepare.sh
===================

File       : dummy_flows.nf
Size       : 5365
Version    : 2 - not compressed
Created    : 2024-11-05 21:07:03
Created by : unknown
nfdump     : f1070400
encryption : no
Appdx blks : 1
Data blks  : 1
Checking data blocks
 |
Checking appendix blocks

Total
Type 3 blocks : 2
Records       : 37
--- test.1.out  2024-11-05 21:07:03.755410518 +0000
+++ nftest.1.out        2024-10-23 17:57:56.000000000 +0000
@@ -25,9 +25,9 @@
   engine type  =                  2
   engine ID    =                  3
   export sysid =                  3
-  first        =      1562841000235 [2019-07-11 10:30:00.235]
-  last         =      1562841002234 [2019-07-11 10:30:02.234]
-  received at  =      1562841000001 [2019-07-11 10:30:00.001]
+  first        =      1562833800235 [2019-07-11 10:30:00.235]
+  last         =      1562833802234 [2019-07-11 10:30:02.234]
+  received at  =      1562833800001 [2019-07-11 10:30:00.001]
   proto        =                  6 TCP
   tcp flags    =               0x02 ......S.
   src port     =              12345
@@ -45,9 +45,9 @@

And so on. Basically all unix timestamps are 7200 seconds = two hours off, while the clock output is the same.

It could be a DST issue in the testsuite, incidentally all uploads in the recent years happened during CEST. However, it does not fail in testing, so it could be a recent toolchain change in unstable.

[bernhardschmidt]

Further investigation shows that this is most likely caused by a change in tzdata 2024b

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084190

   * Upstream obsoleted the System V names CET, CST6CDT, EET, EST*, HST, MET,
     MST*, PST8PDT, and WET. They are symlinks now. Move those zones to
     tzdata-legacy and update /etc/localtime on package update to the new names.
     Please use Etc/GMT* in case you want to avoid DST changes.

Build-Depending on tzdata-legacy fixes the testsuite for now.

[phaag]

Hmm .. nfdump does not set any timezone. Maybe it should do this for the test only. Does it make a difference, if the TZ is set in runtest.sh?

export TZ=Europe/Zurich

[bernhardschmidt]

Hmm .. nfdump does not set any timezone. Maybe it should do this for the test only. Does it make a difference, if the TZ is set in runtest.sh?

The tests do set it to a deprecated one.

https://github.com/phaag/nfdump/blob/79f8637f5c07fedf6a9b217b7cf9dd90660a06cf/src/test/runprepare.sh#L33 https://github.com/phaag/nfdump/blob/79f8637f5c07fedf6a9b217b7cf9dd90660a06cf/src/test/runtest.sh#L33

The other test scripts set it as well, but replacing those two incarnations of TZ=MET with TZ=Europe/Zurich fixes the issue.

Bernhard