Yocto Project - User contributions [en]

Recipe Versions

2025-05-06T22:53:50Z

Khem:

This page lists the expected versions of major packages that will be in the next Yocto Project release (Whinlatter 5.3
at the time of writing).

For further details, please contact the relevant maintainer.

{| class="wikitable" style="margin:auto; width:100%"
|-
! Recipe !! Version !! Maintainer !! Notes
|-
| binutils || 2.45 || Khem Raj <raj.khem@gmail.com> || Should be locked by M1
|-
| gcc || 15.2 || Khem Raj <raj.khem@gmail.com> || GCC 15 in master now
|-
| glibc || 2.42 || Khem Raj <raj.khem@gmail.com> || Should be locked by M1
|-
| linux-yocto || v6.12 & unknown || Bruce Ashfield <bruce.ashfield@gmail.com> || Should be locked by M2
|-
| python3 || 3.13.3 || Trevor Gamblin <tgamblin@baylibre.com> || Should be locked by M2
|}

Key recipe versions by release, (LTS and current release only)

{| class="wikitable" style="margin:auto; width:100%"
|-
! Release || linux-yocto (kernel) || gcc || binutils || glibc || python3
|-
| walnasacar (5.2) || 6.12.x || 14.2 || 2.44 || 2.41 || 3.13.x
|-
| scarthgap (5.0) || 6.6.x || 13.2 || 2.42 || 2.39 || 3.12.x
|-
| kirkstone (4.0) || 5.10.x / 5.15.x || 11.4 || 2.38 || 2.35 || 3.10.x
|-
| dunfell (3.1) || 5.4.x || 9.5 || 2.34 ||2.31 || 3.8.x
|}

Recipe Versions

2025-05-06T22:50:29Z

Khem:

This page lists the expected versions of major packages that will be in the next Yocto Project release (Whinlatter 5.3
at the time of writing).

For further details, please contact the relevant maintainer.

{| class="wikitable" style="margin:auto; width:100%"
|-
! Recipe !! Version !! Maintainer !! Notes
|-
| binutils || 2.45 || Khem Raj <raj.khem@gmail.com> || Should be locked by M1
|-
| gcc || 15.2 || Khem Raj <raj.khem@gmail.com> || GCC 15 in master now
|-
| glibc || 2.42 || Khem Raj <raj.khem@gmail.com> || Should be locked by M1
|-
| linux-yocto || v6.12 & unknown || Bruce Ashfield <bruce.ashfield@gmail.com> || Should be locked by M2
|-
| python3 || 3.13.3 || Trevor Gamblin <tgamblin@baylibre.com> || Should be locked by M2
|}

Key recipe versions by release, (LTS and current release only)

{| class="wikitable" style="margin:auto; width:100%"
|-
! Release || linux-yocto (kernel) || gcc || binutils || glibc || python3
|-
| walnasac (5.2) || 6.12.x || 14.2 || 2.44 || 2.41 || 3.13.x
|-
| scarthgap (5.0) || 6.6.x || 13.2 || 2.42 || 2.39 || 3.12.x
|-
| kirkstone (4.0) || 5.10.x / 5.15.x || 11.4 || 2.38 || 2.35 || 3.10.x
|-
| dunfell (3.1) || 5.4.x || 9.5 || 2.34 ||2.31 || 3.8.x
|}

Meta-gpl2 layer replacement

2024-08-12T20:30:42Z

Khem: /* What's the way out? */

== Options for meta-gpl2 layer replacement ==

meta-gpl2 was created to supply recipe metadata for GPL-2.0 version of OSS components/recipes which have migrated to use GPL-3.0 family of license. Therefore the versions for these components were frozen in time ( circa 2007 ), these components were still receiving security fixes and sundry other minor fixes while they were part of long term supported ( LTS ) binary distributions e.g. ubuntu and CentOS and Debian. Therefore keeping them in healthy state was still possible until these LTS releases of distributions went EOL, which meant that these components stopped receiving any updates and hence became hard to maintain over time

New compiler versions would find new bugs ( build time issues ) which are otherwise fixed in the regular version, the backports are no longer straightforward and have license issues anyway.
No security fixes being applied anymore
Consistently, requiring platform porting e.g. mingw

Therefore it is not recommended to use meta-gpl2 anymore as it is quite problematic. It also sends out a bad message to your own userbase as it implies you are disregarding security issues and as such can cause reputation damage. Whilst it has not been recommended for many years, it has been completely dropped by the Yocto Project after the kirkstone release so the most recent LTS (scarthgap) does not support it.

