build-appliance-image: Update to nanbield head revision

(From OE-Core rev: cce77e8e79c860f4ef0ac4a86b9375bf87507360)

Signed-off-by: Steve Sakoman <steve@sakoman.com>

bitbake/SECURITY.md

@@ -0,0 +1,24 @@
+How to Report a Potential Vulnerability?
+========================================
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---------------------------------------
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS]
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all
+releases of the Yocto Project. Versions in grey are no longer actively maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.

documentation/brief-yoctoprojectqs/index.rst

@@ -254,7 +254,7 @@ an entire Linux distribution, including the toolchain, from source.
          BB_SIGNATURE_HANDLER = "OEEquivHash"
          BB_HASHSERVE = "auto"
          BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
-         SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
+         SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
 
 #. **Start the Build:** Continue with the following command to build an OS
    image for the target, which is ``core-image-sato`` in this example:

documentation/bsp-guide/bsp.rst

@@ -64,8 +64,8 @@ Here is an example that clones the Raspberry Pi BSP layer::
 
 In addition to BSP layers, the ``meta-yocto-bsp`` layer is part of the
 shipped ``poky`` repository. The ``meta-yocto-bsp`` layer maintains
-several "reference" BSPs including the ARM-based Beaglebone, MIPS-based
-EdgeRouter, and generic versions of both 32-bit and 64-bit IA machines.
+several "reference" BSPs including the ARM-based Beaglebone and generic
+versions of both 32-bit and 64-bit IA machines.
 
 For information on typical BSP development workflow, see the
 :ref:`bsp-guide/bsp:developing a board support package (bsp)`
@@ -764,29 +764,13 @@ workflow.
 
    .. note::
 
-      -  There are four hardware reference BSPs in the Yocto
+      -  There are three hardware reference BSPs in the Yocto
          Project release, located in the ``poky/meta-yocto-bsp``
          BSP layer:
 
          -  Texas Instruments Beaglebone (``beaglebone-yocto``)
 
-         -  Ubiquiti Networks EdgeRouter Lite (``edgerouter``)
-
-         -  Two general IA platforms (``genericx86`` and ``genericx86-64``)
-
-      -  There are three core Intel BSPs in the Yocto Project
-         release, in the ``meta-intel`` layer:
-
-         -  ``intel-core2-32``, which is a BSP optimized for the Core2
-            family of CPUs as well as all CPUs prior to the Silvermont
-            core.
-
-         -  ``intel-corei7-64``, which is a BSP optimized for Nehalem
-            and later Core and Xeon CPUs as well as Silvermont and later
-            Atom CPUs, such as the Baytrail SoCs.
-
-         -  ``intel-quark``, which is a BSP optimized for the Intel
-            Galileo gen1 & gen2 development boards.
+         -  Two generic IA platforms (``genericx86`` and ``genericx86-64``)
 
    When you set up a layer for a new BSP, you should follow a standard
    layout. This layout is described in the ":ref:`bsp-guide/bsp:example filesystem layout`"
@@ -1194,7 +1178,7 @@ Use these steps to create a BSP layer:
 
 -  *Create a Kernel Recipe:* Create a kernel recipe in
    ``recipes-kernel/linux`` by either using a kernel append file or a
-   new custom kernel recipe file (e.g. ``yocto-linux_4.12.bb``). The BSP
+   new custom kernel recipe file (e.g. ``linux-yocto_4.12.bb``). The BSP
    layers mentioned in the previous step also contain different kernel
    examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`"
    section in the Yocto Project Linux Kernel Development Manual for
@@ -1250,21 +1234,18 @@ There are one or more machine configuration files in the
 
 For example, the machine configuration file for the `BeagleBone and
 BeagleBone Black development boards <https://beagleboard.org/bone>`__ is
-located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named
-``beaglebone-yocto.conf``::
+located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
+</poky/tree/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf>`::
 
    #@TYPE: Machine
    #@NAME: Beaglebone-yocto machine
    #@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard.org/black boards
 
    PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
-   XSERVER ?= "xserver-xorg \
-               xf86-video-modesetting \
-              "
 
    MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
 
-   EXTRA_IMAGEDEPENDS += "u-boot"
+   EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
    DEFAULTTUNE ?= "cortexa8hf-neon"
    include conf/machine/include/arm/armv7a/tune-cortexa8.inc
@@ -1272,19 +1253,20 @@ located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named
    IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
    EXTRA_IMAGECMD:jffs2 = "-lnp "
    WKS_FILE ?= "beaglebone-yocto.wks"
-   IMAGE_INSTALL:append = " kernel-devicetree kernel-image-zimage"
-   do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
+   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
+   do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot virtual/bootloader:do_deploy"
 
-   SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0"
-   SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
+   SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "5.0%"
+   PREFERRED_VERSION_linux-yocto ?= "6.1%"
 
    KERNEL_IMAGETYPE = "zImage"
    KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
    KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
+   PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+
    SPL_BINARY = "MLO"
    UBOOT_SUFFIX = "img"
    UBOOT_MACHINE = "am335x_evm_defconfig"
@@ -1293,7 +1275,24 @@ located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named
 
    MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
-   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO zImage am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
+
+   # support runqemu
+   EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
+   IMAGE_CLASSES += "qemuboot"
+   QB_DEFAULT_FSTYPE = "wic"
+   QB_FSINFO = "wic:no-kernel-in-fs"
+   QB_KERNEL_ROOT = "/dev/vda2"
+   QB_SYSTEM_NAME = "qemu-system-arm"
+   QB_MACHINE = "-machine virt"
+   QB_CPU = "-cpu cortex-a15"
+   QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0 systemd.mask=systemd-networkd"
+   QB_OPT_APPEND = "-device virtio-rng-device"
+   QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
+   QB_NETWORK_DEVICE = "-device virtio-net-device,netdev=net0,mac=@MAC@"
+   QB_ROOTFS_OPT = "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"
+   QB_SERIAL_OPT = ""
+   QB_TCPSERIAL_OPT = "-device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon"
 
 The variables used to configure the machine define machine-specific properties; for
 example, machine-dependent packages, machine tunings, the type of kernel
@@ -1313,11 +1312,6 @@ Project Reference Manual.
    "virtual/xserver" is "xserver-xorg", available in
    ``poky/meta/recipes-graphics/xorg-xserver``.
 
--  :term:`XSERVER`: The packages that
-   should be installed to provide an X server and drivers for the
-   machine. In this example, the "xserver-xorg" and
-   "xf86-video-modesetting" are installed.
-
 -  :term:`MACHINE_EXTRA_RRECOMMENDS`:
    A list of machine-dependent packages not essential for booting the
    image. Thus, the build does not fail if the packages do not exist.
@@ -1335,12 +1329,15 @@ Project Reference Manual.
    needed in the root filesystem. In this case, the U-Boot recipe must
    be built for the image.
 
+   At the end of the file, we also use this setings to implement
+   ``runqemu`` support on the host machine.
+
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
    These features, which are collectively known as "tuning features",
-   are set in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
-   ``poky/meta/conf/machine/include``). In this example, the default
-   tuning file is ``cortexa8hf-neon``.
+   are set in the :term:`OpenEmbedded-Core (OE-Core)` layer. In this
+   example, the default tuning file is :oe_git:`tune-cortexa8
+   </openembedded-core/tree/meta/conf/machine/include/arm/armv7a/tune-cortexa8.inc>`.
 
    .. note::
 
@@ -1360,13 +1357,7 @@ Project Reference Manual.
 
 -  :term:`WKS_FILE`: The location of
    the :ref:`Wic kickstart <ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
-   by the OpenEmbedded build system to create a partitioned image
-   (image.wic).
-
--  :term:`IMAGE_INSTALL`:
-   Specifies packages to install into an image through the
-   :ref:`ref-classes-image` class. Recipes
-   use the :term:`IMAGE_INSTALL` variable.
+   by the OpenEmbedded build system to create a partitioned image.
 
 -  ``do_image_wic[depends]``: A task that is constructed during the
    build. In this example, the task depends on specific tools in order
@@ -1384,7 +1375,7 @@ Project Reference Manual.
 
 -  :term:`PREFERRED_VERSION_linux-yocto <PREFERRED_VERSION>`:
    Defines the version of the recipe used to build the kernel, which is
-   "5.0" in this case.
+   "6.1" in this case.
 
 -  :term:`KERNEL_IMAGETYPE`:
    The type of kernel to build for the device. In this case, the
@@ -1449,39 +1440,35 @@ The kernel recipe used to build the kernel image for the BeagleBone
 device was established in the machine configuration::
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "5.0%"
+   PREFERRED_VERSION_linux-yocto ?= "6.1%"
 
 The ``meta-yocto-bsp/recipes-kernel/linux`` directory in the layer contains
 metadata used to build the kernel. In this case, a kernel append file
-(i.e. ``linux-yocto_5.0.bbappend``) is used to override an established
-kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in
+(i.e. ``linux-yocto_6.1.bbappend``) is used to override an established
+kernel recipe (i.e. ``linux-yocto_6.1.bb``), which is located in
 :yocto_git:`/poky/tree/meta/recipes-kernel/linux`.
 
 Following is the contents of the append file::
 
-   KBRANCH:genericx86 = "v5.0/standard/base"
-   KBRANCH:genericx86-64 = "v5.0/standard/base"
-   KBRANCH:edgerouter = "v5.0/standard/edgerouter"
-   KBRANCH:beaglebone-yocto = "v5.0/standard/beaglebone"
+   KBRANCH:genericx86  = "v6.1/standard/base"
+   KBRANCH:genericx86-64  = "v6.1/standard/base"
+   KBRANCH:beaglebone-yocto = "v6.1/standard/beaglebone"
 
    KMACHINE:genericx86 ?= "common-pc"
    KMACHINE:genericx86-64 ?= "common-pc-64"
    KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-   SRCREV_machine:genericx86 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine:genericx86-64 ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine:edgerouter ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
-   SRCREV_machine:beaglebone-yocto ?= "3df4aae6074e94e794e27fe7f17451d9353cdf3d"
+   SRCREV_machine:genericx86 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
+   SRCREV_machine:genericx86-64 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
+   SRCREV_machine:beaglebone-yocto ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
 
    COMPATIBLE_MACHINE:genericx86 = "genericx86"
    COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-   COMPATIBLE_MACHINE:edgerouter = "edgerouter"
    COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-   LINUX_VERSION:genericx86 = "5.0.3"
-   LINUX_VERSION:genericx86-64 = "5.0.3"
-   LINUX_VERSION:edgerouter = "5.0.3"
-   LINUX_VERSION:beaglebone-yocto = "5.0.3"
+   LINUX_VERSION:genericx86 = "6.1.30"
+   LINUX_VERSION:genericx86-64 = "6.1.30"
+   LINUX_VERSION:beaglebone-yocto = "6.1.20"
 
 This particular append file works for all the machines that are
 part of the ``meta-yocto-bsp`` layer. The relevant statements are

documentation/contributor-guide/submit-changes.rst

@@ -279,6 +279,46 @@ Here is the general procedure on how to create patches to be sent through email:
    If necessary, rework your commits as described in
    ":ref:`contributor-guide/submit-changes:taking patch review into account`".
 
+Validating Patches with Patchtest
+=================================
+
+``patchtest`` is available in ``openembedded-core`` as a tool for making
+sure that your patches are well-formatted and contain important info for
+maintenance purposes, such as ``Signed-off-by`` and ``Upstream-Status``
+tags. Currently, it only supports testing patches for
+``openembedded-core`` branches. To setup, perform the following::
+
+    pip install -r meta/lib/patchtest/requirements.txt
+    source oe-init-build-env
+    bitbake-layers add-layer ../meta-selftest
+
+Once these steps are complete and you have generated your patch files,
+you can run ``patchtest`` like so::
+
+    patchtest --patch <patch_name>
+
+Alternatively, if you want ``patchtest`` to iterate over and test
+multiple patches stored in a directory, you can use::
+
+    patchtest --directory <directory_name>
+
+By default, ``patchtest`` uses its own modules' file paths to determine what
+repository and test suite to check patches against. If you wish to test
+patches against a repository other than ``openembedded-core`` and/or use
+a different set of tests, you can use the ``--repodir`` and ``--testdir``
+flags::
+
+    patchtest --patch <patch_name> --repodir <path/to/repo> --testdir <path/to/testdir>
+
+Finally, note that ``patchtest`` is designed to test patches in a standalone
+way, so if your patches are meant to apply on top of changes made by
+previous patches in a series, it is possible that ``patchtest`` will report
+false failures regarding the "merge on head" test.
+
+Using ``patchtest`` in this manner provides a final check for the overall
+quality of your changes before they are submitted for review by the
+maintainers.
+
 Sending the Patches via Email
 =============================
 

documentation/dev-manual/index.rst

@@ -42,6 +42,7 @@ Yocto Project Development Tasks Manual
    runtime-testing
    debugging
    licenses
+   security-subjects
    vulnerabilities
    sbom
    error-reporting-tool

documentation/dev-manual/layers.rst

@@ -128,6 +128,20 @@ Follow these general steps to create your layer without using tools:
       variable is a good way to indicate if your particular layer is
       current.
 
+
+   .. note::
+
+      A layer does not have to contain only recipes ``.bb`` or append files
+      ``.bbappend``. Generally, developers create layers using
+      ``bitbake-layers create-layer``.
+      See ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`",
+      explaining how the ``layer.conf`` file is created from a template located in
+      ``meta/lib/bblayers/templates/layer.conf``.
+      In fact, none of the variables set in ``layer.conf`` are mandatory,
+      except when :term:`BBFILE_COLLECTIONS` is present. In this case
+      :term:`LAYERSERIES_COMPAT` and :term:`BBFILE_PATTERN` have to be
+      defined too.
+
 #. *Add Content:* Depending on the type of layer, add the content. If
    the layer adds support for a machine, add the machine configuration
    in a ``conf/machine/`` file within the layer. If the layer adds

documentation/dev-manual/new-machine.rst

@@ -38,7 +38,7 @@ file or include from a lower-level configuration file are as follows:
 
 -  ``PREFERRED_PROVIDER_virtual/kernel``
 
--  :term:`MACHINE_FEATURES` (e.g. "apm screen wifi")
+-  :term:`MACHINE_FEATURES` (e.g. "screen wifi")
 
 You might also need these variables:
 

documentation/dev-manual/new-recipe.rst

@@ -409,8 +409,8 @@ Patching Code
 
 Sometimes it is necessary to patch code after it has been fetched. Any
 files mentioned in :term:`SRC_URI` whose names end in ``.patch`` or
-``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are
-treated as patches. The
+``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz``,
+``patch.bz2``, etc.) are treated as patches. The
 :ref:`ref-tasks-patch` task
 automatically applies these patches.
 

documentation/dev-manual/runtime-testing.rst

@@ -160,12 +160,6 @@ options are available:
    comments at the top of the BeagleBoneTarget
    ``meta-yocto-bsp/lib/oeqa/controllers/beaglebonetarget.py`` file.
 
--  *"EdgeRouterTarget":* Choose "EdgeRouterTarget" if you are deploying
-   images and running tests on the Ubiquiti Networks EdgeRouter Lite.
-   For information on how to use these tests, see the comments at the
-   top of the EdgeRouterTarget
-   ``meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py`` file.
-
 -  *"GrubTarget":* Choose "GrubTarget" if you are deploying images and running
    tests on any generic PC that boots using GRUB. For information on how
    to use these tests, see the comments at the top of the GrubTarget
@@ -288,7 +282,7 @@ Serial Console Connection
 -------------------------
 
 For test target classes requiring a serial console to interact with the
-bootloader (e.g. BeagleBoneTarget, EdgeRouterTarget, and GrubTarget),
+bootloader (e.g. BeagleBoneTarget and GrubTarget),
 you need to specify a command to use to connect to the serial console of
 the target machine by using the
 :term:`TEST_SERIALCONTROL_CMD`

documentation/dev-manual/security-subjects.rst

@@ -0,0 +1,189 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Dealing with Vulnerability Reports
+**********************************
+
+The Yocto Project and OpenEmbedded are open-source, community-based projects
+used in numerous products. They assemble multiple other open-source projects,
+and need to handle security issues and practices both internal (in the code
+maintained by both projects), and external (maintained by other projects and
+organizations).
+
+This manual assembles security-related information concerning the whole
+ecosystem. It includes information on reporting a potential security issue,
+the operation of the YP Security team and how to contribute in the
+related code. It is written to be useful for both security researchers and
+YP developers.
+
+How to report a potential security vulnerability?
+=================================================
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+:yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`.
+
+If you are dealing with a not-yet-released issue, or an urgent one, please send
+a message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available. This mailing list is monitored by the
+Yocto Project Security team.
+
+For each layer, you might also look for specific instructions (if any) for
+reporting potential security issues in the specific ``SECURITY.md`` file at the
+root of the repository. Instructions on how and where submit a patch are
+usually available in ``README.md``. If this is your first patch to the
+Yocto Project/OpenEmbedded, you might want to have a look into the
+Contributor's Manual section
+":ref:`contributor-guide/submit-changes:preparing changes for submission`".
+
+Branches maintained with security fixes
+---------------------------------------
+
+See the
+:ref:`Release process <ref-manual/release-process:Stable Release Process>`
+documentation for details regarding the policies and maintenance of stable
+branches.
+
+The :yocto_wiki:`Releases page </Releases>` contains a list
+of all releases of the Yocto Project. Versions in gray are no longer actively
+maintained with security patches, but well-tested patches may still be accepted
+for them for significant issues.
+
+Security-related discussions at the Yocto Project
+-------------------------------------------------
+
+We have set up two security-related mailing lists:
+
+  -  Public List: yocto [dash] security [at] yoctoproject[dot] org
+
+    This is a public mailing list for anyone to subscribe to. This list is an
+    open list to discuss public security issues/patches and security-related
+    initiatives. For more information, including subscription information,
+    please see the  :yocto_lists:`yocto-security mailing list info page </g/yocto-security>`.
+
+  - Private List: security [at] yoctoproject [dot] org
+
+    This is a private mailing list for reporting non-published potential
+    vulnerabilities. The list is monitored by the Yocto Project Security team.
+
+
+What you should do if you find a security vulnerability
+-------------------------------------------------------
+
+If you find a security flaw: a crash, an information leakage, or anything that
+can have a security impact if exploited in any Open Source software built or
+used by the Yocto Project, please report this to the Yocto Project Security
+Team. If you prefer to contact the upstream project directly, please send a
+copy to the security team at the Yocto Project as well. If you believe this is
+highly sensitive information, please report the vulnerability in a secure way,
+i.e. encrypt the email and send it to the private list. This ensures that
+the exploit is not leaked and exploited before a response/fix has been generated.
+
+Security team
+=============
+
+The Yocto Project/OpenEmbedded security team coordinates the work on security
+subjects in the project. All general discussion takes place publicly. The
+Security Team only uses confidential communication tools to deal with private
+vulnerability reports before they are released.
+
+Security team appointment
+-------------------------
+
+The Yocto Project Security Team consists of at least three members. When new
+members are needed, the Yocto Project Technical Steering Committee (YP TSC)
+asks for nominations by public channels including a nomination deadline.
+Self-nominations are possible. When the limit time is
+reached, the YP TSC posts the list of candidates for the comments of project
+participants and developers. Comments may be sent publicly or privately to the
+YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded
+Technical Steering Committee (OE TSC) and the final list of the team members
+is announced publicly. The aim is to have people representing technical
+leadership, security knowledge and infrastructure present with enough people
+to provide backup/coverage but keep the notification list small enough to
+minimize information risk and maintain trust.
+
+YP Security Team members may resign at any time.
+
+Security Team Operations
+------------------------
+
+The work of the Security Team might require high confidentiality. Team members
+are individuals selected by merit and do not represent the companies they work
+for. They do not share information about confidential issues outside of the team
+and do not hint about ongoing embargoes.
+
+Team members can bring in domain experts as needed. Those people should be
+added to individual issues only and adhere to the same standards as the YP
+Security Team.
+
+The YP security team organizes its meetings and communication as needed.
+
+When the YP Security team receives a report about a potential security
+vulnerability, they quickly analyze and notify the reporter of the result.
+They might also request more information.
+
+If the issue is confirmed and affects the code maintained by the YP, they
+confidentially notify maintainers of that code and work with them to prepare
+a fix.
+
+If the issue is confirmed and affects an upstream project, the YP security team
+notifies the project. Usually, the upstream project analyzes the problem again.
+If they deem it a real security problem in their software, they develop and
+release a fix following their security policy. They may want to include the
+original reporter in the loop. There is also sometimes some coordination for
+handling patches, backporting patches etc, or just understanding the problem
+or what caused it.
+
+When the fix is publicly available, the YP security team member or the
+package maintainer sends patches against the YP code base, following usual
+procedures, including public code review.
+
+What Yocto Security Team does when it receives a security vulnerability
+-----------------------------------------------------------------------
+
+The YP Security Team team performs a quick analysis and would usually report
+the flaw to the upstream project. Normally the upstream project analyzes the
+problem. If they deem it a real security problem in their software, they
+develop and release a fix following their own security policy. They may want
+to include the original reporter in the loop. There is also sometimes some
+coordination for handling patches, backporting patches etc, or just
+understanding the problem or what caused it.
+
+The security policy of the upstream project might include a notification to
+Linux distributions or other important downstream projects in advance to
+discuss coordinated disclosure. These mailing lists are normally non-public.
+
+When the upstream project releases a version with the fix, they are responsible
+for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and
+the CVE record published.
+
+If an upstream project does not respond quickly
+-----------------------------------------------
+
+If an upstream project does not fix the problem in a reasonable time,
+the Yocto's Security Team will contact other interested parties (usually
+other distributions) in the community and together try to solve the
+vulnerability as quickly as possible.
+
+The Yocto Project Security team adheres to the 90 days disclosure policy
+by default. An increase of the embargo time is possible when necessary.
+
+Current Security Team members
+-----------------------------
+
+For secure communications, please send your messages encrypted using the GPG
+keys. Remember, message headers are not encrypted so do not include sensitive
+information in the subject line.
+
+  -  Ross Burton: <ross@burtonini.com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__
+
+  -  Michael Halstead: <mhalstead [at] linuxfoundation [dot] org>
+     `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__
+     or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__
+
+  -  Richard Purdie: <richard.purdie@linuxfoundation.org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__
+
+  -  Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__
+
+  -  Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__

documentation/dev-manual/start.rst

@@ -88,27 +88,15 @@ particular working environment and set of practices.
        For information about BitBake, see the
        :doc:`bitbake:index`.
 
-    It is relatively easy to set up Git services and create
-    infrastructure like :yocto_git:`/`, which is based on
-    server software called ``gitolite`` with ``cgit`` being used to
-    generate the web interface that lets you view the repositories. The
-    ``gitolite`` software identifies users using SSH keys and allows
+    It is relatively easy to set up Git services and create infrastructure like
+    :yocto_git:`/`, which is based on server software called
+    `Gitolite <https://gitolite.com>`__
+    with `cgit <https://git.zx2c4.com/cgit/about/>`__ being used to
+    generate the web interface that lets you view the repositories.
+    ``gitolite`` identifies users using SSH keys and allows
     branch-based access controls to repositories that you can control as
     little or as much as necessary.
 
-    .. note::
-
-       The setup of these services is beyond the scope of this manual.
-       However, here are sites describing how to perform setup:
-
-       -  `Gitolite <https://gitolite.com>`__: Information for
-          ``gitolite``.
-
-       -  `Interfaces, frontends, and
-          tools <https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools>`__:
-          Documentation on how to create interfaces and frontends for
-          Git.
-
 #.  *Set up the Application Development Machines:* As mentioned earlier,
     application developers are creating applications on top of existing
     software stacks. Following are some best practices for setting up

documentation/dev-manual/vulnerabilities.rst

