subtree updates

meta-arm: 025f76a14f..aba9250494: Anusmita Dutta Mazumder (2): arm-bsp/linux-yocto: Remove EOL Linux yocto kernel 6.1 arm-bsp/n1sdp: update to linux yocto kernel 6.6 Bence Balogh (1): arm-bsp/trusted-firmware-m: disable libmetal doc generation Drew Reed (5): meta-arm: Support firmware building under a multiconfig bsp,ci: Build Corstone-1000 firmware under multiconfig bsp: Restore the ability to build firmware only ci: Add back testing of firmware only builds ci: Ensure tests are in the Corstone-1000 flash image meta-raspberrypi: dbf1113a82..95a9103f91: Khem Raj (1): python3-sense-hat: Drop PYTHON_PN Martin Jansa (2): sdcard_image-rpi.bbclass: include ${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and ${IMAGE_LINK_NAME} sdimage-raspberrypi.wks: increase /boot partition minimal size from 20 to 100 meta-openembedded: 528f273006..9f0e513211: Andreas Mützel (1): python3-pynacl: allow -native build Chen Qi (1): unixodbc: fix odbc.pc file generation Daniel Ammann (1): sdmon: add new package Derek Straka (9): python3-trustme: add runtime dependency for tests and re-add to ptest python3-gunicorn: re-enable working ptests for the package python-inotify: re-enable working ptests for the package python3-license-expression: re-enable passing ptests for the package python3-jdcal: re-add functional ptests python3-msgpack: re-add functional ptests python3-parse: re-add functional ptests python3-typeguard: update ptest dependencies and re-enable functional tests python3-service-identity: add missing ptest dependencies and re-enable functional tests Jan Vermaete (1): netdata: version bump 1.43.2 -> 1.44.3 Joerg Hofrichter (1): python3-gevent: adding missing dependency to python3-zopeevent Khawaja Shaheryar (2): libdaq: add recipe snort: add snort3 initial recipe Khem Raj (25): python3-pocketsphinx: Upgrade to 5.0.3 snort: Do not use llvm libunwind snort3: Fix contains reference to TMPDIR [buildpaths] warnings libcamera: Replace VLAs with alloca dav1d: Inherit missing pkgconfig webkitgtk3: Fix build on 32bit x86 ptest-packagelists-meta-oe: Remove oprofile for rv32/rv64 python3-jsmin: Fix ptests to run with python 3.12+ python3-ordered-set: Use automake formatter for ptest output fuse3: Add missing runtime deps for ptests python3-looseversion: Add recipe sshfs-fuse: Fix ptest builds with python 3.12 meta-filesystems: Add meta-filesystems-image-ptest meta-multimedia-image-ptest: Add images to enable BBCLASSEXTEND parallel execution meta-networking-image-ptest: Add images to enable BBCLASSEXTEND parallel execution python3-scapy: Add missing rdeps for ptests ptest-packagelists-meta-oe.inc: Remove oprofile from PTESTS_PROBLEMS_META_OE ptest-packagelists-meta-networking: firewalld hangs therefore disabled ptest-packagelists-meta-perl.inc: Move couple of test to PTESTS_FAST_META_PERL openhpi: Fix ptest run time failures squid: Add missing bash dependency for ptest package meta-networking: Express dependency on meta-python ostree: Remove strace from ptest rdeps python3-pydantic-core,python3-pydantic: Update to 2.16.3 and 2.6.3 respectively python3-pydantic-core: Fix build for arches without 64bit atomics Lei Maohui (1): Fix install error when enable multilib. Markus Volk (7): iwd: update 2.13 -> 2.14 libgedit-gtksourceview: update 299.0.5 -> 299.1.0 gedit: update 46.1 -> 46.2 mutter: update 45.3 -> 45.4 gnome-shell: update 45.3 -> 45.4 gnome-control-center: update 45.2 -> 45.3 dav1d: update 1.3.0 -> 1.4.0 Martin Jansa (5): python3-httpx: respect libdir in packaging snort3: drop SRCPV from PV snort3: fix snort.pc gattlib: use python3native and depend on python3-packaging-native networkmanager-fortisslvpn: use python3native and depend on python3-packaging-native Mingli Yu (1): mariadb: Upgrade to 10.11.7 Niko Mauno (2): python3-pybind11: Migrate to python_setuptools_build_meta python3-pybind11: Restore strip prevention patch Oleh Matiusha (1): yasm: improve reproducibility Peter Marko (1): dnsmasq: Upgrade 2.89 -> 2.90 Romain Naour (1): wavemon: add recipe for version 0.9.5 Sascha Hauer (1): signing.bbclass: fix wrong function name Tim Orling (16): python_mesonpy.bbclass: move to oe-core python3-meson-python: move to oe-core python3-pyproject-metadata: move to oe-core meta-python: drop ${PYTHON_PN} meta-oe: drop ${PYTHON_PN} meta-filesystems: drop ${PYTHON_PN} meta-networking: drop ${PYTHON_PN} meta-gnome: drop ${PYTHON_PN} python3-pytest-lazy-fixtures: add 1.0.5 python3-prettytable: upgrade 3.9.0 => 3.10.0; fix ptests python3-pytest-lazy-fixture: drop recipe meta-oe-image-ptest: add PTESTS_PROBLEMS_META_OE meta-perl-image-ptest: add PTESTS_PROBLEMS_META_PERL meta-python-image-ptest: add PTESTS_PROBLEMS_META_PYTHON libencode-perl: drop recipe libencode-locale-perl: drop recipe Wang Mingyu (49): babl: upgrade 0.1.106 -> 0.1.108 btop: upgrade 1.3.0 -> 1.3.2 gegl: upgrade 0.4.46 -> 0.4.48 gjs: upgrade 1.78.3 -> 1.78.4 gnome-bluetooth: upgrade 42.7 -> 42.8 gnome-keyring: upgrade 42.1 -> 46.1 isomd5sum: upgrade 1.2.3 -> 1.2.4 libei: upgrade 1.2.0 -> 1.2.1 libmanette: upgrade 0.2.6 -> 0.2.7 libmime-types-perl: upgrade 2.24 -> 2.26 logwatch: upgrade 7.9 -> 7.10 mpich: upgrade 4.1.2 -> 4.2.0 ostree: upgrade 2024.1 -> 2024.3 python3-aiohue: upgrade 4.7.0 -> 4.7.1 python3-awesomeversion: upgrade 23.11.0 -> 24.2.0 python3-bidict: upgrade 0.22.1 -> 0.23.0 python3-cantools: upgrade 39.4.3 -> 39.4.4 python3-cmake: upgrade 3.28.1 -> 3.28.3 python3-django: upgrade 5.0.1 -> 5.0.2 python3-dnspython: upgrade 2.5.0 -> 2.6.0 python3-elementpath: upgrade 4.2.0 -> 4.3.0 python3-engineio: upgrade 4.8.2 -> 4.9.0 python3-gevent: upgrade 23.9.1 -> 24.2.1 unbound: upgrade 1.19.0 -> 1.19.1 wireshark: upgrade 4.2.2 -> 4.2.3 protobuf: upgrade 4.25.2 -> 4.25.3 webkitgtk3: upgrade 2.42.4 -> 2.42.5 python3-tqdm: upgrade 4.66.1 -> 4.66.2 python3-google-api-python-client: upgrade 2.116.0 -> 2.118.0 python3-httpcore: upgrade 1.0.2 -> 1.0.3 python3-jsbeautifier: upgrade 1.14.11 -> 1.15.1 python3-langtable: upgrade 0.0.64 -> 0.0.65 python3-polyline: upgrade 2.0.1 -> 2.0.2 python3-protobuf: upgrade 4.25.2 -> 4.25.3 python3-pymisp: upgrade 2.4.184 -> 2.4.185 python3-pymodbus: upgrade 3.6.3 -> 3.6.4 python3-pytest-asyncio: upgrade 0.23.4 -> 0.23.5 python3-tox: upgrade 4.12.1 -> 4.13.0 python3-twine: upgrade 4.0.2 -> 5.0.0 python3-watchdog: upgrade 3.0.0 -> 4.0.0 python3-zopeinterface: upgrade 6.1 -> 6.2 remmina: upgrade 1.4.33 -> 1.4.34 sip: upgrade 6.8.2 -> 6.8.3 python3-google-auth: upgrade 2.27.0 -> 2.28.0 python3-gspread: upgrade 6.0.1 -> 6.0.2 python3-socketio: upgrade 5.11.0 -> 5.11.1 python3-sentry-sdk: upgrade 1.40.0 -> 1.40.4 python3-pydantic-core: upgrade 2.14.6 -> 2.16.1 python3-pydantic: upgrade 2.5.3 -> 2.6.0 William Lyu (1): e2tools: Add ptest Yi Zhao (1): audit: upgrade 3.1.2 -> 4.0 Yoann Congal (2): influxdb: Fix /etc files owner influxdb: Add missing group to static id chenheyun (1): dropwatch: Use header files from sysroot instead of build host poky: fc8e5d7c13..25d60ac6f6: Adrian Freihofer (5): devtool: ide-sdk python 3.12 escaping sdk-manual: extensible.rst: cover devtool ide-sdk devtool: ide-sdk launch.json per recipe only devtool: ide-sdk prefer sources from workspace oe-selftest devtool: ide-sdk tests Alexander Kanavin (1): dbus: disable assertions and enable only modular tests Alexis Lothoré (7): testimage: log exception when failing to retrieve artifacts lib/oeqa: share get_json_result_dir helper testimage: create a list of failed test post actions oeqa/utils/postactions: isolate directory creation in dedicated action oeqa/utils/postactions: add target disk usage stat as post action oeqa/utils/postactions: testimage: add host disk usage stat as post action oeqa/lib/utils/postactions: fix host disk usage stats retrieval Bruce Ashfield (8): linux-yocto/6.6: update to v6.6.17 linux-yocto/6.6: update CVE exclusions linux-yocto/6.6: enable squashfs for selftests linux-yocto/6.6: config: x86 tidy & consolidation kern-tools: depend on git-replacement-native linux-yocto/6.6: genericarm64 configuration/definition linux-yocto/6.6: update to v6.6.18 linux-yocto/6.6: update CVE exclusions Christoph Vogtländer (1): overlayfs: add missing vardeps Claus Stovgaard (1): wpa-supplicant: Fix CVE-2023-52160 Eilís 'pidge' Ní Fhlannagáin (2): creategroup*: Remove coreutils-native as a DEPENDS selftest-users: Convoluted selftest for USERADD_DEPENDS Emil Kronborg (1): bluez5: remove configuration files from install task Enguerrand de Ribaucourt (4): devtool: ide: define compilerPath for meson projects Revert "meson: use absolute cross-compiler paths" bitbake: bitbake: progressbar: accept value over initial maxval devtool: ide-sdk source mapping for vscode Enrico Jörns (1): wic: 'empty' plugin: fix typo in comment Joe Slater (1): qemuboot: predictable network interface names Jonathan GUILLOT (2): lib/oe/package: fix LOCALE_PATHS scan to create locale packages glibc-locale: add an explicit dedicated package for locale.alias file Jose Quaresma (1): go: update 1.20.13 -> 1.20.14 Joshua Watt (1): bitbake: asyncrpc: Add support for server headers Khem Raj (6): ncurses: Always pass -D_GNU_SOURCE linux-yocto: Remove unused patch ref-manual: variables: remove PYTHON_PN python3-bcrypt: Fix build break on arches without 64 bit atomics python3-maturin: Recognise riscv32 architecture llvm: Update to 18.1.0 RC4 Lee Chee Yang (1): migration-guide: add release notes for 4.3.3 Lei Maohui (1): rpm: Fix the following error when run nativesdk-rpm in nativesdk environment. Martin Jansa (1): glib-2.0: backport a switch from distutils to packaging in codegen Michael Halstead (1): yocto-uninative: Update to 4.4 for glibc 2.39 Michael Opdenacker (5): ref-manual: system-requirements: update packages to build docs ref-manual: release-process: grammar fix manuals: suppress excess use of "following" word dev-manual: packages: clarify shared PR service constraint dev-manual: packages: need enough free space Munehisa Kamata (1): kernel.bbclass: Set pkg-config variables for building modules Nick Owens (1): python3: dont disable readline module for editline Philip Lorenz (1): bitbake: fetch2: Ensure that git LFS objects are available Piotr Łobacz (1): useradd.bbclass: Fix order of postinst-useradd-* Richard Purdie (6): numactl: Upgrade 2.0.17 -> 2.0.18 lttng-ust: Upgrade 2.13.6 -> 2.13.7 oeqa/selftest/rust: Simplify the rust testsuite output gathering/processing recipetool: Fix errors with meta-poky bbappend bitbake: runqueue: Add support for BB_LOADFACTOR_MAX mirrors: Switch llvm to use shallow cloning Ross Burton (4): base-files: add usage warning to motd libexif: remove unused version_underscore gstreamer1.0: skip a test that is known to be flaky linux-firmware: split out more firmware pieces Simone Weiß (6): patchtest: provide further guidance for failed testcases patchtest: Skip test for CVE_CHECK_IGNORE for older branches meta: Remove some not needed CVE_STATUS meta: Update CVE_STATUS for incorrect cpes cve-check: Log if CVE_STATUS set but not reported for component dev-manual: Rephrase spdx creation Soumya Sambu (1): bind: Upgrade 9.18.21 -> 9.18.24 Tim Orling (3): bitbake: layerindexlib: fix missing layer branch backtrace python3-cryptography{-vectors}: upgrade to 42.0.5 python3-attrs: disable Hypothesis deadline Tobias Hagelborn (1): bitbake: hashserv: Re-enable connection pooling with psycopg 3 driver Trevor Gamblin (1): python3-git: upgrade 3.1.41 -> 3.1.42 Trevor Woerner (1): wic: allow imager-specific filename extensions Ulrich Ölmann (1): bitbake: taskexp_ncurses: fix execution example in introductory comment Wang Mingyu (44): bash-completion: upgrade 2.11 -> 2.12.0 ccache: upgrade 4.9 -> 4.9.1 createrepo-c: upgrade 1.0.3 -> 1.0.4 ed: upgrade 1.20 -> 1.20.1 efivar: upgrade 38 -> 39 gcr: upgrade 4.1.0 -> 4.2.0 git: upgrade 2.43.0 -> 2.44.0 libffi: upgrade 3.4.5 -> 3.4.6 libgpg-error: upgrade 1.47 -> 1.48 libhandy: upgrade 1.8.2 -> 1.8.3 libksba: upgrade 1.6.5 -> 1.6.6 libmicrohttpd: upgrade 0.9.77 -> 1.0.1 libpng: upgrade 1.6.41 -> 1.6.42 libsecret: upgrade 0.21.2 -> 0.21.4 libunistring: upgrade 1.1 -> 1.2 liburi-perl: upgrade 5.25 -> 5.27 libxext: upgrade 1.3.5 -> 1.3.6 libxkbfile: upgrade 1.1.2 -> 1.1.3 libxvmc: upgrade 1.0.13 -> 1.0.14 lighttpd: upgrade 1.4.73 -> 1.4.74 makedepend: upgrade 1.0.8 -> 1.0.9 mpg123: upgrade 1.32.4 -> 1.32.5 ofono: upgrade 2.3 -> 2.4 pango: upgrade 1.51.0 -> 1.52.0 pciutils: upgrade 3.10.0 -> 3.11.1 pkgconf: upgrade 2.1.0 -> 2.1.1 python3-beartype: upgrade 0.17.0 -> 0.17.2 python3-certifi: upgrade 2023.11.17 -> 2024.2.2 python3-dbusmock: upgrade 0.30.2 -> 0.31.1 python3-hypothesis: upgrade 6.97.3 -> 6.98.12 python3-pip: upgrade 23.3.2 -> 24.0 python3-pycairo: upgrade 1.25.1 -> 1.26.0 python3-pytest: upgrade 8.0.0 -> 8.0.2 python3-pytz: upgrade 2023.4 -> 2024.1 python3-setuptools-rust: upgrade 1.8.1 -> 1.9.0 python3-trove-classifiers: upgrade 2024.1.8 -> 2024.2.23 python3-typing-extensions: upgrade 4.9.0 -> 4.10.0 python3: upgrade 3.12.1 -> 3.12.2 python3-urllib3: upgrade 2.1.0 -> 2.2.1 python3-yamllint: upgrade 1.33.0 -> 1.35.1 swig: upgrade 4.2.0 -> 4.2.1 xkbcomp: upgrade 1.4.6 -> 1.4.7 xkeyboard-config: upgrade 2.40 -> 2.41 xprop: upgrade 1.2.6 -> 1.2.7 Xiangyu Chen (2): systemd-systemctl: fix dead loop when multi services enable each other libc-locale: fix ASCII compatible warning cause build failure. Xiaotian Wu (2): loongarch64: change -march to loongarch64 openssl: Match target name for loongarch64 Yash Shinde (3): rust: Upgrade 1.74.1 -> 1.75.0 rust: Revert PGO to it's default rust: reproducibility issue fix with v1.75 Yoann Congal (1): waf: Improve version parsing to avoid failing on warnings Change-Id: I6dfb848feb4ec8f5aae56a9ccbff475f4eb1edc6 Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
author: Patrick Williams <patrick@stwcx.xyz> 2024-03-01 17:54:02 +0300
committer: Patrick Williams <patrick@stwcx.xyz> 2024-03-01 19:12:33 +0300
commit: 396535664c5645a0b32bd0e06dbab3f1e2849b64 (patch)
tree: dcf5c28dc344e5906f266d9644e0cfab226134a0 /poky/documentation
parent: 73bd93f1d0a338767f36fd1acb54c52ad057db39 (diff)
download: openbmc-396535664c5645a0b32bd0e06dbab3f1e2849b64.tar.xz
41 files changed, 613 insertions, 140 deletions
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 29c69a9305..11ca5d8b76 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -851,8 +851,7 @@ Before looking at BSP requirements, you should consider the following:
    dictating that a specific kernel or kernel version be used in a given
    BSP.
 
-Following are the requirements for a released BSP that conform to the
-Yocto Project:
+The requirements for a released BSP that conform to the Yocto Project are:
 
 -  *Layer Name:* The BSP must have a layer name that follows the Yocto
    Project standards. For information on BSP layer names, see the
@@ -956,7 +955,7 @@ Yocto Project:
 Released BSP Recommendations
 ----------------------------
 
-Following are recommendations for released BSPs that conform to the
+Here are recommendations for released BSPs that conform to the
 Yocto Project:
 
 -  *Bootable Images:* Released BSPs can contain one or more bootable
@@ -1018,7 +1017,7 @@ the following:
    that additional hierarchy and the files would obviously not be able
    to reside in a machine-specific directory.
 
-Following is a specific example to help you better understand the
+Here is a specific example to help you better understand the
 process. This example customizes a recipe by adding a
 BSP-specific configuration file named ``interfaces`` to the
 ``init-ifupdown_1.0.bb`` recipe for machine "xyz" where the BSP layer
@@ -1448,7 +1447,7 @@ metadata used to build the kernel. In this case, a kernel append file
 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::
+The contents of the append file are::
 
    KBRANCH:genericx86  = "v6.1/standard/base"
    KBRANCH:genericx86-64  = "v6.1/standard/base"
diff --git a/poky/documentation/dev-manual/building.rst b/poky/documentation/dev-manual/building.rst
index e964bd1aee..7fcac33b75 100644
--- a/poky/documentation/dev-manual/building.rst
+++ b/poky/documentation/dev-manual/building.rst
@@ -160,7 +160,7 @@ Follow these steps to set up and execute multiple configuration builds:
    The location for these multiconfig configuration files is specific.
    They must reside in the current :term:`Build Directory` in a sub-directory of
    ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory
-   under a directory named ``multiconfig``. Following is an example that defines
+   under a directory named ``multiconfig``. Here is an example that defines
    two configuration files for the "x86" and "arm" multiconfigs:
 
    .. image:: figures/multiconfig_files.png
diff --git a/poky/documentation/dev-manual/debugging.rst b/poky/documentation/dev-manual/debugging.rst
index 834eade766..ce29815e9f 100644
--- a/poky/documentation/dev-manual/debugging.rst
+++ b/poky/documentation/dev-manual/debugging.rst
@@ -170,7 +170,7 @@ You can use the ``oe-pkgdata-util`` command-line utility to query
 various package-related information. When you use the utility, you must
 use it to view information on packages that have already been built.
 
-Following are a few of the available ``oe-pkgdata-util`` subcommands.
+Here are a few of the available ``oe-pkgdata-util`` subcommands.
 
 .. note::
 
@@ -608,7 +608,7 @@ logs, keep in mind the goal is to have informative logs while keeping
 the console as "silent" as possible. Also, if you want status messages
 in the log, use the "debug" loglevel.
 
-Following is an example written in Python. The code handles logging for
+Here is an example written in Python. The code handles logging for
 a function that determines the number of tasks needed to be run. See the
 ":ref:`ref-tasks-listtasks`"
 section for additional information::
@@ -636,7 +636,7 @@ logs, you have the same goals --- informative with minimal console output.
 The syntax you use for recipes written in Bash is similar to that of
 recipes written in Python described in the previous section.
 
-Following is an example written in Bash. The code logs the progress of
+Here is an example written in Bash. The code logs the progress of
 the ``do_my_function`` function::
 
    do_my_function() {
@@ -1236,7 +1236,7 @@ Here are some other tips that you might find useful:
                "$@"
       }
 
-   Following are some usage examples::
+   Here are some usage examples::
 
       $ g FOO # Search recursively for "FOO"
       $ g -i foo # Search recursively for "foo", ignoring case
diff --git a/poky/documentation/dev-manual/development-shell.rst b/poky/documentation/dev-manual/development-shell.rst
index a18d792150..be26bcffc7 100644
--- a/poky/documentation/dev-manual/development-shell.rst
+++ b/poky/documentation/dev-manual/development-shell.rst
@@ -16,7 +16,7 @@ OpenEmbedded build system were executing them. Consequently, working
 this way can be helpful when debugging a build or preparing software to
 be used with the OpenEmbedded build system.
 
-Following is an example that uses ``devshell`` on a target named
+Here is an example that uses ``devshell`` on a target named
 ``matchbox-desktop``::
 
   $ bitbake matchbox-desktop -c devshell
diff --git a/poky/documentation/dev-manual/layers.rst b/poky/documentation/dev-manual/layers.rst
index b3ccf633df..f7929e630e 100644
--- a/poky/documentation/dev-manual/layers.rst
+++ b/poky/documentation/dev-manual/layers.rst
@@ -82,7 +82,7 @@ Follow these general steps to create your layer without using tools:
       LAYERVERSION_yoctobsp = "4"
       LAYERSERIES_COMPAT_yoctobsp = "dunfell"
 
-   Following is an explanation of the layer configuration file:
+   Here is an explanation of the layer configuration file:
 
    -  :term:`BBPATH`: Adds the layer's
       root directory to BitBake's search path. Through the use of the
@@ -191,7 +191,7 @@ following list:
 -  *Structure Your Layers:* Proper use of overrides within append files
    and placement of machine-specific files within your layer can ensure
    that a build is not using the wrong Metadata and negatively impacting
-   a build for a different machine. Following are some examples:
+   a build for a different machine. Here are some examples:
 
    -  *Modify Variables to Support a Different Machine:* Suppose you
       have a layer named ``meta-one`` that adds support for building
@@ -513,7 +513,7 @@ In the main recipe, note the :term:`SRC_URI`
 variable, which tells the OpenEmbedded build system where to find files
 during the build.
 
-Following is the append file, which is named ``formfactor_0.0.bbappend``
+Here is the append file, which is named ``formfactor_0.0.bbappend``
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
 file is in the layer at ``recipes-bsp/formfactor``::
 
@@ -588,7 +588,7 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
 	fi
    }
 
