Migration notes for 6.0 (wrynose)

This section provides migration information for moving to the Yocto Project 6.0 Release (codename “wrynose”) from the prior release. For a list of new features and enhancements, see the Release notes for 6.0 (wrynose) section.

The 6.0 (wrynose) release is the new LTS release after 5.0 (scarthgap). If you are migrating from the 5.0 version, be sure to read the previous migration guides:

See also the list of new features and enhancements of the previous releases:

Supported kernel versions

The OLDEST_KERNEL setting is 5.15 in this release, meaning that out the box, older kernels are not supported. See 4.3 migration notes for details.

Supported distributions

Compared to the previous releases, running BitBake is supported on new GNU/Linux distributions:

  • Fedora 43

  • openSUSE Leap 16.0

  • Ubuntu 26.04 (LTS)

On the other hand, some earlier distributions are no longer supported:

  • Fedora 39

  • Fedora 40

  • Fedora 41

  • openSUSE Leap 15.5

See all supported distributions.

BitBake fetcher removals

The following BitBake fetchers have been disabled or removed:

  • The npm and npmsw (NPM) fetchers were disabled due to security concerns (355cd22) and lack of maintenance.

    All associated tests have been disabled.

  • Support for the Bazaar fetcher was dropped (8e057d5).

  • Support for the OSC fetcher was dropped (99497c1).

  • Support for the CVS fetcher was dropped (5427500).

Default INIT_MANAGER definition changed to systemd

The default definition of INIT_MANAGER in the defaultsetup.conf file was changed from none to systemd.

This means that users of the default distro setup (appearing as the nodistro DISTRO) will be using systemd as the default init manager.

This does not change the default init manager of the Poky distribution, which remains SysVinit.

Reverting to SysVinit can be done by specifying the INIT_MANAGER in your own DISTRO configuration file:

INIT_MANAGER = "sysvinit"

See commit 0b4061c for more information.

Changes in how default DISTRO_FEATURES and MACHINE_FEATURES are provided

The way default DISTRO_FEATURES and MACHINE_FEATURES are provided by the OpenEmbedded Build System has changed.

The DISTRO_FEATURES_BACKFILL, DISTRO_FEATURES_BACKFILL_CONSIDERED, DISTRO_FEATURES_DEFAULT, MACHINE_FEATURES_BACKFILL and MACHINE_FEATURES_BACKFILL_CONSIDERED variables are now obsolete.

Instead, these are replaced by the DISTRO_FEATURES_DEFAULTS, DISTRO_FEATURES_OPTED_OUT, MACHINE_FEATURES_DEFAULTS and MACHINE_FEATURES_OPTED_OUT variables.

Users are advised to migrate to these variables the following way:

  • For DISTRO_FEATURES:

    • If you have previously assigned DISTRO_FEATURES without using DISTRO_FEATURES_DEFAULT, you will now get the default features added automatically (from DISTRO_FEATURES_DEFAULTS). You will need to review these and add any features you do not want to use to DISTRO_FEATURES_OPTED_OUT.

    • DISTRO_FEATURES_DEFAULT is now unused, the new variable name is slightly different (DISTRO_FEATURES_DEFAULTS) to ensure that it is not accidentally used if a layer hasn’t been modified to adapt to the new naming.

    • If you previously set DISTRO_FEATURES_BACKFILL_CONSIDERED, use the new DISTRO_FEATURES_OPTED_OUT variable instead.

    • If you previously modified DISTRO_FEATURES_BACKFILL, remove these assignments and follow the above instructions.

  • For MACHINE_FEATURES:

See commit 159148f and 3194d68 for more information.

Changes to the list of DISTRO_FEATURES enabled by default

The following DISTRO_FEATURES are now enabled by default in meta/conf/bitbake.conf:

  • multiarch: Enable building applications with multiple architecture support.

  • opengl: Include the Open Graphics Library, which is a cross-language multi-platform application programming interface used for rendering two and three-dimensional graphics.

  • ptest: Enable building the package tests where supported by individual recipes. To add the built ptest packages to the image, add ptest-pkgs to IMAGE_FEATURES in your image recipe.

  • vulkan: Include support for the Vulkan API.

  • wayland: Include the Wayland display server protocol and the library that supports it.

See commit 2e1e7c8 for more information.

Default configuration templates removed from meta-poky

The configuration templates located in meta-poky/conf/templates/default have been removed as they are now provided in a single location: OpenEmbedded-Core (OE-Core) meta/conf/templates/default.

These files were duplicating themselves but were mostly similar.

See commit ac300ba for more information on the differences there are between the two sets of default templates.

native and cross classes DEBUG_BUILD change

