[OE-core] [PATCH] Revert "libical: Pass TOOLCHAIN_OPTIONS via CFLAGS"

[Khem Raj]

This reverts commit feb8893e0f52c7ab2d5efd456901a2bb91839d44.
---
 meta/recipes-support/libical/libical_3.0.14.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta/recipes-support/libical/libical_3.0.14.bb 
b/meta/recipes-support/libical/libical_3.0.14.bb
index af8bc59dae3..58baf3f32f7 100644
--- a/meta/recipes-support/libical/libical_3.0.14.bb
+++ b/meta/recipes-support/libical/libical_3.0.14.bb
@@ -20,8 +20,6 @@ UPSTREAM_CHECK_URI = 
"https://github.com/libical/libical/releases;
 
 inherit cmake pkgconfig gobject-introspection vala
 
-CFLAGS += "${TOOLCHAIN_OPTIONS}"
-
 DEPENDS += "libical-native"
 
 PACKAGECONFIG ??= "icu glib"
-- 
2.35.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162776): 
https://lists.openembedded.org/g/openembedded-core/message/162776
Mute This Topic: https://lists.openembedded.org/mt/89563550/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 3/3] pip_install_wheel: clean up

[Khem Raj]

This is causing some install failures in meta-openembedded see
last five recipes in this batch

https://errors.yoctoproject.org/Errors/Details/651080/
https://errors.yoctoproject.org/Errors/Details/651082/
https://errors.yoctoproject.org/Errors/Details/651083/
https://errors.yoctoproject.org/Errors/Details/651084/
https://errors.yoctoproject.org/Errors/Details/651085/

These are the same failures across architectures and libcs.