=== What's the way out? ===

* Move to use a maintained version of the components if possible, which could be allowed per legal policies of your company, please discuss with them.
* Find alternative implementations for similar functionality e.g. readline vs libedit, however this might need API adjustments. Some of coreutils components can be replaced with busybox applets or new project uutils-coreutils https://github.com/uutils/coreutils, bsdutils - https://github.com/dcantrell/bsdutils or chimerautils - https://github.com/chimera-linux/chimerautils
* Change recipes to use PACKAGECONFIGs for such functionality which can safely avoid linking to GPL-3.0 code.
* Selectively remove components from images which have such dependencies. E.g. see meta/lib/oeqa/selftest/cases/incompatible_lic.py
* Switch to checking images for problematic content rather than disabling entire recipes globally. Our license markup of individual packages should be accurate.

=== Start with marking images with below restrictions ===

INCOMPATIBLE_LICENSE:pn-core-image-full-cmdline = "GPL-3.0 LGPL-3.0"

And remove dependencies if not needed or find replacements if available.

For running ptests, lot of recipes need bash, that was the reason ptests were explicitly removed by meta-gpl2, therefore it might be not easy to replace bash with another shell e.g. dash or tcsh
However, it's limited to testing and production builds can still resort to avoiding bash shell from target images.

See following commit for an example: https://git.yoctoproject.org/poky/commit/?id=ebee9854d735bf6321020e791ca84389dc91834b

=== TLS ===

Lot of packages need a TLS dependency and there are multiple providers for TLS implementation, however, some packages use gnutls as default backend and hence a dependency. Some packages
Do provide an option to use other implementations e.g. openssl provided TLS or NSS, therefore such packages should be made to provide this choice via PACKAGECONFIG. The packageconfigs can
Then be set to no-defaults via distributions. A good example

https://git.yoctoproject.org/poky/tree/meta/recipes-extended/wget/wget.inc#n30

=== Code Generator Tools ===

Tools like gettext, bison, m4, patch are used during build mostly. Assessing how they are used in your case can pave a way forward to use their currently maintained versions. The usecases can be discussed with the policy teams of your company based upon how they are used.

=== Multiple providers ===

Packages like libiconv provide components that are already provided by glibc or musl C library, however, they maybe needed on supporting platforms like mingw and Yocto project supports Mingw for
Build and SDK host therefore it will be used in host and not shipped on target software. Therefore the scope of such a package is reduced and is applicable to specific usecases alone.

=== Unchanged License ===

Certain packages e.g. shared-mime-info are still under GPL-2.0 license, the reason to house an older version in meta-gpl2 was to support other old packages.

=== Work so far: ===

Created a global policy file:

https://git.yoctoproject.org/poky/tree/meta/conf/distro/include/no-gplv3.inc

as distro config metadata could help the community to start with a known set of packages and packageconfig and other metadata tweaks. This file can be included in global config metadata and distribution built on top of it.

=== Future work needed: ===

* Find scalable replacement for bash so ptest can be enabled
* readline being gpl3, editline as alternative?
* Gdbserver is GPLv3 causing issues for debug images, lldb-server is an alternative
* Gnupg is used by package managers e.g. dnf, using alternative package manager or using alternative GPG implementation e.g. minisign/libsodium, https://gitlab.com/sequoia-pgp/sequoia ?
* Elfutils could be replaced by LLVM tools
* Document best practices once identified in project manuals
* Distro policy to govern TLS preferences?

Meta-gpl2 layer replacement

2024-07-31T15:37:00Z

Khem: /* What's the way out? */

== Options for meta-gpl2 layer replacement ==

meta-gpl2 was created to supply recipe metadata for GPL-2.0 version of OSS components/recipes which have migrated to use GPL-3.0 family of license. Therefore the versions for these components were frozen in time ( circa 2007 ), these components were still receiving security fixes and sundry other minor fixes while they were part of long term supported ( LTS ) binary distributions e.g. ubuntu and CentOS and Debian. Therefore keeping them in healthy state was still possible until these LTS releases of distributions went EOL, which meant that these components stopped receiving any updates and hence became hard to maintain over time

New compiler versions would find new bugs ( build time issues ) which are otherwise fixed in the regular version, the backports are no longer straightforward and have license issues anyway.
No security fixes being applied anymore
Consistently, requiring platform porting e.g. mingw

Therefore it is not recommended to use meta-gpl2 anymore as it is quite problematic. It also sends out a bad message to your own userbase as it implies you are disregarding security issues and as such can cause reputation damage. Whilst it has not been recommended for many years, it has been completely dropped by the Yocto Project after the kirkstone release so the most recent LTS (scarthgap) does not support it.

