1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK 2 3Release 3.3 (hardknott) 4======================= 5 6This section provides migration information for moving to the Yocto 7Project 3.3 Release (codename "hardknott") from the prior release. 8 9 10.. _migration-3.3-minimum-system-requirements: 11 12Minimum system requirements 13--------------------------- 14 15You will now need at least Python 3.6 installed on your build host. Most recent 16distributions provide this, but should you be building on a distribution that 17does not have it, you can use the :term:`buildtools` tarball (easily installable 18using ``scripts/install-buildtools``) --- see 19:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions` 20for details. 21 22.. _migration-3.3-removed-recipes: 23 24Removed recipes 25--------------- 26 27The following recipes have been removed: 28 29- ``go-dep``: obsolete with the advent of go modules 30- ``gst-validate``: replaced by ``gst-devtools`` 31- ``linux-yocto``: removed 5.8 version recipes (5.4 / 5.10 still provided) 32- ``vulkan-demos``: replaced by ``vulkan-samples`` 33 34 35.. _migration-3.3-common-license-only-versions: 36 37Single version common license file naming 38----------------------------------------- 39 40Some license files in ``meta/files/common-licenses`` have been renamed to match 41current SPDX naming conventions: 42 43- AGPL-3.0 -> AGPL-3.0-only 44- GPL-1.0 -> GPL-1.0-only 45- GPL-2.0 -> GPL-2.0-only 46- GPL-3.0 -> GPL-3.0-only 47- LGPL-2.0 -> LGPL-2.0-only 48- LGPL-2.1 -> LGPL-2.1-only 49- LGPL-3.0 -> LGPL-3.0-only 50 51Additionally, corresponding "-or-later" suffixed files have been added e.g. 52``GPL-2.0-or-later``. 53 54It is not required that you change :term:`LICENSE` values as there are mappings 55from the original names in place; however, in rare cases where you have a recipe 56which sets :term:`LIC_FILES_CHKSUM` to point to file(s) in 57``meta/files/common-licenses`` (which in any case is not recommended) you will 58need to update those. 59 60 61.. _migration-3.3-python3targetconfig: 62 63New ``python3targetconfig`` class 64--------------------------------- 65 66A new :ref:`ref-classes-python3targetconfig` class has 67been created for situations where you would previously have inherited the 68:ref:`ref-classes-python3native` class but need access to 69target configuration data (such as correct installation directories). Recipes 70where this situation applies should be changed to inherit 71:ref:`ref-classes-python3targetconfig` instead of 72:ref:`ref-classes-python3native`. This also adds a dependency 73on target ``python3``, so it should only be used where appropriate in order to 74avoid unnecessarily lengthening builds. 75 76Some example recipes where this change has been made: ``gpgme``, ``libcap-ng``, 77``python3-pycairo``. 78 79 80.. _migration-3.3-distutils-path: 81 82``setup.py`` path for Python modules 83------------------------------------ 84 85In a Python module, sometimes ``setup.py`` can be buried deep in the 86source tree. Previously this was handled in recipes by setting :term:`S` to 87point to the subdirectory within the source where ``setup.py`` is located. 88However with the recent :ref:`pseudo <overview-manual/concepts:fakeroot and pseudo>` 89changes, some Python modules make changes to files beneath ``${S}``, for 90example:: 91 92 S = "${WORKDIR}/git/python/pythonmodule" 93 94then in ``setup.py`` it works with source code in a relative fashion, such 95as ``../../src``. This causes pseudo to fail as it isn't able to track 96the paths properly. This release introduces a new ``DISTUTILS_SETUP_PATH`` 97variable so that recipes can specify it explicitly, for example:: 98 99 S = "${WORKDIR}/git" 100 DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule" 101 102Recipes that inherit from ``distutils3`` (or :ref:`ref-classes-setuptools3` 103which itself inherits ``distutils3``) that also set :term:`S` to point to a 104Python module within a subdirectory in the aforementioned manner should be 105changed to set ``DISTUTILS_SETUP_PATH`` instead. 106 107 108.. _migration-3.3-bitbake: 109 110BitBake changes 111--------------- 112 113- BitBake is now configured to use a default ``umask`` of ``022`` for all tasks 114 (specified via a new :term:`BB_DEFAULT_UMASK` variable). If needed, ``umask`` can 115 still be set on a per-task basis via the ``umask`` varflag on the task 116 function, but that is unlikely to be necessary in most cases. 117 118- If a version specified in :term:`PREFERRED_VERSION` is not available this 119 will now trigger a warning instead of just a note, making such issues more 120 visible. 121 122 123.. _migration-3.3-packaging: 124 125Packaging changes 126----------------- 127 128The following packaging changes have been made; in all cases the main package 129still depends upon the split out packages so you should not need to do anything 130unless you want to take advantage of the improved granularity: 131 132- ``dbus``: ``-common`` and ``-tools`` split out 133- ``iproute2``: split ``ip`` binary to its own package 134- ``net-tools``: split ``mii-tool`` into its own package 135- ``procps``: split ``ps`` and ``sysctl`` into their own packages 136- ``rpm``: split build and extra functionality into separate packages 137- ``sudo``: split ``sudo`` binary into ``sudo-sudo`` and libs into ``sudo-lib`` 138- ``systemtap``: examples, Python scripts and runtime material split out 139- ``util-linux``: ``libuuid`` has been split out to its own 140 ``util-linux-libuuid`` recipe (and corresponding packages) to avoid circular 141 dependencies if ``libgcrypt`` support is enabled in ``util-linux``. 142 (``util-linux`` depends upon ``util-linux-libuuid``.) 143 144 145.. _migration-3.3-misc: 146 147Miscellaneous changes 148--------------------- 149 150- The default poky :term:`DISTRO_VERSION` value now uses the core metadata's 151 git hash (i.e. :term:`METADATA_REVISION`) rather than the date (i.e. 152 :term:`DATE`) to reduce one small source of non-reproducibility. You can 153 of course specify your own :term:`DISTRO_VERSION` value as desired 154 (particularly if you create your own custom distro configuration). 155- ``adwaita-icon-theme`` version 3.34.3 has been added back, and is selected 156 as the default via :term:`PREFERRED_VERSION` in 157 ``meta/conf/distro/include/default-versions.inc`` due to newer versions 158 not working well with ``librsvg`` 2.40. ``librsvg`` is not practically 159 upgradeable at the moment as it has been ported to Rust, and Rust is not 160 (yet) in OE-Core, but this will change in a future release. 161- ``ffmpeg`` is now configured to disable GPL-licensed portions by default 162 to make it harder to accidentally violate the GPL. To explicitly enable GPL 163 licensed portions, add ``gpl`` to :term:`PACKAGECONFIG` for ``ffmpeg`` 164 using a bbappend (or use ``PACKAGECONFIG_append_pn-ffmpeg = " gpl"`` in 165 your configuration.) 166- ``connman`` is now set to conflict with ``systemd-networkd`` as they 167 overlap functionally and may interfere with each other at runtime. 168- Canonical SPDX license names are now used in image license manifests in 169 order to avoid aliases of the same license from showing up together (e.g. 170 ``GPLv2`` and ``GPL-2.0``) 171