subtree updates oct 3 2023mickledore

poky: fc25449687..a61e021c65:
  Alberto Planas (1):
        bitbake.conf: add unzstd in HOSTTOOLS

  Alejandro Hernandez Samaniego (2):
        baremetal-helloworld: Update SRCREV to fix entry addresses for ARM architectures
        baremetal-helloworld: Fix race condition

  Alex Kiernan (2):
        rootfs: Add debugfs package db file copy and cleanup
        rpm: Pick debugfs package db files/dirs explicitly

  Alexander Kanavin (35):
        maintaines.inc: unassign Richard Weinberger from erofs-utils entry
        maintainers.inc: unassign Andreas Müller from itstool entry
        maintainers.inc: unassign Pascal Bach from cmake entry
        maintainers.inc: correct unassigned entries
        maintainers.inc: correct Carlos Rafael Giani's email address
        apr: upgrade 1.7.3 -> 1.7.4
        scripts/runqemu: split lock dir creation into a reusable function
        scripts/runqemu: allocate unfsd ports in a way that doesn't race or clash with unrelated processes
        qemu: a pending patch was submitted and accepted upstream
        maintainers.inc: unassign Adrian Bunk from wireless-regdb
        maintainers.inc: unassign Alistair Francis from opensbi
        maintainers.inc: unassign Chase Qi from libc-test
        maintainers.inc: unassign Oleksandr Kravchuk from python3 and all other items
        maintainers.inc: unassign Ricardo Neri from ovmf
        grub: submit determinism.patch upstream
        gawk: upgrade 5.2.1 -> 5.2.2
        gnupg: upgrade 2.4.0 -> 2.4.2
        libx11: upgrade 1.8.4 -> 1.8.5
        linux-firmware: upgrade 20230404 -> 20230515
        serf: upgrade 1.3.9 -> 1.3.10
        wget: upgrade 1.21.3 -> 1.21.4
        wireless-regdb: upgrade 2023.02.13 -> 2023.05.03
        gdb: upgrade 13.1 -> 13.2
        sysfsutils: fetch a supported fork from github
        diffutils: update 3.9 -> 3.10
        libproxy: fetch from git
        cargo.bbclass: set up cargo environment in common do_compile
        rust-common.bbclass: move musl-specific linking fix from rust-source.inc
        Revert "rootfs-postcommands.bbclass: add post func remove_unused_dnf_log_lock"
        ref-manual: document image-specific variant of INCOMPATIBLE_LICENSE
        glibc-locale: use stricter matching for metapackages' runtime dependencies
        devtool/upgrade: raise an error if extracting source produces more than one directory
        curl: ensure all ptest failures are caught
        python3: upgrade 3.11.2 -> 3.11.3
        python3: update 3.11.3 -> 3.11.4

  Alexis Lothoré (2):
        scripts/resulttool: add mention about new detected tests
        oeqa/utils/gitarchive: fix tag computation when creating archive

  Andrej Valek (2):
        busybox: 1.36.0 -> 1.36.1
        maintainers.inc: Modify email address

  Anuj Mittal (7):
        gstreamer1.0: upgrade 1.22.2 -> 1.22.3
        selftest/cases/glibc.py: fix the override syntax
        glibc/check-test-wrapper: don't emit warnings from ssh
        selftest/cases/glibc.py: increase the memory for testing
        oeqa/utils/nfs: allow requesting non-udp ports
        selftest/cases/glibc.py: switch to using NFS over TCP
        gstreamer1.0: upgrade 1.22.4 -> 1.22.5

  Archana Polampalli (3):
        qemu: fix CVE-2023-0330
        bind: upgrade 9.18.15 -> 9.18.16
        vim: upgrade 9.0.1592 -> 9.0.1664

  BELOUARGA Mohamed (2):
        meta: lib: oe: npm_registry: Add more safe caracters
        linux-firmware : Add firmware of RTL8822 serie

  Benjamin Bouvier (1):
        util-linux: add alternative links for ipcs,ipcrm

  Bruce Ashfield (33):
        linux-yocto/6.1: update to v6.1.26
        linux-yocto/6.1: update to v6.1.27
        linux-yocto/6.1: update to v6.1.28
        linux-yocto/6.1: update to v6.1.29
        linux-yocto/6.1: update to v6.1.30
        linux-yocto/6.1: update to v6.1.31
        linux-yocto/6.1: update to v6.1.32
        linux-yocto/5.15: update to v5.15.114
        linux-yocto/5.15: update to v5.15.115
        linux-yocto/5.15: update to v5.15.116
        linux-yocto/5.15: update to v5.15.117
        linux-yocto/5.15: update to v5.15.118
        linux-yocto/5.15: cfg: fix DECNET configuration warning
        linux-yocto/6.1: update to v6.1.33
        linux-yocto/6.1: fix intermittent x86 boot hangs
        linux-yocto/6.1: update to v6.1.34
        linux-yocto/6.1: update to v6.1.35
        linux-yocto/5.15: update to v5.15.119
        linux-yocto/5.15: update to v5.15.120
        linux-yocto/6.1: update to v6.1.36
        linux-yocto/6.1: update to v6.1.37
        linux-yocto/6.1: update to v6.1.38
        linux-yocto/5.15: update to v5.15.122
        linux-yocto/5.15: update to v5.15.123
        linux-yocto/5.15: update to v5.15.124
        linux-yocto/6.1: cfg: update ima.cfg to match current meta-integrity
        linux-yocto/6.1: update to v6.1.41
        linux-yocto/6.1: update to v6.1.43
        linux-yocto/6.1: update to v6.1.44
        linux-yocto/6.1: update to v6.1.45
        linux-yocto/6.1: fix uninitialized read in nohz_full/isolcpus setup
        linux-yocto/6.1: update to v6.1.46
        linux-yocto/6.1: fix IRQ-80 warnings

  Changqing Li (4):
        systemd: fix a dead link under /var/log
        dnf: only write the log lock to root for native dnf
        rootfs-postcommands.bbclass: add post func remove_unused_dnf_log_lock
        erofs-utils: fix CVE-2023-33551/CVE-2023-33552

  Charlie Wu (1):
        devtool: Fix the wrong variable in srcuri_entry

  Chee Yang Lee (6):
        python3-requests: fix CVE-2023-32681
        curl: fix CVE-2023-32001
        ghostscript: fix CVE-2023-38559
        librsvg: upgrade to 2.54.6
        libssh2: fix CVE-2020-22218
        python3: update to 3.11.5

  Chen Qi (13):
        cmake.bbclass: do not search host paths for find_program()
        qemurunner.py: fix error message about qmp
        sdk.py: error out when moving file fails
        sdk.py: fix moving dnf contents
        rpm: write macros under libdir
        zip: fix configure check by using _Static_assert
        zip: remove unnecessary LARGE_FILE_SUPPORT CLFAGS
        unzip: fix configure check for cross compilation
        unzip: remove hardcoded LARGE_FILE_SUPPORT
        ncurses: fix CVE-2023-29491
        cmake.bbclass: fix allarch override syntax
        multilib.conf: explicitly make MULTILIB_VARIANTS vardeps on MULTILIBS
        gcc-crosssdk: ignore MULTILIB_VARIANTS in signature computation

  Daniel Semkowicz (1):
        dev-manual: wic.rst: Update native tools build command

  Deepthi Hemraj (2):
        glibc: stable 2.37 branch updates.
        binutils: stable 2.40 branch updates

  Denys Dmytriyenko (1):
        binutils: move packaging of gprofng static lib into common .inc

  Dmitry Baryshkov (3):
        openssl: fix building on riscv32
        linux-firmware: package firmare for Dragonboard 410c
        linux-firmware: split platform-specific Adreno shaders to separate packages

  Ed Beroset (1):
        ref-manual: add clarification for SRCREV

  Enrico Scholz (1):
        shadow-sysroot: add license information

  Etienne Cordonnier (2):
        libxcrypt: fix hard-coded ".so" extension
        vim: update obsolete comment

  Fabien Mahot (2):
        useradd-example: package typo correction
        oeqa/selftest/bbtests: add non-existent prefile/postfile tests

  Frieder Paape (1):
        image_types: Fix reproducible builds for initramfs and UKI img

  Frieder Schrempf (1):
        psmisc: Set ALTERNATIVE for pstree to resolve conflict with busybox

  Hannu Lounento (1):
        profile-manual: fix blktrace remote usage instructions

  Ian Ray (1):
        systemd-systemctl: support instance expansion in WantedBy

  Jaeyoon Jung (1):
        cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig

  Jermain Horsman (1):
        logrotate: Do not create logrotate.status file

  Joe Slater (1):
        ghostscript: fix CVE-2023-36664

  Joel Stanley (1):
        kernel: don't fail if Modules.symvers doesn't exist

  Jose Quaresma (8):
        kernel: config modules directories are handled by kernel-module-split
        kernel-module-split: install config modules directories only when they are needed
        kernel-module-split: use context manager to open files
        kernel-module-split: make autoload and probeconf distribution specific
        kernel-module-split add systemd modulesloaddir and modprobedir config
        openssl: add PERLEXTERNAL path to test its existence
        openssl: use a glob on the PERLEXTERNAL to track updates on the path
        go: update 1.20.5 -> 1.20.6

  Julien Stephan (1):
        automake: fix buildtest patch

  Jörg Sommer (2):
        runqemu-gen-tapdevs: Refactoring
        runqemu-ifupdown/get-tapdevs: Add support for ip tuntap

  Kai Kang (4):
        pm-utils: fix multilib conflictions
        webkitgtk: 2.38.5 -> 2.38.6
        webkitgtk: fix CVE-2023-32439
        webkitgtk: fix CVE-2023-32435

  Khem Raj (10):
        systemd: Drop a backport
        perf: Make built-in libtraceevent plugins cohabit with external libtraceevent
        glibc: Pass linker choice via compiler flags
        babeltrace2: Always use BFD linker when building tests with ld-is-lld distro feature
        parted: Add missing libuuid to linker cmdline for libparted-fs-resize.so
        rpcsvc-proto: Upgrade to 1.4.4
        libxml2: Do not use lld linker when building with tests on rv64
        python3-bcrypt: Use BFD linker when building tests
        meson.bbclass: Point to llvm-config from native sysroot
        build-sysroots: Add SUMMARY field

  Lee Chee Yang (7):
        migration-guides: add release notes for 4.0.10
        migration-guides: add release notes for 4.0.11
        migration-guides: add release notes for 4.2.2
        migration-guides: add release notes for 4.2.3
        migration-guides: add release notes for 4.0.12
        bind: update to 9.18.19
        ffmpeg: 5.1.2 -> 5.1.3

  Marc Ferland (1):
        connman: fix warning by specifying runstatedir at configure time

  Marek Vasut (1):
        linux-firmware: Fix mediatek mt7601u firmware path

  Mark Hatle (1):
        tcf-agent: Update to 1.8.0 release

  Markus Niebel (1):
        wic: fix wrong attempt to create file system in upartitioned regions

  Markus Volk (3):
        ell: upgrade 0.56 -> 0.57
        gtk4: upgrade 4.10.3 -> 4.10.4
        gtk4: upgrade 4.10.4 -> 4.10.5

  Martin Jansa (8):
        libx11: remove unused patch and FILESEXTRAPATHS
        qemu: remove unused qemu-7.0.0-glibc-2.36.patch
        minicom: remove unused patch files
        inetutils: remove unused patch files
        libgloss: remove unused patch file
        kmod: remove unused ptest.patch
        tcl: prevent installing another copy of tzdata
        gcc: backport a fix for ICE caused by CVE-2023-4039.patch

  Michael Halstead (4):
        resulttool/resultutils: allow index generation despite corrupt json
        yocto-uninative: Update hashes for uninative 4.1
        yocto-uninative: Update to 4.2 for glibc 2.38
        yocto-uninative: Update to 4.3

  Michael Opdenacker (13):
        ref-manual: releases.svg: updates
        conf.py: add macro for Mitre CVE links
        ref-manual: LTS releases now supported for 4 years
        poky.conf: update SANITY_TESTED_DISTROS to match autobuilder
        scripts/create-pull-request: update URLs to git repositories
        ref-manual: system-requirements: update supported distros
        manuals: add new contributor guide
        dev-manual: disk-space: mention faster "find" command to trim sstate cache
        sdk-manual: extensible.rst: fix multiple formatting issues
        dev-manual: disk-space: improve wording for obsolete sstate cache files
        dev-manual: new-recipe.rst fix inconsistency with contributor guide
        contributor-guide: recipe-style-guide: add Upstream-Status
        dev-manual: licenses: mention SPDX for license compliance

  Mikko Rapeli (1):
        useradd-staticids.bbclass: improve error message

  Mingli Yu (5):
        curl: fix CVE-2023-28319 through CVE-2023-28322
        python3-numpy: remove NPY_INLINE, use inline instead
        acpica: Update SRC_URI
        cups: Fix CVE-2023-34241
        ruby: Fix CVE-2023-36617

  Narpat Mali (5):
        python3-certifi: upgrade 2022.12.7 -> 2023.7.22
        ffmpeg: add CVE_CHECK_IGNORE for CVE-2023-39018
        python3-git: upgrade 3.1.31 -> 3.1.32
        python3-pygments: fix for CVE-2022-40896
        python3-git: upgrade 3.1.32 -> 3.1.37

  Natasha Bailey (1):
        tiff: backport a fix for CVE-2023-2731

  Oleksandr Hnatiuk (2):
        file: return wrapper to fix builds when file is in buildtools-tarball
        file: fix the way path is written to environment-setup.d

  Ovidiu Panait (7):
        mdadm: fix util-linux ptest dependency
        mdadm: fix 07revert-inplace ptest
        mdadm: fix segfaults when running ptests
        mdadm: skip running known broken ptests
        mdadm: re-add mdadm-ptest to PTESTS_SLOW
        mdadm: add util-linux-blockdev ptest dependency
        mdadm: skip running 04update-uuid and 07revert-inplace testcases

  Peter Marko (7):
        cve-update-nvd2-native: fix cvssV3 metrics
        cve-update-nvd2-native: retry all errors and sleep between retries
        cve-update-nvd2-native: increase retry count
        libjpeg-turbo: patch CVE-2023-2804
        python3: ignore CVE-2023-36632
        libarchive: ignore CVE-2023-30571
        openssl: Upgrade 3.1.1 -> 3.1.2

  Peter Suti (1):
        externalsrc: fix dependency chain issues

  Poonam Jadhav (1):
        pixman: Remove duplication of license MIT

  Quentin Schulz (3):
        docs: bsp-guide: bsp: fix typo
        docs: ref-manual: terms: fix typos in SPDX term
        uboot-extlinux-config.bbclass: fix old override syntax in comment

  Randolph Sapp (6):
        weston-init: make sure the render group exists
        weston-init: add weston user to the render group
        weston-init: add the weston user to the wayland group
        weston-init: fix the mixed indentation
        weston-init: guard against systemd configs
        weston-init: add profile to point users to global socket

  Richard Purdie (24):
        selftest/license: Exclude from world
        layer.conf: Add missing dependency exclusion
        v86d: Improve kernel dependency
        strace: Disable failing test
        bitbake: runqueue: Fix deferred task/multiconfig race issue
        strace: Merge two similar patches
        strace: Update patches/tests with upstream fixes
        ptest-runner: Pull in sync fix to improve log warnings
        ptest-runner: Ensure data writes don't race
        ptest-runner: Pull in "runner: Remove threads and mutexes" fix
        gcc-testsuite: Fix ppc cpu specification
        ptest-runner: Pull in parallel test fixes and output handling
        glibc-testsuite: Fix network restrictions causing test failures
        oeqa/target/ssh: Ensure EAGAIN doesn't truncate output
        oeqa/runtime/ltp: Increase ltp test output timeout
        ltp: Add kernel loopback module dependency
        target/ssh: Ensure exit code set for commands
        oeqa/ssh: Further improve process exit handling
        pseudo: Fix to work with glibc 2.38
        lib/package_manager: Improve repo artefact filtering
        gnupg: Fix reproducibility failure
        resulttool/report: Avoid divide by zero
        build-sysroots: Ensure dependency chains are minimal
        vim: Upgrade 9.0.1664 -> 9.0.1894

  Riyaz Khan (1):
        openssh: Remove BSD-4-clause contents completely from codebase

  Roland Hieber (2):
        template: fix typo in section header
        ref-manual: point outdated link to the new location

  Ross Burton (24):
        ninja: ignore CVE-2021-4336, wrong ninja
        binutils: fix CVE-2023-1972
        pkgconf: upgrade 1.9.4 -> 1.9.5
        git: upgrade to 2.39.3
        gobject-introspection: remove obsolete DEPENDS
        cve-update-nvd2-native: handle all configuration nodes, not just first
        cve-update-nvd2-native: use exact times, don't truncate
        cve-update-nvd2-native: log a little more
        cve-update-nvd2-native: actually use API keys
        tiff: upgrade to 4.5.1
        gcc: don't pass --enable-standard-branch-protection
        machine/arch-arm64: add -mbranch-protection=standard
        pkgconf: update SRC_URI
        python3: fix missing comma in get_module_deps3.py
        oeqa/runtime/cases/rpm: fix wait_for_no_process_for_user failure case
        rootfs_rpm: don't depend on opkg-native for update-alternatives
        ltp: add RDEPENDS on findutils
        openssh: upgrade to 9.3p2
        linux-yocto: add script to generate kernel CVE_CHECK_IGNORE entries
        linux/cve-exclusion: add generated CVE_CHECK_IGNOREs
        procps: backport fix for CVE-2023-4016
        graphene: fix runtime detection of IEEE754 behaviour
        gcc: Fix -fstack-protector issue on aarch64
        linux-yocto: update CVE exclusions

  Sakib Sajal (4):
        go: Upgrade 1.20.4 -> 1.20.5
        bno_plot.py, btt_plot.py: Ask for python3 specifically
        go: fix CVE-2023-24531
        go: upgrade 1.20.6 -> 1.20.7

  Sanjana (1):
        binutils: Fix CVE-2023-39128

  Sanjay Chitroda (2):
        cups: Fix CVE-2023-32324
        curl: Add CVE-2023-28320 follow-up fix

  Siddharth (1):
        tiff: Security fix for CVE-2023-25434 and CVE-2023-26965

  Siddharth Doshi (1):
        gdb: Fix CVE-2023-39128

  Soumya (1):
        perl: Fix CVE-2023-31484 & CVE-2023-31486

  Staffan Rydén (1):
        kernel: Fix path comparison in kernel staging dir symlinking

  Steve Sakoman (6):
        maintainers.inc: update version for gcc-source
        Revert "systemd: fix a dead link under /var/log"
        poky.conf: bump version for 4.2.2 release
        build-appliance-image: Update to mickledore head revision
        poky.conf: bump version for 4.2.3 release
        build-appliance-image: Update to mickledore head revision

  Stéphane Veyret (1):
        scripts/oe-setup-builddir: copy conf-notes.txt to build dir

  Sudip Mukherjee (2):
        dpkg: upgrade to v1.21.22
        bind: upgrade to v9.18.17

  Sundeep KOKKONDA (1):
        gcc : upgrade to v12.3

  Thomas Roos (1):
        testimage/oeqa: Drop testimage_dump_host functionality

  Tim Orling (1):
        openssl: upgrade 3.1.0 -> 3.1.1

  Tom Hochstein (1):
        weston: Cleanup and fix x11 and xwayland dependencies

  Trevor Gamblin (4):
        bind: upgrade 9.18.13 -> 9.18.14
        glib-networking: use correct error code in ptest
        vim: upgrade 9.0.1527 -> 9.0.1592
        linux-firmware: upgrade 20230515 -> 20230625

  Wang Mingyu (24):
        babeltrace2: upgrade 2.0.4 -> 2.0.5
        fribidi: upgrade 1.0.12 -> 1.0.13
        libdnf: upgrade 0.70.0 -> 0.70.1
        libmicrohttpd: upgrade 0.9.76 -> 0.9.77
        libxft: upgrade 2.3.7 -> 2.3.8
        libxpm: upgrade 3.5.15 -> 3.5.16
        mobile-broadband-provider-info: upgrade 20221107 -> 20230416
        bind: upgrade 9.18.14 -> 9.18.15
        xdpyinfo: upgrade 1.3.3 -> 1.3.4
        libxml2: upgrade 2.10.3 -> 2.10.4
        freetype: upgrade 2.13.0 -> 2.13.1
        gstreamer1.0: upgrade 1.22.3 -> 1.22.4
        libassuan: upgrade 2.5.5 -> 2.5.6
        libksba: upgrade 1.6.3 -> 1.6.4
        libx11: upgrade 1.8.5 -> 1.8.6
        lttng-ust: upgrade 2.13.5 -> 2.13.6
        taglib: upgrade 1.13 -> 1.13.1
        libwebp: upgrade 1.3.0 -> 1.3.1
        libnss-nis: upgrade 3.1 -> 3.2
        opkg: upgrade 0.6.1 -> 0.6.2
        opkg-utils: upgrade 0.5.0 -> 0.6.2
        file: upgrade 5.44 -> 5.45
        tar: upgrade 1.34 -> 1.35
        bind: upgrade 9.18.17 -> 9.18.18

  Xiangyu Chen (1):
        dbus: upgrade 1.14.6 -> 1.14.8

  Yash Shinde (1):
        glibc: fix CVE-2023-4527

  Yi Zhao (1):
        ifupdown: install missing directories

  Yoann Congal (3):
        recipetool: Fix inherit in created -native* recipes
        oeqa/selftest/devtool: add unit test for "devtool add -b"
        dev-manual: remove unsupported :term: markup inside markup

  Yogita Urade (8):
        dmidecode: fix CVE-2023-30630
        qemu: fix CVE-2023-3301
        qemu: fix CVE-2023-3255
        qemu: fix CVE-2023-2861
        inetutils: fix CVE-2023-40303
        nghttp2: fix CVE-2023-35945
        dropbear: fix CVE-2023-36328
        qemu: fix CVE-2023-3354

  Yuta Hayama (1):
        systemd-systemctl: fix errors in instance name expansion

  nikhil (1):
        libwebp: Fix CVE-2023-1999

  sanjana (2):
        binutils: stable 2.40 branch updates
        glibc: stable 2.37 branch updates

