Building ArchZFS
Run all repository scripts from the repository root. Paths under
packages/*/* are Git submodules. Once initialized, their worktrees contain
generated package repositories; do not treat their PKGBUILDs as the source of
truth. Change conf.sh, definitions under src/kernels/, or templates under
src/zfs* instead.
Container Build
The closest local equivalent to the current GitHub Actions build is:
docker build -t archzfs-builder build-container
docker run -e FAILOVER_RELEASE_NAME --privileged --rm \
-v "$(pwd):/src" archzfs-builder
Production additionally supplies signing material through the GitHub Release
environment. Never place private signing material in local commands, logs, or
commits.
Direct Build
Direct build.sh use requires root, Arch package tooling,
clean-chroot-manager,
network access, and the non-root account configured by makepkg_nonpriv_user in
conf.sh.
Initialize package submodules and configure clean-chroot-manager with a valid
CHROOTPATH; current releases use the ccm command, not the old ccm64 name.
For example, ccm p prepares the clean chroot.
Generate and build utilities first:
sudo bash build.sh utils update make
Then build DKMS or a kernel family:
sudo bash build.sh dkms update make
sudo bash build.sh std update make
sudo bash build.sh lts update make
Common modes are:
utils: userspace utilities.
dkms: DKMS package.
std: standard linux kernel.
lts: linux-lts kernel.
hardened: linux-hardened kernel.
zen: linux-zen kernel.
all excludes iso and vfio. The -s option skips Git and release-candidate
variants and matches the stable-version package generation used by current CI.
Although listed by build.sh --help, test and update-test have no execution
path and must not be reported as validation. See the Testing page for
the current test boundary.