Dear Maintainer,

When updating coreutils to version 9.1 in Ubuntu, we noticed that
datefudge autopkgtests started failing on armhf.

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.

The error probably only appears on armhf because other Ubuntu
architectures are 64-bit.

I think the latest coreutils version in Debian should trigger the same
issue. Reproducing is fairly easy. Get and extract the corresponding deb
and run something like the following (taken from the package tests):

  a='2019-07-31 23:01:12'; datefudge -s "$a" $(pwd)/bin/date '+%F %T'

Best,

Hi Maintainer and i386, arm, mips porters

As can be seen on reproducible builds [1], datefudge now FTBFS on at
least i386 and armhf, and I was able to confirm the failure on the
mipsel porterbox.

As datefudge is a build-dependency of gnutls28 and oath-toolkit, both
key packages, how should this be resolved?

Regards
Graham


[1] https://tests.reproducible-builds.org/debian/rb-pkg/datefudge.html

Hi,

Considering datefudge has seen little development for the past decade,
maybe we should try to move to libfaketime[1] instead which is being
actively maintained. I don't really feel like doing the work for 64-bit
time_t on 32 bit and making sure the ABI is actually fine; that sounds
like a good way to self-inflict annoying bugs. Porting whatever needs
faked time to libfaketime shouldn't be too much work and should be more
future-proof.

As far as I can see, libfaketime doesn't have an equivalent to
datefudge's -s (static time) but I'm not sure if it's really needed in
practice and if it is, I'm confident we can add it to libfaketime.

[1] https://github.com/wolfcw/libfaketime

Best,

[ Author of datefudge here ]

I assume that datefudge is used to support reproducible builds; in that
case it most likely *is* necessary to use the '-s' option, as build
times are not going to be constant.

I do recommend switching to a supported library. I'm sorry to say that
my time budget already is negative for the foreseeable future, thus
resuming support for datefudge is out of the question unfortunately.

I'd start by asking how many implementations of this functionality we
ship, and whether all of them have the same problem.

faketime has more users and an upstream, but the same problem.

Adding the missing functionality to one implementation (faketime?)
and ensuring there are RC bugs against all other implementations
(are there other ones apart from datefudge?) would be my suggestion.

Users of unfixed implementations could then migrated to fixed ones.

cu
Adrian

I was wondering why my answer wasn't showing up in the web interface.
Well, I replied only to Matthias. I'm re-sending here with a some
additional infos. Apologies for the duplication. :)

First thing is that I was wrong: faketime exhibits the same issue. This
isn't a big surprise. I've also looked at Fedora, Opensuse and Arch
Linux; it seems none of them have patches for this class of issue.

For the record, two packages use datefudge and around thirty use
faketime, mostly for tests and for making documentation reproducible.
Only three use faketime at runtime: debrepro.sh, reprotests, and ...
doxygen which would make many packages non-reproducible (NB: the actual
embedders of timestamps are latex tools); only one uses it for a reproducible
python source file (pyacidobasic) and one for reproducible images
(x4d-icons).