meta-openembedded: 9286582126..922f41b39f:
  Armin Kuster (1):
        openldap: update to 2.5.16.

  Beniamin Sandu (1):
        lmsensors: do not pull in unneeded perl modules for run-time dependencies

  Changqing Li (2):
        redis: upgrade 6.2.12 -> 6.2.13
        redis: upgrade 7.0.11 -> 7.0.12

  Chee Yang Lee (2):
        rabbitmq-c: Fix CVE-2023-35789
        c-ares: upgrade 1.19.0 -> 1.19.1

  Chen Qi (3):
        redis: use the files path correctly
        grpc: fix CVE-2023-32732
        grpc: fix CVE-2023-33953

  Chris Dimich (1):
        image_types_sparse: Fix syntax error

  Hitendra Prajapati (4):
        wireshark: Fix CVE-2023-2855 & CVE-2023-2856
        wireshark: Fix CVE-2023-2858 & CVE-2023-2879
        wireshark: CVE-2023-2952 XRA dissector infinite loop
        wireshark: Fix Multiple CVEs

  Jasper Orschulko (1):
        yaml-cpp: Fix cmake export

  Joe Slater (3):
        libgpiod: modify test 'gpioset: toggle (continuous)'
        python3-sqlparse: fix CVE-2023-30608
        libgpiod: modify RDEPENDS for ptest

  Khem Raj (2):
        fftw: Check for TOOLCHAIN_OPTIONS to be non-empty before sed ops
        system-config-printer: Delete __pycache__ files

  Lee Chee Yang (2):
        opensc: fix CVE-2023-2977
        x11vnc: Fix CVE-2020-29074

  Linus Jacobson (1):
        khronos-cts: Replace wayland feature dependancy with vulkan

  Martin Jansa (5):
        libiio: use main branch instead of master
        mongodb: enable hardware crc32 only with crc in TUNE_FEATURES
        khronos-cts.inc: respect MLPREFIX when appending DEPENDS with anonymous python
        libcyusbserial: fix installed-vs-shipped QA issue with multilib
        tcpreplay: fix pcap detection with /usr/lib32 multilib

  Mingli Yu (6):
        dialog: Update the SRC_URI
        gnulib: Update SRC_URI
        yajl: Fix CVE-2023-33460
        iniparser: Fix CVE-2023-33461
        php: Upgrade to 8.2.8
        mcelog: Drop unneeded autotools-brokensep

  Polampalli, Archana (6):
        tcpreplay: upgrade 4.4.3 -> 4.4.4
        nodejs: upgrade 18.14.2 -> 18.16.1
        yasm: fix CVE-2023-31975
        nodejs: upgrade 18.16.1 -> 18.17.1
        hwloc: fix CVE-2022-47022
        python3-appdirs: print ptest results in unified format

  Ross Burton (5):
        glade: add autoconf-archive-native DEPENDS
        libgxim: add autoconf-archive-native DEPENDS
        libblockdev: clean up DEPENDS
        imsettings: add missing DEPENDS on autoconf-archive-native
        system-config-printer: clean up DEPENDS

  Sandeep Gundlupet Raju 837 (1):
        opencv: Revert fix runtime dependencies

  Sanjay Chitroda (1):
        netkit-telnet: Fix CVE-2022-39028

  Soumya (1):
        yasm: fix CVE-2023-37732

  Soumya Sambu (1):
        krb5: Fix CVE-2023-36054

  Soumya via (1):
        opencv: Fix for CVE-2023-2617

  Urade, Yogita t.mo (1):
        c-ares: fix CVE-2023-32067

  Wang Mingyu (3):
        python3-django: upgrade 4.1.7 -> 4.2.1
        iperf3: upgrade 3.13 -> 3.14
        tcpdump: upgrade 4.99.3 -> 4.99.4

  Xiangyu Chen (2):
        libbpf: installing uapi headers for native package
        meta-oe: add pahole to NON_MULTILIB_RECIPES

  Yi Zhao (4):
        frr: upgrade 8.4.2 -> 8.4.4
        mbedtls: upgrade 2.28.2 -> 2.28.3
        open-vm-tools: Security fix CVE-2023-20867
        frr: Security fix CVE-2023-3748

  Yogita Urade (1):
        poppler: fix CVE-2023-34872

