distribution.md

Package and source delivery

Stage a binary release and SHA-256 manifest:

python3 scripts/nvx.py package --binary-only

Binary-only mode requires an explicit acknowledgement because the matching Linux, Alpine, Ubuntu, and Azure Linux source must be published separately.

First materialize the release sources:

python3 scripts/nvx.py collect-sources

This produces a patched Linux corresponding-source archive under build/sources/linux, exact Alpine recipes/upstream sources under build/sources/alpine, and exact Ubuntu .dsc plus referenced source members under build/sources/ubuntu. Then stage the binary release with four separate source artifacts:

python3 scripts/nvx.py package --include-source

The release contains:

source/nvx-project-source-0.1.0.tar.gz
source/nvx-linux-source-6.18.38.tar.gz
source/nvx-alpine-source-0.1.0.tar.gz
source/nvx-ubuntu-source-0.1.0.tar.gz

collect-sources does not collect Azure Linux corresponding source, so --include-source omits initramfs-azurelinux.cpio.gz and its package manifest from the staged release and from the packaged SOURCE-MANIFEST.json. Distribute the Azure Linux guest only from a binary-only package while its corresponding source is published separately.

Linux is GPL-2.0-only, so a distributor of vmlinux must make its complete corresponding source available. Alpine packages retain their individual licenses. The collector uses the exact aports commit embedded in every installed APK and runs abuild fetch plus abuild verify. Its manifest lists the executable recipe files, and the Alpine source archive takes its file modes from that list rather than from the collecting host, which may not store them. If Python initramfs variants are present, collect-sources includes their package manifests automatically.

Ubuntu artifacts use Ubuntu userland with the NVX kernel. The collector deduplicates exact source package name/version pairs from both Ubuntu manifests, downloads the matching .dsc and source members from Canonical's archive, verifies each source index through its signed InRelease file and the pinned Ubuntu archive keyring, and then verifies the indexed SHA-256 metadata before packaging. Source collection and release staging also require each Ubuntu artifact to match the artifact name and SHA-256 embedded in its companion manifest. Exact versions that have left the live suite indexes are located through Canonical's Launchpad publishing history and resolved from a signed historical snapshot.ubuntu.com index. The signed release metadata, keyring, and raw Launchpad responses are retained with their URLs and SHA-256 digests. Newer source versions are never substituted.

OpenVMM is MIT licensed: retain its notice, but its source does not have to be published merely because it is aggregated with Linux. See THIRD_PARTY_NOTICES.md.