datefudge: 64-bit time_t support on 32-bit archs

Affected images versions

• not relevant, as we are still in the phase of rebase to Bookworm and this issue is specific to a package on particular architecture types

Steps to Reproduce

tests for datefudge consistently fail in:

[   73s]    dh_auto_test
[   73s] 	make -j3 test
[   73s] make[1]: Entering directory '/usr/src/packages/BUILD'
[   73s] Running a simple date test... failed: expected: 1970-01-02.12:15:00, actual: 2023-05-29.12:15:00
[   75s]    retrying... failed: expected: 1970-01-02.12:15:00, actual: 2023-05-29.12:15:00
[   75s] Running a simple perl localtime() test... OK
[   75s] make[1]: *** [Makefile:47: test] Error 1
[   75s] make[1]: Leaving directory '/usr/src/packages/BUILD'
[   75s] dh_auto_test: error: make -j3 test returned exit code 2
[   75s] make: *** [debian/rules:16: binary] Error 25

Expected result

Testsuite should pass

Actual result

Testsuite fails on 32 bit systems. As far as I can tell, the reason is that coreutils now uses a 64-bit time_t and functions with a "64" suffix. Datefudge however does not expose nor implement such functions.

Reproducibility

How often the issue is hit when repeating the test and changing nothing (same device, same image, etc.)?

Put the ✅ in the most appropriate entry:

1. ✅ always
2. often, but not always
3. rarely

Impact of bug

This is a time faking library, possibly in use by other packages. It may be used by other packages, that want to fudge the date without touching the system date.

Attachments

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028587
• https://github.com/wolfcw/libfaketime/issues/418

Root cause

During the rebase to Bookworm, it is seen that package datefudge fails to build from source on 32 bit systems, like arm32.

Outcomes

TBD

Management data

This section is for management only, it should be the last one in the description.

/cc @andrunko @em @sagar @sudarshan @wlozano

Phabricator link: https://phabricator.apertis.org/T9746