Re: [hatari-devel] Preparing release 2.3 - re-producible builds

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/21/20 1:16 PM, Nicolas Pomarède wrote:
> Le 21/10/2020 à 12:02, Eero Tamminen a écrit :
> > Nicolas, do you have any comments on this?
>
> I was not aware that reproducible builds (ie binary exact) were used 
> that much.
> But in what context are they used ?

Wikipedia:
https://en.wikipedia.org/wiki/Reproducible_builds

"Reproducible builds can act as part of a chain
of trust;[1] the source code can be signed, and
deterministic compilation can prove that the
binary was compiled from trusted source code."

Debian lists more benefits:
https://wiki.debian.org/ReproducibleBuilds/About

For developer the main benefit is probably it making trivial to check 
that proposed changes have
no impact on binaries (binary is identical).


> If you build the same sources (no 
> change since some days), what's the point of checking you get the same 
> binary ? (as some system libs/headers can change too in the same time)

In reproducible builds they don't, that's
the whole point.  Build is expected to produce
identical binary when *all* the tools & sources
are same.

Linux kernel document on it:
https://www.kernel.org/doc/html/latest/kbuild/reproducible-builds.html

Linux does it generating header for timestamp and
other things that can vary (paths, hostnames etc),
and allowing all of them to be overriden:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/mkcompile_h#n26

There's even spec on how time timestamps should
be handled:
https://reproducible-builds.org/specs/source-date-epoch/#idm53

And example for CMake:
https://reproducible-builds.org/docs/source-date-epoch/#cmake


> fileid can be useful to identify a binary, if only one distro/maintainer 
> wants to remove them, maybe that's not a good enough reason to backport 
> the changes in our code ?

__DATE__ & __TIME__ have already been removed
from them.

The questions were:

* What to do with the remaining ones for
  Hatari version string [1]

* Should fileid strings (of form "Hatari
  <filename>") be added also to files that
  are currently missing them

But I don't think these need to be necessarily
done before release.


	- Eero

[1] I think it should use SOURCE_DATE_EPOCH spec
(which is unix timestamp i.e. seconds since 1970),
which is taken either from date or last git commit
[2], unless user overrides it.  At runtime this
seconds value should be converted to user readable
string when it's output to user.

[2] git log -1 --pretty=%ct