@@ -129,31 +129,97 @@ NVD about CVE entries can be provided through the `NVD contact form <https://nvd
 Fixing vulnerabilities in recipes
 =================================
 
-If a CVE security issue impacts a software component, it can be fixed by updating to a newer
-version of the software component, by applying a patch or by marking it as patched via
-:term:`CVE_STATUS` variable flag. For Poky and OE-Core master branches, updating
-to a newer software component release with fixes is the best option, but patches can be applied
-if releases are not yet available.
+Suppose a CVE security issue impacts a software component. In that case, it can
+be fixed by updating to a newer version, by applying a patch, or by marking it
+as patched via :term:`CVE_STATUS` variable flag. For Poky and OE-Core master
+branches, updating to a more recent software component release with fixes is
+the best option, but patches can be applied if releases are not yet available.
 
-For stable branches, it is preferred to apply patches for the issues. For some software
-components minor version updates can also be applied if they are backwards compatible.
+For stable branches, we want to avoid API (Application Programming Interface)
+or ABI (Application Binary Interface) breakages. When submitting an update,
+a minor version update of a component is preferred if the version is
+backward-compatible. Many software components have backward-compatible stable
+versions, with a notable example of the Linux kernel. However, if the new
+version does or likely might introduce incompatibilities, extracting and
+backporting patches is preferred.
 
 Here is an example of fixing CVE security issues with patch files,
-an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
+an example from the :oe_layerindex:`ffmpeg recipe for dunfell </layerindex/recipe/122174>`::
 
    SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
+              file://mips64_cpu_detection.patch \
+              file://CVE-2020-12284.patch \
               file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
-              file://fix-CVE-2020-20446.patch \
-              file://fix-CVE-2020-20453.patch \
-              file://fix-CVE-2020-22015.patch \
-              file://fix-CVE-2020-22021.patch \
-              file://fix-CVE-2020-22033-CVE-2020-22019.patch \
-              file://fix-CVE-2021-33815.patch \
+              file://CVE-2021-3566.patch \
+              file://CVE-2021-38291.patch \
+              file://CVE-2022-1475.patch \
+              file://CVE-2022-3109.patch \
+              file://CVE-2022-3341.patch \
+              file://CVE-2022-48434.patch \
+          "
 
-A good practice is to include the CVE identifier in both the patch file name
-and inside the patch file commit message using the format::
+The recipe has both generic and security-related fixes. The CVE patch files are named
+according to the CVE they fix.
 
-   CVE: CVE-2020-22033
+When preparing the patch file, take the original patch from the upstream repository.
+Do not use patches from different distributions, except if it is the only available source.
+
+Modify the patch adding OE-related metadata. We will follow the example of the
+``CVE-2022-3341.patch``.
+
+The original `commit message <https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e.patch/>`__
+is::
+
+   From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001
+   From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+   Date: Wed, 23 Feb 2022 10:31:59 +0800
+   Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream
+
+   Check for failure of avformat_new_stream() and propagate
+   the error code.
+
+   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
+   ---
+    libavformat/nutdec.c | 16 ++++++++++++----
+    1 file changed, 12 insertions(+), 4 deletions(-)
+
+
+For the correct operations of the ``cve-check``, it requires the CVE
+identification in a ``CVE:`` tag of the patch file commit message using
+the format::
+
+   CVE: CVE-2022-3341
+
+It is also recommended to add the ``Upstream-Status:`` tag with a link
+to the original patch and sign-off by people working on the backport.
+If there are any modifications to the original patch, note them in
+the ``Comments:`` tag.
+
+With the additional information, the header of the patch file in OE-core becomes::
+
+   From 9cf652cef49d74afe3d454f27d49eb1a1394951e Mon Sep 17 00:00:00 2001
+   From: Jiasheng Jiang <jiasheng@iscas.ac.cn>
+   Date: Wed, 23 Feb 2022 10:31:59 +0800
+   Subject: [PATCH] avformat/nutdec: Add check for avformat_new_stream
+
+   Check for failure of avformat_new_stream() and propagate
+   the error code.
+
+   Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
+
+   CVE: CVE-2022-3341
+
+   Upstream-Status: Backport [https://github.com/FFmpeg/FFmpeg/commit/9cf652cef49d74afe3d454f27d49eb1a1394951e]
+
+   Comments: Refreshed Hunk
+   Signed-off-by: Narpat Mali <narpat.mali@windriver.com>
+   Signed-off-by: Bhabu Bindu <bhabu.bindu@kpit.com>
+   ---
+    libavformat/nutdec.c | 16 ++++++++++++----
+    1 file changed, 12 insertions(+), 4 deletions(-)
+
+A good practice is to include the CVE identifier in the patch file name, the patch file
+commit message and optionally in the recipe commit message.
 
 CVE checker will then capture this information and change the CVE status to ``Patched``
 in the generated reports.
@@ -161,8 +227,16 @@ in the generated reports.
 If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
 version or other reasons, the CVE can be marked as ``Ignored`` by using
 the :term:`CVE_STATUS` variable flag with appropriate reason which is mapped to ``Ignored``.
-As mentioned previously, if data in the CVE database is wrong, it is recommend to fix those
-issues in the CVE database directly.
+The entry should have the format like::
+
+   CVE_STATUS[CVE-2016-10642] = "cpe-incorrect: This is specific to the npm package that installs cmake, so isn't relevant to OpenEmbedded"
+
+As mentioned previously, if data in the CVE database is wrong, it is recommended
+to fix those issues in the CVE database (NVD in the case of OE-core and Poky)
+directly.
+
+Note that if there are many CVEs with the same status and reason, those can be
+shared by using the :term:`CVE_STATUS_GROUPS` variable.
 
 Recipes can be completely skipped by CVE check by including the recipe name in
 the :term:`CVE_CHECK_SKIP_RECIPE` variable.

documentation/dev-manual/wic.rst

@@ -140,19 +140,19 @@ command to return the available Wic images as follows::
 
    $ wic list images
      genericx86                    		Create an EFI disk image for genericx86*
-     edgerouter                    		Create SD card image for Edgerouter
      beaglebone-yocto              		Create SD card image for Beaglebone
-     qemux86-directdisk            		Create a qemu machine 'pcbios' direct disk image
-     systemd-bootdisk              		Create an EFI disk image with systemd-boot
-     mkhybridiso                   		Create a hybrid ISO image
+     qemuriscv                     		Create qcow2 image for RISC-V QEMU machines
      mkefidisk                     		Create an EFI disk image
-     sdimage-bootpart              		Create SD card image with a boot partition
+     qemuloongarch                 		Create qcow2 image for LoongArch QEMU machines
      directdisk-multi-rootfs       		Create multi rootfs image using rootfs plugin
      directdisk                    		Create a 'pcbios' direct disk image
-     directdisk-bootloader-config  		Create a 'pcbios' direct disk image with custom bootloader config
-     qemuriscv                     		Create qcow2 image for RISC-V QEMU machines
+     efi-bootdisk                  		
+     mkhybridiso                   		Create a hybrid ISO image
      directdisk-gpt                		Create a 'pcbios' direct disk image
-     efi-bootdisk
+     systemd-bootdisk              		Create an EFI disk image with systemd-boot
+     sdimage-bootpart              		Create SD card image with a boot partition
+     qemux86-directdisk            		Create a qemu machine 'pcbios' direct disk image
+     directdisk-bootloader-config  		Create a 'pcbios' direct disk image with custom bootloader config
 
 Once you know the list of available
 Wic images, you can use ``help`` with the command to get help on a
@@ -284,15 +284,17 @@ Use the following command to list the available kickstart files::
    $ wic list images
      genericx86                    		Create an EFI disk image for genericx86*
      beaglebone-yocto              		Create SD card image for Beaglebone
-     edgerouter                    		Create SD card image for Edgerouter
-     qemux86-directdisk            		Create a QEMU machine 'pcbios' direct disk image
-     directdisk-gpt                		Create a 'pcbios' direct disk image
+     qemuriscv                     		Create qcow2 image for RISC-V QEMU machines
      mkefidisk                     		Create an EFI disk image
-     directdisk                    		Create a 'pcbios' direct disk image
-     systemd-bootdisk              		Create an EFI disk image with systemd-boot
-     mkhybridiso                   		Create a hybrid ISO image
-     sdimage-bootpart              		Create SD card image with a boot partition
+     qemuloongarch                 		Create qcow2 image for LoongArch QEMU machines
      directdisk-multi-rootfs       		Create multi rootfs image using rootfs plugin
+     directdisk                    		Create a 'pcbios' direct disk image
+     efi-bootdisk                  		
+     mkhybridiso                   		Create a hybrid ISO image
+     directdisk-gpt                		Create a 'pcbios' direct disk image
+     systemd-bootdisk              		Create an EFI disk image with systemd-boot
+     sdimage-bootpart              		Create SD card image with a boot partition
+     qemux86-directdisk            		Create a qemu machine 'pcbios' direct disk image
      directdisk-bootloader-config  		Create a 'pcbios' direct disk image with custom bootloader config
 
 When you use an existing file, you

documentation/kernel-dev/advanced.rst

@@ -69,8 +69,7 @@ to indicate the branch.
    You can use the :term:`KBRANCH` value to define an alternate branch typically
    with a machine override as shown here from the ``meta-yocto-bsp`` layer::
 
-           KBRANCH:edgerouter = "standard/edgerouter"
-
+      KBRANCH:beaglebone-yocto = "standard/beaglebone"
 
 The linux-yocto style recipes can optionally define the following
 variables:

documentation/kernel-dev/common.rst

@@ -387,13 +387,13 @@ Creating the Append File
 
 You create this file in your custom layer. You also name it accordingly
 based on the linux-yocto recipe you are using. For example, if you are
-modifying the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` recipe,
+modifying the ``meta/recipes-kernel/linux/linux-yocto_6.1.bb`` recipe,
 the append file will typically be located as follows within your custom
 layer:
 
 .. code-block:: none
 
-   your-layer/recipes-kernel/linux/linux-yocto_4.12.bbappend
+   your-layer/recipes-kernel/linux/linux-yocto_6.1.bbappend
 
 The append file should initially extend the
 :term:`FILESPATH` search path by
@@ -421,35 +421,31 @@ As an example, consider the following append file used by the BSPs in
 
 .. code-block:: none
 
-   meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
+   meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend
 
 Here are the contents of this file. Be aware that the actual commit ID
 strings in this example listing might be different than the actual
 strings in the file from the ``meta-yocto-bsp`` layer upstream::
 
-   KBRANCH:genericx86  = "standard/base"
-   KBRANCH:genericx86-64  = "standard/base"
+  KBRANCH:genericx86  = "v6.1/standard/base"
+  KBRANCH:genericx86-64  = "v6.1/standard/base"
+  KBRANCH:beaglebone-yocto = "v6.1/standard/beaglebone"
 
-   KMACHINE:genericx86 ?= "common-pc"
-   KMACHINE:genericx86-64 ?= "common-pc-64"
-   KBRANCH:edgerouter = "standard/edgerouter"
-   KBRANCH:beaglebone = "standard/beaglebone"
+  KMACHINE:genericx86 ?= "common-pc"
+  KMACHINE:genericx86-64 ?= "common-pc-64"
+  KMACHINE:beaglebone-yocto ?= "beaglebone"
 
-   SRCREV_machine:genericx86    ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
-   SRCREV_machine:genericx86-64 ?= "d09f2ce584d60ecb7890550c22a80c48b83c2e19"
-   SRCREV_machine:edgerouter ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
-   SRCREV_machine:beaglebone ?= "b5c8cfda2dfe296410d51e131289fb09c69e1e7d"
+  SRCREV_machine:genericx86 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
+  SRCREV_machine:genericx86-64 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
+  SRCREV_machine:beaglebone-yocto ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
 
+  COMPATIBLE_MACHINE:genericx86 = "genericx86"
+  COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
+  COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-   COMPATIBLE_MACHINE:genericx86 = "genericx86"
-   COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-   COMPATIBLE_MACHINE:edgerouter = "edgerouter"
-   COMPATIBLE_MACHINE:beaglebone = "beaglebone"
-
-   LINUX_VERSION:genericx86 = "4.12.7"
-   LINUX_VERSION:genericx86-64 = "4.12.7"
-   LINUX_VERSION:edgerouter = "4.12.10"
-   LINUX_VERSION:beaglebone = "4.12.10"
+  LINUX_VERSION:genericx86 = "6.1.30"
+  LINUX_VERSION:genericx86-64 = "6.1.30"
+  LINUX_VERSION:beaglebone-yocto = "6.1.20"
 
 This append file
 contains statements used to support several BSPs that ship with the
@@ -1005,7 +1001,7 @@ Section.
       the following sequence of commands::
 
               $ cd poky/build
-              $ bitbake -c cleanall yocto-linux
+              $ bitbake -c cleanall linux-yocto
               $ bitbake core-image-minimal -c cleanall
               $ bitbake core-image-minimal
               $ runqemu qemux86

documentation/migration-guides/migration-4.3.rst

@@ -26,15 +26,26 @@ no longer the default supported configuration. This setting does not affect whic
 kernel versions SDKs will run against and does not affect which versions of the kernel
 can be used to run builds.
 
+.. _migration-4.3-layername-override:
+
 Layername override implications
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Code can now know which layer a recipe is coming from through the newly added
 :term:`FILE_LAYERNAME` variable and the ``layer-<layername> override``. This is being used
 for enabling QA checks on a per layer basis. For existing code this has the
-side effect that the QA checks will apply to things being bbappended to recipes
-from other layers. Those other layers would need to have patch upstream status
-entries for patches being bbappended for example.
+side effect that the QA checks will apply to recipes being bbappended
+from other layers - for example, patches added through such bbappends will now
+need to have the "Upstream-Status" specified in the patch header.
+
+.. _migration-4.3-compiling-changes:
+
+Compiling changes
+~~~~~~~~~~~~~~~~~
+
+-  Code on 32 bit platforms is now compiled with largefile support and 64
+   bit ``time_t``, to avoid the Y2038 time overflow issue. This breaks the ABI
+   and could break existing programs in untested layers.
 
 .. _migration-4.3-supported-distributions:
 
@@ -43,10 +54,31 @@ Supported distributions
 
 This release supports running BitBake on new GNU/Linux distributions:
 
+-  Ubuntu 22.10
+-  Fedora 38
+-  Debian 12
+-  CentOS Stream 8
+-  AlmaLinux 8.8
+-  AlmaLinux 9.2
+
 On the other hand, some earlier distributions are no longer supported:
 
+-  Fedora 36
+-  AlmaLinux 8.7
+-  AlmaLinux 9.1
+
 See :ref:`all supported distributions <system-requirements-supported-distros>`.
 
+.. _migration-4.3-removed-machines:
+
+edgerouter machine removed
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The ``edgerouter`` reference BSP for the MIPS architecture in ``meta-yocto-bsp``
+has been removed as the hardware has been unavailable for some time. There is no
+suitable reference MIPS hardware to replace it with, but the MIPS architecture
+will continue to get coverage via QEMU build/boot testing.
+
 .. _migration-4.3-go-changes:
 
 Go language changes
@@ -55,7 +87,9 @@ Go language changes
 -  Support for the Glide package manager has been removed, as ``go mod``
    has become the standard.
 
-Systemd changes
+.. _migration-4.3-systemd-changes:
+
+systemd changes
 ~~~~~~~~~~~~~~~
 
 Upstream systemd is now more strict on filesystem layout and the ``usrmerge``
@@ -70,14 +104,14 @@ Recipe changes
 -  Runtime testing of ptest now fails if no test results are returned by
    any given ptest.
 
-.. _migration-4.3-class-changes:
+.. _migration-4.3-deprecated-variables:
 
-Class changes
-~~~~~~~~~~~~~
+Deprecated variables
+~~~~~~~~~~~~~~~~~~~~
 
--  The ``perl-version`` class no longer provides the ``PERLVERSION`` and ``PERLARCH`` variables
-   as there were no users in any core layer. The functions for this functionality
-   are still available.
+The following variables have been deprecated:
+
+-  :term:`CVE_CHECK_IGNORE`: use :term:`CVE_STATUS` instead.
 
 .. _migration-4.3-removed-variables:
 
@@ -86,8 +120,13 @@ Removed variables
 
 The following variables have been removed:
 
+-  ``AUTHOR``
 -  ``PERLARCH``
 -  ``PERLVERSION``
+-  ``QEMU_USE_SLIRP`` - add ``slirp`` to ``TEST_RUNQEMUPARAMS`` instead.
+-  ``SERIAL_CONSOLES_CHECK`` - no longer necessary because all
+   consoles listed in :term:`SERIAL_CONSOLES` are checked for their existence
+   before a ``getty`` is started.
 
 .. _migration-4.3-removed-recipes:
 
@@ -96,7 +135,15 @@ Removed recipes
 
 The following recipes have been removed in this release:
 
--  ``glide``, as explained in :ref:`migration-4.3-go-changes`.
+-  ``apmd``: obsolete (``apm`` in :term:`MACHINE_FEATURES` also removed).
+-  ``cve-update-db-native``: functionally replaced by ``cve-update-nvd2-native``
+-  ``gcr3``: no longer needed by core recipes, moved to meta-gnome (gcr, i.e. version 4.x, is still provided).
+-  ``glide``: as explained in :ref:`migration-4.3-go-changes`.
+-  ``libdmx``: obsolete
+-  ``linux-yocto`` version 5.15 (versions 6.1 and 6.5 provided instead).
+-  ``python3-async``: obsolete - no longer needed by ``python3-gitdb`` or any other core recipe
+-  ``rust-hello-world``: there are sufficient other Rust recipes and test cases such that this is no longer needed.
+
 
 .. _migration-4.3-removed-classes:
 
@@ -105,6 +152,90 @@ Removed classes
 
 The following classes have been removed in this release:
 
+-  ``glide``: as explained in :ref:`migration-4.3-go-changes`.
+
+
+Output file naming changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In 4.3 there are some minor differences in image and SDK output file names.
+If you rely on the existing naming (e.g. in external scripts) you may need to
+either modify configuration or adapt to the new naming. Further details:
+
+-  :term:`IMAGE_NAME` and :term:`IMAGE_LINK_NAME` now include the
+   :term:`IMAGE_NAME_SUFFIX` value directly. In practical terms, this means
+   that ``.rootfs`` will now appear in image output file names. If you do not
+   wish to have the ``.rootfs`` suffix used, you can just set
+   :term:`IMAGE_NAME_SUFFIX` to "" and this will now be consistently respected
+   in both the image file and image file symlink names. As part of this change,
+   support for the ``imgsuffix`` task varflag has been dropped (mostly
+   an internal implementation detail, but if you were implementing a custom
+   image construction with a task in a similar manner to ``do_bootimg``
+   you may have been using this).
+
+-  :term:`SDK_NAME` now includes the values of :term:`IMAGE_BASENAME` and
+   :term:`MACHINE` so that they are unique when building SDKs for different
+   images and machines.
+
+
+
+.. _migration-4.3-pr-pe:
+
+Versioning changes
+~~~~~~~~~~~~~~~~~~
+
+-  :term:`PR` values have been removed from all core recipes - distro maintainers
+   who make use of :term:`PR` values would need to curate these already so the
+   sparsely set base values would not be that useful anymore. If you have been
+   relying on these (i.e. you are maintaining a binary package feed where package
+   versions should only ever increase), double-check the output (perhaps with the
+   help of the :ref:`ref-classes-buildhistory` class) to ensure that package
+   versions are consistent.
+
+-  The :term:`PR` value can no longer be set from the recipe file name - this
+   was rarely used, but in any case is no longer supported.
+
+-  :term:`PE` and :term:`PR` are no longer included in the work directory path
+   (:term:`WORKDIR`). This may break some tool assumptions about directory paths,
+   but those should really be querying paths from the build system (or not poking
+   into :term:`WORKDIR` externally).
+
+-  Source revision information has been moved from :term:`PV` to :term:`PKGV`.
+   The user visible effect of this change is that :term:`PV` will no longer have
+   revision information in it and this will now be appended to the :term:`PV`
+   value through :term:`PKGV` when the packages are written out (as long as "+"
+   is present in the :term:`PKGV` value). Since :term:`PV` is used in
+   :term:`STAMP` and :term:`WORKDIR`, you may notice small directory naming and
+   stamp naming changes.
+
+-  The :term:`SRCPV` variable is no longer needed in :term:`PV`, but since
+   the default :term:`SRCPV` value is now "", using it is effectively now just a
+   null operation - you can remove it (leaving behind the "+") , but it is not
+   yet required to do so.
+
+
+.. _migration-4.3-qemu-changes:
+
+QEMU changes
+~~~~~~~~~~~~
+
+-  The ``runqemu`` script no longer systematically adds two serial ports
+   (``--serial null`` and ``-serial mon:stdio``) to the QEMU emulated machine
+   if the user already adds such ports through the ``QB_OPT_APPEND`` setting.
+
+   If the user adds one port, only ``--serial null`` is added, and
+   ``-serial mon:stdio`` is no longer passed. If the user adds more than one
+   port, ``--serial null`` is no longer added either. This can break some
+   existing QEMU based configurations expecting such serial ports to be added
+   when ``runqemu`` is executed.
+
+   This change was made to avoid exceeding two serial ports, which interferes
+   with automated testing.
+
+-  ``runqemu`` now uses the ``ip tuntap`` command instead of ``tunctl``, and
+   thus ``tunctl`` is no longer built by the ``qemu-helper-native`` recipe; if
+   for some reason you were calling ``tunctl`` directly from your own scripts
+   you should switch to calling ``ip tuntap`` instead.
 
 .. _migration-4.3-misc-changes:
 
@@ -115,5 +246,7 @@ Miscellaneous changes
    ``virtual/XXX`` provider/dependencies where a ``PREFIX`` was used as well,
    as we don't need both and it made automated dependency rewriting
    unnecessarily complex. In general this only affects internal toolchain
-   dependencies so isn't end user visible.
+   dependencies so isn't end user visible, but if for some reason you have
+   custom classes or recipes that rely upon the old providers then you will
+   need to update those.
 

documentation/migration-guides/release-notes-4.3.rst

@@ -1,16 +1,24 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
-Release notes for 4.3 (nandbield)
-----------------------------------
+Release notes for 4.3 (nanbield)
+--------------------------------
 
 New Features / Enhancements in 4.3
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--  Linux kernel 6.x, glibc 2.xx and ~xxx other recipe upgrades
+-  Linux kernel 6.5 and 6.1, gcc 13, glibc 2.38, LLVM 17, and over 300 other recipe upgrades
+
+-  The autobuilder's shared-state artefacts are now available over the `jsDelivr
+   <https://jsdelivr.com>`__ Content Delivery Network (CDN).
+   See :term:`SSTATE_MIRRORS`.
 
 -  New variables:
 
-   -  :term:`FILE_LAYERNAME`: bitbake now sets this to the name of the layer containing the recipe
+   -  :term:`CVE_CHECK_STATUSMAP`, :term:`CVE_STATUS`, :term:`CVE_STATUS_GROUPS`,
+      replacing the deprecated :term:`CVE_CHECK_IGNORE`.
+
+   -  :term:`FILE_LAYERNAME`: bitbake now sets this to the name of the layer
+      containing the recipe
 
    -  :term:`FIT_ADDRESS_CELLS` and :term:`UBOOT_FIT_ADDRESS_CELLS`.
       See details below.
@@ -19,62 +27,257 @@ New Features / Enhancements in 4.3
 
    -  :term:`KERNEL_DTBVENDORED`: whether to keep vendor subdirectories.
 
+   -  :term:`KERNEL_LOCALVERSION`: to add a string to the kernel version
+      information.
+
+   -  :term:`KERNEL_STRIP`: to specify the command to strip the kernel binary.
+
    -  :term:`LICENSE_FLAGS_DETAILS`: add extra details about a recipe license
       in case it is not allowed by :term:`LICENSE_FLAGS_ACCEPTED`.
 
-- Layername functionality available through overrides
+   -  :term:`MESON_TARGET`: to compile a specific Meson target instead of the
+      default ones.
 
-  Code can now know which layer a recipe is coming from through the newly added :term:`FILE_LAYERNAME`
-  variable. This has been added as an override of the form ``layer-<layername>``. In particular,
-  this means QA checks can now be layer specific, for example::
+   -  :term:`OEQA_REPRODUCIBLE_TEST_PACKAGE`: to restrict package managers used
+      in reproducibility testing.
 
-    ERROR_QA:layer-core:append = " patch-status"
+-  Layername functionality available through overrides
 
-  which will enable the ``patch-status`` QA check for the core layer.
+   Code can now know which layer a recipe is coming from through the newly added :term:`FILE_LAYERNAME`
+   variable. This has been added as an override of the form ``layer-<layername>``. In particular,
+   this means QA checks can now be layer specific, for example::
+
+      ERROR_QA:layer-core:append = " patch-status"
+
+   This will enable the ``patch-status`` QA check for the core layer.
 
 -  Architecture-specific enhancements:
 
+   -  RISCV support is now enabled in LLVM 17.
+
+   -  Loongarch support in the :ref:`ref-classes-linuxloader` class and
+      ``core-image-minimal-initramfs`` image.
+
+   -  The ``arch-armv8`` and ``arch-armv9`` architectures are now given
+      `Scalable Vector Extension (SVE)
+      <https://developer.arm.com/documentation/100891/0612/sve-overview/introducing-sve>`__
+      based tune options. Commits:
+      :yocto_git:`1 </poky/commit/?id=e4be03be5be62e367a40437a389121ef97d6cff3>`,
+      :yocto_git:`2 </poky/commit/?id=8cd5d264af4c346730531cb98ae945ab862dbd69>`.
+
+   -  Many changes to support 64-bit ``time_t`` on 32-bit architectures
+
 -  Kernel-related enhancements:
 
+   - The default kernel is the current stable (6.5), and there is also support
+     for the latest long-term release (6.1).
+
+   - The list of fixed kernel CVEs is updated regularly using data from
+     `linuxkernelcves.com <https://linuxkernelcves.com>`__.
+
+   - A ``showconfig`` task was added to the :ref:`ref-classes-cml1` class, to
+     easily examine the final generated ``.config`` file.
+
 -  New core recipes:
 
--  New classes:
+   -  `appstream <https://github.com/ximion/appstream>`__: a collaborative effort
+      for making machine-readable software metadata easily available
+      (from meta-oe)
 
