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