Canonical’s Zephyr distribution

To provide long-term support, Canonical forks Zephyr and maintains the Zephyr module repositories and any other repositories required to support or develop Zephyr 4.4.

The LTS distribution stores these sources in Launchpad. Each upstream repository has a corresponding git repository with the same name in the Zephyr RTOS Launchpad project. For example, the upstream sdk-ng has a corresponding Zephyr 26.04 LTS sdk-ng hosted on Launchpad.

The distribution diverges from upstream in the provided west manifest, which is altered to target the distribution’s forks. Canonical publishes the manifest repository with an immutable source tag for each tested source set.

This model preserves the standard multi-repository workflow and yields one source namespace for maintenance changes.

The role of the manifest

A Zephyr workspace contains many repositories. The manifest records their URLs, paths, groups, and revisions.

The manifest revisions form a unified, tested, source set. The aforementioned source tag fixes the manifest repository to this tested set. This way west update keeps repositories aligned, while still allowing one to git pull to move one repository outside the tested set.

Relationship and divergence with upstream

Canonical keeps upstream project names and source structure. This structure preserves familiar upstream concepts, commands, and application layouts.

Canonical can add maintenance patches to each forked repository in accordance with upstream and will continue to patch for the duration of the long-term support offering. The Canonical repository history identifies these changes. The release notes describe changes that affect users.

A central divergence with upstream is the use of a personal package archive (PPA), rather than a Python package index, for Python dependencies. The ppa:arctic-tern/zephyr-toolchain-26.04 provided by Canonical contains the Python dependencies normally installed by pip during pip install -r requirements.txt. However, using the PPA installs all Python dependencies globally rather than in a venv environment. This tradeoff is purposeful; the PPA provides Canonical’s security guarantees for each Python dependency. We recommend that users employ either Docker or LXD containers to mitigate the cost of losing the Python sandbox.

Another divergence with upstream is that Canonical’s distribution patches the VERSION file to match 26.04 rather than 4.4. Similarly, we patch the boot banner to welcome our users to the Canonical distribution.

See also

How-to:

• How to install PPA dependencies in Workshop

Reference:

• Source repositories

• Releases