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. On Wed, Jan 18, 2023, Matthias Urlichs wrote: > On 18.01.23 15:51, adrien wrote: > > 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. > > [ 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 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 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 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).
