Reproducible builds enable anyone to reproduce bit by bit identical binary packages from a given source, so that anyone can verify that a given binary derived from the source it was said to be derived. There is more information about reproducible builds on the Debian wiki and on These pages explain in more depth why this is useful, what common issues exist and which workarounds and solutions are known.

Reproducible FreeBSD is an effort to apply this to FreeBSD. Thus FreeBSD is build twice, with a few variations added and then the resulting filesystems from the two builds are put into a compressed tar archive, which is finally compared using diffoscope. Please note that the toolchain is not varied at all as the rebuild happens on exactly the same system. More variations are expected to be seen in the wild.

There is a weekly run jenkins job to test the master branch of freebsd.git. The jenkins job is running, which via ssh triggers a build on a FreeBSD 11.2 system and this script is solely responsible for creating this page. Feel invited to join #reproducible-builds (on to request job runs whenever sensible. Patches and other feedback are very much appreciated - if you want to help, please start by looking at the ToDo list for FreeBSD, you might find something easy to contribute.
Thanks to IONOS for donating the virtual machines this is running on!

0 (0%) out of 0 FreeBSD files were reproducible in our test setup . These tests were last run on 2021-01-21 for the branch master at commit de1aa3dab using diffoscope 164.

variationfirst buildsecond build
hostname osuosl169-amd64 or osuosl170-amd64the other one
domainname is not yet varied between rebuilds of FreeBSD.
env TZTZ="/usr/share/zoneinfo/Etc/GMT+12"TZ="/usr/share/zoneinfo/Etc/GMT-14"
env LANGLANG="en_GB.UTF-8"LANG="et_EE.UTF-8"
env LC_ALLnot setLC_ALL="et_EE.UTF-8"
env PATH is not yet varied between rebuilds of FreeBSD.
env USER is not yet varied between rebuilds of FreeBSD.
uid is not yet varied between rebuilds of FreeBSD.
gid is not yet varied between rebuilds of FreeBSD.
FreeBSD kernel version is not yet varied between rebuilds of FreeBSD.
umask is not yet varied between rebuilds of FreeBSD.
CPU type AMD Opteron 62xx class CPUsame for both builds
/bin/sh is not yet varied between rebuilds of FreeBSD.
year, month, dateosuosl171-amd64: today (2021-01-21) or osuosl172-amd64: 398 days in the future (2022-02-23)the other one
year, month, datetoday (2021-01-21)the 2nd build is done with the build node set 1 year, 1 month and 1 day in the future
hour, minutehour and minute will vary between two buildsadditionally the "future build" also runs 6h and 23min ahead
filesystem of the build directoryufssame for both builds
everything likely the same. There will be more variations in the wild.

Artifacts for freebsd_master_gitde1aa3dab
freebsd_master_gitde1aa3dab failed to build from source.