=== What's the way out? ===

* Move to use a maintained version of the components if possible, which could be allowed per legal policies of your company, please discuss with them.
* Find alternative implementations for similar functionality e.g. readline vs libedit, however this might need API adjustments. Some of coreutils components can be replaced with busybox applets or new project uutils-coreutils https://github.com/uutils/coreutils
* Change recipes to use PACKAGECONFIGs for such functionality which can safely avoid linking to GPL-3.0 code.
* Selectively remove components from images which have such dependencies. E.g. see meta/lib/oeqa/selftest/cases/incompatible_lic.py
* Switch to checking images for problematic content rather than disabling entire recipes globally. Our license markup of individual packages should be accurate.

=== Start with marking images with below restrictions ===

INCOMPATIBLE_LICENSE:pn-core-image-full-cmdline = "GPL-3.0 LGPL-3.0"

And remove dependencies if not needed or find replacements if available.

For running ptests, lot of recipes need bash, that was the reason ptests were explicitly removed by meta-gpl2, therefore it might be not easy to replace bash with another shell e.g. dash or tcsh
However, it's limited to testing and production builds can still resort to avoiding bash shell from target images.

See following commit for an example: https://git.yoctoproject.org/poky/commit/?id=ebee9854d735bf6321020e791ca84389dc91834b

=== TLS ===

Lot of packages need a TLS dependency and there are multiple providers for TLS implementation, however, some packages use gnutls as default backend and hence a dependency. Some packages
Do provide an option to use other implementations e.g. openssl provided TLS or NSS, therefore such packages should be made to provide this choice via PACKAGECONFIG. The packageconfigs can
Then be set to no-defaults via distributions. A good example

https://git.yoctoproject.org/poky/tree/meta/recipes-extended/wget/wget.inc#n30

=== Code Generator Tools ===

Tools like gettext, bison, m4, patch are used during build mostly. Assessing how they are used in your case can pave a way forward to use their currently maintained versions. The usecases can be discussed with the policy teams of your company based upon how they are used.

=== Multiple providers ===

Packages like libiconv provide components that are already provided by glibc or musl C library, however, they maybe needed on supporting platforms like mingw and Yocto project supports Mingw for
Build and SDK host therefore it will be used in host and not shipped on target software. Therefore the scope of such a package is reduced and is applicable to specific usecases alone.

=== Unchanged License ===

Certain packages e.g. shared-mime-info are still under GPL-2.0 license, the reason to house an older version in meta-gpl2 was to support other old packages.

=== Work so far: ===

Created a global policy file:

https://git.yoctoproject.org/poky/tree/meta/conf/distro/include/no-gplv3.inc

as distro config metadata could help the community to start with a known set of packages and packageconfig and other metadata tweaks. This file can be included in global config metadata and distribution built on top of it.

=== Future work needed: ===

* Find scalable replacement for bash so ptest can be enabled
* readline being gpl3, editline as alternative?
* Gdbserver is GPLv3 causing issues for debug images, lldb-server is an alternative
* Gnupg is used by package managers e.g. dnf, using alternative package manager or using alternative GPG implementation e.g. minisign/libsodium, https://gitlab.com/sequoia-pgp/sequoia ?
* Elfutils could be replaced by LLVM tools
* Document best practices once identified in project manuals
* Distro policy to govern TLS preferences?

How to enable KVM for Poky qemu

2017-06-08T18:20:38Z

Khem: /* Change the kvm dev ownership for non-root user */

= enable KVM for poky qemu =
== KVM introduction ==