meta-arm: 8db460fa5d..6e199b354e:
  Abdellatif El Khlifi (6):
        arm-bsp/documentation: corstone1000: Update change log
        arm-bsp/doc: corstone1000: Update the software architecture document
        arm-bsp/documentation: corstone1000: update the release note
        arm-bsp/documentation: corstone1000: update user guide
        kas: set the SHAs for 2023.06 release
        arm-bsp/trusted-firmware-a: corstone1000: enable ERRATA_A35_855472

  Adam Johnston (2):
        CI: Platform specific Trusted Services config
        arm-bsp/trusted-firmware-a: Reserve OP-TEE memory from NWd on N1SDP

  Anton Antonov (1):
        arm/oeqa: Make ts-service-test config match selected SPs

  Denys Dmytriyenko (1):
        optee-os: do not explicitly set CFG_MAP_EXT_DT_SECURE=y

  Emekcan Aras (7):
        arm-bsp/u-boot: corstone1000: Fix EFI multiple protocol install failure
        arm-bsp/u-boot: corstone1000: Enable EFI set/get time services
        arm-bsp/trusted-services: corstone1000: GetNextVariableName Fix
        arm-bsp/optee-os:corstone1000: Drop SPMC non secure interrupt patches
        arm-bsp/u-boot: corstone1000: Fix u-boot compilation warnings
        arm-bsp/trusted-services: corstone1000: Fix PSA_RAW_KEY agreement test
        arm-bsp/trusted-services: corstone1000: Fix Capsule Update

  Gyorgy Szing (11):
        arm/trusted-services: update TS version
        optee-os: remove v3.18 pin of OP-TEE on qemuarm64-secureboot
        optee-os: Add support for TOS_FW_CONFIG on qemu
        arm/trusted-firmware-a: Add TOS_FW_CONFIG handling for quemu
        optee-test: backport SWd ABI compatibility changes
        optee-os: enable SPMC test
        arm/oeqa: enable OP-TEE SPMC tests
        trusted-services: update documentation
        arm/trusted-services: disable psa-iat on qemuarm64-secureboot
        arm/trusted-services: fix nanopb build error
        optee-os: unblock NWd interrupts

  Jon Mason (3):
        CI: remove master refspec for meta-virtualization yml file
        arm/linux-yocto: move 6.1 patches to a unique bbappend
        README: remove reference to meta-arm-autonomy

  Robbie Cao (1):
        arm/recipes-kernel: Add preempt-rt support for generic-arm64

  Rui Miguel Silva (3):
        arm-bsp/trusted-services:corstone1000: remove already merged patches
        arm-bsp/trusted-services: remove merged patches for corstone1000
        arm-bps/corstone1000: setup trusted service proxy configuration

  Tomás González (2):
        arm-bsp/documentation: corstone1000: Update the user guide
        arm-bsp/documentation: corstone1000: Update the release notes

