Reproducible FreeBSD ?

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 https://reproducible-builds.org. 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 main branch of freebsd.git. The jenkins job is running reproducible_freebsd.sh, which via ssh triggers a build on a FreeBSD system and this script is solely responsible for creating this page. Feel invited to join #reproducible-builds (on irc.oftc.net) 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 2024-09-05 for the branch main at commit bedfac1f0 using diffoscope 277.

variation	first build	second build
hostname	osuosl1-amd64 or osuosl2-amd64	the other one
domainname	is not yet varied between rebuilds of FreeBSD.
env TZ	TZ="/usr/share/zoneinfo/Etc/GMT+12"	TZ="/usr/share/zoneinfo/Etc/GMT-14"
env LANG	LANG="en_GB.UTF-8"	LANG="et_EE.UTF-8"
env LC_ALL	not set	LC_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 CPU	same for both builds
/bin/sh	is not yet varied between rebuilds of FreeBSD.
year, month, date	osuosl1-amd64: today (2024-09-05) or osuosl1-amd64: 398 days in the future (2025-10-08)	the other one
year, month, date	today (2024-09-05)	the 2nd build is done with the build node set 1 year, 1 month and 1 day in the future
hour, minute	hour and minute will vary between two builds	additionally the "future build" also runs 6h and 23min ahead
filesystem of the build directory	ufs	same for both builds
Filesystem	tmpfs	same for both builds (currently, this could be varied using disorderfs)
everything else...	is likely the same. There will be more variations in the wild.

Artifacts for `freebsd_main_gitbedfac1f0`
freebsd_main_gitbedfac1f0 failed to build from source.

commit bedfac1f026fa8e2e6572ca380d89d74a01d5def
Author: John Baldwin 
Date:   Thu Sep 5 17:14:36 2024 -0400

    nvmf_tcp: Fully honor kern.nvmf.tcp.max_transmit_data for C2H_DATA PDUs
    
    The previous version of tcp_send_controller_data avoided sending a
    chain of multiple mbufs that exceeded the limit, but if an individual
    mbuf was larger than the limit it was sent as a single, over-sized
    PDU.  Fix by using m_split() to split individual mbufs larger than the
    limit.
    
    Note that this is not a protocol error, per se, as there is no limit
    on C2H_DATA PDU lengths (unlike the MAXH2CDATA parameter).  This fix
    just honors the administrative limit more faithfully.  This case is
    also very unlikely with the default limit of 256k.
    
    Sponsored by:   Chelsio Communications