-Following is the append file, which is named ``xserver-xf86-config_%.bbappend``
+Here is the append file, which is named ``xserver-xf86-config_%.bbappend``
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
 file is in the layer at ``recipes-graphics/xorg-xserver``::
 
diff --git a/poky/documentation/dev-manual/libraries.rst b/poky/documentation/dev-manual/libraries.rst
index ae4ca27209..521dbb9a7c 100644
--- a/poky/documentation/dev-manual/libraries.rst
+++ b/poky/documentation/dev-manual/libraries.rst
@@ -37,7 +37,7 @@ library files.
    Some previously released versions of the Yocto Project defined the
    static library files through ``${PN}-dev``.
 
-Following is part of the BitBake configuration file, where you can see
+Here is the part of the BitBake configuration file, where you can see
 how the static library files are defined::
 
    PACKAGE_BEFORE_PN ?= ""
@@ -177,7 +177,7 @@ Additional Implementation Details
 ---------------------------------
 
 There are generic implementation details as well as details that are specific to
-package management systems. Following are implementation details
+package management systems. Here are implementation details
 that exist regardless of the package management system:
 
 -  The typical convention used for the class extension code as used by
diff --git a/poky/documentation/dev-manual/licenses.rst b/poky/documentation/dev-manual/licenses.rst
index 57713effa0..bffff3675f 100644
--- a/poky/documentation/dev-manual/licenses.rst
+++ b/poky/documentation/dev-manual/licenses.rst
@@ -27,7 +27,7 @@ Specifying the ``LIC_FILES_CHKSUM`` Variable
 --------------------------------------------
 
 The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text
-in the source code for the recipe. Following is an example of how to
+in the source code for the recipe. Here is an example of how to
 specify :term:`LIC_FILES_CHKSUM`::
 
    LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
diff --git a/poky/documentation/dev-manual/new-machine.rst b/poky/documentation/dev-manual/new-machine.rst
index 6b41d24db4..469b2d395a 100644
--- a/poky/documentation/dev-manual/new-machine.rst
+++ b/poky/documentation/dev-manual/new-machine.rst
@@ -104,7 +104,7 @@ contains directories for specific machines such as ``qemuarm`` and
 defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file
 found in the same area.
 
-Following is an example for "qemuarm" machine::
+Here is an example for "qemuarm" machine::
 
    HAVE_TOUCHSCREEN=1
    HAVE_KEYBOARD=1
diff --git a/poky/documentation/dev-manual/new-recipe.rst b/poky/documentation/dev-manual/new-recipe.rst
index 2c1033eb35..61fc2eb122 100644
--- a/poky/documentation/dev-manual/new-recipe.rst
+++ b/poky/documentation/dev-manual/new-recipe.rst
@@ -100,7 +100,7 @@ command::
 
 Running ``recipetool create -o OUTFILE`` creates the base recipe and
 locates it properly in the layer that contains your source files.
-Following are some syntax examples:
+Here are some syntax examples:
 
  - Use this syntax to generate a recipe based on source. Once generated,
    the recipe resides in the existing source code layer::
@@ -1232,7 +1232,7 @@ inherit the :ref:`ref-classes-autotools` class, which contains the definitions
 of all the steps needed to build an Autotool-based application. The result of
 the build is automatically packaged. And, if the application uses NLS for
 localization, packages with local information are generated (one package per
-language). Following is one example: (``hello_2.3.bb``)::
+language). Here is one example: (``hello_2.3.bb``)::
 
    SUMMARY = "GNU Helloworld application"
    SECTION = "examples"
@@ -1285,7 +1285,7 @@ Splitting an Application into Multiple Packages
 You can use the variables :term:`PACKAGES` and :term:`FILES` to split an
 application into multiple packages.
 
-Following is an example that uses the ``libxpm`` recipe. By default,
+Here is an example that uses the ``libxpm`` recipe. By default,
 this recipe generates a single package that contains the library along
 with a few binaries. You can modify the recipe to split the binaries
 into separate packages::
@@ -1510,7 +1510,7 @@ in the BitBake User Manual.
       when you make the assignment, but this is not generally needed.
 
 -  *Quote All Assignments ("value"):* Use double quotes around values in
-   all variable assignments (e.g. ``"value"``). Following is an example::
+   all variable assignments (e.g. ``"value"``). Here is an example::
 
       VAR1 = "${OTHERVAR}"
       VAR2 = "The version is ${PV}"
diff --git a/poky/documentation/dev-manual/packages.rst b/poky/documentation/dev-manual/packages.rst
index 79f21d9f34..a6e6af0de7 100644
--- a/poky/documentation/dev-manual/packages.rst
+++ b/poky/documentation/dev-manual/packages.rst
@@ -205,9 +205,14 @@ history, see the
    The OpenEmbedded build system does not maintain :term:`PR` information as
    part of the shared state (sstate) packages. If you maintain an sstate
    feed, it's expected that either all your building systems that
-   contribute to the sstate feed use a shared PR Service, or you do not
-   run a PR Service on any of your building systems. Having some systems
-   use a PR Service while others do not leads to obvious problems.
+   contribute to the sstate feed use a shared PR service, or you do not
+   run a PR Service on any of your building systems.
+
+   That's because if you had multiple machines sharing a PR service but
+   not their sstate feed, you could end up with "diverging" hashes for
+   the same output artefacts. When presented to the share PR service,
+   each would be considered as new and would increase the revision
+   number, causing many unnecessary package upgrades.
 
    For more information on shared state, see the
    ":ref:`overview-manual/concepts:shared state cache`"
@@ -365,7 +370,7 @@ For more examples that show how to use ``do_split_packages``, see the
 directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
 also find examples in ``meta/classes-recipe/kernel.bbclass``.
 
-Following is a reference that shows ``do_split_packages`` mandatory and
+Here is a reference that shows ``do_split_packages`` mandatory and
 optional arguments::
 
    Mandatory arguments
@@ -607,6 +612,13 @@ subsequent sections are necessary to configure the target. You should
 set these variables before building the image in order to produce a
 correctly configured image.
 
+.. note::
+
+   Your image will need enough free storage space to run package upgrades,
+   especially if many of them need to be downloaded at the same time.
+   You should make sure images are created with enough free space
+   by setting the :term:`IMAGE_ROOTFS_EXTRA_SPACE` variable.
+
 When your build is complete, your packages reside in the
 ``${TMPDIR}/deploy/packageformat`` directory. For example, if
 ``${``\ :term:`TMPDIR`\ ``}`` is
@@ -1123,7 +1135,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe::
    ...
    LICENSE:${PN}-vary = "MIT"
 
-Here are three key points in the previous example:
+Three key points in the previous example are:
 
 -  :term:`SRC_URI` uses the NPM
    scheme so that the NPM fetcher is used.
diff --git a/poky/documentation/dev-manual/prebuilt-libraries.rst b/poky/documentation/dev-manual/prebuilt-libraries.rst
index b80a844e93..a05f39ca1e 100644
--- a/poky/documentation/dev-manual/prebuilt-libraries.rst
+++ b/poky/documentation/dev-manual/prebuilt-libraries.rst
@@ -148,8 +148,8 @@ recipe. By default, ``libfoo.so`` gets packaged into ``${PN}-dev``, which
 triggers a QA warning that a non-symlink library is in a ``-dev`` package,
 and binaries in the same recipe link to the library in ``${PN}-dev``,
 which triggers more QA warnings. To solve this problem, you need to package the
-unversioned library into ``${PN}`` where it belongs. The following are the abridged
-default :term:`FILES` variables in ``bitbake.conf``::
+unversioned library into ``${PN}`` where it belongs. The abridged
+default :term:`FILES` variables in ``bitbake.conf`` are::
 
    SOLIBS = ".so.*"
    SOLIBSDEV = ".so"
diff --git a/poky/documentation/dev-manual/python-development-shell.rst b/poky/documentation/dev-manual/python-development-shell.rst
index 2dc6a3f138..81a5c43472 100644
--- a/poky/documentation/dev-manual/python-development-shell.rst
+++ b/poky/documentation/dev-manual/python-development-shell.rst
@@ -35,7 +35,7 @@ system were executing them. Consequently, working this way can be
 helpful when debugging a build or preparing software to be used with the
 OpenEmbedded build system.
 
-Following is an example that uses ``pydevshell`` on a target named
+Here is an example that uses ``pydevshell`` on a target named
 ``matchbox-desktop``::
 
    $ bitbake matchbox-desktop -c pydevshell
diff --git a/poky/documentation/dev-manual/qemu.rst b/poky/documentation/dev-manual/qemu.rst
index d431ea4b99..19f3e40d63 100644
--- a/poky/documentation/dev-manual/qemu.rst
+++ b/poky/documentation/dev-manual/qemu.rst
@@ -311,7 +311,7 @@ timestamp when it needs to look for an image. Minimally, through the use
 of options, you must provide either a machine name, a virtual machine
 image (``*wic.vmdk``), or a kernel image (``*.bin``).
 