Change-Id: I19ad289a1580a28192b5c063d06553d4e171687b
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>

10 files changed, 66 insertions, 565 deletions

diff --git a/poky/documentation/dev-manual/building.rst b/poky/documentation/dev-manual/building.rst
index 1f1642e846..a395793493 100644
--- a/poky/documentation/dev-manual/building.rst
+++ b/poky/documentation/dev-manual/building.rst
@@ -273,12 +273,12 @@ loading modules needed to locate and mount the final root filesystem.
 
 Follow these steps to create an :term:`Initramfs` image:
 
-#. *Create the :term:`Initramfs` Image Recipe:* You can reference the
+#. *Create the Initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
    ``meta/recipes-core`` directory of the :term:`Source Directory`
    as an example from which to work.
 
-#. *Decide if You Need to Bundle the :term:`Initramfs` Image Into the Kernel
+#. *Decide if You Need to Bundle the Initramfs Image Into the Kernel
    Image:* If you want the :term:`Initramfs` image that is built to be bundled
    in with the kernel image, set the :term:`INITRAMFS_IMAGE_BUNDLE`
    variable to ``"1"`` in your ``local.conf`` configuration file and set the
diff --git a/poky/documentation/dev-manual/changes.rst b/poky/documentation/dev-manual/changes.rst
deleted file mode 100644
index 9db6ce010c..0000000000
--- a/poky/documentation/dev-manual/changes.rst
+++ /dev/null
@@ -1,525 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Making Changes to the Yocto Project
-***********************************
-
-Because the Yocto Project is an open-source, community-based project,
-you can effect changes to the project. This section presents procedures
-that show you how to submit a defect against the project and how to
-submit a change.
-
-Submitting a Defect Against the Yocto Project
-=============================================
-
-Use the Yocto Project implementation of
-`Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
-against the Yocto Project. For additional information on this
-implementation of Bugzilla see the ":ref:`Yocto Project
-Bugzilla <resources-bugtracker>`" section in the
-Yocto Project Reference Manual. For more detail on any of the following
-steps, see the Yocto Project
-:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
-
-Use the following general steps to submit a bug:
-
-#.  Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
-
-#.  Click "File a Bug" to enter a new bug.
-
-#.  Choose the appropriate "Classification", "Product", and "Component"
-    for which the bug was found. Bugs for the Yocto Project fall into
-    one of several classifications, which in turn break down into
-    several products and components. For example, for a bug against the
-    ``meta-intel`` layer, you would choose "Build System, Metadata &
-    Runtime", "BSPs", and "bsps-meta-intel", respectively.
-
-#.  Choose the "Version" of the Yocto Project for which you found the
-    bug (e.g. &DISTRO;).
-
-#.  Determine and select the "Severity" of the bug. The severity
-    indicates how the bug impacted your work.
-
-#.  Choose the "Hardware" that the bug impacts.
-
-#.  Choose the "Architecture" that the bug impacts.
-
-#.  Choose a "Documentation change" item for the bug. Fixing a bug might
-    or might not affect the Yocto Project documentation. If you are
-    unsure of the impact to the documentation, select "Don't Know".
-
-#.  Provide a brief "Summary" of the bug. Try to limit your summary to
-    just a line or two and be sure to capture the essence of the bug.
-
-#.  Provide a detailed "Description" of the bug. You should provide as
-    much detail as you can about the context, behavior, output, and so
-    forth that surrounds the bug. You can even attach supporting files
-    for output from logs by using the "Add an attachment" button.
-
-#.  Click the "Submit Bug" button submit the bug. A new Bugzilla number
-    is assigned to the bug and the defect is logged in the bug tracking
-    system.
-
-Once you file a bug, the bug is processed by the Yocto Project Bug
-Triage Team and further details concerning the bug are assigned (e.g.
-priority and owner). You are the "Submitter" of the bug and any further
-categorization, progress, or comments on the bug result in Bugzilla
-sending you an automated email concerning the particular change or
-progress to the bug.
-
-Submitting a Change to the Yocto Project
-========================================
-
-Contributions to the Yocto Project and OpenEmbedded are very welcome.
-Because the system is extremely configurable and flexible, we recognize
-that developers will want to extend, configure or optimize it for their
-specific uses.
-
-The Yocto Project uses a mailing list and a patch-based workflow that is
-similar to the Linux kernel but contains important differences. In
-general, there is a mailing list through which you can submit patches. You
-should send patches to the appropriate mailing list so that they can be
-reviewed and merged by the appropriate maintainer. The specific mailing
-list you need to use depends on the location of the code you are
-changing. Each component (e.g. layer) should have a ``README`` file that
-indicates where to send the changes and which process to follow.
-
-You can send the patch to the mailing list using whichever approach you
-feel comfortable with to generate the patch. Once sent, the patch is
-usually reviewed by the community at large. If somebody has concerns
-with the patch, they will usually voice their concern over the mailing
-list. If a patch does not receive any negative reviews, the maintainer
-of the affected layer typically takes the patch, tests it, and then
-based on successful testing, merges the patch.
-
-The "poky" repository, which is the Yocto Project's reference build
-environment, is a hybrid repository that contains several individual
-pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
-the combo-layer tool. The upstream location used for submitting changes
-varies by component:
-
--  *Core Metadata:* Send your patch to the
-   :oe_lists:`openembedded-core </g/openembedded-core>`
-   mailing list. For example, a change to anything under the ``meta`` or
-   ``scripts`` directories should be sent to this mailing list.
-
--  *BitBake:* For changes to BitBake (i.e. anything under the
-   ``bitbake`` directory), send your patch to the
-   :oe_lists:`bitbake-devel </g/bitbake-devel>`
-   mailing list.
-
--  *"meta-\*" trees:* These trees contain Metadata. Use the
-   :yocto_lists:`poky </g/poky>` mailing list.
-
--  *Documentation*: For changes to the Yocto Project documentation, use the
-   :yocto_lists:`docs </g/docs>` mailing list.
-
-For changes to other layers hosted in the Yocto Project source
-repositories (i.e. ``yoctoproject.org``) and tools use the
-:yocto_lists:`Yocto Project </g/yocto/>` general mailing list.
-
-.. note::
-
-   Sometimes a layer's documentation specifies to use a particular
-   mailing list. If so, use that list.
-
-For additional recipes that do not fit into the core Metadata, you
-should determine which layer the recipe should go into and submit the
-change in the manner recommended by the documentation (e.g. the
-``README`` file) supplied with the layer. If in doubt, please ask on the
-Yocto general mailing list or on the openembedded-devel mailing list.
-
-You can also push a change upstream and request a maintainer to pull the
-change into the component's upstream repository. You do this by pushing
-to a contribution repository that is upstream. See the
-":ref:`overview-manual/development-environment:git workflows and the yocto project`"
-section in the Yocto Project Overview and Concepts Manual for additional
-concepts on working in the Yocto Project development environment.
-
-Maintainers commonly use ``-next`` branches to test submissions prior to
-merging patches. Thus, you can get an idea of the status of a patch based on
-whether the patch has been merged into one of these branches. The commonly
-used testing branches for OpenEmbedded-Core are as follows:
-
--  *openembedded-core "master-next" branch:* This branch is part of the
-   :oe_git:`openembedded-core </openembedded-core/>` repository and contains
-   proposed changes to the core metadata.
-
--  *poky "master-next" branch:* This branch is part of the
-   :yocto_git:`poky </poky/>` repository and combines proposed
-   changes to BitBake, the core metadata and the poky distro.
-
-Similarly, stable branches maintained by the project may have corresponding
-``-next`` branches which collect proposed changes. For example,
-``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
-branches in both the "openembdedded-core" and "poky" repositories.
-
-Other layers may have similar testing branches but there is no formal
-requirement or standard for these so please check the documentation for the
-layers you are contributing to.
-
-The following sections provide procedures for submitting a change.
-
-Preparing Changes for Submission
---------------------------------
-
-#. *Make Your Changes Locally:* Make your changes in your local Git
-   repository. You should make small, controlled, isolated changes.
-   Keeping changes small and isolated aids review, makes
-   merging/rebasing easier and keeps the change history clean should
-   anyone need to refer to it in future.
-
-#. *Stage Your Changes:* Stage your changes by using the ``git add``
-   command on each file you changed.
-
-#. *Commit Your Changes:* Commit the change by using the ``git commit``
-   command. Make sure your commit information follows standards by
-   following these accepted conventions:
-
-   -  Be sure to include a "Signed-off-by:" line in the same style as
-      required by the Linux kernel. This can be done by using the
-      ``git commit -s`` command. Adding this line signifies that you,
-      the submitter, have agreed to the Developer's Certificate of
-      Origin 1.1 as follows:
-
-      .. code-block:: none
-
-         Developer's Certificate of Origin 1.1
-
-         By making a contribution to this project, I certify that:
-
-         (a) The contribution was created in whole or in part by me and I
-             have the right to submit it under the open source license
-             indicated in the file; or
-
-         (b) The contribution is based upon previous work that, to the best
-             of my knowledge, is covered under an appropriate open source
-             license and I have the right under that license to submit that
-             work with modifications, whether created in whole or in part
-             by me, under the same open source license (unless I am
-             permitted to submit under a different license), as indicated
-             in the file; or
-
-         (c) The contribution was provided directly to me by some other
-             person who certified (a), (b) or (c) and I have not modified
-             it.
-
-         (d) I understand and agree that this project and the contribution
-             are public and that a record of the contribution (including all
-             personal information I submit with it, including my sign-off) is
-             maintained indefinitely and may be redistributed consistent with
-             this project or the open source license(s) involved.
-
-   -  Provide a single-line summary of the change and, if more
-      explanation is needed, provide more detail in the body of the
-      commit. This summary is typically viewable in the "shortlist" of
-      changes. Thus, providing something short and descriptive that
-      gives the reader a summary of the change is useful when viewing a
-      list of many commits. You should prefix this short description
-      with the recipe name (if changing a recipe), or else with the
-      short form path to the file being changed.
-
-   -  For the body of the commit message, provide detailed information
-      that describes what you changed, why you made the change, and the
-      approach you used. It might also be helpful if you mention how you
-      tested the change. Provide as much detail as you can in the body
-      of the commit message.
-
-      .. note::
-
-         You do not need to provide a more detailed explanation of a
-         change if the change is minor to the point of the single line
-         summary providing all the information.
-
-   -  If the change addresses a specific bug or issue that is associated
-      with a bug-tracking ID, include a reference to that ID in your
-      detailed description. For example, the Yocto Project uses a
-      specific convention for bug references --- any commit that addresses
-      a specific bug should use the following form for the detailed
-      description. Be sure to use the actual bug-tracking ID from
-      Bugzilla for bug-id::
-
-         Fixes [YOCTO #bug-id]
-
-         detailed description of change
-
-Using Email to Submit a Patch
------------------------------
-
-Depending on the components changed, you need to submit the email to a
-specific mailing list. For some guidance on which mailing list to use,
-see the
-:ref:`list <dev-manual/changes:submitting a change to the yocto project>`
-at the beginning of this section. For a description of all the available
-mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
-Yocto Project Reference Manual.
-
-Here is the general procedure on how to submit a patch through email
-without using the scripts once the steps in
-:ref:`dev-manual/changes:preparing changes for submission` have been followed:
-
-#. *Format the Commit:* Format the commit into an email message. To
-   format commits, use the ``git format-patch`` command. When you
-   provide the command, you must include a revision list or a number of
-   patches as part of the command. For example, either of these two
-   commands takes your most recent single commit and formats it as an
-   email message in the current directory::
-
-      $ git format-patch -1
-
-   or ::
-
-      $ git format-patch HEAD~
-
-   After the command is run, the current directory contains a numbered
-   ``.patch`` file for the commit.
-
-   If you provide several commits as part of the command, the
-   ``git format-patch`` command produces a series of numbered files in
-   the current directory – one for each commit. If you have more than
-   one patch, you should also use the ``--cover`` option with the
-   command, which generates a cover letter as the first "patch" in the
-   series. You can then edit the cover letter to provide a description
-   for the series of patches. For information on the
-   ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
-   using the ``man git-format-patch`` command.
-
-   .. note::
-
-      If you are or will be a frequent contributor to the Yocto Project
-      or to OpenEmbedded, you might consider requesting a contrib area
-      and the necessary associated rights.
-
-#. *Send the patches via email:* Send the patches to the recipients and
-   relevant mailing lists by using the ``git send-email`` command.
-
-   .. note::
-
-      In order to use ``git send-email``, you must have the proper Git packages
-      installed on your host.
-      For Ubuntu, Debian, and Fedora the package is ``git-email``.
-
-   The ``git send-email`` command sends email by using a local or remote
-   Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
-   through a direct ``smtp`` configuration in your Git ``~/.gitconfig``
-   file. If you are submitting patches through email only, it is very
-   important that you submit them without any whitespace or HTML
-   formatting that either you or your mailer introduces. The maintainer
-   that receives your patches needs to be able to save and apply them
-   directly from your emails. A good way to verify that what you are
-   sending will be applicable by the maintainer is to do a dry run and
-   send them to yourself and then save and apply them as the maintainer
-   would.
-
-   The ``git send-email`` command is the preferred method for sending
-   your patches using email since there is no risk of compromising
-   whitespace in the body of the message, which can occur when you use
-   your own mail client. The command also has several options that let
-   you specify recipients and perform further editing of the email
-   message. For information on how to use the ``git send-email``
-   command, see ``GIT-SEND-EMAIL(1)`` displayed using the
-   ``man git-send-email`` command.
-
-The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__
-to track the status of patches submitted to the various mailing lists and to
-support automated patch testing. Each submitted patch is checked for common
-mistakes and deviations from the expected patch format and submitters are
-notified by patchtest if such mistakes are found. This process helps to
-reduce the burden of patch review on maintainers.
-
-.. note::
-
-   This system is imperfect and changes can sometimes get lost in the flow.
-   Asking about the status of a patch or change is reasonable if the change
-   has been idle for a while with no feedback.
-
-Using Scripts to Push a Change Upstream and Request a Pull
-----------------------------------------------------------
-
-For larger patch series it is preferable to send a pull request which not
-only includes the patch but also a pointer to a branch that can be pulled
-from. This involves making a local branch for your changes, pushing this
-branch to an accessible repository and then using the ``create-pull-request``
-and ``send-pull-request`` scripts from openembedded-core to create and send a
-patch series with a link to the branch for review.
-
-Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`dev-manual/changes:preparing changes for submission` have
-been followed:
-
-.. note::
-
-   You can find general Git information on how to push a change upstream
-   in the
-   `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
-
-#. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
-   permissions to push to an upstream contrib repository, push the
-   change to that repository::
-
-      $ git push upstream_remote_repo local_branch_name
-
-   For example, suppose you have permissions to push
-   into the upstream ``meta-intel-contrib`` repository and you are
-   working in a local branch named `your_name`\ ``/README``. The following
-   command pushes your local commits to the ``meta-intel-contrib``
-   upstream repository and puts the commit in a branch named
-   `your_name`\ ``/README``::
-
-      $ git push meta-intel-contrib your_name/README
-
-#. *Determine Who to Notify:* Determine the maintainer or the mailing
-   list that you need to notify for the change.
-
-   Before submitting any change, you need to be sure who the maintainer
-   is or what mailing list that you need to notify. Use either these
-   methods to find out:
-
-   -  *Maintenance File:* Examine the ``maintainers.inc`` file, which is
-      located in the :term:`Source Directory` at
-      ``meta/conf/distro/include``, to see who is responsible for code.
-
-   -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
-      enter the following command to bring up a short list of all
-      commits against a specific file::
-
-         git shortlog -- filename
-
-      Just provide the name of the file for which you are interested. The
-      information returned is not ordered by history but does include a
-      list of everyone who has committed grouped by name. From the list,
-      you can see who is responsible for the bulk of the changes against
-      the file.
-
-   -  *Examine the List of Mailing Lists:* For a list of the Yocto
-      Project and related mailing lists, see the ":ref:`Mailing
-      lists <resources-mailinglist>`" section in
-      the Yocto Project Reference Manual.
-
-#. *Make a Pull Request:* Notify the maintainer or the mailing list that
-   you have pushed a change by making a pull request.
-
-   The Yocto Project provides two scripts that conveniently let you
-   generate and send pull requests to the Yocto Project. These scripts
-   are ``create-pull-request`` and ``send-pull-request``. You can find
-   these scripts in the ``scripts`` directory within the
-   :term:`Source Directory` (e.g.
-   ``poky/scripts``).
-
-   Using these scripts correctly formats the requests without
-   introducing any whitespace or HTML formatting. The maintainer that
-   receives your patches either directly or through the mailing list
-   needs to be able to save and apply them directly from your emails.
-   Using these scripts is the preferred method for sending patches.
-
-   First, create the pull request. For example, the following command
-   runs the script, specifies the upstream repository in the contrib
-   directory into which you pushed the change, and provides a subject
-   line in the created patch files::
-
-      $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
-
-   Running this script forms ``*.patch`` files in a folder named
-   ``pull-``\ `PID` in the current directory. One of the patch files is a
-   cover letter.
-
-   Before running the ``send-pull-request`` script, you must edit the
-   cover letter patch to insert information about your change. After
-   editing the cover letter, send the pull request. For example, the
-   following command runs the script and specifies the patch directory
-   and email address. In this example, the email address is a mailing
-   list::
-
-      $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
-
-   You need to follow the prompts as the script is interactive.
-
-   .. note::
-
-      For help on using these scripts, simply provide the ``-h``
-      argument as follows::
-
-              $ poky/scripts/create-pull-request -h
-              $ poky/scripts/send-pull-request -h
-
-Responding to Patch Review
---------------------------
-
-You may get feedback on your submitted patches from other community members
-or from the automated patchtest service. If issues are identified in your
-patch then it is usually necessary to address these before the patch will be
-accepted into the project. In this case you should amend the patch according
-to the feedback and submit an updated version to the relevant mailing list,
-copying in the reviewers who provided feedback to the previous version of the
-patch.
-
-The patch should be amended using ``git commit --amend`` or perhaps ``git
-rebase`` for more expert git users. You should also modify the ``[PATCH]``
-tag in the email subject line when sending the revised patch to mark the new
-iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be
-done by passing the ``-v`` argument to ``git format-patch`` with a version
-number.
-
-Lastly please ensure that you also test your revised changes. In particular
-please don't just edit the patch file written out by ``git format-patch`` and
-resend it.
-
-Submitting Changes to Stable Release Branches
----------------------------------------------
-
-The process for proposing changes to a Yocto Project stable branch differs
-from the steps described above. Changes to a stable branch must address
-identified bugs or CVEs and should be made carefully in order to avoid the
-risk of introducing new bugs or breaking backwards compatibility. Typically
-bug fixes must already be accepted into the master branch before they can be
-backported to a stable branch unless the bug in question does not affect the
-master branch or the fix on the master branch is unsuitable for backporting.
-
-The list of stable branches along with the status and maintainer for each
-branch can be obtained from the
-:yocto_wiki:`Releases wiki page </Releases>`.
-
-.. note::
-
-   Changes will not typically be accepted for branches which are marked as
-   End-Of-Life (EOL).
-
-With this in mind, the steps to submit a change for a stable branch are as
-follows:
-
-#. *Identify the bug or CVE to be fixed:* This information should be
-   collected so that it can be included in your submission.
-
-   See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities`
-   for details about CVE tracking.
-
-#. *Check if the fix is already present in the master branch:* This will
-   result in the most straightforward path into the stable branch for the
-   fix.
-
-   #. *If the fix is present in the master branch --- submit a backport request
-      by email:* You should send an email to the relevant stable branch
-      maintainer and the mailing list with details of the bug or CVE to be
-      fixed, the commit hash on the master branch that fixes the issue and
-      the stable branches which you would like this fix to be backported to.
-
-   #. *If the fix is not present in the master branch --- submit the fix to the
-      master branch first:* This will ensure that the fix passes through the
-      project's usual patch review and test processes before being accepted.
-      It will also ensure that bugs are not left unresolved in the master
-      branch itself. Once the fix is accepted in the master branch a backport
-      request can be submitted as above.
-
-   #. *If the fix is unsuitable for the master branch --- submit a patch
-      directly for the stable branch:* This method should be considered as a
-      last resort. It is typically necessary when the master branch is using
-      a newer version of the software which includes an upstream fix for the
-      issue or when the issue has been fixed on the master branch in a way
-      that introduces backwards incompatible changes. In this case follow the
-      steps in :ref:`dev-manual/changes:preparing changes for submission` and
-      :ref:`dev-manual/changes:using email to submit a patch` but modify the subject header of your patch
-      email to include the name of the stable branch which you are
-      targetting. This can be done using the ``--subject-prefix`` argument to
-      ``git format-patch``, for example to submit a patch to the dunfell
-      branch use
-      ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
-
diff --git a/poky/documentation/dev-manual/debugging.rst b/poky/documentation/dev-manual/debugging.rst
index 3c5609cef5..fea2cb30a1 100644
--- a/poky/documentation/dev-manual/debugging.rst
+++ b/poky/documentation/dev-manual/debugging.rst
@@ -879,8 +879,7 @@ The build should work without issue.
 As with all solved problems, if they originated upstream, you need to
 submit the fix for the recipe in OE-Core and upstream so that the
 problem is taken care of at its source. See the
