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@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds