Build Reproducibility Workshop Report

[Rainer Müller]

Thank you for this details report! It seems like this was quite a
productive meeting in Athens and I am glad you represented MacPorts.

On 2015-12-08 23:48, Clemens Lang wrote:
> Testing Build Reproducibility
> =============================

[...]

> To track down the differences that cause builds to be non-reproducible,
> a couple of people from the Debian reproducible builds effort have
> written diffoscope [5], a python diff tool that will interpret file
> formats and try hard to give you a human-readable difference between two
> files. Support for Mach-O binaries is available as a patch at [6] (and I
> hope to push it upstream soon). This tool could also be helpful to look
> at differences in stealth updates.

This looks interesting. Anyone up for creating a port? :-)

> State of Reproducible Builds in MacPorts
> ========================================

[...]

> To fix the timestamp issues, I am looking for a suitable value to use as
> SOURCE_DATE_EPOCH and then add a find statement before creating the
> archive that will put an upper mtime limit on all files to be packaged.
> I am not yet sure what a good (reproducible!) timestamp might be:
>  - The Portfile mtime would be perfect, but is not preserved by
>    Subversion, so we cannot rely on it. It is preserved by our rsync
>    sync, but the mtime in that is probably meaningless since it's the
>    one generated on the rsync server during svn update.

Subversion can be configured to apply the commit timestamps to files
(use-commit-times=yes). We could use that on the server creating the
port tarball for rsync. Although I would prefer a more generic solution.

Previously I wanted to abandon keywords, but taking the date from the
expanded $Id$ in the Portfile would probably be quite handy for this...

>  - The newest timestamp inside a source code tree is a good choice (and
>    https://github.com/0-wiz-0/findnewest could easily give us that
>    timestamp), but sources fetched from version control systems do not
>    always set it to the time of the commit (AFAIK Git doesn't, for
>    example).
>  - A fixed value of 0 or 1 is not a very good choice.
> We could put an additional piece of metadata into Portfiles to be used
> as timestamp (e.g. just like we have checksums). It is my understanding
> that FreeBSD will chose to go this route.

Hm, that would be an additional value that always needs to be increased
by the maintainer? That sounds error-prone.

> Miscellaneous Topics
> ====================
> I've learned that our builds of GHC and all Haskell modules are likely
> ABI-incompatible when downloaded from the buildbot vs. built locally.
> We should disable parallel building for Haskell to fix this until
> upstream provides a better solution. Luckily, this hasn't largely
> affected us yet, because binary availability in the Haskell land is
> high.
> 
> Homebrew achieves good binary package coverage for non-default prefixes
> by scanning the build results for $prefix. In library load commands, the
> path is changed using install_name_tool(1) on installation locally, in
> text files, the path is simply changed. If $prefix is found in a binary
> file, the archive is marked as non-prefix-invariant and ignored by
> non-default prefix installations.

Such a check to verify the build results is something I always wanted
post-destroot. Not necessarily to fix it, but just to validate the build
result. But the implementation to do such analyses is still only in the
diverged branch gsoc11-post-destroot.

We already have been using -headerpad_max_install_names for a few years,
but never dared to go further and actually fix this in a compiled port
archive. I am surprised this works for them.

> Homebrew has methods to provide compiler wrappers that ensure that build
> systems are UsingTheRightCompiler, and additionally ensure that the
> compiler flags are set as expected (e.g. -arch flags, -stdlib flag for
> C++).

This was proposed multiple times already. For example, Fink has always
used wrappers to pass custom flags to the compiler.

See https://trac.macports.org/ticket/44413


On a related side note, all of this would be good additions for MacPorts
base. However, currently our trunk is not in the best shape after
merging the feature branches from last GSoC. The remaining bugs in the
interactive mode and the new reclaim should be fixed first before
beginning new work. Otherwise I fear we will not reach a state where we
could split off a new release. Maybe we should make a real release plan
with milestone targets to make progress?

Rainer