-":ref:`dev-manual/changes:submitting a change to the yocto project`"
-section for more information.
+":doc:`../contributor-guide/submit-changes`" section for more information.
 
 Debugging With the GNU Project Debugger (GDB) Remotely
 ======================================================
@@ -1236,9 +1235,7 @@ Here are some other tips that you might find useful:
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
    Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-   and the
-   ":ref:`dev-manual/changes:submitting a defect against the yocto project`"
-   section.
+   and the ":doc:`../contributor-guide/report-defect`" section.
 
    .. note::
 
diff --git a/poky/documentation/dev-manual/disk-space.rst b/poky/documentation/dev-manual/disk-space.rst
index c63591cc7a..6d1638a302 100644
--- a/poky/documentation/dev-manual/disk-space.rst
+++ b/poky/documentation/dev-manual/disk-space.rst
@@ -23,23 +23,39 @@ final disk usage of 22 Gbytes instead of &MIN_DISK_SPACE; Gbytes. However,
 &MIN_DISK_SPACE_RM_WORK; Gbytes of initial free disk space are still needed to
 create temporary files before they can be deleted.
 
-Purging Duplicate Shared State Cache Files
-==========================================
+Purging Obsolete Shared State Cache Files
+=========================================
 
 After multiple build iterations, the Shared State (sstate) cache can contain
