SHARED PAIR2c–2eAbout →
← Reports

R–02 · Build method

Can we build it twice?

Pinned builders, frozen inputs, matching outputs, SBOMs, and provenance.

Review state
Draft for approval
Updated
31 Aug 2026
Scope
Cross-project

Conclusion

The current packages are repeatable build inputs with clean-container behavioral tests; bit-for-bit reproduction, published SBOMs, and signed provenance remain release requirements rather than completed claims.

01

What is already controlled

Package versions and runtime dependency bounds are explicit. The test suite installs local Debian artifacts into fresh Ubuntu 26.04 containers and exercises application behavior as an unprivileged user.

  • Electron 42.9.3 and 44.0.0 are separate, co-installable artifacts.
  • Every listed application names the runtime major it was tested against.
  • Tests inspect package contents as well as launching or exercising the application.
02

What the tests prove

Behavioral tests establish that the split packages install and perform named operations. Examples include draw.io export, Joplin profile persistence, Jupyter server startup, and Netron model opening. They do not by themselves prove that two independent builders produced identical bytes.

03

Publication requirements

Repository promotion should carry enough material to trace a package back to its inputs and builder. These items remain part of the release checklist.

  • Record and publish source and input hashes.
  • Generate an SBOM for each runtime and application package.
  • Publish builder identity and signed provenance.
  • Attempt an independent rebuild and report whether outputs match.
  • Preserve test results with the exact package versions they describe.