On Fri, Mar 4, 2022 at 9:14 AM Ross Burton  wrote:
>
> There's been a lot of work in this class lately, so a little spring
> cleaning is needed.
>
> Remove redundant creation of PYTHON_SITEPACKAGES_DIR, pip will do that.
>
> Remove redundant export of PYPA_WHEEL.
>
> Simplyify recompile code using "realpath --relative-to".
>
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/pip_install_wheel.bbclass | 15 +++
>  1 file changed, 3 insertions(+), 12 deletions(-)
>
> diff --git a/meta/classes/pip_install_wheel.bbclass 
> b/meta/classes/pip_install_wheel.bbclass
> index 3beff685bb..1870b916fe 100644
> --- a/meta/classes/pip_install_wheel.bbclass
> +++ b/meta/classes/pip_install_wheel.bbclass
> @@ -20,29 +20,20 @@ PIP_INSTALL_ARGS ?= "\
>  --prefix=${prefix} \
>  "
>
> -pip_install_wheel_do_install:prepend () {
> -install -d ${D}${PYTHON_SITEPACKAGES_DIR}
> -}
> -
> -export PYPA_WHEEL
> -
>  PIP_INSTALL_PYTHON = "python3"
>  PIP_INSTALL_PYTHON:class-native = "nativepython3"
>
>  pip_install_wheel_do_install () {
>  nativepython3 -m pip install ${PIP_INSTALL_ARGS} ${PYPA_WHEEL} ||
> -bbfatal_log "Failed to pip install wheel. Check the logs."
> +  bbfatal_log "Failed to pip install wheel. Check the logs."
>
> +cd ${D}
>  for i in ${D}${bindir}/* ${D}${sbindir}/*; do
>  if [ -f "$i" ]; then
>  sed -i -e "1s,#!.*nativepython3,#!${USRBINPATH}/env 
> ${PIP_INSTALL_PYTHON}," $i
>  sed -i -e "s:${PYTHON}:${USRBINPATH}/env\ 
> ${PIP_INSTALL_PYTHON}:g" $i
>  sed -i -e "s:${STAGING_BINDIR_NATIVE}:${bindir}:g" $i
> -# Recompile after modifying it
> -cd ${D}
> -file=`echo $i | sed 's:^${D}/::'`
> -${STAGING_BINDIR_NATIVE}/python3-native/python3 -c "from 
> py_compile import compile; compile('$file')"
> -cd -
> +nativepython3 -mpy_compile $(realpath --relative-to=${D} $i)
>  fi
>  done
>  }
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162775): 
https://lists.openembedded.org/g/openembedded-core/message/162775
Mute This Topic: https://lists.openembedded.org/mt/89553658/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 9/9] linux-yocto/5.15: riscv32: drop MAXPHYSMEM_1GB

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/.:

ea948a0983d riscv32: drop MAXPHYSMEM_128GB

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 153e48b578..ebd811c7bd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "d6781443bac8b711a2c55898223dab38f2ed5896"
-SRCREV_meta ?= "3249e3a8f9c0de4105f5cd410880d5efdeeaf75d"
+SRCREV_meta ?= "ea948a0983d7b7820814e5bce4eda3079201bd95"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index d4ec34beff..244b907cd8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine:qemuarm ?= "000e76cff61c46e4a89c253d499bb92433807196"
 SRCREV_machine ?= "ba4a30c056f9fbb4286f9a79cd574025bae86c8f"
-SRCREV_meta ?= "3249e3a8f9c0de4105f5cd410880d5efdeeaf75d"
+SRCREV_meta ?= "ea948a0983d7b7820814e5bce4eda3079201bd95"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 481cfe9ab5..b9715e71ee 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"5bd4bda819e9c9736b3ab14e9295b8166c61b6a4"
 SRCREV_machine:qemux86-64 ?= "5bd4bda819e9c9736b3ab14e9295b8166c61b6a4"
 SRCREV_machine:qemumips64 ?= "98e983921ddecb99fe11439c033273b90cc5d413"
 SRCREV_machine ?= "5bd4bda819e9c9736b3ab14e9295b8166c61b6a4"
-SRCREV_meta ?= "3249e3a8f9c0de4105f5cd410880d5efdeeaf75d"
+SRCREV_meta ?= "ea948a0983d7b7820814e5bce4eda3079201bd95"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162774): 
https://lists.openembedded.org/g/openembedded-core/message/162774
Mute This Topic: https://lists.openembedded.org/mt/89563153/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 8/9] linux-yocto/5.10: update to v5.10.103

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

915a747ac7f3 Linux 5.10.103
78706b051a8a memblock: use kfree() to release kmalloced memblock regions
4185b788d3ad gpio: tegra186: Fix chip_data type confusion
bb2e0a77235a tty: n_gsm: fix deadlock in gsmtty_open()
e4c8cb95d035 tty: n_gsm: fix wrong tty control line for flow control
1f0641dd0b6c tty: n_gsm: fix NULL pointer access due to DLCI release
1e35cb9e1271 tty: n_gsm: fix proper link termination after failed open
90b47e617fb2 tty: n_gsm: fix encoding of control signal octet bit DV
9e2dbc31e367 riscv: fix oops caused by irqsoff latency tracer
e098933866f9 thermal: int340x: fix memory leak in int3400_notify()
5b1cef5798b4 RDMA/cma: Do not change route.addr.src_addr outside state 
checks
8fe4da55246a driver core: Free DMA range map when device is released
214824764308 xhci: Prevent futile URB re-submissions due to incorrect 
return value.
0b0a229da1f2 xhci: re-initialize the HC during resume if HCE was set
328faee6d409 usb: dwc3: gadget: Let the interrupt handler disable bottom 
halves.
e57bdee8661e usb: dwc3: pci: Fix Bay Trail phy GPIO mappings
99b2425d9178 usb: dwc2: drd: fix soft connect when gadget is unconfigured
c7866880377b USB: serial: option: add Telit LE910R1 compositions
220ba174f192 USB: serial: option: add support for DW5829e
3a1dd56e566f tracefs: Set the group ownership in apply_options() not 
parse_options()
bfa8ffbf USB: gadget: validate endpoint index for xilinx udc
4ce247af3f30 usb: gadget: rndis: add spinlock for rndis response list
ddc254fc8873 Revert "USB: serial: ch341: add new Product ID for CH341A"
d3fce1b6bd95 ata: pata_hpt37x: disable primary channel on HPT371
18701d8afaa1 sc16is7xx: Fix for incorrect data being transmitted
d5ddd7343adf iio: Fix error handling for PM
eabcc609cb8a iio: imu: st_lsm6dsx: wait for settling time in 
st_lsm6dsx_read_oneshot
b8d411a96227 iio: adc: ad7124: fix mask used for setting AIN_BUFP & 
AIN_BUFM bits
1aa12ecfdcba iio: adc: men_z188_adc: Fix a resource leak in an error 
handling path
afbeee13beb5 tracing: Have traceon and traceoff trigger honor the instance
99eb8d694174 RDMA/ib_srp: Fix a deadlock
a7ab53d3c27d configfs: fix a race in configfs_{,un}register_subsystem()
0ecd3e35d78e RDMA/rtrs-clt: Move free_permit from free_clt to rtrs_clt_close
b0ecf9e59414 RDMA/rtrs-clt: Kill wait_for_inflight_permits
8260f1800f83 RDMA/rtrs-clt: Fix possible double free in error case
dc64aa4c7dc0 regmap-irq: Update interrupt clear register for proper reset
2efece1368ae spi: spi-zynq-qspi: Fix a NULL pointer dereference in 
zynq_qspi_exec_mem_op()
67819b983eb3 net/mlx5e: kTLS, Use CHECKSUM_UNNECESSARY for device-offloaded 
packets
be55d3e76c0e net/mlx5: Fix wrong limitation of metadata match on ecpf
8d617110d78e net/mlx5: Fix possible deadlock on rule deletion
1c5912895545 udp_tunnel: Fix end of loop test in udp_tunnel_nic_unregister()
a184f4dd9b33 surface: surface3_power: Fix battery readings on batteries 
without a serial number
91f56a85278e net/smc: Use a mutex for locking "struct smc_pnettable"
7e9880e81d3f netfilter: nf_tables: fix memory leak during stateful obj 
update
af4bc921d39d nfp: flower: Fix a potential leak in 
nfp_tunnel_add_shared_mac()
58a6d5f24f49 net: Force inlining of checksum functions in net/checksum.h
550d98ab3007 net: ll_temac: check the return value of devm_kmalloc()
0fc184735996 net/sched: act_ct: Fix flow table lookup after ct clear or 
switching zones
bc8f768af342 net/mlx5e: Fix wrong return value on ioctl EEPROM query failure
fd020eaaa24a drm/edid: Always set RGB444
1df9d552fe84 openvswitch: Fix setting ipv6 fields causing hw csum failure
dac2490d9ee0 gso: do not skip outer ip header in case of ipip and 
net_failover
b692d5dc6f54 tipc: Fix end of loop tests for list_for_each_entry()
c5722243d0e5 net: __pskb_pull_tail() & pskb_carve_frag_list() drop_monitor 
friends
4a93c6594613 io_uring: add a schedule point in io_add_buffers()
7ef94bfb08fb bpf: Add schedule points in batch ops
4f5d47e6b43f selftests: bpf: Check bpf_msg_push_data return value
d0caa7218d76 bpf: Do not try bpf_msg_push_data with len 0
962b2a3188bf hwmon: Handle failure to register sensor with thermal zone 
correctly
d8b78314c5ba bnxt_en: Fix active FEC reporting to ethtool
7e1eae5d1a7c bnx2x: fix driver load from initrd
51e96061c66c perf data: Fix double free in perf_session__delete()
5419b5be883b ping: remove pr_err from ping_lookup
5da17865c7f3 optee: use driver internal tee_context for some rpc
eb354613847d tee: export teedev_open() and teedev_close_context()
bae7fc6f0dc6 x86/fpu: Correct pkru/xstate inconsistency
68f19845f580 netfilter: nf_tables_offload: incorrect flow 

[OE-core] [PATCH 7/9] linux-yocto/5.15: update to v5.15.26

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

8993e6067f26 Linux 5.15.26
3c805fce07c9 ice: fix concurrent reset and removal of VFs
26bc7197f9d3 ice: Fix race conditions between virtchnl handling and VF ndo 
ops
fd21a0b6da94 memblock: use kfree() to release kmalloced memblock regions
83f331d1debb gpio: tegra186: Fix chip_data type confusion
a15769155440 pinctrl: k210: Fix bias-pull-up
e3a751ee48f9 pinctrl: fix loop in k210_pinconf_get_drive()
92cab57ea6d7 tty: n_gsm: fix deadlock in gsmtty_open()
06bce5327b76 tty: n_gsm: fix wrong modem processing in convergence layer 
type 2
1bc6f3b19bc6 tty: n_gsm: fix wrong tty control line for flow control
50cacb783bb3 tty: n_gsm: fix NULL pointer access due to DLCI release
519d0b389c10 tty: n_gsm: fix proper link termination after failed open
4f0ab1c8a5a6 tty: n_gsm: fix encoding of control signal octet bit DV
1851b9a46706 riscv: fix oops caused by irqsoff latency tracer
e0ff4dffded5 riscv: fix nommu_k210_sdcard_defconfig
72aa720acacf IB/qib: Fix duplicate sysfs directory name
7a7e1b3aeef7 tps6598x: clear int mask on probe failure
bde6a6b111b9 staging: fbtft: fb_st7789v: reset display before initialization
ba9efbbf6745 thermal: int340x: fix memory leak in int3400_notify()
00265efbd3e5 RDMA/cma: Do not change route.addr.src_addr outside state 
checks
8df508b7a44c btrfs: prevent copying too big compressed lzo segment
d2bef2cbd3b1 driver core: Free DMA range map when device is released
453a82127f17 mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios 
property
fcd3f5906d64 nvmem: core: Fix a conflict between MTD and NVMEM on wp-gpios 
property
ce94606060d7 xhci: Prevent futile URB re-submissions due to incorrect 
return value.
c8b38e557414 xhci: re-initialize the HC during resume if HCE was set
88f69c64443f usb: dwc3: gadget: Let the interrupt handler disable bottom 
halves.
83e0190fb77c usb: dwc3: pci: Fix Bay Trail phy GPIO mappings
e62f41a6528f usb: dwc3: pci: Add "snps,dis_u2_susphy_quirk" for Intel Bay 
Trail
943a914d3dab usb: dwc2: drd: fix soft connect when gadget is unconfigured
85171fbf714c USB: serial: option: add Telit LE910R1 compositions
c331aa7e7064 USB: serial: option: add support for DW5829e
6db927ce66ac tracefs: Set the group ownership in apply_options() not 
parse_options()
2c775ad1fd5e USB: gadget: validate endpoint index for xilinx udc
da514063440b usb: gadget: rndis: add spinlock for rndis response list
f7c9fd0dff99 Revert "USB: serial: ch341: add new Product ID for CH341A"
27089f04fac6 ata: pata_hpt37x: disable primary channel on HPT371
4e508c593573 sc16is7xx: Fix for incorrect data being transmitted
72b0fba2dd4d iio: Fix error handling for PM
1f05c7568445 iio: imu: st_lsm6dsx: wait for settling time in 
st_lsm6dsx_read_oneshot
c77f4ae7bd43 iio: accel: fxls8962af: add padding to regmap for SPI
ca9d1799be68 iio: adc: ad7124: fix mask used for setting AIN_BUFP & 
AIN_BUFM bits
0cb9b2f73c18 iio: adc: tsc2046: fix memory corruption by preventing array 
overflow
fe7347780298 iio: adc: men_z188_adc: Fix a resource leak in an error 
handling path
7bdf7d5f0cbd iio:imu:adis16480: fix buffering for devices with no burst mode
9000406481a5 tracing: Have traceon and traceoff trigger honor the instance
7e35b31e2cee tracing: Dump stacktrace trigger to the corresponding instance
c8b56e51aa91 RDMA/ib_srp: Fix a deadlock
e7a66dd26877 configfs: fix a race in configfs_{,un}register_subsystem()
a94879d41917 bnxt_en: Increase firmware message response DMA wait time
27440589551f RDMA/rtrs-clt: Move free_permit from free_clt to rtrs_clt_close
bf2cfad0c6e4 RDMA/rtrs-clt: Fix possible double free in error case
ff999198ec21 net-timestamp: convert sk->sk_tskey to atomic_t
d99dcdabc52a regmap-irq: Update interrupt clear register for proper reset
43221f446c02 gpio: rockchip: Reset int_bothedge when changing trigger
3c32405d6474 spi: spi-zynq-qspi: Fix a NULL pointer dereference in 
zynq_qspi_exec_mem_op()
2378f94c8d9b net/mlx5: Update log_max_qp value to be 17 at most
6e94d2863384 net/mlx5e: kTLS, Use CHECKSUM_UNNECESSARY for device-offloaded 
packets
95c1867704d0 net/mlx5e: MPLSoUDP decap, fix check for unsupported matches
d4d188487ddc net/mlx5: DR, Fix the threshold that defines when pool sync is 
initiated
9703a9e2f968 net/mlx5: Fix wrong limitation of metadata match on ecpf
f63548dd05ab net/mlx5: Fix possible deadlock on rule deletion
837b0d2e69e8 net/mlx5: DR, Don't allow match on IP w/o matching on full 
ethertype/ip_version
954997aeb8f2 ibmvnic: schedule failover only if vioctl fails
117a5a7f019e net/mlx5: DR, Cache STE shadow memory
6b6094db77e6 udp_tunnel: Fix end of loop test in udp_tunnel_nic_unregister()
4039254acbd4 

[OE-core] [PATCH 6/9] linux-yocto/5.15: arm defconfig fixes

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

871f23ad3627 Revert "ARM: defconfig: Enable ax88796c driver for Exynos 
boards"
ffad0783dd5b ARM: config: multi v7: Regenerate defconifg
5c1e1a1ff2d3 ARM: config: multi v7: Add renamed symbols
badaf96564fe ARM: config: multi v7: Clean up enabled by default options
34996040fc9b ARM: config: multi v7: Drop unavailable options

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.15.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.15.bb|  4 ++--
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 20 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 4aa1d90f4d..58feb19cb7 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "3f32ac72547633bb4ba8af0a058ea6dd26700767"
+SRCREV_machine ?= "e62e8c1dfa2fe269a877b99dc9dedac6a9456b99"
 SRCREV_meta ?= "c4e4de6ccb27846e48a848d7ca1f20d9503a6fec"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 5b5946fdc0..30e63bf7f5 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "fa8ed5bf61550cfa9e6bb9b046674a2491db5672"
-SRCREV_machine ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
+SRCREV_machine:qemuarm ?= "e6e97d2b62f29bac98815616d89cf48490b03fc3"
+SRCREV_machine ?= "9cb2e893ad4e54c23650583ff55b6f7dd2168ec1"
 SRCREV_meta ?= "c4e4de6ccb27846e48a848d7ca1f20d9503a6fec"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 8b343d6eaa..fa68e9e574 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "2080556f77628b4b045c670321989cb058749acd"
-SRCREV_machine:qemuarm64 ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemumips ?= "841c395c9a56e60c861e0d8346f39a88120fd8a1"
-SRCREV_machine:qemuppc ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemuriscv64 ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemuriscv32 ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemux86 ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemux86-64 ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
-SRCREV_machine:qemumips64 ?= "f23755ed1e4ed384fe05651d51da41dd5ba1a43a"
-SRCREV_machine ?= "3cba0e6744d4323f2901af62ed458957d40b8017"
+SRCREV_machine:qemuarm ?= "681eace513f2eb77ade3954f7ede8e18c53ef3b8"
+SRCREV_machine:qemuarm64 ?= "5544942b9f3aaf9af76d55a8ea015cfcc8003921"
+SRCREV_machine:qemumips ?= "65c9fa3c96cdd8d2341ab6b6042227a928f04483"
+SRCREV_machine:qemuppc ?= "15df6d697a5319289bf2fcac3fa394da83f9aac2"
+SRCREV_machine:qemuriscv64 ?= "871f23ad362717d75aba60e56d511312522ba15c"
+SRCREV_machine:qemuriscv32 ?= "871f23ad362717d75aba60e56d511312522ba15c"
+SRCREV_machine:qemux86 ?= "871f23ad362717d75aba60e56d511312522ba15c"
+SRCREV_machine:qemux86-64 ?= "871f23ad362717d75aba60e56d511312522ba15c"
+SRCREV_machine:qemumips64 ?= "23dd0a182e404e823a7d4e4f3e00c716d7b33109"
+SRCREV_machine ?= "871f23ad362717d75aba60e56d511312522ba15c"
 SRCREV_meta ?= "c4e4de6ccb27846e48a848d7ca1f20d9503a6fec"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162771): 
https://lists.openembedded.org/g/openembedded-core/message/162771
Mute This Topic: https://lists.openembedded.org/mt/89563150/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 5/9] linux-yocto/5.10: Fix ramoops/ftrace

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

253c752ed120 pstore/ftrace: Add and use ftrace_test_recursion_trylock_safe
356e8a12bd66 pstore/ftrace: Add recursion protection to the ftrace callback
334706a1e873 ftrace: Add ftrace_test_recursion_trylock() helper function
78c260d7f60b ftrace: Move the recursion testing into global headers

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.10.bb  |  4 ++--
 .../linux/linux-yocto-tiny_5.10.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 22 +--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index ec4dea033c..d9e91856ce 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "5c627c3d0740ef68beef456aaf7ef104315a8f7f"
-SRCREV_meta ?= "ff60a2ddb31e54be0f8ac63a28247e58f9c8cd23"
+SRCREV_machine ?= "b8dfdbe4d5a7b790bd2ecdb2889846e036469d25"
+SRCREV_meta ?= "f323785b54712f92ad8cae06e2711a01d66d4fdf"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index 3414c55740..dbc0a6e90d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "ce4e423e88244adab0deef2f9d021b2bf6d492ba"
-SRCREV_machine ?= "cc09c000260f49e35e85a96853dd01404e6aa80a"
-SRCREV_meta ?= "ff60a2ddb31e54be0f8ac63a28247e58f9c8cd23"
+SRCREV_machine:qemuarm ?= "e6fb3720c9823cc706e8c6441cfd382b52bf7ae5"
+SRCREV_machine ?= "57631093be11dd9606bbe8916b9f35bc9b6fe130"
+SRCREV_meta ?= "f323785b54712f92ad8cae06e2711a01d66d4fdf"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index 0437274009..bbca0ffed5 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -13,17 +13,17 @@ KBRANCH:qemux86  ?= "v5.10/standard/base"
 KBRANCH:qemux86-64 ?= "v5.10/standard/base"
 KBRANCH:qemumips64 ?= "v5.10/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "54d10cbfb44b9449f3962d962c6ec0d2e31017e8"
-SRCREV_machine:qemuarm64 ?= "1048394a0538b9b282c1f36f4de7e4ab814c90bf"
-SRCREV_machine:qemumips ?= "0214a416a56f01fed65e4b7818470139dc2b1286"
-SRCREV_machine:qemuppc ?= "b678c6d8d47e6e67aefa985fea85fe3026f2c809"
-SRCREV_machine:qemuriscv64 ?= "bbec956b3ad71d142c590caf5a2c94cc34d224b6"
-SRCREV_machine:qemuriscv32 ?= "bbec956b3ad71d142c590caf5a2c94cc34d224b6"
-SRCREV_machine:qemux86 ?= "bbec956b3ad71d142c590caf5a2c94cc34d224b6"
-SRCREV_machine:qemux86-64 ?= "bbec956b3ad71d142c590caf5a2c94cc34d224b6"
-SRCREV_machine:qemumips64 ?= "8d571427e05d1a8c7f7b0d32f291941429865ada"
-SRCREV_machine ?= "bbec956b3ad71d142c590caf5a2c94cc34d224b6"
-SRCREV_meta ?= "ff60a2ddb31e54be0f8ac63a28247e58f9c8cd23"
+SRCREV_machine:qemuarm ?= "778c2d4c9a4798b90ed3b5609ccbc2fa8b785778"
+SRCREV_machine:qemuarm64 ?= "6c6e9a984aa0a6bb2a11528c27023c588064422d"
+SRCREV_machine:qemumips ?= "3bcde31e0d5e48a2fd21f7d6300a7b5d625e5760"
+SRCREV_machine:qemuppc ?= "20fb5e330325ade20c8c3c2de7a64d9994298af6"
+SRCREV_machine:qemuriscv64 ?= "253c752ed120276124a8463d996b30af0db6f547"
+SRCREV_machine:qemuriscv32 ?= "253c752ed120276124a8463d996b30af0db6f547"
+SRCREV_machine:qemux86 ?= "253c752ed120276124a8463d996b30af0db6f547"
+SRCREV_machine:qemux86-64 ?= "253c752ed120276124a8463d996b30af0db6f547"
+SRCREV_machine:qemumips64 ?= "89e951f3655bd59f7564bd09c106186833702f12"
+SRCREV_machine ?= "253c752ed120276124a8463d996b30af0db6f547"
+SRCREV_meta ?= "f323785b54712f92ad8cae06e2711a01d66d4fdf"
 
 # remap qemuarm to qemuarma15 for the 5.8 kernel
 # KMACHINE:qemuarm ?= "qemuarma15"
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162770): 
https://lists.openembedded.org/g/openembedded-core/message/162770
Mute This Topic: https://lists.openembedded.org/mt/89563149/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 4/9] linux-yocto/5.10: update to v5.10.101

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

3969aba589d6 Linux 5.10.101
cb86e511e78e iommu: Fix potential use-after-free during probe
f6b5d51976fc perf: Fix list corruption in perf_cgroup_switch()
ce3ca12c632a arm64: dts: imx8mq: fix lcdif port node
759aeacdfe70 scsi: lpfc: Reduce log messages seen after firmware download
57c5d7d42076 scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled
199dab00f043 can: isotp: fix error path in isotp_sendmsg() to unlock wait 
queue
3b10ebeb95d7 Makefile.extrawarn: Move -Wunaligned-access to W=1
ad53060bdfc3 hwmon: (dell-smm) Speed up setting of fan speed
3c75d1017cb3 phy: ti: Fix missing sentinel for clk_div_table
6eabe53492c2 speakup-dectlk: Restore pitch setting
3836a5ff4bb7 USB: serial: cp210x: add CPI Bulk Coin Recycler id
51b03a9bcd99 USB: serial: cp210x: add NCR Retail IO box id
a21e6b2e0864 USB: serial: ch341: add support for GW Instek USB2.0-Serial 
devices
7113440a36c7 USB: serial: option: add ZTE MF286D modem
b7ed2f9619cc USB: serial: ftdi_sio: add support for Brainboxes 
US-159/235/320
e07dde31acc9 usb: raw-gadget: fix handling of dual-direction-capable 
endpoints
e9f9b877eb0e usb: gadget: f_uac2: Define specific wTerminalType
fb4ff0f96de3 usb: gadget: rndis: check size of RNDIS_MSG_SET command
22ec10047285 USB: gadget: validate interface OS descriptor requests
351159167cd8 usb: gadget: udc: renesas_usb3: Fix host to USB_ROLE_NONE 
transition
3bfca3891480 usb: dwc3: gadget: Prevent core from processing stale TRBs
2a17bd9f5210 usb: ulpi: Call of_node_put correctly
8b89a6916681 usb: ulpi: Move of_node_put to ulpi_dev_release
758290defe93 net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup
a66a2b17b8c8 Revert "usb: dwc2: drd: fix soft connect when gadget is 
unconfigured"
73961057e9dc usb: dwc2: drd: fix soft connect when gadget is unconfigured
a37960df7eac eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX
1b99fe34e26d n_tty: wake up poll(POLLRDNORM) on receiving data
f1b25737156c vt_ioctl: add array_index_nospec to VT_ACTIVATE
778302ca0949 vt_ioctl: fix array_index_nospec in vt_setactivate
22249886dc5b net: dsa: mv88e6xxx: fix use-after-free in 
mv88e6xxx_mdios_unregister
3a3c65c487a4 net: mscc: ocelot: fix mutex lock error during ethtool stats 
read
809f030745b2 ice: fix IPIP and SIT TSO offload
cf11949b9163 ice: fix an error code in ice_cfg_phy_fec()
f8edc6feab4d dpaa2-eth: unregister the netdev before disconnecting from the 
PHY
ff6c9e0fcee5 net: amd-xgbe: disable interrupts during pci removal
657aea782887 tipc: rate limit warning for received illegal binding update
ef5cdae8bc00 net: mdio: aspeed: Add missing MODULE_DEVICE_TABLE
bf99c144360d veth: fix races around rq->rx_notify_masked
00e6d6c3bc14 net: fix a memleak when uncloning an skb dst and its metadata
2e9fd2d0f69e net: do not keep the dst cache when uncloning an skb dst and 
its metadata
0bae953d7ab5 nfp: flower: fix ida_idx not being released
09ac0fcb0a82 ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() 
on failure path
e177d2e85ebc net: dsa: lantiq_gswip: don't use devres for mdiobus
95e5402f9430 net: dsa: felix: don't use devres for mdiobus
2770b795294e net: dsa: bcm_sf2: don't use devres for mdiobus
475ce5dcf2d8 net: dsa: ar9331: register the mdiobus under devres
8ccebe77df6e net: dsa: mv88e6xxx: don't use devres for mdiobus
4a384c1e4058 bonding: pair enable_port with slave_arr_updates
1ba45dd32667 gpio: sifive: use the correct register to read output values
48e413087de1 ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE
3b72d3f0205e drm/panel: simple: Assign data from panel_dpi_probe() correctly
bf35639192ed ixgbevf: Require large buffers for build_skb on 82599VF
e5a64f548a45 arm64: dts: meson-g12b-odroid-n2: fix typo 'dio2133'
04fe6569a7cf netfilter: ctnetlink: disable helper autoassign
a5ce7ee5fcc0 misc: fastrpc: avoid double fput() on failed usercopy
21c890ca8eae drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd.
70ea005626a9 gpio: aggregator: Fix calling into sleeping GPIO controllers
0042178a69eb usb: f_fs: Fix use-after-free for epfile
5a37fd9fdcce ARM: dts: imx7ulp: Fix 'assigned-clocks-parents' typo
39bf132a6ed5 phy: xilinx: zynqmp: Fix bus width setting for SGMII
108868dae2ee ARM: dts: imx6qdl-udoo: Properly describe the SD card detect
0a7b5e8d8c1e staging: fbtft: Fix error path in fbtft_driver_module_init()
74cd5cb2190f ARM: dts: meson8b: Fix the UART device-tree schema validation
566b558e9429 ARM: dts: meson8: Fix the UART device-tree schema validation
210d70f08100 ARM: dts: meson: Fix the UART compatible strings
88f0e61354f4 ARM: dts: Fix timer regression for beagleboard revision c

[OE-core] [PATCH 3/9] linux-yocto/5.15: update to v5.15.24

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

a0ebea480bb3 Linux 5.15.24
65ab30f6a695 iommu: Fix potential use-after-free during probe
7969fe91c983 perf: Fix list corruption in perf_cgroup_switch()
8ebcd2c680e1 arm64: dts: imx8mq: fix lcdif port node
48f54966f7f7 MIPS: octeon: Fix missed PTR->PTR_WD conversion
cd4494f8685c scsi: lpfc: Reduce log messages seen after firmware download
6737f9a95a42 scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled
c8e9c2b52c4c Makefile.extrawarn: Move -Wunaligned-access to W=1
24645c47880b x86/sgx: Silence softlockup detection when releasing large 
enclaves
30de73bebf2b hwmon: (dell-smm) Speed up setting of fan speed
16cde074b00c bus: mhi: pci_generic: Add mru_default for Cinterion MV31-W
2c1d20e34669 bus: mhi: pci_generic: Add mru_default for Foxconn SDX55
fe990b7bf6ac s390/cio: verify the driver availability for path_event call
56ca18dd5483 signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE
f7a56fcca2e4 seccomp: Invalidate seccomp mode to catch death failures
956cf21cd1ae mm: memcg: synchronize objcg lists with a dedicated spinlock
b7f54894aa75 iio: buffer: Fix file related error handling in 
IIO_BUFFER_GET_FD_IOCTL
7a360e546ad9 phy: ti: Fix missing sentinel for clk_div_table
12431425c466 speakup-dectlk: Restore pitch setting
9ae3dad535a9 USB: serial: cp210x: add CPI Bulk Coin Recycler id
7e5108a22f19 USB: serial: cp210x: add NCR Retail IO box id
8d226d39d052 USB: serial: ch341: add support for GW Instek USB2.0-Serial 
devices
2ea4f4612cb9 USB: serial: option: add ZTE MF286D modem
24311a9fc426 USB: serial: ftdi_sio: add support for Brainboxes 
US-159/235/320
2330b2ba6465 usb: raw-gadget: fix handling of dual-direction-capable 
endpoints
33d2a0c1ec20 usb: gadget: f_uac2: Define specific wTerminalType
2da3b0ab54fb usb: gadget: rndis: check size of RNDIS_MSG_SET command
3e33e5c67cb9 USB: gadget: validate interface OS descriptor requests
d3d5bfb3a279 usb: gadget: udc: renesas_usb3: Fix host to USB_ROLE_NONE 
transition
8d2b04dad380 usb: dwc3: gadget: Prevent core from processing stale TRBs
93feb2bdf6d4 usb: ulpi: Call of_node_put correctly
fc50f42e4616 usb: ulpi: Move of_node_put to ulpi_dev_release
ffd0393adcdc net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup
f4e72ad027b0 Revert "usb: dwc2: drd: fix soft connect when gadget is 
unconfigured"
a6ef1bda0efd usb: dwc2: drd: fix soft connect when gadget is unconfigured
9a5f471ae380 eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX
decb36e9a9f0 n_tty: wake up poll(POLLRDNORM) on receiving data
573321db328b vt_ioctl: add array_index_nospec to VT_ACTIVATE
ffe54289b02e vt_ioctl: fix array_index_nospec in vt_setactivate
f916181692cb net: dsa: mv88e6xxx: fix use-after-free in 
mv88e6xxx_mdios_unregister
d98ba26a4ba9 net: mscc: ocelot: fix mutex lock error during ethtool stats 
read
41a8c548d47b ice: Avoid RTNL lock when re-creating auxiliary device
f9daedc3ab8f ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler
52eb5c86ede4 ice: fix IPIP and SIT TSO offload
efd399e12c1b ice: fix an error code in ice_cfg_phy_fec()
12e067a4d98f dpaa2-eth: unregister the netdev before disconnecting from the 
PHY
29b25d5f8f30 mptcp: netlink: process IPv6 addrs in creating listening 
sockets
dcd1c4663469 drm/amd/pm: fix hwmon node of power1_label create issue
4b24ef1d03cf net: amd-xgbe: disable interrupts during pci removal
489d9fa78e59 tipc: rate limit warning for received illegal binding update
bb04b5527aff net: mdio: aspeed: Add missing MODULE_DEVICE_TABLE
b8ac37e57044 veth: fix races around rq->rx_notify_masked
fdcb263fa5cd net: fix a memleak when uncloning an skb dst and its metadata
f1ab1ba32d36 net: do not keep the dst cache when uncloning an skb dst and 
its metadata
6cbe14cc0eb6 nfp: flower: fix ida_idx not being released
3cab045c99db ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() 
on failure path
b5652bc50dde net: dsa: lantiq_gswip: don't use devres for mdiobus
46b747232329 net: dsa: mt7530: fix kernel bug in mdiobus_free() when 
unbinding
8cda7577a0b4 net: dsa: felix: don't use devres for mdiobus
caabb5f64f5c net: dsa: bcm_sf2: don't use devres for mdiobus
aae1c6a1d3d6 net: dsa: ar9331: register the mdiobus under devres
8b626d45127d net: dsa: mv88e6xxx: don't use devres for mdiobus
147540cae264 bonding: pair enable_port with slave_arr_updates
3523167d6658 fbcon: Avoid 'cap' set but not used warning
ef2cb1fc0365 gpio: sifive: use the correct register to read output values
d9daa2b76dde gpiolib: Never return internal error codes to user space
e799974e7cbb ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE
ab142ea5d502 drm/panel: simple: Assign data 

[OE-core] [PATCH 2/9] linux-yocto/5.10: features/zram: remove CONFIG_ZRAM_DEF_COMP

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/.:

7a012dfacdc features/zram: remove CONFIG_ZRAM_DEF_COMP

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.10.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 8a8a7eabe9..5f512016b2 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "e5b266bc6b15dc8852649b7d2a31395195dc7b3a"
-SRCREV_meta ?= "b53e11ea46f4e78ff4cb48532a11e1dbad7939b1"
+SRCREV_meta ?= "7a012dfacdc82bce2279c26af29cf40b5fdbeed2"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index bf7662eed3..7a7a13e031 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine:qemuarm ?= "9a8497a8761a22b3086cab63d18698024a69a410"
 SRCREV_machine ?= "317635e1feaecfd8aa29bc94d8d03ba873190414"
-SRCREV_meta ?= "b53e11ea46f4e78ff4cb48532a11e1dbad7939b1"
+SRCREV_meta ?= "7a012dfacdc82bce2279c26af29cf40b5fdbeed2"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index ecb2d03949..130e3286ce 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"c0b313d988a16b25c1ee730bfe7393c462ee8a5c"
 SRCREV_machine:qemux86-64 ?= "c0b313d988a16b25c1ee730bfe7393c462ee8a5c"
 SRCREV_machine:qemumips64 ?= "ae7887fe8d4da06d2d0d0a5071d09155899de26c"
 SRCREV_machine ?= "c0b313d988a16b25c1ee730bfe7393c462ee8a5c"
-SRCREV_meta ?= "b53e11ea46f4e78ff4cb48532a11e1dbad7939b1"
+SRCREV_meta ?= "7a012dfacdc82bce2279c26af29cf40b5fdbeed2"
 
 # remap qemuarm to qemuarma15 for the 5.8 kernel
 # KMACHINE:qemuarm ?= "qemuarma15"
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162767): 
https://lists.openembedded.org/g/openembedded-core/message/162767
Mute This Topic: https://lists.openembedded.org/mt/89563146/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 0/9] linux-yocto: consolidated pull request

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

Here's the next round of -stable and configuration updates for 5.10 and
5.15.

Nothing significant here, I've been soaking them for a while, hopefully
the AB agrees with my "it's green" assesment!

Cheers,

Bruce

The following changes since commit a25c07622502727ca1b0e01d32127b57f75d28fb:

  Revert "libsdl2: Add libunwind-native to the libsdl2-native DEPENDS" 
(2022-03-05 00:08:33 +)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (9):
  linux-yocto/5.15: riscv64: drop MAXPHYSMEM_128GB
  linux-yocto/5.10: features/zram: remove CONFIG_ZRAM_DEF_COMP
  linux-yocto/5.15: update to v5.15.24
  linux-yocto/5.10: update to v5.10.101
  linux-yocto/5.10: Fix ramoops/ftrace
  linux-yocto/5.15: arm defconfig fixes
  linux-yocto/5.15: update to v5.15.26
  linux-yocto/5.10: update to v5.10.103
  linux-yocto/5.15: riscv32: drop MAXPHYSMEM_1GB

 .../linux/linux-yocto-rt_5.10.bb  |  6 ++---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb|  8 +++---
 .../linux/linux-yocto-tiny_5.15.bb|  8 +++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 -
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 6 files changed, 39 insertions(+), 39 deletions(-)

-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162765): 
https://lists.openembedded.org/g/openembedded-core/message/162765
Mute This Topic: https://lists.openembedded.org/mt/89563142/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/9] linux-yocto/5.15: riscv64: drop MAXPHYSMEM_128GB

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto:

commit e1b976ee4fb5af517cf01a9f2dd4a32f560ca894
Author: Bruce Ashfield 
Date:   Tue Feb 15 23:27:31 2022 -0500

riscv64: drop MAXPHYSMEM_128GB

The MAXPHYSMEM config options have been removed upstream via the
following commit, so we drop our setting.

   commit 6250ecf5ba42292b652cd01c9fcb2239010c5c44
   Author: Alexandre Ghiti 
   Date:   Mon Jan 17 10:57:16 2022 +0100

   riscv: Get rid of MAXPHYSMEM configs

   commit db1503d355a79d1d4255a9996f20e72848b74a56 upstream.

   CONFIG_MAXPHYSMEM_* are actually never used, even the nommu 
defconfigs
   selecting the MAXPHYSMEM_2GB had no effects on PAGE_OFFSET since 
it was
   preempted by !MMU case right before.

   In addition, the move of the kernel mapping at the end of the 
address
   space broke the use of MAXPHYSMEM_2G with MMU since it defines 
PAGE_OFFSET
   at the same address as the kernel mapping.

   Reported-by: Geert Uytterhoeven 
   Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of 
linear mapping")
   Signed-off-by: Alexandre Ghiti 
   Tested-by: Geert Uytterhoeven 
   Tested-by: Conor Dooley 
   Cc: sta...@vger.kernel.org
   Signed-off-by: Palmer Dabbelt 
   Signed-off-by: Greg Kroah-Hartman 

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 9b652a797b..22385ad38c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "c5b3006ccedbb8397aa58b667b981e0c2435b943"
-SRCREV_meta ?= "2d38a472b21ae343707c8bd64ac68a9eaca066a0"
+SRCREV_meta ?= "e1b976ee4fb5af517cf01a9f2dd4a32f560ca894"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 754dbc7d60..ae72f34c26 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -17,7 +17,7 @@ KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine:qemuarm ?= "66d56b3bcc1391639a84e35be3ef00c5197089a8"
 SRCREV_machine ?= "7f685244afb3acd13e94968312580b63d7296705"
-SRCREV_meta ?= "2d38a472b21ae343707c8bd64ac68a9eaca066a0"
+SRCREV_meta ?= "e1b976ee4fb5af517cf01a9f2dd4a32f560ca894"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 4b5e332c37..43409fb45e 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"7f685244afb3acd13e94968312580b63d7296705"
 SRCREV_machine:qemux86-64 ?= "7f685244afb3acd13e94968312580b63d7296705"
 SRCREV_machine:qemumips64 ?= "1d269d782d6b6effed2437ad6b11ae4f4e789259"
 SRCREV_machine ?= "7f685244afb3acd13e94968312580b63d7296705"
-SRCREV_meta ?= "2d38a472b21ae343707c8bd64ac68a9eaca066a0"
+SRCREV_meta ?= "e1b976ee4fb5af517cf01a9f2dd4a32f560ca894"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162766): 
https://lists.openembedded.org/g/openembedded-core/message/162766
Mute This Topic: https://lists.openembedded.org/mt/89563144/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED

[Randy MacLeod]

On 2022-03-04 16:10, Khem Raj wrote:

On Fri, Mar 4, 2022 at 12:56 PM Otavio Salvador
 wrote:


Em sex., 4 de mar. de 2022 às 15:04, Alexander Kanavin  
escreveu:

Rust is a low-risk item from feature freeze perspective, so I already
queued a patch. If a-full is ok with it, there's no reason not to
merge it in my opinion.

I agree; it makes sense to upgrade it (even during the LTS lifetime) especially 
because Rust compiler isn't long term maintained so we should consider it.

Its not end of world even if its not merged, given the rust compiler
cadence we perhaps will have a mixin layer for
it for kirkstone few months after release.



My approach of drawing an bogus line in the sand worked! ;-)

I'm fine with upgrading to 1.59 or staying with 1.58.1

I have been meaning to look at how other distros are handling
Rust in their releases so I looked at:
   https://pkgs.org/search/?q=rustc

and Debian/Ubuntu/Fedora seems to be sticking with the
"ship a version and stick with it" model, unlike say chromium
where the policy varies a across distros.

As Khem points out, Rust is under substantial development so
a mixin layer might make sense for some; we'll see.

./.Randy




--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750





--
# Randy MacLeod
# Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162764): 
https://lists.openembedded.org/g/openembedded-core/message/162764
Mute This Topic: https://lists.openembedded.org/mt/89530593/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH v2] layer.conf: Filter docs dependencies for efficiency

[Richard Purdie]

Where a recipe has depends on native docs tools, in most cases
we don't need recipes that depend on that recipe to also install
these things into the sysroot. We can rely on recipes wanting these
tools to have direct dependencies instead.

This massively reduced dependency creep in simple recipes (e.g. an
allarch one) and reduced the size of builds with the api-documentation
feature substancially.

gperf-native is also included since that would normally have a direct
dependency in a recipe which needs it too.

For gtk-doc-native, we do need the xmlto-native dependency.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index bdeb8a47589..77a765d7cb5 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -100,6 +100,10 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->patch-native \
 .*->pkgconfig-native \
 .*->quilt-native \
+^(?!gtk-doc-native).*->xmlto-native \
+.*->gperf-native \
+.*->gtk-doc-native \
+.*->texinfo-native \
 "
 # Nothing needs to depend on libc-initial
 # base-passwd/shadow-sysroot don't need their dependencies
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162763): 
https://lists.openembedded.org/g/openembedded-core/message/162763
Mute This Topic: https://lists.openembedded.org/mt/89562124/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] layer.conf: Allow sysroot dependencies on perlcross-native to be skipped

[Richard Purdie]

The only thing which needs perlcross-native will depend upon it directly
so we can optimise this out everywhere else for small space/speed gains.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 935c4f6b9b7..ea57123601c 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -105,6 +105,7 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->gperf-native \
 .*->gtk-doc-native \
 .*->texinfo-native \
+.*->perlcross-native \
 libarchive-native->e2fsprogs-native \
 "
 # Nothing needs to depend on libc-initial
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162762): 
https://lists.openembedded.org/g/openembedded-core/message/162762
Mute This Topic: https://lists.openembedded.org/mt/89562093/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libsdl2: Add libunwind-native to the libsdl2-native DEPENDS

[Richard Purdie]

On Fri, 2022-03-04 at 18:20 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org
> >  On Behalf Of Carlos Rafael Giani
> > via lists.openembedded.org
> > Sent: den 4 mars 2022 08:55
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] libsdl2: Add libunwind-native to the 
> > libsdl2-native
> > DEPENDS
> > 
> > This fixes this CMake configuration error:
> > 
> > > -- Checking for one of the modules 'libunwind'
> > > CMake Error at [...]/build/tmp/work/x86_64-linux/libsdl2-native/2.0.20-
> > > r0/recipe-sysroot-native/usr/share/cmake-
> > > 3.22/Modules/FindPkgConfig.cmake:890 (message):
> > >   None of the required 'libunwind' found
> > > Call Stack (most recent call first):
> > >   CMakeLists.txt:1367 (pkg_search_module)
> > 
> > This error happens even if libunwind is installed complete with its C
> > headers and development .so files (in Ubuntu, this means libunwind-dev
> > is installed).
> > 
> > Signed-off-by: Carlos Rafael Giani 
> > ---
> >  meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb b/meta/recipes-
> > graphics/libsdl2/libsdl2_2.0.20.bb
> > index 90724ab8b7..802efba980 100644
> > --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb
> > +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb
> > @@ -27,6 +27,8 @@ SRC_URI[sha256sum] =
> > "c56aba1d7b5b0e7e999e4a7698c70b63a3394ff9704b5f6e1c57e0c16f
> > 
> >  inherit cmake lib_package binconfig-disabled pkgconfig
> > 
> > +DEPENDS:class-native += "libunwind-native"
> 
> The above should be:
> 
> DEPENDS:append:class-native = " libunwind-native"
> 
> However, why don't libsdl2 built for target and nativesdk 
> need to depend on libunwind? I.e., why isn't the above:
> 
> DEPENDS = "libunwind"
> 
> 

There is a second issue, libunwind-native doesn't build on all our systems:

https://autobuilder.yoctoproject.org/typhoon/#/builders/91/builds/5624/steps/12/logs/stdio

:(

I think I may have to revert this until we get to the bottom of things.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162761): 
https://lists.openembedded.org/g/openembedded-core/message/162761
Mute This Topic: https://lists.openembedded.org/mt/89544908/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Bruce Ashfield]

On Fri, Mar 4, 2022 at 3:14 PM Khem Raj  wrote:
>
> On Fri, Mar 4, 2022 at 11:20 AM Konrad Weihmann  wrote:
> >
> > If it's about meta-python why can't be placed there? I don't follow the 
> > argument that some edge case stuff outside of core requires the project to 
> > have additional (as of now not time limited) maintenance effort - if there 
> > would be a clear plan to remove that before kirkstone release I might 
> > agree, but with the release looming this all feels like abandoning the 
> > commitment for the upcoming release.
>
> it is about many layers e.g. meta-oe, meta-xfce, meta-python and
> perhaps many more that I have not come across yet. We want to enable a
> wider ecosystem and we
> do carry features in OE-core to do so from time to time. Core in
> itself is a reference distribution, its not meant to carry just what
> it needs to support a minimum distro
> it serves as a baseline for many distros which may include other
> layers. At times we do put specific features in specific layers, this
> is not one of those.

Agreed.

I'd prefer that this be in core, versus meta-python.

Bruce

>
> >
> > And just to emphasize my claim, if there's nothing in core that would 
> > require this patch it won't get tested, so it's another dead end.
> >
> > In the end it's the decision of the project leads, but I would be 
> > personally be disappointed to take the easy way out here.
> >
> > On 4 Mar 2022 19:01, Otavio Salvador  
> > wrote:
> >
> >
> >
> > Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:
> >
> > There are recipes in meta-oe and meta-python which would need this
> > and both layer only list core as sole dependency, if we put it in either of
> > these layers, then one will depend on other which is not nice, so I rather
> > would prefer it in core.
> >
> >
> > Couldn't those recipes (depending on Python) go to meta-python?
> >
> > --
> > Otavio Salvador O.S. Systems
> > http://www.ossystems.com.brhttp://code.ossystems.com.br
> > Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
> >
> >
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162760): 
https://lists.openembedded.org/g/openembedded-core/message/162760
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Konrad Weihmann]

On 4 Mar 2022 21:14, Khem Raj  wrote:On Fri, Mar 4, 2022 at 11:20 AM Konrad Weihmann  wrote:

>

> If it's about meta-python why can't be placed there? I don't follow the argument that some edge case stuff outside of core requires the project to have additional (as of now not time limited) maintenance effort - if there would be a clear plan to remove that before kirkstone release I might agree, but with the release looming this all feels like abandoning the commitment for the upcoming release.



it is about many layers e.g. meta-oe, meta-xfce, meta-python and

perhaps many more that I have not come across yet. Then please provide a list what is failing, just so people, such as myself, can see the necessity of this change - as of now I didn't see any technically sound proof that this needs to be in coreWe want to enable a

wider ecosystem and we

do carry features in OE-core to do so from time to time. Core in

itself is a reference distribution, its not meant to carry just what

it needs to support a minimum distro

it serves as a baseline for many distros which may include other

layers. At times we do put specific features in specific layers, this

is not one of those.



>

> And just to emphasize my claim, if there's nothing in core that would require this patch it won't get tested, so it's another dead end.

>

> In the end it's the decision of the project leads, but I would be personally be disappointed to take the easy way out here.

>

> On 4 Mar 2022 19:01, Otavio Salvador  wrote:

>

>

>

> Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:

>

> There are recipes in meta-oe and meta-python which would need this

> and both layer only list core as sole dependency, if we put it in either of

> these layers, then one will depend on other which is not nice, so I rather

> would prefer it in core.

>

>

> Couldn't those recipes (depending on Python) go to meta-python?

>

> --

> Otavio Salvador O.S. Systems

> http://www.ossystems.com.br    http://code.ossystems.com.br

> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

>

>



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162759): 
https://lists.openembedded.org/g/openembedded-core/message/162759
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED

[Khem Raj]

On Fri, Mar 4, 2022 at 12:56 PM Otavio Salvador
 wrote:
>
>
>
> Em sex., 4 de mar. de 2022 às 15:04, Alexander Kanavin 
>  escreveu:
>>
>> Rust is a low-risk item from feature freeze perspective, so I already
>> queued a patch. If a-full is ok with it, there's no reason not to
>> merge it in my opinion.
>
>
> I agree; it makes sense to upgrade it (even during the LTS lifetime) 
> especially because Rust compiler isn't long term maintained so we should 
> consider it.

Its not end of world even if its not merged, given the rust compiler
cadence we perhaps will have a mixin layer for
it for kirkstone few months after release.

>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162758): 
https://lists.openembedded.org/g/openembedded-core/message/162758
Mute This Topic: https://lists.openembedded.org/mt/89530593/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED

[Otavio Salvador]

Em sex., 4 de mar. de 2022 às 15:04, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:

> Rust is a low-risk item from feature freeze perspective, so I already
> queued a patch. If a-full is ok with it, there's no reason not to
> merge it in my opinion.
>

I agree; it makes sense to upgrade it (even during the LTS lifetime)
especially because Rust compiler isn't long term maintained so we should
consider it.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162757): 
https://lists.openembedded.org/g/openembedded-core/message/162757
Mute This Topic: https://lists.openembedded.org/mt/89530593/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Khem Raj]

On Fri, Mar 4, 2022 at 11:20 AM Konrad Weihmann  wrote:
>
> If it's about meta-python why can't be placed there? I don't follow the 
> argument that some edge case stuff outside of core requires the project to 
> have additional (as of now not time limited) maintenance effort - if there 
> would be a clear plan to remove that before kirkstone release I might agree, 
> but with the release looming this all feels like abandoning the commitment 
> for the upcoming release.

it is about many layers e.g. meta-oe, meta-xfce, meta-python and
perhaps many more that I have not come across yet. We want to enable a
wider ecosystem and we
do carry features in OE-core to do so from time to time. Core in
itself is a reference distribution, its not meant to carry just what
it needs to support a minimum distro
it serves as a baseline for many distros which may include other
layers. At times we do put specific features in specific layers, this
is not one of those.

>
> And just to emphasize my claim, if there's nothing in core that would require 
> this patch it won't get tested, so it's another dead end.
>
> In the end it's the decision of the project leads, but I would be personally 
> be disappointed to take the easy way out here.
>
> On 4 Mar 2022 19:01, Otavio Salvador  wrote:
>
>
>
> Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:
>
> There are recipes in meta-oe and meta-python which would need this
> and both layer only list core as sole dependency, if we put it in either of
> these layers, then one will depend on other which is not nice, so I rather
> would prefer it in core.
>
>
> Couldn't those recipes (depending on Python) go to meta-python?
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162756): 
https://lists.openembedded.org/g/openembedded-core/message/162756
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Konrad Weihmann]

If it's about meta-python why can't be placed there? I don't follow the argument that some edge case stuff outside of core requires the project to have additional (as of now not time limited) maintenance effort - if there would be a clear plan to remove that before kirkstone release I might agree, but with the release looming this all feels like abandoning the commitment for the upcoming release.And just to emphasize my claim, if there's nothing in core that would require this patch it won't get tested, so it's another dead end.In the end it's the decision of the project leads, but I would be personally be disappointed to take the easy way out here.On 4 Mar 2022 19:01, Otavio Salvador  wrote:Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:There are recipes in meta-oe and meta-python which would need this
and both layer only list core as sole dependency, if we put it in either of
these layers, then one will depend on other which is not nice, so I rather
would prefer it in core.Couldn't those recipes (depending on Python) go to meta-python?  -- Otavio Salvador                             O.S. Systemshttp://www.ossystems.com.br        http://code.ossystems.com.brMobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162755): 
https://lists.openembedded.org/g/openembedded-core/message/162755
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 2/3] setuptools3.bbclass: clean up

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Ross Burton
> Sent: den 4 mars 2022 18:14
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH 2/3] setuptools3.bbclass: clean up
> 
> There's been a lot of work in this class lately, so a little spring
> cleaning is needed.
> 
> Create wheels verbosely to help debug problems.
> 
> Remove unused SETUPTOOLS_INSTALL_ARGS, these can't be passed to
> bdist_wheel.
> 
> Remove duplicate manipulation of files in bindir as pip_install_wheel
> does the same.
> 
> Remove obsolete deletion of easy-install.pth, wheels don't generate that.
> 
> Remove obsolete ${datadir}/share fixup, pip-installed wheels can't
> generate that path combination.
> 
> Remove purging of ${D} references from *.py, these won't be written by
> standard setuptools, and recipes can do it themselves to work around
> specific issues if needed.
> 
> Remove obsolete vardepsexclude of MACHINE on do_install, as that variable
> isn't referenced.
> 
> Signed-off-by: Ross Burton 
> 
> fixup! setuptools3.bbclass: clean up

That last line looks like some leftover from rebasing?

> ---
>  meta/classes/setuptools3.bbclass | 34 +---
>  1 file changed, 1 insertion(+), 33 deletions(-)
> 
> diff --git a/meta/classes/setuptools3.bbclass
> b/meta/classes/setuptools3.bbclass
> index 564996c556..1b1a8aac76 100644
> --- a/meta/classes/setuptools3.bbclass
> +++ b/meta/classes/setuptools3.bbclass
> @@ -4,13 +4,6 @@ inherit setuptools3-base pip_install_wheel
>  #B = "${WORKDIR}/build"
> 
>  SETUPTOOLS_BUILD_ARGS ?= ""
> -SETUPTOOLS_INSTALL_ARGS ?= "--root=${D} \
> ---prefix=${prefix} \
> ---install-lib=${PYTHON_SITEPACKAGES_DIR} \
> ---install-data=${datadir}"
> -
> -SETUPTOOLS_PYTHON = "python3"
> -SETUPTOOLS_PYTHON:class-native = "nativepython3"
> 
>  SETUPTOOLS_SETUP_PATH ?= "${S}"
> 
> @@ -24,42 +17,17 @@ setuptools3_do_compile() {
>  STAGING_INCDIR=${STAGING_INCDIR} \
>  STAGING_LIBDIR=${STAGING_LIBDIR} \
>  ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
> -bdist_wheel ${SETUPTOOLS_BUILD_ARGS} || \
> +bdist_wheel --verbose ${SETUPTOOLS_BUILD_ARGS} || \
>  bbfatal_log "'${PYTHON_PN} setup.py bdist_wheel 
> ${SETUPTOOLS_BUILD_ARGS}' execution failed."

Why all the backslashes? This is bitbake, not make. ;)

>  }
>  setuptools3_do_compile[vardepsexclude] = "MACHINE"
>  do_compile[cleandirs] += "${SETUPTOOLS_SETUP_PATH}/dist"
> 
>  setuptools3_do_install() {
> -cd ${SETUPTOOLS_SETUP_PATH}
> -
>  pip_install_wheel_do_install
> -
> -# support filenames with *spaces*
> -find ${D} -name "*.py" -exec grep -q ${D} {} \; \
> -   -exec sed -i -e s:${D}::g {} \;
> -
> -for i in ${D}${bindir}/* ${D}${sbindir}/*; do
> -if [ -f "$i" ]; then
> -sed -i -e s:${PYTHON}:${USRBINPATH}/env\ 
> ${SETUPTOOLS_PYTHON}:g $i
> -sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
> -fi
> -done
> -
> -rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
> -
> -#
> -# FIXME: Bandaid against wrong datadir computation
> -#
> -if [ -e ${D}${datadir}/share ]; then
> -mv -f ${D}${datadir}/share/* ${D}${datadir}/
> -rmdir ${D}${datadir}/share
> -fi
>  }
> -setuptools3_do_install[vardepsexclude] = "MACHINE"
> 
>  EXPORT_FUNCTIONS do_configure do_compile do_install
> 
>  export LDSHARED="${CCLD} -shared"
>  DEPENDS += "python3-setuptools-native python3-wheel-native"
> -
> --
> 2.25.1

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162754): 
https://lists.openembedded.org/g/openembedded-core/message/162754
Mute This Topic: https://lists.openembedded.org/mt/89553657/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Khem Raj]

On Fri, Mar 4, 2022 at 10:01 AM Otavio Salvador
 wrote:
>
>
>
> Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:
>>
>> There are recipes in meta-oe and meta-python which would need this
>> and both layer only list core as sole dependency, if we put it in either of
>> these layers, then one will depend on other which is not nice, so I rather
>> would prefer it in core.
>
>
> Couldn't those recipes (depending on Python) go to meta-python?

not without making meta-python as core dependency for meta-oe, its
better to keep them
independent.

>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162753): 
https://lists.openembedded.org/g/openembedded-core/message/162753
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libsdl2: Add libunwind-native to the libsdl2-native DEPENDS

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Carlos Rafael Giani 
> via lists.openembedded.org
> Sent: den 4 mars 2022 08:55
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] libsdl2: Add libunwind-native to the 
> libsdl2-native DEPENDS
> 
> This fixes this CMake configuration error:
> 
> | -- Checking for one of the modules 'libunwind'
> | CMake Error at 
> [...]/build/tmp/work/x86_64-linux/libsdl2-native/2.0.20-r0/recipe-sysroot-native/usr/share/cmake-3.22/Modules/FindPkgConfig.cmake:890
>  (message):
> |   None of the required 'libunwind' found
> | Call Stack (most recent call first):
> |   CMakeLists.txt:1367 (pkg_search_module)
> 
> This error happens even if libunwind is installed complete with its C
> headers and development .so files (in Ubuntu, this means libunwind-dev
> is installed).
> 
> Signed-off-by: Carlos Rafael Giani 
> ---
>  meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb 
> b/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb
> index 90724ab8b7..802efba980 100644
> --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb
> +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.20.bb
> @@ -27,6 +27,8 @@ SRC_URI[sha256sum] =
> "c56aba1d7b5b0e7e999e4a7698c70b63a3394ff9704b5f6e1c57e0c16f
> 
>  inherit cmake lib_package binconfig-disabled pkgconfig
> 
> +DEPENDS:class-native += "libunwind-native"

The above should be:

DEPENDS:append:class-native = " libunwind-native"

However, why don't libsdl2 built for target and nativesdk 
need to depend on libunwind? I.e., why isn't the above:

DEPENDS = "libunwind"

> +
>  BINCONFIG = "${bindir}/sdl2-config"
> 
>  CVE_PRODUCT = "simple_directmedia_layer sdl"
> --
> 2.32.0

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162752): 
https://lists.openembedded.org/g/openembedded-core/message/162752
Mute This Topic: https://lists.openembedded.org/mt/89544908/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED

[Alexander Kanavin]

Rust is a low-risk item from feature freeze perspective, so I already
queued a patch. If a-full is ok with it, there's no reason not to
merge it in my opinion.

Alex

On Fri, 4 Mar 2022 at 18:45, Randy MacLeod  wrote:
>
>
> FYI: 1.59 release notes:
> https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html
>
>
> While there are interesting features in 1.59, such as the inline
> assembly support,
> we are in feature freeze so I expect we'll stick with 1.58.1 .
>
> It probably also makes sense to skip 1.59 and wait for 1.60 in early May
> for 3.6
> depending on when we branch 3.5.
>
> ../Randy
>
> On 2022-03-03 12:42, a...@yoctoproject.org wrote:
> > Hello,
> >
> > this email is a notification from the Auto Upgrade Helper
> > that the automatic attempt to upgrade the recipe *rust-llvm* to *1.59.0* 
> > has Failed (devtool error).
> >
> > Detailed error information:
> >
> > The following devtool command failed:  finish -f rust-llvm 
> > /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust
> > NOTE: Starting bitbake server...
> > Loading cache...done.
> > Loaded 1521 entries from dependency cache.
> > Parsing recipes...done.
> > Parsing of 844 .bb files complete (843 cached, 1 parsed). 1523 targets, 34 
> > skipped, 0 masked, 0 errors.
> >
> > ERROR: Traceback (most recent call last):
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
> >  line 162, in wrapped
> >  return func(fn, *args)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
> >  line 187, in parse_config_file
> >  return bb.parse.handle(fn, data, include)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
> >  line 107, in handle
> >  return h['handle'](fn, data, include)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
> >  line 118, in handle
> >  abs_fn = resolve_file(fn, data)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
> >  line 131, in resolve_file
> >  raise IOError(errno.ENOENT, "file %s not found" % fn)
> > FileNotFoundError: [Errno 2] file 
> > /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
> >  not found
> >
> > ERROR: Unable to parse 
> > /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf:
> >  [Errno 2] file 
> > /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
> >  not found
> > Traceback (most recent call last):
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
> >  line 162, in wrapped
> >  return func(fn, *args)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
> >  line 187, in parse_config_file
> >  return bb.parse.handle(fn, data, include)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
> >  line 107, in handle
> >  return h['handle'](fn, data, include)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
> >  line 118, in handle
> >  abs_fn = resolve_file(fn, data)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
> >  line 131, in resolve_file
> >  raise IOError(errno.ENOENT, "file %s not found" % fn)
> > FileNotFoundError: [Errno 2] file 
> > /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
> >  not found
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/devtool", line 
> > 334, in 
> >  ret = main()
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/devtool", line 
> > 321, in main
> >  ret = args.func(args, config, basepath, workspace)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/lib/devtool/standard.py",
> >  line 2108, in finish
> >  updated, appendfile, removed = _update_recipe(args.recipename, 
> > workspace, rd, args.mode, appendlayerdir, wildcard_version=True, 
> > no_remove=False, no_report_remove=removing_original, 
> > initial_rev=args.initial_rev, dry_run_outdir=dry_run_outdir, 
> > no_overrides=args.no_overrides, 
> > force_patch_refresh=args.force_patch_refresh)
> >File 
> > "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/lib/devtool/standard.py",
> >  line 1814, in _update_recipe
> >  updated, appendf, removed = _update_recipe_patch(recipename, 
> > workspace, srctree, crd, appendlayerdir, wildcard_version, no_remove, 
> > no_report_remove, initial_rev, dry_run_outdir, force_patch_refresh)
> >File 
> > 

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Otavio Salvador]

Em sex., 4 de mar. de 2022 às 13:56, Khem Raj  escreveu:

> There are recipes in meta-oe and meta-python which would need this
> and both layer only list core as sole dependency, if we put it in either of
> these layers, then one will depend on other which is not nice, so I rather
> would prefer it in core.


Couldn't those recipes (depending on Python) go to meta-python?

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162750): 
https://lists.openembedded.org/g/openembedded-core/message/162750
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [AUH] rust-llvm: upgrading to 1.59.0 FAILED

[Randy MacLeod]

FYI: 1.59 release notes:
   https://blog.rust-lang.org/2022/02/24/Rust-1.59.0.html


While there are interesting features in 1.59, such as the inline 
assembly support,

we are in feature freeze so I expect we'll stick with 1.58.1 .

It probably also makes sense to skip 1.59 and wait for 1.60 in early May 
for 3.6

depending on when we branch 3.5.

../Randy

On 2022-03-03 12:42, a...@yoctoproject.org wrote:

Hello,

this email is a notification from the Auto Upgrade Helper
that the automatic attempt to upgrade the recipe *rust-llvm* to *1.59.0* has 
Failed (devtool error).

Detailed error information:

The following devtool command failed:  finish -f rust-llvm 
/home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust
NOTE: Starting bitbake server...
Loading cache...done.
Loaded 1521 entries from dependency cache.
Parsing recipes...done.
Parsing of 844 .bb files complete (843 cached, 1 parsed). 1523 targets, 34 
skipped, 0 masked, 0 errors.

ERROR: Traceback (most recent call last):
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
 line 162, in wrapped
 return func(fn, *args)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
 line 187, in parse_config_file
 return bb.parse.handle(fn, data, include)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
 line 107, in handle
 return h['handle'](fn, data, include)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
 line 118, in handle
 abs_fn = resolve_file(fn, data)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
 line 131, in resolve_file
 raise IOError(errno.ENOENT, "file %s not found" % fn)
FileNotFoundError: [Errno 2] file 
/home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
 not found

ERROR: Unable to parse 
/home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf:
 [Errno 2] file 
/home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
 not found
Traceback (most recent call last):
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
 line 162, in wrapped
 return func(fn, *args)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
 line 187, in parse_config_file
 return bb.parse.handle(fn, data, include)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
 line 107, in handle
 return h['handle'](fn, data, include)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py",
 line 118, in handle
 abs_fn = resolve_file(fn, data)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/parse/__init__.py",
 line 131, in resolve_file
 raise IOError(errno.ENOENT, "file %s not found" % fn)
FileNotFoundError: [Errno 2] file 
/home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-devtools/rust/conf/layer.conf
 not found

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/devtool", line 
334, in 
 ret = main()
   File "/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/devtool", 
line 321, in main
 ret = args.func(args, config, basepath, workspace)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/lib/devtool/standard.py",
 line 2108, in finish
 updated, appendfile, removed = _update_recipe(args.recipename, workspace, 
rd, args.mode, appendlayerdir, wildcard_version=True, no_remove=False, 
no_report_remove=removing_original, initial_rev=args.initial_rev, 
dry_run_outdir=dry_run_outdir, no_overrides=args.no_overrides, 
force_patch_refresh=args.force_patch_refresh)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/lib/devtool/standard.py",
 line 1814, in _update_recipe
 updated, appendf, removed = _update_recipe_patch(recipename, workspace, 
srctree, crd, appendlayerdir, wildcard_version, no_remove, no_report_remove, 
initial_rev, dry_run_outdir, force_patch_refresh)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/scripts/lib/devtool/standard.py",
 line 1671, in _update_recipe_patch
 redirect_output=dry_run_outdir)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/meta/lib/oe/recipeutils.py", 
line 705, in bbappend_recipe
 appendpath, pathok = get_bbappend_path(rd, destlayerdir, wildcardver)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/meta/lib/oe/recipeutils.py", 
line 632, in get_bbappend_path
 confdata = bb.cookerdata.parse_config_file(destlayerconf, confdata)
   File 
"/home/pokybuild/yocto-worker/auh/build/build/poky/bitbake/lib/bb/cookerdata.py",
 line 

[OE-core] [PATCH v2] python3-importlib-metadata: upgrade 4.10.1 -> 4.11.2

[Tim Orling]

inherit setuptools_build_meta

v4.11.2
369: Fixed bug where EntryPoint.extras was returning match objects and not the 
extras strings.

v4.11.1
367: In Distribution.requires for egg-info, if requires.txt is empty, return an 
empty list.

v4.11.0
bpo-46246: Added __slots__ to EntryPoints.

v4.10.2
365 and bpo-46546: Avoid leaking method_name in DeprecatedList.

Signed-off-by: Tim Orling 
---
Change in v2:
  * _actually_ inherit setuptools_build_meta

 ...etadata_4.10.1.bb => python3-importlib-metadata_4.11.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-devtools/python/{python3-importlib-metadata_4.10.1.bb => 
python3-importlib-metadata_4.11.2.bb} (83%)

diff --git a/meta/recipes-devtools/python/python3-importlib-metadata_4.10.1.bb 
b/meta/recipes-devtools/python/python3-importlib-metadata_4.11.2.bb
similarity index 83%
rename from meta/recipes-devtools/python/python3-importlib-metadata_4.10.1.bb
rename to meta/recipes-devtools/python/python3-importlib-metadata_4.11.2.bb
index ff40def563f..25be7e7fb67 100644
--- a/meta/recipes-devtools/python/python3-importlib-metadata_4.10.1.bb
+++ b/meta/recipes-devtools/python/python3-importlib-metadata_4.11.2.bb
@@ -3,12 +3,12 @@ HOMEPAGE = "https://pypi.org/project/importlib-metadata/;
 LICENSE = "Apache-2.0"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=e88ae122f3925d8bde8319060f2ddb8e"
 
-inherit pypi setuptools3
+inherit pypi setuptools_build_meta
 
 PYPI_PACKAGE = "importlib_metadata"
 UPSTREAM_CHECK_REGEX = "/importlib-metadata/(?P(\d+[\.\-_]*)+)/"
 
-SRC_URI[sha256sum] = 
"951f0d8a5b7260e9db5e41d429285b5f451e928479f19d80818878527d36e95e"
+SRC_URI[sha256sum] = 
"b36ffa925fe3139b2f6ff11d6925ffd4fa7bc47870165e3ac260ac7b4f91e6ac"
 
 S = "${WORKDIR}/importlib_metadata-${PV}"
 
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162748): 
https://lists.openembedded.org/g/openembedded-core/message/162748
Mute This Topic: https://lists.openembedded.org/mt/89553826/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] bmap-tools: remove redundant python3native inherit

[Ross Burton]

setuptools3 pulls this in, so there's no need to explicitly inherit it.

Signed-off-by: Ross Burton 
---
 meta/recipes-support/bmap-tools/bmap-tools_git.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_git.bb 
b/meta/recipes-support/bmap-tools/bmap-tools_git.bb
index e3315321ed..c5acdc5cbf 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_git.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_git.bb
@@ -21,7 +21,6 @@ UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
 # Need df from coreutils
 RDEPENDS:${PN} = "python3-core python3-compression python3-mmap 
python3-setuptools python3-fcntl python3-six coreutils"
 
-inherit python3native
 inherit setuptools3
 
 PIP_INSTALL_PACKAGE = "bmap_tools"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162747): 
https://lists.openembedded.org/g/openembedded-core/message/162747
Mute This Topic: https://lists.openembedded.org/mt/89553821/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] setuptools3.bbclass: clean up

[Ross Burton]

There's been a lot of work in this class lately, so a little spring
cleaning is needed.

Create wheels verbosely to help debug problems.

Remove unused SETUPTOOLS_INSTALL_ARGS, these can't be passed to
bdist_wheel.

Remove duplicate manipulation of files in bindir as pip_install_wheel
does the same.

Remove obsolete deletion of easy-install.pth, wheels don't generate that.

Remove obsolete ${datadir}/share fixup, pip-installed wheels can't
generate that path combination.

Remove purging of ${D} references from *.py, these won't be written by
standard setuptools, and recipes can do it themselves to work around
specific issues if needed.

Remove obsolete vardepsexclude of MACHINE on do_install, as that variable
isn't referenced.

Signed-off-by: Ross Burton 

fixup! setuptools3.bbclass: clean up
---
 meta/classes/setuptools3.bbclass | 34 +---
 1 file changed, 1 insertion(+), 33 deletions(-)

diff --git a/meta/classes/setuptools3.bbclass b/meta/classes/setuptools3.bbclass
index 564996c556..1b1a8aac76 100644
--- a/meta/classes/setuptools3.bbclass
+++ b/meta/classes/setuptools3.bbclass
@@ -4,13 +4,6 @@ inherit setuptools3-base pip_install_wheel
 #B = "${WORKDIR}/build"
 
 SETUPTOOLS_BUILD_ARGS ?= ""
-SETUPTOOLS_INSTALL_ARGS ?= "--root=${D} \
---prefix=${prefix} \
---install-lib=${PYTHON_SITEPACKAGES_DIR} \
---install-data=${datadir}"
-
-SETUPTOOLS_PYTHON = "python3"
-SETUPTOOLS_PYTHON:class-native = "nativepython3"
 
 SETUPTOOLS_SETUP_PATH ?= "${S}"
 
@@ -24,42 +17,17 @@ setuptools3_do_compile() {
 STAGING_INCDIR=${STAGING_INCDIR} \
 STAGING_LIBDIR=${STAGING_LIBDIR} \
 ${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
-bdist_wheel ${SETUPTOOLS_BUILD_ARGS} || \
+bdist_wheel --verbose ${SETUPTOOLS_BUILD_ARGS} || \
 bbfatal_log "'${PYTHON_PN} setup.py bdist_wheel 
${SETUPTOOLS_BUILD_ARGS}' execution failed."
 }
 setuptools3_do_compile[vardepsexclude] = "MACHINE"
 do_compile[cleandirs] += "${SETUPTOOLS_SETUP_PATH}/dist"
 
 setuptools3_do_install() {
-cd ${SETUPTOOLS_SETUP_PATH}
-
 pip_install_wheel_do_install
-
-# support filenames with *spaces*
-find ${D} -name "*.py" -exec grep -q ${D} {} \; \
-   -exec sed -i -e s:${D}::g {} \;
-
-for i in ${D}${bindir}/* ${D}${sbindir}/*; do
-if [ -f "$i" ]; then
-sed -i -e s:${PYTHON}:${USRBINPATH}/env\ 
${SETUPTOOLS_PYTHON}:g $i
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-fi
-done
-
-rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
-
-#
-# FIXME: Bandaid against wrong datadir computation
-#
-if [ -e ${D}${datadir}/share ]; then
-mv -f ${D}${datadir}/share/* ${D}${datadir}/
-rmdir ${D}${datadir}/share
-fi
 }
-setuptools3_do_install[vardepsexclude] = "MACHINE"
 
 EXPORT_FUNCTIONS do_configure do_compile do_install
 
 export LDSHARED="${CCLD} -shared"
 DEPENDS += "python3-setuptools-native python3-wheel-native"
-
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162745): 
https://lists.openembedded.org/g/openembedded-core/message/162745
Mute This Topic: https://lists.openembedded.org/mt/89553657/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/3] asciidoc: update git repository

[Ross Burton]

The asciidoc-py3 repository has been renamed to asciidoc-py.

Signed-off-by: Ross Burton 
---
 meta/recipes-extended/asciidoc/asciidoc_10.1.3.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/asciidoc/asciidoc_10.1.3.bb 
b/meta/recipes-extended/asciidoc/asciidoc_10.1.3.bb
index 34bf2550f5..fc8cbc89c8 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_10.1.3.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_10.1.3.bb
@@ -8,7 +8,7 @@ LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=4e5d1baf6f20559e3bec172226a47e4e \
 file://LICENSE;md5=b234ee4d69f5fce4486a80fdaf4a4263 "
 
-SRC_URI = "git://github.com/asciidoc/asciidoc-py3;protocol=https;branch=main"
+SRC_URI = "git://github.com/asciidoc/asciidoc-py;protocol=https;branch=main"
 SRCREV = "342639edbbc0dcc64354a0291d2214d4d5e65cab"
 
 DEPENDS = "libxml2-native libxslt-native docbook-xml-dtd4-native 
docbook-xsl-stylesheets-native"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162744): 
https://lists.openembedded.org/g/openembedded-core/message/162744
Mute This Topic: https://lists.openembedded.org/mt/89553656/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/3] pip_install_wheel: clean up

[Ross Burton]

There's been a lot of work in this class lately, so a little spring
cleaning is needed.

Remove redundant creation of PYTHON_SITEPACKAGES_DIR, pip will do that.

Remove redundant export of PYPA_WHEEL.

Simplyify recompile code using "realpath --relative-to".

Signed-off-by: Ross Burton 
---
 meta/classes/pip_install_wheel.bbclass | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/meta/classes/pip_install_wheel.bbclass 
b/meta/classes/pip_install_wheel.bbclass
index 3beff685bb..1870b916fe 100644
--- a/meta/classes/pip_install_wheel.bbclass
+++ b/meta/classes/pip_install_wheel.bbclass
@@ -20,29 +20,20 @@ PIP_INSTALL_ARGS ?= "\
 --prefix=${prefix} \
 "
 
-pip_install_wheel_do_install:prepend () {
-install -d ${D}${PYTHON_SITEPACKAGES_DIR}
-}
-
-export PYPA_WHEEL
-
 PIP_INSTALL_PYTHON = "python3"
 PIP_INSTALL_PYTHON:class-native = "nativepython3"
 
 pip_install_wheel_do_install () {
 nativepython3 -m pip install ${PIP_INSTALL_ARGS} ${PYPA_WHEEL} ||
-bbfatal_log "Failed to pip install wheel. Check the logs."
+  bbfatal_log "Failed to pip install wheel. Check the logs."
 
+cd ${D}
 for i in ${D}${bindir}/* ${D}${sbindir}/*; do
 if [ -f "$i" ]; then
 sed -i -e "1s,#!.*nativepython3,#!${USRBINPATH}/env 
${PIP_INSTALL_PYTHON}," $i
 sed -i -e "s:${PYTHON}:${USRBINPATH}/env\ ${PIP_INSTALL_PYTHON}:g" 
$i
 sed -i -e "s:${STAGING_BINDIR_NATIVE}:${bindir}:g" $i
-# Recompile after modifying it
-cd ${D}
-file=`echo $i | sed 's:^${D}/::'`
-${STAGING_BINDIR_NATIVE}/python3-native/python3 -c "from 
py_compile import compile; compile('$file')"
-cd -
+nativepython3 -mpy_compile $(realpath --relative-to=${D} $i)
 fi
 done
 }
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162746): 
https://lists.openembedded.org/g/openembedded-core/message/162746
Mute This Topic: https://lists.openembedded.org/mt/89553658/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/3] layer.conf: Filter docs dependencies for efficiency

[Richard Purdie]

The net result of this series is that for a recipe like run-postinsts (allarch)
with api-documentation enabled, for the do_package task, the recipe-sysroot-
native no longer needs to contain: 

e2fsprogs-native
gperf-native
gtk-doc-native
libcap-ng-native
libpcre2-native
libxml2-native
libxslt-native
python3-flit-core-native
python3-pip-native
python3-pygments-native
python3-setuptools-native
python3-six-native
python3-wheel-native
unzip-native
util-linux-native

with the dependencies reduced to:

bzip2-native
curl-native
dwarfsrcfiles-native
elfutils-native
file-native
gdbm-native
gmp-native
gnutls-native
libarchive-native
libcap-native
libffi-native
libgcrypt-native
libgpg-error-native
libidn2-native
libmicrohttpd-native
libnsl2-native
libtirpc-native
libunistring-native
lua-native
lzo-native
ncurses-native
nettle-native
openssl-native
perlcross-native
perl-native
popt-native
python3-native
readline-native
rpm-native
sqlite3-native
util-linux-libuuid-native
xz-native
zlib-native
zstd-native

which does make a significant difference to the numbers of files.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162743): 
https://lists.openembedded.org/g/openembedded-core/message/162743
Mute This Topic: https://lists.openembedded.org/mt/89552837/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Khem Raj]

On Fri, Mar 4, 2022 at 6:06 AM Konrad Weihmann  wrote:
>
>
>
> On 04.03.22 14:13, Ross Burton wrote:
> > On Fri, 4 Mar 2022 at 12:44, Konrad Weihmann  wrote:
> >> For me that would be a candidate to be added to meta-python, or are
> >> there any core recipes that currently break because of the new behavior?
> >
> > This is restoring existing behaviour, so I believe it should be in
> > core.  There's going to be enough recipes using this that it is
> > justified in core. I expect we'll have deleted this by the time the
> > next LTS comes around too.
> >
> >> Furthermore the variables names are the same, so if people accidentally
> >> (or due to complex injection trees/classes/distro settings/whatever have
> >> new setuptools3 and this class here in the same recipe, things become
> >> rather unpredictable - as of now there are the same but surely they will
> >> start to diverge at one point.
> >
> > That's intentional: if you have a recipe which needs the legacy
> > behaviour, just change the import from setuptool3 to
> > setuptools3_legacy.
>
> Can you name any publicly available recipe that requires that?
>
> For me this is the same situation as with the python2 > python3
> transition - there wasn't any fallback provided in core, but outside of
> core it was - so I would propose to do the same here.
>
> If that legacy class will be part of core it's likely that it will
> remain till EOL of kirkstone which is somewhat in ~2025 (by current
> planning) - and meta-python2 showed that even then some recipes still
> haven't migrated (yes, chromium looking at you).

latest chromium does not need py2 in OE context anymore for a year or so now.

> All in all I think core should just provide *one* way to do it while the
> legacy cases can easily live outside in a separate layer (meta-python
> for instance as the "old" distutils have been put there as well).
>

There are recipes in meta-oe and meta-python which would need this
and both layer only list core as sole dependency, if we put it in either of
these layers, then one will depend on other which is not nice, so I rather
would prefer it in core.
, regarding distutils classes we did move them to meta-python but there
are recipes in meta-oe needing them e.g. unattended-upgrades which now
are forced to be moved to meta-python which is less than ideal but can
be lived with.

seuptool-legacy is similar to autotools-brokensep in spirit. python2 issue was
of a different nature

> In additional everyone was worried so much about reputation lately that
> doing this long announced transition, while keeping the "old" way
> enabled (and creating more maintenance effort in the end), would
> definitely send the wrong signal to the community.
>
> >
> >> While we are at it pypi class needs a fallback too, because for me this
> >> is the standard way of packaging python recipes and new class points to
> >> the new setuptools implementation - so if we want to have this here, we
> >> might need a fallback for pypi class as well
> >
> > My understanding is that almost anything on pypi is already a pure
> > Python module and is mostly unaffected by the changes.
> >
> > Ross
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162742): 
https://lists.openembedded.org/g/openembedded-core/message/162742
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/3] python3: Reduce util-linux dependency to util-linux-libuuid

[Richard Purdie]

Only libuuid is needed by python so reduce the dependency and hence
reduce the amount pulled into the syroot for the native case in particular.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/python/python3_3.10.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3_3.10.2.bb 
b/meta/recipes-devtools/python/python3_3.10.2.bb
index e61b23c6a9b..32da2a12c8d 100644
--- a/meta/recipes-devtools/python/python3_3.10.2.bb
+++ b/meta/recipes-devtools/python/python3_3.10.2.bb
@@ -71,7 +71,7 @@ ALTERNATIVE_LINK_NAME[python3-config] = 
"${bindir}/python${PYTHON_MAJMIN}-config
 ALTERNATIVE_TARGET[python3-config] = 
"${bindir}/python${PYTHON_MAJMIN}-config-${MULTILIB_SUFFIX}"
 
 
-DEPENDS = "bzip2-replacement-native libffi bzip2 openssl sqlite3 zlib 
virtual/libintl xz virtual/crypt util-linux libtirpc libnsl2 
autoconf-archive-native"
+DEPENDS = "bzip2-replacement-native libffi bzip2 openssl sqlite3 zlib 
virtual/libintl xz virtual/crypt util-linux-libuuid libtirpc libnsl2 
autoconf-archive-native"
 DEPENDS:append:class-target = " python3-native"
 DEPENDS:append:class-nativesdk = " python3-native"
 
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162741): 
https://lists.openembedded.org/g/openembedded-core/message/162741
Mute This Topic: https://lists.openembedded.org/mt/89552842/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/3] layer.conf: Add libarchive-native e2fsprogs-native exclusion from sysroot

[Richard Purdie]

Currently, libarchive-native pulls e2fsprogs and all it's dependencies into
the sysroot. Since only headers are needed at buildtime and there is no
runtime dependency, we can avoid this and shrink the native sysroots.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 8f30de5f6b4..3eda0b0ded9 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -91,6 +91,7 @@ SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += " \
 # (e.g. X -> Y -> binutils-cross -> bison-native) no longer meet the
 # dependency incidentally. This improves determinism and avoids build
 # failures when people switch to external toolchains.
+# libarchive only needs e2fsprogs headers at buildtime
 SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->autoconf-native \
 .*->automake-native \
@@ -104,6 +105,7 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->gperf-native \
 .*->gtk-doc-native \
 .*->texinfo-native \
+libarchive-native->e2fsprogs-native \
 "
 # Nothing needs to depend on libc-initial
 # base-passwd/shadow-sysroot don't need their dependencies
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162740): 
https://lists.openembedded.org/g/openembedded-core/message/162740
Mute This Topic: https://lists.openembedded.org/mt/89552838/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/3] layer.conf: Filter docs dependencies for efficiency

[Richard Purdie]

Where a recipe has depends on native docs tools, in most cases
we don't need recipes that depend on that recipe to also install
these things into the sysroot. We can rely on recipes wanting these
tools to have direct dependencies instead.

This massively reduced dependency creep in simple recipes (e.g. an
allarch one) and reduced the size of builds with the api-documentation
feature substancially.

gperf-native is also included since that would normally have a direct
dependency in a recipe which needs it too.

Signed-off-by: Richard Purdie 
---
 meta/conf/layer.conf | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index bdeb8a47589..8f30de5f6b4 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -100,6 +100,10 @@ SSTATE_EXCLUDEDEPS_SYSROOT += "\
 .*->patch-native \
 .*->pkgconfig-native \
 .*->quilt-native \
+.*->xmlto-native \
+.*->gperf-native \
+.*->gtk-doc-native \
+.*->texinfo-native \
 "
 # Nothing needs to depend on libc-initial
 # base-passwd/shadow-sysroot don't need their dependencies
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162739): 
https://lists.openembedded.org/g/openembedded-core/message/162739
Mute This Topic: https://lists.openembedded.org/mt/89552837/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] python3-importlib-metadata: upgrade 4.10.1 -> 4.11.2

[Tim Orling]

On Fri, Mar 4, 2022 at 2:13 AM Lee Chee Yang 
wrote:

> Error while do_compile
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3190/steps/11/logs/stdio
>
>
I just have missed committing a local change.

>
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Tim Orling
> > Sent: Friday, March 4, 2022 4:44 AM
> > To: openembedded-core@lists.openembedded.org
> > Cc: Tim Orling 
> > Subject: [OE-core] [PATCH 1/2] python3-importlib-metadata: upgrade 4.10.1
> > -> 4.11.2
> >
> > inherit setuptools_build_meta
> >
> > v4.11.2
> > 369: Fixed bug where EntryPoint.extras was returning match objects and
> not
> > the extras strings.
> >
> > v4.11.1
> > 367: In Distribution.requires for egg-info, if requires.txt is empty,
> return an
> > empty list.
> >
> > v4.11.0
> > bpo-46246: Added __slots__ to EntryPoints.
> >
> > v4.10.2
> > 365 and bpo-46546: Avoid leaking method_name in DeprecatedList.
> >
> > Signed-off-by: Tim Orling 
> > ---
> >  ...-metadata_4.10.1.bb => python3-importlib-metadata_4.11.2.bb} | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)  rename meta/recipes-
> > devtools/python/{python3-importlib-metadata_4.10.1.bb => python3-
> > importlib-metadata_4.11.2.bb} (88%)
> >
> > diff --git a/meta/recipes-devtools/python/python3-importlib-
> > metadata_4.10.1.bb b/meta/recipes-devtools/python/python3-importlib-
> > metadata_4.11.2.bb
> > similarity index 88%
> > rename from meta/recipes-devtools/python/python3-importlib-
> > metadata_4.10.1.bb
> > rename to meta/recipes-devtools/python/python3-importlib-
> > metadata_4.11.2.bb
> > index ff40def563f..15c468e41b7 100644
> > --- a/meta/recipes-devtools/python/python3-importlib-metadata_4.10.1.bb
> > +++ b/meta/recipes-devtools/python/python3-importlib-
> > metadata_4.11.2.bb
> > @@ -8,7 +8,7 @@ inherit pypi setuptools3  PYPI_PACKAGE =
> > "importlib_metadata"
> >  UPSTREAM_CHECK_REGEX = "/importlib-metadata/(?P(\d+[\.\-
> > _]*)+)/"
> >
> > -SRC_URI[sha256sum] =
> > "951f0d8a5b7260e9db5e41d429285b5f451e928479f19d80818878527d36e95e"
> > +SRC_URI[sha256sum] =
> > "b36ffa925fe3139b2f6ff11d6925ffd4fa7bc47870165e3ac260ac7b4f91e6ac"
> >
> >  S = "${WORKDIR}/importlib_metadata-${PV}"
> >
> > --
> > 2.30.2
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162738): 
https://lists.openembedded.org/g/openembedded-core/message/162738
Mute This Topic: https://lists.openembedded.org/mt/89534634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 18/18] uninative: Upgrade to 3.5

[Steve Sakoman]

From: Michael Halstead 

Add support for glibc 2.35.

Signed-off-by: Michael Halstead 
Signed-off-by: Richard Purdie 
(cherry picked from commit 347b8c87fb4e2c398644f900728cf6e22ba4516d)
Signed-off-by: Steve Sakoman 
---
 meta/conf/distro/include/yocto-uninative.inc | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 6833072cd3..bfe05ce1eb 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -6,10 +6,10 @@
 # to the distro running on the build machine.
 #
 
-UNINATIVE_MAXGLIBCVERSION = "2.34"
-UNINATIVE_VERSION = "3.4"
+UNINATIVE_MAXGLIBCVERSION = "2.35"
+UNINATIVE_VERSION = "3.5"
 
 UNINATIVE_URL ?= 
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/;
-UNINATIVE_CHECKSUM[aarch64] ?= 
"3013cdda8f0dc6639ce1c80f33eabce66f06b890bd5b58739a6d7a92a0bb7100"
-UNINATIVE_CHECKSUM[i686] ?= 
"abed500de584aad63ec237546db20cdd0c69d8870a6f8e94ac31721ace64b376"
-UNINATIVE_CHECKSUM[x86_64] ?= 
"126f4f7f6f21084ee140dac3eb4c536b963837826b7c38599db0b512c3377ba2"
+UNINATIVE_CHECKSUM[aarch64] ?= 
"6de0771bd21e0fcb5e80388e5b561a8023b24083bcbf46e056a089982aff75d7"
+UNINATIVE_CHECKSUM[i686] ?= 
"8c8745becbfa1c341bae839c7eab56ddf17ce36c303bcd73d3b2f2f788b631c2"
+UNINATIVE_CHECKSUM[x86_64] ?= 
"e8047a5748e6f266165da141eb6d08b23674f30e477b0e5505b6403d50fbc4b2"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162737): 
https://lists.openembedded.org/g/openembedded-core/message/162737
Mute This Topic: https://lists.openembedded.org/mt/89550483/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 17/18] uninative: Add version to uninative tarball name

[Steve Sakoman]

From: Richard Purdie 

uninative works via hashes and doesn't need the version in the tarball name but
it does make things easier to inspect in DL_DIR. There were reasons such as
ease of publication of the build tarballs but we can handle those differently
now and the signature issues from the early code aren't an issue now. From 3.4
onwards we can use a version'd name.

[YOCTO #12970]

Signed-off-by: Richard Purdie 
(cherry picked from commit dadba70d6a24d8ebb5576598efffa973151c7218)
Signed-off-by: Steve Sakoman 
---
 meta/classes/uninative.bbclass   | 2 +-
 meta/conf/distro/include/yocto-uninative.inc | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 3c7ccd66f4..4412d7c567 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -2,7 +2,7 @@ UNINATIVE_LOADER ?= 
"${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux/lib/
 UNINATIVE_STAGING_DIR ?= "${STAGING_DIR}"
 
 UNINATIVE_URL ?= "unset"
-UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.xz"
+UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc-${UNINATIVE_VERSION}.tar.xz"
 # Example checksums
 #UNINATIVE_CHECKSUM[aarch64] = "dead"
 #UNINATIVE_CHECKSUM[i686] = "dead"
diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 3165fc93b8..6833072cd3 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -7,8 +7,9 @@
 #
 
 UNINATIVE_MAXGLIBCVERSION = "2.34"
+UNINATIVE_VERSION = "3.4"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/3.4/;
+UNINATIVE_URL ?= 
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/;
 UNINATIVE_CHECKSUM[aarch64] ?= 
"3013cdda8f0dc6639ce1c80f33eabce66f06b890bd5b58739a6d7a92a0bb7100"
 UNINATIVE_CHECKSUM[i686] ?= 
"abed500de584aad63ec237546db20cdd0c69d8870a6f8e94ac31721ace64b376"
 UNINATIVE_CHECKSUM[x86_64] ?= 
"126f4f7f6f21084ee140dac3eb4c536b963837826b7c38599db0b512c3377ba2"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162736): 
https://lists.openembedded.org/g/openembedded-core/message/162736
Mute This Topic: https://lists.openembedded.org/mt/89550480/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 14/18] cml1.bbclass: Handle ncurses-native being available via pkg-config

[Steve Sakoman]

From: Nathan Rossi 

The linux kernel will by default use pkg-config to get ncurses(w) paths,
falling back to absolute path checks otherwise. If the build host does
not have ncurses installed this will fail as pkg-config will not search
the native sysroot for ncurses.

To more all kernel/kconfig sources, inject the equivalent native
pkg-config variables similar to what is done by the pkg-config-native
script. This only affects the menuconfig python task itself and the
oe_terminal call inside it.

(cherry picked from commit abb95c421bb67d452691819e3f63dabd02e2ba37)
Signed-off-by: Nathan Rossi 
Signed-off-by: Richard Purdie 
Signed-off-by: Steve Sakoman 
---
 meta/classes/cml1.bbclass | 8 
 1 file changed, 8 insertions(+)

diff --git a/meta/classes/cml1.bbclass b/meta/classes/cml1.bbclass
index 8ab240589a..46a19fce32 100644
--- a/meta/classes/cml1.bbclass
+++ b/meta/classes/cml1.bbclass
@@ -36,6 +36,14 @@ python do_menuconfig() {
 except OSError:
 mtime = 0
 
+# setup native pkg-config variables (kconfig scripts call pkg-config 
directly, cannot generically be overriden to pkg-config-native)
+d.setVar("PKG_CONFIG_DIR", 
"${STAGING_DIR_NATIVE}${libdir_native}/pkgconfig")
+d.setVar("PKG_CONFIG_PATH", 
"${PKG_CONFIG_DIR}:${STAGING_DATADIR_NATIVE}/pkgconfig")
+d.setVar("PKG_CONFIG_LIBDIR", "${PKG_CONFIG_DIR}")
+d.setVarFlag("PKG_CONFIG_SYSROOT_DIR", "unexport", "1")
+# ensure that environment variables are overwritten with this tasks 'd' 
values
+d.appendVar("OE_TERMINAL_EXPORTS", " PKG_CONFIG_DIR PKG_CONFIG_PATH 
PKG_CONFIG_LIBDIR PKG_CONFIG_SYSROOT_DIR")
+
 oe_terminal("sh -c \"make %s; if [ \\$? -ne 0 ]; then echo 'Command 
failed.'; printf 'Press any key to continue... '; read r; fi\"" % 
d.getVar('KCONFIG_CONFIG_COMMAND'),
 d.getVar('PN') + ' Configuration', d)
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162733): 
https://lists.openembedded.org/g/openembedded-core/message/162733
Mute This Topic: https://lists.openembedded.org/mt/89550472/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 16/18] buildhistory.bbclass: create the buildhistory directory when needed

[Steve Sakoman]

From: Jose Quaresma 

When the BUILDHISTORY_RESET is enabled we need to move the
content from BUILDHISTORY_DIR to BUILDHISTORY_OLD_DIR but
when we start a clean build in the first run we don't have the
BUILDHISTORY_DIR so the move of files will fail.

| ERROR: Command execution failed: Traceback (most recent call last):
|  File "/xxx/poky/bitbake/lib/bb/command.py", line 110, in runAsyncCommand
|commandmethod(self.cmds_async, self, options)
|  File "/xxx/poky/bitbake/lib/bb/command.py", line 564, in buildTargets
|command.cooker.buildTargets(pkgs_to_build, task)
|  File "/xxx/poky/bitbake/lib/bb/cooker.py", line 1481, in buildTargets
|bb.event.fire(bb.event.BuildStarted(buildname, ntargets), 
self.databuilder.mcdata[mc])
|  File "/xxx/home/builder/src/base/poky/bitbake/lib/bb/event.py", line 214, in 
fire
|fire_class_handlers(event, d)
|  File "/xxx/poky/bitbake/lib/bb/event.py", line 121, in fire_class_handlers
|execute_handler(name, handler, event, d)
|  File "/xxx/poky/bitbake/lib/bb/event.py", line 93, in execute_handler
|ret = handler(event)
|  File "/xxx/poky/meta/classes/buildhistory.bbclass", line 919, in 
buildhistory_eventhandler
|entries = [ x for x in os.listdir(rootdir) if not x.startswith('.') ]
| FileNotFoundError: [Errno 2] No such file or directory: '/xxx/buildhistory'

Signed-off-by: Jose Quaresma 
Signed-off-by: Richard Purdie 
(cherry picked from commit 97bc2168da7dbacdfbf79cd70db674363ab84f6b)
Signed-off-by: Steve Sakoman 
---
 meta/classes/buildhistory.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 2746996cbb..6a1a20653a 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -865,6 +865,7 @@ python buildhistory_eventhandler() {
 if os.path.isdir(olddir):
 shutil.rmtree(olddir)
 rootdir = e.data.getVar("BUILDHISTORY_DIR")
+bb.utils.mkdirhier(rootdir)
 entries = [ x for x in os.listdir(rootdir) if not 
x.startswith('.') ]
 bb.utils.mkdirhier(olddir)
 for entry in entries:
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162735): 
https://lists.openembedded.org/g/openembedded-core/message/162735
Mute This Topic: https://lists.openembedded.org/mt/89550477/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 15/18] libxml-parser-perl: Add missing RDEPENDS

[Steve Sakoman]

From: Richard Purdie 

Running the ptest package in an image alone highlighted missing module
dependencies. Add them to fix those errors.

Signed-off-by: Richard Purdie 
(cherry picked from commit 3859f49db2d694c7b63fdbe25be0018afba5c738)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/perl/libxml-parser-perl_2.46.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/perl/libxml-parser-perl_2.46.bb 
b/meta/recipes-devtools/perl/libxml-parser-perl_2.46.bb
index bc154bbdc5..ef2b292352 100644
--- a/meta/recipes-devtools/perl/libxml-parser-perl_2.46.bb
+++ b/meta/recipes-devtools/perl/libxml-parser-perl_2.46.bb
@@ -53,6 +53,7 @@ do_install_ptest() {
chown -R root:root ${D}${PTEST_PATH}/samples
 }
 
+RDEPENDS_${PN} += "perl-module-carp perl-module-file-spec"
 RDEPENDS_${PN}-ptest += "perl-module-filehandle perl-module-if 
perl-module-test perl-module-test-more"
 
 BBCLASSEXTEND="native nativesdk"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162734): 
https://lists.openembedded.org/g/openembedded-core/message/162734
Mute This Topic: https://lists.openembedded.org/mt/89550474/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 13/18] bootchart2: Add missing python3-math dependency

[Steve Sakoman]

From: Marek Vasut 

Without this dependency, generating the bootchart may fail with:
"
ModuleNotFoundError: No module named 'random'
"

(cherry picked from commit 487e9f16a00f895159b79f1865fe8b626b47ddc2)
Signed-off-by: Marek Vasut 
Cc: Mingli Yu 
Cc: Richard Purdie 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb 
b/meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb
index 66bd897a9a..7f05bd1b0b 100644
--- a/meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb
+++ b/meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb
@@ -144,7 +144,7 @@ do_install () {
 
 PACKAGES =+ "pybootchartgui"
 FILES_pybootchartgui += "${PYTHON_SITEPACKAGES_DIR}/pybootchartgui 
${bindir}/pybootchartgui"
-RDEPENDS_pybootchartgui = "python3-pycairo python3-compression python3-image 
python3-shell python3-compression python3-codecs"
+RDEPENDS_pybootchartgui = "python3-pycairo python3-compression python3-image 
python3-math python3-shell python3-compression python3-codecs"
 RDEPENDS_${PN}_class-target += "${@bb.utils.contains('DISTRO_FEATURES', 
'sysvinit', 'sysvinit-pidof', 'procps', d)}"
 RDEPENDS_${PN}_class-target += "lsb-release"
 DEPENDS_append_class-native = " python3-pycairo-native"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162732): 
https://lists.openembedded.org/g/openembedded-core/message/162732
Mute This Topic: https://lists.openembedded.org/mt/89550471/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 12/18] wireless-regdb: upgrade 2021.08.28 -> 2022.02.18

[Steve Sakoman]

From: wangmy 

Signed-off-by: Wang Mingyu 
Signed-off-by: Richard Purdie 
(cherry picked from commit e5c06ddfd3c0db0d0762c0241c019f59ad310e53)
Signed-off-by: Steve Sakoman 
---
 ...ireless-regdb_2021.08.28.bb => wireless-regdb_2022.02.18.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2021.08.28.bb => 
wireless-regdb_2022.02.18.bb} (94%)

diff --git a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2021.08.28.bb 
b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2022.02.18.bb
similarity index 94%
rename from meta/recipes-kernel/wireless-regdb/wireless-regdb_2021.08.28.bb
rename to meta/recipes-kernel/wireless-regdb/wireless-regdb_2022.02.18.bb
index 376311804e..4e6da4cbe1 100644
--- a/meta/recipes-kernel/wireless-regdb/wireless-regdb_2021.08.28.bb
+++ b/meta/recipes-kernel/wireless-regdb/wireless-regdb_2022.02.18.bb
@@ -5,7 +5,7 @@ LICENSE = "ISC"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=07c4f6dea3845b02a18dc00c8c87699c"
 
 SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz;
-SRC_URI[sha256sum] = 
"cff370c410d1e6d316ae0a7fa8ac6278fdf1efca5d3d664aca7cfd2aafa54446"
+SRC_URI[sha256sum] = 
"8828c25a4ee25020044004f57374bb9deac852809fad70f8d3d01770bf9ac97f"
 
 inherit bin_package allarch
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162731): 
https://lists.openembedded.org/g/openembedded-core/message/162731
Mute This Topic: https://lists.openembedded.org/mt/89550469/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 11/18] Revert "cve-check: add lockfile to task"

[Steve Sakoman]

From: Ross Burton 

Now that all of the functions in cve-check open the database read-only,
we can remove this lockfile.

This means cve-check can run in parallal again, improving runtimes
massively.

This reverts commit d55fbf4779483d2cfd71df78d0f733b599fef739.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit e60d149b41d14d177df20dbecaef943696df1586)
Signed-off-by: Steve Sakoman 
---
 meta/classes/cve-check.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 5369b7074c..75c5b92b96 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -110,7 +110,6 @@ python do_cve_check () {
 }
 
 addtask cve_check before do_build after do_fetch
-do_cve_check[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
 do_cve_check[depends] = "cve-update-db-native:do_fetch"
 do_cve_check[nostamp] = "1"
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162730): 
https://lists.openembedded.org/g/openembedded-core/message/162730
Mute This Topic: https://lists.openembedded.org/mt/89550468/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 10/18] cve-check: get_cve_info should open the database read-only

[Steve Sakoman]

From: Ross Burton 

All of the function in cve-check should open the database read-only, as
the only writer is the fetch task in cve-update-db.  However,
get_cve_info() was failing to do this, which might be causing locking
issues with sqlite.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit 8de517238f1f418d9af1ce312d99de04ce2e26fc)
Signed-off-by: Steve Sakoman 
---
 meta/classes/cve-check.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 6b627464a0..5369b7074c 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -323,7 +323,8 @@ def get_cve_info(d, cves):
 import sqlite3
 
 cve_data = {}
-conn = sqlite3.connect(d.getVar("CVE_CHECK_DB_FILE"))
+db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
+conn = sqlite3.connect(db_file, uri=True)
 
 for cve in cves:
 for row in conn.execute("SELECT * FROM NVD WHERE ID IS ?", (cve,)):
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162729): 
https://lists.openembedded.org/g/openembedded-core/message/162729
Mute This Topic: https://lists.openembedded.org/mt/89550465/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 09/18] coreutils: remove obsolete ignored CVE list

[Steve Sakoman]

From: Ross Burton 

Three CVEs were meant to be ignored via CVE_WHITELIST, but that wasn't
the correct variable name.

The CPEs for those CVEs mean that they don't get picked up in our report,
so just remove the assignment.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
(cherry picked from commit dea00faf30ec7c19b6b5ed4651b430ba3faf69ff)
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/coreutils/coreutils_8.31.bb | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb 
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index aabeee882c..3d569881e8 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -206,6 +206,3 @@ do_install_ptest () {
 }
 
 FILES_${PN}-ptest += "${bindir}/getlimits"
-
-# These are specific to Opensuse
-CVE_WHITELIST += "CVE-2013-0221 CVE-2013-0222 CVE-2013-0223"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162728): 
https://lists.openembedded.org/g/openembedded-core/message/162728
Mute This Topic: https://lists.openembedded.org/mt/89550464/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 08/18] expat: fix CVE-2022-25315

[Steve Sakoman]

In Expat (aka libexpat) before 2.4.5, there is an integer overflow
in storeRawNames.

Backport patch from:
https://github.com/libexpat/libexpat/pull/559/commits/eb0362808b4f9f1e2345a0cf203b8cc196d776d9

CVE: CVE-2022-25315

Signed-off-by: Steve Sakoman 
---
 .../expat/expat/CVE-2022-25315.patch  | 145 ++
 meta/recipes-core/expat/expat_2.2.9.bb|   1 +
 2 files changed, 146 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25315.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-25315.patch 
b/meta/recipes-core/expat/expat/CVE-2022-25315.patch
new file mode 100644
index 00..a39771d28a
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25315.patch
@@ -0,0 +1,145 @@
+From eb0362808b4f9f1e2345a0cf203b8cc196d776d9 Mon Sep 17 00:00:00 2001
+From: Samanta Navarro 
+Date: Tue, 15 Feb 2022 11:55:46 +
+Subject: [PATCH] Prevent integer overflow in storeRawNames
+
+It is possible to use an integer overflow in storeRawNames for out of
+boundary heap writes. Default configuration is affected. If compiled
+with XML_UNICODE then the attack does not work. Compiling with
+-fsanitize=address confirms the following proof of concept.
+
+The problem can be exploited by abusing the m_buffer expansion logic.
+Even though the initial size of m_buffer is a power of two, eventually
+it can end up a little bit lower, thus allowing allocations very close
+to INT_MAX (since INT_MAX/2 can be surpassed). This means that tag
+names can be parsed which are almost INT_MAX in size.
+
+Unfortunately (from an attacker point of view) INT_MAX/2 is also a
+limitation in string pools. Having a tag name of INT_MAX/2 characters
+or more is not possible.
+
+Expat can convert between different encodings. UTF-16 documents which
+contain only ASCII representable characters are twice as large as their
+ASCII encoded counter-parts.
+
+The proof of concept works by taking these three considerations into
+account:
+
+1. Move the m_buffer size slightly below a power of two by having a
+   short root node . This allows the m_buffer to grow very close
+   to INT_MAX.
+2. The string pooling forbids tag names longer than or equal to
+   INT_MAX/2, so keep the attack tag name smaller than that.
+3. To be able to still overflow INT_MAX even though the name is
+   limited at INT_MAX/2-1 (nul byte) we use UTF-16 encoding and a tag
+   which only contains ASCII characters. UTF-16 always stores two
+   bytes per character while the tag name is converted to using only
+   one. Our attack node byte count must be a bit higher than
+   2/3 INT_MAX so the converted tag name is around INT_MAX/3 which
+   in sum can overflow INT_MAX.
+
+Thanks to our small root node, m_buffer can handle 2/3 INT_MAX bytes
+without running into INT_MAX boundary check. The string pooling is
+able to store INT_MAX/3 as tag name because the amount is below
+INT_MAX/2 limitation. And creating the sum of both eventually overflows
+in storeRawNames.
+
+Proof of Concept:
+
+1. Compile expat with -fsanitize=address.
+
+2. Create Proof of Concept binary which iterates through input
+   file 16 MB at once for better performance and easier integer
+   calculations:
+
+```
+cat > poc.c << EOF
+ #include 
+ #include 
+ #include 
+ #include 
+
+ #define CHUNK (16 * 1024 * 1024)
+ int main(int argc, char *argv[]) {
+   XML_Parser parser;
+   FILE *fp;
+   char *buf;
+   int i;
+
+   if (argc != 2)
+ errx(1, "usage: poc file.xml");
+   if ((parser = XML_ParserCreate(NULL)) == NULL)
+ errx(1, "failed to create expat parser");
+   if ((fp = fopen(argv[1], "r")) == NULL) {
+ XML_ParserFree(parser);
+ err(1, "failed to open file");
+   }
+   if ((buf = malloc(CHUNK)) == NULL) {
+ fclose(fp);
+ XML_ParserFree(parser);
+ err(1, "failed to allocate buffer");
+   }
+   i = 0;
+   while (fread(buf, CHUNK, 1, fp) == 1) {
+ printf("iteration %d: XML_Parse returns %d\n", ++i,
+   XML_Parse(parser, buf, CHUNK, XML_FALSE));
+   }
+   free(buf);
+   fclose(fp);
+   XML_ParserFree(parser);
+   return 0;
+ }
+EOF
+gcc -fsanitize=address -lexpat -o poc poc.c
+```
+
+3. Construct specially prepared UTF-16 XML file:
+
+```
+dd if=/dev/zero bs=1024 count=794624 | tr '\0' 'a' > poc-utf8.xml
+echo -n '<' | dd conv=notrunc of=poc-utf8.xml
+echo -n '><' | dd conv=notrunc of=poc-utf8.xml bs=1 seek=805306368
+iconv -f UTF-8 -t UTF-16LE poc-utf8.xml > poc-utf16.xml
+```
+
+4. Run proof of concept:
+
+```
+./poc poc-utf16.xml
+```
+
+Upstream-Status: Backport
+https://github.com/libexpat/libexpat/pull/559/commits/eb0362808b4f9f1e2345a0cf203b8cc196d776d9
+
+CVE: CVE-2022-25315
+
+Signed-off-by: Steve Sakoman 
+---
+ lib/xmlparse.c | 7 ++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index 4b43e613..f34d6ab5 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -2563,6 +2563,7 @@ storeRawNames(XML_Parser parser) {
+   while (tag) {
+ int bufSize;
+ int 

[OE-core][dunfell 07/18] expat: fix CVE-2022-25314

[Steve Sakoman]

In Expat (aka libexpat) before 2.4.5, there is an integer overflow in
copyString.

Backport patch from:
https://github.com/libexpat/libexpat/pull/560/commits/efcb347440ade24b9f1054671e6bd05e60b4cafd

CVE: CVE-2022-25314

Signed-off-by: Steve Sakoman 
---
 .../expat/expat/CVE-2022-25314.patch  | 32 +++
 meta/recipes-core/expat/expat_2.2.9.bb|  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25314.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-25314.patch 
b/meta/recipes-core/expat/expat/CVE-2022-25314.patch
new file mode 100644
index 00..2f713ebb54
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25314.patch
@@ -0,0 +1,32 @@
+From efcb347440ade24b9f1054671e6bd05e60b4cafd Mon Sep 17 00:00:00 2001
+From: Samanta Navarro 
+Date: Tue, 15 Feb 2022 11:56:57 +
+Subject: [PATCH] Prevent integer overflow in copyString
+
+The copyString function is only used for encoding string supplied by
+the library user.
+
+Upstream-Status: Backport
+https://github.com/libexpat/libexpat/pull/560/commits/efcb347440ade24b9f1054671e6bd05e60b4cafd
+
+CVE: CVE-2022-25314
+
+Signed-off-by: Steve Sakoman 
+
+---
+ expat/lib/xmlparse.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index 4b43e613..a39377c2 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -7412,7 +7412,7 @@ getElementType(XML_Parser parser, const ENCODING *enc, 
const char *ptr,
+ 
+ static XML_Char *
+ copyString(const XML_Char *s, const XML_Memory_Handling_Suite *memsuite) {
+-  int charsRequired = 0;
++  size_t charsRequired = 0;
+   XML_Char *result;
+ 
+   /* First determine how long the string is */
diff --git a/meta/recipes-core/expat/expat_2.2.9.bb 
b/meta/recipes-core/expat/expat_2.2.9.bb
index 4d945a295e..dd8eeddf80 100644
--- a/meta/recipes-core/expat/expat_2.2.9.bb
+++ b/meta/recipes-core/expat/expat_2.2.9.bb
@@ -17,6 +17,7 @@ SRC_URI = 
"git://github.com/libexpat/libexpat.git;protocol=https;branch=master \
file://CVE-2022-25236.patch \
file://CVE-2022-25313.patch \
file://CVE-2022-25313-regression.patch \
+   file://CVE-2022-25314.patch \
file://libtool-tag.patch \
  "
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162726): 
https://lists.openembedded.org/g/openembedded-core/message/162726
Mute This Topic: https://lists.openembedded.org/mt/89550462/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 06/18] expat: fix CVE-2022-25313

