.. SPDX-License-Identifier: CC-BY-SA-2.0-UK

Release 4.2 (mickledore)
========================

Migration notes for 4.2 (mickledore)
------------------------------------

This section provides migration information for moving to the Yocto
Project 4.2 Release (codename "mickledore") from the prior release.

.. _migration-4.2-supported-distributions:

Supported distributions
~~~~~~~~~~~~~~~~~~~~~~~

This release supports running BitBake on new GNU/Linux distributions:

-  Fedora 36 and 37
-  AlmaLinux 8.7 and 9.1
-  OpenSuse 15.4

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

-  Debian 10.x
-  Fedora 34 and 35
-  AlmaLinux 8.5

See :ref:`all supported distributions <system-requirements-supported-distros>`.

.. _migration-4.2-python-3.8:

Python 3.8 is now the minimum required Python version version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BitBake and OpenEmbedded-Core now require Python 3.8 or newer,
making it a requirement to use a distribution providing at least this
version, or to install a :term:`buildtools` tarball.

.. _migration-4.2-gcc-8.0:

gcc 8.0 is now the minimum required GNU C compiler version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This version, released in 2018, is a minimum requirement
to build the ``mesa-native`` recipe and as the latter is in the
default dependency chain when building QEMU this has now been
made a requirement for all builds.

In the event that your host distribution does not provide this
or a newer version of gcc, you can install a
:term:`buildtools-extended` tarball.

.. _migration-4.2-new-nvd-api:

Fetching the NVD vulnerability database through the 2.0 API
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This new version adds a new fetcher for the NVD database using the 2.0 API,
as the 1.0 API will be retired in 2023.

The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.

Here are minor changes that you may notice:

-  The database starts in 1999 instead of 2002
-  The complete fetch is longer (30 minutes typically)

.. _migration-4.2-rust-crate-checksums:

Rust: mandatory checksums for crates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release now supports checksums for Rust crates and makes
them mandatory for each crate in a recipe. See :yocto_git:`python3_bcrypt recipe changes
</poky/commit/?h=mickledore&id=0dcb5ab3462fdaaf1646b05a00c7150eea711a9a>`
for example.

The ``cargo-update-recipe-crates`` utility
:yocto_git:`has been extended </poky/commit/?h=mickledore&id=eef7fbea2c5bf59369390be4d5efa915591b7b22>`
to include such checksums. So, in case you need to add the list of checksums
to a recipe just inheriting the :ref:`ref-classes-cargo` class so far, you can
follow these steps:

#.  Make the recipe inherit :ref:`ref-classes-cargo-update-recipe-crates`
#.  Remove all ``crate://`` lines from the recipe
#.  Create an empty ``${BPN}-crates.inc`` file and make your recipe require it
#.  Execute ``bitbake -c update_crates your_recipe``
#.  Copy and paste the output of BitBake about the missing checksums into the
    ``${BPN}-crates.inc`` file.


.. _migration-4.2-addpylib:

Python library code extensions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

BitBake in this release now supports a new ``addpylib`` directive to enable
Python libraries within layers.

This directive should be added to your layer configuration
as in the below example from ``meta/conf/layer.conf``::

   addpylib ${LAYERDIR}/lib oe

Layers currently adding a lib directory to extend Python library code should now
use this directive as :term:`BBPATH` is not going to be added automatically by
OE-Core in future. Note that the directives are immediate operations, so it does
make modules available for use sooner than the current BBPATH-based approach.

