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>

1 files changed, 0 insertions, 525 deletions

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' ...``.
-