#4235 Maxima fails Debian requirements for reproducible builds due to baked-in timestamp

[Gunter Königsmann]

build_info();

contains a timestamp when maxima has been built - which is disencouraged by the debian build system, as timestamps hinder the build from being reproducible (see https://reproducible-builds.org/docs/timestamps/ for details).

AFAICS this timestamp is done in three separate places (maxima.system and maxima.asd, which are the main files for two separate build systems, as well as init-cl.lispfor lisps like ECL that don't save the values of variables during a core dump; I am not sure if asking for the time in that place adds a timestamp of the build time, or a timestamp for the current time, though.

Currently the command

(get-decoded-time)

is used, which should be the same as

(decode-universal-time (get-universal-time))

If we want to provide a build timestamp (perhaps we want to, as dropping fields from an user-visible struct might break user code) debian offers us a way: If they want a reproducible build they set the environment variable SOURCE_DATE_EPOCH to the number of seconds since Januar 1st, 1980 a half-way sane build timestamp would have => Something like

(decode-universal-time (+ (maxima-getenv "SOURCE_DATE_EPOCH")  2524521600))

(with the appropriate type conversions and error handling added) should do the trick, in that case.

Bonus task:
Perhaps it would be nice to merge the three separate definitions to one place so the code in the three places doesn't differ.

[Robert Dodier]

Merging different build time timestamps seems like a win. I'm sympathetic to making builds exactly reproducible although it does seem like a low-priority item.

We would need to ensure that whatever solution we arrive at works okay for non-Debian systems too, I guess.