I could see a slight use case for the date when running with uncommitted
code, but I don't think that is a compelling enough case to keep the date
On Mon, Feb 19, 2018 at 1:54 PM Tom Russo <ru...@bogodyn.org> wrote:
> This was brought to my attention today:
> There is an attempt by Debian to keep builds completely reproducible, for
> what appear to be really good reasons (see
> Xastir's build system will create a file "compiledate.c" every time you
> 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
> 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,
> 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
> build was created using THIS code," using the compilation date was a
> 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
> 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
> 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
> 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
> My position is that the compilation date is a poor substitute for "is the
> I compiled current?" given that we're now actually saying "this code was
> from THIS repository state." If we stop using it altogether and rely
> 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
> 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]
> Xastir-dev mailing list
Xastir-dev mailing list