-Following is the command-line help output for the ``runqemu`` command::
+Here is the command-line help output for the ``runqemu`` command::
 
    $ runqemu --help
 
@@ -353,7 +353,7 @@ Following is the command-line help output for the ``runqemu`` command::
 ``runqemu`` Command-Line Options
 ================================
 
-Following is a description of ``runqemu`` options you can provide on the
+Here is a description of ``runqemu`` options you can provide on the
 command line:
 
 .. note::
diff --git a/poky/documentation/dev-manual/runtime-testing.rst b/poky/documentation/dev-manual/runtime-testing.rst
index 1a2e9ec4fe..7a2b42f25a 100644
--- a/poky/documentation/dev-manual/runtime-testing.rst
+++ b/poky/documentation/dev-manual/runtime-testing.rst
@@ -193,7 +193,7 @@ perform a one-time setup of your controller image by doing the following:
    "controller" image and you can customize the image recipe as you would
    any other recipe.
 
-   Here are the image recipe requirements:
+   Image recipe requirements are:
 
    -  Inherits ``core-image`` so that kernel modules are installed.
 
@@ -572,7 +572,7 @@ data:
    When set to "true", the package is not automatically installed into
    the DUT.
 
-Following is an example JSON file that handles test "foo" installing
+Here is an example JSON file that handles test "foo" installing
 package "bar" and test "foobar" installing packages "foo" and "bar".
 Once the test is complete, the packages are removed from the DUT::
 
diff --git a/poky/documentation/dev-manual/sbom.rst b/poky/documentation/dev-manual/sbom.rst
index f51d08f84d..b72bad1554 100644
--- a/poky/documentation/dev-manual/sbom.rst
+++ b/poky/documentation/dev-manual/sbom.rst
@@ -30,22 +30,29 @@ To make this happen, you must inherit the
 
    INHERIT += "create-spdx"
 
-You then get :term:`SPDX` output in JSON format as an
-``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
-:term:`Build Directory`.
+Upon building an image, you will then get:
 
-This is a toplevel file accompanied by an ``IMAGE-MACHINE.spdx.index.json``
-containing an index of JSON :term:`SPDX` files for individual recipes, together
-with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
-files.
+-  :term:`SPDX` output in JSON format as an ``IMAGE-MACHINE.spdx.json`` file in
+   ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`.
+
+-  This toplevel file is accompanied by an ``IMAGE-MACHINE.spdx.index.json``
+   containing an index of JSON :term:`SPDX` files for individual recipes.
+
+-  The compressed archive ``IMAGE-MACHINE.spdx.tar.zst`` contains the index
+   and the files for the single recipes.
 
 The :ref:`ref-classes-create-spdx` class offers options to include
-more information in the output :term:`SPDX` data, such as making the generated
-files more human readable (:term:`SPDX_PRETTY`), adding compressed archives of
-the files in the generated target packages (:term:`SPDX_ARCHIVE_PACKAGED`),
-adding a description of the source files used to generate host tools and target
-packages (:term:`SPDX_INCLUDE_SOURCES`) and adding archives of these source
-files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
+more information in the output :term:`SPDX` data:
+
+-  Make the json files more human readable by setting (:term:`SPDX_PRETTY`).
+
+-  Add compressed archives of the files in the generated target packages by
+   setting (:term:`SPDX_ARCHIVE_PACKAGED`).
+
+-  Add a description of the source files used to generate host tools and target
+   packages (:term:`SPDX_INCLUDE_SOURCES`)
+
+-  Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
 
 Though the toplevel :term:`SPDX` output is available in
 ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`, ancillary
@@ -65,11 +72,12 @@ generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as:
 
 See also the :term:`SPDX_CUSTOM_ANNOTATION_VARS` variable which allows
 to associate custom notes to a recipe.
-
 See the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX`
 project website for a list of tools to consume and transform the :term:`SPDX`
 data generated by the OpenEmbedded build system.
 
-See also Joshua Watt's
+See also Joshua Watt's presentations
 `Automated SBoM generation with OpenEmbedded and the Yocto Project <https://youtu.be/Q5UQUM6zxVU>`__
-presentation at FOSDEM 2023.
+at FOSDEM 2023 and
+`SPDX in the Yocto Project <https://fosdem.org/2024/schedule/event/fosdem-2024-3318-spdx-in-the-yocto-project/>`__
+at FOSDEM 2024.
diff --git a/poky/documentation/dev-manual/speeding-up-build.rst b/poky/documentation/dev-manual/speeding-up-build.rst
index 31b6f75ab0..6e0d7873ac 100644
--- a/poky/documentation/dev-manual/speeding-up-build.rst
+++ b/poky/documentation/dev-manual/speeding-up-build.rst
@@ -33,7 +33,7 @@ auto-scaling ensures that the build system fundamentally takes advantage
 of potential parallel operations during the build based on the build
 machine's capabilities.
 
-Following are additional factors that can affect build speed:
+Additional factors that can affect build speed are:
 
 -  File system type: The file system type that the build is being
    performed on can also influence performance. Using ``ext4`` is
@@ -88,7 +88,7 @@ that can help you speed up the build:
    variable to "1".
 
 -  Disable static library generation for recipes derived from
-   ``autoconf`` or ``libtool``: Following is an example showing how to
+   ``autoconf`` or ``libtool``: Here is an example showing how to
    disable static libraries and still provide an override to handle
    exceptions::
 
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index b108337795..8539bc0889 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -36,7 +36,7 @@ particular working environment and set of practices.
     equipment together and set up your development environment's
     hardware topology.
 
-    Here are possible roles:
+    Possible roles are:
 
     -  *Application Developer:* This type of developer does application
        level work on top of an existing software stack.
@@ -99,7 +99,7 @@ particular working environment and set of practices.
 
 #.  *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
+    software stacks. Here are some best practices for setting up
     machines used for application development:
 
     -  Use a pre-built toolchain that contains the software stack
@@ -118,7 +118,7 @@ particular working environment and set of practices.
 
 #.  *Set up the Core Development Machines:* As mentioned earlier, core
     developers work on the contents of the operating system itself.
-    Following are some best practices for setting up machines used for
+    Here are some best practices for setting up machines used for
     developing images:
 
     -  Have the :term:`OpenEmbedded Build System` available on
diff --git a/poky/documentation/kernel-dev/common.rst b/poky/documentation/kernel-dev/common.rst
index 9b197bfccb..0cee503346 100644
--- a/poky/documentation/kernel-dev/common.rst
+++ b/poky/documentation/kernel-dev/common.rst
@@ -1295,7 +1295,7 @@ In order to run this task, you must have an existing ``.config`` file.
 See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
 information on how to create a configuration file.
 
-Following is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
+Here is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
 
 .. code-block:: none
 
@@ -1726,7 +1726,7 @@ tree. Using Git is an efficient way to see what has changed in the tree.
 What Changed in a Kernel?
 -------------------------
 
-Following are a few examples that show how to use Git commands to
+Here are a few examples that show how to use Git commands to
 examine changes. These examples are by no means the only way to see
 changes.
 
diff --git a/poky/documentation/migration-guides/migration-1.5.rst b/poky/documentation/migration-guides/migration-1.5.rst
index d82d33f91f..c8f3cbc165 100644
--- a/poky/documentation/migration-guides/migration-1.5.rst
+++ b/poky/documentation/migration-guides/migration-1.5.rst
@@ -256,7 +256,7 @@ section in the Yocto Project Development Tasks Manual.
 Build History
 -------------
 
-Following are changes to Build History:
+The changes to Build History are:
 
 -  Installed package sizes: ``installed-package-sizes.txt`` for an image
    now records the size of the files installed by each package instead
@@ -279,7 +279,7 @@ section in the Yocto Project Development Tasks Manual.
 ``udev``
 --------
 
-Following are changes to ``udev``:
+The changes to ``udev`` are:
 
 -  ``udev`` no longer brings in ``udev-extraconf`` automatically through
    :term:`RRECOMMENDS`, since this was originally
@@ -323,7 +323,7 @@ Removed and Renamed Recipes
 Other Changes
 -------------
 
-Following is a list of short entries describing other changes:
+Here is a list of short entries describing other changes:
 
 -  ``run-postinsts``: Make this generic.
 
diff --git a/poky/documentation/migration-guides/migration-2.2.rst b/poky/documentation/migration-guides/migration-2.2.rst
index 3932792c78..9d50dc6202 100644
--- a/poky/documentation/migration-guides/migration-2.2.rst
+++ b/poky/documentation/migration-guides/migration-2.2.rst
@@ -73,8 +73,8 @@ Metadata Must Now Use Python 3 Syntax
 The metadata is now required to use Python 3 syntax. For help preparing
 metadata, see any of the many Python 3 porting guides available.
 Alternatively, you can reference the conversion commits for BitBake and
-you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
-particular areas of interest:
+you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes.
+Particular areas of interest are:
 
   - subprocess command-line pipes needing locale decoding
 
@@ -182,7 +182,7 @@ root filesystem, provides an image, and uses the ``nographic`` option::
 
    $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
 
-Following is a list of variables that can be set in configuration files
+Here is a list of variables that can be set in configuration files
 such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``::
 
    QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386")
diff --git a/poky/documentation/migration-guides/migration-2.4.rst b/poky/documentation/migration-guides/migration-2.4.rst
index abad43acc3..5d5d601988 100644
--- a/poky/documentation/migration-guides/migration-2.4.rst
+++ b/poky/documentation/migration-guides/migration-2.4.rst
@@ -91,8 +91,6 @@ occurred:
 Removed Recipes
 ---------------
 
-The following recipes have been removed:
-
 -  ``acpitests``: This recipe is not maintained.
 
 -  ``autogen-native``: No longer required by Grub, oe-core, or
@@ -213,8 +211,6 @@ recipes you might have. This will avoid breakage in post 2.4 releases.
 Package QA Changes
 ------------------
 
-The following package QA changes took place:
-
 -  The "unsafe-references-in-scripts" QA check has been removed.
 
 -  If you refer to ``${COREBASE}/LICENSE`` within
@@ -229,8 +225,6 @@ The following package QA changes took place:
 ``README`` File Changes
 -----------------------
 
-The following are changes to ``README`` files:
-
 -  The main Poky ``README`` file has been moved to the ``meta-poky``
    layer and has been renamed ``README.poky``. A symlink has been
    created so that references to the old location work.
@@ -246,8 +240,6 @@ The following are changes to ``README`` files:
 Miscellaneous Changes
 ---------------------
 
-The following are additional changes:
-
 -  The ``ROOTFS_PKGMANAGE_BOOTSTRAP`` variable and any references to it
    have been removed. You should remove this variable from any custom
    recipes.
diff --git a/poky/documentation/migration-guides/migration-2.5.rst b/poky/documentation/migration-guides/migration-2.5.rst
index 9f089bb93b..facf5110b7 100644
--- a/poky/documentation/migration-guides/migration-2.5.rst
+++ b/poky/documentation/migration-guides/migration-2.5.rst
@@ -87,8 +87,6 @@ The following recipes have been removed:
 Scripts and Tools Changes
 -------------------------
 
