Project Repositories

NextBSD is assembled from a chain of repositories. Each publishes a rolling continuous artifact that the next stage ingests, so a change to the kernel flows automatically through to a bootable image.

This page is for people who want to contribute or understand the build. If you just want to use NextBSD, Getting Started is the page you want.

The chain

toolchain → nextbsd-freebsd-compat (base) ─┐
                                           ├→ nextbsd-userland → nextbsd (image + ISO)
            nextbsd-kernel → modules ──────┘                          │
                                                                      ▼
                                                                 nextbsd-pkg

What each repo owns

Repository	Owns
nextbsd	Assembles the bootable image and ISO. Start here — its README and PORTING.md are the best overview.
nextbsd-kernel	The kernel, as patches plus an overlay on FreeBSD. The FreeBSD tree is never forked in place. Kernel config lives in config/NEXTBSD.
nextbsd-kernel-modules	Driver kexts, KPI-matched to the kernel.
nextbsd-userland	The Darwin system layer — Mach, launchd, configd, CoreFoundation, IOKit and their daemons. Also the installer.
nextbsd-freebsd-compat	The curated FreeBSD-source base userland, built from a srclist.
nextbsd-pkg	Turns the above artifacts into pkg(8) packages and publishes a flat repo.
nextbsd-overlays	Seed-once system config for images — /etc, loader fragments.
nextbsd-kernel-toolchain	Cross-build toolchain containers.

How the build actually runs

Everything runs on GitHub Actions' Linux runners — there is no FreeBSD hardware in the loop.

• The kernel and the from-source base are cross-compiled on Linux with a FreeBSD cross-toolchain (clang -target …-freebsd) in a prebuilt container, so those stages never need a FreeBSD host.
• Image assembly (build.sh in the nextbsd repo) runs inside a FreeBSD VM on that same Linux runner, because it needs a real FreeBSD userland for makefs and mkimg. That stage also boot-tests the result and refreshes the continuous release when main builds successfully.
• pkg runs in a FreeBSD VM too; the Linux runner only moves artifacts.

Because the kernel and base arrive as published artifacts, build.sh is a CI orchestration step rather than a standalone local build command.

Where the userland comes from

The userland is split deliberately:

From Darwin source (things with no FreeBSD equivalent) — libmach, libdispatch, libxpc, liblaunch, libCoreFoundation, launchd, configd, libIOKit, kext_tools, Libnotify, the syslog/ASL stack, IPConfiguration, mDNSResponder, DiskArbitration, hostnamed.

From FreeBSD source (generic POSIX tools) — file_cmds, shell_cmds, text_cmds, adv_cmds, system_cmds. Apple's versions buy nothing over FreeBSD's for these, so they come from curated FreeBSD source synced to the releng train.

Versioning

Every build is stamped with one UTC timestamp, YYYYMMDD-HHMMSS, computed once and shared by the image name, /etc/os-release and nextbsd-version. Kernel and userland build in separate repos at different times, so their stamps differ — which is exactly what nextbsd-version -k exists to show.

Contributing

• Discussions — design questions, ideas, help
• Issues — bugs
• Pull requests go to the repository that owns the code — the table above says which.

Kernel and kext changes deserve testing on a real VM before merge, not just green CI. The console and newbus paths fail in ways CI cannot observe.