[Steve Sakoman]

In Expat (aka libexpat) before 2.4.5, an attacker can trigger stack
exhaustion in build_model via a large nesting depth in the DTD element.

Backport patch from:
https://github.com/libexpat/libexpat/pull/558/commits/9b4ce651b26557f16103c3a366c91934ecd439ab

Also add patch which fixes a regression introduced in the above fix:
https://github.com/libexpat/libexpat/pull/566

CVE: CVE-2022-25313

Signed-off-by: Steve Sakoman 
---
 .../expat/CVE-2022-25313-regression.patch | 131 ++
 .../expat/expat/CVE-2022-25313.patch  | 230 ++
 meta/recipes-core/expat/expat_2.2.9.bb|   2 +
 3 files changed, 363 insertions(+)
 create mode 100644 
meta/recipes-core/expat/expat/CVE-2022-25313-regression.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25313.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-25313-regression.patch 
b/meta/recipes-core/expat/expat/CVE-2022-25313-regression.patch
new file mode 100644
index 00..af255e8cb5
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25313-regression.patch
@@ -0,0 +1,131 @@
+From b12f34fe32821a69dc12ff9a021daca0856de238 Mon Sep 17 00:00:00 2001
+From: Samanta Navarro 
+Date: Sat, 19 Feb 2022 23:59:25 +
+Subject: [PATCH] Fix build_model regression.
+
+The iterative approach in build_model failed to fill children arrays
+correctly. A preorder traversal is not required and turned out to be the
+culprit. Use an easier algorithm:
+
+Add nodes from scaffold tree starting at index 0 (root) to the target
+array whenever children are encountered. This ensures that children
+are adjacent to each other. This complies with the recursive version.
+
+Store only the scaffold index in numchildren field to prevent a direct
+processing of these children, which would require a recursive solution.
+This allows the algorithm to iterate through the target array from start
+to end without jumping back and forth, converting on the fly.
+
+Co-authored-by: Sebastian Pipping 
+---
+ lib/xmlparse.c | 79 ++--
+ 1 file changed, 47 insertions(+), 32 deletions(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index c479a258..84885b5a 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -7373,39 +7373,58 @@ build_model(XML_Parser parser) {
+*
+* The iterative approach works as follows:
+*
+-   * - We use space in the target array for building a temporary stack 
structure
+-   *   while that space is still unused.
+-   *   The stack grows from the array's end downwards and the "actual data"
+-   *   grows from the start upwards, sequentially.
+-   *   (Because stack grows downwards, pushing onto the stack is a decrement
+-   *   while popping off the stack is an increment.)
++   * - We have two writing pointers, both walking up the result array; one 
does
++   *   the work, the other creates "jobs" for its colleague to do, and leads
++   *   the way:
+*
+-   * - A stack element appears as a regular XML_Content node on the outside,
+-   *   but only uses a single field -- numchildren -- to store the source
+-   *   tree node array index.  These are the breadcrumbs leading the way back
+-   *   during pre-order (node first) depth-first traversal.
++   *   - The faster one, pointer jobDest, always leads and writes "what job
++   * to do" by the other, once they reach that place in the
++   * array: leader "jobDest" stores the source node array index (relative
++   * to array dtd->scaffold) in field "numchildren".
+*
+-   * - The reason we know the stack will never grow into (or overlap with)
+-   *   the area with data of value at the start of the array is because
+-   *   the overall number of elements to process matches the size of the 
array,
+-   *   and the sum of fully processed nodes and yet-to-be processed nodes
+-   *   on the stack, cannot be more than the total number of nodes.
+-   *   It is possible for the top of the stack and the about-to-write node
+-   *   to meet, but that is safe because we get the source index out
+-   *   before doing any writes on that node.
++   *   - The slower one, pointer dest, looks at the value stored in the
++   * "numchildren" field (which actually holds a source node array index
++   * at that time) and puts the real data from dtd->scaffold in.
++   *
++   * - Before the loop starts, jobDest writes source array index 0
++   *   (where the root node is located) so that dest will have something to do
++   *   when it starts operation.
++   *
++   * - Whenever nodes with children are encountered, jobDest appends
++   *   them as new jobs, in order.  As a result, tree node siblings are
++   *   adjacent in the resulting array, for example:
++   *
++   * [0] root, has two children
++   *   [1] first child of 0, has three children
++   * [3] first child of 1, does not have children
++   * [4] second child of 1, does not have children
++   * [5] third child of 1, does not 

[OE-core][dunfell 05/18] expat: fix CVE-2022-25236

[Steve Sakoman]

xmlparse.c in Expat (aka libexpat) before 2.4.5 allows
attackers to insert namespace-separator characters into
namespace URIs.

Backport patches from:
https://github.com/libexpat/libexpat/pull/561/commits

CVE: CVE-2022-25236

Signed-off-by: Steve Sakoman 
---
 .../expat/expat/CVE-2022-25236.patch  | 129 ++
 meta/recipes-core/expat/expat_2.2.9.bb|   1 +
 2 files changed, 130 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25236.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-25236.patch 
b/meta/recipes-core/expat/expat/CVE-2022-25236.patch
new file mode 100644
index 00..ba6443fc6a
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25236.patch
@@ -0,0 +1,129 @@
+From 6881a4fc8596307ab9ff2e85e605afa2e413ab71 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Sat, 12 Feb 2022 00:19:13 +0100
+Subject: [PATCH] lib: Fix (harmless) use of uninitialized memory
+
+Upstream-Status: Backport
+https://github.com/libexpat/libexpat/pull/561/commits
+
+CVE: CVE-2022-25236
+
+Signed-off-by: Steve Sakoman 
+
+---
+ expat/lib/xmlparse.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index 902895d5..c768f856 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -718,8 +718,7 @@ XML_ParserCreate(const XML_Char *encodingName) {
+ 
+ XML_Parser XMLCALL
+ XML_ParserCreateNS(const XML_Char *encodingName, XML_Char nsSep) {
+-  XML_Char tmp[2];
+-  *tmp = nsSep;
++  XML_Char tmp[2] = {nsSep, 0};
+   return XML_ParserCreate_MM(encodingName, NULL, tmp);
+ }
+ 
+@@ -1344,8 +1343,7 @@ XML_ExternalEntityParserCreate(XML_Parser oldParser, 
const XML_Char *context,
+  would be otherwise.
+   */
+   if (parser->m_ns) {
+-XML_Char tmp[2];
+-*tmp = parser->m_namespaceSeparator;
++XML_Char tmp[2] = {parser->m_namespaceSeparator, 0};
+ parser = parserCreate(encodingName, >m_mem, tmp, newDtd);
+   } else {
+ parser = parserCreate(encodingName, >m_mem, NULL, newDtd);
+From a2fe525e660badd64b6c557c2b1ec26ddc07f6e4 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Sat, 12 Feb 2022 01:09:29 +0100
+Subject: [PATCH] lib: Protect against malicious namespace declarations
+ (CVE-2022-25236)
+
+---
+ expat/lib/xmlparse.c | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index c768f856..a3aef88c 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -3754,6 +3754,17 @@ addBinding(XML_Parser parser, PREFIX *prefix, const 
ATTRIBUTE_ID *attId,
+ if (! mustBeXML && isXMLNS
+ && (len > xmlnsLen || uri[len] != xmlnsNamespace[len]))
+   isXMLNS = XML_FALSE;
++
++// NOTE: While Expat does not validate namespace URIs against RFC 3986,
++//   we have to at least make sure that the XML processor on top of
++//   Expat (that is splitting tag names by namespace separator into
++//   2- or 3-tuples (uri-local or uri-local-prefix)) cannot be 
confused
++//   by an attacker putting additional namespace separator characters
++//   into namespace declarations.  That would be ambiguous and not to
++//   be expected.
++if (parser->m_ns && (uri[len] == parser->m_namespaceSeparator)) {
++  return XML_ERROR_SYNTAX;
++}
+   }
+   isXML = isXML && len == xmlLen;
+   isXMLNS = isXMLNS && len == xmlnsLen;
+From 2de077423fb22750ebea599677d523b53cb93b1d Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Sat, 12 Feb 2022 00:51:43 +0100
+Subject: [PATCH] tests: Cover CVE-2022-25236
+
+---
+ expat/tests/runtests.c | 30 ++
+ 1 file changed, 30 insertions(+)
+
+diff --git a/tests/runtests.c b/tests/runtests.c
+index d07203f2..bc5344b1 100644
+--- a/tests/runtests.c
 b/tests/runtests.c
+@@ -7220,6 +7220,35 @@ START_TEST(test_ns_double_colon_doctype) {
+ }
+ END_TEST
+ 
++START_TEST(test_ns_separator_in_uri) {
++  struct test_case {
++enum XML_Status expectedStatus;
++const char *doc;
++  };
++  struct test_case cases[] = {
++  {XML_STATUS_OK, ""},
++  {XML_STATUS_ERROR, ""},
++  };
++
++  size_t i = 0;
++  size_t failCount = 0;
++  for (; i < sizeof(cases) / sizeof(cases[0]); i++) {
++XML_Parser parser = XML_ParserCreateNS(NULL, '\n');
++XML_SetElementHandler(parser, dummy_start_element, dummy_end_element);
++if (XML_Parse(parser, cases[i].doc, (int)strlen(cases[i].doc),
++  /*isFinal*/ XML_TRUE)
++!= cases[i].expectedStatus) {
++  failCount++;
++}
++XML_ParserFree(parser);
++  }
++
++  if (failCount) {
++fail("Namespace separator handling is broken");
++  }
++}
++END_TEST
++
+ /* Control variable; the number of times duff_allocator() will successfully
+  * allocate */
+ #define ALLOC_ALWAYS_SUCCEED (-1)
+@@ -11905,6 +11934,7 @@ make_suite(void) {
+   tcase_add_test(tc_namespace, test_ns_utf16_doctype);
+   tcase_add_test(tc_namespace, test_ns_invalid_doctype);
+   

[OE-core][dunfell 04/18] expat: fix CVE-2022-25235

[Steve Sakoman]

xmltok_impl.c in Expat (aka libexpat) before 2.4.5 lacks certain
validation of encoding, such as checks for whether a UTF-8 character
is valid in a certain context.

Backport patches from:
https://github.com/libexpat/libexpat/pull/562/commits

CVE: CVE-2022-25235

Signed-off-by: Steve Sakoman 
---
 .../expat/expat/CVE-2022-25235.patch  | 283 ++
 meta/recipes-core/expat/expat_2.2.9.bb|   1 +
 2 files changed, 284 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25235.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2022-25235.patch 
b/meta/recipes-core/expat/expat/CVE-2022-25235.patch
new file mode 100644
index 00..be9182a5c1
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2022-25235.patch
@@ -0,0 +1,283 @@
+From ee2a5b50e7d1940ba8745715b62ceb9efd3a96da Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Tue, 8 Feb 2022 17:37:14 +0100
+Subject: [PATCH] lib: Drop unused macro UTF8_GET_NAMING
+
+Upstream-Status: Backport
+https://github.com/libexpat/libexpat/pull/562/commits
+
+CVE: CVE-2022-25235
+
+Signed-off-by: Steve Sakoman 
+
+---
+ expat/lib/xmltok.c | 5 -
+ 1 file changed, 5 deletions(-)
+
+diff --git a/lib/xmltok.c b/lib/xmltok.c
+index a72200e8..3bddf125 100644
+--- a/lib/xmltok.c
 b/lib/xmltok.c
+@@ -95,11 +95,6 @@
+ + byte)[1]) & 3) << 1) + byte)[2]) >> 5) & 1)]
 \