-   - A ``ptest-cargo`` class was added to allow Cargo based recipes to easily add ptests
+   -  `cargo-c-native <https://crates.io/crates/cargo-c>`__: cargo applet to build
+      and install C-ABI compatible dynamic and static libraries
 
--  QEMU/runqemu enhancements:
+   -  `libadwaita <https://gitlab.gnome.org/GNOME/libadwaita>`__: Building blocks
+      for modern GNOME applications (from meta-gnome)
 
-   -  QEMU has been upgraded to version 8.0
+   -  `libtraceevent <https://git.kernel.org/pub/scm/libs/libtrace/libtracefs.git/>`__:
+      API to access the kernel tracefs directory (from meta-openembedded)
+
+   -  `libxmlb <https://github.com/hughsie/libxmlb>`__: A library to help create
+       and query binary XML blobs (from meta-oe)
+
+   -  ``musl-legacy-error``: glibc ``error()`` API implementation still needed
+      by a few packages.
+
+   -  `python3-beartype <https://beartype.readthedocs.io>`__, unbearably fast
+      runtime type checking in pure Python.
+
+   -  `python3-booleanpy <https://github.com/bastikr/boolean.py>`__: Define boolean
+      algebras, create and parse boolean expressions and create custom boolean DSL
+      (from meta-python)
+
+   -  `python3-calver <https://github.com/di/calver>`__: Setuptools extension for
+      CalVer package versions
+
+   -  `python3-click <http://click.pocoo.org/>`__: A simple wrapper around optparse
+      for powerful command line utilities (from meta-python)
+
+   -  ``python3-dtc``: Python Library for the Device Tree Compiler (from
+      meta-virtualization)
+
+   -  `python3-isodate <https://github.com/gweis/isodate/>`__: ISO 8601 date/time
+      parser (from meta-python)
+
+   -  `python3-license-expression <https://github.com/nexB/license-expression>`__:
+      Utility library to parse, compare, simplify and normalize license expressions
+      (from meta-python)
+
+   -  `python3-rdflib <https://github.com/RDFLib/rdflib>`__: a pure Python package
+      for working with RDF (from meta-python)
+
+   -  `python3-spdx-tools <https://github.com/spdx/tools-python>`__,
+      tools for SPDX validation and conversion.
+
+   -  `python3-trove-classifiers <https://github.com/pypa/trove-classifiers>`__:
+      Canonical source for classifiers on PyPI (pypi.org)
+
+   -  `python3-uritools <https://github.com/tkem/uritools/>`__, replacement for
+      the ``urllib.parse`` module.
+
+   -  `python3-xmltodict <https://github.com/martinblech/xmltodict>`__: Makes
+      working with XML feel like you are working with JSON (from meta-python)
+
+   -  `ttyrun <https://github.com/ibm-s390-linux/s390-tools>`__, starts
+      ``getty`` programs only when a terminal exists, preventing respawns
+      through the ``init`` program. This enabled removing the
+      ``SERIAL_CONSOLES_CHECK`` variable.
+
+   -  ``vulkan-validation-layers``: Khronos official validation layers to assist in
+      verifying that applications correctly use the
+      `Vulkan API <https://www.khronos.org/vulkan>`__.
+
+   -  `xcb-util-cursor <http://xcb.freedesktop.org/XcbUtil/>`__: XCB port of
+      libXcursor (from meta-oe)
+
+-  QEMU / ``runqemu`` enhancements:
+
+   -  QEMU has been upgraded to version 8.1
+
+   -  Many updates to the ``runqemu`` command.
+
+   -  The ``qemu-system-native`` recipe is now built with PNG support, which could be
+      useful to grab screenshots for error reporting purposes.
 
 -  Rust improvements:
 
-   -  Rust has been upgraded to version 1.69
+   -  Rust has been upgraded to version 1.70
 
--  Image-related enhancements:
+   -  New ``ptest-cargo`` class was added to allow Cargo based recipes to easily add ptests
+
+   -  New :ref:`ref-classes-cargo_c` class was added to allow recipes to make Rust code
+      available to C and C++ programs. See
+      ``meta-selftest/recipes-devtools/rust/rust-c-lib-example_git.bb`` for an example.
 
 -  wic Image Creator enhancements:
 
+   -  ``bootimg-efi``: if ``fixed-size`` is set then use that for mkdosfs
+
+   -  ``bootimg-efi``: stop hardcoding VMA offsets, as required by systemd-boot v254
+      (and dracut/ukify)
+
+   -  ``bootimg-pcbios``: use kernel name from :term:`KERNEL_IMAGETYPE` instead of
+      hardcoding ``vmlinuz``
+
+   -  Added new ``gpt-hybrid`` option to ``ptable_format`` (formatting a disk with a hybrid
+      MBR and GPT partition scheme)
+
+   -  Use ``part_name`` in default imager when defined
+
+   -  Added ``--hidden`` argument to default imager to avoid MS Windows prompting to
+      format partition after flashing to a USB stick/SD card
+
 -  FIT image related improvements:
 
    -  New :term:`FIT_ADDRESS_CELLS` and :term:`UBOOT_FIT_ADDRESS_CELLS` variables allowing
       to specify 64 bit addresses, typically for loading U-Boot.
 
+   -  Added ``compatible`` line to config section (with value from dtb) to allow bootloaders
+      to select the best matching configuration.
+
+
 -  SDK-related improvements:
 
+   -  Extended the following recipes to ``nativesdk``: ``libwebp``, ``python3-ply``
+
 -  Testing:
 
+   -  The :ref:`ref-classes-insane` class now adds an :ref:`unimplemented-ptest
+      <qa-check-unimplemented-ptest>` infrastructure to detect package sources
+      with unit tests but no implemented ptests in the recipe.
+
+   -  A new task to perform recipe-wide QA checks was added: ``do_recipe_qa``.
+
+   -  New build-time checks for set :term:`SUMMARY`, :term:`HOMEPAGE`, and
+      :term:`RECIPE_MAINTAINER` fields was added, and enabled for the core
+      recipes.
+
+   -  The ``parselogs`` runtime test was rewritten.  Notably it no longer uses
+      regular expressions, which may mean custom patterns need updating.
+
+   -  A self-test to validate that the :term:`SPDX` manifests generated by
+      image builds are valid was added.
+
+   -  The ``QEMU_USE_SLIRP`` variable has been replaced by adding ``slirp`` to
+      ``TEST_RUNQEMUPARAMS``.
+
 -  Utility script changes:
 
+   -  New ``scripts/patchtest`` utility to check patches to the
+      OpenEmbedded-Core project. See
+      :ref:`contributor-guide/submit-changes:validating patches with patchtest`
+      for details.
+
+   -  ``scripts/bblock`` was added, allowing the user to lock/unlock specific
+      recipes from being built. This makes it possibly to work on the
+      ``python3`` recipe without causing ``python3-native`` to rebuild.
+
 -  BitBake improvements:
 
