[Reproducible-builds] reproducible builds of FreeBSD in a chroot on Linux

Holger Levsen holger at layer-acht.org
Sat Jul 18 14:09:45 UTC 2015


Hi,

so I made some progress on this: a.) there is a build host running freebsd 
10.1 (called freebsd-jenkins.debian.net) now, on which the jenkins user from 
jenkins.debian.net can login via ssh as jenkins user b.) besides the base 
system it has "screen git vim sudo denyhosts" installed and c.) the 
directories /srv/workspace/chroots/ and /srv/reproducible-results have been 
created (and are owned by the jenkins user) and d.) /usr/obj/srv is a link to 
/srv.

With this, 
http://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/reproducible_freebsd.sh 
gets as far as 
https://jenkins.debian.net/view/reproducible/job/reproducible_freebsd/7/console 
where "stage 2.1: cleaning up the object tree" fails on "make buildworld", 
because /srv/workspace/chroots/freebsd-
XXXXXXXX.v1adN6Qo/freebsd/lib/libc/tests does not exist.

And at this point I'm stuck as to why this happens. Any hint much welcome!

(Please note that reproducible_freebsd.sh is just a work-in-progress now and 
there are still some bits from it's source, reproducible_netbsd.sh visible. 
This need to be cleaned up, but shouldn't be too confusing know that this is 
clear.)

On Mittwoch, 17. Juni 2015, Ed Maste wrote:
> > https://wiki.freebsd.org/ReproducibleBuilds claims there are 3 known
> > issues (for "make world" AIUI) for HEAD, I would like to build twice and
> > verify myself.
> I'm interested in fixing the remaining kernel / world issues, with the
> kernel being my higher priority.

cool!
 
> For the kernel we have the username, hostname, and build timestamp.
> The path is included too, but I don't anticipate trying to address it
> at first; release builds are done in a consistent location anyhow
> (/usr/src).

/me nods - that's what we are doing in (reproducible builds for) Debian too, 
the path has to be the same on rebuilds (as it is included in too many build 
artifacts to deeply.)

> These are used only as user-facing strings for the kern.version sysctl
> and reported by uname. An example kern.version string:
> FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26 16:07:47 EDT
> 2015
> emaste at feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC
> 
> From a technical perspective they're trivially eliminated. There may
> be some 3rd party ports expect the precise format, but probably not
> very many (and they should be fixed, anyhow).  There's a much larger
> social issue in convincing the FreeBSD developer community to accept
> their removal, though :-)

If any build (of the same sources) results in the exact same bits, the build 
time becomes meaningless and thus a.) can be dropped or b.) replaced with the 
date of the last modification of the sources - which is meaningful information 
again!

While this is/was a new thought for most everyone (me included...) in my 
experience it also has been convincing logic for most everyone. The technical 
details to achieve this are sometimes a bit harder to achieve, but not 
impossible. (eg they differ whether git, svn or tarballs are the means to get 
access to sources.)

In Debian we want 100% bit identical packages (=.deb files) as this allows us 
to only require a checksum comparison to see whether two builds created 
reproducible results.

> > https://wiki.freebsd.org/PortsReproducibleBuilds says "Of the 23599
> > packages which were built in both runs, 15164 have the same checksum
> > when using the previously mentioned patch, giving 64.25% reproducible
> > packages." - I'm also curious to re-confirm this - and set up a test
> > bed, which can be triggered regularily and easily. Our jenkins set up
> > allows this and I'm interested to do this.
> 
> I'm pleasantly surprised by the ports results -- 64.25% seems quite
> good for such a straightforward change. The test there is on the same
> host though, and so avoids any non-reproducibility from host/user/path
> leaks.

ah

> > My interest is to help FreeBSD with reproducible builds as I want to see
> > reproducible builds become the norm in the free software world and as I
> > believe FreeBSD is an important part of this world. And also because I'm
> > curious. :)
> 
> Great! Hopefully we can help lend some weight in convincing upstream
> projects to accept reproducibility patches (once we get further along
> in our ports effort).

I'm looking forward to see this happen! ;-)


cheers,
	Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20150718/f1393b31/attachment.sig>


More information about the Reproducible-builds mailing list