+& (1u << (((byte)[2]) & 0x1F)))
+ 
+-#define UTF8_GET_NAMING(pages, p, n)  
 \
+-  ((n) == 2   
 \
+-   ? UTF8_GET_NAMING2(pages, (const unsigned char *)(p))  
 \
+-   : ((n) == 3 ? UTF8_GET_NAMING3(pages, (const unsigned char *)(p)) : 0))
+-
+ /* Detection of invalid UTF-8 sequences is based on Table 3.1B
+of Unicode 3.2: http://www.unicode.org/unicode/reports/tr28/
+with the additional restriction of not allowing the Unicode
+From 3f0a0cb644438d4d8e3294cd0b1245d0edb0c6c6 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Tue, 8 Feb 2022 04:32:20 +0100
+Subject: [PATCH] lib: Add missing validation of encoding (CVE-2022-25235)
+
+---
+ expat/lib/xmltok_impl.c | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/lib/xmltok_impl.c b/lib/xmltok_impl.c
+index 0430591b4..64a3b2c15 100644
+--- a/lib/xmltok_impl.c
 b/lib/xmltok_impl.c
+@@ -61,7 +61,7 @@
+   case BT_LEAD##n:
 \
+ if (end - ptr < n)
 \
+   return XML_TOK_PARTIAL_CHAR;
 \
+-if (! IS_NAME_CHAR(enc, ptr, n)) {
 \
++if (IS_INVALID_CHAR(enc, ptr, n) || ! IS_NAME_CHAR(enc, ptr, n)) {
 \
+   *nextTokPtr = ptr;  
 \
+   return XML_TOK_INVALID; 
 \
+ } 
 \
+@@ -90,7 +90,7 @@
+   case BT_LEAD##n:
 \
+ if (end - ptr < n)
 \
+   return XML_TOK_PARTIAL_CHAR;
 \
+-if (! IS_NMSTRT_CHAR(enc, ptr, n)) {  
 \
++if (IS_INVALID_CHAR(enc, ptr, n) || ! IS_NMSTRT_CHAR(enc, ptr, n)) {  
 \
+   *nextTokPtr = ptr;  
 \
+   return XML_TOK_INVALID; 
 \
+ } 
 \
+@@ -1134,6 +1134,10 @@ PREFIX(prologTok)(const ENCODING *enc, const char *ptr, 
const char *end,
+   case BT_LEAD##n:
 \
+ if (end - ptr < n)
 \
+   return XML_TOK_PARTIAL_CHAR;
 \
++if (IS_INVALID_CHAR(enc, ptr, n)) {   
 \
++  *nextTokPtr = ptr;  
 \
++  return XML_TOK_INVALID; 
 \
++} 
 \
+ if (IS_NMSTRT_CHAR(enc, ptr, n)) {
 \
+   ptr += n;   
 \
+   tok = XML_TOK_NAME; 
 \
+From c85a3025e7a1be086dc34e7559fbc543914d047f Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Wed, 9 Feb 2022 01:00:38 +0100
+Subject: [PATCH] lib: Add comments to BT_LEAD* cases where encoding has
+ already been validated
+
+---
+ 

[OE-core][dunfell 02/18] go: fix CVE-2022-23806

[Steve Sakoman]

From: Minjae Kim 

crypto/elliptic: fix IsOnCurve for big.Int values that are not valid coordinates

Some big.Int values that are not valid field elements (negative or overflowing)
might cause Curve.IsOnCurve to incorrectly return true. Operating on those 
values
may cause a panic or an invalid curve operation. Note that Unmarshal will never
return such values.

Upstream-Status: Backport [https://go.dev/issue/50974]
CVE: CVE-2022-23806
Signed-off-by:Minjae Kim 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.14.inc  |   1 +
 .../go/go-1.14/CVE-2022-23806.patch   | 142 ++
 2 files changed, 143 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-23806.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index abc6f42184..fcb316e09e 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -19,6 +19,7 @@ SRC_URI += "\
 file://CVE-2021-34558.patch \
 file://CVE-2021-33196.patch \
 file://CVE-2021-33197.patch \
+file://CVE-2022-23806.patch \
 "
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
 SRC_URI[main.sha256sum] = 
"7ed13b2209e54a451835997f78035530b331c5b6943cdcd68a3d815fdc009149"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-23806.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2022-23806.patch
new file mode 100644
index 00..772acdcbf6
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-23806.patch
@@ -0,0 +1,142 @@
+From 5b376a209d1c61e10847e062d78c4b1aa90dff0c Mon Sep 17 00:00:00 2001
+From: Filippo Valsorda 
+Date: Sat, 26 Feb 2022 10:40:57 +
+Subject: [PATCH] crypto/elliptic: make IsOnCurve return false for invalid
+
+ field elements
+
+Updates #50974
+Fixes #50977
+Fixes CVE-2022-23806
+
+Signed-off-by: Minjae Kim 
+
+---
+ src/crypto/elliptic/elliptic.go  |  6 +++
+ src/crypto/elliptic/elliptic_test.go | 81 
+ src/crypto/elliptic/p224.go  |  6 +++
+ 3 files changed, 93 insertions(+)
+
+diff --git a/src/crypto/elliptic/elliptic.go b/src/crypto/elliptic/elliptic.go
+index e2f71cd..bd574a4 100644
+--- a/src/crypto/elliptic/elliptic.go
 b/src/crypto/elliptic/elliptic.go
+@@ -53,6 +53,12 @@ func (curve *CurveParams) Params() *CurveParams {
+ }
+ 
+ func (curve *CurveParams) IsOnCurve(x, y *big.Int) bool {
++
++  if x.Sign() < 0 || x.Cmp(curve.P) >= 0 ||
++  y.Sign() < 0 || y.Cmp(curve.P) >= 0 {
++  return false
++  }
++
+   // y² = x³ - 3x + b
+   y2 := new(big.Int).Mul(y, y)
+   y2.Mod(y2, curve.P)
+diff --git a/src/crypto/elliptic/elliptic_test.go 
b/src/crypto/elliptic/elliptic_test.go
+index 09c5483..b13a620 100644
+--- a/src/crypto/elliptic/elliptic_test.go
 b/src/crypto/elliptic/elliptic_test.go
+@@ -628,3 +628,84 @@ func TestUnmarshalToLargeCoordinates(t *testing.T) {
+   t.Errorf("Unmarshal accepts invalid Y coordinate")
+   }
+ }
++
++func testAllCurves(t *testing.T, f func(*testing.T, Curve)) {
++  tests := []struct {
++  name  string
++  curve Curve
++  }{
++  {"P256", P256()},
++  {"P256/Params", P256().Params()},
++  {"P224", P224()},
++  {"P224/Params", P224().Params()},
++  {"P384", P384()},
++  {"P384/Params", P384().Params()},
++  {"P521", P521()},
++  {"P521/Params", P521().Params()},
++  }
++  if testing.Short() {
++  tests = tests[:1]
++  }
++  for _, test := range tests {
++  curve := test.curve
++  t.Run(test.name, func(t *testing.T) {
++  t.Parallel()
++  f(t, curve)
++  })
++  }
++}
++
++// TestInvalidCoordinates tests big.Int values that are not valid field 
elements
++// (negative or bigger than P). They are expected to return false from
++// IsOnCurve, all other behavior is undefined.
++func TestInvalidCoordinates(t *testing.T) {
++  testAllCurves(t, testInvalidCoordinates)
++}
++
++func testInvalidCoordinates(t *testing.T, curve Curve) {
++  checkIsOnCurveFalse := func(name string, x, y *big.Int) {
++  if curve.IsOnCurve(x, y) {
++  t.Errorf("IsOnCurve(%s) unexpectedly returned true", 
name)
++  }
++  }
++
++  p := curve.Params().P
++  _, x, y, _ := GenerateKey(curve, rand.Reader)
++  xx, yy := new(big.Int), new(big.Int)
++
++  // Check if the sign is getting dropped.
++  xx.Neg(x)
++  checkIsOnCurveFalse("-x, y", xx, y)
++  yy.Neg(y)
++  checkIsOnCurveFalse("x, -y", x, yy)
++
++  // Check if negative values are reduced modulo P.
++  xx.Sub(x, p)
++  checkIsOnCurveFalse("x-P, y", xx, y)
++  yy.Sub(y, p)
++  checkIsOnCurveFalse("x, y-P", x, yy)
++
++  // Check if positive values are reduced 

[OE-core][dunfell 03/18] go: fix CVE-2022-23772

[Steve Sakoman]

From: Minjae Kim 

math/big: prevent large memory consumption in Rat.SetString

An attacker can cause unbounded memory growth in a program using 
(*Rat).SetString
due to an unhandled overflow.

Upstream-Status: Backport [https://go.dev/issue/50699]
CVE: CVE-2022-23772
Signed-off-by:Minjae Kim 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.14.inc  |  1 +
 .../go/go-1.14/CVE-2022-23772.patch   | 50 +++
 2 files changed, 51 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-23772.patch

diff --git a/meta/recipes-devtools/go/go-1.14.inc 
b/meta/recipes-devtools/go/go-1.14.inc
index fcb316e09e..9b3c3b30a8 100644
--- a/meta/recipes-devtools/go/go-1.14.inc
+++ b/meta/recipes-devtools/go/go-1.14.inc
@@ -20,6 +20,7 @@ SRC_URI += "\
 file://CVE-2021-33196.patch \
 file://CVE-2021-33197.patch \
 file://CVE-2022-23806.patch \
+file://CVE-2022-23772.patch \
 "
 SRC_URI_append_libc-musl = " 
file://0009-ld-replace-glibc-dynamic-linker-with-musl.patch"
 SRC_URI[main.sha256sum] = 
"7ed13b2209e54a451835997f78035530b331c5b6943cdcd68a3d815fdc009149"
diff --git a/meta/recipes-devtools/go/go-1.14/CVE-2022-23772.patch 
b/meta/recipes-devtools/go/go-1.14/CVE-2022-23772.patch
new file mode 100644
index 00..f0daee3624
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.14/CVE-2022-23772.patch
@@ -0,0 +1,50 @@
+From 70882eedccac803ddcf1c3215e0ae8fd59847e39 Mon Sep 17 00:00:00 2001
+From: Katie Hockman 
+Date: Sat, 26 Feb 2022 20:03:38 +
+Subject: [PATCH] [release-branch.go1.16] math/big: prevent overflow in
+ (*Rat).SetString
+
+Credit to rsc@ for the original patch.
+
+Thanks to the OSS-Fuzz project for discovering this
+issue and to Emmanuel Odeke (@odeke_et) for reporting it.
+
+Updates #50699
+Fixes #50700
+Fixes CVE-2022-23772
+---
+ src/math/big/ratconv.go  | 5 +
+ src/math/big/ratconv_test.go | 1 +
+ 2 files changed, 6 insertions(+)
+
+diff --git a/src/math/big/ratconv.go b/src/math/big/ratconv.go
+index 941139e..e8cbdbe 100644
+--- a/src/math/big/ratconv.go
 b/src/math/big/ratconv.go
+@@ -168,6 +168,11 @@ func (z *Rat) SetString(s string) (*Rat, bool) {
+   n := exp5
+   if n < 0 {
+   n = -n
++  if n < 0 {
++  // This can occur if -n overflows. -(-1 << 63) 
would become
++  // -1 << 63, which is still negative.
++  return nil, false
++  }
+   }
+   pow5 := z.b.abs.expNN(natFive, nat(nil).setWord(Word(n)), nil) 
// use underlying array of z.b.abs
+   if exp5 > 0 {
+diff --git a/src/math/big/ratconv_test.go b/src/math/big/ratconv_test.go
+index ba0d1ba..b820df4 100644
+--- a/src/math/big/ratconv_test.go
 b/src/math/big/ratconv_test.go
+@@ -104,6 +104,7 @@ var setStringTests = []StringTest{
+   {in: "4/3/"},
+   {in: "4/3."},
+   {in: "4/"},
++  {in: "13e-9223372036854775808"}, // CVE-2022-23772
+ 
+   // valid
+   {"0", "0", true},
+-- 
+2.17.1
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162722): 
https://lists.openembedded.org/g/openembedded-core/message/162722
Mute This Topic: https://lists.openembedded.org/mt/89550456/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 01/18] libarchive: Fix for CVE-2021-36976

[Steve Sakoman]

From: Virendra Thakur 

Add patch to fix CVE-2021-36976

CVE-2021-36976 fix are provided by below mentioned pull request.
1) https://github.com/libarchive/libarchive/pull/1491
2) https://github.com/libarchive/libarchive/pull/1492
3) https://github.com/libarchive/libarchive/pull/1493

Signed-off-by: Virendra Thakur 
Signed-off-by: virendra thakur 
Signed-off-by: Steve Sakoman 
---
 .../libarchive/CVE-2021-36976-1.patch | 321 ++
 .../libarchive/CVE-2021-36976-2.patch | 121 +++
 .../libarchive/CVE-2021-36976-3.patch |  93 +
 .../libarchive/libarchive_3.4.2.bb|   6 +-
 4 files changed, 540 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-1.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-2.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-3.patch

diff --git a/meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-1.patch 
b/meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-1.patch
new file mode 100644
index 00..fca53fc9b6
--- /dev/null
+++ b/meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-1.patch
@@ -0,0 +1,321 @@
+From 05ebb55896d10a9737dad9ae0303f7f45489ba6f Mon Sep 17 00:00:00 2001
+From: Grzegorz Antoniak 
+Date: Sat, 13 Feb 2021 09:08:13 +0100
+Subject: [PATCH] RAR5 reader: fixed out of bounds read in some files
+
+Added more range checks in the bit stream reading functions
+(read_bits_16 and read_bits_32) in order to better guard against out of
+memory reads.
+
+This commit contains a test with OSSFuzz sample #30448.
+
+Upstream-Status: Backport 
[https://git.launchpad.net/ubuntu/+source/libarchive/plain/debian/patches/CVE-2021-36976-1.patch?h=applied/3.4.3-2ubuntu0.1]
+CVE: CVE-2021-36976
+Signed-off-by: Virendra Thakur 
+---
+ Makefile.am   |   1 +
+ libarchive/archive_read_support_format_rar5.c | 108 ++
+ libarchive/test/test_read_format_rar5.c   |  16 +++
+ ...r5_decode_number_out_of_bounds_read.rar.uu |  10 ++
+ 4 files changed, 89 insertions(+), 46 deletions(-)
+ create mode 100644 
libarchive/test/test_read_format_rar5_decode_number_out_of_bounds_read.rar.uu
+
+--- a/Makefile.am
 b/Makefile.am
+@@ -883,6 +883,7 @@ libarchive_test_EXTRA_DIST=\
+   
libarchive/test/test_read_format_rar5_arm_filter_on_window_boundary.rar.uu \
+   libarchive/test/test_read_format_rar5_different_winsize_on_merge.rar.uu 
\
+   libarchive/test/test_read_format_rar5_block_size_is_too_small.rar.uu \
++  
libarchive/test/test_read_format_rar5_decode_number_out_of_bounds_read.rar.uu \
+   libarchive/test/test_read_format_raw.bufr.uu \
+   libarchive/test/test_read_format_raw.data.gz.uu \
+   libarchive/test/test_read_format_raw.data.Z.uu \
+--- a/libarchive/archive_read_support_format_rar5.c
 b/libarchive/archive_read_support_format_rar5.c
+@@ -1012,7 +1012,16 @@ static int read_var_sized(struct archive
+   return ret;
+ }
+ 
+-static int read_bits_32(struct rar5* rar, const uint8_t* p, uint32_t* value) {
++static int read_bits_32(struct archive_read* a, struct rar5* rar,
++  const uint8_t* p, uint32_t* value)
++{
++  if(rar->bits.in_addr >= rar->cstate.cur_block_size) {
++  archive_set_error(>archive,
++  ARCHIVE_ERRNO_PROGRAMMER,
++  "Premature end of stream during extraction of data 
(#1)");
++  return ARCHIVE_FATAL;
++  }
++
+   uint32_t bits = ((uint32_t) p[rar->bits.in_addr]) << 24;
+   bits |= p[rar->bits.in_addr + 1] << 16;
+   bits |= p[rar->bits.in_addr + 2] << 8;
+@@ -1023,7 +1032,16 @@ static int read_bits_32(struct rar5* rar
+   return ARCHIVE_OK;
+ }
+ 
+-static int read_bits_16(struct rar5* rar, const uint8_t* p, uint16_t* value) {
++static int read_bits_16(struct archive_read* a, struct rar5* rar,
++  const uint8_t* p, uint16_t* value)
++{
++  if(rar->bits.in_addr >= rar->cstate.cur_block_size) {
++  archive_set_error(>archive,
++  ARCHIVE_ERRNO_PROGRAMMER,
++  "Premature end of stream during extraction of data 
(#2)");
++  return ARCHIVE_FATAL;
++  }
++
+   int bits = (int) ((uint32_t) p[rar->bits.in_addr]) << 16;
+   bits |= (int) p[rar->bits.in_addr + 1] << 8;
+   bits |= (int) p[rar->bits.in_addr + 2];
+@@ -1039,8 +1057,8 @@ static void skip_bits(struct rar5* rar,
+ }
+ 
+ /* n = up to 16 */
+-static int read_consume_bits(struct rar5* rar, const uint8_t* p, int n,
+-int* value)
++static int read_consume_bits(struct archive_read* a, struct rar5* rar,
++  const uint8_t* p, int n, int* value)
+ {
+   uint16_t v;
+   int ret, num;
+@@ -1051,7 +1069,7 @@ static int read_consume_bits(struct rar5
+   return ARCHIVE_FATAL;
+   }
+ 
+-  ret = read_bits_16(rar, p, );
++  ret = 

[OE-core][dunfell 00/18] Patch review

[Steve Sakoman]

Please review this set of patches for dunfell and have comments back by end
of day Tuesday.

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3314

with the exception of a known autobuilder intermittent issue on qemumips64:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=14029

which passed on subsequent retest:

https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/4787

The following changes since commit 79ce9059f716546a7d6f4562ba194aedd90c22cd:

  grub: add a fix for a crash in scripts (2022-02-23 05:00:42 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut

Jose Quaresma (1):
  buildhistory.bbclass: create the buildhistory directory when needed

Marek Vasut (1):
  bootchart2: Add missing python3-math dependency

Michael Halstead (1):
  uninative: Upgrade to 3.5

Minjae Kim (2):
  go: fix CVE-2022-23806
  go: fix CVE-2022-23772

Nathan Rossi (1):
  cml1.bbclass: Handle ncurses-native being available via pkg-config

Richard Purdie (2):
  libxml-parser-perl: Add missing RDEPENDS
  uninative: Add version to uninative tarball name

Ross Burton (3):
  coreutils: remove obsolete ignored CVE list
  cve-check: get_cve_info should open the database read-only
  Revert "cve-check: add lockfile to task"

Steve Sakoman (5):
  expat: fix CVE-2022-25235
  expat: fix CVE-2022-25236
  expat: fix CVE-2022-25313
  expat: fix CVE-2022-25314
  expat: fix CVE-2022-25315

Virendra Thakur (1):
  libarchive: Fix for CVE-2021-36976

wangmy (1):
  wireless-regdb: upgrade 2021.08.28 -> 2022.02.18

 meta/classes/buildhistory.bbclass |   1 +
 meta/classes/cml1.bbclass |   8 +
 meta/classes/cve-check.bbclass|   4 +-
 meta/classes/uninative.bbclass|   2 +-
 meta/conf/distro/include/yocto-uninative.inc  |  11 +-
 meta/recipes-core/coreutils/coreutils_8.31.bb |   3 -
 .../expat/expat/CVE-2022-25235.patch  | 283 +++
 .../expat/expat/CVE-2022-25236.patch  | 129 +++
 .../expat/CVE-2022-25313-regression.patch | 131 +++
 .../expat/expat/CVE-2022-25313.patch  | 230 +
 .../expat/expat/CVE-2022-25314.patch  |  32 ++
 .../expat/expat/CVE-2022-25315.patch  | 145 
 meta/recipes-core/expat/expat_2.2.9.bb|   6 +
 .../bootchart2/bootchart2_0.14.9.bb   |   2 +-
 meta/recipes-devtools/go/go-1.14.inc  |   2 +
 .../go/go-1.14/CVE-2022-23772.patch   |  50 +++
 .../go/go-1.14/CVE-2022-23806.patch   | 142 
 .../perl/libxml-parser-perl_2.46.bb   |   1 +
 .../libarchive/CVE-2021-36976-1.patch | 321 ++
 .../libarchive/CVE-2021-36976-2.patch | 121 +++
 .../libarchive/CVE-2021-36976-3.patch |  93 +
 .../libarchive/libarchive_3.4.2.bb|   6 +-
 08.28.bb => wireless-regdb_2022.02.18.bb} |   2 +-
 23 files changed, 1711 insertions(+), 14 deletions(-)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25235.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25236.patch
 create mode 100644 
meta/recipes-core/expat/expat/CVE-2022-25313-regression.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25313.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25314.patch
 create mode 100644 meta/recipes-core/expat/expat/CVE-2022-25315.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-23772.patch
 create mode 100644 meta/recipes-devtools/go/go-1.14/CVE-2022-23806.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-1.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-2.patch
 create mode 100644 
meta/recipes-extended/libarchive/libarchive/CVE-2021-36976-3.patch
 rename meta/recipes-kernel/wireless-regdb/{wireless-regdb_2021.08.28.bb => 
wireless-regdb_2022.02.18.bb} (94%)

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162719): 
https://lists.openembedded.org/g/openembedded-core/message/162719
Mute This Topic: https://lists.openembedded.org/mt/89550450/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Konrad Weihmann]