+   -  A fetcher for the Google Cloud Platform (``gs://``) was added.
+
    -  The BitBake Cooker log now contains notes when the caches are
-      invalidated which is useful for memory resident bitbake debugging.
+      invalidated which is useful for memory resident BitBake debugging.
+
+   -  BitBake no longer watches files with :wikipedia:`inotify <inotify>` for
+      changes, as under load this can lead to races causing build instability.
+
+   -  Toaster's dependencies were upgraded to current releases, specifically
+      to Django 4.2.
 
 -  Packaging changes:
 
+   -  :term:`FILES` now accepts a ``**`` wildcard, which matches zero or more
+      subdirectories.
+
+   -  The X server packagegroup now defaults to using the ``modesetting`` X
+      driver, which obsoletes the ``fbdev`` driver.
+
+   -  If a recipe uses :term:`LICENSE_FLAGS` and the licenses are not accepted,
+      it can set a custom message with :term:`LICENSE_FLAGS_DETAILS` to be
+      displayed to the users.
+
+   -  Recipes that fetch specific revisions no longer need to explicitly add
+      :term:`SRCPV` to :term:`PV` as BitBake will now automatically add the
+      revision information to :term:`PKGV` if needed (as long as "+" is still
+      present in the :term:`PKGV` value, which is set from :term:`PV` by
+      default).
+
+   -  The default :term:`PR` values in many recipes have been removed.
+
+-  Security improvements:
+
+   -  Most repositories now include a :yocto_git:`SECURITY.md
+      </poky/tree/SECURITY.md>` file with hints for security researchers
+      and other parties who might report potential security vulnerabilities.
+
 -  Prominent documentation updates:
 
-   -  Long due documentation for the :ref:`ref-classes-devicetree` class.
+   -  New :doc:`../contributor-guide/index` document.
+
+   -  New :doc:`../dev-manual/security-subjects` chapter in the Development
+      Tasks Manual.
+
+   -  Long overdue documentation for the :ref:`ref-classes-devicetree` class.
 
    -  New :ref:`summary about available init systems
       <dev-manual/init-manager:summary>`.
@@ -85,26 +288,678 @@ New Features / Enhancements in 4.3
 
 -  Miscellaneous changes:
 
-   -  Git based recipes in OE-Core which used the git protocol have been
-      changed to use https where possibile. https is now believed to be
-      faster and more reliable.
+   -  Selecting systemd via :term:`INIT_MANAGER` now adds ``usrmerge`` to
+      :term:`DISTRO_FEATURES` as current versions of systemd now require
+      merged ``/usr``.
+
+   -  Generation of :term:`SPDX` manifests is now enabled by default.
+
+   -  Git based recipes in OE-Core which used the ``git``  protocol have been
+      changed to use `https`` where possible, as it is typically faster and
+      more reliable.
 
    -  The ``os-release`` recipe added a ``CPE_NAME`` to the fields provided, with the
       default being populated from :term:`DISTRO`.
 
+   -  The ``psplash`` recipe now accepts a PNG format image through
+      :term:`SPLASH_IMAGES`, instead of a harder to generate and modify
+      ``.h`` file.
+
+   -  The ; character is no longer needed to separate functions specified in
+      :term:`IMAGE_POSTPROCESS_COMMAND`, :term:`IMAGE_PREPROCESS_COMMAND`,
+      :term:`POPULATE_SDK_POST_HOST_COMMAND`, :term:`ROOTFS_POSTINSTALL_COMMAND`
+      etc. (If any are present they will be replaced with spaces, so existing
+      metadata does not yet need to be changed.)
+
+   -  In the ``Upstream-Status`` field in a patch header, "Accepted" is no longer
+      a valid value since it is logically the same as "Backport". Change any
+      values you have (particularly in patches applied through bbappends for core
+      recipes, since they will be validated as indicated above).
+
+
 Known Issues in 4.3
 ~~~~~~~~~~~~~~~~~~~
 
+-  N/A
+
+
 Recipe License changes in 4.3
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The following corrections have been made to the :term:`LICENSE` values set by recipes:
 
+-  ``glib-networking``: make :term:`LICENSE` more accurate (``LGPL-2.1`` -> ``LGPL-2.1-or-later``) and add an exception for linking to OpenSSL if it is enabled (``openssl`` is in :term:`PACKAGECONFIG`)
+-  ``libbsd``: set per-package licensing to clarify that BSD-4-Clause code is only in the ``-doc`` package
+-  ``openssh``: BSD-4-Clause code has been removed completely from the codebase as part of 9.4p1 update - previously in the kirkstone release, ``BSD-4-Clause`` was removed from the :term:`LICENSE` value in our recipe, however some BSD-4-Clause code actually still remained upstream until 9.4p1.
+-  ``python3-sphinx``: remove ``BSD-3-Clause`` from :term:`LICENSE` - BSD-3-Clause code was removed as part of the python3-sphinx 7.0.1 release (see `this upstream commit <https://github.com/sphinx-doc/sphinx/commit/a7f5d91c29d6f377b9fe7e926965c6f9d3e7b802>`__)
+
+
 Security Fixes in 4.3
 ~~~~~~~~~~~~~~~~~~~~~
 
+-  bind: :cve:`2023-2911`, :cve:`2023-2828`, :cve:`2023-3341`, :cve:`2023-4236`
+-  binutils: :cve:`2023-1972`
+-  connman: :cve:`2023-28488`
+-  cups: :cve:`2023-32324`, :cve:`2023-34241`, :cve:`2023-4504`
+-  dbus: :cve:`2023-34969`
+-  dmidecode: :cve:`2023-30630`
+-  dropbear: :cve:`2023-36328`
+-  erofs-utils: :cve:`2023-33551`, :cve:`2023-33552`
+-  gcc: :cve:`2023-4039`
+-  ghostscript: :cve:`2023-28879`, :cve:`2023-36664`, :cve:`2023-38559;` ignore :cve:`2023-38560`
+-  git: :cve:`2023-25652`, :cve:`2023-29007`
+-  glibc: :cve:`2023-4527`, :cve:`2023-4806`
+-  go: :cve:`2023-24537`, :cve:`2023-39325`
+-  gstreamer: :cve:`2023-40475`, :cve:`2023-40476`
+-  inetutils: :cve:`2023-40303`
+-  libarchive: ignore :cve:`2023-30571`
+-  librsvg: :cve:`2023-38633`
+-  libwebp: :cve:`2023-1999`, :cve:`2023-4863`
+-  libx11: :cve:`2023-3138`, :cve:`2023-43785`, :cve:`2023-43786`, :cve:`2023-43787`
+-  libxml2: :cve:`2023-28484`, :cve:`2023-29469;` ignore disputed :cve:`2023-45322`
+-  libxpm: :cve:`2023-43788`, :cve:`2023-43789`, :cve:`2022-44617`
+-  linux: update CVE exclusions
+-  ncurses: :cve:`2023-29491`
+-  nghttp2: :cve:`2023-44487`
+-  ninja: ignore :cve:`2021-4336`, wrong ninja
+-  openssh: :cve:`2023-38408`
+-  openssl: :cve:`2023-2650`, :cve:`2023-1255`, :cve:`2023-0466`, :cve:`2023-0465`, :cve:`2023-0464`, :cve:`2023-3817`, :cve:`2023-3446`, :cve:`2023-2975`, :cve:`2023-4807`
+-  perl: :cve:`2023-31484`, :cve:`2023-31486`
+-  pixman: ignore :cve:`2023-37769`
+-  procps: :cve:`2023-4016`
+-  python3-git: :cve:`2023-41040`
+-  python3: ignore :cve:`2023-36632`
+-  python3-urllib3: :cve:`2023-43804`
+-  qemu: :cve:`2023-40360`, :cve:`2023-42467;` ignore :cve:`2023-0664` (Windows-specific), ignore :cve:`2023-2680` (RHEL specific)
+-  screen: :cve:`2023-24626`
+-  shadow: :cve:`2023-29383`
+-  sqlite3: ignore :cve:`2023-36191`
+-  sysstat: :cve:`2023-33204`
+-  tiff: :cve:`2022-4645`, :cve:`2023-2731`, :cve:`2023-26965`, :cve:`2023-40745`, :cve:`2023-41175`
+-  vim: :cve:`2023-2426`, :cve:`2023-2609`, :cve:`2023-2610`, :cve:`2023-3896`, :cve:`2023-5441`, :cve:`2023-5535`
+-  zlib: ignore :cve:`2023-45853`
+
+
 Recipe Upgrades in 4.3
 ~~~~~~~~~~~~~~~~~~~~~~
 
+-  acpica: upgrade 20220331 -> 20230628
+-  adwaita-icon-theme: 43 -> 45.0
+-  alsa-lib: upgrade 1.2.8 -> 1.2.10
+-  alsa-ucm-conf: upgrade 1.2.8 -> 1.2.10
+-  alsa-utils: upgrade 1.2.8 -> 1.2.10
+-  apr: upgrade 1.7.2 -> 1.7.4
+-  apt: Upgrade to v2.6.0
+-  at-spi2-core: update 2.46.0 -> 2.50.0
+-  autoconf: Upgrade to 2.72c
+-  babeltrace2: upgrade 2.0.4 -> 2.0.5
+-  bind: upgrade 9.18.12 -> 9.18.19
+-  binutils: Upgrade to 2.41 release
+-  bluez5: upgrade 5.66 -> 5.69
+-  boost: upgrade 1.81.0 -> 1.83.0
+-  btrfs-tools: upgrade 6.1.3 -> 6.5.1
+-  busybox: 1.36.0 -> 1.36.1
+-  ccache: upgrade 4.7.4 -> 4.8.3
+-  cmake: upgrade to 3.27.5
+-  connman: update 1.41 -> 1.42
+-  coreutils: upgrade 9.1 -> 9.4
+-  cpio: upgrade to 2.14
+-  cracklib: upgrade 2.9.10 -> 2.9.11
+-  createrepo-c: update 0.20.1 -> 1.0.0
+-  cryptodev: update to 1.13 + latest git
+-  cups: upgrade to 2.4.6
+-  curl: upgrade 8.0.1 -> 8.4.0
+-  dbus: upgrade 1.14.6 -> 1.14.10
+-  debianutils: upgrade 5.8 -> 5.13
+-  dhcpcd: upgrade to 10.0.2
+-  diffoscope: upgrade 236 -> 249
+-  diffutils: update 3.9 -> 3.10
+-  dmidecode: upgrade to 3.5
+-  dnf: upgrade 4.14.0 -> 4.17.0
+-  dos2unix: upgrade 7.4.4 -> 7.5.1
+-  dpkg: upgrade to v1.22.0
+-  efivar: Upgrade to tip of trunk
+-  elfutils: upgrade 0.188 -> 0.189
+-  ell: upgrade 0.56 -> 0.58
+-  enchant2: upgrade 2.3.4 -> 2.6.1
+-  epiphany: upgrade 43.1 -> 44.6
+-  erofs-utils: update 1.5 -> 1.6
+-  ethtool: upgrade 6.2 -> 6.5
+-  eudev: Upgrade 3.2.11 -> 3.2.12
+-  ffmpeg: update 5.1.2 -> 6.0
+-  file: upgrade 5.44 -> 5.45
+-  flac: Upgrade 1.4.2 -> 1.4.3
+-  font-util: upgrade 1.4.0 -> 1.4.1
+-  freetype: upgrade 2.13.0 -> 2.13.2
+-  fribidi: upgrade 1.0.12 -> 1.0.13
+-  gawk: upgrade 5.2.1 -> 5.2.2
+-  gcc: upgrade to 13.2
+-  gcompat: Upgrade to 1.1.0
+-  gcr: update 4.0.0 -> 4.1.0
+-  gdb: upgrade 13.1 -> 13.2
+-  gettext: upgrade 0.21.1 -> 0.22
+-  ghostscript: upgrade to 10.02.0
+-  git: upgrade to 2.42.0
+-  glib-2.0: upgrade 2.74.6 -> 2.78.0
+-  glibc: upgrade to 2.38 + stable updates
+-  glib-networking: upgrade 2.74.0 -> 2.76.1
+-  glslang: upgrade to 1.3.243
+-  gmp: upgrade 6.2.1 -> 6.3.0
+-  gnu-efi: upgrade 3.0.15 -> 3.0.17
+-  gnupg: upgrade 2.4.0 -> 2.4.3
+-  gnutls: update 3.8.0 -> 3.8.1
+-  gobject-introspection: upgrade 1.74.0 -> 1.78.1
+-  go-helloworld: Upgrade to tip of trunk
+-  go: update 1.20.1 -> 1.20.10
+-  gpgme: update 1.18.0 -> 1.22.0
+-  grep: upgrade 3.10 -> 3.11
+-  groff: update 1.22.4 -> 1.23.0
+-  gsettings-desktop-schemas: upgrade 43.0 -> 44.0
+-  gstreamer1.0: upgrade 1.22.0 -> 1.22.5
+-  gstreamer: upgrade 1.22.5 -> 1.22.6
+-  gtk+3: upgrade 3.24.36 -> 3.24.38
+-  gtk4: update 4.10.0 -> 4.12.3
+-  gzip: update 1.12 -> 1.13
+-  harfbuzz: upgrade 7.1.0 -> 8.2.1
+-  icu: upgrade 72-1 -> 73-2
+-  igt-gpu-tools: update 1.27.1 -> 1.28
+-  iproute2: upgrade 6.2.0 -> 6.5.0
+-  iso-codes: upgrade 4.13.0 -> 4.15.0
+-  jquery: upgrade 3.6.3 -> 3.7.1
+-  json-c: upgrade 0.16 -> 0.17
+-  kbd: upgrade 2.5.1 -> 2.6.3
+-  kea: upgrade to v2.4.0
+-  kexec-tools: upgrade 2.0.26 -> 2.0.27
+-  kmscube: upgrade to latest revision
+-  less: update 608 -> 643
+-  libadwaita: upgrade 1.3.3 -> 1.4.0
+-  libarchive: upgrade 3.6.2 -> 3.7.2
+-  libassuan: upgrade 2.5.5 -> 2.5.6
+-  libatomic-ops: update 7.6.14 -> 7.8.0
+-  libcap: upgrade 2.67 -> 2.69
+-  libcgroup: update 3.0.0 -> 3.1.0
+-  libconvert-asn1-perl: upgrade 0.33 -> 0.34
+-  libdnf: update 0.70.1 -> 0.70.1
+-  libdrm: upgrade 2.4.115 -> 2.4.116
+-  libedit: upgrade 20221030-3.1 -> 20230828-3.1
+-  libevdev: upgrade 1.13.0 -> 1.13.1
+-  libgcrypt: update 1.10.1 -> 1.10.2
+-  libgit2: upgrade 1.6.3 -> 1.7.1
+-  libglu: update 9.0.2 -> 9.0.3
+-  libgpg-error: update 1.46 -> 1.47
+-  libgudev: upgrade 237 -> 238
+-  libhandy: upgrade 1.8.1 -> 1.8.2
+-  libinput: upgrade to 1.24.0
+-  libjpeg-turbo: upgrade to 3.0.0
+-  libksba: upgrade 1.6.3 -> 1.6.4
+-  libmd: upgrade 1.0.4 -> 1.1.0
+-  libmicrohttpd: upgrade 0.9.76 -> 0.9.77
+-  libmodule-build-perl: upgrade 0.4232 -> 0.4234
+-  libmodulemd: upgrade 2.14.0 -> 2.15.0
+-  libnl: upgrade 3.7.0 -> 3.8.0
+-  libnss-nis: upgrade 3.1 -> 3.2
+-  libpam: update 1.5.2 -> 1.5.3
+-  libpcap: upgrade 1.10.3 -> 1.10.4
+-  libpng: upgrade 1.6.39 -> 1.6.40
+-  libportal: upgrade 0.6 -> 0.7.1
+-  libproxy: update 0.4.18 -> 0.5.3
+-  libpthread-stubs: update 0.4 -> 0.5
+-  librepo: upgrade 1.15.1 -> 1.16.0
+-  librsvf: update 2.54.5 -> 2.56.0
+-  librsvg: update 2.56.0 -> 2.56.3
+-  libsdl2: upgrade 2.26.3 -> 2.28.3
+-  libsecret: upgrade 0.20.5 -> 0.21.1
+-  libsndfile1: upgrade 1.2.0 -> 1.2.2
+-  libsolv: upgrade 0.7.23 -> 0.7.25
+-  libsoup: upgrade 3.2.2 -> 3.4.2
+-  libssh2: update 1.10.0 -> 1.11.0
+-  libtraceevent: upgrade 1.7.2 -> 1.7.3
+-  libubootenv: upgrade 0.3.3 -> 0.3.4
+-  liburi-perl: update 5.17 -> 5.21
+-  libuv: upgrade 1.44.2 -> 1.46.0
+-  libva: update 2.16 -> 2.19.0
+-  libva-utils: update 2.19.0 -> 2.20.0
+-  libwebp: upgrade 1.3.0 -> 1.3.2
+-  libx11: upgrade 1.8.4 -> 1.8.7
+-  libxcb: upgrade 1.15 -> 1.16
+-  libxcrypt: upgrade 4.4.33 -> 4.4.36
+-  libxfixes: Upgrade to v6.0.1
+-  libxft: upgrade 2.3.7 -> 2.3.8
+-  libxi: upgrade to v1.8.1
+-  libxml2: upgrade 2.10.3 -> 2.11.5
+-  libxpm: upgrade 3.5.15 -> 3.5.17
+-  libxslt: upgrade 1.1.37 -> 1.1.38
+-  libxt: Upgrade to v1.3.0
+-  lighttpd: upgrade 1.4.69 -> 1.4.71
+-  linux-firmware: upgrade 20230210 -> 20230804
+-  linux-libc-headers: uprev to v6.5
+-  linux-yocto/6.1: update to v6.1.57
+-  linux-yocto-dev: update to v6.6-rcX
+-  linux-yocto: introduce 6.5 reference kernel recipes
+-  llvm: Upgrade to 17.0.2
+-  ltp: upgrade 20230127 -> 20230516
+-  lttng-modules: Upgrade 2.13.9 -> 2.13.10
+-  lttng-tools: Upgrade 2.13.9 -> 2.13.11
+-  lttng-ust: upgrade 2.13.5 -> 2.13.6
+-  lua: update 5.4.4 -> 5.4.6
+-  man-pages: upgrade 6.03 -> 6.05.01
+-  mc: upgrade 4.8.29 -> 4.8.30
+-  mesa: upgrade 23.0.0 -> 23.2.1
+-  meson: upgrade 1.0.1 -> 1.2.2
+-  mmc-utils: upgrade to latest revision
+-  mobile-broadband-provider-info: upgrade 20221107 -> 20230416
+-  mpfr: upgrade 4.2.0 -> 4.2.1
+-  mpg123: upgrade 1.31.2 -> 1.31.3
+-  msmtp: upgrade 1.8.23 -> 1.8.24
+-  mtd-utils: upgrade 2.1.5 -> 2.1.6
+-  mtools: upgrade 4.0.42 -> 4.0.43
+-  musl: update to latest master
+-  neard: upgrade 0.18 -> 0.19
+-  nettle: upgrade 3.8.1 -> 3.9.1
+-  nfs-utils: upgrade 2.6.2 -> 2.6.3
+-  nghttp2: upgrade 1.52.0 -> 1.57.0
+-  ofono: upgrade 2.0 -> 2.1
+-  openssh: upgrade to 9.5p1
+-  openssl: upgrade 3.1.0 -> 3.1.3
+-  opkg: upgrade 0.6.1 -> 0.6.2
+-  opkg-utils: upgrade 0.5.0 -> 0.6.2
+-  orc: upgrade 0.4.33 -> 0.4.34
+-  ovmf: update 202211 -> 202305
+-  ovmf: update edk2-stable202305 -> edk2-stable202308
+-  p11-kit: upgrade 0.24.1 -> 0.25.0
+-  pango: upgrade 1.50.13 -> 1.51.0
+-  parted: upgrade 3.5 -> 3.6
+-  patchelf: Upgrade 0.17.2 -> 0.18.0
+-  pciutils: upgrade 3.9.0 -> 3.10.0
+-  perlcross: update 1.4 -> 1.5
+-  perl: update 5.36.0 -> 5.38.0
+-  piglit: upgrade to latest revision
+-  pigz: upgrade 2.7 -> 2.8
+-  pkgconf: upgrade 1.9.4 -> 2.0.3
+-  ppp: upgrade 2.4.9 -> 2.5.0
+-  procps: update 4.0.3 -> 4.0.4
+-  puzzles: upgrade to latest revision
+-  python3-attrs: upgrade 22.2.0 -> 23.1.0
+-  python3-build: upgrade to 1.0.3
+-  python3-certifi: upgrade 2022.12.7 -> 2023.7.22
+-  python3-chardet: upgrade 5.1.0 -> 5.2.0
+-  python3-cryptography{-vectors}: upgrade 39.0.2 -> 41.0.4
+-  python3-cython: upgrade 0.29.33 -> 0.29.36
+-  python3-dbusmock: upgrade 0.28.7 -> 0.29.1
+-  python3-docutils: upgrade 0.19 -> 0.20.1
+-  python3-dtc: upgrade 1.6.1 -> 1.7.0
+-  python3-dtschema: upgrade 2023.1 -> 2023.7
+-  python3-editables: upgrade 0.3 -> 0.5
+-  python3-flit-core: upgrade 3.8.0 -> 3.9.0
+-  python3-git: upgrade 3.1.31 -> 3.1.36
+-  python3-hatch-fancy-pypi-readme: upgrade 22.8.0 -> 23.1.0
+-  python3-hatchling: upgrade 1.13.0 -> 1.18.0
+-  python3-hypothesis: upgrade 6.68.2 -> 6.86.2
+-  python3-importlib-metadata: upgrade 6.0.0 -> 6.8.0
+-  python3-installer: upgrade 0.6.0 -> 0.7.0
+-  python3-iso8601: upgrade 1.1.0 -> 2.0.0
+-  python3-jsonpointer: upgrade to 2.4
+-  python3-libarchive-c: upgrade 4.0 -> 5.0
+-  python3-lxml: upgrade 4.9.2 -> 4.9.3
+-  python3-markdown: upgrade 3.4.1 -> 3.4.4
+-  python3-markupsafe: upgrade 2.1.2 -> 2.1.3
+-  python3-more-itertools: upgrade 9.1.0 -> 10.1.0
+-  python3-numpy: upgrade 1.24.2 -> 1.26.0
+-  python3-packaging: upgrade 23.0 -> 23.1
+-  python3-pathspec: upgrade 0.11.0 -> 0.11.2
+-  python3-pip: upgrade 23.0.1 -> 23.2.1
+-  python3-pluggy: upgrade 1.0.0 -> 1.3.0
+-  python3-poetry-core: upgrade 1.5.2 -> 1.7.0
+-  python3-psutil: upgrade 5.9.4 -> 5.9.5
+-  python3-pyasn1: upgrade 0.4.8 -> 0.5.0
+-  python3-pycairo: upgrade 1.23.0 -> 1.24.0
+-  python3-pycryptodome: upgrade 3.17 -> 3.19.0
+-  python3-pycryptodomex: upgrade 3.17 -> 3.19.0
+-  python3-pyelftools: upgrade 0.29 -> 0.30
+-  python3-pygments: upgrade 2.14.0 -> 2.16.1
+-  python3-pygobject: upgrade 3.42.2 -> 3.46.0
+-  python3-pyopenssl: upgrade 23.0.0 -> 23.2.0
+-  python3-pyparsing: upgrade 3.0.9 -> 3.1.1
+-  python3-pytest-subtests: upgrade 0.10.0 -> 0.11.0
+-  python3-pytest: upgrade 7.2.2 -> 7.4.2
+-  python3-pytz: upgrade 2022.7.1 -> 2023.3
+-  python3-pyyaml: upgrade 6.0 -> 6.0.1
+-  python3-requests: Upgrade to 2.31.0
+-  python3-ruamel-yaml: upgrade 0.17.21 -> 0.17.32
+-  python3-setuptools-rust: upgrade 1.5.2 -> 1.7.0
+-  python3-setuptools: upgrade 67.6.0 -> 68.2.2
+-  python3-smmap: upgrade 5.0.0 -> 6.0.0
+-  python3-sphinx-rtd-theme: upgrade 1.2.0 -> 1.3.0
+-  python3-sphinx: upgrade 6.1.3 -> 7.2.6
+-  python3-trove-classifiers: upgrade 2023.4.29 -> 2023.9.19
+-  python3-typing-extensions: upgrade 4.5.0 -> 4.8.0
+-  python3: upgrade 3.11.2 -> 3.11.5
+-  python3-urllib3: upgrade 1.26.15 -> 2.0.6
+-  python3-webcolors: upgrade 1.12 -> 1.13
+-  python3-wheel: upgrade 0.40.0 -> 0.41.2
+-  python3-zipp: upgrade 3.15.0 -> 3.17.0
+-  qemu: Upgrade 7.2.0 -> 8.1.0
+-  re2c: upgrade 3.0 -> 3.1
+-  repo: upgrade 2.32 -> 2.36.1
+-  rpcsvc-proto: Upgrade to 1.4.4
+-  rpm2cpio.sh: update to the last 4.x version
+-  rpm: update 4.18.0 -> 4.18.1
+-  ruby: upgrade 3.2.1 -> 3.2.2
+-  rust: Upgrade 1.68.1 -> 1.70.0
+-  screen: update 4.9.0 -> 4.9.1
+-  seatd: upgrade 0.7.0 -> 0.8.0
+-  serf: upgrade 1.3.9 -> 1.3.10
+-  shaderc: upgrade 2023.2 -> 2023.6
+-  spirv-headers: upgrade 1.3.239.0 -> 1.3.243.0
+-  spirv-tools: upgrade 1.3.239.0 -> 1.3.243.0
+-  sqlite3: upgrade 3.41.0 -> 3.43.1
+-  squashfs-tools: upgrade 4.5.1 -> 4.6.1
+-  sstatesig: Update to match bitbake changes to runtaskdeps
+-  strace: upgrade 6.2 -> 6.5
+-  stress-ng: upgrade 0.15.06 -> 0.16.05
+-  sudo: update 1.9.13p3 -> 1.9.14p3
+-  sysfsutils: update 2.1.0 -> 2.1.1
+-  sysklogd: upgrade 2.4.4 -> 2.5.2
+-  sysstat: update 12.6.2 -> 12.7.4
+-  systemd: upgrade 253.1 -> 254.4
+-  systemtap: upgrade 4.8 -> 4.9
+-  taglib: upgrade 1.13 -> 1.13.1
+-  tar: upgrade 1.34 -> 1.35
+-  tcf-agent: Update to 1.8.0 release
+-  texinfo: upgrade 7.0.2 -> 7.0.3
+-  tiff: upgrade to 4.6.0
+-  u-boot: Upgrade to 2023.10
+-  util-linux: upgrade 2.38.1 -> 2.39.2
+-  vala: upgrade 0.56.4 -> 0.56.13
+-  valgrind: update 3.20.0 -> 3.21.0
+-  vim: upgrade 9.0.1429 -> 9.0.2048
+-  vte: upgrade 0.72.0 -> 0.72.2
+-  vulkan-headers: upgrade to 1.3.243
+-  vulkan-loader: upgrade to 1.3.243
+-  vulkan-samples: update to latest SHA
+-  vulkan-tools: upgrade to 1.3.243
+-  vulkan: upgrade 1.3.243.0 -> 1.3.261.1
+-  waffle: upgrade 1.7.0 -> 1.7.2
+-  wayland-protocols: upgrade 1.31 -> 1.32
+-  wayland: upgrade 1.21.0 -> 1.22.0
+-  wayland-utils: upgrade 1.1.0 -> 1.2.0
+-  webkitgtk: update 2.38.5 -> 2.40.5
+-  weston: update 11.0.1 -> 12.0.2
+-  wget: upgrade 1.21.3 -> 1.21.4
+-  wireless-regdb: upgrade 2023.02.13 -> 2023.09.01
+-  wpebackend-fdo: upgrade 1.14.0 -> 1.14.2
+-  xcb-proto: upgrade 1.15.2 -> 1.16.0
+-  xdpyinfo: upgrade 1.3.3 -> 1.3.4
+-  xeyes: upgrade 1.2.0 -> 1.3.0
+-  xf86-input-libinput: upgrade 1.2.1 -> 1.4.0
+-  xf86-input-mouse: upgrade 1.9.4 -> 1.9.5
+-  xinput: upgrade to v1.6.4
+-  xkeyboard-config: upgrade 2.38 -> 2.39
+-  xorgproto: upgrade 2022.2 -> 2023.2
+-  xserver-xorg: upgrade 21.1.7 -> 21.1.8
+-  xtrans: update 1.4.0 -> 1.5.0
+-  xwayland: upgrade 22.1.8 -> 23.2.1
+-  xwininfo: upgrade to v1.1.6
+-  xxhash: upgrade 0.8.1 -> 0.8.2
+-  xz: upgrade 5.4.2 -> 5.4.4
+-  zlib: upgrade 1.2.13 -> 1.3
+-  zstd: upgrade 1.5.4 -> 1.5.5
+
+
+
+
 Contributors to 4.3
 ~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Adrian Freihofer
+-  Alassane Yattara
+-  Alberto Pianon
+-  Alberto Planas
+-  Alejandro Hernandez Samaniego
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Alexis Lothoré
+-  Alex Kiernan
+-  Andreas Cord-Landwehr
+-  André Draszik
+-  Andrej Valek
+-  Andrew Jeffery
+-  Andrey Zhizhikin
+-  Angelo Ribeiro
+-  Antoine Lubineau
+-  Antonin Godard
+-  Anuj Mittal
+-  Archana Polampalli
+-  Armin Kuster
+-  Arne Schwerdt
+-  Arno Baumfalk
+-  Arslan Ahmad
+-  Bartosz Golaszewski
+-  BELHADJ SALEM Talel
+-  BELOUARGA Mohamed
+-  Benjamin Bara
+-  Benjamin Bouvier
+-  Bergin, Peter
+-  Bruce Ashfield
+-  Changhyeok Bae
+-  Changqing Li
+-  Charles-Antoine Couret
+-  Charlie Wu
+-  Chen Qi
+-  Chi Xu
+-  Chris Laplante
+-  Christopher Larson
+-  Daniel Ammann
+-  Daniel McGregor
+-  Daniel Semkowicz
+-  David Reyna
+-  Deepthi Hemraj
+-  Denis OSTERLAND-HEIM
+-  Denys Dmytriyenko
+-  Derek Straka
+-  Dit Kozmaj
+-  Dmitry Baryshkov
+-  Ed Beroset
+-  Eero Aaltonen
+-  Eilís 'pidge' Ní Fhlannagáin
+-  Emil Ekmečić
+-  Emil Kronborg Andersen
+-  Enrico Jörns
+-  Enrico Scholz
+-  Etienne Cordonnier
+-  Fabien Mahot
+-  Fabio Estevam
+-  Fahad Arslan
+-  Frank WOLFF
+-  Frederic Martinsons
+-  Frieder Paape
+-  Frieder Schrempf
+-  Geoff Parker
+-  Hannu Lounento
+-  Ian Ray
+-  Insu Park
+-  Jaeyoon Jung
+-  Jamin Lin
+-  Jan Garcia
+-  Jan Vermaete
+-  Jasper Orschulko
+-  Jean-Marie Lemetayer
+-  Jérémy Rosen
+-  Jermain Horsman
+-  Jialing Zhang
+-  Joel Stanley
+-  Joe Slater
+-  Johannes Schrimpf
+-  Jon Mason
+-  Jörg Sommer
+-  Jose Quaresma
+-  Joshua Watt
+-  Julien Stephan
+-  Kai Kang
+-  Khem Raj
+-  Kyle Russell
+-  Lee Chee Yang
+-  Lei Maohui
+-  Leon Anavi
+-  Lorenzo Arena
+-  Louis Rannou
+-  Luan Rafael Carneiro
+-  Luca Boccassi
+-  Luca Ceresoli
+-  Marc Ferland
+-  Marcus Flyckt
+-  Marek Vasut
+-  Mark Asselstine
+-  Mark Hatle
+-  Markus Niebel
+-  Markus Volk
+-  Marlon Rodriguez Garcia
+-  Marta Rybczynska
+-  Martijn de Gouw
+-  Martin Jansa
+-  Martin Siegumfeldt
+-  Matthias Schnelte
+-  Mauro Queiros
+-  Max Krummenacher
+-  Michael Halstead
+-  Michael Opdenacker
+-  Mickael RAMILISON
+-  Mikko Rapeli
+-  Ming Liu
+-  Mingli Yu
+-  Narpat Mali
+-  Natasha Bailey
+-  Nikhil R
+-  Ninad Palsule
+-  Ola x Nilsson
+-  Oleksandr Hnatiuk
+-  Otavio Salvador
+-  Ovidiu Panait
+-  Pascal Bach
+-  Patrick Williams
+-  Paul Eggleton
+-  Paul Gortmaker
+-  Paulo Neves
+-  Pavel Zhukov
+-  Pawan Badganchi
+-  Peter Bergin
+-  Peter Hoyes
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Peter Suti
+-  Petr Gotthard
+-  Petr Kubizňák
+-  Piotr Łobacz
+-  Poonam Jadhav
+-  Qiu Tingting
+-  Quentin Schulz
+-  Randolph Sapp
+-  Randy MacLeod
+-  Ranjitsinh Rathod
+-  Rasmus Villemoes
+-  Remi Peuvergne
+-  Richard Purdie
+-  Riyaz Khan
+-  Robert Joslyn
+-  Robert P. J. Day
+-  Robert Yang
+-  Roland Hieber
+-  Ross Burton
+-  Ryan Eatmon
+-  Sakib Sajal
+-  Samantha Jalabert
+-  Sanjay Chitroda
+-  Sean Nyekjaer
+-  Sergei Zhmylev
+-  Siddharth Doshi
+-  Soumya Sambu
+-  Staffan Rydén
+-  Stefano Babic
+-  Stefan Tauner
+-  Stéphane Veyret
+-  Stephan Wurm
+-  Sudip Mukherjee
+-  Sundeep KOKKONDA
+-  Svend Meyland Nicolaisen
+-  Tan Wen Yan
+-  Thomas Roos
+-  Tim Orling
+-  Tom Hochstein
+-  Tom Isaacson
+-  Trevor Gamblin
+-  Ulrich Ölmann
+-  Victor Kamensky
+-  Vincent Davis Jr
+-  Virendra Thakur
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Yang Xu
+-  Yash Shinde
+-  Yi Zhao
+-  Yoann Congal
+-  Yogita Urade
+-  Yuta Hayama
+-  Zang Ruochen
+-  Zhixiong Chi
+
+
+Repositories / Downloads for Yocto-4.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`nanbield </poky/log/?h=nanbield>`
+-  Tag:  :yocto_git:`yocto-4.3 </poky/log/?h=yocto-4.3>`
+-  Git Revision: :yocto_git:`15b576c4101231d248fda7ae0824e1780e1a8901 </poky/commit/?id=15b576c4101231d248fda7ae0824e1780e1a8901>`
+-  Release Artefact: poky-15b576c4101231d248fda7ae0824e1780e1a8901
+-  sha: 6b0ef7914d15db057f3efdf091b169a7361c74aac0abcfa717ef55d1a0adf74c
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3/poky-15b576c4101231d248fda7ae0824e1780e1a8901.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3/poky-15b576c4101231d248fda7ae0824e1780e1a8901.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`nanbield </openembedded-core/log/?h=nanbield>`
+-  Tag:  :oe_git:`yocto-4.3 </openembedded-core/log/?h=yocto-4.3>`
+-  Git Revision: :oe_git:`4c261f8cbdf0c7196a74daad041d04eb093015f3 </openembedded-core/commit/?id=4c261f8cbdf0c7196a74daad041d04eb093015f3>`
+-  Release Artefact: oecore-4c261f8cbdf0c7196a74daad041d04eb093015f3
+-  sha: c9e6ac75d7848ce8844cb29c98659dd8f83b3de13b916124dff76abe034e6a5c
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3/oecore-4c261f8cbdf0c7196a74daad041d04eb093015f3.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3/oecore-4c261f8cbdf0c7196a74daad041d04eb093015f3.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`nanbield </meta-mingw/log/?h=nanbield>`
+-  Tag:  :yocto_git:`yocto-4.3 </meta-mingw/log/?h=yocto-4.3>`
+-  Git Revision: :yocto_git:`65ef95a74f6ae815f63f636ed53e140a26a014ce </meta-mingw/commit/?id=65ef95a74f6ae815f63f636ed53e140a26a014ce>`
+-  Release Artefact: meta-mingw-65ef95a74f6ae815f63f636ed53e140a26a014ce
+-  sha: fb2bf806941a00a1be6349c074379b63a76490bcf0f3b740d96d1aeeefa12286
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3/meta-mingw-65ef95a74f6ae815f63f636ed53e140a26a014ce.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3/meta-mingw-65ef95a74f6ae815f63f636ed53e140a26a014ce.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.6 </bitbake/log/?h=2.6>`
+-  Tag:  :oe_git:`yocto-4.3 </bitbake/log/?h=yocto-4.3>`
+-  Git Revision: :oe_git:`5419a8473d6d4cd1d01537de68ad8d72cf5be0b2 </bitbake/commit/?id=5419a8473d6d4cd1d01537de68ad8d72cf5be0b2>`
+-  Release Artefact: bitbake-5419a8473d6d4cd1d01537de68ad8d72cf5be0b2
+-  sha: e5dab4b3345d91307860803e2ad73b2fcffa9d17dd3fde0e013ca0ebea0d05ca
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3/bitbake-5419a8473d6d4cd1d01537de68ad8d72cf5be0b2.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3/bitbake-5419a8473d6d4cd1d01537de68ad8d72cf5be0b2.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`nanbield </yocto-docs/log/?h=nanbield>`
+-  Tag: :yocto_git:`yocto-4.3 </yocto-docs/log/?h=yocto-4.3>`
+-  Git Revision: :yocto_git:`ceb1812e63b9fac062f886c2a1dde23137c0e1ed </yocto-docs/commit/?id=ceb1812e63b9fac062f886c2a1dde23137c0e1ed>`
+

documentation/overview-manual/concepts.rst

@@ -2189,3 +2189,173 @@ For more information, see the
 BitBake User Manual. You can also reference the "`Why Not
 Fakeroot? <https://github.com/wrpseudo/pseudo/wiki/WhyNotFakeroot>`__"
 article for background information on Fakeroot and Pseudo.
+
+BitBake Tasks Map
+=================
+
+To understand how BitBake operates in the build directory and environment
+we can consider the following recipes and diagram, to have full picture
+about the tasks that BitBake runs to generate the final package file
+for the recipe.
+
+We will have two recipes as an example:
+
+-  ``libhello``: A recipe that provides a shared library
+-  ``sayhello``: A recipe that uses ``libhello`` library to do its job
+
+.. note::
+
+   ``sayhello`` depends on ``libhello`` at compile time as it needs the shared
+   library to do the dynamic linking process. It also depends on it at runtime
+   as the shared library loader needs to find the library.
+   For more details about dependencies check :ref:`ref-varlocality-recipe-dependencies`.
+
+``libhello`` sources are as follows:
+
+-  ``LICENSE``: This is the license associated with this library
+-  ``Makefile``: The file used by ``make`` to build the library
+-  ``hellolib.c``: The implementation of the library
+-  ``hellolib.h``: The C header of the library
+
+``sayhello`` sources are as follows:
+
+-  ``LICENSE``: This is the license associated with this project
+-  ``Makefile``: The file used by ``make`` to build the project
+-  ``sayhello.c``: The source file of the project
+
+Before presenting the contents of each file, here are the steps
+that we need to follow to accomplish what we want in the first place,
+which is integrating ``sayhello`` in our root file system:
+
+#.  Create a Git repository for each project with the corresponding files
+
+#.  Create a recipe for each project
+
+#.  Make sure that ``sayhello`` recipe :term:`DEPENDS` on ``libhello``
+
+#.  Make sure that ``sayhello`` recipe :term:`RDEPENDS` on ``libhello``
+
+#.  Add ``sayhello`` to :term:`IMAGE_INSTALL` to integrate it into
+    the root file system
+
+The following are the contents of ``libhello/Makefile``::
+
+   LIB=libhello.so
+
+   all: $(LIB)
+
+   $(LIB): hellolib.o
+      $(CC) $< -Wl,-soname,$(LIB).1 -fPIC $(LDFLAGS) -shared -o $(LIB).1.0
+
+   %.o: %.c
+      $(CC) -c $<
+
+   clean:
+      rm -rf *.o *.so*
+
+.. note::
+
+   When creating shared libraries, it is strongly recommended to follow the Linux
+   conventions and guidelines (see `this article
+   <https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html>`__
+   for some background).
+
+.. note::
+
+   When creating ``Makefile`` files, it is strongly recommended to use ``CC``, ``LDFLAGS``
+   and ``CFLAGS`` as BitBake will set them as environment variables according
+   to your build configuration.
+
+The following are the contents of ``libhello/hellolib.h``::
+
+   #ifndef HELLOLIB_H
+   #define HELLOLIB_H
+
+   void Hello();
+
+   #endif
+
+The following are the contents of ``libhello/hellolib.c``::
+
+   #include <stdio.h>
+
+   void Hello(){
+      puts("Hello from a Yocto demo \n");
+   }
+
+The following are the contents of ``sayhello/Makefile``::
+
+   EXEC=sayhello
+   LDFLAGS += -lhello
+
+   all: $(EXEC)
+
+   $(EXEC): sayhello.c
+      $(CC) $< $(LDFLAGS) $(CFLAGS) -o $(EXEC)
+
+   clean:
+      rm -rf $(EXEC) *.o
+
+The following are the contents of ``sayhello/sayhello.c``::
+
+   #include <hellolib.h>
+
+   int main(){
+      Hello();
+      return 0;
+   }
+
+The following are the contents of ``libhello_0.1.bb``::
+
+   SUMMARY = "Hello demo library"
+   DESCRIPTION = "Hello shared library used in Yocto demo"
+
+   # NOTE: Set the License according to the LICENSE file of your project
+   #       and then add LIC_FILES_CHKSUM accordingly
+   LICENSE = "CLOSED"
+
+   # Assuming the branch is main
+   # Change <username> accordingly
+   SRC_URI = "git://github.com/<username>/libhello;branch=main;protocol=https"
+
+   S = "${WORKDIR}/git"
+
+   do_install(){
+      install -d ${D}${includedir}
+      install -d ${D}${libdir}
+
+      install hellolib.h ${D}${includedir}
+      oe_soinstall ${PN}.so.${PV} ${D}${libdir}
+   }
+
+The following are the contents of ``sayhello_0.1.bb``::
+
+   SUMMARY = "SayHello demo"
+   DESCRIPTION = "SayHello project used in Yocto demo"
+
+   # NOTE: Set the License according to the LICENSE file of your project
+   #       and then add LIC_FILES_CHKSUM accordingly
+   LICENSE = "CLOSED"
+
+   # Assuming the branch is main
+   # Change <username> accordingly
+   SRC_URI = "git://github.com/<username>/sayhello;branch=main;protocol=https"
+
+   DEPENDS += "libhello"
+   RDEPENDS:${PN} += "libhello"
+
+   S = "${WORKDIR}/git"
+
+   do_install(){
+      install -d ${D}/usr/bin
+      install -m 0700 sayhello ${D}/usr/bin
+   }
+
+After placing the recipes in a custom layer we can run ``bitbake sayhello``
+to build the recipe.
+
+The following diagram shows the sequences of tasks that BitBake
+executes to accomplish that.
+
+.. image:: svg/bitbake_tasks_map.*
+   :width: 100%

documentation/poky.yaml.in

@@ -1,10 +1,10 @@
-DISTRO : "4.2"
-DISTRO_NAME_NO_CAP : "mickledore"
-DISTRO_NAME : "Mickledore"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "langdale"
+DISTRO : "4.3"
+DISTRO_NAME_NO_CAP : "nanbield"
+DISTRO_NAME : "Nanbield"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "mickledore"
 DISTRO_NAME_NO_CAP_LTS : "kirkstone"
-YOCTO_DOC_VERSION : "4.2"
-DISTRO_REL_TAG : "yocto-4.2"
+YOCTO_DOC_VERSION : "4.3"
+DISTRO_REL_TAG : "yocto-4.3"
 DOCCONF_VERSION : "dev"
 BITBAKE_SERIES : ""
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"

documentation/profile-manual/intro.rst

@@ -7,43 +7,45 @@ Yocto Project Profiling and Tracing Manual
 Introduction
 ============
 
-Yocto bundles a number of tracing and profiling tools --- this 'HOWTO'
+Yocto Project bundles a number of tracing and profiling tools --- this manual
 describes their basic usage and shows by example how to make use of them
-to examine application and system behavior.
+to analyze application and system behavior.
 
-The tools presented are for the most part completely open-ended and have
+The tools presented are, for the most part, completely open-ended and have
 quite good and/or extensive documentation of their own which can be used
 to solve just about any problem you might come across in Linux. Each
 section that describes a particular tool has links to that tool's
 documentation and website.
 
-The purpose of this 'HOWTO' is to present a set of common and generally
+The purpose of this manual is to present a set of common and generally
 useful tracing and profiling idioms along with their application (as
 appropriate) to each tool, in the context of a general-purpose
 'drill-down' methodology that can be applied to solving a large number
-(90%?) of problems. For help with more advanced usages and problems,
-please see the documentation and/or websites listed for each tool.
+of problems. For help with more advanced usages and problems,
+refer to the documentation and/or websites provided for each tool.
 
-The final section of this 'HOWTO' is a collection of real-world examples
-which we'll be continually adding to as we solve more problems using the
-tools --- feel free to add your own examples to the list!
+The final section of this manual is a collection of real-world examples
+which we'll be continually updating as we solve more problems using the
+tools --- feel free to suggest additions to what you read here.
 
 General Setup
 =============
 
-Most of the tools are available only in 'sdk' images or in images built
-after adding 'tools-profile' to your local.conf. So, in order to be able
-to access all of the tools described here, please first build and boot
-an 'sdk' image e.g. ::
+Most of the tools are available only in ``sdk`` images or in images built
+after adding ``tools-profile`` to your ``local.conf`` file. So, in order to be able
+to access all of the tools described here, you can build and boot
+an ``sdk`` image, perhaps one of::
 
    $ bitbake core-image-sato-sdk
+   $ bitbake core-image-weston-sdk
+   $ bitbake core-image-rt-sdk
 
-or alternatively by adding 'tools-profile' to the :term:`EXTRA_IMAGE_FEATURES` line in
-your local.conf::
+Alternatively,  you can add ``tools-profile`` to the :term:`EXTRA_IMAGE_FEATURES` line in
+your ``local.conf`` file::
 
    EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile"
 
-If you use the 'tools-profile' method, you don't need to build an sdk image -
+If you use the ``tools-profile`` method, you don't need to build an sdk image ---
 the tracing and profiling tools will be included in non-sdk images as well e.g.::
 
    $ bitbake core-image-sato
@@ -64,12 +66,12 @@ the tracing and profiling tools will be included in non-sdk images as well e.g.:
 If you've already built a stripped image, you can generate debug
 packages (xxx-dbg) which you can manually install as needed.
 
-To generate debug info for packages, you can add dbg-pkgs to
-:term:`EXTRA_IMAGE_FEATURES` in local.conf. For example::
+To generate debug info for packages, you can add ``dbg-pkgs`` to
+:term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example::
 
    EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
 
-Additionally, in order to generate the right type of debuginfo, we also need to
+Additionally, in order to generate the right type of debug info, we also need to
 set :term:`PACKAGE_DEBUG_SPLIT_STYLE` in the ``local.conf`` file::
 
    PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'

documentation/ref-manual/classes.rst

@@ -281,6 +281,19 @@ tool.
 
 This class inherits the :ref:`ref-classes-cargo_common` class.
 
+.. _ref-classes-cargo_c:
+
+``cargo_c``
+===========
+
+The :ref:`ref-classes-cargo_c` class can be inherited by a recipe to generate
+a Rust library that can be called by C/C++ code. The recipe which inherits this
+class has to only replace ``inherit cargo`` by ``inherit cargo_c``.
+
+See the :yocto_git:`rust-c-lib-example_git.bb
+</poky/tree/meta-selftest/recipes-devtools/rust/rust-c-lib-example_git.bb>`
+example recipe.
+
 .. _ref-classes-cargo_common:
 
 ``cargo_common``
@@ -370,7 +383,9 @@ preferred CMake Module directory: ``${D}${datadir}/cmake/modules/``.
 ========
 
 The :ref:`ref-classes-cml1` class provides basic support for the Linux kernel style
-build configuration system.
+build configuration system. "cml" stands for "Configuration Menu Language", which
+originates from the Linux kernel but is also used in other projects such as U-Boot
+and BusyBox. It could have been called "kconfig" too.
 
 .. _ref-classes-compress_doc:
 
@@ -1480,6 +1495,9 @@ Here are the tests you can list with the :term:`WARN_QA` and
    also inherits :ref:`ref-classes-features_check` in order for the
    requirement to actually work.
 
+-  ``unimplemented-ptest:`` Checks that ptests are implemented for upstream
+   tests.
+
 -  ``unlisted-pkg-lics:`` Checks that all declared licenses applying
    for a package are also declared on the recipe level (i.e. any license
    in ``LICENSE:*`` should appear in :term:`LICENSE`).
@@ -1776,9 +1794,10 @@ class.
 =========
 
 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.
+using the `Meson <https://mesonbuild.com/>`__ build system. You can use the
+:term:`MESON_BUILDTYPE`, :term:`MESON_TARGET` and :term:`EXTRA_OEMESON`
+variables to specify additional configuration options to be passed using the
+``meson`` command line.
 
 .. _ref-classes-metadata_scm:
 

documentation/ref-manual/features.rst

@@ -52,8 +52,6 @@ Project metadata:
 
 -  *alsa:* Hardware has ALSA audio drivers
 
--  *apm:* Hardware uses APM (or APM emulation)
-
 -  *bluetooth:* Hardware has integrated BT
 
 -  *efi:* Support for booting through EFI
@@ -225,6 +223,10 @@ metadata, as extra layers can define their own:
    reduced shell overhead, and other features. This ``init`` manager is
    used by many distributions.
 
+-  *systemd-resolved:* Include support and use ``systemd-resolved`` as the
+   main DNS name resolver in ``glibc`` Name Service Switch. This is a DNS
+   resolver daemon from ``systemd``.
+
 -  *usbgadget:* Include USB Gadget Device support (for USB
    networking/serial/storage).
 

documentation/ref-manual/qa-checks.rst

@@ -789,6 +789,17 @@ Errors and Warnings
     use a relative path rather than an absolute one, or to pick up the path from
     runtime configuration or environment variables.
 
+.. _qa-check-unimplemented-ptest:
+
+- ``<tool> tests detected [unimplemented-ptest]``
+
+    This check will detect if the source of the package contains some
+    upstream-provided tests and, if so, that ptests are implemented for this
+    recipe.  See the ":ref:`dev-manual/packages:testing packages with ptest`"
+    section in the Yocto Project Development Tasks Manual. See also the
+    ":ref:`ref-classes-ptest`" section.
+
+
 
 Configuring and Disabling QA Checks
 ===================================

documentation/ref-manual/variables.rst

@@ -1358,6 +1358,32 @@ system and gives an overview of their function and contents.
       speed since the build system skips parsing recipes not compatible
       with the current machine.
 
+      If one wants to have a recipe only available for some architectures
+      (here ``aarch64`` and ``mips64``), the following can be used::
+
+         COMPATIBLE_MACHINE = "^$"
+         COMPATIBLE_MACHINE:arch64 = "^(aarch64)$"
+         COMPATIBLE_MACHINE:mips64 = "^(mips64)$"
+
+      The first line means "match all machines whose :term:`MACHINEOVERRIDES`
+      contains the empty string", which will always be none.
+
+      The second is for matching all machines whose :term:`MACHINEOVERRIDES`
+      contains one override which is exactly ``aarch64``.
+
+      The third is for matching all machines whose :term:`MACHINEOVERRIDES`
+      contains one override which is exactly ``mips64``.
+
+      The same could be achieved with::
+
+         COMPATIBLE_MACHINE = "^(aarch64|mips64)$"
+
+      .. note::
+
+         When :term:`COMPATIBLE_MACHINE` is set in a recipe inherits from
+         native, the recipe is always skipped. All native recipes must be
+         entirely target independent and should not rely on :term:`MACHINE`.
+
    :term:`COMPLEMENTARY_GLOB`
       Defines wildcards to match when installing a list of complementary
       packages for all the packages explicitly (or implicitly) installed in
@@ -1698,7 +1724,8 @@ system and gives an overview of their function and contents.
 
       It has the format "reason: description" and the description is optional.
       The Reason is mapped to the final CVE state by mapping via
-      :term:`CVE_CHECK_STATUSMAP`
+      :term:`CVE_CHECK_STATUSMAP`. See :ref:`dev-manual/vulnerabilities:fixing vulnerabilities in recipes`
+      for details.
 
    :term:`CVE_STATUS_GROUPS`
       If there are many CVEs with the same status and reason, they can by simplified by using this
@@ -2459,6 +2486,16 @@ system and gives an overview of their function and contents.
       external tools. See the :ref:`ref-classes-kernel-yocto` class in
       ``meta/classes-recipe`` to see how the variable is used.
 
+   :term:`KERNEL_LOCALVERSION`
+      This variable allows to append a string to the version
+      of the kernel image. This corresponds to the ``CONFIG_LOCALVERSION``
+      kernel configuration parameter.
+
+      Using this variable is only useful when you are using a kernel recipe
+      inheriting the :ref:`ref-classes-kernel` class, and which doesn't
+      already set a local version. Therefore, setting this variable has no
+      impact on ``linux-yocto`` kernels.
+
    :term:`EXTERNAL_TOOLCHAIN`
       When you intend to use an
       :ref:`external toolchain <dev-manual/external-toolchain:optionally using an external toolchain>`,
@@ -3765,9 +3802,9 @@ system and gives an overview of their function and contents.
    :term:`IMAGE_POSTPROCESS_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons::
+      functions separated by spaces::
 
-         IMAGE_POSTPROCESS_COMMAND += "function; ... "
+         IMAGE_POSTPROCESS_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -3778,9 +3815,9 @@ system and gives an overview of their function and contents.
    :term:`IMAGE_PREPROCESS_COMMAND`
       Specifies a list of functions to call before the OpenEmbedded build
       system creates the final image output files. You can specify
-      functions separated by semicolons::
+      functions separated by spaces::
 
-         IMAGE_PREPROCESS_COMMAND += "function; ... "
+         IMAGE_PREPROCESS_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within the
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -4333,17 +4370,16 @@ system and gives an overview of their function and contents.
       This variable is also used from the kernel's append file to identify
       the kernel branch specific to a particular machine or target
       hardware. Continuing with the previous kernel example, the kernel's
-      append file (i.e. ``linux-yocto_4.12.bbappend``) is located in the
+      append file is located in the
       BSP layer for a given machine. For example, the append file for the
-      Beaglebone, EdgeRouter, and generic versions of both 32 and 64-bit IA
+      Beaglebone and generic versions of both 32 and 64-bit IA
       machines (``meta-yocto-bsp``) is named
-      ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``.
+      ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_6.1.bbappend``.
       Here are the related statements from that append file::
 
-         KBRANCH:genericx86 = "standard/base"
-         KBRANCH:genericx86-64 = "standard/base"
-         KBRANCH:edgerouter = "standard/edgerouter"
-         KBRANCH:beaglebone = "standard/beaglebone"
+         KBRANCH:genericx86  = "v6.1/standard/base"
+         KBRANCH:genericx86-64  = "v6.1/standard/base"
+         KBRANCH:beaglebone-yocto = "v6.1/standard/beaglebone"
 
       The :term:`KBRANCH` statements
       identify the kernel branch to use when building for each supported
@@ -4718,6 +4754,10 @@ system and gives an overview of their function and contents.
       to the :term:`KERNEL_SRC` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
 
+   :term:`KERNEL_STRIP`
+      Allows to specific which ``strip`` command to use to strip the kernel
+      binary, typically either GNU binutils ``strip`` or ``llvm-strip``.
+
    :term:`KERNEL_VERSION`
       Specifies the version of the kernel as extracted from ``version.h``
       or ``utsrelease.h`` within the kernel sources. Effects of setting
@@ -5075,7 +5115,6 @@ system and gives an overview of their function and contents.
          MACHINE ?= "genericx86"
          MACHINE ?= "genericx86-64"
          MACHINE ?= "beaglebone"
-         MACHINE ?= "edgerouter"
 
       The last five are Yocto Project reference hardware
       boards, which are provided in the ``meta-yocto-bsp`` layer.
@@ -5280,6 +5319,11 @@ system and gives an overview of their function and contents.
       you to specify the inclusion of debugging symbols and the compiler
       optimizations (none, performance or size).
 
+   :term:`MESON_TARGET`
+      A variable for the :ref:`ref-classes-meson` class, allowing to choose
+      a Meson target to build in :ref:`ref-tasks-compile`.  Otherwise, the
+      default targets are built.
+
    :term:`METADATA_BRANCH`
       The branch currently checked out for the OpenEmbedded-Core layer (path
       determined by :term:`COREBASE`).
@@ -5591,6 +5635,11 @@ system and gives an overview of their function and contents.
       For additional information on how this variable is used, see the
       initialization script.
 
+   :term:`OEQA_REPRODUCIBLE_TEST_PACKAGE`
+      Set the package manager(s) for build reproducibility testing.
+      See :yocto_git:`reproducible.py </poky/tree/meta/lib/oeqa/selftest/cases/reproducible.py>`
+      and :doc:`/test-manual/reproducible-builds`.
+
    :term:`OEQA_REPRODUCIBLE_TEST_TARGET`
       Set build target for build reproducibility testing. By default
       all available recipes are compiled with "bitbake world", see also :term:`EXCLUDE_FROM_WORLD`
@@ -6059,13 +6108,11 @@ system and gives an overview of their function and contents.
       omit any argument you like but must retain the separating commas. The
       order is important and specifies the following:
 
-      #. Extra arguments that should be added to the configure script
-         argument list (:term:`EXTRA_OECONF` or
-         :term:`PACKAGECONFIG_CONFARGS`) if
-         the feature is enabled.
+      #. Extra arguments that should be added to :term:`PACKAGECONFIG_CONFARGS`
+         if the feature is enabled.
 
-      #. Extra arguments that should be added to :term:`EXTRA_OECONF` or
-         :term:`PACKAGECONFIG_CONFARGS` if the feature is disabled.
+      #. Extra arguments that should be added to :term:`PACKAGECONFIG_CONFARGS`
+         if the feature is disabled.
 
       #. Additional build dependencies (:term:`DEPENDS`)
          that should be added if the feature is enabled.
@@ -6123,6 +6170,38 @@ system and gives an overview of their function and contents.
 
             PACKAGECONFIG:append:pn-recipename = " f4"
 
+      Consider the following example of a :ref:`ref-classes-cmake` recipe with a systemd service
+      in which :term:`PACKAGECONFIG` is used to transform the systemd service
+      into a feature that can be easily enabled or disabled via :term:`PACKAGECONFIG`::
+
+         example.c
+         example.service
+         CMakeLists.txt
+
+      The ``CMakeLists.txt`` file contains::
+
+         if(WITH_SYSTEMD)
+            install(FILES ${PROJECT_SOURCE_DIR}/example.service DESTINATION /etc/systemd/systemd)
+         endif(WITH_SYSTEMD)
+
+      In order to enable the installation of ``example.service`` we need to
+      ensure that ``-DWITH_SYSTEMD=ON`` is passed to the ``cmake`` command
+      execution.  Recipes that have ``CMakeLists.txt`` generally inherit the
+      :ref:`ref-classes-cmake` class, that runs ``cmake`` with
+      :term:`EXTRA_OECMAKE`, which :term:`PACKAGECONFIG_CONFARGS` will be
+      appended to.  Now, knowing that :term:`PACKAGECONFIG_CONFARGS` is
+      automatically filled with either the first or second element of
+      :term:`PACKAGECONFIG` flag value, the recipe would be like::
+
+         inherit cmake
+         PACKAGECONFIG = "systemd"
+         PACKAGECONFIG[systemd] = "-DWITH_SYSTEMD=ON,-DWITH_SYSTEMD=OFF"
+
+      A side note to this recipe is to check if ``systemd`` is in fact the used :term:`INIT_MANAGER`
+      or not::
+
+         PACKAGECONFIG = "${@'systemd' if d.getVar('INIT_MANAGER') == 'systemd' else ''}"
+
    :term:`PACKAGECONFIG_CONFARGS`
       A space-separated list of configuration options generated from the
       :term:`PACKAGECONFIG` setting.
@@ -6409,9 +6488,9 @@ system and gives an overview of their function and contents.
    :term:`POPULATE_SDK_POST_HOST_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the host part of the SDK. You can specify
-      functions separated by semicolons::
+      functions separated by spaces::
 
-          POPULATE_SDK_POST_HOST_COMMAND += "function; ... "
+          POPULATE_SDK_POST_HOST_COMMAND += "function"
 
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
@@ -6421,9 +6500,9 @@ system and gives an overview of their function and contents.
    :term:`POPULATE_SDK_POST_TARGET_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the target part of the SDK. You can specify
-      functions separated by semicolons::
+      functions separated by spaces::
 
-         POPULATE_SDK_POST_TARGET_COMMAND += "function; ... "
+         POPULATE_SDK_POST_TARGET_COMMAND += "function"
 
       If you need to pass the SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
@@ -6910,6 +6989,22 @@ system and gives an overview of their function and contents.
       ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the
       BitBake User Manual for additional information on tasks and dependencies.
 
+   :term:`RECIPE_MAINTAINER`
+      This variable defines the name and e-mail address of the maintainer of a
+      recipe. Such information can be used by human users submitted changes,
+      and by automated tools to send notifications, for example about
+      vulnerabilities or source updates.
+
+      The variable can be defined in a global distribution :oe_git:`maintainers.inc
+      </openembedded-core/tree/meta/conf/distro/include/maintainers.inc>` file::
+
+          meta/conf/distro/include/maintainers.inc:RECIPE_MAINTAINER:pn-sysvinit = "Ross Burton <ross.burton@arm.com>"
+
+      It can also be directly defined in a recipe,
+      for example in the ``libgpiod`` one::
+
+          RECIPE_MAINTAINER = "Bartosz Golaszewski <brgl@bgdev.pl>"
+
    :term:`RECIPE_NO_UPDATE_REASON`
       If a recipe should not be replaced by a more recent upstream version,
       putting the reason why in this variable in a recipe allows
@@ -6917,6 +7012,36 @@ system and gives an overview of their function and contents.
       in the ":ref:`ref-manual/devtool-reference:checking on the upgrade status of a recipe`"
       section.
 
+   :term:`RECIPE_SYSROOT`
+      This variable points to the directory that holds all files populated from
+      recipes specified in :term:`DEPENDS`. As the name indicates,
+      think of this variable as a custom root (``/``) for the recipe that will be
+      used by the compiler in order to find headers and other files needed to complete
+      its job.
+
+      This variable is related to :term:`STAGING_DIR_HOST` or :term:`STAGING_DIR_TARGET`
+      according to the type of the recipe and the build target.
+
+      To better understand this variable, consider the following examples:
+
+      -  For ``#include <header.h>``, ``header.h`` should be in ``"${RECIPE_SYSROOT}/usr/include"``
+
+      -  For ``-lexample``, ``libexample.so`` should be in ``"${RECIPE_SYSROOT}/lib"``
+         or other library sysroot directories.
+
+      The default value is ``"${WORKDIR}/recipe-sysroot"``.
+      Do not modify it.
+
+   :term:`RECIPE_SYSROOT_NATIVE`
+      This is similar to :term:`RECIPE_SYSROOT` but the populated files are from
+      ``-native`` recipes. This allows a recipe built for the target machine to
+      use ``native`` tools.
+
+      This variable is related to :term:`STAGING_DIR_NATIVE`.
+
+      The default value is ``"${WORKDIR}/recipe-sysroot-native"``.
+      Do not modify it.
+
    :term:`REPODIR`
       See :term:`bitbake:REPODIR` in the BitBake manual.
 
@@ -6979,9 +7104,9 @@ system and gives an overview of their function and contents.
    :term:`ROOTFS_POSTINSTALL_COMMAND`
       Specifies a list of functions to call after the OpenEmbedded build
       system has installed packages. You can specify functions separated by
-      semicolons::
+      spaces::
 
-         ROOTFS_POSTINSTALL_COMMAND += "function; ... "
+         ROOTFS_POSTINSTALL_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -6992,9 +7117,9 @@ system and gives an overview of their function and contents.
    :term:`ROOTFS_POSTPROCESS_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons::
+      separated by spaces::
 
-         ROOTFS_POSTPROCESS_COMMAND += "function; ... "
+         ROOTFS_POSTPROCESS_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -7007,9 +7132,9 @@ system and gives an overview of their function and contents.
       system has removed unnecessary packages. When runtime package
       management is disabled in the image, several packages are removed
       including ``base-passwd``, ``shadow``, and ``update-alternatives``.
-      You can specify functions separated by semicolons::
+      You can specify functions separated by spaces::
 
-         ROOTFS_POSTUNINSTALL_COMMAND += "function; ... "
+         ROOTFS_POSTUNINSTALL_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -7020,9 +7145,9 @@ system and gives an overview of their function and contents.
    :term:`ROOTFS_PREPROCESS_COMMAND`
       Specifies a list of functions to call before the OpenEmbedded build
       system has created the root filesystem. You can specify functions
-      separated by semicolons::
+      separated by spaces::
 
-         ROOTFS_PREPROCESS_COMMAND += "function; ... "
+         ROOTFS_PREPROCESS_COMMAND += "function"
 
       If you need to pass the root filesystem path to a command within a
       function, you can use ``${IMAGE_ROOTFS}``, which points to the
@@ -7297,13 +7422,16 @@ system and gives an overview of their function and contents.
       :term:`SDK_EXT_TYPE` is set to "full".
 
    :term:`SDK_NAME`
-      The base name for SDK output files. The name is derived from the
-      :term:`DISTRO`, :term:`TCLIBC`,
-      :term:`SDK_ARCH`,
-      :term:`IMAGE_BASENAME`, and
-      :term:`TUNE_PKGARCH` variables::
+      The base name for SDK output files. The default value (as set in
+      ``meta-poky/conf/distro/poky.conf``) is derived from the
+      :term:`DISTRO`,
+      :term:`TCLIBC`,
+      :term:`SDKMACHINE`,
+      :term:`IMAGE_BASENAME`,
+      :term:`TUNE_PKGARCH`, and
+      :term:`MACHINE` variables::
 
-         SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}"
+         SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
 
    :term:`SDK_OS`
       Specifies the operating system for which the SDK will be built. The
