Every xOneRS binary carries one version stamp, built at compile time from the semver, the commit, a dirty flag, a date, the target and the compiler. The release script fixes the date to the commit time with SOURCE_DATE_EPOCH and removes build paths from the binary, so two release builds of one tag are byte-equal. A static musl build for issue #894 passed the static checks but is larger than the release size budget. This post covers the build only; no new release has been published.

For how to read the stamp, see the release process; for checking a downloaded file, see verifying a release artifact.

How is the version stamp built?

bin/xone/build.rs writes, at compile time (build.rs):

xOneRS/v<semver>-<commit8>[-dirty]-<DDMMYYYY>/<os>-<arch>/rustc<version>
  • <commit8> comes from git; without git data it is unknown.
  • -dirty is added when git status --porcelain is not empty. Editing a tracked file flips it without any git command.
  • <DDMMYYYY> comes from SOURCE_DATE_EPOCH when it is set, else from the build time.
  • rustc<version> comes from rustc --version.

Why does a release use SOURCE_DATE_EPOCH?

ci/release.sh sets SOURCE_DATE_EPOCH to the commit time of the tag (git log -1 --format=%ct). The stamp date is then the commit date, not the build day, so every rebuild of a tag gives the same stamp. The script also checks that the binary's stamp equals xOneRS/v<version>-<commit8>-<date of SOURCE_DATE_EPOCH> and refuses a stamp with unknown or -dirty (release.sh, docs/ops/release.md).

Which flags make two builds equal?

The release script removes paths that differ between machines and turns off the random build id:

RUSTFLAGS="--remap-path-prefix=$root=/build --remap-path-prefix=$cargo_home=/cargo \
  --remap-path-prefix=$sysroot=/rustc -C link-arg=-Wl,--build-id=none"
CFLAGS="-Wno-error=date-time"   # libmdbx uses __DATE__; fixed by SOURCE_DATE_EPOCH

The rehearsal ci/test-release.sh builds the same tag in two clones at different paths, at the same time, with SOURCE_DATE_EPOCH set to the commit time. The recorded result: the binary and the tarball SHA-256 are equal. The rehearsal notes that the run used one user, one CARGO_HOME and one host, so it proves path independence only (release-rehearsal.md).

What did the static musl test build show?

Issue #894 asked for a static musl rebuild of v0.1.x, because the published v0.1.0 binary is dynamically linked. It was closed on 2026-11-15 by PR #1120, which adds ci/republish-v0.1.sh and docs/ops/republish-v0.1.md; the PR uploads no assets, and the v0.1.0 release still has the dynamic binary. A preparation run on 2026-11-15 built the release step by hand from main (no tag, no publish) and recorded:

REFERENCE TABLEScroll to explore all columns →
Check Result
file ELF 64-bit, statically linked, stripped
ldd not a dynamic executable
GLIBC symbols (objdump -T) 0
Stamp xOneRS/v0.1.0-a95eb05f-15112026/linux-x86_64/rustc1.94.0, equal to what the script expects for that commit and date
.dep-v0 section (cargo-auditable) present
Size 20,820,968 bytes, above the 18,874,368-byte budget (18 MiB)

The size means ci/release.sh would refuse the binary. The v0.1.0 glibc binary was 19,066,296 bytes, also over. The comment leaves the choice to the owner: raise the budget or reduce the size. Issue #894 is open, and a new release still needs a tag, the version bump, ci/qualify-artifact.sh and the signing-key decision.

The collected competitor articles state no claim about reproducible builds, so this post has no comparison table.

Frequently asked questions

What does the date in an xOne version stamp mean?

In a release build, the commit date of the tag, from SOURCE_DATE_EPOCH. In a plain developer build without that variable, the day of the build.

Can I rebuild an xOne release and get the same bytes?

The rehearsal shows equal SHA-256 for two builds of one tag at different paths on one host with the release script's flags. Builds on different hosts or toolchains are not covered by that record.

Why would the release script refuse a binary?

A dirty tree, a HEAD that is not at the tag, a stamp that differs from the tag and commit, a binary that is not static, GLIBC symbols, or a size over the budget.

Is there a static musl release of xOne now?

Not yet. A republish helper exists (PR #1120), but the v0.1.0 release assets were not replaced when we checked on 2026-11-15.

Sources