-duplicate cache files for a given package, while only the most recent one
-is likely to be reusable. The following command purges all but the
-newest sstate cache file for each package::
+multiple cache files for a given package, consuming a substantial amount of
+disk space. However, only the most recent ones are likely to be reused.
 
-   sstate-cache-management.sh --remove-duplicated --cache-dir=build/sstate-cache
+The following command is a quick way to purge all the cache files which
+haven't been used for a least a specified number of days::
 
-This command will ask you to confirm the deletions it identifies.
+   find build/sstate-cache -type f -mtime +$DAYS -delete
 
-.. note::
+The above command relies on the fact that BitBake touches the sstate cache
+files as it accesses them, when it has write access to the cache.
 
-   The duplicated sstate cache files of one package must have the same
-   architecture, which means that sstate cache files with multiple
-   architectures are not considered as duplicate.
+You could use ``-atime`` instead of ``-mtime`` if the partition isn't mounted
+with the ``noatime`` option for a read only cache.
 
+For more advanced needs, OpenEmbedded-Core also offers a more elaborate
+command. It has the ability to purge all but the newest cache files on each
+architecture, and also to remove files that it considers unreachable by
+exploring a set of build configurations. However, this command
+requires a full build environment to be available and doesn't work well
+covering multiple releases. It won't work either on limited environments
+such as BSD based NAS::
+
+   sstate-cache-management.sh --remove-duplicated --cache-dir=build/sstate-cache
+
+This command will ask you to confirm the deletions it identifies.
 Run ``sstate-cache-management.sh`` for more details about this script.
 