@@ -7334,7 +7462,9 @@ system and gives an overview of their function and contents.
    :term:`SDK_POSTPROCESS_COMMAND`
       Specifies a list of functions to call once the OpenEmbedded build
       system creates the SDK. You can specify functions separated by
-      semicolons: SDK_POSTPROCESS_COMMAND += "function; ... "
+      spaces:
+
+         SDK_POSTPROCESS_COMMAND += "function"
 
       If you need to pass an SDK path to a command within a function, you
       can use ``${SDK_DIR}``, which points to the parent directory used by
@@ -7516,23 +7646,6 @@ system and gives an overview of their function and contents.
 
          SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1"
 
-   :term:`SERIAL_CONSOLES_CHECK`
-      Specifies serial consoles, which must be listed in
-      :term:`SERIAL_CONSOLES`, to check against
-      ``/proc/console`` before enabling them using getty. This variable
-      allows aliasing in the format: <device>:<alias>. If a device was
-      listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in
-      ``/proc/console``, you would do the following::
-
-         SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0"
-
-      This variable is currently only supported with SysVinit (i.e. not
-      with systemd). Note that :term:`SERIAL_CONSOLES_CHECK` also requires
-      ``/etc/inittab`` to be writable when used with SysVinit. This makes it
-      incompatible with customizations such as the following::
-
-         EXTRA_IMAGE_FEATURES += "read-only-rootfs"
-
    :term:`SETUPTOOLS_BUILD_ARGS`
       When used by recipes that inherit the :ref:`ref-classes-setuptools3`
       class, this variable can be used to specify additional arguments to be
