diff options
Diffstat (limited to 'poky/documentation')
19 files changed, 582 insertions, 129 deletions
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst index fccf059ccc..f2f5d4d954 100644 --- a/poky/documentation/bsp-guide/bsp.rst +++ b/poky/documentation/bsp-guide/bsp.rst @@ -1179,14 +1179,14 @@ Use these steps to create a BSP layer: :yocto_git:`Source Repositories <>`. To get examples of what you need in your configuration file, locate a layer (e.g. "meta-ti") and examine the - :yocto_git:`local.conf </meta-ti/tree/conf/layer.conf>` + :yocto_git:`local.conf </meta-ti/tree/meta-ti-bsp/conf/layer.conf>` file. - *Create a Machine Configuration File:* Create a ``conf/machine/bsp_root_name.conf`` file. See :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>` for sample ``bsp_root_name.conf`` files. There are other samples such as - :yocto_git:`meta-ti </meta-ti/tree/conf/machine>` + :yocto_git:`meta-ti </meta-ti/tree/meta-ti-bsp/conf/machine>` and :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>` from other vendors that have more specific machine and tuning @@ -1209,7 +1209,7 @@ BSP Layer Configuration Example ------------------------------- The layer's ``conf`` directory contains the ``layer.conf`` configuration -file. In this example, the ``conf/layer.conf`` is the following:: +file. In this example, the ``conf/layer.conf`` file is the following:: # We have a conf and classes directory, add to BBPATH BBPATH .= ":${LAYERDIR}" diff --git a/poky/documentation/dev-manual/changes.rst b/poky/documentation/dev-manual/changes.rst index 9cb25f3549..9db6ce010c 100644 --- a/poky/documentation/dev-manual/changes.rst +++ b/poky/documentation/dev-manual/changes.rst @@ -319,7 +319,7 @@ without using the scripts once the steps in command, see ``GIT-SEND-EMAIL(1)`` displayed using the ``man git-send-email`` command. -The Yocto Project uses a `Patchwork instance <https://patchwork.openembedded.org/>`__ +The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__ to track the status of patches submitted to the various mailing lists and to support automated patch testing. Each submitted patch is checked for common mistakes and deviations from the expected patch format and submitters are diff --git a/poky/documentation/dev-manual/licenses.rst b/poky/documentation/dev-manual/licenses.rst index 65914e5efe..9629dc5329 100644 --- a/poky/documentation/dev-manual/licenses.rst +++ b/poky/documentation/dev-manual/licenses.rst @@ -242,10 +242,8 @@ defined in the COMMERCIAL_AUDIO_PLUGINS ?= "" COMMERCIAL_VIDEO_PLUGINS ?= "" -If you -want to enable these components, you can do so by making sure you have -statements similar to the following in your ``local.conf`` configuration -file:: +If you want to enable these components, you can do so by making sure you have +statements similar to the following in your ``local.conf`` configuration file:: COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \ gst-plugins-ugly-mpegaudioparse" @@ -253,20 +251,26 @@ file:: gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse" LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp" - -Of course, you could also create a matching list for those -components using the more general "commercial" in the -:term:`LICENSE_FLAGS_ACCEPTED` variable, but that would also enable all -the other packages with :term:`LICENSE_FLAGS` +Of course, you could also create a matching list for those components using the +more general "commercial" string in the :term:`LICENSE_FLAGS_ACCEPTED` variable, +but that would also enable all the other packages with :term:`LICENSE_FLAGS` containing "commercial", which you may or may not want:: LICENSE_FLAGS_ACCEPTED = "commercial" Specifying audio and video plugins as part of the -``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements -(along with the enabling :term:`LICENSE_FLAGS_ACCEPTED`) includes the -plugins or components into built images, thus adding support for media -formats or components. +:term:`COMMERCIAL_AUDIO_PLUGINS` and :term:`COMMERCIAL_VIDEO_PLUGINS` statements +(along with :term:`LICENSE_FLAGS_ACCEPTED`) includes the plugins or +components into built images, thus adding support for media formats or +components. + +.. note:: + + GStreamer "ugly" and "bad" plugins are actually available through + open source licenses. However, the "ugly" ones can be subject to software + patents in some countries, making it necessary to pay licensing fees + to distribute them. The "bad" ones are just deemed unreliable by the + GStreamer community and should therefore be used with care. Maintaining Open Source License Compliance During Your Product's Lifecycle ========================================================================== diff --git a/poky/documentation/dev-manual/new-recipe.rst b/poky/documentation/dev-manual/new-recipe.rst index 4751f64b7e..1ed217be7f 100644 --- a/poky/documentation/dev-manual/new-recipe.rst +++ b/poky/documentation/dev-manual/new-recipe.rst @@ -288,7 +288,7 @@ extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so forth), are automatically extracted during the :ref:`ref-tasks-unpack` task. For another example that specifies these types of files, see the -":ref:`dev-manual/new-recipe:autotooled package`" section. +":ref:`dev-manual/new-recipe:building an autotooled package`" section. Another way of specifying source is from an SCM. For Git repositories, you must specify :term:`SRCREV` and you should specify :term:`PV` to include @@ -361,7 +361,7 @@ and searches specific directories in a certain order: ``files``. The directories are assumed to be subdirectories of the directory in which the recipe or append file resides. For another example that specifies these types of files, see the -":ref:`dev-manual/new-recipe:single .c file package (hello world!)`" section. +"`building a single .c file package`_" section. The previous example also specifies a patch file. Patch files are files whose names usually end in ``.patch`` or ``.diff`` but can end with @@ -776,7 +776,7 @@ the software being built: ``PREFIX=${D}``, ``INSTALLROOT=${D}``, and so forth). For an example recipe using ``make install``, see the - ":ref:`dev-manual/new-recipe:makefile-based package`" section. + ":ref:`dev-manual/new-recipe:building a makefile-based package`" section. - *Manual:* You need to define a :ref:`ref-tasks-install` function in your recipe. The function must first use ``install -d`` to create the @@ -1165,28 +1165,29 @@ Examples ======== To help summarize how to write a recipe, this section provides some -examples given various scenarios: +recipe examples given various scenarios: -- Recipes that use local files +- `Building a single .c file package`_ -- Using an Autotooled package +- `Building a Makefile-based package`_ -- Using a Makefile-based package +- `Building an Autotooled package`_ -- Splitting an application into multiple packages +- `Building a Meson package`_ -- Adding binaries to an image +- `Splitting an application into multiple packages`_ -Single .c File Package (Hello World!) -------------------------------------- +- `Packaging externally produced binaries`_ -Building an application from a single file that is stored locally (e.g. -under ``files``) requires a recipe that has the file listed in the -:term:`SRC_URI` variable. Additionally, you need to manually write the -:ref:`ref-tasks-compile` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the -directory containing the source code, which is set to -:term:`WORKDIR` in this case --- the -directory BitBake uses for the build:: +Building a Single .c File Package +--------------------------------- + +Building an application from a single file that is stored locally (e.g. under +``files``) requires a recipe that has the file listed in the :term:`SRC_URI` +variable. Additionally, you need to manually write the :ref:`ref-tasks-compile` +and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the +directory containing the source code, which is set to :term:`WORKDIR` in this +case --- the directory BitBake uses for the build:: SUMMARY = "Simple helloworld application" SECTION = "examples" @@ -1206,52 +1207,22 @@ directory BitBake uses for the build:: install -m 0755 helloworld ${D}${bindir} } -By default, the ``helloworld``, ``helloworld-dbg``, and -``helloworld-dev`` packages are built. For information on how to -customize the packaging process, see the +By default, the ``helloworld``, ``helloworld-dbg``, and ``helloworld-dev`` packages +are built. For information on how to customize the packaging process, see the ":ref:`dev-manual/new-recipe:splitting an application into multiple packages`" section. -Autotooled Package ------------------- +Building a Makefile-Based Package +--------------------------------- -Applications that use Autotools such as ``autoconf`` and ``automake`` -require a recipe that has a source archive listed in :term:`SRC_URI` and -also inherit the :ref:`ref-classes-autotools` class, -which contains the definitions of all the steps needed to build an -Autotool-based application. The result of the build is automatically -packaged. And, if the application uses NLS for localization, packages -with local information are generated (one package per language). -Following is one example: (``hello_2.3.bb``):: - - SUMMARY = "GNU Helloworld application" - SECTION = "examples" - LICENSE = "GPL-2.0-or-later" - LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" - - SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" - - inherit autotools gettext - -The variable :term:`LIC_FILES_CHKSUM` is used to track source license -changes as described in the -":ref:`dev-manual/licenses:tracking license changes`" section in -the Yocto Project Overview and Concepts Manual. You can quickly create -Autotool-based recipes in a manner similar to the previous example. - -Makefile-Based Package ----------------------- - -Applications that use GNU ``make`` also require a recipe that has the -source archive listed in :term:`SRC_URI`. You do not need to add a -:ref:`ref-tasks-compile` step since by default BitBake starts the ``make`` command -to compile the application. If you need additional ``make`` options, you -should store them in the -:term:`EXTRA_OEMAKE` or -:term:`PACKAGECONFIG_CONFARGS` -variables. BitBake passes these options into the GNU ``make`` -invocation. Note that a :ref:`ref-tasks-install` task is still required. -Otherwise, BitBake runs an empty :ref:`ref-tasks-install` task by default. +Applications built with GNU ``make`` require a recipe that has the source archive +listed in :term:`SRC_URI`. You do not need to add a :ref:`ref-tasks-compile` +step since by default BitBake starts the ``make`` command to compile the +application. If you need additional ``make`` options, you should store them in +the :term:`EXTRA_OEMAKE` or :term:`PACKAGECONFIG_CONFARGS` variables. BitBake +passes these options into the GNU ``make`` invocation. Note that a +:ref:`ref-tasks-install` task is still required. Otherwise, BitBake runs an +empty :ref:`ref-tasks-install` task by default. Some applications might require extra parameters to be passed to the compiler. For example, the application might need an additional header @@ -1294,6 +1265,60 @@ In the following example, ``lz4`` is a makefile-based package:: BBCLASSEXTEND = "native nativesdk" +Building an Autotooled Package +------------------------------ + +Applications built with the Autotools such as ``autoconf`` and ``automake`` +require a recipe that has a source archive listed in :term:`SRC_URI` and also +inherit the :ref:`ref-classes-autotools` class, which contains the definitions +of all the steps needed to build an Autotool-based application. The result of +the build is automatically packaged. And, if the application uses NLS for +localization, packages with local information are generated (one package per +language). Following is one example: (``hello_2.3.bb``):: + + SUMMARY = "GNU Helloworld application" + SECTION = "examples" + LICENSE = "GPL-2.0-or-later" + LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" + + SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" + + inherit autotools gettext + +The variable :term:`LIC_FILES_CHKSUM` is used to track source license changes +as described in the ":ref:`dev-manual/licenses:tracking license changes`" +section in the Yocto Project Overview and Concepts Manual. You can quickly +create Autotool-based recipes in a manner similar to the previous example. + +Building a Meson Package +------------------------ + +Applications built with the `Meson build system <https://mesonbuild.com/>`__ +just need a recipe that has sources described in :term:`SRC_URI` and inherits +the :ref:`ref-classes-meson` class. + +The :oe_git:`ipcalc recipe </meta-openembedded/tree/meta-networking/recipes-support/ipcalc>` +is a simple example of an application without dependencies:: + + SUMMARY = "Tool to assist in network address calculations for IPv4 and IPv6." + HOMEPAGE = "https://gitlab.com/ipcalc/ipcalc" + + SECTION = "net" + + LICENSE = "GPL-2.0-only" + LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263" + + SRC_URI = "git://gitlab.com/ipcalc/ipcalc.git;protocol=https;branch=master" + SRCREV = "4c4261a47f355946ee74013d4f5d0494487cc2d6" + + S = "${WORKDIR}/git" + + inherit meson + +Applications with dependencies are likely to inherit the +:ref:`ref-classes-pkgconfig` class, as ``pkg-config`` is the default method +used by Meson to find dependencies and compile applications against them. + Splitting an Application into Multiple Packages ----------------------------------------------- diff --git a/poky/documentation/dev-manual/prebuilt-libraries.rst b/poky/documentation/dev-manual/prebuilt-libraries.rst index ca43463820..b80a844e93 100644 --- a/poky/documentation/dev-manual/prebuilt-libraries.rst +++ b/poky/documentation/dev-manual/prebuilt-libraries.rst @@ -153,9 +153,9 @@ default :term:`FILES` variables in ``bitbake.conf``:: SOLIBS = ".so.*" SOLIBSDEV = ".so" - FILES_${PN} = "... ${libdir}/lib*${SOLIBS} ..." + FILES:${PN} = "... ${libdir}/lib*${SOLIBS} ..." FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..." - FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..." + FILES:${PN}-dev = "... ${FILES_SOLIBSDEV} ..." :term:`SOLIBS` defines a pattern that matches real shared object libraries. :term:`SOLIBSDEV` matches the development form (unversioned symlink). These two diff --git a/poky/documentation/dev-manual/sbom.rst b/poky/documentation/dev-manual/sbom.rst index c67b7344d1..448c071c55 100644 --- a/poky/documentation/dev-manual/sbom.rst +++ b/poky/documentation/dev-manual/sbom.rst @@ -67,3 +67,6 @@ See the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX` project website for a list of tools to consume and transform the :term:`SPDX` data generated by the OpenEmbedded build system. +See also Joshua Watt's +`Automated SBoM generation with OpenEmbedded and the Yocto Project <https://youtu.be/Q5UQUM6zxVU>`__ +presentation at FOSDEM 2023. diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst index dff8f504fd..e0a85575c1 100644 --- a/poky/documentation/kernel-dev/common.rst +++ b/poky/documentation/kernel-dev/common.rst @@ -649,12 +649,12 @@ append files, you can direct the OpenEmbedded build system to use a To specify an "in-tree" ``defconfig`` file, use the following statement form:: - KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file" + KBUILD_DEFCONFIG:<machine> ?= "defconfig_file" -Here is an example -that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2" -and provides the path to the "in-tree" ``defconfig`` file to be used for -a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset:: +Here is an example that assigns the :term:`KBUILD_DEFCONFIG` variable utilizing +an override for the "raspberrypi2" :term:`MACHINE` and provides the path to the +"in-tree" ``defconfig`` file to be used for a Raspberry Pi 2, which is based on +the Broadcom 2708/2709 chipset:: KBUILD_DEFCONFIG:raspberrypi2 ?= "bcm2709_defconfig" diff --git a/poky/documentation/migration-guides/migration-4.2.rst b/poky/documentation/migration-guides/migration-4.2.rst index 944ad31a4c..1339411b3e 100644 --- a/poky/documentation/migration-guides/migration-4.2.rst +++ b/poky/documentation/migration-guides/migration-4.2.rst @@ -12,7 +12,7 @@ Project 4.2 Release (codename "mickledore") from the prior release. .. _migration-4.2-python-3.8: Python 3.8 is now the minimum required Python version version -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ BitBake and OpenEmbedded-Core are now relying on Python 3.8, making it a requirement to use a distribution providing at least this @@ -28,8 +28,8 @@ QA check changes Miscellaneous changes ~~~~~~~~~~~~~~~~~~~~~ -- The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has been - removed. +- The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has been + removed. .. _migration-4.2-removed-variables: @@ -37,7 +37,8 @@ Removed variables ~~~~~~~~~~~~~~~~~ The following variables have been removed: -- ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by :term:``SERIAL_CONSOLES``. + +- ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by :term:``SERIAL_CONSOLES``. .. _migration-4.2-removed-recipes: diff --git a/poky/documentation/migration-guides/release-4.0.rst b/poky/documentation/migration-guides/release-4.0.rst index 8ca8498838..87ba768a22 100644 --- a/poky/documentation/migration-guides/release-4.0.rst +++ b/poky/documentation/migration-guides/release-4.0.rst @@ -13,3 +13,4 @@ Release 4.0 (kirkstone) release-notes-4.0.4 release-notes-4.0.5 release-notes-4.0.6 + release-notes-4.0.7 diff --git a/poky/documentation/migration-guides/release-notes-4.0.7.rst b/poky/documentation/migration-guides/release-notes-4.0.7.rst new file mode 100644 index 0000000000..9e8ad51a0c --- /dev/null +++ b/poky/documentation/migration-guides/release-notes-4.0.7.rst @@ -0,0 +1,242 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Release notes for Yocto-4.0.7 (Kirkstone) +----------------------------------------- + +Security Fixes in Yocto-4.0.7 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- binutils: Fix :cve:`2022-4285` +- curl: Fix :cve:`2022-43551` and `CVE-2022-43552 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43552>`__ +- ffmpeg: Fix :cve:`2022-3109` and :cve:`2022-3341` +- go: Fix :cve:`2022-41715` and :cve:`2022-41717` +- libX11: Fix :cve:`2022-3554` and :cve:`2022-3555` +- libarchive: Fix :cve:`2022-36227` +- libksba: Fix :cve:`2022-47629` +- libpng: Fix :cve:`2019-6129` +- libxml2: Fix :cve:`2022-40303` and :cve:`2022-40304` +- openssl: Fix :cve:`2022-3996` +- python3: Fix :cve:`2022-45061` +- python3-git: Fix :cve:`2022-24439` +- python3-setuptools: Fix :cve:`2022-40897` +- python3-wheel: Fix :cve:`2022-40898` +- qemu: Fix :cve:`2022-4144` +- sqlite: Fix :cve:`2022-46908` +- systemd: Fix :cve:`2022-45873` +- vim: Fix :cve:`2023-0049`, :cve:`2023-0051`, :cve:`2023-0054` and :cve:`2023-0088` +- webkitgtk: Fix :cve:`2022-32886`, `CVE-2022-32891 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32891>`__ and :cve:`2022-32912` + + +Fixes in Yocto-4.0.7 +~~~~~~~~~~~~~~~~~~~~ + +- Revert "gstreamer1.0: disable flaky gstbin:test_watch_for_state_change test" +- at: Change when files are copied +- baremetal-image: Avoid overriding qemu variables from IMAGE_CLASSES +- base.bbclass: Fix way to check ccache path +- bc: extend to nativesdk +- bind: upgrade to 9.18.10 +- busybox: always start do_compile with orig config files +- busybox: rm temporary files if do_compile was interrupted +- cairo: fix CVE patches assigned wrong CVE number +- cairo: update patch for :cve:`2019-6461` with upstream solution +- classes/create-spdx: Add SPDX_PRETTY option +- classes: image: Set empty weak default IMAGE_LINGUAS +- combo-layer: add sync-revs command +- combo-layer: dont use bb.utils.rename +- combo-layer: remove unused import +- curl: Correct LICENSE from MIT-open-group to curl +- cve-check: write the cve manifest to IMGDEPLOYDIR +- cve-update-db-native: avoid incomplete updates +- cve-update-db-native: show IP on failure +- dbus: Add missing CVE product name +- devtool/upgrade: correctly handle recipes where S is a subdir of upstream tree +- devtool: process local files only for the main branch +- dhcpcd: backport two patches to fix runtime error +- docs: kernel-dev: faq: update tip on how to not include kernel in image +- docs: migration-4.0: specify variable name change for kernel inclusion in image recipe +- efibootmgr: update compilation with musl +- externalsrc: fix lookup for .gitmodules +- ffmpeg: refresh patches to apply cleanly +- freetype:update mirror site. +- gcc: Refactor linker patches and fix linker on arm with usrmerge +- glibc: stable 2.35 branch updates. +- go-crosssdk: avoid host contamination by GOCACHE +- gstreamer1.0: Fix race conditions in gstbin tests +- gstreamer1.0: upgrade to 1.20.5 +- gtk-icon-cache: Fix GTKIC_CMD if-else condition +- harfbuzz: remove bindir only if it exists +- kernel-fitimage: Adjust order of dtb/dtbo files +- kernel-fitimage: Allow user to select dtb when multiple dtb exists +- kernel.bbclass: remove empty module directories to prevent QA issues +- lib/buildstats: fix parsing of trees with reduced_proc_pressure directories +- lib/oe/reproducible: Use git log without gpg signature +- libepoxy: remove upstreamed patch +- libnewt: update 0.52.21 -> 0.52.23 +- libseccomp: fix typo in DESCRIPTION +- libxcrypt-compat: upgrade 4.4.30 -> 4.4.33 +- libxml2: fix test data checksums +- linux-firmware: upgrade 20221109 -> 20221214 +- linux-yocto/5.10: update to v5.10.152 +- linux-yocto/5.10: update to v5.10.154 +- linux-yocto/5.10: update to v5.10.160 +- linux-yocto/5.15: fix perf build with clang +- linux-yocto/5.15: libbpf: Fix build warning on ref_ctr_off +- linux-yocto/5.15: ltp and squashfs fixes +- linux-yocto/5.15: powerpc: Fix reschedule bug in KUAP-unlocked user copy +- linux-yocto/5.15: update to v5.15.84 +- lsof: add update-alternatives logic +- lttng-modules: update 2.13.7 -> 2.13.8 +- manuals: add 4.0.5 and 4.0.6 release notes +- manuals: document SPDX_PRETTY variable +- mpfr: upgrade 4.1.0 -> 4.1.1 +- oeqa/concurrencytest: Add number of failures to summary output +- oeqa/rpm.py: Increase timeout and add debug output +- oeqa/selftest/externalsrc: add test for srctree_hash_files +- openssh: remove RRECOMMENDS to rng-tools for sshd package +- poky.conf: bump version for 4.0.7 +- qemuboot.bbclass: make sure runqemu boots bundled initramfs kernel image +- rm_work.bbclass: use HOSTTOOLS 'rm' binary exclusively +- rm_work: adjust dependency to make do_rm_work_all depend on do_rm_work +- ruby: merge .inc into .bb +- ruby: update 3.1.2 -> 3.1.3 +- selftest/virgl: use pkg-config from the host +- tiff: Add packageconfig knob for webp +- toolchain-scripts: compatibility with unbound variable protection +- tzdata: update 2022d -> 2022g +- valgrind: skip the boost_thread test on arm +- xserver-xorg: upgrade 21.1.4 -> 21.1.6 +- xwayland: libxshmfence is needed when dri3 is enabled +- xwayland: upgrade 22.1.5 -> 22.1.7 +- yocto-check-layer: Allow OE-Core to be tested + + +Known Issues in Yocto-4.0.7 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- N/A + + +Contributors to Yocto-4.0.7 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Alejandro Hernandez Samaniego +- Alex Kiernan +- Alex Stewart +- Alexander Kanavin +- Antonin Godard +- Benoît Mauduit +- Bhabu Bindu +- Bruce Ashfield +- Carlos Alberto Lopez Perez +- Changqing Li +- Chen Qi +- Daniel Gomez +- Florin Diaconescu +- He Zhe +- Hitendra Prajapati +- Jagadeesh Krishnanjanappa +- Jan Kircher +- Jermain Horsman +- Jose Quaresma +- Joshua Watt +- KARN JYE LAU +- Kai Kang +- Khem Raj +- Luis +- Marta Rybczynska +- Martin Jansa +- Mathieu Dubois-Briand +- Michael Opdenacker +- Narpat Mali +- Ovidiu Panait +- Pavel Zhukov +- Peter Marko +- Petr Kubizňák +- Quentin Schulz +- Randy MacLeod +- Ranjitsinh Rathod +- Richard Purdie +- Robert Andersson +- Ross Burton +- Sandeep Gundlupet Raju +- Saul Wold +- Steve Sakoman +- Vivek Kumbhar +- Wang Mingyu +- Xiangyu Chen +- Yash Shinde +- Yogita Urade + + +Repositories / Downloads for Yocto-4.0.7 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +poky + +- Repository Location: :yocto_git:`/poky` +- Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.7 </poky/log/?h=yocto-4.0.7>` +- Git Revision: :yocto_git:`65dafea22018052fe7b2e17e6e4d7eb754224d38 </poky/commit/?id=65dafea22018052fe7b2e17e6e4d7eb754224d38>` +- Release Artefact: poky-65dafea22018052fe7b2e17e6e4d7eb754224d38 +- sha: 6b1b67600b84503e2d5d29bcd6038547339f4f9413b830cd2408df825eda642d +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/poky-65dafea22018052fe7b2e17e6e4d7eb754224d38.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/poky-65dafea22018052fe7b2e17e6e4d7eb754224d38.tar.bz2 + +openembedded-core + +- Repository Location: :oe_git:`/openembedded-core` +- Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>` +- Tag: :oe_git:`yocto-4.0.7 </openembedded-core/log/?h=yocto-4.0.7>` +- Git Revision: :oe_git:`a8c82902384f7430519a31732a4bb631f21693ac </openembedded-core/commit/?id=a8c82902384f7430519a31732a4bb631f21693ac>` +- Release Artefact: oecore-a8c82902384f7430519a31732a4bb631f21693ac +- sha: 6f2dbc4ea1e388620ef77ac3a7bbb2b5956bb8bf9349b0c16cd7610e9996f5ea +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/oecore-a8c82902384f7430519a31732a4bb631f21693ac.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/oecore-a8c82902384f7430519a31732a4bb631f21693ac.tar.bz2 + +meta-mingw + +- Repository Location: :yocto_git:`/meta-mingw` +- Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.7 </meta-mingw/log/?h=yocto-4.0.7>` +- Git Revision: :yocto_git:`a90614a6498c3345704e9611f2842eb933dc51c1 </meta-mingw/commit/?id=a90614a6498c3345704e9611f2842eb933dc51c1>` +- Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1 +- sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2 + +meta-gplv2 + +- Repository Location: :yocto_git:`/meta-gplv2` +- Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.7 </meta-gplv2/log/?h=yocto-4.0.7>` +- Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>` +- Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a +- sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2 + +bitbake + +- Repository Location: :oe_git:`/bitbake` +- Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>` +- Tag: :oe_git:`yocto-4.0.7 </bitbake/log/?h=yocto-4.0.7>` +- Git Revision: :oe_git:`7e268c107bb0240d583d2c34e24a71e373382509 </bitbake/commit/?id=7e268c107bb0240d583d2c34e24a71e373382509>` +- Release Artefact: bitbake-7e268c107bb0240d583d2c34e24a71e373382509 +- sha: c3e2899012358c95962c7a5c85cf98dc30c58eae0861c374124e96d9556bb901 +- Download Locations: + http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/bitbake-7e268c107bb0240d583d2c34e24a71e373382509.tar.bz2 + http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/bitbake-7e268c107bb0240d583d2c34e24a71e373382509.tar.bz2 + +yocto-docs + +- Repository Location: :yocto_git:`/yocto-docs` +- Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>` +- Tag: :yocto_git:`yocto-4.0.7 </yocto-docs/log/?h=yocto-4.0.7>` +- Git Revision: :yocto_git:`5883e897c34f25401b358a597fb6e18d80f7f90b </yocto-docs/commit/?id=5883e897c34f25401b358a597fb6e18d80f7f90b>` + + diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst index 4c847a09de..35f5345ad4 100644 --- a/poky/documentation/overview-manual/yp-intro.rst +++ b/poky/documentation/overview-manual/yp-intro.rst @@ -361,7 +361,7 @@ Yocto Project: of the :oe_layerindex:`OpenEmbedded Layer Index <>`, which is a website that indexes OpenEmbedded-Core layers. -- *Patchwork:* `Patchwork <http://jk.ozlabs.org/projects/patchwork/>`__ +- *Patchwork:* `Patchwork <https://patchwork.yoctoproject.org/>`__ is a fork of a project originally started by `OzLabs <https://ozlabs.org/>`__. The project is a web-based tracking system designed to streamline the process of bringing contributions diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst index 1e31019897..703ac459a0 100644 --- a/poky/documentation/profile-manual/usage.rst +++ b/poky/documentation/profile-manual/usage.rst @@ -1738,7 +1738,7 @@ events': The tool is pretty self-explanatory, but for more detailed information on navigating through the data, see the `kernelshark -website <https://rostedt.homelinux.com/kernelshark/>`__. +website <https://kernelshark.org/Documentation.html>`__. ftrace Documentation -------------------- @@ -1767,8 +1767,8 @@ There is a nice series of articles on using ftrace and trace-cmd at LWN: - `trace-cmd: A front-end for Ftrace <https://lwn.net/Articles/410200/>`__ -There's more detailed documentation kernelshark usage here: -`KernelShark <https://rostedt.homelinux.com/kernelshark/>`__ +See also `KernelShark's documentation <https://kernelshark.org/Documentation.html>`__ +for further usage details. An amusing yet useful README (a tracing mini-HOWTO) can be found in ``/sys/kernel/debug/tracing/README``. diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index 0cb507b500..7ff0fcb335 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -93,7 +93,7 @@ standardization. This class defines a set of tasks (e.g. ``configure``, should usually be enough to define a few standard variables and then simply ``inherit autotools``. These classes can also work with software that emulates Autotools. For more information, see the -":ref:`dev-manual/new-recipe:autotooled package`" section +":ref:`dev-manual/new-recipe:building an autotooled package`" section in the Yocto Project Development Tasks Manual. By default, the :ref:`autotools* <ref-classes-autotools>` classes use out-of-tree builds (i.e. @@ -254,8 +254,68 @@ When inherited globally, prints statistics at the end of the build on sstate re-use. In order to function, this class requires the :ref:`ref-classes-buildstats` class be enabled. +.. _ref-classes-cargo: + +``cargo`` +========= + +The :ref:`ref-classes-cargo` class allows to compile Rust language programs +using `Cargo <https://doc.rust-lang.org/cargo/>`__. Cargo is Rust's package +manager, allowing to fetch package dependencies and build your program. + +Using this class makes it very easy to build Rust programs. All you need +is to use the :term:`SRC_URI` variable to point to a source repository +which can be built by Cargo, typically one that was created by the +``cargo new`` command, containing a ``Cargo.toml`` file and a ``src`` +subdirectory. + +You will find a simple example in the +:oe_git:`rust-hello-world_git.bb </openembedded-core/tree/meta/recipes-extended/rust-example/rust-hello-world_git.bb>` +recipe. A more complex example, with package dependencies, is the +:oe_git:`uutils-coreutils </meta-openembedded/tree/meta-oe/recipes-core/uutils-coreutils>` +recipe, which was generated by the `cargo-bitbake <https://crates.io/crates/cargo-bitbake>`__ +tool. + +This class inherits the :ref:`ref-classes-cargo_common` class. + +.. _ref-classes-cargo_common: + +``cargo_common`` +================ + +The :ref:`ref-classes-cargo_common` class is an internal class +that is not intended to be used directly. + +An exception is the "rust" recipe, to build the Rust compiler and runtime +library, which is built by Cargo but cannot use the :ref:`ref-classes-cargo` +class. This is why this class was introduced. + .. _ref-classes-ccache: +.. _ref-classes-cargo-update-recipe-crates: + +``cargo-update-recipe-crates`` +=============================== + +The :ref:`ref-classes-cargo-update-recipe-crates` class allows +recipe developers to update the list of Cargo crates in :term:`SRC_URI` +by reading the ``Cargo.lock`` file in the source tree. + +To do so, create a recipe for your program, for example using +:doc:`devtool </ref-manual/devtool-reference>`, +make it inherit the :ref:`ref-classes-cargo` and +:ref:`ref-classes-cargo-update-recipe-crates` and run:: + + bitbake -c update_crates recipe + +This creates a ``recipe-crates.inc`` file that you can include in your +recipe:: + + require ${BPN}-crates.inc + +That's also something you can achieve by using the +`cargo-bitbake <https://crates.io/crates/cargo-bitbake>`__ tool. + ``ccache`` ========== @@ -286,17 +346,20 @@ in order to make them relocatable. ``cmake`` ========= -The ref:`ref-classes-cmake` class allows for recipes that need to build software using -the `CMake <https://cmake.org/overview/>`__ build system. You can use -the :term:`EXTRA_OECMAKE` variable to specify -additional configuration options to be passed using the ``cmake`` -command line. +The :ref:`ref-classes-cmake` class allows recipes to build software using the +`CMake <https://cmake.org/overview/>`__ build system. You can use the +:term:`EXTRA_OECMAKE` variable to specify additional configuration options to +pass to the ``cmake`` command line. + +By default, the :ref:`ref-classes-cmake` class uses +`Ninja <https://ninja-build.org/>`__ instead of GNU make for building, which +offers better build performance. If a recipe is broken with Ninja, then the +recipe can set the :term:`OECMAKE_GENERATOR` variable to ``Unix Makefiles`` to +use GNU make instead. -On the occasion that you would be installing custom CMake toolchain -files supplied by the application being built, you should install them -to the preferred CMake Module directory: ``${D}${datadir}/cmake/`` -Modules during -:ref:`ref-tasks-install`. +If you need to install custom CMake toolchain files supplied by the application +being built, you should install them (during :ref:`ref-tasks-install`) to the +preferred CMake Module directory: ``${D}${datadir}/cmake/modules/``. .. _ref-classes-cml1: @@ -1588,6 +1651,16 @@ messages for various BitBake severity levels (i.e. ``bbplain``, This class is enabled by default since it is inherited by the :ref:`ref-classes-base` class. +.. _ref-classes-meson: + +``meson`` +========= + +The :ref:`ref-classes-meson` class allows to create recipes that build software +using the `Meson <https://mesonbuild.com/>`__ build system. You can use +the :term:`MESON_BUILDTYPE` and :term:`EXTRA_OEMESON` variables to specify +additional configuration options to be passed using the ``meson`` command line. + .. _ref-classes-metadata_scm: ``metadata_scm`` @@ -2171,6 +2244,31 @@ The :ref:`ref-classes-python_poetry_core` class enables building Python modules Internally this uses the :ref:`ref-classes-python_pep517` class. +.. _ref-classes-python_pyo3: + +``python_pyo3`` +=============== + +The :ref:`ref-classes-python_pyo3` class helps make sure that Python extensions +written in Rust and built with `PyO3 <https://pyo3.rs/>`__, properly set up the +environment for cross compilation. + +This class is internal to the :ref:`ref-classes-python-setuptools3_rust` class +and is not meant to be used directly in recipes. + +.. _ref-classes-python-setuptools3_rust: + +``python-setuptools3_rust`` +=========================== + +The :ref:`ref-classes-python-setuptools3_rust` class enables building Python +extensions implemented in Rust with `PyO3 <https://pyo3.rs/>`__, which allows +to compile and distribute Python extensions written in Rust as easily +as if they were written in C. + +This class inherits the :ref:`ref-classes-setuptools3` and +:ref:`ref-classes-python_pyo3` classes. + .. _ref-classes-pixbufcache: ``pixbufcache`` @@ -2493,6 +2591,24 @@ For information on how root filesystem images are created, see the ":ref:`overview-manual/concepts:image generation`" section in the Yocto Project Overview and Concepts Manual. +.. _ref-classes-rust: + +``rust`` +======== + +The :ref:`ref-classes-rust` class is an internal class which is just used +in the "rust" recipe, to build the Rust compiler and runtime +library. Except for this recipe, it is not intended to be used directly. + +.. _ref-classes-rust-common: + +``rust-common`` +=============== + +The :ref:`ref-classes-rust-common` class is an internal class to the +:ref:`ref-classes-cargo_common` and :ref:`ref-classes-rust` classes and is not +intended to be used directly. + .. _ref-classes-sanity: ``sanity`` diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index 6aa09f6d6f..32e64d02a2 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -378,14 +378,7 @@ command:: Unless you provide a specific recipe name on the command line, the command checks all recipes in all configured layers. -Following is a partial example table that reports on all the recipes. -Notice the reported reason for not upgrading the ``base-passwd`` recipe. -In this example, while a new version is available upstream, you do not -want to use it because the dependency on ``cdebconf`` is not easily -satisfied. Maintainers can explicit the reason that is shown by adding -the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe. -See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>` -for an example:: +Following is a partial example table that reports on all the recipes:: $ devtool check-upgrade-status ... @@ -396,6 +389,16 @@ for an example:: INFO: base-passwd 3.5.29 3.5.51 Anuj Mittal <anuj.mittal@intel.com> cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility ... +Notice the reported reason for not upgrading the ``base-passwd`` recipe. +In this example, while a new version is available upstream, you do not +want to use it because the dependency on ``cdebconf`` is not easily +satisfied. Maintainers can explicit the reason that is shown by adding +the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe. +See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb?h=kirkstone>` +for an example:: + + RECIPE_NO_UPDATE_REASON = "Version 3.5.38 requires cdebconf for update-passwd utility" + Last but not least, you may set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1`` in a recipe when there's currently no way to determine its latest upstream version. diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst index 794a6fd15b..051bf9320a 100644 --- a/poky/documentation/ref-manual/features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -294,11 +294,11 @@ Here are the image features available for all images: forced in ``/etc/passwd`` and ``/etc/shadow`` if such files exist. .. note:: - ``empty-root-passwd`` doesn't set an empty root password by itself. + ``empty-root-password`` doesn't set an empty root password by itself. You get an initial empty root password thanks to the :oe_git:`base-passwd </openembedded-core/tree/meta/recipes-core/base-passwd/>` and :oe_git:`shadow </openembedded-core/tree/meta/recipes-extended/shadow/>` - recipes, and the presence of ``empty-root-passwd`` or ``debug-tweaks`` + recipes, and the presence of ``empty-root-password`` or ``debug-tweaks`` just disables the mechanism which forces an non-empty password for the root user. diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 5a09909c70..d2344e39a0 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -173,7 +173,7 @@ Here is a list of resources you might find helpful: - :yocto_wiki:`FAQ </FAQ>`: A list of commonly asked questions and their answers. -- :yocto_docs:`Release Information </migration-guides/>`: +- :doc:`Release Information </migration-guides/index>`: Migration guides, release notes, new features, updates and known issues for the current and past releases of the Yocto Project. diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index 3cd0894687..38d4aaf5a7 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -42,18 +42,20 @@ Currently, the Yocto Project is supported on the following distributions: - Ubuntu 22.04 (LTS) -- Fedora 34 +- Fedora 36 -- Fedora 35 +- Fedora 37 -- AlmaLinux 8.5 +- AlmaLinux 8.7 -- Debian GNU/Linux 10.x (Buster) +- AlmaLinux 9.1 - Debian GNU/Linux 11.x (Bullseye) - OpenSUSE Leap 15.3 +- OpenSUSE Leap 15.4 + .. note:: - While the Yocto Project Team attempts to ensure all Yocto Project diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index 725f5c54cc..9b581599e3 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -1313,6 +1313,26 @@ system and gives an overview of their function and contents. optional at the distribution level, in case the hardware supports Bluetooth but you do not ever intend to use it. + :term:`COMMERCIAL_AUDIO_PLUGINS` + This variable is specific to the :yocto_git:`GStreamer recipes + </poky/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-meta-base.bb>`. + It allows to build the GStreamer `"ugly" + <https://github.com/GStreamer/gst-plugins-ugly>`__ and + `"bad" <https://github.com/GStreamer/gst-plugins-bad>`__ audio plugins. + + See the :ref:`dev-manual/licenses:other variables related to commercial licenses` + section for usage details. + + :term:`COMMERCIAL_VIDEO_PLUGINS` + This variable is specific to the :yocto_git:`GStreamer recipes + </poky/tree/meta/recipes-multimedia/gstreamer/gstreamer1.0-meta-base.bb>`. + It allows to build the GStreamer `"ugly" + <https://github.com/GStreamer/gst-plugins-ugly>`__ and + `"bad" <https://github.com/GStreamer/gst-plugins-bad>`__ video plugins. + + See the :ref:`dev-manual/licenses:other variables related to commercial licenses` + section for usage details. + :term:`COMMON_LICENSE_DIR` Points to ``meta/files/common-licenses`` in the :term:`Source Directory`, which is where generic license @@ -2004,9 +2024,9 @@ system and gives an overview of their function and contents. variable. :term:`DEV_PKG_DEPENDENCY` - Provides an easy way for recipes to disable or adjust the runtime - dependency (:term:`RDEPENDS`) of the ``${PN}-dev`` package on the main - (``${PN}``) package, particularly where the main package may be empty. + Provides an easy way for recipes to disable or adjust the runtime recommendation + (:term:`RRECOMMENDS`) of the ``${PN}-dev`` package on the main + (``${PN}``) package. :term:`DISABLE_STATIC` Used in order to disable static linking by default (in order to save @@ -2528,6 +2548,20 @@ system and gives an overview of their function and contents. variable specifies additional configuration options you want to pass to the ``scons`` command line. + :term:`EXTRA_OEMESON` + Additional `Meson <https://mesonbuild.com/>`__ options. See the + :ref:`ref-classes-meson` class for additional information. + + In addition to standard Meson options, such options correspond to + `Meson build options <https://mesonbuild.com/Build-options.html>`__ + defined in the ``meson_options.txt`` file in the sources to build. + Here is an example:: + + EXTRA_OEMESON = "-Dpython=disabled -Dvalgrind=disabled" + + Note that any custom value for the Meson ``--buildtype`` option + should be set through the :term:`MESON_BUILDTYPE` variable. + :term:`EXTRA_USERS_PARAMS` When inheriting the :ref:`ref-classes-extrausers` class, this variable provides image level user and group operations. @@ -2892,13 +2926,14 @@ system and gives an overview of their function and contents. :term:`FIT_KERNEL_COMP_ALG` Compression algorithm to use for the kernel image inside the FIT Image. - At present, the only supported values are "gzip" (default) or "none" + At present, the only supported values are "gzip" (default), "lzo" or "none". If you set this variable to anything other than "none" you may also need to set :term:`FIT_KERNEL_COMP_ALG_EXTENSION`. :term:`FIT_KERNEL_COMP_ALG_EXTENSION` File extension corresponding to :term:`FIT_KERNEL_COMP_ALG`. The default - value is ".gz". + value is ".gz". If you set :term:`FIT_KERNEL_COMP_ALG` to "lzo", + you may want to set this variable to ".lzo". :term:`FIT_KEY_GENRSA_ARGS` Arguments to openssl genrsa for generating RSA private key for signing @@ -4274,9 +4309,9 @@ system and gives an overview of their function and contents. To use the variable, set it in the append file for your kernel recipe using the following form:: - KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file + KBUILD_DEFCONFIG:<machine> ?= "defconfig_file" - Here is an example from a "raspberrypi2" :term:`KMACHINE` build that uses + Here is an example from a "raspberrypi2" :term:`MACHINE` build that uses a ``defconfig`` file named "bcm2709_defconfig":: KBUILD_DEFCONFIG:raspberrypi2 = "bcm2709_defconfig" @@ -5137,6 +5172,17 @@ system and gives an overview of their function and contents. :term:`MAINTAINER` The email address of the distribution maintainer. + :term:`MESON_BUILDTYPE` + Value of the Meson ``--buildtype`` argument used by the + :ref:`ref-classes-meson` class. It defaults to ``debug`` if + :term:`DEBUG_BUILD` is set to "1", and ``plain`` otherwise. + + See `Meson build options <https://mesonbuild.com/Builtin-options.html>`__ + for the values you could set in a recipe. Values such as ``plain``, + ``debug``, ``debugoptimized``, ``release`` and ``minsize`` allow + you to specify the inclusion of debugging symbols and the compiler + optimizations (none, performance or size). + :term:`METADATA_BRANCH` The branch currently checked out for the OpenEmbedded-Core layer (path determined by :term:`COREBASE`). @@ -5398,6 +5444,16 @@ system and gives an overview of their function and contents. :term:`Source Directory` for details on how this class applies these additional sed command arguments. + :term:`OECMAKE_GENERATOR` + A variable for the :ref:`ref-classes-cmake` class, allowing to choose + which back-end will be generated by CMake to build an application. + + By default, this variable is set to ``Ninja``, which is faster than GNU + make, but if building is broken with Ninja, a recipe can use this + variable to use GNU make instead:: + + OECMAKE_GENERATOR = "Unix Makefiles" + :term:`OE_IMPORTS` An internal variable used to tell the OpenEmbedded build system what Python modules to import for every Python function run by the system. @@ -7793,7 +7849,7 @@ system and gives an overview of their function and contents. :term:`SSTATE_EXCLUDEDEPS_SYSROOT` is evaluated as two regular expressions of recipe and dependency to ignore. An example - is the rule in :oe_git:`meta/conf/layer.conf </meta/conf/layer.conf>`:: + is the rule in :oe_git:`meta/conf/layer.conf </openembedded-core/tree/meta/conf/layer.conf>`:: # Nothing needs to depend on libc-initial # base-passwd/shadow-sysroot don't need their dependencies @@ -8480,7 +8536,7 @@ system and gives an overview of their function and contents. responsibility to ensure that the toolchain is compatible with the default toolchain. Using older or newer versions of these components might cause build problems. See - :yocto_docs:`Release Information </migration-guides/>` for your + :doc:`Release Information </migration-guides/index>` for your version of the Yocto Project, to find the specific components with which the toolchain must be compatible. diff --git a/poky/documentation/test-manual/reproducible-builds.rst b/poky/documentation/test-manual/reproducible-builds.rst index 2a2f7790d2..50256fb197 100644 --- a/poky/documentation/test-manual/reproducible-builds.rst +++ b/poky/documentation/test-manual/reproducible-builds.rst @@ -24,8 +24,8 @@ reproducibility matters. The primary focus of the project is the ability to detect security issues being introduced. However, from a Yocto Project perspective, it is also hugely important that our builds are deterministic. When you build a given input set of metadata, we expect you to get consistent output. -This has always been a key focus but, :yocto_docs:`since release 3.1 ("dunfell") -</ref-manual/migration-3.1.html#reproducible-builds-now-enabled-by-default>`, +This has always been a key focus but, :ref:`since release 3.1 ("dunfell") +<migration-guides/migration-3.1:reproducible builds now enabled by default>`, it is now true down to the binary level including timestamps. For example, at some point in the future life of a product, you find that you |