Article: FreeBSD Release Engineering

[bofh]

Summary

This article discusses the different build mechanisms and relevant variables that affect the release of build artifacts.

Test Plan

The article is available live at this URL for easier reading:
https://fdp.bofh.network/en/articles/reproducible-build/

[lwhsu]

documentation/content/en/articles/reproducible-build/_index.adoc

33

Those variables seem not being used in this article?

[emaste]

documentation/content/en/articles/reproducible-build/_index.adoc

80

They're not necessarily public domain, they're just publicly released.

93

107

I wouldn't say secteam is part of the re process at all; and security patches and integration into release branches is after the release is out not "during" the RE process

108

Check them against what?

186

202

maybe semi-automatically?

204

biweekly?

248

We probably need to clarify the targets in release/Makefile vs. the release/release.sh script and thermite here; e.g. TARGET and TARGET_ARCH are for the first one

278

parallel builds are possible with or without MAKEOBJDIRPREFIX
the object files are placed in a subdir of MAKEOBJDIRPREFIX (/usr/obj if not set) based on the src tree path and target arch and it's that aspect that allows parallel builds of mutliple architectures

282

Probably choose an example that isn't the default

287

These are not release artifact targets. I'm not sure there's a reason to document DESTDIR for release artifacts?

297

Not sure these belong with release artifact builds either?

308

And same here. Probably all of these belong in a different document?

357

NO_PROFILE is an error (see 20200212 UPDATING)
Profile support is gone entirely for some time

360

360–361

The double/triple negative here is confusing: release builds disable the feature that disables the logic that strips build timestamps

it's probably better to explain that historically some build artifacts included build timestamps, user information etc. and that has now been removed by default. WITHOUT_REPRODUCIBLE_BUILD restores those non-reproducible things

362

Note that for ISO and memstick release artifacts this is an internal detail between release/Makefile's targets and installworld et. al. The user doesn't have to set this - it is explicitly passed to the make invocations (distributeworld, packageworld, distributekernel, packagekernel, installworld, installkernel, distribution) in release/Makefile.

373

This shouldn't be the case - any META_MODE-induced non-reproducibility is a bug to fix. Are there actual examples of this?

419

is it fair to say that make release is the make target to build all release artifacts for one given TARGET/TARGET_ARCH pair?

We should also have an example showing this or at least explicitly point out that this is a target in release/Makefile not the top-level

431

?

441

something like "for each TARGET/TARGET_ARCH pair, release.sh:"?

508–509

At least prior to 15.0.

555

561

base.txz?

[dch]

I like this article. A lot. No specific feedback, just a general comment - who is the target audience for this?

I had 2 potential groups in mind:

• FreeBSD user/organisation who wants to build from sources, replicating the official release process as close as possible

• FreeBSD project itself, serving as an overall guide on what this process is and who is involved

For the former, I would make sure there is a clear "golden path" through the
myriad options and knobs.

For the latter, again we should also be clear what are the settings we use today are.

But the document might be more clear if it targeted just one group rather than both.

[bofh]

Address some of the issues mentioned here.

[bofh]

documentation/content/en/articles/reproducible-build/_index.adoc

107

I had a discussion with @cperciva and he mentioned that secteam@ actually generates related freebsd-update deltas for the BET and RC releases and users can actually update to these intermediate releases either for testing or whatever the purpose is. So I have updated the description to match to that statement.

108

See above comments. This line has also been updated to address this.

373

This is something I will need to recheck. I am more than confirmed that I have faced this issue.

[dch]

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

[bofh]

In D50331#1157176, @dch wrote:

Unless there are major objections we could commit this and tinker later. LGTM, thanks moin!

No. We have made some plan changes during our last meeting. We want to add the entire release engineering process including how a downstream provider can actually build a custom image. At the moment I am still occupied with the final touch of the 14.3 Release Notes. And plan on reshuffling this after that.