@@ -8105,6 +8218,16 @@ system and gives an overview of their function and contents.
              file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
              file://.* file:///some-local-dir/sstate/PATH"
 
+      The Yocto Project actually shares the cache data objects built by its
+      autobuilder::
+
+         SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
+
+      As such binary artifacts are built for the generic QEMU machines
+      supported by the various Poky releases, they are less likely to be
+      reusable in real projects building binaries optimized for a specific
+      CPU family.
+
    :term:`SSTATE_SCAN_FILES`
       Controls the list of files the OpenEmbedded build system scans for
       hardcoded installation paths. The variable uses a space-separated
@@ -8221,10 +8344,15 @@ system and gives an overview of their function and contents.
             for ``-native`` recipes, as they make use of host headers and
             libraries.
 
+      Check :term:`RECIPE_SYSROOT` and :term:`RECIPE_SYSROOT_NATIVE`.
+
    :term:`STAGING_DIR_NATIVE`
       Specifies the path to the sysroot directory used when building
       components that run on the build host itself.
 
+      The default value is ``"${RECIPE_SYSROOT_NATIVE}"``,
+      check :term:`RECIPE_SYSROOT_NATIVE`.
+
    :term:`STAGING_DIR_TARGET`
       Specifies the path to the sysroot used for the system for which the
       component generates code. For components that do not generate code,
@@ -8409,6 +8537,35 @@ system and gives an overview of their function and contents.
              ${libdir}/${BPN}/ptest \
              "
 
+      Consider the following example in which you need to manipulate this variable.
+      Assume you have a recipe ``A`` that provides a shared library ``.so.*`` that is
+      installed into a custom folder other than "``${libdir}``"
+      or "``${base_libdir}``", let's say "``/opt/lib``".
+
+      .. note::
+
+         This is not a recommended way to deal with shared libraries, but this
+         is just to show the usefulness of setting :term:`SYSROOT_DIRS`.
+
+      When a recipe ``B`` :term:`DEPENDS` on ``A``, it means what is in
+      :term:`SYSROOT_DIRS` will be copied from :term:`D` of the recipe ``B``
+      into ``B``'s :term:`SYSROOT_DESTDIR` that is "``${WORKDIR}/sysroot-destdir``".
+
+      Now, since ``/opt/lib`` is not in :term:`SYSROOT_DIRS`, it will never be copied to
+      ``A``'s :term:`RECIPE_SYSROOT`, which is "``${WORKDIR}/recipe-sysroot``". So,
+      the linking process will fail.
+
+      To fix this, you need to add ``/opt/lib`` to :term:`SYSROOT_DIRS`::
+
+         SYSROOT_DIRS:append = " /opt/lib"
+
+      .. note::
+         Even after setting ``/opt/lib`` to :term:`SYSROOT_DIRS`, the linking process will still fail
+         because the linker does not know that location, since :term:`TARGET_LDFLAGS`
+         doesn't contain it (if your recipe is for the target). Therefore, so you should add::
+
+            TARGET_LDFLAGS:append = " -L${RECIPE_SYSROOT}/opt/lib"
+
    :term:`SYSROOT_DIRS_NATIVE`
       Extra directories staged into the sysroot by the
       :ref:`ref-tasks-populate_sysroot` task for
@@ -9046,6 +9203,16 @@ system and gives an overview of their function and contents.
       portion of an eSDK. This is similar to :term:`TOOLCHAIN_HOST_TASK`
       applying to SDKs.
 
+   :term:`TOOLCHAIN_OPTIONS`
+      This variable holds extra options passed to the compiler and the linker
+      for non ``-native`` recipes as they have to point to their custom
+      ``sysroot`` folder pointed to by :term:`RECIPE_SYSROOT`::
+
+         TOOLCHAIN_OPTIONS = " --sysroot=${RECIPE_SYSROOT}"
+
+      Native recipes don't need this variable to be set, as they are
+      built for the host machine with the native compiler.
+
    :term:`TOOLCHAIN_OUTPUTNAME`
       This variable defines the name used for the toolchain output. The
       :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class sets

documentation/sdk-manual/appendix-obtain.rst

@@ -39,27 +39,20 @@ Follow these steps to locate and hand-install the toolchain:
    download the installer appropriate for your build host, target
    hardware, and image type.
 
-   The installer files (``*.sh``) follow this naming convention::
+   The installer files (``*.sh``) follow this naming convention:
+   ``poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh``:
 
-      poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh
+   -  ``host_system``: string representing your development system: ``i686`` or ``x86_64``
 
-      Where:
-          host_system is a string representing your development system:
-                 "i686" or "x86_64"
+   -  ``type``: string representing the image: ``sato`` or ``minimal``
 
-          type is a string representing the image:
-                "sato" or "minimal"
+   -  ``arch``: string representing the target architecture such as ``cortexa57-qemuarm64``
 
-          arch is a string representing the target architecture:
-                 "aarch64", "armv5e", "core2-64", "cortexa8hf-neon", "i586", "mips32r2",
-                 "mips64", or "ppc7400"
-
-          release is the version of Yocto Project.
-
-          NOTE:
-             The standard SDK installer does not have the "-ext" string as
-             part of the filename.
+   -  ``release``: version of the Yocto Project.
 
+   .. note::
+      The standard SDK installer does not have the ``-ext`` string as
+      part of the filename.
 
    The toolchains provided by the Yocto
    Project are based off of the ``core-image-sato`` and
@@ -67,16 +60,16 @@ Follow these steps to locate and hand-install the toolchain:
    developing against those images.
 
    For example, if your build host is a 64-bit x86 system and you need
-   an extended SDK for a 64-bit core2 target, go into the ``x86_64``
+   an extended SDK for a 64-bit core2 QEMU target, go into the ``x86_64``
    folder and download the following installer::
 
-      poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
+      poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
 
 #. *Run the Installer:* Be sure you have execution privileges and run
    the installer. Following is an example from the ``Downloads``
    directory::
 
-      $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
+      $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
 
    During execution of the script, you choose the root location for the
    toolchain. See the
@@ -216,21 +209,14 @@ Follow these steps to extract the root filesystem:
    also contain flattened root filesystem image files (``*.ext4``),
    which you can use with QEMU directly.
 
-   The pre-built root filesystem image files follow these naming
-   conventions::
+   The pre-built root filesystem image files follow the
+   ``core-image-profile-machine.tar.bz2`` naming convention:
 
-      core-image-profile-arch.tar.bz2
+   -  ``profile``: filesystem image's profile, such as ``minimal``,
+      ``minimal-dev`` or ``sato``. For information on these types of image
+      profiles, see the "Images" chapter in the Yocto Project Reference Manual.
 
-      Where:
-          profile is the filesystem image's profile:
-                    lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, minimal-initramfs,
-                    sato, sato-dev, sato-sdk, sato-sdk-ptest. For information on
-                    these types of image profiles, see the "Images" chapter in
-                    the Yocto Project Reference Manual.
-
-          arch is a string representing the target architecture:
-                    beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb,
-                    genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*.
+   -  ``machine``:  same string as the name of the parent download directory.
 
    The root filesystems
    provided by the Yocto Project are based off of the

documentation/set_versions.py

@@ -26,8 +26,8 @@ ourversion = None
 if len(sys.argv) == 2:
     ourversion = sys.argv[1]
 
-activereleases = ["mickledore", "kirkstone", "dunfell"]
-devbranch = "nanbield"
+activereleases = ["nanbield", "mickledore", "kirkstone", "dunfell"]
+devbranch = "scarthgap"
 ltsseries = ["kirkstone", "dunfell"]
 
 # used by run-docs-builds to get the default page
@@ -36,6 +36,7 @@ if ourversion == "getlatest":
     sys.exit(0)
 
 release_series = collections.OrderedDict()
+release_series["scarthgap"] = "5.0"
 release_series["nanbield"] = "4.3"
 release_series["mickledore"] = "4.2"
 release_series["langdale"] = "4.1"