commit de1aa3dab23c06fec962a14da3e7b4755c5880cf
Author: Ulrich Spörlein 
Date:   Wed Dec 30 11:29:55 2020 +0100

    Dear all,
    the FreeBSD project has switched their source of truth repository from
    Subversion to Git on 2020-12-23. The previously published commit hashes
    were missing required merge commits and were thus unsuitable to be the
    basis of the source of truth repository.
    They had to be changed (aka "force pushed"). We're sorry for the
    inconvenience this causes.
    The `master` branch will no longer see any updates and we will push to
    `main` going forward. The `stable/X` and `releng/X` branches will see a
    force-push directly.
    To transplant your work, it is recommended to head over to the wiki at for instructions on how to
    rebase or remerge your in-flight work. A short outline will be provided
    Please note that the actual git "trees" are of course identical between
    the old and new conversions, so it's relatively easy to craft git
    commits that merge or rebase the work w/o any merge conflicts. Please
    reach out to or file an issue under if you need assistance.
    The mapping of the old to new commit hashes (for the same tree) are
    given below. We have archived a copy of the legacy repo under which you can add as a remote
    to always have a reference to the old `master` or `stable/X` branches
    and names.
    This is a merge commit that brings both histories together, giving you
    common history ancestors, which should help with later merging.
    You should be able to cleanly merge into this "legacy" master, and then
    merge into "main" following from that. All the following commands assume
    you've checked out your own workbranch.
    -- Merge from master to main --
    $ git remote add freebsd-legacy
    $ git fetch --all
    $ git merge freebsd-legacy/master  (this convenience commit)
    $ git merge origin/main
    -- Merge for stable/X or releng/Y branches --
    $ git remote add freebsd-legacy
    $ git fetch --all
    $ git merge freebsd-legacy/stable/X  (to get to the legacy hashes from below)
    $ git merge -s ours --allow-unrelated-histories  (this is guaranteed conflict free)
    $ git merge origin/stable/X
    PLEASE NOTE: You'll end up with twice the history and git log output
    will show old history twice and will likely confuse you. Please make an
    effort to migrate your work over to a fresh branch based off of main.
    A git replace --graft can be used to at least patch up git log output.
    -- Rebase your work --
    Only for folks that always rebase their local work on top of an origin
    $ git remote add freebsd-legacy
    $ git fetch --all
    $ git branch -u freebsd-legacy/master
    $ git rebase --onto origin/main 
    -- Old to new hash mappings --
       BRANCH                    LEGACY HASH                                    NEW HASH
    master / main   9e4440ca5ba7072e6b8c4d0d9799fb9d82c5ad49    3cc0c0d66a065554459bd2f9b4f80cc07426464a
    stable/10       10f4a6c225ee83ceae8013937d720abc6d55a42b    3ad46d07830bba44c479e2d19ce376212e52e9af
    stable/11       a76e2a369a53c030aca4a52b694102e99aadbb2f    46062cb1a2d980ab8fc52a36a418bb44c06fe95f
    stable/12       f262e04c92d7b7a409e91c21a09ea09d54619099    f4d0bc6aa6b90cbb0ea6cb993d9a10e36f5f4a4c
    releng/10.0     fcf03644270b915aec5f010cd84202ad00ce746d    0099f6f89a1325dc504096aecbdcbddad498310e
    releng/10.1     a5b8a0cee842e12aa090449e042788b9eabc35da    a9b4be204689211fddaab97ddd6df73b8f44d222
    releng/10.2     14e67f3152c63dff2a97a5fcd9b3fa03a6625f31    2a3488342441b3296995c8a9eca705a468d0eff0
    releng/10.3     57fbb64699be1ef57f413a39f3d6920bb192ee7f    8411c9ac24aabdbbde468778b35da58dc3c15178
    releng/10.4     976886d4ea7217ba54d00b10afc0c0a3e59cc552    d869f4ade283f4691dc249e435376a5883824be2
    releng/11.0     bc72ed658ec8c6cef0ceb206e8e29ed67a58af03    8d2708de5d6112a492744d367cfdfb8fd219227a
    releng/11.1     d3b778b791f4e4d8afc69698b2097efdf2f79de7    3e9337c6b211e778829ed3af783cd41447a8721b
    releng/11.2     24e863807ab509af9c38e84b4e5df34ff4fdf9e2    c0d2bc3b0336fb6825302f44adabff0893d25aed
    releng/11.3     b43bbc16b05f1b7e0770ac18bc2be0b3805a994e    9e63140d5a00c9d691d88c5a650c2f74a63105ff
    releng/11.4     9332e027885d3d785a45dfcf3f7bd2f7c8181d0a    4adbf1f6686ffdc4c0555a018e14ec63b5981534
    releng/12.0     58cdccde6ac7b22cc1ca42fbca6460a58304077f    12b769ed36a115da3b5013c92cdf294a3a5de98d
    releng/12.1     c522014dbaadf4b1d7431093f91c52cbf1d3ca62    e30782bbdad59b00537d9c44c17e3fb5b3cec95b
    releng/12.2     30ef47ef8fb0026951af8501fe30d33f3b4a7090    2120d07af09cb830873554ba5405c5d3e51b41cc
    Again, we're sorry for the inconvenience, please reach out via GitHub
    issues and the mailing list to get further help in transplanting your
    work onto the one true, canonical, source of truth.
    Good luck in 2021!
    Ulrich Spörlein, on behalf of the FreeBSD Git working group.