On 04.03.22 14:13, Ross Burton wrote:

On Fri, 4 Mar 2022 at 12:44, Konrad Weihmann  wrote:

For me that would be a candidate to be added to meta-python, or are
there any core recipes that currently break because of the new behavior?


This is restoring existing behaviour, so I believe it should be in
core.  There's going to be enough recipes using this that it is
justified in core. I expect we'll have deleted this by the time the
next LTS comes around too.


Furthermore the variables names are the same, so if people accidentally
(or due to complex injection trees/classes/distro settings/whatever have
new setuptools3 and this class here in the same recipe, things become
rather unpredictable - as of now there are the same but surely they will
start to diverge at one point.


That's intentional: if you have a recipe which needs the legacy
behaviour, just change the import from setuptool3 to
setuptools3_legacy.


Can you name any publicly available recipe that requires that?

For me this is the same situation as with the python2 > python3 
transition - there wasn't any fallback provided in core, but outside of 
core it was - so I would propose to do the same here.


If that legacy class will be part of core it's likely that it will 
remain till EOL of kirkstone which is somewhat in ~2025 (by current 
planning) - and meta-python2 showed that even then some recipes still 
haven't migrated (yes, chromium looking at you).
All in all I think core should just provide *one* way to do it while the 
legacy cases can easily live outside in a separate layer (meta-python 
for instance as the "old" distutils have been put there as well).


In additional everyone was worried so much about reputation lately that 
doing this long announced transition, while keeping the "old" way 
enabled (and creating more maintenance effort in the end), would 
definitely send the wrong signal to the community.





While we are at it pypi class needs a fallback too, because for me this
is the standard way of packaging python recipes and new class points to
the new setuptools implementation - so if we want to have this here, we
might need a fallback for pypi class as well


My understanding is that almost anything on pypi is already a pure
Python module and is mostly unaffected by the changes.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162718): 
https://lists.openembedded.org/g/openembedded-core/message/162718
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Ross Burton]

