diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index fccf059..f2f5d4d 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -1179,14 +1179,14 @@
    :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 @@
 -------------------------------
 
 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 9cb25f3..9db6ce0 100644
--- a/poky/documentation/dev-manual/changes.rst
+++ b/poky/documentation/dev-manual/changes.rst
@@ -319,7 +319,7 @@
    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 65914e5..9629dc5 100644
--- a/poky/documentation/dev-manual/licenses.rst
+++ b/poky/documentation/dev-manual/licenses.rst
@@ -242,10 +242,8 @@
    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 @@
        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 4751f64..1ed217b 100644
--- a/poky/documentation/dev-manual/new-recipe.rst
+++ b/poky/documentation/dev-manual/new-recipe.rst
@@ -288,7 +288,7 @@
 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 @@
 ``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 @@
    ``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 @@
 ========
 
 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 @@
        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 @@
 
    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 ca43463..b80a844 100644
--- a/poky/documentation/dev-manual/prebuilt-libraries.rst
+++ b/poky/documentation/dev-manual/prebuilt-libraries.rst
@@ -153,9 +153,9 @@
 
    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 c67b734..448c071 100644
--- a/poky/documentation/dev-manual/sbom.rst
+++ b/poky/documentation/dev-manual/sbom.rst
@@ -67,3 +67,6 @@
 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 dff8f50..e0a8557 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -649,12 +649,12 @@
 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 944ad31..1339411 100644
--- a/poky/documentation/migration-guides/migration-4.2.rst
+++ b/poky/documentation/migration-guides/migration-4.2.rst
@@ -12,7 +12,7 @@
 .. _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 @@
 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 @@
 ~~~~~~~~~~~~~~~~~
 
 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 8ca8498..87ba768 100644
--- a/poky/documentation/migration-guides/release-4.0.rst
+++ b/poky/documentation/migration-guides/release-4.0.rst
@@ -13,3 +13,4 @@
    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 0000000..9e8ad51
--- /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 4c847a0..35f5345 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -361,7 +361,7 @@
    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 1e31019..703ac45 100644
--- a/poky/documentation/profile-manual/usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -1738,7 +1738,7 @@
 
 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 @@
 -  `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 0cb507b..7ff0fcb 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -93,7 +93,7 @@
 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 @@
 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 @@
 ``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.
 
-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`.
+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.
+
+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 @@
 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 @@
 
 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 @@
 ":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 6aa09f6..32e64d0 100644
--- a/poky/documentation/ref-manual/devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -378,14 +378,7 @@
 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 @@
    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 794a6fd..051bf93 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -294,11 +294,11 @@
    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 5a09909..d2344e3 100644
--- a/poky/documentation/ref-manual/resources.rst
+++ b/poky/documentation/ref-manual/resources.rst
@@ -173,7 +173,7 @@
 -  :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 3cd0894..38d4aaf 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -42,18 +42,20 @@
 
 -  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 725f5c5..9b58159 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -1313,6 +1313,26 @@
       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 @@
       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 @@
       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 @@
 
    :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 @@
       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 @@
    :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 @@
       :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 @@
 
       :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 @@
          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 2a2f779..50256fb 100644
--- a/poky/documentation/test-manual/reproducible-builds.rst
+++ b/poky/documentation/test-manual/reproducible-builds.rst
@@ -24,8 +24,8 @@
 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