diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2023-10-03 17:44:52 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2023-10-03 18:04:36 +0300 |
commit | 1e488cdf844bf4aa82d3c90875a56fb35c7f210d (patch) | |
tree | be163d890651760d24effea503cd567df3e119b5 /poky/documentation/contributor-guide/submit-changes.rst | |
parent | 4f6b1c0dcf9f9cb734f71b277af913e0d58c503f (diff) | |
download | openbmc-1e488cdf844bf4aa82d3c90875a56fb35c7f210d.tar.xz |
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>
Diffstat (limited to 'poky/documentation/contributor-guide/submit-changes.rst')
-rw-r--r-- | poky/documentation/contributor-guide/submit-changes.rst | 754 |
1 files changed, 754 insertions, 0 deletions
diff --git a/poky/documentation/contributor-guide/submit-changes.rst b/poky/documentation/contributor-guide/submit-changes.rst new file mode 100644 index 0000000000..cda2d12d25 --- /dev/null +++ b/poky/documentation/contributor-guide/submit-changes.rst @@ -0,0 +1,754 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +Contributing Changes to a Component +************************************ + +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. + +.. _ref-why-mailing-lists: + +Contributing through mailing lists --- Why not using web-based workflows? +========================================================================= + +Both Yocto Project and OpenEmbedded have many key components that are +maintained by patches being submitted on mailing lists. We appreciate this +approach does look a little old fashioned when other workflows are available +through web technology such as GitHub, GitLab and others. Since we are often +asked this question, we’ve decided to document the reasons for using mailing +lists. + +One significant factor is that we value peer review. When a change is proposed +to many of the core pieces of the project, it helps to have many eyes of review +go over them. Whilst there is ultimately one maintainer who needs to make the +final call on accepting or rejecting a patch, the review is made by many eyes +and the exact people reviewing it are likely unknown to the maintainer. It is +often the surprise reviewer that catches the most interesting issues! + +This is in contrast to the "GitHub" style workflow where either just a +maintainer makes that review, or review is specifically requested from +nominated people. We believe there is significant value added to the codebase +by this peer review and that moving away from mailing lists would be to the +detriment of our code. + +We also need to acknowledge that many of our developers are used to this +mailing list workflow and have worked with it for years, with tools and +processes built around it. Changing away from this would result in a loss +of key people from the project, which would again be to its detriment. + +The projects are acutely aware that potential new contributors find the +mailing list approach off-putting and would prefer a web-based GUI. +Since we don’t believe that can work for us, the project is aiming to ensure +`patchwork <https://patchwork.yoctoproject.org/>`__ is available to help track +patch status and also looking at how tooling can provide more feedback to users +about patch status. We are looking at improving tools such as ``patchtest`` to +test user contributions before they hit the mailing lists and also at better +documenting how to use such workflows since we recognise that whilst this was +common knowledge a decade ago, it might not be as familiar now. + +Preparing Changes for Submission +================================ + +Set up Git +---------- + +The first thing to do is to install Git packages. Here is an example +on Debian and Ubuntu:: + + sudo aptitude install git-core git-email + +Then, you need to set a name and e-mail address that Git will +use to identify your commits:: + + git config --global user.name "Ada Lovelace" + git config --global user.email "ada.lovelace@gmail.com" + +Clone the Git repository for the component to modify +---------------------------------------------------- + +After identifying the component to modify as described in the +":doc:`../contributor-guide/identify-component`" section, clone the +corresponding Git repository. Here is an example for OpenEmbedded-Core:: + + git clone https://git.openembedded.org/openembedded-core + cd openembedded-core + +Create a new branch +------------------- + +Then, create a new branch in your local Git repository +for your changes, starting from the reference branch in the upstream +repository (often called ``master``):: + + $ git checkout <ref-branch> + $ git checkout -b my-changes + +If you have completely unrelated sets of changes to submit, you should even +create one branch for each set. + +Implement and commit changes +---------------------------- + +In each branch, you should group your changes into small, controlled and +isolated ones. 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. + +To this purpose, you should create *one Git commit per change*, +corresponding to each of the patches you will eventually submit. +See `further guidance <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__ +in the Linux kernel documentation if needed. + +For example, when you intend to add multiple new recipes, each recipe +should be added in a separate commit. For upgrades to existing recipes, +the previous version should usually be deleted as part of the same commit +to add the upgraded version. + +#. *Stage Your Changes:* Stage your changes by using the ``git add`` + command on each file you modified. If you want to stage all the + files you modified, you can even use the ``git add -A`` command. + +#. *Commit Your Changes:* This is when you can create separate commits. For + each commit to create, use the ``git commit -s`` command with the files + or directories you want to include in the commit:: + + $ git commit -s file1 file2 dir1 dir2 ... + + To include **a**\ ll staged files:: + + $ git commit -sa + + - The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line + to your commit message. There is the same requirement for contributing + to the Linux kernel. Adding such a line signifies that you, the + submitter, have agreed to the `Developer's Certificate of Origin 1.1 + <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__ + 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. + + .. note:: + + To find a suitable prefix for the commit summary, a good idea + is to look for prefixes used in previous commits touching the + same files or directories:: + + git log --oneline <paths> + + - 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:: + + If the single line summary is enough to describe a simple + change, the body of the commit message can be left empty. + + - 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 + +#. *Crediting contributors:* By using the ``git commit --amend`` command, + you can add some tags to the commit description to credit other contributors + to the change: + + - ``Reported-by``: name and email of a person reporting a bug + that your commit is trying to fix. This is a good practice + to encourage people to go on reporting bugs and let them + know that their reports are taken into account. + + - ``Suggested-by``: name and email of a person to credit for the + idea of making the change. + + - ``Tested-by``, ``Reviewed-by``: name and email for people having + tested your changes or reviewed their code. These fields are + usually added by the maintainer accepting a patch, or by + yourself if you submitted your patches to early reviewers, + or are submitting an unmodified patch again as part of a + new iteration of your patch series. + + - ``CC:`` Name and email of people you want to send a copy + of your changes to. This field will be used by ``git send-email``. + + See `more guidance about using such tags + <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__ + in the Linux kernel documentation. + +Creating Patches +================ + +Here is the general procedure on how to create patches to be sent through email: + +#. *Describe the Changes in your Branch:* If you have more than one commit + in your branch, it's recommended to provide a cover letter describing + the series of patches you are about to send. + + For this purpose, a good solution is to store the cover letter contents + in the branch itself:: + + git branch --edit-description + + This will open a text editor to fill in the description for your + changes. This description can be updated when necessary and will + be used by Git to create the cover letter together with the patches. + + It is recommended to start this description with a title line which + will serve a the subject line for the cover letter. + +#. *Generate Patches for your Branch:* The ``git format-patch`` command will + generate patch files for each of the commits in your branch. You need + to pass the reference branch your branch starts from. + + If you branch didn't need a description in the previous step:: + + $ git format-patch <ref-branch> + + If you filled a description for your branch, you will want to generate + a cover letter too:: + + $ git format-patch --cover-letter --cover-from-description=auto <ref-branch> + + After the command is run, the current directory contains numbered + ``.patch`` files for the commits in your branch. If you have a cover + letter, it will be in the ``0000-cover-letter.patch``. + + .. note:: + + The ``--cover-from-description=auto`` option makes ``git format-patch`` + use the first paragraph of the branch description as the cover + letter title. Another possibility, which is easier to remember, is to pass + only the ``--cover-letter`` option, but you will have to edit the + subject line manually every time you generate the patches. + + See the `git format-patch manual page <https://git-scm.com/docs/git-format-patch>`__ + for details. + +#. *Review each of the Patch Files:* This final review of the patches + before sending them often allows to view your changes from a different + perspective and discover defects such as typos, spacing issues or lines + or even files that you didn't intend to modify. This review should + include the cover letter patch too. + + If necessary, rework your commits as described in + ":ref:`contributor-guide/submit-changes:taking patch review into account`". + +Sending the Patches via Email +============================= + +Using Git to Send Patches +------------------------- + +To submit patches through email, it is very important that you send 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, using the ``git am`` +command. + +Using the ``git send-email`` command is the only error-proof way of 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. It will also properly include your patches as *inline attachments*, +which is not easy to do with standard e-mail clients without breaking lines. +If you used your regular e-mail client and shared your patches as regular +attachments, reviewers wouldn't be able to quote specific sections of your +changes and make comments about them. + +Setting up Git to Send Email +---------------------------- + +The ``git send-email`` command can send 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. + +Here are the settings for letting ``git send-email`` send e-mail through your +regular STMP server, using a Google Mail account as an example:: + + git config --global sendemail.smtpserver smtp.gmail.com + git config --global sendemail.smtpserverport 587 + git config --global sendemail.smtpencryption tls + git config --global sendemail.smtpuser ada.lovelace@gmail.com + git config --global sendemail.smtppass = XXXXXXXX + +These settings will appear in the ``.gitconfig`` file in your home directory. + +If you neither can use a local MTA nor SMTP, make sure you use an email client +that does not touch the message (turning spaces in tabs, wrapping lines, etc.). +A good mail client to do so is Pine (or Alpine) or Mutt. For more +information about suitable clients, see `Email clients info for Linux +<https://www.kernel.org/doc/html/latest/process/email-clients.html>`__ +in the Linux kernel sources. + +If you use such clients, just include the patch in the body of your email. + +Finding a Suitable Mailing List +------------------------------- + +You should send patches to the appropriate mailing list so that they can be +reviewed by the right contributors and merged by the appropriate maintainer. +The specific mailing list you need to use depends on the location of the code +you are changing. + +If people have concerns with any of the patches, they will usually voice +their concern over the mailing list. If patches do not receive any negative +reviews, the maintainer of the affected layer typically takes them, tests them, +and then based on successful testing, merges them. + +In general, each component (e.g. layer) should have a ``README`` file +that indicates where to send the changes and which process to follow. + +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 patches 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 patches 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 and tools hosted in the Yocto Project source +repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the +:yocto_lists:`yocto </g/yocto/>` general mailing list. + +For changes to other layers hosted in the OpenEmbedded source +repositories (i.e. :oe_git:`git.openembedded.org <>`), use +the :oe_lists:`openembedded-devel </g/openembedded-devel>` +mailing list, unless specified otherwise in the layer's ``README`` file. + +If you intend to submit a new recipe that neither fits into the core Metadata, +nor into :oe_git:`meta-openembedded </meta-openembedded/>`, you should +look for a suitable layer in https://layers.openembedded.org. If similar +recipes can be expected, you may consider :ref:`dev-manual/layers:creating your own layer`. + +If in doubt, please ask on the :yocto_lists:`yocto </g/yocto/>` general mailing list +or on the :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list. + +Subscribing to the Mailing List +------------------------------- + +After identifying the right mailing list to use, you will have to subscribe to +it if you haven't done it yet. + +If you attempt to send patches to a list you haven't subscribed to, your email +will be returned as undelivered. + +However, if you don't want to be receive all the messages sent to a mailing list, +you can set your subscription to "no email". You will still be a subscriber able +to send messages, but you won't receive any e-mail. If people reply to your message, +their e-mail clients will default to including your email address in the +conversation anyway. + +Anyway, you'll also be able to access the new messages on mailing list archives, +either through a web browser, or for the lists archived on https://lore.kernelorg, +through an individual newsgroup feed or a git repository. + +Sending Patches via Email +------------------------- + +At this stage, you are ready to send your patches via email. Here's the +typical usage of ``git send-email``:: + + git send-email --to <mailing-list-address> *.patch + +Then, review each subject line and list of recipients carefully, and then +and then allow the command to send each message. + +You will see that ``git send-email`` will automatically copy the people listed +in any commit tags such as ``Signed-off-by`` or ``Reported-by``. + +In case you are sending patches for :oe_git:`meta-openembedded </meta-openembedded/>` +or any layer other than :oe_git:`openembedded-core </openembedded-core/>`, +please add the appropriate prefix so that it is clear which layer the patch is intended +to be applied to:: + + git send-email --subject-prefix="meta-oe][PATCH" ... + +.. note:: + + It is actually possible to send patches without generating them + first. However, make sure you have reviewed your changes carefully + because ``git send-email`` will just show you the title lines of + each patch. + + Here's a command you can use if you just have one patch in your + branch:: + + git send-email --to <mailing-list-address> -1 + + If you have multiple patches and a cover letter, you can send + patches for all the commits between the reference branch + and the tip of your branch:: + + git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch> + +See the `git send-email manual page <https://git-scm.com/docs/git-send-email>`__ +for details. + +Troubleshooting Email Issues +---------------------------- + +Fixing your From identity +~~~~~~~~~~~~~~~~~~~~~~~~~ + +We have a frequent issue with contributors whose patches are received through +a ``From`` field which doesn't match the ``Signed-off-by`` information. Here is +a typical example for people sending from a domain name with :wikipedia:`DMARC`:: + + From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>" + +This ``From`` field is used by ``git am`` to recreate commits with the right +author name. The following will ensure that your e-mails have an additional +``From`` field at the beginning of the Email body, and therefore that +maintainers accepting your patches don't have to fix commit author information +manually:: + + git config --global sendemail.from "linus.torvalds@kernel.org" + +The ``sendemail.from`` should match your ``user.email`` setting, +which appears in the ``Signed-off-by`` line of your commits. + +Streamlining git send-email usage +--------------------------------- + +If you want to save time and not be forced to remember the right options to use +with ``git send-email``, you can use Git configuration settings. + +- To set the right mailing list address for a given repository:: + + git config --local sendemail.to openembedded-devel@lists.openembedded.org + +- If the mailing list requires a subject prefix for the layer + (this only works when the repository only contains one layer):: + + git config --local format.subjectprefix "meta-something][PATCH" + +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:`contributor-guide/submit-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>`__. + +#. *Request Push Access to an "Upstream" Contrib Repository:* Send an email to + ``helpdesk@yoctoproject.org``: + + - Attach your SSH public key which usually named ``id_rsa.pub.``. + If you don't have one generate it by running ``ssh-keygen -t rsa -b 4096 -C "your_email@example.com"``. + + - List the repositories you're planning to contribute to. + + - Include your preferred branch prefix for ``-contrib`` repositories. + +#. *Push Your Commits to the "Contrib" Upstream:* Push your + changes 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. + + - *Find the Mailing List to Use:* See the + ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`" + section above. + +#. *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 + +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:`contributor-guide/submit-changes:preparing changes for submission`" + and in the following sections 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 + "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use:: + + git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ... + +Taking Patch Review into Account +================================ + +You may get feedback on your submitted patches from other community members +or from the automated patchtest service. If issues are identified in your +patches then it is usually necessary to address these before the patches are +accepted into the project. In this case you should your commits according +to the feedback and submit an updated version to the relevant mailing list. + +In any case, never fix reported issues by fixing them in new commits +on the tip of your branch. Always come up with a new series of commits +without the reported issues. + +.. note:: + + It is a good idea to send a copy to the reviewers who provided feedback + to the previous version of the patch. You can make sure this happens + by adding a ``CC`` tag to the commit description:: + + CC: William Shakespeare <bill@yoctoproject.org> + +A single patch can be amended using ``git commit --amend``, and multiple +patches can be easily reworked and reordered through an interactive Git rebase:: + + git rebase -i <ref-branch> + +See `this tutorial <https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d>`__ +for practical guidance about using Git interactive rebasing. + +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:: + + git format-patch -v2 <ref-branch> + +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. + +Tracking the Status of Patches +============================== + +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. + +If your patches have not had any feedback in a few days, they may have already +been merged. You can run ``git pull`` branch to check this. Note that many if +not most layer maintainers do not send out acknowledgement emails when they +accept patches. Alternatively, if there is no response or merge after a few days +the patch may have been missed or the appropriate reviewers may not currently be +around. It is then perfectly fine to reply to it yourself with a reminder asking +for feedback. + +.. note:: + + Patch reviews for feature and recipe upgrade patches are likely be delayed + during a feature freeze because these types of patches aren't merged during + at that time --- you may have to wait until after the freeze is lifted. + +Maintainers also 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. + |