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 _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
