subtree updates openembedded poky
meta-openembedded: 491b7592f4..eff1b182c1:
Alejandro Hernandez Samaniego (1):
emacs: update to 29.1
Archana Polampalli (2):
python3-pyroute2: fix ptest failure
nodejs: upgrade 18.17.0 -> 18.17.1
Bartosz Golaszewski (1):
libgpiod: update to v2.0.2
Beniamin Sandu (3):
unbound: upgrade 1.17.1 -> 1.18.0
mbedtls: upgrade 3.4.0 -> 3.4.1
mbedtls: upgrade 2.28.3 -> 2.28.4
Benjamin Bara (3):
libvpx: fix VPXTARGET for non-neon armv7a
ne10: set incompatible for armv7 without neon
openh264: make neon optional and disable if not supported
Chaitanya Vadrevu (1):
bolt: Add recipe
Chen Qi (2):
spice-protocol: fix populate_sdk error when spice is installed
python3-blivetgui: switch from master to main
Christophe Vu-Brugier (1):
sg3-utils: upgrade 1.47 -> 1.48
Danik (2):
python3-gspread: interface for google spreadsheet
python3-piccata: piccata - a simple CoAP toolkit added
Denys Zagorui (1):
bpftool: add native and nativesdk support
Emil Kronborg Andersen (3):
lcms: add CVE_PRODUCT
snappy: add CVE_PRODUCT
libopus: add CVE_PRODUCT
Enrico Jorns (1):
microcom: add new recipe
Ewa Kujawska (1):
python3-oauth2client_4.1.2.bb: recipe added
Frieder Schrempf (1):
python3-can: Add missing runtime dependencies
Gianfranco Costamagna (1):
dlt-daemon: upgrade 2.18.9 -> 2.18.10 (commit: 0f2d4cfffada6f8448a2cb27995b38eb4271044f)
Joe Slater (1):
python3-inotify: fix tests
Justin Bronder (5):
python3-mypy-extensions: upgrade 0.4.3 -> 1.0.0
python3-types-setuptools: add 68.0.0.3
python3-typed-ast: remove EOL package
python3-types-psutil: add 5.9.5.16
python3-mypy: upgrade 0.971 -> 1.5.0
Kai Kang (1):
libmcrypt: fix multilib conflict
Khem Raj (31):
qad: Fix build with clang
python3-dominate: Fix get_thread_context ptest on musl
perfetto: Add SRCREV_FORMAT
gosu: Define SRCREV_FORMAT
libsdl2-ttf: Define SRCREV_FORMAT
gosu: Define SRCREV_FORMAT
sysdig: Add SRCREV_FORMAT
cockpit: Upgrade to 298 release
librelp: Fix function prototypes in tests
jemalloc: Unbolt clang workaroud
python3-protobuf: Fix build errors seen with clang
mariadb: Fix build with libfmt 10.1+
librelp: Add packageconfigs for TLS implementations
librelp: Fix ptests builds on musl
librelp: Fix ptest installs to work with dash
librelp: Add to meta-oe ptest image
liburing: Upgrade to 2.4 release
rsyslog: Enable openssl transport by default
libio-socket-ssl-perl: Upgrade to 2.083
libfaketime: Fix build with clang
libfaketime: Eanable LFS64 on musl
python3-lz4: Drop using PYTHON_PN
python3-lz4: Add missing rdeps needed for ptests
rsyslog: Skip failing omfile-outchannel test on musl
python3-m2crypto: Append architecture to SWIG_FEATURES instead of overriding
networkmanager: Fix build on musl
network-manager-applet: Fix build with musl/lld linker
networkmanager-openvpn: Fix build with lld on musl
openconnect: Upgrade to 9.12
openconnect: Fix build with GnuTLS v3.8.1
fontforge: Fix build with gettext 0.22
Kirk Hays (1):
jack: Drop dependency on readline
Leon Anavi (2):
aml: add new recipe
neatvnc: add new recipe
Marek Vasut (2):
libiio: Use tagged v0.25
libiio: Rename to versioned recipe filename
Marine Vovard (1):
python3-kivy: Require X11 or Wayland in DISTRO_FEATURES
Mark Hatle (1):
kconfig-frontends: Avoid using hard coded /usr/include paths
Markus Volk (28):
gvfs: update 1.51.1 -> 1.51.90
gnome-themes-extra: fix datadir path
libnice: add graphviz-native dependency
libcanberra: fix api-documentation build
libgweather4: fix api-documentation build
appstream: disable docs
gtksourceview5: fix api-documentation build
libpeas: fix api-documentation build
nautilus: fix api-documentation build
evince: fix api-documentation build
usbids: add recipe
libcacard: add recipe
usbredir: upgrade 0.9.0 -> 0.13.0
spice: upgrade 0.14.2 -> 0.15.2
gnome-remote-desktop: add recipe
libosinfo: add recipe
gnome-boxes: add recipe
pipewire: upgrade 0.3.77 -> 0.3.78
spice-gtk: fix api-documentation build
flatpak: fix api-documentation build
phodav: add recipe
libdecor: update to latest commit
spice-guest-vdagent: add recipe
pipewire: upgrade 0.3.78 -> 0.3.79
spice: add missing dependency on orc
spice-guest-vdagent: add missing dependencies
libosinfo: build vapi only if gobject-introspection is enabled
gnome-boxes: remove dependency on ovmf
Martin Jansa (12):
openh264: fix installed-vs-shared QA issue with multilib
libfaketime: simplify packaging
json-schema-validator: restore 0004-cmake-Use-GNUInstallDirs.patch
phodav: make sure systemd files are packaged correctly
sysbench: avoid -L/usr/lib32 and configure-unsafe QA issue
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
libiio: use main branch instead of master
webkitgtk: explicitly disable JIT for armv7* with softfp
layer.conf: update LAYERSERIES_COMPAT for nanbield
Ming Liu (1):
libusbgx: usbgx.service: use Type=oneshot
Mingli Yu (4):
mariadb: Upgrade to 10.11.5
dialog: Update the SRC_URI
gnulib: Update SRC_URI
thrift: Remove buildpaths
Nicolas Marguet (1):
librelp: add ptest
Parian Golchin (1):
json-schema-validator: Updrade to 2.2.0
Pawel Langowski (1):
qcbor: add recipe
Petr Chernikov (1):
Fix empty 0.0.0-0-g0 jemalloc version by adding --with-version
Petr Gotthard (1):
python3-sdbus: add recipe
Robert Yang (1):
frr: Fix CVE-2023-41358 and CVE-2023-41360
Roger Knecht (1):
python3-schedule: add recipe
Roland Hieber (1):
fbida: update Upstream-Status for submitted patches
Ross Burton (1):
Revert "protobuf: stage protoc binary to sysroot"
Soumya (1):
yasm: fix CVE-2023-37732
Soumya Sambu (1):
krb5: Upgrade 1.20.1 -> 1.20.2
Sourav Kumar Pramanik (1):
meta-oe-components: Avoid usage of nobranch=1
Sourav Pramanik (2):
rapidjson: Avoid usage of nobranch=1
nlohmann-json: Avoid usage of nobranch=1
Stanislav Angelovic (1):
feat: bump sdbus-c++ up to v1.3.0
Sudip Mukherjee (1):
qad: Add initial recipe
Trevor Gamblin (1):
python3-kivy: fix filename
Tymoteusz Burak (2):
ttf-google-fira: add recipe
libfaketime: add recipe
Vincent Davis Jr (1):
cglm: upgrade v0.8.9 -> v0.9.1
Wang Mingyu (108):
libcloudproviders: upgrade 0.3.1 -> 0.3.2
chrony: upgrade 4.3 -> 4.4
networkmanager: upgrade 1.42.8 -> 1.44.0
weechat: upgrade 4.0.2 -> 4.0.3
ctags: upgrade 6.0.20230730.0 -> 6.0.20230813.0
fmt: upgrade 10.0.0 -> 10.1.0
gensio: upgrade 2.6.7 -> 2.7.2
googletest: upgrade 1.13.0 -> 1.14.0
lvgl: upgrade 8.3.8 -> 8.3.9
postgresql: upgrade 15.3 -> 15.4
smartmontools: upgrade 7.3 -> 7.4
xdg-dbus-proxy: upgrade 0.1.4 -> 0.1.5
yaml-cpp: upgrade 0.7.0 -> 0.8.0
libtest-harness-perl: upgrade 3.44 -> 3.47
python3-alembic: upgrade 1.11.1 -> 1.11.2
python3-async-timeout: upgrade 4.0.2 -> 4.0.3
python3-bitarray: upgrade 2.8.0 -> 2.8.1
python3-cmake: upgrade 3.27.0 -> 3.27.2
python3-coverage: upgrade 7.2.7 -> 7.3.0
python3-dnspython: upgrade 2.4.1 -> 2.4.2
python3-google-api-python-client: upgrade 2.95.0 -> 2.96.0
python3-googleapis-common-protos: upgrade 1.59.1 -> 1.60.0
python3-joblib: upgrade 1.3.1 -> 1.3.2
python3-luma-oled: upgrade 3.12.0 -> 3.13.0
python3-platformdirs: upgrade 3.9.1 -> 3.10.0
python3-pycodestyle: upgrade 2.10.0 -> 2.11.0
python3-pyflakes: upgrade 3.0.1 -> 3.1.0
python3-pymisp: upgrade 2.4.173 -> 2.4.174
python3-rdflib: upgrade 6.3.2 -> 7.0.0
python3-regex: upgrade 2023.6.3 -> 2023.8.8
python3-rich: upgrade 13.4.2 -> 13.5.2
python3-sh: upgrade 2.0.4 -> 2.0.6
python3-tox: upgrade 4.6.4 -> 4.8.0
python3-tqdm: upgrade 4.65.0 -> 4.66.1
python3-uefi-firmware: upgrade 1.10 -> 1.11
python3-virtualenv: upgrade 20.24.2 -> 20.24.3
python3-web3: upgrade 6.7.0 -> 6.8.0
python3-yamlloader: upgrade 1.2.2 -> 1.3.2
python3-zeroconf: upgrade 0.71.4 -> 0.76.0
python3-protobuf: upgrade 4.23.4 -> 4.24.0
ctags: upgrade 6.0.20230813.0 -> 6.0.20230820.0
debootstrap: upgrade 1.0.128 -> 1.0.131
gensio: upgrade 2.7.2 -> 2.7.4
gnome-bluetooth: upgrade 42.5 -> 42.6
nginx: upgrade 1.25.1 -> 1.25.2
geary: update 44.0 -> 44.1
php: upgrade 8.2.8 -> 8.2.9
python3-redis: upgrade 4.6.0 -> 5.0.0
python3-alembic: upgrade 1.11.2 -> 1.11.3
python3-awesomeversion: upgrade 23.5.0 -> 23.8.0
python3-bitstring: upgrade 4.0.2 -> 4.1.0
python3-click: upgrade 8.1.6 -> 8.1.7
python3-engineio: upgrade 4.5.1 -> 4.6.0
python3-google-api-python-client: upgrade 2.96.0 -> 2.97.0
python3-humanize: upgrade 4.7.0 -> 4.8.0
python3-mypy: upgrade 1.5.0 -> 1.5.1
python3-oauth2client: upgrade 4.1.2 -> 4.1.3
python3-protobuf: upgrade 4.24.0 -> 4.24.1
python3-pycocotools: upgrade 2.0.6 -> 2.0.7
python3-pymetno: upgrade 0.10.0 -> 0.11.0
python3-pymongo: upgrade 4.4.1 -> 4.5.0
python3-pywbem: upgrade 1.6.1 -> 1.6.2
python3-sqlalchemy: upgrade 2.0.19 -> 2.0.20
python3-tox: upgrade 4.8.0 -> 4.10.0
python3-typeguard: upgrade 4.1.0 -> 4.1.2
python3-types-setuptools: upgrade 68.0.0.3 -> 68.1.0.0
python3-zeroconf: upgrade 0.76.0 -> 0.82.1
redis: upgrade 7.0.12 -> 7.2.0
weechat: upgrade 4.0.3 -> 4.0.4
traceroute: upgrade 2.1.2 -> 2.1.3
wireshark: upgrade 4.0.7 -> 4.0.8
adw-gtk3: upgrade 4.8 -> 4.9
ctags: upgrade 6.0.20230820.0 -> 6.0.20230827.0
debootstrap: upgrade 1.0.131 -> 1.0.132
dialog: upgrade 1.3-20210509 -> 1.3-20230209
fmt: upgrade 10.1.0 -> 10.1.1
gensio: upgrade 2.7.4 -> 2.7.5
iwd: upgrade 2.7 -> 2.8
libgphoto2: upgrade 2.5.30 -> 2.5.31
libzip: upgrade 1.10.0 -> 1.10.1
logwatch: upgrade 7.8 -> 7.9
thrift: upgrade 0.18.1 -> 0.19.0
libnet-dns-perl: upgrade 1.39 -> 1.40
python3-alembic: upgrade 1.11.3 -> 1.12.0
python3-argh: upgrade 0.28.1 -> 0.29.3
python3-asttokens: upgrade 2.2.1 -> 2.4.0
python3-bitstring: upgrade 4.1.0 -> 4.1.1
python3-cmake: upgrade 3.27.2 -> 3.27.4.1
python3-diskcache: upgrade 5.6.1 -> 5.6.3
python3-engineio: upgrade 4.6.0 -> 4.7.0
python3-imageio: upgrade 2.31.1 -> 2.31.3
python3-ipython: upgrade 8.14.0 -> 8.15.0
python3-kiwisolver: upgrade 1.4.4 -> 1.4.5
python3-langtable: upgrade 0.0.62 -> 0.0.63
python3-luma-core: upgrade 2.4.0 -> 2.4.1
python3-protobuf: upgrade 4.24.1 -> 4.24.2
python3-pymisp: upgrade 2.4.174 -> 2.4.175
python3-pymodbus: upgrade 3.4.1 -> 3.5.0
python3-smbus2: upgrade 0.4.2 -> 0.4.3
python3-snagboot: upgrade 1.1 -> 1.2
python3-socketio: upgrade 5.8.0 -> 5.9.0
python3-soupsieve: upgrade 2.4.1 -> 2.5
python3-tox: upgrade 4.10.0 -> 4.11.1
python3-typeguard: upgrade 4.1.2 -> 4.1.3
python3-types-setuptools: upgrade 68.1.0.0 -> 68.1.0.1
python3-virtualenv: upgrade 20.24.3 -> 20.24.4
python3-web3: upgrade 6.8.0 -> 6.9.0
python3-zeroconf: upgrade 0.82.1 -> 0.97.0
Willy Tu (1):
abseil-cpp: upgrade 20230125.3 -> 20230802.0
Yi Zhao (7):
nftables: upgrade 1.0.7 -> 1.0.8
libssh: upgrade 0.10.4 -> 0.10.5
samba: upgrade 4.18.5 -> 4.18.6
libyang: upgrade 2.1.55 -> 2.1.111
frr: Security fix CVE-2023-3748
vsomeip: add recipe
ntp: add missing runtime dependencies
Yogita Urade (2):
poppler: fix CVE-2023-34872
hwloc: fix CVE-2022-47022
Βούλγαρη Αικατερίνη (1):
collectd: build with rrdcached plugin
poky: 71282bbc53..61531cd395:
Adrian Freihofer (2):
cmake.bbclass: cleanup spaces and tabs
cmake.bbclass: refactor cmake args
Alberto Planas (1):
bitbake.conf: add bunzip2 in HOSTTOOLS
Alexander Kanavin (18):
lib/oe/recipeutils.py: accommodate SRCPV being optional and deprecated in version check regex
python3-sphinx: correct version check
systemd-bootchart: musl fixes have been rejected upstream
openssl: build and install manpages only if they are enabled
gettext: upgrade 0.21.1 -> 0.22
connman: update 1.41 -> 1.42
libcgroup: update 3.0.0 -> 3.1.0
perlcross: update 1.4.1 -> 1.5
perl: update 5.36.1 -> 5.38.0
groff: update 1.22.4 -> 1.23.0
libglu: update 9.0.2 -> 9.0.3
libpthread-stubs: update 0.4 -> 0.5
gpgme: upgrade 1.20.0 -> 1.22.0
libgudev: upgrade 237 -> 238
gnupg: upgrade 2.4.2 -> 2.4.3
gnutls: update 3.8.0 -> 3.8.1
runqemu: check permissions of available render nodes as well as their presence
build-sysroots: target or native sysroot population need to be selected explicitly
Alexis Lothoré (7):
oeqa/utils/gitarchive: fix tag computation when creating archive
oeqa/selftest: introduce gitarchive tests
oeqa/utils/gitarchive: fix tag computation when creating archive
oeqa/selftest/gitarchive: add tests about tags lisiting when no remote is configured
oeqa/utils/gitarchive: allow to pass a logger to get_tags
oeqa/utils/gitarchive: fall back to local tags when listing existing tags
oeqa/utils/gitarchive: replace warning with info when reading local tags
Angelo Ribeiro (1):
ccache.bbclass: Add allowed list for native recipes
Anuj Mittal (3):
gstreamer1.0: upgrade 1.22.4 -> 1.22.5
harfbuzz: upgrade 8.0.1 -> 8.1.1
stress-ng: upgrade 0.15.08 -> 0.16.04
Archana Polampalli (1):
vim: upgrade 9.0.1592 -> 9.0.1664
Benjamin Bara (6):
rust-target-config: fix target_features for vfpv3d16
README: fix mail address in git example command
pixman: avoid neon on unsupported machines
nettle: avoid neon on unsupported machines
ffmpeg: avoid neon on unsupported machines
ghostscript: avoid neon on unsupported machines
Bruce Ashfield (19):
conf/machine: set preferred kernel to be 6.4
poky/poky-tiny: set preferred linux-yocto version to 6.4
linux-yocto/6.1: update to v6.1.44
linux-yocto/6.4: update to v6.4.10
linux-yocto/6.1: update to v6.1.45
kern-tools: include utility to post process config diffs
linux-yocto/6.1: fix uninitialized read in nohz_full/isolcpus setup
linux-yocto/6.4: fix uninitialized read in nohz_full/isolcpus setup
linux-yocto/6.4: update to v6.4.11
linux-yocto/6.1: update to v6.1.46
linux-yocto/6.1: fix IRQ-80 warnings
linux-yocto/6.4: fix IRQ-80 warnings
linux-yocto/6.4: fix CONFIG_F2FS_IO_TRACE configuration warning
linux-yocto/6.1: fix CONFIG_F2FS_IO_TRACE configuration warning
linux-yocto/6.4: update to v6.4.12
linux-yocto/6.1: update to v6.1.50
linux-yocto/6.4: update to v6.4.13
linux-yocto/6.4: update to v6.4.14
linux-yocto/6.1: update to v6.1.51
Changqing Li (1):
sqlite3: set CVE_STATUS for CVE-2023-36191
Chen Qi (6):
bitbake: runqueue.py: fix PSI check logic
cmake: drop OE specific environment variable support
cmake.bbclass: fix allarch override syntax
uninative.bbclass: sync to use UNINATIVE_STAGING_DIR
stress-ng: disable DEBUG_BUILD
oe-depends-dot: improve '-w' behavior
Daniel Semkowicz (1):
dev-manual: wic.rst: Update native tools build command
David Reyna (3):
bitbake: toaster: Update to Django 4.2
bitbake: toaster: import only used layers
bitbake: toaster: accommodate missing 'Image Name' value in buildinfohelper
Dmitry Baryshkov (4):
mdadm: disable strace on rv32 arch
linux-firmware: upgrade 20230625 -> 20230804
linux-firmware: package audio topology for Lenovo X13s
linux-firmware: package Dragonboard 845c sensors DSP firmware
Eilís 'pidge' Ní Fhlannagáin (1):
nativesdk-intercept: Fix bad intercept chgrp/chown logic
Emil Ekmečić (2):
bitbake: fetch2: add Google Cloud Platform (GCP) fetcher
Add GCP fetcher to list of supported protocols
Emil Kronborg Andersen (2):
dbus: add additional entries to CVE_PRODUCT
libxkbcommon: add CVE_PRODUCT
Etienne Cordonnier (2):
vim: update obsolete comment
migration-guides: system-conf -> systemd-conf
Frederic Martinsons (5):
rust: add cargo-c native recipe
classes-recipe: add cargo_c.bbclass
rust: provide examples for C library generation in rust
oeqa/runtime/rust: correct rust test
ref-manual: classes.rst: suppress rust-hello-world reference, add ptest-cargo class
Jaeyoon Jung (1):
cml1: Fix KCONFIG_CONFIG_COMMAND not conveyed fully in do_menuconfig
Jasper Orschulko (1):
cve_check: Fix cpe_id generation
Joe Slater (1):
file: fix call to localtime_r()
Jon Mason (1):
linux-yocto-dev: correct qemuarmv5 device tree location
Jose Quaresma (3):
systemd: fix efi dependency
systemd-boot: remove old gummiboot TUNE_CCARGS
pybootchartgui: also match do_compile and do_configure subtasks
Joshua Watt (9):
bitbake: bblayers/query: Add multiconfig support to `show-appends`
bitbake: cooker: Fix error message
bitbake: lib/bb: Add xattr and acl libraries
buildtools-tarball: Add libacl
classes/image_types: Add vfat image type
bitbake: fetch2: git: Check if clone directory is a git repo
wic: Add gpt-hybrid partition layout
bitbake: fetch2: git: Remove useless try..else clause
Add libacl to required packages
Julien Stephan (4):
less: upgrade 633 -> 643
less: add ptest support
patch.py: use --absolute-git-dir instead of --show-toplevel to retrieve gitdir
vulkan-samples: convert debugfix.patch to git format patch
Kai Kang (1):
webkitgtk: fix build failure with DEBUG_BUILD enabled
Khem Raj (22):
gnu-efi: Fix build on musl
systemd-boot: Fix build on musl
glibc: Upgrade to 2.38 release
glibc: Enable fortify sources by defaults
glibc: Drop --enable-tunables
glibc: Fix SVE detection on aarch64
glibc-tests: Add missing libgcc runtime dependency
kernel.bbclass: Use KERNEL_STRIP instead of STRIP
build-sysroots: Add SUMMARY field
tunes: Add support for sve instructions on armv8/armv9
arch-armv8,arch-armv9: Add sve based tune options
python3: Increase default thread stack size on musl
inetutils: Fix CVE-2023-40303
inetutils: Apply devtool formatting suggestions
qemu: Fix CVE-2023-40360
core-image-ptest: Define a fallback for SUMMARY field
dos2unix: upgrade 7.5.0 -> 7.5.1
python3: Fix ptests on musl
tcl: Add a way to skip ptests
rust-target-config: Map rust target to OE target
libc-test: Depend on musl-staticdev
apr: Fix ptests on musl
Lee Chee Yang (2):
migration-guides: add release notes for 4.2.3
migration-guides: add release notes for 4.0.12
Lei Maohui (1):
glibc-package: Fix conflict error when enable multilib.
Luan Rafael Carneiro (2):
weston: Upgrade version 12.0.1 -> 12.0.2
weston: Add sysconfdir to FILES:${PN}
Luca Ceresoli (1):
Revert "oeqa/runtime/parselogs: Exclude preempt-rt error for now"
Markus Niebel (2):
wic: fix wrong attempt to create file system in upartitioned regions
oeqa: wic: Add test for --no-table option
Markus Volk (8):
gtk4: upgrade 4.10.4 -> 4.10.5
libadwaita: upgrade 1.3.3 -> 1.3.4
gtk4: upgrade 4.10.5 -> 4.12.0
qemu: fix libudev packageconfig for systemd images
qemu: build pulseaudio support depending on distro_feature
qemu: add packageconfigs for fuse and dbus-display
gtk4: upgrade 4.12.0 -> 4.12.1
mesa: add intel raytracing support to opencl build
Martin Jansa (6):
tcl: prevent installing another copy of tzdata
cross-localedef-native: fix build on hosts with older glibc
bitbake: runqueue: show more pressure data
Makefile: remove from top-level directory
bitbake: runqueue: show number of currently running bitbake threads when pressure changes
webkitgtk: explicitly disable JIT for armv7* with softfp
Michael Halstead (2):
yocto-uninative: Update to 4.2 for glibc 2.38
yocto-uninative: Update to 4.3
Michael Opdenacker (26):
scripts/create-pull-request: update URLs to git repositories
manuals: create a dedicated "Contributor Guide" document
ref-manual: classes.rst: fix location of _ref-classes-ccache
ref-manual: update supported distro versions
contributor-guide: add missing links to mailing lists
contributor-guide: add section about why we use mailing lists
contributor-guide: add recipe style guide
ref-manual: remove AUTHOR variable
contributor guide: call section "Reporting a defect"
contributor-guide: remove obsolete pkg-config guidelines
contributor guide: remove unnecessary information about mailing lists
contributor-guide: clarification about patchtest
contributor guide: update instructions for making and sharing changes
dev-manual: disk-space: mention faster "find" command to trim sstate cache
contributor-guide: move to 2nd place in top menu
contributor-guide: submit-changes: simplify note
contributor-guide: identify component: provide link to repositories
contributor-guide: submit-changes: detail commit and patch creation
contributor-guide: submit-changes: develop sending patches section
manuals: README: update list of manuals
contributor-guide: submit-changes: reorganize and develop sections
contributor-guide: submit-changes: improvements to mailing lists section
contributor-guide: submit-changes: commit guidelines for recipes
contributor-guide: submit-changes: how to request push access to repositories
README: update/fix contribution guidelines
bitbake: doc: bitbake-user-manual: remove reference to SSTATE_MIRRORS variable
Mikko Rapeli (4):
openssh: capture ptest regression test failure logs
oeqa selftest context.py: whitespace fix
oeqa selftest context.py: remove warning from missing meta-selftest
oeqa selftest context.py: fix git commands and set branch name
Mingli Yu (2):
qemu: Add qemu-common package
webkitgtk: Add opengl to REQUIRED_DISTRO_FEATURES
Narpat Mali (1):
ffmpeg: add CVE_STATUS for CVE-2023-39018
Otavio Salvador (2):
weston-init: remove misleading comment about udev rule
weston-init: fix init code indentation
Ovidiu Panait (1):
mdadm: skip running 04update-uuid and 07revert-inplace testcases
Paulo Neves (1):
bitbake: siggen.py: Improve taskhash reproducibility
Peter Kjellerstedt (3):
bin_package.bbclass: Inhibit the default dependencies
insane.bbclass: Remove an unused variable
poky.conf: Switch to post release name/version
Peter Marko (2):
openssl: Upgrade 3.1.1 -> 3.1.2
gcc-runtime: remove bashism
Poonam Jadhav (1):
pixman: Remove duplication of license MIT
Randolph Sapp (1):
bitbake: gitsm: tolerate git-lfs in submodules
Richard Purdie (39):
bitbake: siggen: Fix indentation
bitbake: siggen: Update debug
resulttool/report: Avoid divide by zero
gcc-testsuite: Fix qemu binary filtering code logic error
gcc-testsuite: Set qemu options for mips correctly
mips/tune-mips64r2: Set qemu cpu option correctly
binutils-cross-testsuite: Pass TUNE_LDARGS to tests
arch-mips: Ensure TUNE_LDARGS is set correctly
gcc: Add patch to improve testsuite failures, particularly mips
oeqa/runtime/parselogs: Exclude preempt-rt error for now
qemu: Upgrade 8.0.3 -> 8.0.4
lib/package_manager: Improve repo artefact filtering
Revert "oeqa/utils/gitarchive: fix tag computation when creating archive"
lttng-modules: Upgrade 2.13.9 -> 2.13.10
lttng-tools: Upgrade 2.13.9 -> 2.13.10
pseudo: Fix to work with glibc 2.38
binutils: Add missing DEPENDS on pod2man
build-sysroots: Ensure dependency chains are minimal
bitbake: fetch2: Add new srcrev fetcher API
base/package: Move source revision information from PV to PKGV
recipes/classes/scripts: Drop SRCPV usage in OE-Core
glibc: Add glibc 2.38 stable updates
README: Update to point to new contributor guide
bitbake: README: Update to point to new contributor guide
bitbake: command: Avoid time intensive distractions for ping
README: Clarify/standardise contributions process
python3-numpy: Attempt to fix reproducibility issue
bitbake: doc: Document challenges of tags with git fetcher
bitbake: server/process: Add more timing debug
qemu: Upgrade 8.0.4 -> 8.1.0
qemu: Add patches to resolve x86 and then mips boot issues
mdadm: Disable further tests due to intermittent failures
Revert "oeqa selftest context.py: fix git commands and set branch name"
classes: Drop ';' delimiter from ROOTFS/IMAGE*COMMAND variables
build-appliance-image: Update to master head revision
layer.conf: Update to nanbield release series
bitbake: bitbake: Update to 2.6.0 release series/version
layer.conf: Update to nanbield release series
build-appliance-image: Update to master head revision
Ross Burton (47):
connman-conf: don't take over any ethernet devices, not just eth0
meson.bbclass: add MESON_TARGET
meson.bbclass:: update do_write_config vardeps
systemd-boot: use MESON_TARGET
systemd-boot: improve cross file generation
p11-kit: fix build without qemu-usermode
gi-docgen: depend on qemu-usermode MACHINE_FEATURES
python3-pygobject: add explicit check for qemu-usermode MACHINE_FEATURE
graphene: fix runtime detection of IEEE754 behaviour
python3: ignore disputed CVE-2023-36632
procps: backport fix for CVE-2023-4016
linux/generate-cve-exclusions.py: fix comparison
linux/cve-exclusions: update CVE_STATUS exclusions
perf: enable verbose feature detection
perf: add more PACKAGECONFIGs
perf: fix perl binding support
perf: split scripting PACKAGECONFIG into perl and python
perf: disable perl support
libtraceevent: build with Meson
linux/generate-cve-exclusions: add version check warning
linux-yocto: update CVE exclusions files
site: remove at-spi2-core values
inetutils: don't guess target paths
inetutils: remove obsolete patches
inetutils: remove obsolete cruft from do_configure
glib-networking: enable build with GnuTLS if PKCS#11 was disabled
glib-networking: use gnutls backend for TLS sockets
cve-extra-exclusions: remove historic kernel CVEs which are handled now
cve-extra-exclusions: remove BlueZ issues
linux-yocto: update kernel CVE status
linux: review some historic CVE_STATUS
glib-2.0: explicitly enable strlcpy()
scripts/oe-find-native-sysroot: use bitbake-getvar
qemu-system-native: enable PNG support
python3-build: upgrade to 1.0.0
glib-2.0: libelf has a configure option now, specify it
harfbuzz: update PACKAGECONFIG
pango: explictly enable/disable libthai
libsoup-2.4: update PACKAGECONFIG
libsoup: update PACKAGECONFIG
wayland-utils: add libdrm PACKAGECONFIG
cve-exclusion: review the last of the historical kernel CVEs
busybox: remove coreutils dependency in busybox-ptest
libgudev: explicitly disable tests and vapi
linux: update CVE exclusions
python3-build: upgrade to 1.0.3
avahi: handle invalid service types gracefully
Ryan Eatmon (1):
kernel.bbclass: Add force flag to rm calls
Samantha Jalabert (1):
bitbake: Fix disk space monitoring on cephfs
Stéphane Veyret (1):
nfs-utils: Add needed library to client
Sudip Mukherjee (4):
kea: upgrade to v2.4.0
cmake: upgrade to v3.27.4
dpkg: upgrade to v1.22.0
openssh: upgrade to v9.4p1
Tom Hochstein (1):
linux-firmware: add firmware files for NXP BT chipsets
Trevor Gamblin (16):
python3-hypothesis: upgrade 6.82.0 -> 6.82.5
python3-more-itertools: upgrade 10.0.0 -> 10.1.0
python3-pygments: upgrade 2.15.1 -> 2.16.1
python3-wheel: upgrade 0.41.0 -> 0.41.1
maintainers.inc: Add self for unmaintained Python recipes
oe-buildenv-internal: update required Python version
python3-dbusmock: upgrade 0.29.0 -> 0.29.1
python3-numpy: upgrade 1.25.1 -> 1.25.2
python3-trove-classfiers: upgrade 2023.7.6 -> 2023.8.7
python3-setuptools: upgrade 68.0.0 -> 68.1.0
python3-dtc: upgrade 1.6.1 -> 1.7.0
python3-poetry: upgrade 1.6.1 -> 1.7.0
python3-git: upgrade 3.1.32 -> 3.1.34
python3-hypothesis: upgrade 6.82.7 -> 6.84.0
python3-pytest: upgrade 7.4.0 -> 7.4.1
python3-sphinx: upgrade 7.1.1 -> 7.2.5
Ulrich Ölmann (1):
weston: fix comment
Wang Mingyu (47):
btrfs-tools: upgrade 6.3.1 -> 6.3.3
curl: upgrade 8.2.0 -> 8.2.1
file: upgrade 5.44 -> 5.45
gmp: upgrade 6.2.1 -> 6.3.0
xxhash: upgrade 0.8.1 -> 0.8.2
python3-editables: upgrade 0.4 -> 0.5
python3-markdown: upgrade 3.4.3 -> 3.4.4
python3-pathspec: upgrade 0.11.1 -> 0.11.2
python3-pip: upgrade 23.2 -> 23.2.1
python3-pyparsing: upgrade 3.1.0 -> 3.1.1
re2c: upgrade 3.0 -> 3.1
shaderc: upgrade 2023.4 -> 2023.5
sudo: upgrade 1.9.14p2 -> 1.9.14p3
libarchive: upgrade 3.6.2 -> 3.7.1
tar: upgrade 1.34 -> 1.35
bind: upgrade 9.18.17 -> 9.18.18
bluez5: upgrade 5.68 -> 5.69
ell: upgrade 0.57 -> 0.58
git: upgrade 2.41.0 -> 2.42.0
kbd: upgrade 2.6.1 -> 2.6.2
libconvert-asn1-perl: upgrade 0.33 -> 0.34
libdrm: upgrade 2.4.115 -> 2.4.116
libedit: upgrade 20221030-3.1 -> 20230828-3.1
libgit2: upgrade 1.7.0 -> 1.7.1
librepo: upgrade 1.15.1 -> 1.15.2
libsecret: upgrade 0.20.5 -> 0.21.0
libsndfile1: upgrade 1.2.0 -> 1.2.2
libxml2: upgrade 2.11.4 -> 2.11.5
mc: upgrade 4.8.29 -> 4.8.30
mpfr: upgrade 4.2.0 -> 4.2.1
neard: upgrade 0.18 -> 0.19
python3: upgrade 3.11.4 -> 3.11.5
pango: upgrade 1.50.14 -> 1.51.0
pigz: upgrade 2.7 -> 2.8
pkgconf: upgrade 1.9.5 -> 2.0.2
python3-setuptools: upgrade 68.1.0 -> 68.1.2
repo: upgrade 2.35 -> 2.36.1
shaderc: upgrade 2023.5 -> 2023.6
sqlite3: upgrade 3.42.0 -> 3.43.0
sysklogd: upgrade 2.5.0 -> 2.5.2
xz: upgrade 5.4.3 -> 5.4.4
zlib: upgrade 1.2.13 -> 1.3
python3-hypothesis: upgrade 6.82.5 -> 6.82.7
python3-pluggy: upgrade 1.2.0 -> 1.3.0
python3-sphinx-rtd-theme: upgrade 1.2.2 -> 1.3.0
python3-wheel: upgrade 0.41.1 -> 0.41.2
librepo: upgrade 1.15.2 -> 1.16.0
Yang Xu (1):
meson: don't fail if no .pyc exists
Yi Zhao (2):
dhcpcd: upgrade 10.0.1 -> 10.0.2
dhcpcd: fix buffer overflow
Yoann Congal (1):
dev-manual: remove unsupported :term: markup inside markup
Yogita Urade (1):
dropbear: fix CVE-2023-36328
Yuta Hayama (3):
linux/generate-cve-exclusions: print the generated time in UTC
linux/generate-cve-exclusions: fix mishandling of boundary values
linux-yocto: correct the wording in CVE_STATUS
Zang Ruochen (6):
tcf-agent: Disable non-building features on loongarch64
gcc-sanitizers: Add loongarch as a compatible architecture.
goarch.bbclass: Add loongarch64 to go_map_arch
qemuloongarch.inc:Change to use virtio-serial-pci
kernel-devsrc: Fixed missing loongarch64 kernel source code when test_kernelmodules
gcc: Fresh 0003-64-bit-multilib-hack.patch to add loongarch64 support
Change-Id: I4d4752539711b34471002dd1817bb7c14a590675
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
diff --git a/poky/documentation/contributor-guide/submit-changes.rst b/poky/documentation/contributor-guide/submit-changes.rst
new file mode 100644
index 0000000..cda2d12
--- /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.
+