For reference, I've opened a bug upstream:
https://github.com/wolfcw/libfaketime/issues/418
(and I probably need to open a bug against the faketime package but
won't do so this evening)

I don't have a list of binaries using this ABI but there are probably
only a few, if any, such files outside of coreutils. Considering the
current freeze, it seems very unlikely that new issues will crop up for
the release and there's probably no need to hurry too much.

On the Ubuntu side, I think it wouldn't be reasonable to fix that later
than for 23.10.

I checked again and it implements the same -s behavior but does so based
on the time specification the is provided. You can either provide an
absolute and static time, an absolute and dynamic time, or a relative
and dynamic time (I didn't notice relative and static but didn't try to
find it either). I prefer -s but at least libfaketime should do what we
need.

I definitely understand your situation.

Also, it seems libfaketime has gotten more attention and, by now, many
more features. It would be difficult to come close to it (I never
thought a time-faking library could have so many features).

We believe that the bug you reported is fixed in the latest version of
datefudge, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1028587@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Robert Luberda <robert@debian.org> (supplier of updated datefudge package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sat, 13 Jan 2024 12:52:30 +0100
Source: datefudge
Architecture: source
Version: 1.25
Distribution: unstable
Urgency: low
Maintainer: Robert Luberda <robert@debian.org>
Changed-By: Robert Luberda <robert@debian.org>
Closes: 946776 1028587
Changes:
 datefudge (1.25) unstable; urgency=low
 .
   * Provide 64-bit versions of time functions on 32-bit architectures
     (closes: #1028587, LP: #2002803).
   * Cleanup source code, and reformat it with clang-format.
   * In --static mode, set sub-seconds part to 0 (closes: #946776).
   * Mention in man page and README file existence of libfaketime package,
     that might be considered for more advanced functionalities than the
     ones provided by datefudge.
   * Standards-Version: 4.6.2 (no changes).
Checksums-Sha1:
 d00c414a909c0d1fd9f441a06acc9a606edbf014 1572 datefudge_1.25.dsc
 cdd4aa0b54398a340808045735746aa675340d32 14820 datefudge_1.25.tar.xz
 176ae728f69bb0e4a97116e28e36216da4f23d72 6519 datefudge_1.25_amd64.buildinfo
Checksums-Sha256:
 ce345eafd42fd5ca933bf3414c60babd9d53bf518f21d34c79e6a233df647ea8 1572 datefudge_1.25.dsc
 6c754a6c4de4f934b782d08c1bfef1f0181d796d599f2ce826f74422eecaa8fa 14820 datefudge_1.25.tar.xz
 27a7f3b0ed98d157e8abb1eb5fd7394432a5ce02d23c3a9ec29884979f4e01d7 6519 datefudge_1.25_amd64.buildinfo
Files:
 f7e7f88670d43b3d3432a5caaac2e6a9 1572 devel optional datefudge_1.25.dsc
 2f7a8b88f66dc7987dc407ed870d96c0 14820 devel optional datefudge_1.25.tar.xz
 7a7b30633680462ddd536a4cf36cf253 6519 devel optional datefudge_1.25_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENeh2+rTTcy6TtNI3Yx3nVTvor9QFAmWiegAACgkQYx3nVTvo
r9T57hAAolJP1kAGVNoUeDHiZ16xXjnG1t4Czt4jpcUivP08ATko/cdKG4LkWpHF
zK6PGJ7VCFXkPs154rIg3oXqEqsitY7u/Fb2pzYSQr89VFSsfRurTl5ivWUK7g/S
N34ILaRykveUOhVUk0JUyRtRm51vO6U+N2CIEB7FyMGxT01X7SaWppqLEcw2o1Lm
i0qhK6Ng0m72cQKyC28K195IfibQUN2j0iDfqSfz+Uqj/G8JNjFgtYiyvZZJRJlD
MndZazZkOeNXKIDYGUfgdMDpZ1fmn5beHjxdBrz95HpZUcX90m+eCxTKgqxIxcDt
mVLTxgP0AqiPwuB69GF1s72F1WQZ6VYlm25gSSPmwyAJhzP4kTVi8KSlleejPIcI
Q0oT0KgvW+n+LJ9Ar/WNBQwNp48G/TpsDFjGtYu2JYphlWrmSVB/ruMZYadCYWoD
LPv80VPNJIwTzEHmo+jEvzMC15IpUXBIeTC+cro0AZw3JLqyfrnk0xfSfF/NWGt7
Q6B277JObP6m5tgBjOEyin52VC2NVhjFt5YNNcf5Shw9t0v/UuVkjM/AKu6LPoia
xdNVCVBRtzQPK68IKSArgBdXou3lNnT0wWpi0v9dv2VJS/P3JAu7jl+GljS7oxnM
zV/CY5GFDN27PsZdq+c1kmXDCe78TBptrkoIR4zf4YFlKNRUXRM=
=b2oX
-----END PGP SIGNATURE-----