-The following are changes to scripts and tools:
-
 -  ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``: The
    ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer`` scripts
    previously shipped with poky but not in OpenEmbedded-Core have been
@@ -119,8 +117,6 @@ The following are changes to scripts and tools:
 BitBake Changes
 ---------------
 
-The following are BitBake changes:
-
 -  The ``--runall`` option has changed. There are two different
    behaviors people might want:
 
@@ -153,7 +149,7 @@ The following are BitBake changes:
 Python and Python 3 Changes
 ---------------------------
 
-The following are auto-packaging changes to Python and Python 3:
+Here are auto-packaging changes to Python and Python 3:
 
 The script-managed ``python-*-manifest.inc`` files that were previously
 used to generate Python and Python 3 packages have been replaced with a
@@ -187,8 +183,6 @@ change please see :yocto_git:`this commit
 Miscellaneous Changes
 ---------------------
 
-The following are additional changes:
-
 -  The :ref:`ref-classes-kernel` class supports building packages for multiple kernels.
    If your kernel recipe or ``.bbappend`` file mentions packaging at
    all, you should replace references to the kernel in package names
diff --git a/poky/documentation/migration-guides/migration-4.0.rst b/poky/documentation/migration-guides/migration-4.0.rst
index 2aa9145ef8..b5bd57c312 100644
--- a/poky/documentation/migration-guides/migration-4.0.rst
+++ b/poky/documentation/migration-guides/migration-4.0.rst
@@ -142,7 +142,7 @@ Python changes
   classes should be updated to inherit ``setuptools*`` equivalents instead.
   
 - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__.
-  Here are the new Python packaging classes that should be used:
+  The new Python packaging classes that should be used are
   :ref:`ref-classes-python_flit_core`, :ref:`ref-classes-python_setuptools_build_meta`
   and :ref:`ref-classes-python_poetry_core`.
 
diff --git a/poky/documentation/migration-guides/release-4.3.rst b/poky/documentation/migration-guides/release-4.3.rst
index 3adb5b620e..fa5653c467 100644
--- a/poky/documentation/migration-guides/release-4.3.rst
+++ b/poky/documentation/migration-guides/release-4.3.rst
@@ -9,3 +9,4 @@ Release 4.3 (nanbield)
    release-notes-4.3
    release-notes-4.3.1
    release-notes-4.3.2
+   release-notes-4.3.3
diff --git a/poky/documentation/migration-guides/release-notes-4.3.3.rst b/poky/documentation/migration-guides/release-notes-4.3.3.rst
new file mode 100644
index 0000000000..2a0658a9c9
--- /dev/null
+++ b/poky/documentation/migration-guides/release-notes-4.3.3.rst
@@ -0,0 +1,200 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.3.3 (Nanbield)
+----------------------------------------
+
+Security Fixes in Yocto-4.3.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  curl: Fix :cve:`2023-46219`
+-  glibc: Ignore fixed :cve:`2023-0687` and :cve:`2023-5156`
+-  linux-yocto/6.1: Ignore :cve:`2022-48619`, :cve:`2023-4610`, :cve:`2023-5178`, :cve:`2023-5972`, :cve:`2023-6040`, :cve:`2023-6531`, :cve:`2023-6546`, :cve:`2023-6622`, :cve:`2023-6679`, :cve:`2023-6817`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2023-7192`, :cve:`2024-0193` and :cve:`2024-0443`
+-  linux-yocto/6.1: Fix :cve:`2023-1193`, :cve_mitre:`2023-51779`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782` and :cve:`2023-6606`
+-  qemu: Fix :cve:`2023-3019`
+-  shadow: Fix :cve:`2023-4641`
+-  sqlite3: Fix :cve:`2024-0232`
+-  sqlite3: drop obsolete CVE ignore :cve:`2023-36191`
+-  sudo: Fix :cve:`2023-42456` and :cve:`2023-42465`
+-  tiff: Fix :cve:`2023-6277`
+-  xwayland: Fix :cve:`2023-6377` and :cve:`2023-6478`
+
+
+Fixes in Yocto-4.3.3
+~~~~~~~~~~~~~~~~~~~~
+
+-  aspell: upgrade to 0.60.8.1
+-  avahi: update URL for new project location
+-  base-passwd: upgrade to 3.6.3
+-  bitbake: asyncrpc: Add context manager API
+-  bitbake: toaster/toastergui: Bug-fix verify given layer path only if import/add local layer
+-  build-appliance-image: Update to nanbield head revision
+-  classes-global/sstate: Fix variable typo
+-  cmake: Unset CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
+-  contributor-guide: fix lore URL
+-  contributor-guide: use "apt" instead of "aptitude"
+-  create-spdx-2.2: combine spdx can try to write before dir creation
+-  curl: Disable test 1091 due to intermittent failures
+-  curl: Disable two intermittently failing tests
+-  dev-manual: gen-tapdevs need iptables installed
+-  dev-manual: start.rst: Update use of Download page
+-  dev-manual: update license manifest path
+-  devtool: deploy: provide max_process to strip_execs
+-  devtool: modify: Handle recipes with a menuconfig task correctly
+-  docs: document VSCode extension
+-  dtc: preserve version also from shallow git clones
+-  elfutils: Update license information
+-  glib-2.0: upgrade to 2.78.3
+-  glibc-y2038-tests: do not run tests using 32 bit time APIs
+-  go: upgrade to 1.20.12
+-  grub: fs/fat: Don't error when mtime is 0
+-  gstreamer1.0: upgrade to 1.22.8
+-  icon-naming-utils: take tarball from debian
+-  kea: upgrade to 2.4.1
+-  lib/prservice: Improve lock handling robustness
+-  libadwaita: upgrade to 1.4.2
+-  libatomic-ops: upgrade to 7.8.2
+-  libva-utils: upgrade to 2.20.1
+-  linux-firmware: Change bnx2 packaging
+-  linux-firmware: Create bnx2x subpackage
+-  linux-firmware: Fix the linux-firmware-bcm4373 :term:`FILES` variable
+-  linux-firmware: Package iwlwifi .pnvm files
+-  linux-yocto/6.1: security/cfg: add configs to harden protection
+-  linux-yocto/6.1: update to v6.1.73
+-  meta/documentation.conf: fix do_menuconfig description
+-  migration-guide: add release notes for 4.0.16
+-  migration-guide: add release notes for 4.3.2
+-  ncurses: Fix - tty is hung after reset
+-  nfs-utils: Update Upstream-Status
+-  nfs-utils: upgrade to 2.6.4
+-  oeqa/selftest/prservice: Improve test robustness
+-  package.py: OEHasPackage: Add :term:`MLPREFIX` to packagename
+-  poky.conf: bump version for 4.3.3 release
+-  pseudo: Update to pull in syncfs probe fix
+-  python3-license-expression: Fix the ptest failure
+-  qemu.bbclass: fix a python TypeError
+-  qemu: upgrade to 8.1.4
+-  ref-manual: Add UBOOT_BINARY, extend :term:`UBOOT_CONFIG`
+-  ref-manual: classes: remove insserv bbclass
+-  ref-manual: update tested and supported distros
+-  release-notes-4.3: fix spacing
+-  rootfs.py: check depmodwrapper execution result
+-  rpcbind: Specify state directory under /run
+-  scripts/runqemu: fix regex escape sequences
+-  sqlite3: upgrade to 3.43.2
+-  sstate: Fix dir ownership issues in :term:`SSTATE_DIR`
+-  sudo: upgrade to 1.9.15p5
+-  tcl: Fix prepending to run-ptest script
+-  uninative-tarball.xz - reproducibility fix
+-  xwayland: upgrade to 23.2.3
+-  zstd: fix :term:`LICENSE` statement
+
+
+Known Issues in Yocto-4.3.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.3.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alassane Yattara
+-  Alexander Kanavin
+-  Anuj Mittal
+-  Baruch Siach
+-  Bruce Ashfield
+-  Chen Qi
+-  Clay Chang
+-  Enguerrand de Ribaucourt
+-  Ilya A. Kriveshko
+-  Jason Andryuk
+-  Jeremy A. Puhlman
+-  Joao Marcos Costa
+-  Jose Quaresma
+-  Joshua Watt
+-  Jörg Sommer
+-  Khem Raj
+-  Lee Chee Yang
+-  Markus Volk
+-  Massimiliano Minella
+-  Maxin B. John
+-  Michael Opdenacker
+-  Ming Liu
+-  Mingli Yu
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Richard Purdie
+-  Robert Berger
+-  Robert Yang
+-  Rodrigo M. Duarte
+-  Ross Burton
+-  Saul Wold
+-  Simone Weiß
+-  Soumya Sambu
+-  Steve Sakoman
+-  Trevor Gamblin
+-  Wang Mingyu
+-  William Lyu
+-  Xiangyu Chen
+-  Yang Xu
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.3.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`nanbield </poky/log/?h=nanbield>`
+-  Tag:  :yocto_git:`yocto-4.3.3 </poky/log/?h=yocto-4.3.3>`
+-  Git Revision: :yocto_git:`d3b27346c3a4a7ef7ec517e9d339d22bda74349d </poky/commit/?id=d3b27346c3a4a7ef7ec517e9d339d22bda74349d>`
+-  Release Artefact: poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d
+-  sha: 2db39f1bf7bbcee039e9970eed1f6f9233bcc95d675159647c9a2a334fc81eb0
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/poky-d3b27346c3a4a7ef7ec517e9d339d22bda74349d.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.3 </openembedded-core/log/?h=yocto-4.3.3>`
+-  Git Revision: :oe_git:`0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3 </openembedded-core/commit/?id=0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3>`
+-  Release Artefact: oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3
+-  sha: 730de0d5744f139322402ff9a6b2483c6ab929f704cec06258ae51de1daebe3d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/oecore-0584d01f623e1f9b0fef4dfa95dd66de6cbfb7b3.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.3 </meta-mingw/log/?h=yocto-4.3.3>`
+-  Git Revision: :yocto_git:`49617a253e09baabbf0355bc736122e9549c8ab2 </meta-mingw/commit/?id=49617a253e09baabbf0355bc736122e9549c8ab2>`
+-  Release Artefact: meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2
+-  sha: 2225115b73589cdbf1e491115221035c6a61679a92a93b2a3cf761ff87bf4ecc
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/meta-mingw-49617a253e09baabbf0355bc736122e9549c8ab2.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.6 </bitbake/log/?h=2.6>`
+-  Tag:  :oe_git:`yocto-4.3.3 </bitbake/log/?h=yocto-4.3.3>`
+-  Git Revision: :oe_git:`380a9ac97de5774378ded5e37d40b79b96761a0c </bitbake/commit/?id=380a9ac97de5774378ded5e37d40b79b96761a0c>`
+-  Release Artefact: bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c
+-  sha: 78f579b9d29e72d09b6fb10ac62aa925104335e92d2afb3155bc9ab1994e36c1
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.3.3/bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.3.3/bitbake-380a9ac97de5774378ded5e37d40b79b96761a0c.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.3 </yocto-docs/log/?h=yocto-4.3.3>`
+-  Git Revision: :yocto_git:`dde4b815db82196af086847f68ee27d7902b4ffa </yocto-docs/commit/?id=dde4b815db82196af086847f68ee27d7902b4ffa>`
+
diff --git a/poky/documentation/overview-manual/concepts.rst b/poky/documentation/overview-manual/concepts.rst
index d335c2fcdd..d177ca33b7 100644
--- a/poky/documentation/overview-manual/concepts.rst
+++ b/poky/documentation/overview-manual/concepts.rst
@@ -37,7 +37,7 @@ to each data source as a layer. For information on layers, see the
 ":ref:`dev-manual/layers:understanding and creating layers`"
 section of the Yocto Project Development Tasks Manual.
 
-Following are some brief details on these core components. For
+Here are some brief details on these core components. For
 additional information on how these components interact during a build,
 see the
 ":ref:`overview-manual/concepts:openembedded build system concepts`"
@@ -1321,7 +1321,7 @@ can initialize the environment before using the tools.
 All the output files for an SDK are written to the ``deploy/sdk`` folder
 inside the :term:`Build Directory` as shown in the previous figure. Depending
 on the type of SDK, there are several variables to configure these files.
-Here are the variables associated with an extensible SDK:
+The variables associated with an extensible SDK are:
 
 -  :term:`DEPLOY_DIR`: Points to
    the ``deploy`` directory.
@@ -2238,7 +2238,7 @@ which is integrating ``sayhello`` in our root file system:
 #.  Add ``sayhello`` to :term:`IMAGE_INSTALL` to integrate it into
     the root file system
 
-The following are the contents of ``libhello/Makefile``::
+The contents of ``libhello/Makefile`` are::
 
    LIB=libhello.so
 
@@ -2266,7 +2266,7 @@ The following are the contents of ``libhello/Makefile``::
    and ``CFLAGS`` as BitBake will set them as environment variables according
    to your build configuration.
 
-The following are the contents of ``libhello/hellolib.h``::
+The contents of ``libhello/hellolib.h`` are::
 
    #ifndef HELLOLIB_H
    #define HELLOLIB_H
@@ -2275,7 +2275,7 @@ The following are the contents of ``libhello/hellolib.h``::
 
    #endif
 
-The following are the contents of ``libhello/hellolib.c``::
+The contents of ``libhello/hellolib.c`` are::
 
    #include <stdio.h>
 
@@ -2283,7 +2283,7 @@ The following are the contents of ``libhello/hellolib.c``::
       puts("Hello from a Yocto demo \n");
    }
 
-The following are the contents of ``sayhello/Makefile``::
+The contents of ``sayhello/Makefile`` are::
 
    EXEC=sayhello
    LDFLAGS += -lhello
@@ -2296,7 +2296,7 @@ The following are the contents of ``sayhello/Makefile``::
    clean:
       rm -rf $(EXEC) *.o
 
-The following are the contents of ``sayhello/sayhello.c``::
+The contents of ``sayhello/sayhello.c`` are::
 
    #include <hellolib.h>
 
@@ -2305,7 +2305,7 @@ The following are the contents of ``sayhello/sayhello.c``::
       return 0;
    }
 
-The following are the contents of ``libhello_0.1.bb``::
+The contents of ``libhello_0.1.bb`` are::
 
    SUMMARY = "Hello demo library"
    DESCRIPTION = "Hello shared library used in Yocto demo"
@@ -2328,7 +2328,7 @@ The following are the contents of ``libhello_0.1.bb``::
       oe_soinstall ${PN}.so.${PV} ${D}${libdir}
    }
 
-The following are the contents of ``sayhello_0.1.bb``::
+The contents of ``sayhello_0.1.bb`` are::
 
    SUMMARY = "SayHello demo"
    DESCRIPTION = "SayHello project used in Yocto demo"
diff --git a/poky/documentation/overview-manual/yp-intro.rst b/poky/documentation/overview-manual/yp-intro.rst
index 1e6820c14e..4a27e12e01 100644
--- a/poky/documentation/overview-manual/yp-intro.rst
+++ b/poky/documentation/overview-manual/yp-intro.rst
@@ -737,7 +737,7 @@ workflow:
 .. image:: figures/YP-flow-diagram.png
     :width: 100%
 
-Following is a brief summary of the "workflow":
+Here is a brief summary of the "workflow":
 
 #. Developers specify architecture, policies, patches and configuration
    details.
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 844433c551..7300020ef1 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -693,7 +693,7 @@ information about using :ref:`ref-classes-devshell`.
 The :ref:`ref-classes-devupstream` class uses
 :term:`BBCLASSEXTEND` to add a variant of the
 recipe that fetches from an alternative URI (e.g. Git) instead of a
-tarball. Following is an example::
+tarball. Here is an example::
 
    BBCLASSEXTEND = "devupstream:target"
    SRC_URI:class-devupstream = "git://git.example.com/example;branch=main"
@@ -1246,8 +1246,8 @@ Please keep in mind that the QA checks
 are meant to detect real or potential problems in the packaged
 output. So exercise caution when disabling these checks.
 
-Here are the tests you can list with the :term:`WARN_QA` and
-:term:`ERROR_QA` variables:
+The tests you can list with the :term:`WARN_QA` and
+:term:`ERROR_QA` variables are:
 
 -  ``already-stripped:`` Checks that produced binaries have not
    already been stripped prior to the build system extracting debug
@@ -3246,7 +3246,7 @@ information.
 The :ref:`ref-classes-uboot-sign` class provides support for U-Boot verified boot.
 It is intended to be inherited from U-Boot recipes.
 
-Here are variables used by this class:
+The variables used by this class are:
 
 -  :term:`SPL_MKIMAGE_DTCOPTS`: DTC options for U-Boot ``mkimage`` when
    building the FIT image.
diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst
index e167f58092..9319addc3c 100644
--- a/poky/documentation/ref-manual/devtool-reference.rst
+++ b/poky/documentation/ref-manual/devtool-reference.rst
@@ -378,7 +378,7 @@ command::
 Unless you provide a specific recipe name on the command line, the
 command checks all recipes in all configured layers.
 
-Following is a partial example table that reports on all the recipes::
+Here is a partial example table that reports on all the recipes::
 
    $ devtool check-upgrade-status
    ...
@@ -598,7 +598,7 @@ The ``devtool status`` command has no command-line options::
 
    $ devtool status
 
-Following is sample output after using
+Here is sample output after using
 :ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>`
 to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory::
 
diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index a3a15506c3..bab284bbfd 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -90,7 +90,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You
 can use ``file://`` URLs to point to local directories or network shares
 as well.
 
-Here are other options::
+Another option is to set::
 
    BB_NO_NETWORK = "1"
 
@@ -106,7 +106,7 @@ This statement limits the build system to pulling source from the
 :term:`PREMIRRORS` only.  Again, this technique is useful for reproducing
 builds.
 
-Here is another technique::
+Here is yet another technique::
 
    BB_GENERATE_MIRROR_TARBALLS = "1"
 
@@ -135,7 +135,7 @@ Most source fetching by the OpenEmbedded build system is done by
 single user or can be in ``/usr/local/etc/wgetrc`` as a global user
 file.
 
-Following is the applicable code for setting various proxy types in the
+Here is the applicable code for setting various proxy types in the
 ``.wgetrc`` file. By default, these settings are disabled with comments.
 To use them, remove the comments::
 
diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst
index b9d3b30f18..2ea946b31d 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -271,7 +271,7 @@ you can add several different predefined packages such as development
 utilities or packages with debug information needed to investigate
 application problems or profile applications.
 
-Here are the image features available for all images:
+The image features available for all images are:
 
 -  *allow-empty-password:* Allows Dropbear and OpenSSH to accept
    logins from accounts having an empty password string.
