Maxima fails Debian requirements for reproducible builds due to baked-in timestamp #4205
Description
Imported from SourceForge on 2024-07-09 20:03:12
Created by peterpall on 2023-12-29 12:54:13
Original: https://sourceforge.net/p/maxima/bugs/4235
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.