This was brought to my attention today: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890651
There is an attempt by Debian to keep builds completely reproducible, for what appear to be really good reasons (see https://reproducible-builds.org/). Xastir's build system will create a file "compiledate.c" every time you build it, with the current date and time in it. This feature was added in 2006 as a result of a patch from a user, in commit bf89457. By doing that, we make builds NOT reproducible in the sense desired. They propose that we change our makefile to allow this timestamp to be overridden via an environment variable, so they can simply feed an standard date into it and have us use that instead of the date/time that the compilation is run. But before I (or Dave Hibberd, the Debian maintaner) go ahead and open a bug report to do this, I would like to open a more general philosophical discussion: if you follow the various links about reproducible builds, faking out the compile date is actually sort of a second-best approach: the better one is not to include the compile date in the code in the first place. I propose we take that better approach. Back in 2006, since we were using CVS and there was no single way to say "this build was created using THIS code," using the compilation date was a moderately helpful way to check whether the Xastir you were running was up to date, by checking the Help->About box and seeing how old the build was. This was particularly helpful if you were running code right out of CVS, because the version number was pretty meaningless, and there was no single revision number to point to to show which revision you had built (every single file in CVS had its own revision number). But now, code built from a release source tarball has a meaningful version number and always has (so the compile date is irrelevant), and as of commit ba3b807, any code built out of a git clone has the git SHA-1 hash that was actually built encoded into the About box, in parentheses next to the somewhat meaningless version number that only indicates "the next release in development." The git SHA uniquely indicates what repository state you're looking at or building, so this is pretty close to what the original use case for the compile date was. So it seems to me that instead of applying a patch like the one attached to the debian bug report above, the more permanent and completely portable solution to the reproducible build issue would be to STOP putting the compilation date into the binary altogether. (The actual patch in the debian bug report isn't portable as it relies on linuxisms and GNU Make, so needs a little bit of work if we want to go in the direction of patching up the build). My position is that the compilation date is a poor substitute for "is the code I compiled current?" given that we're now actually saying "this code was built from THIS repository state." If we stop using it altogether and rely instead on the version number and git sha (if and only if the code was built out of a git clone), the build is reproducible by default. So I think that's what we should do. Any thoughts one way or another? Is there anyone who was really still depending on the build date in the About box for anything? -- Tom Russo KM5VY Tijeras, NM echo "prpv_a'rfg_cnf_har_cvcr" | sed -e 's/_/ /g' | tr [a-m][n-z] [n-z][a-m] _______________________________________________ Xastir-dev mailing list [email protected] http://xastir.org/mailman/listinfo/xastir-dev