Previously, setting DEBUG_BUILD to “1” globally would prevent the OpenEmbedded Build System from stripping target, native and cross binaries. This was changed so that only target binaries are stripped when this variable is set.

This change can be reverted by setting the two following lines in a configuration file:

INHIBIT_SYSROOT_STRIP:class-cross = "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"
INHIBIT_SYSROOT_STRIP:class-native = "${@oe.utils.vartrue('DEBUG_BUILD', '1', '', d)}"

See commit 3c29afe for more information.

U-Boot configuration flow changes (uboot-config)

Declaring multiple U-Boot configurations used to be entirely defined by one UBOOT_CONFIG variable flag per configuration, e.g.:

UBOOT_CONFIG ??= "foo bar"
UBOOT_CONFIG[foo] = "config,images,binary"
UBOOT_CONFIG[bar] = "config2,images2,binary2"

This has now been split into more variable flags, e.g.:

UBOOT_CONFIG ??= "foo bar"
UBOOT_CONFIG[foo] = "config"
UBOOT_CONFIG[bar] = "config2"

UBOOT_CONFIG_IMAGE_FSTYPES[bar] = "fstype"

UBOOT_CONFIG_BINARY[foo] = "binary"

UBOOT_CONFIG_MAKE_OPTS[foo] = "FOO=1"
UBOOT_CONFIG_MAKE_OPTS[bar] = "BAR=1"

UBOOT_CONFIG_FRAGMENTS[foo] = "foo.fragment"

See the documentation of the uboot-config for full details.

While the previous legacy approach is still supported, it will be removed in for the next release. Users are advised to migrate to the new approach.

See commit cd9e730 for more information.

Note

Single configuration builds have not changed and are still declared using the following statements:

UBOOT_MACHINE = "config"
UBOOT_BINARY = "u-boot.bin"

vex output JSON document extension change

Image recipes that inherit the vex class have an extra JSON document generated which was previous ending with the .json suffix. For example, a build for the core-image-minimal image recipe with this class would have resulted in a file named:

core-image-minimal-qemuarm64.rootfs.json

The suffix of this file is now .vex.json. Taking the above example, the same file is now named:

core-image-minimal-qemuarm64.rootfs.vex.json

Support for SPDX 2.2 removed

Support for generating SPDX 2.2 document through the create-spdx-2.2 class was removed:

Removes SPDX 2.2 support in favor of SPDX 3 support being the only
option. The SPDX 3 data is far superior to SPDX 2.2 and thus more useful
for SBoM uses cases.

See commit 12abd05 for more information.

Users are advised to transition to SDPX 3.0, which is provided by the create-spdx class.

cve-check class removed

The cve-check class was removed and replaced by the sbom-cve-check class. Quoting the commit removing the class (00de455):

It's been long known that the cve-check class in oe-core is not that
usable in the real world, for more details see "Future of CVE scanning
in Yocto"[1].  This mail proposed an alternative direction that included
a CVE scanning tool that can be ran both during the build and afterwards,
so that periodic scans of a previously build image is possible.

Last year, Bootlin wrote sbom-cve-check[2] and I compared this to my
proposal in "Comparing cve-check with sbom-cve-check"[3], concluding
that this is likely the missing piece.

Support for sbom-cve-check has been merged into oe-core, and the
cve-check class is now obsolete. So that we don't have to maintain it for
the four-year lifecycle of the Wrynose release, delete it.

This patch also deletes the database fetcher recipes, and the test cases
that were specific to cve-check.  Note that the oe.cve_check library
still exists as this is used by the SPDX classes.

[1] https://lore.kernel.org/openembedded-core/7D6E419E-A7AE-4324-966C-3552C586E452@arm.com/
[2] https://github.com/bootlin/sbom-cve-check
[3] https://lore.kernel.org/openembedded-core/2CD10DD9-FB2A-4B10-B98A-85918EB6B4B7@arm.com/

Users currently using the cve-check class are advised to switch to sbom-cve-check:

  • The following assignment:

    INHERIT += "cve-check"

    Should be removed and replaced by:

    OE_FRAGMENTS += "core/yocto/sbom-cve-check"

    This will enable the sbom-cve-check class along with the recommended settings.

    This will deploy two files to the deployment directory (DEPLOY_DIR_IMAGE) after building an image:

    • A file ending with .sbom-cve-check.yocto.json: this is the output JSON report in the same format as the one deployed by the cve-check class.

    • A file ending with .sbom-cve-check.spdx.json: this is an output SPDX report annonated with vulnerable CVEs.

  • The cve-check class output summary file (deployed in the DEPLOY_DIR_IMAGE) ending with .cve.txt is no longer deployed by default but can be added back by adding the following statement to a configuration file:

    SBOM_CVE_CHECK_EXPORT_VARS:append = " SBOM_CVE_CHECK_EXPORT_SUMMARY"

    This will deploy a new file ending with .cve.txt, which uses the same format as the summary previously deployed by the cve-check class.

    See the documentation of SBOM_CVE_CHECK_EXPORT_VARS for more details.

  • The CVE_CHECK_SHOW_WARNINGS variable, which was used to control whether the cve-check would print warning when unpatched CVEs were found, is now removed and replaced by the SBOM_CVE_CHECK_SHOW_WARNINGS variable, which does the same.