On Fri, 4 Mar 2022 at 12:44, Konrad Weihmann  wrote:
> For me that would be a candidate to be added to meta-python, or are
> there any core recipes that currently break because of the new behavior?

This is restoring existing behaviour, so I believe it should be in
core.  There's going to be enough recipes using this that it is
justified in core. I expect we'll have deleted this by the time the
next LTS comes around too.

> Furthermore the variables names are the same, so if people accidentally
> (or due to complex injection trees/classes/distro settings/whatever have
> new setuptools3 and this class here in the same recipe, things become
> rather unpredictable - as of now there are the same but surely they will
> start to diverge at one point.

That's intentional: if you have a recipe which needs the legacy
behaviour, just change the import from setuptool3 to
setuptools3_legacy.

> While we are at it pypi class needs a fallback too, because for me this
> is the standard way of packaging python recipes and new class points to
> the new setuptools implementation - so if we want to have this here, we
> might need a fallback for pypi class as well

My understanding is that almost anything on pypi is already a pure
Python module and is mostly unaffected by the changes.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162717): 
https://lists.openembedded.org/g/openembedded-core/message/162717
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes: add setuptools3_legacy

[Konrad Weihmann]

For me that would be a candidate to be added to meta-python, or are 
there any core recipes that currently break because of the new behavior?