''KVM'' (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, '''kvm.ko''', that provides the core virtualization infrastructure and a processor specific module, '''kvm-intel.ko''' or kvm-amd.ko. KVM also requires a modified QEMU although work is underway to get the required changes upstream.

Compared with native qemu, a pure emulator, KVM has better performance based on virtualization as most of guest instruction can be executed directly on the host processor.

== detect VT support ==
You need make sure your x86 processor support VT before using KVM.

With a recent enough Linux kernel, run the command:

$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.

* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.

In case of doubt, contact your hardware vendor.

== get the KVM module ==

The quick & easy way for this is just using it from your distribution. As of now, all major community and enterprise distributions contain kvm kernel modules; these are either installed by default or require installing a kvm package. For someone looking for stability, these are the best choice. No effort is needed to build or install the modules, support is provided by the distribution, and the distribution/module combination is well tested.

In other cases, you need refer [http://www.linux-kvm.org/page/Getting_the_kvm_kernel_modules getting kvm modules].

After getting the modules, you can install them into kernel by

$ sudo modprobe kvm-intel

== make KVM aware QEMU ==
Upstream QEMU has already supported KVM, and I have already checked in one patch to enable it. So you get a KVM capable qemu after poky build.

== Change the kvm dev ownership for non-root user ==
qemu is started as non-root user in poky, but ''/dev/kvm'' from some distribution remains root:root that only allow root to use KVM. To work around this, we need create a new group named '''kvm''', and make both ''/dev/kvm'' and the non-root user belongs to it.

sudo groupadd --system kvm
sudo gpasswd -a $USER kvm
sudo chown root:kvm /dev/kvm
sudo chmod 0660 /dev/kvm

The output of "ls -l /dev/kvm" should be like this:
crw-rw----+ 1 root kvm 10, 232 2010-07-02 09:27 /dev/kvm

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to /etc/udev/rules.d/40-permissions.rules).

KERNEL=="kvm", GROUP="kvm", MODE="0660"

Note
* You need log out then log in the non-root user to take the effect
* Some distributions have already made this, so that we can skip this step

== running qemu with KVM enabled ==
just append "kvm" parameter to the ''runqemu'' like this

$ runqemu qemux86 kvm

How to enable KVM for Poky qemu

2013-03-29T08:13:04Z

Khem: /* Change the kvm dev ownership for non-root user */

= enable KVM for poky qemu =
== KVM introduction ==

''KVM'' (for Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel module, '''kvm.ko''', that provides the core virtualization infrastructure and a processor specific module, '''kvm-intel.ko''' or kvm-amd.ko. KVM also requires a modified QEMU although work is underway to get the required changes upstream.

Compared with native qemu, a pure emulator, KVM has better performance based on virtualization as most of guest instruction can be executed directly on the host processor.

== detect VT support ==
You need make sure your x86 processor support VT before using KVM.

With a recent enough Linux kernel, run the command:

$ egrep '^flags.*(vmx|svm)' /proc/cpuinfo

If something shows up, you have VT. You can also check the processor model name (in `/proc/cpuinfo`) in the vendor's web site.

Note:

* You'll never see (vmx|svm) in /proc/cpuinfo if you're currently running in in a dom0 or domU. The Xen hypervisor suppresses these flags in order to prevent hijacking.

* Some manufacturers disable VT in the machine's BIOS, in such a way that it cannot be re-enabled.

* `/proc/cpuinfo` only shows virtualization capabilities starting with Linux 2.6.15 (Intel) and Linux 2.6.16 (AMD). Use the `uname -r` command to query your kernel version.

In case of doubt, contact your hardware vendor.

== get the KVM module ==

The quick & easy way for this is just using it from your distribution. As of now, all major community and enterprise distributions contain kvm kernel modules; these are either installed by default or require installing a kvm package. For someone looking for stability, these are the best choice. No effort is needed to build or install the modules, support is provided by the distribution, and the distribution/module combination is well tested.

In other cases, you need refer [http://www.linux-kvm.org/page/Getting_the_kvm_kernel_modules getting kvm modules].

After getting the modules, you can install them into kernel by

$ sudo modprobe kvm-intel

== make KVM aware QEMU ==
Upstream QEMU has already supported KVM, and I have already checked in one patch to enable it. So you get a KVM capable qemu after poky build.

== Change the kvm dev ownership for non-root user ==
qemu is started as non-root user in poky, but ''/dev/kvm'' from some distribution remains root:root that only allow root to use KVM. To work around this, we need create a new group named '''kvm''', and make both ''/dev/kvm'' and the non-root user belongs to it.

sudo addgroup --system kvm
sudo adduser $USER kvm
sudo chown root:kvm /dev/kvm
sudo chmod 0660 /dev/kvm

The output of "ls -l /dev/kvm" should be like this:
crw-rw----+ 1 root kvm 10, 232 2010-07-02 09:27 /dev/kvm

On a system that runs udev, you will probably need to add the following line somewhere in your udev configuration so it will automatically give the right group to the newly created device (i-e for ubuntu add a line to /etc/udev/rules.d/40-permissions.rules).

KERNEL=="kvm", GROUP="kvm"

Note
* You need log out then log in the non-root user to take the effect
* Some distributions have already made this, so that we can skip this step

== running qemu with KVM enabled ==
just append "kvm" parameter to the ''poky-qemu'' like this

$ poky-qemu qemux86 kvm