See the Checking for Vulnerabilities section of the Yocto Project Security Manual for more information.

CVE_PRODUCT character escaping change

The CVE_PRODUCT variable, which specifies a name used to match the recipe name against the name in the upstream NIST CVE database, used to require special characters to be escaped.

This is no longer, the case. For example, the CVE_PRODUCT variable for the webkitgtk recipe must no longer be written as webkitgtk\+ but webkitgtk+.

Users are advised to review their CVE_PRODUCT assignments and remove any special character escaping.

WIC_SECTOR_SIZE should be replaced by --sector-size

The WIC_SECTOR_SIZE variable was previously used to define the sector size of the partitions generated by the WIC tool. The wic command-line tool now supports a --sector-size argument that replaces this variable.

While this variable can still be used in recipes, a warning is now printed on the console when used:

DEPRECATED: WIC_SECTOR_SIZE is deprecated, use the --sector-size command-line argument instead.

Using the --sector-size command-line argument can be done through the WIC_CREATE_EXTRA_ARGS variable.

For example, a previous assignment to WIC_SECTOR_SIZE:

WIC_SECTOR_SIZE = "4096"

Should be replaced by:

WIC_CREATE_EXTRA_ARGS += "--sector-size 4096"

See commit b50d6de for more information.

WIC files to be moved under files/wic

WIC related files such as WKS files or custom WIC plugins should be moved to the files/wic/ directory of the layer containing them.

If not done, the build will fail with errors indicating how to move these files, for example:

wic/wks files at ../meta-custom/wic need to be moved to files/wic within the layer to be found/used
wic/wks files at ../meta-custom/scripts/lib/wic/canned-wks need to be moved to files/wic within the layer to be found/used

For example, here is the content of the OpenEmbedded-Core (OE-Core) “meta” layer as of writing:

meta/files/wic
├── common.wks.inc
├── directdisk-bootloader-config.cfg
├── directdisk-bootloader-config.wks
├── directdisk-gpt.wks
├── directdisk-multi-rootfs.wks
├── directdisk.wks
├── efi-bootdisk.wks.in
├── efi-uki-bootdisk.wks.in
├── mkefidisk.wks
├── mkhybridiso.wks
├── qemuloongarch.wks
├── qemuriscv.wks
├── qemux86-directdisk.wks
├── sdimage-bootpart.wks
└── systemd-bootdisk.wks

Support for SysVinit compatibility in systemd was dropped

Support for the SysVinit compatibility in systemd was dropped.

This is due to recent announcements in systemd which is planning to drop support for the SysVinit compatibility.

This means that the systemd and sysvinit distro features cannot be used together anymore.

Users are advised to switch to one init manager or the other entirely.

See commit d9ec9e2 for more information.

Removed recipes

The following recipes have been removed in this release:

  • jquery: The last users of this recipe were the reproducible tests, but have been reworked to use the jQuery CDN instead with d3ee549 (See aae793a)

  • systemd-compat-units: Dropped as a consequence of removing SysVinit support in systemd (d9ec9e2)

  • gstreamer1.0-vaapi: removed as it was already provided by the va PACKAGECONFIG item of gstreamer1.0-plugins-bad. (9e2d2a5)

  • pkgconfig: replaced by the pkgconf recipe (e32bf38)

  • python3-pyzstd: there were no users of this in OpenEmbedded-Core (OE-Core) and Python 3.14 now has built-in support for zstd (55061de)

  • cve-update-db-native, cve-update-nvd2-native: removed with the cve-check class removal as it was the only user of these recipes. (00de455)

  • python3-roman-numerals-py: renamed to python3-roman-numerals (faff756)

Removed PACKAGECONFIG options

Removed classes

The following classes have been removed in this release:

  • oelint: remove as most of the checks done by this class are done in other areas of code now, making this class obsolete.

Miscellaneous changes

  • meson: drop meson_do_qa_configure as it was non-functional (0514b45)

  • Drop VSCode setup support from the oe-init-build-env script. Users are advised to use bitbake-setup instead (4e781c6)