+.. note::
+
+   As this command is much more cautious and selective, removing only cache files,
+   it will execute much slower than the simple ``find`` command described above.
+   Therefore, it may not be your best option to trim huge cache directories.
diff --git a/poky/documentation/dev-manual/index.rst b/poky/documentation/dev-manual/index.rst
index b0bb5576ad..3618e51c8d 100644
--- a/poky/documentation/dev-manual/index.rst
+++ b/poky/documentation/dev-manual/index.rst
@@ -43,7 +43,6 @@ Yocto Project Development Tasks Manual
    build-quality
    runtime-testing
    debugging
-   changes
    licenses
    vulnerabilities
    sbom
diff --git a/poky/documentation/dev-manual/licenses.rst b/poky/documentation/dev-manual/licenses.rst
index 9629dc5329..200c3fc389 100644
--- a/poky/documentation/dev-manual/licenses.rst
+++ b/poky/documentation/dev-manual/licenses.rst
@@ -298,14 +298,28 @@ There are other requirements beyond the scope of these three and the
 methods described in this section (e.g. the mechanism through which
 source code is distributed).
 
-As different organizations have different methods of complying with open
-source licensing, this section is not meant to imply that there is only
-one single way to meet your compliance obligations, but rather to
-describe one method of achieving compliance. The remainder of this
-section describes methods supported to meet the previously mentioned
-three requirements. Once you take steps to meet these requirements, and
-prior to releasing images, sources, and the build system, you should
-audit all artifacts to ensure completeness.
+As different organizations have different ways of releasing software,
+there can be multiple ways of meeting license obligations. At
+least, we describe here two methods for achieving compliance:
+
+-  The first method is to use OpenEmbedded's ability to provide
+   the source code, provide a list of licenses, as well as
+   compilation scripts and source code modifications.
+
+   The remainder of this section describes supported methods to meet
+   the previously mentioned three requirements.
+
+-  The second method is to generate a *Software Bill of Materials*
+   (:term:`SBoM`), as described in the ":doc:`/dev-manual/sbom`" section.
+   Not only do you generate :term:`SPDX` output which can be used meet
+   license compliance requirements (except for sharing the build system
+   and layers sources for the time being), but this output also includes
+   component version and patch information which can be used
+   for vulnerability assessment.
+
+Whatever method you choose, prior to releasing images, sources,
+and the build system, you should audit all artifacts to ensure
+completeness.
 
 .. note::
 