diff --git a/poky/documentation/ref-manual/images.rst b/poky/documentation/ref-manual/images.rst
index 0f6d6bdb3f..c45f9104a9 100644
--- a/poky/documentation/ref-manual/images.rst
+++ b/poky/documentation/ref-manual/images.rst
@@ -32,7 +32,7 @@ that contain image recipe files::
 
    $ ls meta*/recipes*/images/*.bb
 
-Following is a list of supported recipes:
+Here is a list of supported recipes:
 
 -  ``build-appliance-image``: An example virtual machine that contains
    all the pieces required to run builds using the build system as well
diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst
index c861feaa9d..920794679d 100644
--- a/poky/documentation/ref-manual/release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -14,7 +14,7 @@ Major and Minor Release Cadence
 
 The Yocto Project delivers major releases (e.g. &DISTRO;) using a six
 month cadence roughly timed each April and October of the year.
-Following are examples of some major YP releases with their codenames
+Here are examples of some major YP releases with their codenames
 also shown. See the ":ref:`ref-manual/release-process:major release codenames`"
 section for information on codenames used with major releases.
 
@@ -29,8 +29,8 @@ major holidays in various geographies.
 
 The Yocto project delivers minor (point) releases on an unscheduled
 basis and are usually driven by the accumulation of enough significant
-fixes or enhancements to the associated major release. Following are
-some example past point releases:
+fixes or enhancements to the associated major release.
+Some example past point releases are:
 
   - 4.1.3
   - 4.0.8
@@ -175,7 +175,7 @@ consists of the following pieces:
    piece of software. The test allows the packages to be run within a
    target image.
 
--  ``oe-selftest``: Tests combination BitBake invocations. These tests
+-  ``oe-selftest``: Tests combinations of BitBake invocations. These tests
    operate outside the OpenEmbedded build system itself. The
    ``oe-selftest`` can run all tests by default or can run selected
    tests or test suites.
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index f1b11ad69b..acadd5efa3 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -537,7 +537,7 @@ recipe-specific :term:`WORKDIR` directories. Thus, the
 This directory holds information that BitBake uses for accounting
 purposes to track what tasks have run and when they have run. The
 directory is sub-divided by architecture, package name, and version.
-Following is an example::
+Here is an example::
 
       stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
 
diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
index 9e2dd532f9..0fc92550a5 100644
--- a/poky/documentation/ref-manual/system-requirements.rst
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -164,8 +164,8 @@ with a supported Ubuntu or Debian Linux distribution::
 
 Here are the packages needed to build Project documentation manuals::
 
-   $ sudo apt install make python3-pip inkscape texlive-latex-extra
-   &PIP3_HOST_PACKAGES_DOC;
+   $ sudo apt install git make inkscape texlive-latex-extra
+   $ sudo apt install sphinx python3-saneyaml python3-sphinx-rtd-theme
 
 Fedora Packages
 ---------------
@@ -177,7 +177,7 @@ with a supported Fedora Linux distribution::
 
 Here are the packages needed to build Project documentation manuals::
 
-   $ sudo dnf install make python3-pip which inkscape texlive-fncychap
+   $ sudo dnf install git make python3-pip which inkscape texlive-fncychap
    &PIP3_HOST_PACKAGES_DOC;
 
 openSUSE Packages
@@ -190,7 +190,7 @@ with a supported openSUSE distribution::
 
 Here are the packages needed to build Project documentation manuals::
 
-   $ sudo zypper install make python3-pip which inkscape texlive-fncychap
+   $ sudo zypper install git make python3-pip which inkscape texlive-fncychap
    &PIP3_HOST_PACKAGES_DOC;
 
 
@@ -217,7 +217,7 @@ with a supported AlmaLinux distribution::
 
 Here are the packages needed to build Project documentation manuals::
 
-   $ sudo dnf install make python3-pip which inkscape texlive-fncychap
+   $ sudo dnf install git make python3-pip which inkscape texlive-fncychap
    &PIP3_HOST_PACKAGES_DOC;
 
 .. _system-requirements-buildtools:
diff --git a/poky/documentation/ref-manual/terms.rst b/poky/documentation/ref-manual/terms.rst
index 31ddeae009..ad9c46c339 100644
--- a/poky/documentation/ref-manual/terms.rst
+++ b/poky/documentation/ref-manual/terms.rst
@@ -4,7 +4,7 @@
 Yocto Project Terms
 *******************
 
-Following is a list of terms and definitions users new to the Yocto Project
+Here is a list of terms and definitions users new to the Yocto Project
 development environment might find helpful. While some of these terms are
 universal, the list includes them just in case:
 
@@ -67,7 +67,7 @@ universal, the list includes them just in case:
       :term:`TOPDIR` variable points to the :term:`Build Directory`.
 
       You have a lot of flexibility when creating the :term:`Build Directory`.
-      Following are some examples that show how to create the directory.  The
+      Here are some examples that show how to create the directory.  The
       examples assume your :term:`Source Directory` is named ``poky``:
 
          -  Create the :term:`Build Directory` inside your Source Directory and let
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 6f7d6ff01e..a0187a6d47 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -311,7 +311,7 @@ system and gives an overview of their function and contents.
 
    :term:`BB_ALLOWED_NETWORKS`
       Specifies a space-delimited list of hosts that the fetcher is allowed
-      to use to obtain the required source code. Following are
+      to use to obtain the required source code. Here are
       considerations surrounding this variable:
 
       -  This host list is only used if :term:`BB_NO_NETWORK` is either not set
@@ -6557,7 +6557,7 @@ system and gives an overview of their function and contents.
       The :term:`PREFERRED_PROVIDER` variable is set with the name (:term:`PN`) of
       the recipe you prefer to provide "virtual/kernel".
 
-      Following are more examples::
+      Here are more examples::
 
          PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
          PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
@@ -6813,20 +6813,6 @@ system and gives an overview of their function and contents.
       names used when installing the Python headers and libraries in
       sysroot (e.g. ``.../python3.3m/...``).
 
-   :term:`PYTHON_PN`
-      When used by recipes that inherit the :ref:`ref-classes-setuptools3`
-      class, specifies the major Python version being built. For Python 3.x,
-      :term:`PYTHON_PN` would be "python3". You do not have to set this
-      variable as the OpenEmbedded build system automatically sets it for you.
-
-      The variable allows recipes to use common infrastructure such as the
-      following::
-
-         DEPENDS += "${PYTHON_PN}-native"
-
-      In the previous example,
-      the version of the dependency is :term:`PYTHON_PN`.
-
    :term:`QA_EMPTY_DIRS`
       Specifies a list of directories that are expected to be empty when
       packaging; if ``empty-dirs`` appears in :term:`ERROR_QA` or
@@ -9391,7 +9377,7 @@ system and gives an overview of their function and contents.
       configuration can define the :term:`UBOOT_MACHINE` and optionally the
       :term:`IMAGE_FSTYPES` and the :term:`UBOOT_BINARY`.
 
-      Following is an example from the ``meta-freescale`` layer. ::
+      Here is an example from the ``meta-freescale`` layer. ::
 
          UBOOT_CONFIG ??= "sdcard-ifc-secure-boot sdcard-ifc sdcard-qspi lpuart qspi secure-boot nor"
          UBOOT_CONFIG[nor] = "ls1021atwr_nor_defconfig"
@@ -9929,7 +9915,7 @@ system and gives an overview of their function and contents.
       With the :term:`WKS_FILE_DEPENDS` variable, you have the possibility to
       specify a list of additional dependencies (e.g. native tools,
       bootloaders, and so forth), that are required to build Wic images.
-      Following is an example::
+      Here is an example::
 
          WKS_FILE_DEPENDS = "some-native-tool"
 
diff --git a/poky/documentation/sdk-manual/appendix-obtain.rst b/poky/documentation/sdk-manual/appendix-obtain.rst
index ad531cbf24..d06d6ec6b5 100644
--- a/poky/documentation/sdk-manual/appendix-obtain.rst
+++ b/poky/documentation/sdk-manual/appendix-obtain.rst
@@ -66,7 +66,7 @@ Follow these steps to locate and hand-install the toolchain:
       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``
+   the installer. Here is an example from the ``Downloads``
    directory::
 
       $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
@@ -165,12 +165,12 @@ build the SDK installer. Follow these steps:
          variable inside your ``local.conf`` file before building the
          SDK installer. Doing so ensures that the eventual SDK
          installation process installs the appropriate library packages
-         as part of the SDK. Following is an example using ``libc``
+         as part of the SDK. Here is an example using ``libc``
          static development libraries: TOOLCHAIN_TARGET_TASK:append = "
          libc-staticdev"
 
 #. *Run the Installer:* You can now run the SDK installer from
-   ``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example::
+   ``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example::
 
       $ cd poky/build/tmp/deploy/sdk
       $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
@@ -235,7 +235,7 @@ Follow these steps to extract the root filesystem:
    This script is located in the top-level directory in which you
    installed the toolchain (e.g. ``poky_sdk``).
 
-   Following is an example based on the toolchain installed in the
+   Here is an example based on the toolchain installed in the
    ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section::
 
       $ source poky_sdk/environment-setup-core2-64-poky-linux
@@ -243,7 +243,7 @@ Follow these steps to extract the root filesystem:
 #. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
    command and provide the root filesystem image.
 
-   Following is an example command that extracts the root filesystem
+   Here is an example command that extracts the root filesystem
    from a previously built root filesystem image that was downloaded
    from the :yocto_dl:`Index of Releases </releases/yocto/yocto-&DISTRO;/machines/>`.
    This command extracts the root filesystem into the ``core2-64-sato``
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 355c6cb0e4..05dd527469 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -63,6 +63,8 @@ their own pros and cons:
    need to provide a well-functioning binary artefact cache over the network
    for developers with underpowered laptops.
 
+.. _setting_up_ext_sdk_in_build:
+
 Setting up the Extensible SDK environment directly in a Yocto build
 -------------------------------------------------------------------
 
@@ -168,6 +170,8 @@ architecture. The example assumes the SDK installer is located in
    that case, set up the proper permissions in the directory and run the
    installer again.
 
+.. _running_the_ext_sdk_env:
+
 Running the Extensible SDK Environment Setup Script
 ===================================================
 
@@ -205,6 +209,8 @@ use the SDK (e.g. ``PATH``, :term:`CC`, :term:`LD`, and so forth). If you want
 to see all the environment variables the script exports, examine the
 installation file itself.
 
+.. _using_devtool:
+
 Using ``devtool`` in Your SDK Workflow
 ======================================
 
@@ -230,13 +236,15 @@ all the commands.
    See the ":doc:`/ref-manual/devtool-reference`"
    section in the Yocto Project Reference Manual.
 
-Three ``devtool`` subcommands provide entry-points into development:
+``devtool`` subcommands provide entry-points into development:
 
 -  *devtool add*: Assists in adding new software to be built.
 
 -  *devtool modify*: Sets up an environment to enable you to modify
    the source of an existing component.
 
+-  *devtool ide-sdk*: Generates a configuration for an IDE.
+
 -  *devtool upgrade*: Updates an existing recipe so that you can
    build it for an updated set of source files.
 
@@ -614,6 +622,279 @@ command:
       decide you do not want to proceed with your work. If you do use this
       command, realize that the source tree is preserved.
 
+``devtool ide-sdk`` configures IDEs for the extensible SDK
+----------------------------------------------------------
+
+``devtool ide-sdk`` automatically configures IDEs to use the extensible SDK.
+To make sure that all parts of the extensible SDK required by the generated
+IDE configuration are available, ``devtool ide-sdk`` uses BitBake in the
+background to bootstrap the extensible SDK.
+
+The extensible SDK supports two different development modes.
+``devtool ide-sdk`` supports both of them:
+
+#. *Modified mode*:
+
+   By default ``devtool ide-sdk`` generates IDE configurations for recipes in
+   workspaces created by ``devtool modify`` or ``devtool add`` as described in
+   :ref:`using_devtool`.  This mode creates IDE configurations with support for
+   advanced features, such as deploying the binaries to the remote target
+   device and performing remote debugging sessions. The generated IDE
+   configurations use the per recipe sysroots as Bitbake does internally.
+
+   In order to use the tool, a few settings are needed. As a starting example,
+   the following lines of code can be added to the ``local.conf`` file::
+
+      # Build the companion debug file system
+      IMAGE_GEN_DEBUGFS = "1"
+      # Optimize build time: with devtool ide-sdk the dbg tar is not needed
+      IMAGE_FSTYPES_DEBUGFS = ""
+      # Without copying the binaries into roofs-dbg, GDB does not find all source files.
+      IMAGE_CLASSES += "image-combined-dbg"
+
+      # SSH is mandatory, no password simplifies the usage
+      EXTRA_IMAGE_FEATURES += "\
+         ssh-server-openssh \
+         debug-tweaks \
+      "
+
+      # Remote debugging needs gdbserver on the target device
+      IMAGE_INSTALL:append = " gdbserver"
+
+      # Add the recipes which should be modified to the image
+      # Otherwise some dependencies might be missing.
+      IMAGE_INSTALL:append = " my-recipe"
+
+   Assuming the BitBake environment is set up correctly and a workspace has
+   been created for the recipe using ``devtool modify my-recipe``, the
+   following command can create the SDK and the configuration for VSCode in
+   the recipe workspace::
+
+      $ devtool ide-sdk my-recipe core-image-minimal --target root@192.168.7.2
+
+   The command requires an image recipe (``core-image-minimal`` for this example)
+   that is used to create the SDK. This firmware image should also be installed
+   on the target device.  It is possible to pass multiple package recipes.
+   ``devtool ide-sdk`` tries to create an IDE configuration for all package
+   recipes.
+
+   What this command does exactly depends on the recipe, more precisely on the
+   build tool used by the recipe. The basic idea is to configure the IDE so
+   that it calls the build tool exactly as ``bitbake`` does.
+
+   For example, a CMake preset is created for a recipe that inherits
+   :ref:`ref-classes-cmake`. In the case of VSCode, CMake presets are supported
+   by the CMake Tools plugin.  This is an example of how the build
+   configuration used by ``bitbake`` is exported to an IDE configuration that
+   gives exactly the same build results.
+
+   Support for remote debugging with seamless integration into the IDE is
+   important for a cross-SDK. ``devtool ide-sdk`` automatically generates the
+   necessary helper scripts for deploying the compiled artifacts to the target
+   device as well as the necessary configuration for the debugger and the IDE.
+
+   .. note::
+
+      To ensure that the debug symbols on the build machine match the binaries
+      running on the target device, it is essential that the image built by
+      ``devtool ide-sdk`` is running on the target device.
+
+   ``devtool ide-sdk`` aims to support multiple programming languages and
+   multiple IDEs natively. "Natively" means that the IDE is configured to call
+   the build tool (e.g. CMake or Meson) directly. This has several advantages.
+   First of all, it is much faster than ``devtool build``, but it also allows
+   to use the very good integration of tools like CMake or GDB in VSCode and
+   other IDEs. However, supporting many programming languages and multiple
+   IDEs is quite an elaborate and constantly evolving thing. Support for IDEs
+   is therefore implemented as plugins. Plugins can also be provided by
+   optional layers.
+
+   The default IDE is VSCode. Some hints about using VSCode:
+
+   -  To work on the source code of a recipe an instance of VSCode is started in
+      the recipe's workspace. Example::
+
+         code build/workspace/sources/my-recipe
+
+   -  To work with CMake press ``Ctrl + Shift + p``, type ``cmake``. This will
+      show some possible commands like selecting a CMake preset, compiling or
+      running CTest.
+
+      For recipes inheriting :ref:`ref-classes-cmake-qemu` rather than
+      :ref:`ref-classes-cmake`, executing cross-compiled unit tests on the host
+      can be supported transparently with QEMU user-mode.
+
+   -  To work with Meson press ``Ctrl + Shift + p``, type ``meson``. This will
+      show some possible commands like compiling or executing the unit tests.
+
+      A note on running cross-compiled unit tests on the host: Meson enables
+      support for QEMU user-mode by default. It is expected that the execution
+      of the unit tests from the IDE will work easily without any additional
+      steps, provided that the code is suitable for execution on the host
+      machine.
+
+   -  For the deployment to the target device, just press ``Ctrl + Shift + p``,
+      type ``task``.  Select ``install && deploy-target``.
+
+   -  For remote debugging, switch to the debugging view by pressing the "play"
+      button with the ``bug icon`` on the left side. This will provide a green
+      play button with a drop-down list where a debug configuration can be
+      selected.  After selecting one of the generated configurations, press the
+      "play" button.
+
+      Starting a remote debugging session automatically initiates the deployment
+      to the target device. If this is not desired, the
+      ``"dependsOn": ["install && deploy-target...]`` parameter of the tasks
+      with ``"label": "gdbserver start...`` can be removed from the
+      ``tasks.json`` file.
+
+      VSCode supports GDB with many different setups and configurations for many
+      different use cases.  However, most of these setups have some limitations
+      when it comes to cross-development, support only a few target
+      architectures or require a high performance target device. Therefore
+      ``devtool ide-sdk`` supports the classic, generic setup with GDB on the
+      development host and gdbserver on the target device.
+
+      Roughly summarized, this means:
+
+      -  The binaries are copied via SSH to the remote target device by a script
+         referred by ``tasks.json``.
+
+      -  gdbserver is started on the remote target device via SSH by a script
+         referred by ``tasks.json``.
+
+         Changing the parameters that are passed to the debugging executable
+         requires modifying the generated script. The script is located at
+         ``oe-scripts/gdbserver_*``. Defining the parameters in the ``args``
+         field in the ``launch.json`` file does not work.
+
+      -  VSCode connects to gdbserver as documented in
+         `Remote debugging or debugging with a local debugger server
+         <https://code.visualstudio.com/docs/cpp/launch-json-reference#_remote-debugging-or-debugging-with-a-local-debugger-server>`__.
+
+   Additionally ``--ide=none`` is supported. With the ``none`` IDE parameter,
+   some generic configuration files like ``gdbinit`` files and some helper
+   scripts starting gdbserver remotely on the target device as well as the GDB
+   client on the host are generated.
+
+   Here is a usage example for the ``cmake-example`` recipe from the
+   ``meta-selftest`` layer which inherits :ref:`ref-classes-cmake-qemu`:
+
+   .. code-block:: sh
+
+      # Create the SDK
+      devtool modify cmake-example
+      devtool ide-sdk cmake-example core-image-minimal -c --debug-build-config --ide=none
+
+      # Install the firmware on a target device or start QEMU
+      runqemu
+
+      # From exploring the workspace of cmake-example
+      cd build/workspace/sources/cmake-example
+
+      # Find cmake-native and save the path into a variable
+      # Note: using just cmake instead of $CMAKE_NATIVE would work in many cases
+      CMAKE_NATIVE="$(jq -r '.configurePresets[0] | "\(.cmakeExecutable)"' CMakeUserPresets.json)"
+
+      # List available CMake presets
+      "$CMAKE_NATIVE" --list-presets
+      Available configure presets:
+
+        "cmake-example-cortexa57" - cmake-example: cortexa57
+
+      # Re-compile the already compiled sources
+      "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57
+      ninja: no work to do.
+      # Do a clean re-build
+      "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target clean
+      [1/1] Cleaning all built files...
+      Cleaning... 8 files.
+      "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target all
+      [7/7] Linking CXX executable cmake-example
+
+      # Run the cross-compiled unit tests with QEMU user-mode
+      "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target test
+      [0/1] Running tests...
+      Test project .../build/tmp/work/cortexa57-poky-linux/cmake-example/1.0/cmake-example-1.0
+          Start 1: test-cmake-example
+      1/1 Test #1: test-cmake-example ...............   Passed    0.03 sec
+
+      100% tests passed, 0 tests failed out of 1
+
+      Total Test time (real) =   0.03 sec
+
+      # Using CTest directly is possible as well
+      CTEST_NATIVE="$(dirname "$CMAKE_NATIVE")/ctest"
+
+      # List available CMake presets
+      "$CTEST_NATIVE" --list-presets
+      Available test presets:
+
+        "cmake-example-cortexa57" - cmake-example: cortexa57
+
+      # Run the cross-compiled unit tests with QEMU user-mode
+      "$CTEST_NATIVE" --preset "cmake-example-cortexa57"
+      Test project ...build/tmp/work/cortexa57-poky-linux/cmake-example/1.0/cmake-example-1.0
+          Start 1: test-cmake-example
+      1/1 Test #1: test-cmake-example ...............   Passed    0.03 sec
+
+      100% tests passed, 0 tests failed out of 1
+
+      Total Test time (real) =   0.03 sec
+
+      # Deploying the new build to the target device (default is QEUM at 192.168.7.2)
+      oe-scripts/install_and_deploy_cmake-example-cortexa57
+
+      # Start a remote debugging session with gdbserver on the target and GDB on the host
+      oe-scripts/gdbserver_1234_usr-bin-cmake-example_m
+      oe-scripts/gdb_1234_usr-bin-cmake-example
+      break main
+      run
+      step
+      stepi
+      continue
+      quit
+
+      # Stop gdbserver on the target device
+      oe-scripts/gdbserver_1234_usr-bin-cmake-example_m stop
+
+#. *Shared sysroots mode*
+
+   For some recipes and use cases a per-recipe sysroot based SDK is not
+   suitable.  Optionally ``devtool ide-sdk`` configures the IDE to use the
+   toolchain provided by the extensible SDK as described in
+   :ref:`running_the_ext_sdk_env`. ``devtool ide-sdk --mode=shared`` is
+   basically a wrapper for the setup of the extensible SDK as described in
+   :ref:`setting_up_ext_sdk_in_build`. The IDE gets a configuration to use the
+   shared sysroots.
+
+   Creating a SDK with shared sysroots that contains all the dependencies needed
+   to work with ``my-recipe`` is possible with the following example command::
+
+      $ devtool ide-sdk --mode=shared my-recipe
+
+   For VSCode the cross-toolchain is exposed as a CMake kit. CMake kits are
+   defined in ``~/.local/share/CMakeTools/cmake-tools-kits.json``.
+   The following example shows how the cross-toolchain can be selected in
+   VSCode. First of all we need a folder containing a CMake project.
+   For this example, let's create a CMake project and start VSCode::
+
+      mkdir kit-test
+      echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt
+      code kit-test
+
+   If there is a CMake project in the workspace, cross-compilation is supported:
+
+   - Press ``Ctrl + Shift + P``, type ``CMake: Scan for Kits``
+   - Press ``Ctrl + Shift + P``, type ``CMake: Select a Kit``
+
+   Finally most of the features provided by CMake and the IDE should be available.
+
+   Other IDEs than VSCode are supported as well. However,
+   ``devtool ide-sdk --mode=shared --ide=none my-recipe`` is currently
+   just a simple wrapper for the setup of the extensible SDK, as described in
+   :ref:`setting_up_ext_sdk_in_build`.
+
 Use ``devtool upgrade`` to Create a Version of the Recipe that Supports a Newer Version of the Software
 -------------------------------------------------------------------------------------------------------
 
diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
index 49aa921e70..e8fd191dbc 100644
--- a/poky/documentation/sdk-manual/intro.rst
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -66,7 +66,7 @@ The SDK development environment consists of the following:
 
 In summary, the extensible and standard SDK share many features.
 However, the extensible SDK has powerful development tools to help you
-more quickly develop applications. Following is a table that summarizes
+more quickly develop applications. Here is a table that summarizes
 the primary differences between the standard and extensible SDK types
 when considering which to build:
 
diff --git a/poky/documentation/toaster-manual/setup-and-use.rst b/poky/documentation/toaster-manual/setup-and-use.rst
index c5521edda1..a0c27499ba 100644
--- a/poky/documentation/toaster-manual/setup-and-use.rst
+++ b/poky/documentation/toaster-manual/setup-and-use.rst
@@ -365,7 +365,7 @@ Perform the following steps to install Toaster:
 
       /etc/apache2/conf.d/toaster.conf
 
-    Following is a sample Apache configuration for Toaster you can follow:
+    Here is a sample Apache configuration for Toaster you can follow:
 
     .. code-block:: apache
 
@@ -495,7 +495,7 @@ The Toaster web interface allows you to do the following:
 Toaster Web Interface Videos
 ----------------------------
 
-Following are several videos that show how to use the Toaster GUI:
+Here are several videos that show how to use the Toaster GUI:
 
 -  *Build Configuration:* This
    `video <https://www.youtube.com/watch?v=qYgDZ8YzV6w>`__ overviews and
author	Patrick Williams <patrick@stwcx.xyz>	2024-03-01 17:54:02 +0300
committer	Patrick Williams <patrick@stwcx.xyz>	2024-03-01 19:12:33 +0300
commit	396535664c5645a0b32bd0e06dbab3f1e2849b64 (patch)
tree	dcf5c28dc344e5906f266d9644e0cfab226134a0 /poky/documentation
parent	73bd93f1d0a338767f36fd1acb54c52ad057db39 (diff)
download	openbmc-396535664c5645a0b32bd0e06dbab3f1e2849b64.tar.xz