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