For more information, see :ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`.


.. _migration-4.2-removed-variables:

Removed variables
~~~~~~~~~~~~~~~~~

The following variables have been removed:

-  ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by :term:`SERIAL_CONSOLES`.
-  ``PACKAGEBUILDPKGD``, a mostly internal variable in the :ref:`ref-classes-package`
   class was rarely used to customise packaging. If you were using this in your custom
   recipes or bbappends, you will need to switch to using :term:`PACKAGE_PREPROCESS_FUNCS`
   or :term:`PACKAGESPLITFUNCS` instead.

.. _migration-4.2-removed-recipes:

Removed recipes
~~~~~~~~~~~~~~~

The following recipes have been removed in this release:

-  ``python3-picobuild``: after switching to ``python3-build``
-  ``python3-strict-rfc3339``: unmaintained and not needed by anything in
   :oe_git:`openembedded-core </openembedded-core>`
   or :oe_git:`meta-openembedded </meta-openembedded>`.
-  ``linux-yocto``: removed version 5.19 recipes (6.1 and 5.15 still provided)


.. _migration-4.2-removed-classes:

Removed classes
~~~~~~~~~~~~~~~

The following classes have been removed in this release:

-  ``rust-bin``: no longer used
-  ``package_tar``: could not be used for actual packaging, and thus not particularly useful.


LAYERSERIES_COMPAT for custom layers and devtool workspace
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Some layer maintainers have been setting :term:`LAYERSERIES_COMPAT` in their
layer's ``conf/layer.conf`` to the value of ``LAYERSERIES_CORENAMES`` to
effectively bypass the compatibility check - this is no longer permitted.
Layer maintainers should set :term:`LAYERSERIES_COMPAT` appropriately to
help users understand the compatibility status of the layer.

Additionally, the :term:`LAYERSERIES_COMPAT` value for the devtool workspace
layer is now set at the time of creation, thus if you upgrade with the
workspace layer enabled and you wish to retain it, you will need to manually
update the :term:`LAYERSERIES_COMPAT` value in ``workspace/conf/layer.conf``
(or remove the path from :term:`BBLAYERS` in ``conf/bblayers.conf`` and
delete/move the ``workspace`` directory out of the way if you no longer
need it).


.. _migration-4.2-runqemu-slirp:

runqemu now limits slirp host port forwarding to localhost
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

With default slirp port forwarding configuration in runqemu, qemu
previously listened on TCP ports 2222 and 2323 on all IP addresses
available on the build host. Most use cases with runqemu only need
it for localhost and it is not safe to run qemu images with root
login without password enabled and listening on all available,
possibly Internet reachable network interfaces. Thus, in this
release we limit qemu port forwarding to localhost (127.0.0.1).

However, if you need the qemu machine to be reachable from the
network, then it can be enabled via ``conf/local.conf`` or machine
config variable ``QB_SLIRP_OPT``::

   QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp::2222-:22"


.. _migration-4.2-patch-qa:

Patch QA checks
~~~~~~~~~~~~~~~

The QA checks for patch fuzz and Upstream-Status have been reworked
slightly in this release. The Upstream-Status checking is now configurable
from :term:`WARN_QA` / :term:`ERROR_QA` (``patch-status-core`` for the
core layer, and ``patch-status-noncore`` for other layers).

The ``patch-fuzz`` and ``patch-status-core`` checks are now in the default
value of :term:`ERROR_QA` so that they will cause the build to fail
if triggered. If you prefer to avoid this you will need to adjust the value
of :term:`ERROR_QA` in your configuration as desired.


.. _migration-4.2-mesa:

Native/nativesdk mesa usage and graphics drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release includes mesa 23.0, and with that mesa release it is not longer
possible to use drivers from the host system, as mesa upstream has added strict
checks for matching builds between drivers and libraries that load them.

This is particularly relevant when running QEMU built within the build
system. A check has been added to runqemu so that there is a helpful error
when there is no native/nativesdk opengl/virgl support available.

To support this, a number of drivers have been enabled when building ``mesa-native``.
The one major dependency pulled in by this change is ``llvm-native`` which will
add a few minutes to the build on a modern machine. If this is undesirable, you
can set the value of :term:`DISTRO_FEATURES_NATIVE` in your configuration such
that ``opengl`` is excluded.


.. _migration-4.2-misc-changes:

Miscellaneous changes
~~~~~~~~~~~~~~~~~~~~~

-  The :term:`IMAGE_NAME` variable is now set based on :term:`IMAGE_LINK_NAME`. This
   means that if you are setting :term:`IMAGE_LINK_NAME` to "" to disable unversioned
   image symlink creation, you also now need to set :term:`IMAGE_NAME` to still have
   a reasonable value e.g.::

      IMAGE_LINK_NAME = ""
      IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"

-  In ``/etc/os-release``, the ``VERSION_CODENAME`` field is now used instead of
   ``DISTRO_CODENAME`` (though its value is still set from the :term:`DISTRO_CODENAME`
   variable) for better conformance to standard os-release usage. If you have runtime
   code reading this from ``/etc/os-release`` it may need to be updated.

-  The kmod recipe now enables OpenSSL support by default in order to support module
   signing. If you do not need this and wish to reclaim some space/avoid the dependency
   you should set :term:`PACKAGECONFIG` in a kmod bbappend (or ``PACKAGECONFIG:pn-kmod``
   at the configuration level) to exclude ``openssl``.

-  The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has been
   removed. It is unlikely that you would have selected to use this, but if you have
   you will need to remove this setting.

-  The :ref:`ref-classes-package` class now checks if package names conflict via
   ``PKG:${PN}`` override during ``do_package``. If you receive the associated error
   you will need to address the :term:`PKG` usage so that the conflict is resolved.

-  openssh no longer uses :term:`RRECOMMENDS` to pull in ``rng-tools``, since rngd
   is no longer needed as of Linux kernel 5.6. If you still need ``rng-tools``
   installed for other reasons, you should add ``rng-tools`` explicitly to your
   image. If you additionally need rngd to be started as a service you will also
   need to add the ``rng-tools-service`` package as that has been split out.

-  The cups recipe no longer builds with the web interface enabled, saving ~1.8M of
   space in the final image. If you wish to enable it, you should set
   :term:`PACKAGECONFIG` in a cups bbappend (or ``PACKAGECONFIG:pn-cups`` at the
   configuration level) to include ``webif``.

-  The :ref:`ref-classes-scons` class now passes a ``MAXLINELENGTH`` argument to
   scons in order to fix an issue with scons and command line lengths when ccache is
   enabled. However, some recipes may be using older scons versions which don't support
   this argument. If that is the case you can set the following in the recipe in order
   to disable this::

      SCONS_MAXLINELENGTH = ""