[Xastir-dev] Value of "compilation date" in a source-built Xastir?

[Tom Russo]

On Mon, Feb 19, 2018 at 08:16:31PM +0000, we recorded a bogon-computron collision of the <godfreja at gmail.com> flavor, containing:
> I could see a slight use case for the date when running with uncommitted
> code, 

Agreed, this has occurred to me, as the git sha1 hash won't reflect that
you're running modified code.  But in this case, the person interested in
whether the code running is the code in the source tree is presumably the 
same person doing the editing of code, and one can check modification file 
dates of the binary just as easily as the "about" box.  In the CVS days,
even having the compile date in there didn't eliminate this need --- you'd
still have to check that the compile date is later than any of the modification
times of files in the source tree.

> but I don't think that is a compelling enough case to keep the date
> functionality.

Nod.  

If a compelling enough case can be made for keeping it, then there is a path
forward --- fix things so that one can force a fake date in.  Or even add
a configure option that enables building with the compile date, but have it
be default OFF.  But I'd rather do the simpler thing and just not include it
unless it gives some folks real heartache.

> On Mon, Feb 19, 2018 at 1:54 PM Tom Russo <russo at bogodyn.org> wrote:
> 
> > 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
> > Xastir-dev at lists.xastir.org
> > http://xastir.org/mailman/listinfo/xastir-dev
> >

-- 
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]