Furthermore the variables names are the same, so if people accidentally 
(or due to complex injection trees/classes/distro settings/whatever have 
new setuptools3 and this class here in the same recipe, things become 
rather unpredictable - as of now there are the same but surely they will 
start to diverge at one point.


While we are at it pypi class needs a fallback too, because for me this 
is the standard way of packaging python recipes and new class points to 
the new setuptools implementation - so if we want to have this here, we 
might need a fallback for pypi class as well



On 04.03.22 12:55, Ross Burton wrote:

Following a good discussion with PyPA upstream[1] the migration of the
setuptools3.bbclass to use bdist_wheel+pip turns out to be more complex
than thought.

Essentially, we're midway through a lot of changes: the future of Python
packaging is wheels and pip, but those by design are not as flexible as
traditional distutils and setup.py.

Specifically, with traditional distutils the package can implement its
own install task and write arbitrary files (such as init scripts).  With
wheels this is explicity impossible, so packages that do this cannot use
the new setuptools class and must continue to use the build/install tasks
as before.

This class is the old setuptools behaviour, bought back. However, as
distutils and the setuptools install task are both deprecated and will
soon be removed entirely, any users of this class should be moving to an
alternative build tool, be it a modern Python tool which works with
wheels, or a non-Pythonic tool such as Meson.

[1] https://github.com/pypa/packaging-problems/issues/576

Signed-off-by: Ross Burton 
---
  meta/classes/setuptools3_legacy.bbclass | 78 +
  1 file changed, 78 insertions(+)
  create mode 100644 meta/classes/setuptools3_legacy.bbclass

diff --git a/meta/classes/setuptools3_legacy.bbclass 
b/meta/classes/setuptools3_legacy.bbclass
new file mode 100644
index 00..5a99daadb5
--- /dev/null
+++ b/meta/classes/setuptools3_legacy.bbclass
@@ -0,0 +1,78 @@
+# This class is for packages which use the deprecated setuptools behaviour,
+# specifically custom install tasks which don't work correctly with 
bdist_wheel.
+# This behaviour is deprecated in setuptools[1] and won't work in the future, 
so
+# all users of this should consider their options: pure Python modules can use 
a
+# modern Python tool such as build[2], or packages which are doing more (such 
as
+# installing init scripts) should use a fully-featured build system such as 
Meson.
+#
+# [1] https://setuptools.pypa.io/en/latest/history.html#id142
+# [2] https://pypi.org/project/build/
+
+inherit setuptools3-base
+
+B = "${WORKDIR}/build"
+
+SETUPTOOLS_BUILD_ARGS ?= ""
+SETUPTOOLS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"
+
+SETUPTOOLS_PYTHON = "python3"
+SETUPTOOLS_PYTHON:class-native = "nativepython3"
+
+SETUPTOOLS_SETUP_PATH ?= "${S}"
+
+setuptools3_legacy_do_configure() {
+:
+}
+
+setuptools3_legacy_do_compile() {
+cd ${SETUPTOOLS_SETUP_PATH}
+NO_FETCH_BUILD=1 \
+STAGING_INCDIR=${STAGING_INCDIR} \
+STAGING_LIBDIR=${STAGING_LIBDIR} \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
+build --build-base=${B} ${SETUPTOOLS_BUILD_ARGS} || \
+bbfatal_log "'${PYTHON_PN} setup.py build ${SETUPTOOLS_BUILD_ARGS}' 
execution failed."
+}
+setuptools3_legacy_do_compile[vardepsexclude] = "MACHINE"
+
+setuptools3_legacy_do_install() {
+cd ${SETUPTOOLS_SETUP_PATH}
+install -d ${D}${PYTHON_SITEPACKAGES_DIR}
+STAGING_INCDIR=${STAGING_INCDIR} \
+STAGING_LIBDIR=${STAGING_LIBDIR} \
+PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
+build --build-base=${B} install --skip-build 
${SETUPTOOLS_INSTALL_ARGS} || \
+bbfatal_log "'${PYTHON_PN} setup.py install ${SETUPTOOLS_INSTALL_ARGS}' 
execution failed."
+
+# support filenames with *spaces*
+find ${D} -name "*.py" -exec grep -q ${D} {} \; \
+   -exec sed -i -e s:${D}::g {} \;
+
+for i in ${D}${bindir}/* ${D}${sbindir}/*; do
+if [ -f "$i" ]; then
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ 
${SETUPTOOLS_PYTHON}:g $i
+sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
+fi
+done
+
+rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
+
+#
+# FIXME: Bandaid against wrong datadir computation
+#
+if [ -e ${D}${datadir}/share ]; then
+mv -f ${D}${datadir}/share/* ${D}${datadir}/
+rmdir ${D}${datadir}/share
+

[OE-core] [PATCH] classes: add setuptools3_legacy

[Ross Burton]

Following a good discussion with PyPA upstream[1] the migration of the
setuptools3.bbclass to use bdist_wheel+pip turns out to be more complex
than thought.

Essentially, we're midway through a lot of changes: the future of Python
packaging is wheels and pip, but those by design are not as flexible as
traditional distutils and setup.py.

Specifically, with traditional distutils the package can implement its
own install task and write arbitrary files (such as init scripts).  With
wheels this is explicity impossible, so packages that do this cannot use
the new setuptools class and must continue to use the build/install tasks
as before.

This class is the old setuptools behaviour, bought back. However, as
distutils and the setuptools install task are both deprecated and will
soon be removed entirely, any users of this class should be moving to an
alternative build tool, be it a modern Python tool which works with
wheels, or a non-Pythonic tool such as Meson.

[1] https://github.com/pypa/packaging-problems/issues/576

Signed-off-by: Ross Burton 
---
 meta/classes/setuptools3_legacy.bbclass | 78 +
 1 file changed, 78 insertions(+)
 create mode 100644 meta/classes/setuptools3_legacy.bbclass

diff --git a/meta/classes/setuptools3_legacy.bbclass 
b/meta/classes/setuptools3_legacy.bbclass
new file mode 100644
index 00..5a99daadb5
--- /dev/null
+++ b/meta/classes/setuptools3_legacy.bbclass
@@ -0,0 +1,78 @@
+# This class is for packages which use the deprecated setuptools behaviour,
+# specifically custom install tasks which don't work correctly with 
bdist_wheel.
+# This behaviour is deprecated in setuptools[1] and won't work in the future, 
so
+# all users of this should consider their options: pure Python modules can use 
a
+# modern Python tool such as build[2], or packages which are doing more (such 
as
+# installing init scripts) should use a fully-featured build system such as 
Meson.
+#
+# [1] https://setuptools.pypa.io/en/latest/history.html#id142
+# [2] https://pypi.org/project/build/
+
+inherit setuptools3-base
+
+B = "${WORKDIR}/build"
+
+SETUPTOOLS_BUILD_ARGS ?= ""
+SETUPTOOLS_INSTALL_ARGS ?= "--root=${D} \
+--prefix=${prefix} \
+--install-lib=${PYTHON_SITEPACKAGES_DIR} \
+--install-data=${datadir}"
+
+SETUPTOOLS_PYTHON = "python3"
+SETUPTOOLS_PYTHON:class-native = "nativepython3"
+
+SETUPTOOLS_SETUP_PATH ?= "${S}"
+
+setuptools3_legacy_do_configure() {
+:
+}
+
+setuptools3_legacy_do_compile() {
+cd ${SETUPTOOLS_SETUP_PATH}
+NO_FETCH_BUILD=1 \
+STAGING_INCDIR=${STAGING_INCDIR} \
+STAGING_LIBDIR=${STAGING_LIBDIR} \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
+build --build-base=${B} ${SETUPTOOLS_BUILD_ARGS} || \
+bbfatal_log "'${PYTHON_PN} setup.py build ${SETUPTOOLS_BUILD_ARGS}' 
execution failed."
+}
+setuptools3_legacy_do_compile[vardepsexclude] = "MACHINE"
+
+setuptools3_legacy_do_install() {
+cd ${SETUPTOOLS_SETUP_PATH}
+install -d ${D}${PYTHON_SITEPACKAGES_DIR}
+STAGING_INCDIR=${STAGING_INCDIR} \
+STAGING_LIBDIR=${STAGING_LIBDIR} \
+PYTHONPATH=${D}${PYTHON_SITEPACKAGES_DIR} \
+${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py \
+build --build-base=${B} install --skip-build 
${SETUPTOOLS_INSTALL_ARGS} || \
+bbfatal_log "'${PYTHON_PN} setup.py install 
${SETUPTOOLS_INSTALL_ARGS}' execution failed."
+
+# support filenames with *spaces*
+find ${D} -name "*.py" -exec grep -q ${D} {} \; \
+   -exec sed -i -e s:${D}::g {} \;
+
+for i in ${D}${bindir}/* ${D}${sbindir}/*; do
+if [ -f "$i" ]; then
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ 
${SETUPTOOLS_PYTHON}:g $i
+sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
+fi
+done
+
+rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
+
+#
+# FIXME: Bandaid against wrong datadir computation
+#
+if [ -e ${D}${datadir}/share ]; then
+mv -f ${D}${datadir}/share/* ${D}${datadir}/
+rmdir ${D}${datadir}/share
+fi
+}
+setuptools3_legacy_do_install[vardepsexclude] = "MACHINE"
+
+EXPORT_FUNCTIONS do_configure do_compile do_install
+
+export LDSHARED="${CCLD} -shared"
+DEPENDS += "python3-setuptools-native"
+
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162715): 
https://lists.openembedded.org/g/openembedded-core/message/162715
Mute This Topic: https://lists.openembedded.org/mt/89547022/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] python3-importlib-metadata: upgrade 4.10.1 -> 4.11.2

[Lee Chee Yang]

Error while do_compile 

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/3190/steps/11/logs/stdio



> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Tim Orling
> Sent: Friday, March 4, 2022 4:44 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Tim Orling 
> Subject: [OE-core] [PATCH 1/2] python3-importlib-metadata: upgrade 4.10.1
> -> 4.11.2
> 
> inherit setuptools_build_meta
> 
> v4.11.2
> 369: Fixed bug where EntryPoint.extras was returning match objects and not
> the extras strings.
> 
> v4.11.1
> 367: In Distribution.requires for egg-info, if requires.txt is empty, return 
> an
> empty list.
> 
> v4.11.0
> bpo-46246: Added __slots__ to EntryPoints.
> 
> v4.10.2
> 365 and bpo-46546: Avoid leaking method_name in DeprecatedList.
> 
> Signed-off-by: Tim Orling 
> ---
>  ...-metadata_4.10.1.bb => python3-importlib-metadata_4.11.2.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)  rename meta/recipes-
> devtools/python/{python3-importlib-metadata_4.10.1.bb => python3-
> importlib-metadata_4.11.2.bb} (88%)
> 
> diff --git a/meta/recipes-devtools/python/python3-importlib-
> metadata_4.10.1.bb b/meta/recipes-devtools/python/python3-importlib-
> metadata_4.11.2.bb
> similarity index 88%
> rename from meta/recipes-devtools/python/python3-importlib-
> metadata_4.10.1.bb
> rename to meta/recipes-devtools/python/python3-importlib-
> metadata_4.11.2.bb
> index ff40def563f..15c468e41b7 100644
> --- a/meta/recipes-devtools/python/python3-importlib-metadata_4.10.1.bb
> +++ b/meta/recipes-devtools/python/python3-importlib-
> metadata_4.11.2.bb
> @@ -8,7 +8,7 @@ inherit pypi setuptools3  PYPI_PACKAGE =
> "importlib_metadata"
>  UPSTREAM_CHECK_REGEX = "/importlib-metadata/(?P(\d+[\.\-
> _]*)+)/"
> 
> -SRC_URI[sha256sum] =
> "951f0d8a5b7260e9db5e41d429285b5f451e928479f19d80818878527d36e95e"
> +SRC_URI[sha256sum] =
> "b36ffa925fe3139b2f6ff11d6925ffd4fa7bc47870165e3ac260ac7b4f91e6ac"
> 
>  S = "${WORKDIR}/importlib_metadata-${PV}"
> 
> --
> 2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162714): 
https://lists.openembedded.org/g/openembedded-core/message/162714
Mute This Topic: https://lists.openembedded.org/mt/89534634/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH] copy_buildsystem: allow more layer paths

[Andrej Valek]

Hi Daniel,

thanks for the explanation. To be honest, when I was dealing with the
layer structure, I didn't take a case about the layer outside of "work"
directory.

Basically it's the same as mine, but respect the external layers
outside of work, right? So, your proposal makes sense to me.

layers
├── meta-my-layer
├── meta-openembedded
│   ├── meta-networking
│   └── meta-oe
└── poky
└── meta

Forget about the last variant. We don't want to remove the layer
structure.

Regards,
Andrej

On Fri, 2022-03-04 at 10:26 +0100, Daniel Wagenknecht wrote:
> Hello Andrej,
> 
> On Thu, 2022-03-03 at 06:35 +, Andrej Valek wrote:
> > Hi Daniel,
> > 
> > Could you please give here the examples how the layer structure looks
> > before and after change? I want to see how transformation looks like.
> 
> With a directory-structure like
> 
> /
> ├── repo
> │   └── layers
> │   └── meta-my-layer
> └── work
>     ├── build
>     └── layers
>     └── external
>     ├── meta-openembedded
>     │   ├── meta-networking
>     │   └── meta-oe
>     └── poky
>     └── meta
> 
> and
> 
> # Set through bitbake itself
> COREBASE = "/work/layers/external/poky"
> TOPDIR = "/work/build"
> # Set in bblayers.conf
> BBLAYERS = " \
>     /repo/layers/meta-my-layer \
>     /work/layers/external/meta-openembedded/meta-networking \
>     /work/layers/external/meta-openembedded/meta-oe \
>     /work/layers/external/poky/meta"
> 
> The resulting eSDK layers directory will look like this:
> 
> .
> ├── meta-my-layer
> ├── meta-openembedded
> │   ├── meta-networking
> │   └── meta-oe
> └── poky
>     └── meta
> 
> Without this patch the /repo/meta-my-layer layer broke the build:
> > > This patch resolves issues like
> > >   ERROR: my-image-1.0-r0 do_populate_sdk_ext: Failed to generate
> > > filtered task list for extensible SDK:
> > > 
> > >   ### Shell environment set up for builds. ###
> > >   [...]
> > > 
> > >   ERROR: bitbake failed:
> > >   ERROR: The following layer directories do not exist:
> > >   ERROR:    /build/tmp/work/my-board-linux/my-image/1.0-r0/sdk-
> > > ext/image/tmp-renamed-sdk/layers/../../../repo/layers/meta-my-layer
> > >   ERROR: Please check BBLAYERS in /build/tmp/work/my-board-
> > > linux/my-
> > > image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
> > >   ERROR: Logfile of failure stored in: /build/tmp/work/my-board-
> > > linux/my-image/1.0-r0/temp/log.do_populate_sdk_ext.68844
> > > 
> 
> Without meta-my-layer this patch should not cause any change.
> 
> The alternative
> > > Alternative to this patch:
> > > Delete the whole else / elseif block. This would lead to a layer
> > > structure in
> > > the eSDK like
> > >   layers/poky/meta
> > >   layers/meta-networking
> > >   layers/meta-oe
> > > thus flattening the layer tree.
> would remove the special casing in the implementation (except for
> COREBASE
> sublayers), thus resulting in the following layer structure in the
> eSDKs layers
> directory:
> 
> .
> ├── meta-my-layer
> ├── meta-networking
> ├── meta-oe
> └── poky
>     └── meta
> 
> --
> Sincerely
> Daniel Wagenknecht
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162713): 
https://lists.openembedded.org/g/openembedded-core/message/162713
Mute This Topic: https://lists.openembedded.org/mt/89508969/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH] copy_buildsystem: allow more layer paths

[Daniel Wagenknecht]

Hello Andrej,

On Thu, 2022-03-03 at 06:35 +, Andrej Valek wrote:
> Hi Daniel,
> 
> Could you please give here the examples how the layer structure looks
> before and after change? I want to see how transformation looks like.

With a directory-structure like

/
├── repo
│   └── layers
│   └── meta-my-layer
└── work
├── build
└── layers
└── external
├── meta-openembedded
│   ├── meta-networking
│   └── meta-oe
└── poky
└── meta

and

# Set through bitbake itself
COREBASE = "/work/layers/external/poky"
TOPDIR = "/work/build"
# Set in bblayers.conf
BBLAYERS = " \
/repo/layers/meta-my-layer \
/work/layers/external/meta-openembedded/meta-networking \
/work/layers/external/meta-openembedded/meta-oe \
/work/layers/external/poky/meta"

The resulting eSDK layers directory will look like this:

.
├── meta-my-layer
├── meta-openembedded
│   ├── meta-networking
│   └── meta-oe
└── poky
└── meta

Without this patch the /repo/meta-my-layer layer broke the build:
> > This patch resolves issues like
> >   ERROR: my-image-1.0-r0 do_populate_sdk_ext: Failed to generate
> > filtered task list for extensible SDK:
> > 
> >   ### Shell environment set up for builds. ###
> >   [...]
> > 
> >   ERROR: bitbake failed:
> >   ERROR: The following layer directories do not exist:
> >   ERROR:/build/tmp/work/my-board-linux/my-image/1.0-r0/sdk-
> > ext/image/tmp-renamed-sdk/layers/../../../repo/layers/meta-my-layer
> >   ERROR: Please check BBLAYERS in /build/tmp/work/my-board-linux/my-
> > image/1.0-r0/sdk-ext/image/tmp-renamed-sdk/conf/bblayers.conf
> >   ERROR: Logfile of failure stored in: /build/tmp/work/my-board-
> > linux/my-image/1.0-r0/temp/log.do_populate_sdk_ext.68844
> > 

Without meta-my-layer this patch should not cause any change.

The alternative
> > Alternative to this patch:
> > Delete the whole else / elseif block. This would lead to a layer
> > structure in
> > the eSDK like
> >   layers/poky/meta
> >   layers/meta-networking
> >   layers/meta-oe
> > thus flattening the layer tree.
would remove the special casing in the implementation (except for COREBASE
sublayers), thus resulting in the following layer structure in the eSDKs layers
directory:

.
├── meta-my-layer
├── meta-networking
├── meta-oe
└── poky
└── meta

--
Sincerely
Daniel Wagenknecht


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162712): 
https://lists.openembedded.org/g/openembedded-core/message/162712
Mute This Topic: https://lists.openembedded.org/mt/89508969/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] libical: Pass TOOLCHAIN_OPTIONS via CFLAGS

[Jose Quaresma]

Richard Purdie  escreveu no dia quinta,
3/03/2022 à(s) 23:15:

> On Thu, 2022-03-03 at 15:05 -0800, Khem Raj wrote:
> > On Thu, Mar 3, 2022 at 2:53 PM Richard Purdie
> >  wrote:
> > >
> > > On Mon, 2022-02-28 at 20:13 -0800, Khem Raj wrote:
> > > > This ensures that right sysroot is used during build, otherwise we
> see
> > > > warnings in build about using wrong sysroot and it fails explicitly
> with
> > > > clang
> > > >
> > > > x86_64-yoe-linux-ld: warning: library search path "/usr/lib/gcc/x86_6
> > > > 4-pc-linux-gnu/11.2.0/../../../../lib64" is unsafe for
> cross-compilation
> > > >
> > > > x86_64-yoe-linux-ld: cannot find /usr/lib/clang/14.0.0/lib/linux/libc
> > > > lang_rt.builtins-x86_64.a: No such file or directory
> > > >
> > > > Signed-off-by: Khem Raj 
> > > > ---
> > > >  meta/recipes-support/libical/libical_3.0.14.bb | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/meta/recipes-support/libical/libical_3.0.14.bb
> b/meta/recipes-support/libical/libical_3.0.14.bb
> > > > index 717eb11e125..879ad8ed595 100644
> > > > --- a/meta/recipes-support/libical/libical_3.0.14.bb
> > > > +++ b/meta/recipes-support/libical/libical_3.0.14.bb
> > > > @@ -18,6 +18,8 @@ UPSTREAM_CHECK_URI = "
> https://github.com/libical/libical/releases;
> > > >
> > > >  inherit cmake pkgconfig gobject-introspection vala
> > > >
> > > > +CFLAGS += "${TOOLCHAIN_OPTIONS}"
> > > > +
> > > >  DEPENDS += "libical-native"
> > > >
> > > >  PACKAGECONFIG ??= "icu glib"
> > >
> > >
> > > I gave this (and the cmake patch) a go and whilst it mostly worked, it
> doesn't
> > > work on arm (qemuarm or beaglebone):
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/4855
> > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/3774
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/4829
> > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/3715
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/4825
> > >
> > > Any ideas?
> >
> > I think we need to check why CC is being passed here from env
> > explicitly when invoking g-ir-scanner-wrapper, which is bare compiler
> > without TOOLCHAIN_OPTIONS and this cmd seems to not
> > respect CFLAGS
>

I will take a look in the weekend.

Jose


> >
> > > [95/112] cd
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/build/src/libical
> > &&
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/recipe-sysroot-native/usr/bin/cmake
> > -E env
> "CC='/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc'"
> >
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/recipe-sysroot/usr/bin/g-ir-scanner-wrapper
> > --c-include=libical/ical.h --pkg-export libical
> > --identifier-prefix=ical
> >
> -I/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/libical-3.0.14/src/libical
> >
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/build/src/libical/ical.h
> > --namespace=ICal --nsversion=3.0 --no-libtool --library=ical
> > --include=GObject-2.0
> >
> -L/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/build/lib
> > --output
> /home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/libical/3.0.14-r0/build/src/libical/ICal-3.0.gir
> > --accept-unprefixed
> >
> > I will take a look later today.
>
> Thanks, I'll be asleep shortly I hope! :)
>
> >
> > btw. is this the only failure left ?
> >
>
> For that patch in core, yes, I think so.
>
> Cheers,
>
> Richard
>
> >
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#162711): 
https://lists.openembedded.org/g/openembedded-core/message/162711
Mute This Topic: https://lists.openembedded.org/mt/89469112/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-