diff --git a/poky/documentation/dev-manual/new-recipe.rst b/poky/documentation/dev-manual/new-recipe.rst
index ab3e193aaf..39ee9683b0 100644
--- a/poky/documentation/dev-manual/new-recipe.rst
+++ b/poky/documentation/dev-manual/new-recipe.rst
@@ -1082,13 +1082,14 @@ build system and package managers, so the resulting packages will not
 correctly trigger an upgrade.
 
 In order to ensure the versions compare properly, the recommended
-convention is to set :term:`PV` within the
-recipe to "previous_version+current_version". You can use an additional
-variable so that you can use the current version elsewhere. Here is an
-example::
+convention is to use a tilde (``~``) character as follows::
 
-   REALPV = "0.8.16-rc1"
-   PV = "0.8.15+${REALPV}"
+  PV = 0.8.16~rc1
+
+This way ``0.8.16~rc1`` sorts before ``0.8.16``. See the
+":ref:`contributor-guide/recipe-style-guide:version policy`" section in the
+Yocto Project and OpenEmbedded Contributor Guide for more details about
+versioning code corresponding to a pre-release or to a specific Git commit.
 
 Post-Installation Scripts
 =========================
diff --git a/poky/documentation/dev-manual/start.rst b/poky/documentation/dev-manual/start.rst
index 4881481044..88afa27ad5 100644
--- a/poky/documentation/dev-manual/start.rst
+++ b/poky/documentation/dev-manual/start.rst
@@ -246,14 +246,13 @@ particular working environment and set of practices.
     -  The Yocto Project community encourages you to send patches to the
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
-       messages. See the
-       ":ref:`dev-manual/changes:submitting a change to the yocto project`"
-       section.
+       messages. See the ":doc:`../contributor-guide/submit-changes`"
+       section in the Yocto Project and OpenEmbedded Contributor Guide.
 
     -  Send changes to the core sooner than later as others are likely
        to run into the same issues. For some guidance on mailing lists
-       to use, see the list in the
-       ":ref:`dev-manual/changes:submitting a change to the yocto project`"
+       to use, see the lists in the
+       ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`"
        section. For a description
        of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
        the Yocto Project Reference Manual.
diff --git a/poky/documentation/dev-manual/vulnerabilities.rst b/poky/documentation/dev-manual/vulnerabilities.rst
index 0ee3ec52c5..ac0ca249c1 100644
--- a/poky/documentation/dev-manual/vulnerabilities.rst
+++ b/poky/documentation/dev-manual/vulnerabilities.rst
@@ -22,7 +22,7 @@ issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
 contributors and anyone interested in the issues to investigate and possibly fix them by
 updating software components to newer versions or by applying patches to address them.
 It is recommended to work with Poky and OE-Core upstream maintainers and submit
-patches to fix them, see ":ref:`dev-manual/changes:submitting a change to the yocto project`" for details.
+patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
 =================================
diff --git a/poky/documentation/dev-manual/wic.rst b/poky/documentation/dev-manual/wic.rst
index 2a4408cdb0..664f07a212 100644
--- a/poky/documentation/dev-manual/wic.rst
+++ b/poky/documentation/dev-manual/wic.rst
@@ -92,7 +92,7 @@ system needs to meet the following requirements:
 -  You must build several native tools, which are built to run on the
    build system::
 
-      $ bitbake parted-native dosfstools-native mtools-native
+      $ bitbake wic-tools
 
 -  Include "wic" as part of the
    :term:`IMAGE_FSTYPES`