123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276 |
- .. 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 = ""
|