@@ -67,6 +68,7 @@ release_series["laverne"] = "0.9"
 
 
 bitbake_mapping = {
+    "scarthgap" : "2.8",
     "nanbield" : "2.6",
     "mickledore" : "2.4",
     "langdale" : "2.2",

documentation/test-manual/reproducible-builds.rst

@@ -68,17 +68,6 @@ things we do within the build system to ensure reproducibility include:
 -  Filtering the tools available from the host's ``PATH`` to only a specific set
    of tools, set using the :term:`HOSTTOOLS` variable.
 
-.. note::
-
-   Because of an open bug in GCC, using ``DISTRO_FEATURES:append = " lto"`` or
-   adding ``-flto`` (Link Time Optimization) to :term:`CFLAGS` makes the resulting
-   binary non-reproducible, in that it depends on the full absolute build path
-   to ``recipe-sysroot-native``, so installing the Yocto Project in a different
-   directory results in a different binary.
-
-   This issue is addressed by
-   :yocto_bugs:`bug 14481 -  Programs built with -flto are not reproducible</show_bug.cgi?id=14481>`.
-
 =========================================
 Can we prove the project is reproducible?
 =========================================

meta-poky/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "4.3"
+DISTRO_VERSION = "4.3.1"
 DISTRO_CODENAME = "nanbield"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"

meta-yocto-bsp/conf/machine/beaglebone-yocto.conf

@@ -18,7 +18,6 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-image kernel-devicetree"
 do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot virtual/bootloader:do_deploy"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
-SERIAL_CONSOLES_CHECK = "${SERIAL_CONSOLES}"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "6.1%"

meta-yocto-bsp/conf/machine/genericx86-64.conf

@@ -6,6 +6,5 @@ DEFAULTTUNE ?= "core2-64"
 require conf/machine/include/x86/tune-core2.inc
 require conf/machine/include/genericx86-common.inc
 
-SERIAL_CONSOLES_CHECK = "ttyS0"
 #For runqemu
 QB_SYSTEM_NAME = "qemu-system-x86_64"

meta/classes-global/base.bbclass

@@ -634,7 +634,7 @@ python () {
         # Mercurial packages should DEPEND on mercurial-native
         elif uri.scheme == "hg":
             d.appendVar("EXTRANATIVEPATH", ' python3-native ')
-            d.appendVarFlag('do_fetch', 'depends', ' mercurial-native:do_populate_sysroot')
+            d.appendVarFlag('do_fetch', 'depends', ' mercurial-native:do_populate_sysroot ca-certificates-native:do_populate_sysroot')
 
         # OSC packages should DEPEND on osc-native
         elif uri.scheme == "osc":

meta/classes-recipe/bin_package.bbclass

@@ -20,9 +20,6 @@
 # they would be in ${WORKDIR}.
 #
 
-# Nothing is being built so there is no need for the cross-compiler.
-INHIBIT_DEFAULT_DEPS = "1"
-
 # Skip the unwanted steps
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"

meta/classes-recipe/goarch.bbclass

@@ -68,33 +68,10 @@ SECURITY_NOPIE_CFLAGS ??= ""
 CCACHE_DISABLE ?= "1"
 
 def go_map_arch(a, d):
-    import re
-    if re.match('i.86', a):
-        return '386'
-    elif a == 'x86_64':
-        return 'amd64'
-    elif re.match('arm.*', a):
-        return 'arm'
-    elif re.match('aarch64.*', a):
-        return 'arm64'
-    elif re.match('mips64el.*', a):
-        return 'mips64le'
-    elif re.match('mips64.*', a):
-        return 'mips64'
-    elif a == 'mips':
-        return 'mips'
-    elif a == 'mipsel':
-        return 'mipsle'
-    elif re.match('p(pc|owerpc)(64le)', a):
-        return 'ppc64le'
-    elif re.match('p(pc|owerpc)(64)', a):
-        return 'ppc64'
-    elif a == 'riscv64':
-        return 'riscv64'
-    elif a == 'loongarch64':
-        return 'loong64'
-    else:
+    arch = oe.go.map_arch(a)
+    if not arch:
         raise bb.parse.SkipRecipe("Unsupported CPU architecture: %s" % a)
+    return arch
 
 def go_map_arm(a, d):
     if a.startswith("arm"):

meta/classes-recipe/kernel-arch.bbclass

@@ -77,5 +77,5 @@ KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_KERNEL_ARCH} -fuse-ld=bfd ${DE
 KERNEL_LD = "${CCACHE}${HOST_PREFIX}ld.bfd ${HOST_LD_KERNEL_ARCH}"
 KERNEL_AR = "${CCACHE}${HOST_PREFIX}ar ${HOST_AR_KERNEL_ARCH}"
 KERNEL_OBJCOPY = "${CCACHE}${HOST_PREFIX}objcopy ${HOST_OBJCOPY_KERNEL_ARCH}"
-KERNEL_STRIP = "${CCACHE}${HOST_PREFIX}strip ${HOST_STRIP_KERNEL_ARCH}"
+KERNEL_STRIP = "${HOST_PREFIX}strip ${HOST_STRIP_KERNEL_ARCH}"
 TOOLCHAIN ?= "gcc"

meta/classes-recipe/kernel.bbclass

@@ -336,7 +336,7 @@ kernel_do_transform_bundled_initramfs() {
 do_transform_bundled_initramfs[dirs] = "${B}"
 
 python do_package:prepend () {
-    os.environ['STRIP'] = d.getVar('KERNEL_STRIP')
+    d.setVar('STRIP',  d.getVar('KERNEL_STRIP').strip())
 }
 
 python do_devshell:prepend () {

meta/classes/cve-check.bbclass

@@ -138,6 +138,8 @@ def generate_json_report(d, out_path, link_path):
                     cve_check_merge_jsons(summary, data)
                 filename = f.readline()
 
+        summary["package"].sort(key=lambda d: d['name'])
+
         with open(out_path, "w") as f:
             json.dump(summary, f, indent=2)
 

meta/conf/documentation.conf

@@ -379,7 +379,6 @@ SDKMACHINE[doc] = "Specifies the architecture (i.e. i686 or x86_64) for which to
 SECTION[doc] = "The section in which packages should be categorized. Package management utilities can make use of this variable."
 SELECTED_OPTIMIZATION[doc] = "The variable takes the value of FULL_OPTIMIZATION unless DEBUG_BUILD = '1'. In this case, the value of DEBUG_OPTIMIZATION is used."
 SERIAL_CONSOLES[doc] = "Defines the serial consoles (TTYs) to enable using getty."
-SERIAL_CONSOLES_CHECK[doc] = "Similar to SERIAL_CONSOLES except the device is checked for existence before attempting to enable it. Supported only by SysVinit."
 SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS[doc] = "A list of recipe dependencies that should not be used to determine signatures of tasks from one recipe when they depend on tasks from another recipe."
 SIGGEN_EXCLUDERECIPES_ABISAFE[doc] = "A list of recipes that are completely stable and will never change."
 SITEINFO_BITS[doc] = "Specifies the number of bits for the target system CPU."

meta/conf/layer.conf

@@ -7,7 +7,7 @@ BBFILE_COLLECTIONS += "core"
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "nanbield mickledore"
+LAYERSERIES_CORENAMES = "nanbield"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers

meta/lib/oe/__init__.py

@@ -9,4 +9,4 @@ __path__ = extend_path(__path__, __name__)
 
 BBIMPORTS = ["data", "path", "utils", "types", "package", "packagedata", \
              "packagegroup", "sstatesig", "lsb", "cachedpath", "license", \
-             "qa", "reproducible", "rust", "buildcfg"]
+             "qa", "reproducible", "rust", "buildcfg", "go"]

meta/lib/oe/cve_check.py

@@ -95,11 +95,6 @@ def get_patched_cves(d):
     for url in oe.patch.src_patches(d):
         patch_file = bb.fetch.decodeurl(url)[2]
 
-        # Remote compressed patches may not be unpacked, so silently ignore them
-        if not os.path.isfile(patch_file):
-            bb.warn("%s does not exist, cannot extract CVE list" % patch_file)
-            continue
-
         # Check patch file name for CVE ID
         fname_match = cve_file_name_match.search(patch_file)
         if fname_match:
@@ -107,6 +102,12 @@ def get_patched_cves(d):
             patched_cves.add(cve)
             bb.debug(2, "Found CVE %s from patch file name %s" % (cve, patch_file))
 
+        # Remote patches won't be present and compressed patches won't be
+        # unpacked, so say we're not scanning them
+        if not os.path.isfile(patch_file):
+            bb.note("%s is remote or compressed, not scanning content" % patch_file)
+            continue
+
         with open(patch_file, "r", encoding="utf-8") as f:
             try:
                 patch_text = f.read()
@@ -172,7 +173,7 @@ def cve_check_merge_jsons(output, data):
 
     for product in output["package"]:
         if product["name"] == data["package"][0]["name"]:
-            bb.error("Error adding the same package twice")
+            bb.error("Error adding the same package %s twice" % product["name"])
             return
 
     output["package"].append(data["package"][0])

meta/lib/oe/go.py

@@ -0,0 +1,34 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import re
+
+def map_arch(a):
+    if re.match('i.86', a):
+        return '386'
+    elif a == 'x86_64':
+        return 'amd64'
+    elif re.match('arm.*', a):
+        return 'arm'
+    elif re.match('aarch64.*', a):
+        return 'arm64'
+    elif re.match('mips64el.*', a):
+        return 'mips64le'
+    elif re.match('mips64.*', a):
+        return 'mips64'
+    elif a == 'mips':
+        return 'mips'
+    elif a == 'mipsel':
+        return 'mipsle'
+    elif re.match('p(pc|owerpc)(64le)', a):
+        return 'ppc64le'
+    elif re.match('p(pc|owerpc)(64)', a):
+        return 'ppc64'
+    elif a == 'riscv64':
+        return 'riscv64'
+    elif a == 'loongarch64':
+        return 'loong64'
+    return ''

meta/lib/oeqa/core/target/ssh.py

@@ -232,11 +232,12 @@ def SSHCall(command, logger, timeout=None, **opts):
         output_raw = b''
         starttime = time.time()
         process = subprocess.Popen(command, **options)
+        has_timeout = False
         if timeout:
             endtime = starttime + timeout
             eof = False
             os.set_blocking(process.stdout.fileno(), False)
-            while time.time() < endtime and not eof:
+            while not has_timeout and not eof:
                 try:
                     logger.debug('Waiting for process output: time: %s, endtime: %s' % (time.time(), endtime))
                     if select.select([process.stdout], [], [], 5)[0] != []:
@@ -257,6 +258,10 @@ def SSHCall(command, logger, timeout=None, **opts):
                     logger.debug('BlockingIOError')
                     continue
 
+                if time.time() >= endtime:
+                    logger.debug('SSHCall has timeout! Time: %s, endtime: %s' % (time.time(), endtime))
+                    has_timeout = True
+
             process.stdout.close()
 
             # process hasn't returned yet
@@ -293,6 +298,16 @@ def SSHCall(command, logger, timeout=None, **opts):
                     pass
                 process.wait()
 
+        if has_timeout:
+            # Version of openssh before 8.6_p1 returns error code 0 when killed
+            # by a signal, when the timeout occurs we will receive a 0 error
+            # code because the process is been terminated and it's wrong because
+            # that value means success, but the process timed out.
+            # Afterwards, from version 8.6_p1 onwards, the returned code is 255.
+            # Fix this behaviour by checking the return code
+            if process.returncode == 0:
+                process.returncode = 255
+
     options = {
         "stdout": subprocess.PIPE,
         "stderr": subprocess.STDOUT,

meta/lib/oeqa/runtime/cases/ssh.py

@@ -13,6 +13,9 @@ class SSHTest(OERuntimeTestCase):
     @OETestDepends(['ping.PingTest.test_ping'])
     @OEHasPackage(['dropbear', 'openssh-sshd'])
     def test_ssh(self):
+        (status, output) = self.target.run('sleep 20', timeout=2)
+        msg='run() timed out but return code was zero.'
+        self.assertNotEqual(status, 0, msg=msg)
         (status, output) = self.target.run('uname -a')
         self.assertEqual(status, 0, msg='SSH Test failed: %s' % output)
         (status, output) = self.target.run('cat /etc/controllerimage')

meta/lib/oeqa/selftest/cases/debuginfod.py

@@ -6,7 +6,11 @@
 import os
 import socketserver
 import subprocess
+import time
+import urllib
+import pathlib
 
+from oeqa.core.decorator import OETestTag
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import bitbake, get_bb_var, runqemu
 
@@ -21,39 +25,54 @@ class Debuginfod(OESelftestTestCase):
         Request the metrics endpoint periodically and wait for there to be no
         busy scanning threads.
 
-        Returns True if debuginfod is ready, False if we timed out
+        Returns if debuginfod is ready, raises an exception if not within the
+        timeout.
         """
-        import time, urllib
 
-        # Wait a minute
-        countdown = 6
-        delay = 10
+        # Wait two minutes
+        countdown = 24
+        delay = 5
+        latest = None
 
         while countdown:
+            self.logger.info("waiting...")
             time.sleep(delay)
+
+            self.logger.info("polling server")
+            if self.debuginfod.poll():
+                self.logger.info("server dead")
+                self.debuginfod.communicate()
+                self.fail("debuginfod terminated unexpectedly")
+            self.logger.info("server alive")
+
             try:
-                with urllib.request.urlopen("http://localhost:%d/metrics" % port) as f:
-                    lines = f.read().decode("ascii").splitlines()
-                    if "thread_busy{role=\"scan\"} 0" in lines:
-                        return True
+                with urllib.request.urlopen("http://localhost:%d/metrics" % port, timeout=10) as f:
+                    for line in f.read().decode("ascii").splitlines():
+                        key, value = line.rsplit(" ", 1)
+                        if key == "thread_busy{role=\"scan\"}":
+                            latest = int(value)
+                            self.logger.info("Waiting for %d scan jobs to finish" % latest)
+                            if latest == 0:
+                                return
             except urllib.error.URLError as e:
+                # TODO: how to catch just timeouts?
                 self.logger.error(e)
+
             countdown -= 1
-        return False
 
+        raise TimeoutError("Cannot connect debuginfod, still %d scan jobs running" % latest)
 
-    def test_debuginfod(self):
-        self.write_config(
-            """
-DISTRO_FEATURES:append = " debuginfod"
-CORE_IMAGE_EXTRA_INSTALL += "elfutils"
-        """
-        )
-        bitbake("core-image-minimal elfutils-native:do_addto_recipe_sysroot")
+    def start_debuginfod(self):
+        # We assume that the caller has already bitbake'd elfutils-native:do_addto_recipe_sysroot
+
+        # Save some useful paths for later
+        native_sysroot = pathlib.Path(get_bb_var("RECIPE_SYSROOT_NATIVE", "elfutils-native"))
+        native_bindir = native_sysroot / "usr" / "bin"
+        self.debuginfod = native_bindir / "debuginfod"
+        self.debuginfod_find = native_bindir / "debuginfod-find"
 
-        native_sysroot = get_bb_var("RECIPE_SYSROOT_NATIVE", "elfutils-native")
         cmd = [
-            os.path.join(native_sysroot, "usr", "bin", "debuginfod"),
+            self.debuginfod,
             "--verbose",
             # In-memory database, this is a one-shot test
             "--database=:memory:",
@@ -76,31 +95,64 @@ CORE_IMAGE_EXTRA_INSTALL += "elfutils"
         else:
             self.fail("Unknown package class %s" % format)
 
-        # Find a free port
+        # Find a free port. Racey but the window is small.
         with socketserver.TCPServer(("localhost", 0), None) as s:
-            port = s.server_address[1]
-            cmd.append("--port=%d" % port)
+            self.port = s.server_address[1]
+            cmd.append("--port=%d" % self.port)
+
+        self.logger.info(f"Starting server {cmd}")
+        self.debuginfod = subprocess.Popen(cmd, env={})
+        self.wait_for_debuginfod(self.port)
+
+
+    def test_debuginfod_native(self):
+        """
+        Test debuginfod outside of qemu, by building a package and looking up a
+        binary's debuginfo using elfutils-native.
+        """
+
+        self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-debuginfod"
+DISTRO_FEATURES:append = " debuginfod"
+""")
+        bitbake("elfutils-native:do_addto_recipe_sysroot xz xz:do_package")
 
         try:
-            # Remove DEBUGINFOD_URLS from the environment so we don't try
-            # looking in the distro debuginfod
-            env = os.environ.copy()
-            if "DEBUGINFOD_URLS" in env:
-                del env["DEBUGINFOD_URLS"]
+            self.start_debuginfod()
 
-            self.logger.info(f"Starting server {cmd}")
-            debuginfod = subprocess.Popen(cmd, env=env)
+            env = os.environ.copy()
+            env["DEBUGINFOD_URLS"] = "http://localhost:%d/" % self.port
+
+            pkgs = pathlib.Path(get_bb_var("PKGDEST", "xz"))
+            cmd = (self.debuginfod_find, "debuginfo", pkgs / "xz" / "usr" / "bin" / "xz.xz")
+            self.logger.info(f"Starting client {cmd}")
+            output = subprocess.check_output(cmd, env=env, text=True)
+            # This should be more comprehensive
+            self.assertIn("/.cache/debuginfod_client/", output)
+        finally:
+            self.debuginfod.kill()
+
+    @OETestTag("runqemu")
+    def test_debuginfod_qemu(self):
+        """
+        Test debuginfod-find inside a qemu, talking to a debuginfod on the host.
+        """
+
+        self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-debuginfod"
+DISTRO_FEATURES:append = " debuginfod"
+CORE_IMAGE_EXTRA_INSTALL += "elfutils xz"
+        """)
+        bitbake("core-image-minimal elfutils-native:do_addto_recipe_sysroot")
+
+        try:
+            self.start_debuginfod()
 
             with runqemu("core-image-minimal", runqemuparams="nographic") as qemu:
-                self.assertTrue(self.wait_for_debuginfod(port))
-
-                cmd = (
-                    "DEBUGINFOD_URLS=http://%s:%d/ debuginfod-find debuginfo /usr/bin/debuginfod"
-                    % (qemu.server_ip, port)
-                )
+                cmd = "DEBUGINFOD_URLS=http://%s:%d/ debuginfod-find debuginfo /usr/bin/xz" % (qemu.server_ip, self.port)
                 self.logger.info(f"Starting client {cmd}")
                 status, output = qemu.run_serial(cmd)
                 # This should be more comprehensive
                 self.assertIn("/.cache/debuginfod_client/", output)
         finally:
-            debuginfod.kill()
+            self.debuginfod.kill()

meta/lib/oeqa/selftest/cases/devtool.py

@@ -27,6 +27,9 @@ def setUpModule():
     corecopydir = os.path.join(templayerdir, 'core-copy')
     bblayers_conf = os.path.join(os.environ['BUILDDIR'], 'conf', 'bblayers.conf')
     edited_layers = []
+    # make sure user doesn't have a local workspace
+    result = runCmd('bitbake-layers show-layers')
+    assert "workspacelayer" not in result.output, "Devtool test suite cannot be run with a local workspace directory"
 
     # We need to take a copy of the meta layer so we can modify it and not
     # have any races against other tests that might be running in parallel

meta/lib/patchtest/data.py

@@ -16,7 +16,6 @@
 import os
 import argparse
 import collections
-import tempfile
 import logging
 
 logger=logging.getLogger('patchtest')

meta/lib/patchtest/repo.py

@@ -11,7 +11,6 @@
 import os
 import utils
 import logging
-import json
 from patch import PatchTestPatch
 
 logger = logging.getLogger('patchtest')

meta/lib/patchtest/selftest/files/CVE.test_cve_presence_in_commit_message.fail

@@ -1,72 +0,0 @@
-From 14d72f6973270f78455a8628143f2cff90e8f41e Mon Sep 17 00:00:00 2001
-From: Trevor Gamblin <tgamblin@baylibre.com>
-Date: Tue, 29 Aug 2023 14:12:27 -0400
-Subject: [PATCH] selftest-hello: fix CVE-1234-56789
-
-This patch should fail the test for CVE presence in the mbox commit message.
-
-Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
----
- .../selftest-hello/files/CVE-1234-56789.patch | 27 +++++++++++++++++++
- .../selftest-hello/selftest-hello_1.0.bb      |  6 +++--
- 2 files changed, 31 insertions(+), 2 deletions(-)
- create mode 100644 meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-
-diff --git a/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch b/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-new file mode 100644
-index 0000000000..869cfb6fe5
---- /dev/null
-+++ b/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-@@ -0,0 +1,27 @@
-+From b26a31186e6ee2eb1f506d5f2f9394d327a0df2f Mon Sep 17 00:00:00 2001
-+From: Trevor Gamblin <tgamblin@baylibre.com>
-+Date: Tue, 29 Aug 2023 14:08:20 -0400
-+Subject: [PATCH] Fix CVE-NOT-REAL
-+
-+CVE: CVE-1234-56789
-+Upstream-Status: Backport(http://example.com/example)
-+
-+Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
-+---
-+ strlen.c | 1 +
-+ 1 file changed, 1 insertion(+)
-+
-+diff --git a/strlen.c b/strlen.c
-+index 1788f38..83d7918 100644
-+--- a/strlen.c
-++++ b/strlen.c
-+@@ -8,6 +8,7 @@ int main() {
-+ 
-+ 	printf("%d\n", str_len(string1));
-+ 	printf("%d\n", str_len(string2));
-++	printf("CVE FIXED!!!\n");
-+ 
-+ 	return 0;
-+ }
-+-- 
-+2.41.0
-diff --git a/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb b/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-index 547587bef4..76975a6729 100644
---- a/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-+++ b/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-@@ -3,7 +3,9 @@ SECTION = "examples"
- LICENSE = "MIT"
- LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
- 
--SRC_URI = "file://helloworld.c"
-+SRC_URI = "file://helloworld.c \
-+           file://CVE-1234-56789.patch \
-+           "
- 
- S = "${WORKDIR}"
- 
-@@ -16,4 +18,4 @@ do_install() {
- 	install -m 0755 helloworld ${D}${bindir}
- }
- 
--BBCLASSEXTEND = "native nativesdk"
-\ No newline at end of file
-+BBCLASSEXTEND = "native nativesdk"
--- 
-2.41.0
-

meta/lib/patchtest/selftest/files/CVE.test_cve_presence_in_commit_message.pass

@@ -1,74 +0,0 @@
-From 14d72f6973270f78455a8628143f2cff90e8f41e Mon Sep 17 00:00:00 2001
-From: Trevor Gamblin <tgamblin@baylibre.com>
-Date: Tue, 29 Aug 2023 14:12:27 -0400
-Subject: [PATCH] selftest-hello: fix CVE-1234-56789
-
-This test should pass the mbox cve tag test.
-
-CVE: CVE-1234-56789
-
-Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
----
- .../selftest-hello/files/CVE-1234-56789.patch | 27 +++++++++++++++++++
- .../selftest-hello/selftest-hello_1.0.bb      |  6 +++--
- 2 files changed, 31 insertions(+), 2 deletions(-)
- create mode 100644 meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-
-diff --git a/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch b/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-new file mode 100644
-index 0000000000..869cfb6fe5
---- /dev/null
-+++ b/meta-selftest/recipes-test/selftest-hello/files/CVE-1234-56789.patch
-@@ -0,0 +1,27 @@
-+From b26a31186e6ee2eb1f506d5f2f9394d327a0df2f Mon Sep 17 00:00:00 2001
-+From: Trevor Gamblin <tgamblin@baylibre.com>
-+Date: Tue, 29 Aug 2023 14:08:20 -0400
-+Subject: [PATCH] Fix CVE-NOT-REAL
-+
-+CVE: CVE-1234-56789
-+Upstream-Status: Backport(http://example.com/example)
-+
-+Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
-+---
-+ strlen.c | 1 +
-+ 1 file changed, 1 insertion(+)
-+
-+diff --git a/strlen.c b/strlen.c
-+index 1788f38..83d7918 100644
-+--- a/strlen.c
-++++ b/strlen.c
-+@@ -8,6 +8,7 @@ int main() {
-+ 
-+ 	printf("%d\n", str_len(string1));
-+ 	printf("%d\n", str_len(string2));
-++	printf("CVE FIXED!!!\n");
-+ 
-+ 	return 0;
-+ }
-+-- 
-+2.41.0
-diff --git a/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb b/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-index 547587bef4..76975a6729 100644
---- a/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-+++ b/meta-selftest/recipes-test/selftest-hello/selftest-hello_1.0.bb
-@@ -3,7 +3,9 @@ SECTION = "examples"
- LICENSE = "MIT"
- LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
- 
--SRC_URI = "file://helloworld.c"
-+SRC_URI = "file://helloworld.c \
-+           file://CVE-1234-56789.patch \
-+           "
- 
- S = "${WORKDIR}"
- 
-@@ -16,4 +18,4 @@ do_install() {
- 	install -m 0755 helloworld ${D}${bindir}
- }
- 
--BBCLASSEXTEND = "native nativesdk"
-\ No newline at end of file
-+BBCLASSEXTEND = "native nativesdk"
--- 
-2.41.0
-

meta/lib/patchtest/selftest/files/TestMbox.test_shortlog_length.fail

@@ -56,7 +56,7 @@ index 547587bef4..76975a6729 100644
  
 -SRC_URI = "file://helloworld.c"
 +SRC_URI = "file://helloworld.c \
-+           file://CVE-1234-56789.patch \
++           file://0001-Fix-CVE-1234-56789.patch \
 +           "
  
  S = "${WORKDIR}"

meta/lib/patchtest/selftest/selftest

@@ -18,14 +18,15 @@ parentdir  = os.path.dirname(topdir)
 # path to the repo root
 repodir = os.path.dirname(os.path.dirname(parentdir))
 
-def print_results(passcount, skipcount, failcount, xpasscount, xfailcount, errorcount):
-    total = passcount + skipcount + failcount + xpasscount + xfailcount + errorcount
+def print_results(passcount, failcount, skipcount, xpasscount, xfailcount, xskipcount, errorcount):
+    total = passcount + skipcount + failcount + xpasscount + xfailcount + xskipcount + errorcount
     print("============================================================================")
     print("Testsuite summary for %s" % os.path.basename(topdir))
     print("============================================================================")
     print("# TOTAL: %s" % str(total))
     print("# XPASS: %s" % str(xpasscount))
     print("# XFAIL: %s" % str(xfailcount))
+    print("# XSKIP: %s" % str(xskipcount))
     print("# PASS: %s" % str(passcount))
     print("# FAIL: %s" % str(failcount))
     print("# SKIP: %s" % str(skipcount))
@@ -48,6 +49,7 @@ if __name__ == '__main__':
     skipcount = 0
     xpasscount = 0
     xfailcount = 0
+    xskipcount = 0
     errorcount = 0
 
     results = None
@@ -71,6 +73,9 @@ if __name__ == '__main__':
                     elif expected_result.upper() == "PASS" and result.upper() == "PASS":
                         xpasscount = xpasscount + 1
                         print("XPASS: %s (file: %s)" % (testid.strip("."), os.path.basename(patch)))
+                    elif expected_result.upper() == "SKIP" and result.upper() == "SKIP":
+                        xskipcount = xskipcount + 1
+                        print("XSKIP: %s (file: %s)" % (testid.strip("."), os.path.basename(patch)))
                     else:
                         print("%s: %s (%s)" % (result.upper(), testid.strip("."), os.path.basename(patch)))
                         if result.upper() == "PASS":
@@ -86,4 +91,4 @@ if __name__ == '__main__':
             else:
                 print ("No test for=%s" % patch)
 
-    print_results(passcount, skipcount, failcount, xpasscount, xfailcount, errorcount)
+    print_results(passcount, failcount, skipcount, xpasscount, xfailcount, xskipcount, errorcount)

meta/lib/patchtest/tests/test_mbox.py

@@ -0,0 +1,159 @@
+# Checks related to the patch's author
+#
+# Copyright (C) 2016 Intel Corporation
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import base
+import collections
+import parse_shortlog
+import parse_signed_off_by
+import pyparsing
+import subprocess
+from data import PatchTestInput
+
+def headlog():
+    output = subprocess.check_output(
+        "cd %s; git log --pretty='%%h#%%aN#%%cD:#%%s' -1" % PatchTestInput.repodir,
+        universal_newlines=True,
+        shell=True
+        )
+    return output.split('#')
+
+class TestMbox(base.Base):
+
+    auh_email = 'auh@auh.yoctoproject.org'
+
+    invalids = [pyparsing.Regex("^Upgrade Helper.+"),
+                pyparsing.Regex(auh_email),
+                pyparsing.Regex("uh@not\.set"),
+                pyparsing.Regex("\S+@example\.com")]
+
+    rexp_detect = pyparsing.Regex('\[\s?YOCTO.*\]')
+    rexp_validation = pyparsing.Regex('\[(\s?YOCTO\s?#\s?(\d+)\s?,?)+\]')
+    revert_shortlog_regex = pyparsing.Regex('Revert\s+".*"')
+    signoff_prog = parse_signed_off_by.signed_off_by
+    revert_shortlog_regex = pyparsing.Regex('Revert\s+".*"')
+    maxlength = 90
+
+    # base paths of main yocto project sub-projects
+    paths = {
+        'oe-core': ['meta-selftest', 'meta-skeleton', 'meta', 'scripts'],
+        'bitbake': ['bitbake'],
+        'documentation': ['documentation'],
+        'poky': ['meta-poky','meta-yocto-bsp'],
+        'oe': ['meta-gpe', 'meta-gnome', 'meta-efl', 'meta-networking', 'meta-multimedia','meta-initramfs', 'meta-ruby', 'contrib', 'meta-xfce', 'meta-filesystems', 'meta-perl', 'meta-webserver', 'meta-systemd', 'meta-oe', 'meta-python']
+        }
+
+    # scripts folder is a mix of oe-core and poky, most is oe-core code except:
+    poky_scripts = ['scripts/yocto-bsp', 'scripts/yocto-kernel', 'scripts/yocto-layer', 'scripts/lib/bsp']
+
+    Project = collections.namedtuple('Project', ['name', 'listemail', 'gitrepo', 'paths'])
+
+    bitbake = Project(name='Bitbake', listemail='bitbake-devel@lists.openembedded.org', gitrepo='http://git.openembedded.org/bitbake/', paths=paths['bitbake'])
+    doc     = Project(name='Documentantion', listemail='yocto@yoctoproject.org', gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/', paths=paths['documentation'])
+    poky    = Project(name='Poky', listemail='poky@yoctoproject.org', gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/poky/', paths=paths['poky'])
+    oe      = Project(name='oe', listemail='openembedded-devel@lists.openembedded.org', gitrepo='http://git.openembedded.org/meta-openembedded/', paths=paths['oe'])
+
+
+    def test_signed_off_by_presence(self):
+        for commit in TestMbox.commits:
+            # skip those patches that revert older commits, these do not required the tag presence
+            if self.revert_shortlog_regex.search_string(commit.shortlog):
+                continue
+            if not self.signoff_prog.search_string(commit.payload):
+                self.fail('Mbox is missing Signed-off-by. Add it manually or with "git commit --amend -s"',
+                          commit=commit)
+
+    def test_shortlog_format(self):
+        for commit in TestMbox.commits:
+            shortlog = commit.shortlog
+            if not shortlog.strip():
+                self.skip('Empty shortlog, no reason to execute shortlog format test')
+            else:
+                # no reason to re-check on revert shortlogs
+                if shortlog.startswith('Revert "'):
+                    continue
+                try:
+                    parse_shortlog.shortlog.parseString(shortlog)
+                except pyparsing.ParseException as pe:
+                    self.fail('Commit shortlog (first line of commit message) should follow the format "<target>: <summary>"',
+                              commit=commit)
+
+    def test_shortlog_length(self):
+        for commit in TestMbox.commits:
+            # no reason to re-check on revert shortlogs
+            shortlog = commit.shortlog
+            if shortlog.startswith('Revert "'):
+                continue
+            l = len(shortlog)
+            if l > self.maxlength:
+                self.fail('Edit shortlog so that it is %d characters or less (currently %d characters)' % (self.maxlength, l),
+                          commit=commit)
+
+    def test_series_merge_on_head(self):
+        self.skip("Merge test is disabled for now")
+        if PatchTestInput.repo.branch != "master":
+            self.skip("Skipping merge test since patch is not intended for master branch. Target detected is %s" % PatchTestInput.repo.branch)
+        if not PatchTestInput.repo.ismerged:
+            commithash, author, date, shortlog = headlog()
+            self.fail('Series does not apply on top of target branch %s' % PatchTestInput.repo.branch,
+                      data=[('Targeted branch', '%s (currently at %s)' % (PatchTestInput.repo.branch, commithash))])
+
+    def test_target_mailing_list(self):
+        """In case of merge failure, check for other targeted projects"""
+        if PatchTestInput.repo.ismerged:
+            self.skip('Series merged, no reason to check other mailing lists')
+
+        # a meta project may be indicted in the message subject, if this is the case, just fail
+        # TODO: there may be other project with no-meta prefix, we also need to detect these
+        project_regex = pyparsing.Regex("\[(?P<project>meta-.+)\]")
+        for commit in TestMbox.commits:
+            match = project_regex.search_string(commit.subject)
+            if match:
+                self.fail('Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists',
+                          commit=commit)
+
+        for patch in self.patchset:
+            folders = patch.path.split('/')
+            base_path = folders[0]
+            for project in [self.bitbake, self.doc, self.oe, self.poky]:
+                if base_path in  project.paths:
+                    self.fail('Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists',
+                              data=[('Suggested ML', '%s [%s]' % (project.listemail, project.gitrepo)),
+                                    ('Patch\'s path:', patch.path)])
+
+            # check for poky's scripts code
+            if base_path.startswith('scripts'):
+                for poky_file in self.poky_scripts:
+                    if patch.path.startswith(poky_file):
+                        self.fail('Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists',
+                                  data=[('Suggested ML', '%s [%s]' % (self.poky.listemail, self.poky.gitrepo)),('Patch\'s path:', patch.path)])
+
+    def test_mbox_format(self):
+        if self.unidiff_parse_error:
+            self.fail('Series has malformed diff lines. Create the series again using git-format-patch and ensure it applies using git am',
+                      data=[('Diff line',self.unidiff_parse_error)])
+
+    def test_commit_message_presence(self):
+        for commit in TestMbox.commits:
+            if not commit.commit_message.strip():
+                self.fail('Please include a commit message on your patch explaining the change', commit=commit)
+
+    def test_bugzilla_entry_format(self):
+        for commit in TestMbox.commits:
+            if not self.rexp_detect.search_string(commit.commit_message):
+                self.skip("No bug ID found")
+            elif not self.rexp_validation.search_string(commit.commit_message):
+                self.fail('Bugzilla issue ID is not correctly formatted - specify it with format: "[YOCTO #<bugzilla ID>]"', commit=commit)
+
+    def test_author_valid(self):
+        for commit in self.commits:
+            for invalid in self.invalids:
+                if invalid.search_string(commit.author):
+                    self.fail('Invalid author %s. Resend the series with a valid patch author' % commit.author, commit=commit)
+
+    def test_non_auh_upgrade(self):
+        for commit in self.commits:
+            if self.auh_email in commit.payload:
+                self.fail('Invalid author %s. Resend the series with a valid patch author' % self.auh_email, commit=commit)

meta/lib/patchtest/tests/test_mbox_author.py

@@ -1,29 +0,0 @@
-# Checks related to the patch's author
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import pyparsing
-
-class Author(base.Base):
-
-    auh_email = 'auh@auh.yoctoproject.org'
-
-    invalids = [pyparsing.Regex("^Upgrade Helper.+"),
-                pyparsing.Regex(auh_email),
-                pyparsing.Regex("uh@not\.set"),
-                pyparsing.Regex("\S+@example\.com")]
-
-
-    def test_author_valid(self):
-        for commit in self.commits:
-            for invalid in self.invalids:
-                if invalid.search_string(commit.author):
-                    self.fail('Invalid author %s. Resend the series with a valid patch author' % commit.author, commit=commit)
-
-    def test_non_auh_upgrade(self):
-        for commit in self.commits:
-            if self.auh_email in commit.payload:
-                self.fail('Invalid author %s. Resend the series with a valid patch author' % self.auh_email, commit=commit)

meta/lib/patchtest/tests/test_mbox_bugzilla.py

@@ -1,20 +0,0 @@
-# Checks related to the patch's bugzilla tag
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import pyparsing
-import base
-
-class Bugzilla(base.Base):
-    rexp_detect = pyparsing.Regex('\[\s?YOCTO.*\]')
-    rexp_validation = pyparsing.Regex('\[(\s?YOCTO\s?#\s?(\d+)\s?,?)+\]')
-
-    def test_bugzilla_entry_format(self):
-        for commit in Bugzilla.commits:
-            if not self.rexp_detect.search_string(commit.commit_message):
-                self.skip("No bug ID found")
-            elif not self.rexp_validation.search_string(commit.commit_message):
-                self.fail('Bugzilla issue ID is not correctly formatted - specify it with format: "[YOCTO #<bugzilla ID>]"', commit=commit)
-

meta/lib/patchtest/tests/test_mbox_cve.py

@@ -1,39 +0,0 @@
-# Checks related to the patch's CVE lines
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-import base
-import os
-import parse_cve_tags
-import pyparsing
-
-class CVE(base.Base):
-
-    revert_shortlog_regex = pyparsing.Regex('Revert\s+".*"')
-    prog = parse_cve_tags.cve_tag
-    patch_prog = parse_cve_tags.patch_cve_tag
-
-    def setUp(self):
-        if self.unidiff_parse_error:
-            self.skip('Parse error %s' % self.unidiff_parse_error)
-
-        # we are just interested in series that introduce CVE patches, thus discard other
-        # possibilities: modification to current CVEs, patch directly introduced into the
-        # recipe, upgrades already including the CVE, etc.
-        new_patches = [p for p in self.patchset if p.path.endswith('.patch') and p.is_added_file]
-        if not new_patches:
-            self.skip('No new patches introduced')
-
-    def test_cve_presence_in_commit_message(self):
-        for commit in CVE.commits:
-            # skip those patches that revert older commits, these do not required the tag presence
-            if self.revert_shortlog_regex.search_string(commit.shortlog):
-                continue
-            if not self.patch_prog.search_string(commit.payload):
-                self.skip("No CVE tag in added patch, so not needed in mbox")
-            elif not self.prog.search_string(commit.payload):
-                self.fail('Missing or incorrectly formatted CVE tag in mbox. Correct or include the CVE tag in the mbox with format: "CVE: CVE-YYYY-XXXX"',
-                          commit=commit)

meta/lib/patchtest/tests/test_mbox_description.py

@@ -1,15 +0,0 @@
-# Checks related to the patch's commit_message
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-
-class CommitMessage(base.Base):
-
-    def test_commit_message_presence(self):
-        for commit in CommitMessage.commits:
-            if not commit.commit_message.strip():
-                self.fail('Mbox is missing a descriptive commit message. Please include a commit message on your patch explaining the change', commit=commit)
-

meta/lib/patchtest/tests/test_mbox_format.py

@@ -1,14 +0,0 @@
-# Checks correct parsing of mboxes
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-
-class MboxFormat(base.Base):
-
-    def test_mbox_format(self):
-        if self.unidiff_parse_error:
-            self.fail('Series cannot be parsed correctly due to malformed diff lines. Create the series again using git-format-patch and ensure it can be applied using git am',
-                      data=[('Diff line',self.unidiff_parse_error)])

meta/lib/patchtest/tests/test_mbox_mailinglist.py

@@ -1,63 +0,0 @@
-# Check if the series was intended for other project (not OE-Core)
-#
-# Copyright (C) 2017 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import subprocess
-import collections
-import base
-import pyparsing
-from data import PatchTestInput
-
-class MailingList(base.Base):
-
-    # base paths of main yocto project sub-projects
-    paths = {
-        'oe-core': ['meta-selftest', 'meta-skeleton', 'meta', 'scripts'],
-        'bitbake': ['bitbake'],
-        'documentation': ['documentation'],
-        'poky': ['meta-poky','meta-yocto-bsp'],
-        'oe': ['meta-gpe', 'meta-gnome', 'meta-efl', 'meta-networking', 'meta-multimedia','meta-initramfs', 'meta-ruby', 'contrib', 'meta-xfce', 'meta-filesystems', 'meta-perl', 'meta-webserver', 'meta-systemd', 'meta-oe', 'meta-python']
-        }
-
-    # scripts folder is a mix of oe-core and poky, most is oe-core code except:
-    poky_scripts = ['scripts/yocto-bsp', 'scripts/yocto-kernel', 'scripts/yocto-layer', 'scripts/lib/bsp']
-
-    Project = collections.namedtuple('Project', ['name', 'listemail', 'gitrepo', 'paths'])
-
-    bitbake = Project(name='Bitbake', listemail='bitbake-devel@lists.openembedded.org', gitrepo='http://git.openembedded.org/bitbake/', paths=paths['bitbake'])
-    doc     = Project(name='Documentantion', listemail='yocto@yoctoproject.org', gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/', paths=paths['documentation'])
-    poky    = Project(name='Poky', listemail='poky@yoctoproject.org', gitrepo='http://git.yoctoproject.org/cgit/cgit.cgi/poky/', paths=paths['poky'])
-    oe      = Project(name='oe', listemail='openembedded-devel@lists.openembedded.org', gitrepo='http://git.openembedded.org/meta-openembedded/', paths=paths['oe'])
-
-
-    def test_target_mailing_list(self):
-        """In case of merge failure, check for other targeted projects"""
-        if PatchTestInput.repo.ismerged:
-            self.skip('Series merged, no reason to check other mailing lists')
-
-        # a meta project may be indicted in the message subject, if this is the case, just fail
-        # TODO: there may be other project with no-meta prefix, we also need to detect these
-        project_regex = pyparsing.Regex("\[(?P<project>meta-.+)\]")
-        for commit in MailingList.commits:
-            match = project_regex.search_string(commit.subject)
-            if match:
-                self.fail('Series sent to the wrong mailing list. Check the project\'s README (%s) and send the patch to the indicated list' % match.group('project'),
-                          commit=commit)
-
-        for patch in self.patchset:
-            folders = patch.path.split('/')
-            base_path = folders[0]
-            for project in [self.bitbake, self.doc, self.oe, self.poky]:
-                if base_path in  project.paths:
-                    self.fail('Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists. Send the series again to the correct mailing list (ML)',
-                              data=[('Suggested ML', '%s [%s]' % (project.listemail, project.gitrepo)),
-                                    ('Patch\'s path:', patch.path)])
-
-            # check for poky's scripts code
-            if base_path.startswith('scripts'):
-                for poky_file in self.poky_scripts:
-                    if patch.path.startswith(poky_file):
-                        self.fail('Series sent to the wrong mailing list or some patches from the series correspond to different mailing lists. Send the series again to the correct mailing list (ML)',
-                                  data=[('Suggested ML', '%s [%s]' % (self.poky.listemail, self.poky.gitrepo)),('Patch\'s path:', patch.path)])

meta/lib/patchtest/tests/test_mbox_merge.py

@@ -1,24 +0,0 @@
-# Check if mbox was merged by patchtest
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import subprocess
-import base
-from data import PatchTestInput
-
-def headlog():
-    output = subprocess.check_output(
-        "cd %s; git log --pretty='%%h#%%aN#%%cD:#%%s' -1" % PatchTestInput.repodir,
-        universal_newlines=True,
-        shell=True
-        )
-    return output.split('#')
-
-class Merge(base.Base):
-    def test_series_merge_on_head(self):
-        if not PatchTestInput.repo.ismerged:
-            commithash, author, date, shortlog = headlog()
-            self.fail('Series does not apply on top of target branch. Rebase your series and ensure the target is correct',
-                      data=[('Targeted branch', '%s (currently at %s)' % (PatchTestInput.repo.branch, commithash))])

meta/lib/patchtest/tests/test_mbox_shortlog.py

@@ -1,39 +0,0 @@
-# Checks related to the patch's  summary
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import parse_shortlog
-import pyparsing
-
-maxlength = 90
-
-class Shortlog(base.Base):
-
-    def test_shortlog_format(self):
-        for commit in Shortlog.commits:
-            shortlog = commit.shortlog
-            if not shortlog.strip():
-                self.skip('Empty shortlog, no reason to execute shortlog format test')
-            else:
-                # no reason to re-check on revert shortlogs
-                if shortlog.startswith('Revert "'):
-                    continue
-                try:
-                    parse_shortlog.shortlog.parseString(shortlog)
-                except pyparsing.ParseException as pe:
-                    self.fail('Commit shortlog (first line of commit message) should follow the format "<target>: <summary>"',
-                              commit=commit)
-
-    def test_shortlog_length(self):
-        for commit in Shortlog.commits:
-            # no reason to re-check on revert shortlogs
-            shortlog = commit.shortlog
-            if shortlog.startswith('Revert "'):
-                continue
-            l = len(shortlog)
-            if l > maxlength:
-                self.fail('Edit shortlog so that it is %d characters or less (currently %d characters)' % (maxlength, l),
-                          commit=commit)

meta/lib/patchtest/tests/test_mbox_signed_off_by.py

@@ -1,27 +0,0 @@
-# Checks related to the patch's signed-off-by lines
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import parse_signed_off_by
-import pyparsing
-
-class SignedOffBy(base.Base):
-
-    revert_shortlog_regex = pyparsing.Regex('Revert\s+".*"')
-
-    @classmethod
-    def setUpClassLocal(cls):
-        # match self.mark with no '+' preceding it
-        cls.prog = parse_signed_off_by.signed_off_by
-
-    def test_signed_off_by_presence(self):
-        for commit in SignedOffBy.commits:
-            # skip those patches that revert older commits, these do not required the tag presence
-            if self.revert_shortlog_regex.search_string(commit.shortlog):
-                continue
-            if not SignedOffBy.prog.search_string(commit.payload):
-                self.fail('Mbox is missing Signed-off-by. Add it manually or with "git commit --amend -s"',
-                          commit=commit)

meta/lib/patchtest/tests/test_metadata.py

@@ -0,0 +1,180 @@
+# Checks related to the patch's LIC_FILES_CHKSUM  metadata variable
+#
+# Copyright (C) 2016 Intel Corporation
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import base
+import os
+import pyparsing
+from data import PatchTestInput, PatchTestDataStore
+
+class TestMetadata(base.Metadata):
+    metadata_lic = 'LICENSE'
+    invalid_license = 'PATCHTESTINVALID'
+    metadata_chksum = 'LIC_FILES_CHKSUM'
+    license_var  = 'LICENSE'
+    closed   = 'CLOSED'
+    lictag_re  = pyparsing.AtLineStart("License-Update:")
+    lic_chksum_added = pyparsing.AtLineStart("+" + metadata_chksum)
+    lic_chksum_removed = pyparsing.AtLineStart("-" + metadata_chksum)
+    add_mark = pyparsing.Regex('\+ ')
+    max_length = 200
+    metadata_src_uri  = 'SRC_URI'
+    md5sum    = 'md5sum'
+    sha256sum = 'sha256sum'
+    git_regex = pyparsing.Regex('^git\:\/\/.*')
+    metadata_summary = 'SUMMARY'
+
+    def test_license_presence(self):
+        if not self.added:
+            self.skip('No added recipes, skipping test')
+
+        # TODO: this is a workaround so we can parse the recipe not
+        # containing the LICENSE var: add some default license instead
+        # of INVALID into auto.conf, then remove this line at the end
+        auto_conf = os.path.join(os.environ.get('BUILDDIR'), 'conf', 'auto.conf')
+        open_flag = 'w'
+        if os.path.exists(auto_conf):
+            open_flag = 'a'
+        with open(auto_conf, open_flag) as fd:
+            for pn in self.added:
+                fd.write('LICENSE ??= "%s"\n' % self.invalid_license)
+
+        no_license = False
+        for pn in self.added:
+            rd = self.tinfoil.parse_recipe(pn)
+            license = rd.getVar(self.metadata_lic)
+            if license == self.invalid_license:
+                no_license = True
+                break
+
+        # remove auto.conf line or the file itself
+        if open_flag == 'w':
+            os.remove(auto_conf)
+        else:
+            fd = open(auto_conf, 'r')
+            lines = fd.readlines()
+            fd.close()
+            with open(auto_conf, 'w') as fd:
+                fd.write(''.join(lines[:-1]))
+
+        if no_license:
+            self.fail('Recipe does not have the LICENSE field set.')
+
+    def test_lic_files_chksum_presence(self):
+        if not self.added:
+            self.skip('No added recipes, skipping test')
+
+        for pn in self.added:
+            rd = self.tinfoil.parse_recipe(pn)
+            pathname = rd.getVar('FILE')
+            # we are not interested in images
+            if '/images/' in pathname:
+                continue
+            lic_files_chksum = rd.getVar(self.metadata_chksum)
+            if rd.getVar(self.license_var) == self.closed:
+                continue
+            if not lic_files_chksum:
+                self.fail('%s is missing in newly added recipe' % self.metadata_chksum)
+
+    def test_lic_files_chksum_modified_not_mentioned(self):
+        if not self.modified:
+            self.skip('No modified recipes, skipping test')
+
+        for patch in self.patchset:
+            # for the moment, we are just interested in metadata
+            if patch.path.endswith('.patch'):
+                continue
+            payload = str(patch)
+            if (self.lic_chksum_added.search_string(payload) or self.lic_chksum_removed.search_string(payload)):
+                # if any patch on the series contain reference on the metadata, fail
+                for commit in self.commits:
+                    if self.lictag_re.search_string(commit.commit_message):
+                       break
+                else:
+                    self.fail('LIC_FILES_CHKSUM changed without "License-Update:" tag and description in commit message')
+
+    def test_max_line_length(self):
+        for patch in self.patchset:
+            # for the moment, we are just interested in metadata
+            if patch.path.endswith('.patch'):
+                continue
+            payload = str(patch)
+            for line in payload.splitlines():
+                if self.add_mark.search_string(line):
+                    current_line_length = len(line[1:])
+                    if current_line_length > self.max_length:
+                        self.fail('Patch line too long (current length %s, maximum is %s)' % (current_line_length, self.max_length),
+                                  data=[('Patch', patch.path), ('Line', '%s ...' % line[0:80])])
+
+    def pretest_src_uri_left_files(self):
+        # these tests just make sense on patches that can be merged
+        if not PatchTestInput.repo.canbemerged:
+            self.skip('Patch cannot be merged')
+        if not self.modified:
+            self.skip('No modified recipes, skipping pretest')
+
+        # get the proper metadata values
+        for pn in self.modified:
+            # we are not interested in images
+            if 'core-image' in pn:
+                continue
+            rd = self.tinfoil.parse_recipe(pn)
+            PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata_src_uri, pn)] = rd.getVar(self.metadata_src_uri)
+
+    def test_src_uri_left_files(self):
+        # these tests just make sense on patches that can be merged
+        if not PatchTestInput.repo.canbemerged:
+            self.skip('Patch cannot be merged')
+        if not self.modified:
+            self.skip('No modified recipes, skipping pretest')
+
+        # get the proper metadata values
+        for pn in self.modified:
+            # we are not interested in images
+            if 'core-image' in pn:
+                continue
+            rd = self.tinfoil.parse_recipe(pn)
+            PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata_src_uri, pn)] = rd.getVar(self.metadata_src_uri)
+
+        for pn in self.modified:
+            pretest_src_uri = PatchTestDataStore['pre%s-%s-%s' % (self.shortid(), self.metadata_src_uri, pn)].split()
+            test_src_uri    = PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata_src_uri, pn)].split()
+
+            pretest_files = set([os.path.basename(patch) for patch in pretest_src_uri if patch.startswith('file://')])
+            test_files    = set([os.path.basename(patch) for patch in test_src_uri    if patch.startswith('file://')])
+
+            # check if files were removed
+            if len(test_files) < len(pretest_files):
+
+                # get removals from patchset
+                filesremoved_from_patchset = set()
+                for patch in self.patchset:
+                    if patch.is_removed_file:
+                        filesremoved_from_patchset.add(os.path.basename(patch.path))
+
+                # get the deleted files from the SRC_URI
+                filesremoved_from_usr_uri = pretest_files - test_files
+
+                # finally, get those patches removed at SRC_URI and not removed from the patchset
+                # TODO: we are not taking into account  renames, so test may raise false positives
+                not_removed = filesremoved_from_usr_uri - filesremoved_from_patchset
+                if not_removed:
+                    self.fail('Patches not removed from tree. Remove them and amend the submitted mbox',
+                              data=[('Patch', f) for f in not_removed])
+
+    def test_summary_presence(self):
+        if not self.added:
+            self.skip('No added recipes, skipping test')
+
+        for pn in self.added:
+            # we are not interested in images
+            if 'core-image' in pn:
+                continue
+            rd = self.tinfoil.parse_recipe(pn)
+            summary = rd.getVar(self.metadata_summary)
+
+            # "${PN} version ${PN}-${PR}" is the default, so fail if default
+            if summary.startswith('%s version' % pn):
+                self.fail('%s is missing in newly added recipe' % self.metadata_summary)

meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py

@@ -1,80 +0,0 @@
-# Checks related to the patch's LIC_FILES_CHKSUM  metadata variable
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import pyparsing
-from data import PatchTestInput, PatchTestDataStore
-
-class LicFilesChkSum(base.Metadata):
-    metadata = 'LIC_FILES_CHKSUM'
-    license  = 'LICENSE'
-    closed   = 'CLOSED'
-    lictag   = 'License-Update'
-    lictag_re  = pyparsing.Regex("^%s:" % lictag)
-
-    def setUp(self):
-        # these tests just make sense on patches that can be merged
-        if not PatchTestInput.repo.canbemerged:
-            self.skip('Patch cannot be merged')
-
-    def test_lic_files_chksum_presence(self):
-        if not self.added:
-            self.skip('No added recipes, skipping test')
-
-        for pn in self.added:
-            rd = self.tinfoil.parse_recipe(pn)
-            pathname = rd.getVar('FILE')
-            # we are not interested in images
-            if '/images/' in pathname:
-                continue
-            lic_files_chksum = rd.getVar(self.metadata)
-            if rd.getVar(self.license) == self.closed:
-                continue
-            if not lic_files_chksum:
-                self.fail('%s is missing in newly added recipe' % self.metadata)
-
-    def pretest_lic_files_chksum_modified_not_mentioned(self):
-        if not self.modified:
-            self.skip('No modified recipes, skipping pretest')
-        # get the proper metadata values
-        for pn in self.modified:
-            rd = self.tinfoil.parse_recipe(pn)
-            pathname = rd.getVar('FILE')
-            # we are not interested in images
-            if '/images/' in pathname:
-                continue
-            PatchTestDataStore['%s-%s-%s' % (self.shortid(),self.metadata,pn)] = rd.getVar(self.metadata)
-
-    def test_lic_files_chksum_modified_not_mentioned(self):
-        if not self.modified:
-            self.skip('No modified recipes, skipping test')
-
-        # get the proper metadata values
-        for pn in self.modified:
-            rd = self.tinfoil.parse_recipe(pn)
-            pathname = rd.getVar('FILE')
-            # we are not interested in images
-            if '/images/' in pathname:
-                continue
-            PatchTestDataStore['%s-%s-%s' % (self.shortid(),self.metadata,pn)] = rd.getVar(self.metadata)
-        # compare if there were changes between pre-merge and merge
-        for pn in self.modified:
-            pretest = PatchTestDataStore['pre%s-%s-%s' % (self.shortid(),self.metadata, pn)]
-            test    = PatchTestDataStore['%s-%s-%s' % (self.shortid(),self.metadata, pn)]
-
-            # TODO: this is workaround to avoid false-positives when pretest metadata is empty (not reason found yet)
-            # For more info, check bug 12284
-            if not pretest:
-                return
-
-            if pretest != test:
-                # if any patch on the series contain reference on the metadata, fail
-                for commit in self.commits:
-                    if self.lictag_re.search_string(commit.commit_message):
-                       break
-                else:
-                    self.fail('LIC_FILES_CHKSUM changed on target %s but there is no "%s" tag in commit message. Include it with a brief description' % (pn, self.lictag),
-                              data=[('Current checksum', pretest), ('New checksum', test)])

meta/lib/patchtest/tests/test_metadata_license.py

@@ -1,55 +0,0 @@
-# Checks related to the patch's LIC_FILES_CHKSUM  metadata variable
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import os
-from data import PatchTestInput
-
-class License(base.Metadata):
-    metadata = 'LICENSE'
-    invalid_license = 'PATCHTESTINVALID'
-
-    def setUp(self):
-        # these tests just make sense on patches that can be merged
-        if not PatchTestInput.repo.canbemerged:
-            self.skip('Patch cannot be merged')
-
-    def test_license_presence(self):
-        if not self.added:
-            self.skip('No added recipes, skipping test')
-
-        # TODO: this is a workaround so we can parse the recipe not
-        # containing the LICENSE var: add some default license instead
-        # of INVALID into auto.conf, then remove this line at the end
-        auto_conf = os.path.join(os.environ.get('BUILDDIR'), 'conf', 'auto.conf')
-        open_flag = 'w'
-        if os.path.exists(auto_conf):
-            open_flag = 'a'
-        with open(auto_conf, open_flag) as fd:
-            for pn in self.added:
-                fd.write('LICENSE ??= "%s"\n' % self.invalid_license)
-
-        no_license = False
-        for pn in self.added:
-            rd = self.tinfoil.parse_recipe(pn)
-            license = rd.getVar(self.metadata)
-            if license == self.invalid_license:
-                no_license = True
-                break
-
-        # remove auto.conf line or the file itself
-        if open_flag == 'w':
-            os.remove(auto_conf)
-        else:
-            fd = open(auto_conf, 'r')
-            lines = fd.readlines()
-            fd.close()
-            with open(auto_conf, 'w') as fd:
-                fd.write(''.join(lines[:-1]))
-
-        if no_license:
-            self.fail('Recipe does not have the LICENSE field set.')
-

meta/lib/patchtest/tests/test_metadata_max_length.py

@@ -1,25 +0,0 @@
-# Checks related to patch line lengths
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-import pyparsing
-
-class MaxLength(base.Base):
-    add_mark = pyparsing.Regex('\+ ')
-    max_length = 200
-
-    def test_max_line_length(self):
-        for patch in self.patchset:
-            # for the moment, we are just interested in metadata
-            if patch.path.endswith('.patch'):
-                continue
-            payload = str(patch)
-            for line in payload.splitlines():
-                if self.add_mark.search_string(line):
-                    current_line_length = len(line[1:])
-                    if current_line_length > self.max_length:
-                        self.fail('Patch line too long (current length %s, maximum is %s)' % (current_line_length, self.max_length),
-                                  data=[('Patch', patch.path), ('Line', '%s ...' % line[0:80])])

meta/lib/patchtest/tests/test_metadata_src_uri.py

@@ -1,74 +0,0 @@
-# Checks related to the patch's SRC_URI metadata variable
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import subprocess
-import base
-import os
-import pyparsing
-from data import PatchTestInput, PatchTestDataStore
-
-class SrcUri(base.Metadata):
-
-    metadata  = 'SRC_URI'
-    md5sum    = 'md5sum'
-    sha256sum = 'sha256sum'
-    git_regex = pyparsing.Regex('^git\:\/\/.*')
-
-    def setUp(self):
-        # these tests just make sense on patches that can be merged
-        if not PatchTestInput.repo.canbemerged:
-            self.skip('Patch cannot be merged')
-
-    def pretest_src_uri_left_files(self):
-        if not self.modified:
-            self.skip('No modified recipes, skipping pretest')
-
-        # get the proper metadata values
-        for pn in self.modified:
-            # we are not interested in images
-            if 'core-image' in pn:
-                continue
-            rd = self.tinfoil.parse_recipe(pn)
-            PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata, pn)] = rd.getVar(self.metadata)
-
-    def test_src_uri_left_files(self):
-        if not self.modified:
-            self.skip('No modified recipes, skipping pretest')
-
-        # get the proper metadata values
-        for pn in self.modified:
-            # we are not interested in images
-            if 'core-image' in pn:
-                continue
-            rd = self.tinfoil.parse_recipe(pn)
-            PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata, pn)] = rd.getVar(self.metadata)
-
-        for pn in self.modified:
-            pretest_src_uri = PatchTestDataStore['pre%s-%s-%s' % (self.shortid(), self.metadata, pn)].split()
-            test_src_uri    = PatchTestDataStore['%s-%s-%s' % (self.shortid(), self.metadata, pn)].split()
-
-            pretest_files = set([os.path.basename(patch) for patch in pretest_src_uri if patch.startswith('file://')])
-            test_files    = set([os.path.basename(patch) for patch in test_src_uri    if patch.startswith('file://')])
-
-            # check if files were removed
-            if len(test_files) < len(pretest_files):
-
-                # get removals from patchset
-                filesremoved_from_patchset = set()
-                for patch in self.patchset:
-                    if patch.is_removed_file:
-                        filesremoved_from_patchset.add(os.path.basename(patch.path))
-
-                # get the deleted files from the SRC_URI
-                filesremoved_from_usr_uri = pretest_files - test_files
-
-                # finally, get those patches removed at SRC_URI and not removed from the patchset
-                # TODO: we are not taking into account  renames, so test may raise false positives
-                not_removed = filesremoved_from_usr_uri - filesremoved_from_patchset
-                if not_removed:
-                    self.fail('Patches not removed from tree. Remove them and amend the submitted mbox',
-                              data=[('Patch', f) for f in not_removed])
-

meta/lib/patchtest/tests/test_metadata_summary.py

@@ -1,31 +0,0 @@
-# Checks related to the patch's summary metadata variable
-#
-# Copyright (C) 2016 Intel Corporation
-#
-# SPDX-License-Identifier: GPL-2.0-only
-
-import base
-from data import PatchTestInput
-
-class Summary(base.Metadata):
-    metadata = 'SUMMARY'
-
-    def setUp(self):
-        # these tests just make sense on patches that can be merged
-        if not PatchTestInput.repo.canbemerged:
-            self.skip('Patch cannot be merged')
-
-    def test_summary_presence(self):
-        if not self.added:
-            self.skip('No added recipes, skipping test')
-
-        for pn in self.added:
-            # we are not interested in images
-            if 'core-image' in pn:
-                continue
-            rd = self.tinfoil.parse_recipe(pn)
-            summary = rd.getVar(self.metadata)
-
-            # "${PN} version ${PN}-${PR}" is the default, so fail if default
-            if summary.startswith('%s version' % pn):
-                self.fail('%s is missing in newly added recipe' % self.metadata)

meta/lib/patchtest/tests/test_patch.py

@@ -1,16 +1,19 @@
-# Checks related to the patch's upstream-status lines
+# Checks related to the patch's CVE lines
 #
 # Copyright (C) 2016 Intel Corporation
 #
 # SPDX-License-Identifier: GPL-2.0-only
+#
 
 import base
+import parse_signed_off_by
 import parse_upstream_status
 import pyparsing
-import os
 
-class PatchUpstreamStatus(base.Base):
+class TestPatch(base.Base):
 
+    re_cve_pattern = pyparsing.Regex("CVE\-\d{4}\-\d+")
+    re_cve_payload_tag = pyparsing.Regex("\+CVE:(\s+CVE\-\d{4}\-\d+)+")
     upstream_status_regex = pyparsing.AtLineStart("+" + "Upstream-Status")
 
     @classmethod
@@ -21,20 +24,33 @@ class PatchUpstreamStatus(base.Base):
             if patch.path.endswith('.patch') and patch.is_added_file:
                 cls.newpatches.append(patch)
 
+        cls.mark = str(parse_signed_off_by.signed_off_by_mark).strip('"')
+
+        # match PatchSignedOffBy.mark with '+' preceding it
+        cls.prog = parse_signed_off_by.patch_signed_off_by
+
     def setUp(self):
         if self.unidiff_parse_error:
-            self.skip('Python-unidiff parse error')
+            self.skip('Parse error %s' % self.unidiff_parse_error)
+
         self.valid_status    = ', '.join(parse_upstream_status.upstream_status_nonliteral_valid_status)
         self.standard_format = 'Upstream-Status: <Valid status>'
 
+        # we are just interested in series that introduce CVE patches, thus discard other
+        # possibilities: modification to current CVEs, patch directly introduced into the
+        # recipe, upgrades already including the CVE, etc.
+        new_cves = [p for p in self.patchset if p.path.endswith('.patch') and p.is_added_file]
+        if not new_cves:
+            self.skip('No new CVE patches introduced')
+
     def test_upstream_status_presence_format(self):
-        if not PatchUpstreamStatus.newpatches:
+        if not TestPatch.newpatches:
             self.skip("There are no new software patches, no reason to test Upstream-Status presence/format")
 
-        for newpatch in PatchUpstreamStatus.newpatches:
+        for newpatch in TestPatch.newpatches:
             payload = newpatch.__str__()
             if not self.upstream_status_regex.search_string(payload):
-                self.fail('Added patch file is missing Upstream-Status in the header. Add Upstream-Status: <Valid status> to the header',
+                self.fail('Added patch file is missing Upstream-Status: <Valid status> in the commit message',
                           data=[('Standard format', self.standard_format), ('Valid status', self.valid_status)])
             for line in payload.splitlines():
                 if self.patchmetadata_regex.match(line):
@@ -58,3 +74,29 @@ class PatchUpstreamStatus(base.Base):
                             except pyparsing.ParseException as pe:
                                 self.fail('Upstream-Status is in incorrect format',
                                           data=[('Current', pe.pstr), ('Standard format', self.standard_format), ('Valid status', self.valid_status)])
+
+    def test_signed_off_by_presence(self):
+        if not TestPatch.newpatches:
+            self.skip("There are no new software patches, no reason to test %s presence" % PatchSignedOffBy.mark)
+
+        for newpatch in TestPatch.newpatches:
+            payload = newpatch.__str__()
+            for line in payload.splitlines():
+                if self.patchmetadata_regex.match(line):
+                    continue
+                if TestPatch.prog.search_string(payload):
+                    break
+            else:
+                self.fail('A patch file has been added without a Signed-off-by tag. Sign off the added patch file (%s)' % newpatch.path)
+
+    def test_cve_tag_format(self):
+        for commit in TestPatch.commits:
+            if self.re_cve_pattern.search_string(commit.shortlog) or self.re_cve_pattern.search_string(commit.commit_message):
+                tag_found = False
+                for line in commit.payload.splitlines():
+                    if self.re_cve_payload_tag.search_string(line):
+                        tag_found = True
+                        break
+                if not tag_found:
+                    self.fail('Missing or incorrectly formatted CVE tag in patch file. Correct or include the CVE tag in the patch with format: "CVE: CVE-YYYY-XXXX"',
+                              commit=commit)