date:20230117

Please review this set of patches for kirkstone and have comments back by
end of day Thursday.

Passed a-full on autobuilder:

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

The following changes since commit 4760fac939a6204e3cb7dcd3699cd9a2508f9dee:

  devtool: process local files only for the main branch (2023-01-12 04:56:26 
-1000)

are available in the Git repository at:

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

Bhabu Bindu (1):
  qemu: Fix CVE-2022-4144

Daniel Gomez (1):
  gtk-icon-cache: Fix GTKIC_CMD if-else condition

KARN JYE LAU (1):
  freetype:update mirror site.

Martin Jansa (1):
  ffmpeg: refresh patches to apply cleanly

Narpat Mali (3):
  python3-setuptools: fix for CVE-2022-40897
  python3-wheel: fix for CVE-2022-40898
  python3-git: fix for CVE-2022-24439

Yash Shinde (1):
  glibc: stable 2.35 branch updates.

Yogita Urade (1):
  libksba: fix CVE-2022-47629

 meta/classes/gtk-icon-cache.bbclass   |   2 +-
 meta/recipes-core/glibc/glibc-version.inc |   2 +-
 ...-git-CVE-2022-24439-fix-from-PR-1518.patch |  97 
 ...-git-CVE-2022-24439-fix-from-PR-1521.patch | 488 ++
 .../python/python3-git_3.1.27.bb  |   4 +
 ...-of-whitespace-to-search-backtrack.-.patch |  31 ++
 .../python/python3-setuptools_59.5.0.bb   |   1 +
 ...tential-DoS-attack-via-WHEEL_INFO_RE.patch |  32 ++
 .../python/python3-wheel_0.37.1.bb|   4 +-
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 .../qemu/qemu/CVE-2022-4144.patch |  99 
 .../freetype/freetype_2.11.1.bb   |   2 +-
 ...c-stop-accessing-out-of-bounds-frame.patch |  19 +-
 ...c-stop-accessing-out-of-bounds-frame.patch |   7 +-
 ...-vp3-Add-missing-check-for-av_malloc.patch |  12 +-
 ...overflow-in-the-CRL-signature-parser.patch |  72 +++
 meta/recipes-support/libksba/libksba_1.6.2.bb |   3 +-
 17 files changed, 848 insertions(+), 28 deletions(-)
 create mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 create mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1521.patch
 create mode 100644 
meta/recipes-devtools/python/python3-setuptools/0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch
 create mode 100644 
meta/recipes-devtools/python/python3-wheel/0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
 create mode 100644 
meta/recipes-support/libksba/libksba/0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch

-- 
2.25.1


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

[OE-core][kirkstone 2/9] qemu: Fix CVE-2022-4144

From: Bhabu Bindu 

Add patch to fix CVE-2022-4144

Link: https://security-tracker.debian.org/tracker/CVE-2022-4144

Signed-off-by: Bhabu Bindu 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2022-4144.patch | 99 +++
 2 files changed, 100 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index cc9681fb4b..b68be447f1 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -92,6 +92,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \

file://0020-target-ppc-move-xs-n-madd-am-ds-p-xs-n-msub-am-ds-p-.patch \
file://0021-target-ppc-implement-xs-n-maddqp-o-xs-n-msubqp-o.patch \
file://CVE-2022-3165.patch \
+   file://CVE-2022-4144.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
new file mode 100644
index 00..96052a19e8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
@@ -0,0 +1,99 @@
+From 6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Mon, 28 Nov 2022 21:27:40 +0100
+Subject: [PATCH] hw/display/qxl: Avoid buffer overrun in qxl_phys2virt
+ (CVE-2022-4144)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Have qxl_get_check_slot_offset() return false if the requested
+buffer size does not fit within the slot memory region.
+
+Similarly qxl_phys2virt() now returns NULL in such case, and
+qxl_dirty_one_surface() aborts.
+
+This avoids buffer overrun in the host pointer returned by
+memory_region_get_ram_ptr().
+
+Fixes: CVE-2022-4144 (out-of-bounds read)
+Reported-by: Wenxu Yin (@awxylitol)
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1336
+
+CVE: CVE-2022-4144
+Upstream-Status: Backport 
[https://gitlab.com/qemu-project/qemu/-/commit/6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622]
+Comments: Deleted patch hunk in qxl.h,as it contains change
+in comments which is not present in current version of qemu
+
+Signed-off-by: Philippe Mathieu-DaudÃ© 
+Signed-off-by: Stefan Hajnoczi 
+Message-Id: <20221128202741.4945-5-phi...@linaro.org>
+Signed-off-by: Bhabu Bindu 
+---
+ hw/display/qxl.c | 27 +++
+ 1 files changed, 23 insertions(+), 4 deletions(-)
+
+diff --git a/hw/display/qxl.c b/hw/display/qxl.c
+index 231d733250..0b21626aad 100644
+--- a/hw/display/qxl.c
 b/hw/display/qxl.c
+@@ -1424,11 +1424,13 @@ static void qxl_reset_surfaces(PCIQXLDevice *d)
+ 
+ /* can be also called from spice server thread context */
+ static bool qxl_get_check_slot_offset(PCIQXLDevice *qxl, QXLPHYSICAL pqxl,
+-  uint32_t *s, uint64_t *o)
++  uint32_t *s, uint64_t *o,
++  size_t size_requested)
+ {
+ uint64_t phys   = le64_to_cpu(pqxl);
+ uint32_t slot   = (phys >> (64 -  8)) & 0xff;
+ uint64_t offset = phys & 0x;
++uint64_t size_available;
+ 
+ if (slot >= NUM_MEMSLOTS) {
+ qxl_set_guest_bug(qxl, "slot too large %d >= %d", slot,
+@@ -1452,6 +1454,23 @@ static bool qxl_get_check_slot_offset(PCIQXLDevice 
*qxl, QXLPHYSICAL pqxl,
+   slot, offset, qxl->guest_slots[slot].size);
+ return false;
+ }
++size_available = memory_region_size(qxl->guest_slots[slot].mr);
++if (qxl->guest_slots[slot].offset + offset >= size_available) {
++qxl_set_guest_bug(qxl,
++  "slot %d offset %"PRIu64" > region size 
%"PRIu64"\n",
++  slot, qxl->guest_slots[slot].offset + offset,
++  size_available);
++return false;
++}
++size_available -= qxl->guest_slots[slot].offset + offset;
++if (size_requested > size_available) {
++qxl_set_guest_bug(qxl,
++  "slot %d offset %"PRIu64" size %zu: "
++  "overrun by %"PRIu64" bytes\n",
++  slot, offset, size_requested,
++  size_requested - size_available);
++return false;
++}
+ 
+ *s = slot;
+ *o = offset;
+@@ -1471,7 +1490,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL pqxl, 
int group_id,
+ offset = le64_to_cpu(pqxl) & 0x;
+ return (void *)(intptr_t)offset;
+ case MEMSLOT_GROUP_GUEST:
+-if (!qxl_get_check_slot_offset(qxl, pqxl, &slot, &offset)) {
++if (!qxl_get_check_slot_offset(qxl, pqxl, &slot, &offset, size)) {
+ return NULL;
+ }
+ ptr = memory_region_get_ram_ptr(qxl->guest_slots[slot].mr);
+@@ -1937,9 +1956

[OE-core][kirkstone 3/9] python3-setuptools: fix for CVE-2022-40897

From: Narpat Mali 

Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote 
attackers
to cause a denial of service via HTML in a crafted package or custom 
PackageIndex
page. There is a Regular Expression Denial of Service (ReDoS) in 
package_index.py.

CVE: CVE-2022-40897

Upstream-Status: Backport 
[https://github.com/pypa/setuptools/commit/43a9c9bfa6aa626ec2a22540bea28d2ca77964be]

Signed-off-by: Narpat Mali 
Signed-off-by: Steve Sakoman 
---
 ...-of-whitespace-to-search-backtrack.-.patch | 31 +++
 .../python/python3-setuptools_59.5.0.bb   |  1 +
 2 files changed, 32 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-setuptools/0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch

diff --git 
a/meta/recipes-devtools/python/python3-setuptools/0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch
 
b/meta/recipes-devtools/python/python3-setuptools/0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch
new file mode 100644
index 00..20a13da7bc
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-setuptools/0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch
@@ -0,0 +1,31 @@
+From 9e9f617a83f6593b476669030b0347d48e831c3f Mon Sep 17 00:00:00 2001
+From: Narpat Mali 
+Date: Mon, 9 Jan 2023 14:45:05 +
+Subject: [PATCH] Limit the amount of whitespace to search/backtrack. Fixes
+ #3659.
+
+CVE: CVE-2022-40897
+
+Upstream-Status: Backport 
[https://github.com/pypa/setuptools/commit/43a9c9bfa6aa626ec2a22540bea28d2ca77964be]
+
+Signed-off-by: Narpat Mali 
+---
+ setuptools/package_index.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/setuptools/package_index.py b/setuptools/package_index.py
+index 270e7f3..e93fcc6 100644
+--- a/setuptools/package_index.py
 b/setuptools/package_index.py
+@@ -197,7 +197,7 @@ def unique_values(func):
+ return wrapper
+ 
+ 
+-REL = re.compile(r"""<([^>]*\srel\s*=\s*['"]?([^'">]+)[^>]*)>""", re.I)
++REL = re.compile(r"""<([^>]*\srel\s{0,10}=\s{0,10}['"]?([^'" >]+)[^>]*)>""", 
re.I)
+ # this line is here to fix emacs' cruddy broken syntax highlighting
+ 
+ 
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb 
b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
index f2810e18d3..5f2676a04a 100644
--- a/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
+++ b/meta/recipes-devtools/python/python3-setuptools_59.5.0.bb
@@ -11,6 +11,7 @@ SRC_URI:append:class-native = " 
file://0001-conditionally-do-not-fetch-code-by-e
 SRC_URI += "\
 file://0001-change-shebang-to-python3.patch \
 file://0001-_distutils-sysconfig-append-STAGING_LIBDIR-python-sy.patch \
+file://0001-Limit-the-amount-of-whitespace-to-search-backtrack.-.patch \
 "
 
 SRC_URI[sha256sum] = 
"d144f85102f999444d06f9c0e8c737fd0194f10f2f7e5fdb77573f6e2fa4fad0"
-- 
2.25.1


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

[OE-core][kirkstone 4/9] python3-wheel: fix for CVE-2022-40898

From: Narpat Mali 

An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1
and earlier allows remote attackers to cause a denial of service via
attacker controlled input to wheel cli.

CVE: CVE-2022-40898

Upstream-Status: Backport 
[https://github.com/pypa/wheel/commit/88f02bc335d5404991e532e7f3b0fc80437bf4e0]

Signed-off-by: Narpat Mali 
---
 ...tential-DoS-attack-via-WHEEL_INFO_RE.patch | 32 +++
 .../python/python3-wheel_0.37.1.bb|  4 ++-
 2 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/python/python3-wheel/0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch

diff --git 
a/meta/recipes-devtools/python/python3-wheel/0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch
 
b/meta/recipes-devtools/python/python3-wheel/0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch
new file mode 100644
index 00..bdaae7dd10
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-wheel/0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch
@@ -0,0 +1,32 @@
+From a9a0d67a663f20b69903751c23851dd4cd6b49d4 Mon Sep 17 00:00:00 2001
+From: Narpat Mali 
+Date: Wed, 11 Jan 2023 07:45:57 +
+Subject: [PATCH] Fixed potential DoS attack via WHEEL_INFO_RE
+
+CVE: CVE-2022-40898
+
+Upstream-Status: Backport 
[https://github.com/pypa/wheel/commit/88f02bc335d5404991e532e7f3b0fc80437bf4e0]
+
+Signed-off-by: Narpat Mali 
+---
+ src/wheel/wheelfile.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/wheel/wheelfile.py b/src/wheel/wheelfile.py
+index 21e7361..ff06edf 100644
+--- a/src/wheel/wheelfile.py
 b/src/wheel/wheelfile.py
+@@ -27,8 +27,8 @@ else:
+ # Non-greedy matching of an optional build number may be too clever (more
+ # invalid wheel filenames will match). Separate regex for .dist-info?
+ WHEEL_INFO_RE = re.compile(
+-r"""^(?P(?P.+?)-(?P.+?))(-(?P\d[^-]*))?
+- -(?P.+?)-(?P.+?)-(?P.+?)\.whl$""",
++r"""^(?P(?P[^-]+?)-(?P[^-]+?))(-(?P\d[^-]*))?
++ -(?P[^-]+?)-(?P[^-]+?)-(?P[^.]+?)\.whl$""",
+ re.VERBOSE)
+ 
+ 
+-- 
+2.32.0
+
diff --git a/meta/recipes-devtools/python/python3-wheel_0.37.1.bb 
b/meta/recipes-devtools/python/python3-wheel_0.37.1.bb
index 2f7dd122ba..3ee03ddd36 100644
--- a/meta/recipes-devtools/python/python3-wheel_0.37.1.bb
+++ b/meta/recipes-devtools/python/python3-wheel_0.37.1.bb
@@ -8,7 +8,9 @@ SRC_URI[sha256sum] = 
"e9a504e793efbca1b8e0e9cb979a249cf4a0a7b5b8c9e8b65a5e39d495
 
 inherit python_flit_core pypi
 
-SRC_URI += " 
file://0001-Backport-pyproject.toml-from-flit-backend-branch.patch"
+SRC_URI += "file://0001-Backport-pyproject.toml-from-flit-backend-branch.patch 
\
+file://0001-Fixed-potential-DoS-attack-via-WHEEL_INFO_RE.patch \
+   "
 
 BBCLASSEXTEND = "native nativesdk"
 
-- 
2.25.1


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

[OE-core][kirkstone 1/9] ffmpeg: refresh patches to apply cleanly

From: Martin Jansa 

* the last patch added in:
  
https://git.openembedded.org/openembedded-core/commit/?h=kirkstone&id=874b72fe259cd3a23f4613fccfe2e9cc3f79cd6a
  doesn't apply cleanly.

* fixes:
  ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:

  Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
  patching file libavcodec/vp3.c
  Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).

Signed-off-by: Martin Jansa 
Signed-off-by: Steve Sakoman 
---
 ...c-stop-accessing-out-of-bounds-frame.patch | 19 ---
 ...c-stop-accessing-out-of-bounds-frame.patch |  7 ++-
 ...-vp3-Add-missing-check-for-av_malloc.patch | 12 +---
 3 files changed, 15 insertions(+), 23 deletions(-)

diff --git 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
index 2775a81cc8..23573bb6b3 100644
--- 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
+++ 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
@@ -1,4 +1,4 @@
-From 92f9b28ed84a77138105475beba16c146bdaf984 Mon Sep 17 00:00:00 2001
+From ce25c03fb83395c0a8b5b8121182a486c4408dd4 Mon Sep 17 00:00:00 2001
 From: Paul B Mahol 
 Date: Sat, 12 Nov 2022 16:12:00 +0100
 Subject: [PATCH] avcodec/rpzaenc: stop accessing out of bounds frame
@@ -12,10 +12,10 @@ Signed-off-by: 
  1 file changed, 15 insertions(+), 7 deletions(-)
 
 diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
-index d710eb4f82..4ced9523e2 100644
+index 337b1fa..3e97c87 100644
 --- a/libavcodec/rpzaenc.c
 +++ b/libavcodec/rpzaenc.c
-@@ -205,7 +205,7 @@ static void get_max_component_diff(const BlockInfo *bi, 
const uint16_t *block_pt
+@@ -205,7 +205,7 @@ static void get_max_component_diff(BlockInfo *bi, uint16_t 
*block_ptr,
  
  // loop thru and compare pixels
  for (y = 0; y < bi->block_height; y++) {
@@ -24,7 +24,7 @@ index d710eb4f82..4ced9523e2 100644
  // TODO:  optimize
  min_r = FFMIN(R(block_ptr[x]), min_r);
  min_g = FFMIN(G(block_ptr[x]), min_g);
-@@ -278,7 +278,7 @@ static int leastsquares(const uint16_t *block_ptr, const 
BlockInfo *bi,
+@@ -277,7 +277,7 @@ static int leastsquares(uint16_t *block_ptr, BlockInfo *bi,
  return -1;
  
  for (i = 0; i < bi->block_height; i++) {
@@ -33,7 +33,7 @@ index d710eb4f82..4ced9523e2 100644
  x = GET_CHAN(block_ptr[j], xchannel);
  y = GET_CHAN(block_ptr[j], ychannel);
  sumx += x;
-@@ -325,7 +325,7 @@ static int calc_lsq_max_fit_error(const uint16_t 
*block_ptr, const BlockInfo *bi
+@@ -324,7 +324,7 @@ static int calc_lsq_max_fit_error(uint16_t *block_ptr, 
BlockInfo *bi,
  int max_err = 0;
  
  for (i = 0; i < bi->block_height; i++) {
@@ -42,7 +42,7 @@ index d710eb4f82..4ced9523e2 100644
  int x_inc, lin_y, lin_x;
  x = GET_CHAN(block_ptr[j], xchannel);
  y = GET_CHAN(block_ptr[j], ychannel);
-@@ -420,7 +420,9 @@ static void update_block_in_prev_frame(const uint16_t 
*src_pixels,
+@@ -419,7 +419,9 @@ static void update_block_in_prev_frame(const uint16_t 
*src_pixels,
 uint16_t *dest_pixels,
 const BlockInfo *bi, int block_counter)
  {
@@ -53,7 +53,7 @@ index d710eb4f82..4ced9523e2 100644
  memcpy(dest_pixels, src_pixels, 8);
  dest_pixels += bi->rowstride;
  src_pixels += bi->rowstride;
-@@ -730,14 +732,15 @@ post_skip :
+@@ -729,14 +731,15 @@ post_skip :
  
  if (err > s->sixteen_color_thresh) { // DO SIXTEEN COLOR BLOCK
  uint16_t *row_ptr;
@@ -72,7 +72,7 @@ index d710eb4f82..4ced9523e2 100644
  rgb555 = row_ptr[x] & ~0x8000;
  
  put_bits(&s->pb, 16, rgb555);
-@@ -745,6 +748,11 @@ post_skip :
+@@ -744,6 +747,11 @@ post_skip :
  row_ptr += bi.rowstride;
  }
  
@@ -84,6 +84,3 @@ index d710eb4f82..4ced9523e2 100644
  block_counter++;
  } else { // FOUR COLOR BLOCK
  block_counter += encode_four_color_block(min_color, max_color,
--- 
-2.34.1
-
diff --git 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
index 923fc6a9c1..6e237fdd52 100644
--- 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
+++ 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
@@ -1,4 +1,4 @@
-From 13c13109759090b7f7182480d075e13b36ed8edd Mon Sep 17 00:00:00 2001
+From d2f31887df2c42948dba7446c475026fdbc69336 Mon Sep 17 00:00:00 2001
 From: Paul B Mahol

[OE-core][kirkstone 5/9] python3-git: fix for CVE-2022-24439

From: Narpat Mali 

All versions of package gitpython are vulnerable to Remote Code Execution
(RCE) due to improper user input validation, which makes it possible to
inject a maliciously crafted remote URL into the clone command. Exploiting
this vulnerability is possible because the library makes external calls to
git without sufficient sanitization of input arguments.

CVE: CVE-2022-24439

Upstream-Status: Backport

Reference:
https://github.com/gitpython-developers/GitPython/discussions/1529
https://github.com/gitpython-developers/GitPython/pull/1518
https://github.com/gitpython-developers/GitPython/pull/1521

Signed-off-by: Narpat Mali 
---
 ...-git-CVE-2022-24439-fix-from-PR-1518.patch |  97 
 ...-git-CVE-2022-24439-fix-from-PR-1521.patch | 488 ++
 .../python/python3-git_3.1.27.bb  |   4 +
 3 files changed, 589 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 create mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1521.patch

diff --git 
a/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 
b/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
new file mode 100644
index 00..16192b22c7
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
@@ -0,0 +1,97 @@
+From 6ebe9231cd34dacd32a964859bc509aaa1e3f5fd Mon Sep 17 00:00:00 2001
+From: Narpat Mali 
+Date: Fri, 6 Jan 2023 14:13:10 +
+Subject: [PATCH] python3-git: CVE-2022-24439 fix from PR 1518
+
+Fix command injection
+Add `--` in some commands that receive user input
+and if interpreted as options could lead to remote
+code execution (RCE).
+
+There may be more commands that could benefit from `--`
+so the input is never interpreted as an option,
+but most of those aren't dangerous.
+
+Fixed commands:
+
+- push
+- pull
+- fetch
+- clone/clone_from and friends
+- archive (not sure if this one can be exploited, but it doesn't hurt
+  adding `--` :))
+
+For anyone using GitPython and exposing any of the GitPython methods to users,
+make sure to always validate the input (like if starts with `--`).
+And for anyone allowing users to pass arbitrary options, be aware
+that some options may lead fo RCE, like `--exc`, `--upload-pack`,
+`--receive-pack`, `--config` (#1516).
+
+Ref #1517
+
+CVE: CVE-2022-24439
+
+Upstream-Status: Backport 
[https://github.com/gitpython-developers/GitPython/pull/1518]
+
+Signed-off-by: Narpat Mali 
+---
+ git/remote.py| 6 +++---
+ git/repo/base.py | 4 ++--
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/git/remote.py b/git/remote.py
+index 56f3c5b..59681bc 100644
+--- a/git/remote.py
 b/git/remote.py
+@@ -881,7 +881,7 @@ class Remote(LazyMixin, IterableObj):
+ else:
+ args = [refspec]
+ 
+-proc = self.repo.git.fetch(self, *args, as_process=True, 
with_stdout=False,
++proc = self.repo.git.fetch("--", self, *args, as_process=True, 
with_stdout=False,
+universal_newlines=True, v=verbose, 
**kwargs)
+ res = self._get_fetch_info_from_stderr(proc, progress,
+
kill_after_timeout=kill_after_timeout)
+@@ -905,7 +905,7 @@ class Remote(LazyMixin, IterableObj):
+ # No argument refspec, then ensure the repo's config has a fetch 
refspec.
+ self._assert_refspec()
+ kwargs = add_progress(kwargs, self.repo.git, progress)
+-proc = self.repo.git.pull(self, refspec, with_stdout=False, 
as_process=True,
++proc = self.repo.git.pull("--", self, refspec, with_stdout=False, 
as_process=True,
+   universal_newlines=True, v=True, **kwargs)
+ res = self._get_fetch_info_from_stderr(proc, progress,
+
kill_after_timeout=kill_after_timeout)
+@@ -945,7 +945,7 @@ class Remote(LazyMixin, IterableObj):
+ If the operation fails completely, the length of the returned 
IterableList will
+ be 0."""
+ kwargs = add_progress(kwargs, self.repo.git, progress)
+-proc = self.repo.git.push(self, refspec, porcelain=True, 
as_process=True,
++proc = self.repo.git.push("--", self, refspec, porcelain=True, 
as_process=True,
+   universal_newlines=True,
+   kill_after_timeout=kill_after_timeout,
+   **kwargs)
+diff --git a/git/repo/base.py b/git/repo/base.py
+index 7713c91..f14f929 100644
+--- a/git/repo/base.py
 b/git/repo/base.py
+@@ -1072,7 +1072,7 @@ class Repo(object):
+ multi = None
+ if multi_options:
+ multi = shlex.split(' '.join(multi_options))
+-proc = git.clone(multi, Git.polish_url(st

[OE-core][kirkstone 6/9] libksba: fix CVE-2022-47629

From: Yogita Urade 

Libksba before 1.6.3 is prone to an integer overflow vulnerability in the CRL 
signature parser.

CVE: CVE-2022-47926

References: https://nvd.nist.gov/vuln/detail/CVE-2022-47629

Signed-off-by: Yogita Urade 
---
 ...overflow-in-the-CRL-signature-parser.patch | 72 +++
 meta/recipes-support/libksba/libksba_1.6.2.bb |  3 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-support/libksba/libksba/0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch

diff --git 
a/meta/recipes-support/libksba/libksba/0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch
 
b/meta/recipes-support/libksba/libksba/0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch
new file mode 100644
index 00..8c0080d56b
--- /dev/null
+++ 
b/meta/recipes-support/libksba/libksba/0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch
@@ -0,0 +1,72 @@
+From f61a5ea4e0f6a80fd4b28ef0174bee77793cf070 Mon Sep 17 00:00:00 2001
+From: Werner Koch 
+Date: Tue, 22 Nov 2022 16:36:46 +0100
+Subject: [PATCH] Fix an integer overflow in the CRL signature parser.
+
+* src/crl.c (parse_signature): N+N2 now checked for overflow.
+
+* src/ocsp.c (parse_response_extensions): Do not accept too large
+values.
+(parse_single_extensions): Ditto.
+--
+
+The second patch is an extra safegourd not related to the reported
+bug.
+
+CVE: CVE-2022-47629
+
+Upstream-Status: Backport 
[https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=commit;h=f61a5ea4e0f6a80fd4b28ef0174bee77793cf070]
+
+GnuPG-bug-id: 6284
+Reported-by: Joseph Surin, elttam
+---
+ src/crl.c  |  2 +-
+ src/ocsp.c | 12 
+ 2 files changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/src/crl.c b/src/crl.c
+index 9f71c85..2e6ca29 100644
+--- a/src/crl.c
 b/src/crl.c
+@@ -1349,7 +1349,7 @@ parse_signature (ksba_crl_t crl)
+  && !ti.is_constructed) )
+ return gpg_error (GPG_ERR_INV_CRL_OBJ);
+   n2 = ti.nhdr + ti.length;
+-  if (n + n2 >= DIM(tmpbuf))
++  if (n + n2 >= DIM(tmpbuf) || (n + n2) < n)
+ return gpg_error (GPG_ERR_TOO_LARGE);
+   memcpy (tmpbuf+n, ti.buf, ti.nhdr);
+   err = read_buffer (crl->reader, tmpbuf+n+ti.nhdr, ti.length);
+diff --git a/src/ocsp.c b/src/ocsp.c
+index d4cba04..657d15f 100644
+--- a/src/ocsp.c
 b/src/ocsp.c
+@@ -721,6 +721,12 @@ parse_response_extensions (ksba_ocsp_t ocsp,
+   || memcmp (ocsp->nonce, data, ti.length))
+ ocsp->bad_nonce = 1;
+ }
++  if (ti.length > (1<<24))
++{
++  /* Bail out on much too large objects.  */
++  err = gpg_error (GPG_ERR_BAD_BER);
++  goto leave;
++}
+   ex = xtrymalloc (sizeof *ex + strlen (oid) + ti.length);
+   if (!ex)
+ {
+@@ -788,6 +794,12 @@ parse_single_extensions (struct ocsp_reqitem_s *ri,
+   err = parse_octet_string (&data, &datalen, &ti);
+   if (err)
+ goto leave;
++  if (ti.length > (1<<24))
++{
++  /* Bail out on much too large objects.  */
++  err = gpg_error (GPG_ERR_BAD_BER);
++  goto leave;
++}
+   ex = xtrymalloc (sizeof *ex + strlen (oid) + ti.length);
+   if (!ex)
+ {
+-- 
+2.32.0
+
diff --git a/meta/recipes-support/libksba/libksba_1.6.2.bb 
b/meta/recipes-support/libksba/libksba_1.6.2.bb
index f6ecb9aec4..d0ee8475f8 100644
--- a/meta/recipes-support/libksba/libksba_1.6.2.bb
+++ b/meta/recipes-support/libksba/libksba_1.6.2.bb
@@ -22,7 +22,8 @@ inherit autotools binconfig-disabled pkgconfig texinfo
 
 UPSTREAM_CHECK_URI = "https://gnupg.org/download/index.html";
 SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
-   file://ksba-add-pkgconfig-support.patch"
+   file://ksba-add-pkgconfig-support.patch \
+   
file://0001-Fix-an-integer-overflow-in-the-CRL-signature-parser.patch"
 
 SRC_URI[sha256sum] = 
"fce01ccac59812bddadffacff017dac2e4762bdb6ebc6ffe06f6ed4f6192c971"
 
-- 
2.25.1


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

[OE-core][kirkstone 7/9] glibc: stable 2.35 branch updates.

From: Yash Shinde 

Below commits on glibc-2.35 stable branch are updated.

293211b6fd time: Use 64 bit time on tzfile
26c8278889 nscd: Use 64 bit time_t on libc nscd routines (BZ# 29402)
f75f61b659 nis: Build libnsl with 64 bit time_t
ca97201c24 Apply asm redirections in syslog.h before first use [BZ #27087]
cad7947db7 elf: Fix wrong fscanf usage on tst-pldd
e9eb987894 Allow for unpriviledged nested containers
2636fbb7ef elf: Fix wrong fscanf usage on tst-pldd
e7019eeeb5 x86: Fix wcsnlen-avx2 page cross length comparison [BZ #29591]
fb73a40981 elf: Fix rtld-audit trampoline for aarch64

Signed-off-by: Yash Shinde 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-core/glibc/glibc-version.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc-version.inc 
b/meta/recipes-core/glibc/glibc-version.inc
index 7d7db46c2f..d36da0ce3f 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
 SRCBRANCH ?= "release/2.35/master"
 PV = "2.35"
-SRCREV_glibc ?= "8d125a1f9145ad90c94e438858d6b5b7578686f2"
+SRCREV_glibc ?= "293211b6fddf60fc407d21fcba0326dd2148f76b"
 SRCREV_localedef ?= "794da69788cbf9bf57b59a852f9f11307663fa87"
 
 GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
-- 
2.25.1


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

[OE-core][kirkstone 8/9] freetype:update mirror site.

From: KARN JYE LAU 

update SAVANNAH_NONGNU_MIRROR to SAVANNAH_GNU_MIRROR
to resolve package fetching issues.

Signed-off-by: KARN JYE LAU 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-graphics/freetype/freetype_2.11.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/freetype/freetype_2.11.1.bb 
b/meta/recipes-graphics/freetype/freetype_2.11.1.bb
index 5b464d3d70..d425e162bc 100644
--- a/meta/recipes-graphics/freetype/freetype_2.11.1.bb
+++ b/meta/recipes-graphics/freetype/freetype_2.11.1.bb
@@ -12,7 +12,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.TXT;md5=a5927784d823d443c6cae55701d01553 \
 file://docs/FTL.TXT;md5=9f37b4e6afa3fef9dba8932b16bd3f97 \
 file://docs/GPLv2.TXT;md5=8ef380476f642c20ebf40fecb0add2ec"
 
-SRC_URI = "${SAVANNAH_NONGNU_MIRROR}/${BPN}/${BP}.tar.xz \ 
+SRC_URI = "${SAVANNAH_GNU_MIRROR}/${BPN}/${BP}.tar.xz \ 
file://CVE-2022-27404.patch \
file://CVE-2022-27405.patch \
file://CVE-2022-27406.patch \
-- 
2.25.1


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

[OE-core][kirkstone 9/9] gtk-icon-cache: Fix GTKIC_CMD if-else condition

2023-01-17 Thread Sandeep Gundlupet Raju via lists.openembedded.org

From: Daniel Gomez 

GTKIC_CMD variable gets the wrong assignation leading into a post
install script error. Fix if-else condition in GTKIC_CMD variable
to assign gtk4-update-icon-cache when GTKIC_VERSION is 4 but
gtk-update-icon-cache when is 3.

Also, rename gtk-update-icon-cache-3.0.0 to gtk-update-icon-cache-3.0
to match the gtk-update-icon-cache binary name deployed in
meta/recipes-gnome/gtk+/gtk+3.inc.

Signed-off-by: Daniel Gomez 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
Signed-off-by: Robert Joslyn 
Signed-off-by: Steve Sakoman 
---
 meta/classes/gtk-icon-cache.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass 
b/meta/classes/gtk-icon-cache.bbclass
index 6808339b90..f999b891f3 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -3,7 +3,7 @@ FILES:${PN} += "${datadir}/icons/hicolor"
 GTKIC_VERSION ??= '3'
 
 GTKPN = "${@ 'gtk4' if d.getVar('GTKIC_VERSION') == '4' else 'gtk+3' }"
-GTKIC_CMD = "${@ 'gtk-update-icon-cache-3.0.0' if d.getVar('GTKIC_VERSION') == 
'4' else 'gtk4-update-icon-cache' }"
+GTKIC_CMD = "${@ 'gtk4-update-icon-cache' if d.getVar('GTKIC_VERSION') == '4' 
else 'gtk-update-icon-cache-3.0' }"
 
 #gtk+3/gtk4 require GTK3DISTROFEATURES, DEPENDS on it make all the
 #recipes inherit this class require GTK3DISTROFEATURES
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176047): 
https://lists.openembedded.org/g/openembedded-core/message/176047
Mute This Topic: https://lists.openembedded.org/mt/96330198/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] uninative-tarball: Add libgcc

2023-01-17 Thread Jose Quaresma

Richard Purdie  escreveu no dia
segunda, 16/01/2023 à(s) 23:42:

> On Mon, 2023-01-16 at 19:21 +, Jose Quaresma wrote:
> > Hi Richard,
> >
> > I am seeing some build errors like this at the end of the build whre
> bibake segment fault.
> > My problem is this happens on a build that doesn't use uninative,
> > does bitbake require uninative to build on master?
>
> No, it doesn't.
>
> My worry was that uninative didn't contain libgcc which meant that
> builds could fail like this if it wasn't present. The reason for the
> change is threading in bitbake itself and the thread.join() calls which
> seem to trigger pthread_cancel() calls under some circumstances. Having
> libgcc present in uninative seemed like a good idea so I've ensured
> that. I wasn't entirely convinced it would solve it, I half expected to
> see a new/different error replacing it.
>
> Is libgcc present on your build system? It would seem strange for it
> not to be but that is what the error message suggests.
>

No, I don't have libgcc installed on my build container and this is the
main reason.
I know that we now need the libgcc on the build host and this can satisfied
in two different ways:

1 - installing the libgcc on the build host
2 - using the unative

For now I will use the [1] because I don't use the uninative.
Maybe the documentation needs to be updated adding the libgcc
as a requirement of bitbake.


> I've also seem mention of issues with this in some versions of python
> but I've not seen any errors on the autobuilder since I ensured it was
> present in uninative.
>
> > This is my build log where bitbake crash at the end:
> >
> > INFO: Build completion summary:
> > INFO:   do_populate_sysroot: 100.0% sstate reuse(387 setscene, 0 scratch)
> > INFO:   do_deploy_source_date_epoch: 100.0% sstate reuse(5 setscene, 0
> scratch)
> > INFO:   do_deploy_archives: 100.0% sstate reuse(400 setscene, 0 scratch)
> > INFO:   do_create_spdx: 100.0% sstate reuse(364 setscene, 0 scratch)
> > INFO:   do_create_runtime_spdx: 100.0% sstate reuse(342 setscene, 0
> scratch)
> > INFO:   do_package_qa: 100.0% sstate reuse(243 setscene, 0 scratch)
> > INFO:   do_package: 100.0% sstate reuse(26 setscene, 0 scratch)
> > INFO:   do_packagedata: 100.0% sstate reuse(243 setscene, 0 scratch)
> > INFO:   do_package_write_ipk: 100.0% sstate reuse(243 setscene, 0
> scratch)
> > INFO:   do_populate_lic: 100.0% sstate reuse(395 setscene, 0 scratch)
> > INFO: Writing buildhistory
> > INFO: Writing buildhistory took: 10 seconds
> > libgcc_s.so.1 must be installed for pthread_cancel to work
> > /lmp/bb-build.sh: line 24: 91770 Aborted (core dumped)
> bitbake -D ...
>
> This is the build system's python saying it can't find libgcc_s.so.1 so
> I'd start by checking it is there. I'm assuming you're not using
> buildtools?
>

No, I am not using the buildtools nor the uninative.
My build container is ubuntu 20.04 based and dont have libgcc.
This is not the first time I see this error in the last few weeks
but I'll go install libgcc and it should fix my issue, if not i will come
back.

Jose



>
> Cheers,
>
> Richard
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176048): 
https://lists.openembedded.org/g/openembedded-core/message/176048
Mute This Topic: https://lists.openembedded.org/mt/96152280/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] uninative-tarball: Add libgcc

2023-01-17 Thread Richard Purdie

On Tue, 2023-01-17 at 14:35 +, Jose Quaresma wrote:
> No, I don't have libgcc installed on my build container and this is
> the main reason.
> I know that we now need the libgcc on the build host and this can
> satisfied in two different ways:
> 
> 1 - installing the libgcc on the build host

This is the correct thing to do here.

> 2 - using the unative
> 
> For now I will use the [1] because I don't use the uninative.
> Maybe the documentation needs to be updated adding the libgcc
> as a requirement of bitbake.

To be clear, this is a distro python dependency problem. python is
needing libgcc but is missing a dependency, that is the real issue.

We can document it as a known problem and something to install but we
should be clear it is required by python.

> 
> No, I am not using the buildtools nor the uninative.
> My build container is ubuntu 20.04 based and dont have libgcc.
> This is not the first time I see this error in the last few weeks
> but I'll go install libgcc and it should fix my issue, if not i will
> come back.

Sounds good. We should add libgcc to the list of packages to ensure are
installed in the docs. Patches for that would be very welcome.
 
Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176049): 
https://lists.openembedded.org/g/openembedded-core/message/176049
Mute This Topic: https://lists.openembedded.org/mt/96152280/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] uninative-tarball: Add libgcc

2023-01-17 Thread Jose Quaresma

Richard Purdie  escreveu no dia terça,
17/01/2023 à(s) 15:07:

> On Tue, 2023-01-17 at 14:35 +, Jose Quaresma wrote:
> > No, I don't have libgcc installed on my build container and this is
> > the main reason.
> > I know that we now need the libgcc on the build host and this can
> > satisfied in two different ways:
> >
> > 1 - installing the libgcc on the build host
>
> This is the correct thing to do here.
>
> > 2 - using the unative
> >
> > For now I will use the [1] because I don't use the uninative.
> > Maybe the documentation needs to be updated adding the libgcc
> > as a requirement of bitbake.
>
> To be clear, this is a distro python dependency problem. python is
> needing libgcc but is missing a dependency, that is the real issue.
>
> We can document it as a known problem and something to install but we
> should be clear it is required by python.
>
> >
> > No, I am not using the buildtools nor the uninative.
> > My build container is ubuntu 20.04 based and dont have libgcc.
> > This is not the first time I see this error in the last few weeks
> > but I'll go install libgcc and it should fix my issue, if not i will
> > come back.
>
> Sounds good. We should add libgcc to the list of packages to ensure are
> installed in the docs. Patches for that would be very welcome.
>

I will do some tests with libgcc installed and after that send something
to update the documentation.

Thanks for your time.

Jose


>
> Cheers,
>
> Richard
>


-- 
Best regards,

José Quaresma

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

[OE-core] Yocto Project Status 17 January 2023 (WW03)

2023-01-17 Thread Stephen Jolley

Current Dev Position: YP 4.2 M2

Next Deadline: 23rd January 2023 YP 4.2 M2 Build

 

Next Team Meetings:

*   Bug Triage meeting Thursday January 19th 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday January 17th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 4.1.2 is due to be released and YP 3.1.22 is in QA
*   We had a few annoying intermittent autobuilder bug fixes this week,
thanks to anyone who helped fix those!
*   Failures on the autobuilder slowed down patch testing and merging as
builds took a long time to stabilize. Thankfully we believe the most
frequently occurring issues have been fixed so things should speed up again
a little this week.
*   CVE levels in master are becoming worrying again, help would be
appreciated to address the open issues.
*   We have a growing number of bugs in bugzilla, any help with them is
appreciated.

 

Ways to contribute:

*   As people are likely aware, the project has a number of components
which are either unmaintained, or have people with little to no time trying
to keep them alive. These components include: patchtest, layerindex,
devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more.
Many have open bugs. Help is welcome in trying to better look after these
components!
*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 4.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.2_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.2 Milestone Dates:

*   YP 4.2 M2 build date 2023/01/23
*   YP 4.2 M2 Release date 2023/02/03
*   YP 4.2 M3 build date 2023/02/20
*   YP 4.2 M3 Release date 2023/03/03
*   YP 4.2 M4 build date 2023/04/03
*   YP 4.2 M4 Release date 2023/04/28

 

Upcoming dot releases:

*   YP 4.1.2 ready for release
*   YP 3.1.22  built and in QA
*   YP 3.1.22 Release date 2023/01/27
*   YP 4.0.7 build date 2023/01/30
*   YP 4.0.7 Release date 2023/02/10
*   YP 3.1.23 build date 2023/02/13
*   YP 3.1.23 Release date 2023/02/24
*   YP 4.0.8 build date 2023/02/27
*   YP 4.0.8 Release date 2023/03/10
*   YP 4.1.3 build date 2023/03/06
*   YP 4.1.3 Release date 2023/03/17
*   YP 3.1.24 build date 2023/03/20
*   YP 3.1.24 Release date 2023/03/31
*   YP 4.0.9 build date 2023/04/10
*   YP 4.0.9 Release date 2023/04/21
*   YP 4.1.4 build date 2023/05/01
*   YP 4.1.4 Release date 2023/05/13
*   YP 3.1.25 build date 2023/05/08
*   YP 3.1.25 Release date 2023/05/19
*   YP 4.0.10 build date 2023/05/15
*   YP 4.0.10 Release date 2023/05/26

 

Tracking Metrics:

*   WDD 2457 (last week 2447) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1181 (last week 1176)
*   Patches in the Pending State: 279 (24%) [last week 281 (24%)]

*
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to s

Re: [oe-core][PATCH] mesa: update 22.2.3 -> 22.3.0

2023-01-17 Thread Samuli Piippo

I think this is now a webos specific issue since they have disabled xlib
feature (
https://github.com/shr-project/meta-webosose/blob/c96010fe4df28397a33e447bde650932a3463a9e/meta-webos/recipes-qt/qt6/qtbase_git.bbappend#L56
)
While the qtbase cmake configuration could be improved to better handle
situation where x11 dependencies are found but shouldn't be used, I think
the simplest solution would be to disable egl on X11 in the webos bbappend
(-DFEATURE_egl_x11=OFF)

-samuli

On Tue, 17 Jan 2023 at 13:01, Martin Jansa  wrote:

> Samuli:
>
> Similar mesa upgrade was merged recently:
>
> https://git.openembedded.org/openembedded-core/commit/?id=3bf4341ef6a681574a1c6f393bf241f412e26eac
>
> qtbase still fails the same, more details in:
>
> https://github.com/shr-project/meta-webosose/commit/c96010fe4df28397a33e447bde650932a3463a9e
>
> The change you've mentioned is the one which actually breaks some
> PACKAGECONFIG combinations, hopefully now you'll be able to reproduce it.
>
> Regards,
>
> On Thu, Dec 8, 2022 at 8:55 AM Martin Jansa via lists.openembedded.org
>  wrote:
>
>> On Thu, Dec 8, 2022 at 8:42 AM Samuli Piippo  wrote:
>>
>>> Qt6 should handle this already with
>>> https://codereview.qt-project.org/c/qt/qtbase/+/371780 in place.
>>> I tried test build with the mesa upgrade and didn't catch any build
>>> errors.
>>>
>>
>> I've tried qemux86-64 build with 6.4.1 and 6.5.0 from yesterday's dev
>> branch and both failed after including this mesa upgrade with:
>> | In file included from
>> qtbase/6.4.1-r0/recipe-sysroot/usr/include/EGL/egl.h:20,
>> |  from
>> qtbase/6.4.1-r0/build/include/QtGui/6.4.1/QtGui/private/../../../../../../git/src/gui/opengl/platform/egl/qt_egl_p.h:43,
>> |  from
>> qtbase/6.4.1-r0/build/include/QtGui/6.4.1/QtGui/private/qt_egl_p.h:1,
>> |  from
>> qtbase/6.4.1-r0/git/src/gui/opengl/platform/egl/qeglstreamconvenience_p.h:20,
>> |  from
>> qtbase/6.4.1-r0/git/src/gui/opengl/platform/egl/qeglstreamconvenience.cpp:4:
>> | qtbase/6.4.1-r0/recipe-sysroot/usr/include/EGL/eglplatform.h:109:10:
>> fatal error: X11/Xlib.h: No such file or directory
>> |   109 | #include 
>> |   |  ^~~~
>> | compilation terminated.
>>
>>>
>>
>>
>>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176052): 
https://lists.openembedded.org/g/openembedded-core/message/176052
Mute This Topic: https://lists.openembedded.org/mt/95388063/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][langdale][PATCH v2 1/2] kernel-fitimage: Adjust order of dtb/dtbo files


Hi All,

Can someone merge these patches to langdale branch?

Thanks,

Sandeep

On 1/13/2023 9:51 AM, Gundlupet Raju, Sandeep wrote:

Hi Richard, Alex,

Thanks for merging the patches in master. Can you merge these patches 
to langdale release as well?


Thanks,

Sandeep

On 1/12/2023 7:19 PM, Gundlupet Raju, Sandeep wrote:

Hi Michael,

Any updates on patch merge?

Thanks,

Sandeep

On 1/8/2023 10:25 AM, sandeep.gundlupet-r...@amd.com wrote:

From: Sandeep Gundlupet Raju 

The dtb files must be before the dtbo files, otherwise the overlays may
not be applied correctly.

 From Bruce Ashfield:

   We can split between dtbs and dtbos, they just need to be sorted
   for reproducibility reasons.

   Of course, this was only working by luck previously (before the
   sort), since it has always been gathering dtbs and dtbo's with
   find, depending on filesystem ordering for the order in the
   fitimage).

Signed-off-by: Sandeep Gundlupet Raju 
---

Changes in v2:
  - Remove 2 loops and use single loop for dtb and dtbo with same 
logic.


---
  meta/classes-recipe/kernel-fitimage.bbclass | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass

index 8ddebf8dd8..06cdc4f1ec 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -546,10 +546,11 @@ fitimage_assemble() {
    if [ -n "${EXTERNAL_KERNEL_DEVICETREE}" ]; then
  dtbcount=1
-    for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" \( -name 
'*.dtb' -o -name '*.dtbo' \) -printf '%P\n' | sort); do
+    for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name 
'*.dtb' -printf '%P\n' | sort) \
+    $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtbo' 
-printf '%P\n' | sort); do

  DTB=$(echo "$DTB" | tr '/' '_')
  -    # Skip DTB if we've picked it up previously
+    # Skip DTB/DTBO if we've picked it up previously
  echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
    DTBS="$DTBS $DTB"

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176053): 
https://lists.openembedded.org/g/openembedded-core/message/176053
Mute This Topic: https://lists.openembedded.org/mt/96134986/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] vim: upgrade 9.0.0947 -> 9.0.1211

Includes fixes for:
   https://nvd.nist.gov/vuln/detail/CVE-2023-0049
   https://nvd.nist.gov/vuln/detail/CVE-2023-0051
   https://nvd.nist.gov/vuln/detail/CVE-2023-0054
   https://nvd.nist.gov/vuln/detail/CVE-2023-0288

Signed-off-by: Randy MacLeod 
---
 meta/recipes-support/vim/vim.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index d86841efaa..9bc6881fce 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -20,8 +20,8 @@ SRC_URI = 
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://no-path-adjust.patch \
"
 
-PV .= ".0947"
-SRCREV = "cc762a48d42b579fb7bdec2c614636b830342dd5"
+PV .= ".1211"
+SRCREV = "f7d1c6e1884c76680980571f1cf15e0928d247b5"
 
 # Remove when 8.3 is out
 UPSTREAM_VERSION_UNKNOWN = "1"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176054): 
https://lists.openembedded.org/g/openembedded-core/message/176054
Mute This Topic: https://lists.openembedded.org/mt/96333742/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] gobject-introspection: check for GI_DATA_ENABLED

2023-01-17 Thread Luca Ceresoli via lists.openembedded.org

On Tue, 17 Jan 2023 at 11:57, Petr Kubizňák  wrote:
> I'm slowly progressing with the patch but always end up at the principal 
> issue of hard dependency on g-i being enabled.
>
> For example, graphene recipe does not reflect on "gobject-introspection-data" 
> being/not being in distro features, claiming gtk4 requires build with 
> introspection. Graphene can be patched to be buildable under both 
> circumstances but gtk4 then (unsurprisingly) fails in do_configure step due 
> to missing graphene-gobject-1.0 if g-i is disabled.
>
> I don't think gtk4 can be patched to build with g-i disabled, do you?
>
> If you agree with me, how can we proceed with the fact that some packages 
> (namely gtk4) basically cannot be built without the feature, while still 
> allowing to disable that feature? Is it really necessary to have everything 
> buildable with g-i disabled? Apparently, it's not buildable now.

It helps if you show the errors you are getting, and source code lines
they are coming from, so I do not have to guess what is happening or
dig around source code.

The way I read gtk4 and graphene source code, what the recipe claims
is not true: you can disable introspection in graphene, and it would
still build and install graphene-gobject.pc which is what gtk4 is
looking for. If the needed piece is not installed, then you need to
get to the bottom of why, e.g. specific source code lines where that
decision is made.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176055): 
https://lists.openembedded.org/g/openembedded-core/message/176055
Mute This Topic: https://lists.openembedded.org/mt/96048399/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 v2] scripts/oe-setup-layers: Make efficiently idempotent

Hello Chuck,

On Mon, 16 Jan 2023 17:59:30 -0800
"Chuck Wolber"  wrote:

> The effect of subsequent setup-layers executions is now either a NOOP
> or the minimal set of changes required to ensure layers precisely match
> the JSON configuration.
> 
> This change allows setup-layers to be incorporated into a team's
> configuration management strategy. In particular, the configuration
> JSON manages a "pinning policy" that documents the oversight of sources
> of change (a requirement for embedded development in highly regulated
> industries).
> 
> One model for this strategy would work as follows. Team level policy is
> developed to regularly review upstream commits that occur between the
> current upstream HEAD and the previously pinned revision. The JSON
> configuration is periodically updated after a review, test, and approval
> process. In the rare instance that an upstream change is considered
> problematic, the bbappend mechanism can be used to make relevant
> changes in the team's project repository. This approach also requires
> that team developers regularly run the project repository copy of
> setup-layers. This is most easily accomplished by including setup-layers
> in a wrapper script that all team developers use to interact with the
> bitbake tool suite (e.g. "bb bitbake foo-image"). Project level policy
> and oversight is effectively "contained" within this wrapper script,
> thereby reducing a significant source of human error.
> 
> Left unstated, but acknowledged here, are a number of nuances required
> to successfully implement the above strategy.  The details are out of
> scope for this explanation. What should be clear is that a larger
> configuration management strategy can now benefit from the utility
> provided by setup-layers.
> 
> Note: Neither the above configuration management strategy example nor
> the change itself is intended to alter the original intent to use
> "bitbake-layers create-layers-setup destdir" to keep pace with upstream
> activity for those who wish to use it that way.
> 
> Signed-off-by: Chuck Wolber 

I'm afraind I am unable to apply this patch on my testing branch as it
conflicts with another patch ("oe-setup-build: add a tool for
discovering config templates and setting up builds" by Alexander
Kanavin) which is already on my branch.

You might want to rework your patch on top of Alex's, or just wait for
it to be on master and then send a v3.

Kind regards,
Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176056): 
https://lists.openembedded.org/g/openembedded-core/message/176056
Mute This Topic: https://lists.openembedded.org/mt/96322236/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 v2] scripts/oe-setup-layers: Make efficiently idempotent

2023-01-17 Thread Luca Ceresoli via lists.openembedded.org

On Tue, 17 Jan 2023 at 18:03, Luca Ceresoli via lists.openembedded.org
 wrote:

> I'm afraind I am unable to apply this patch on my testing branch as it
> conflicts with another patch ("oe-setup-build: add a tool for
> discovering config templates and setting up builds" by Alexander
> Kanavin) which is already on my branch.
>
> You might want to rework your patch on top of Alex's, or just wait for
> it to be on master and then send a v3.

I think RP is not going to accept the oe-setup-build patch in its
current form, so you can drop it for now.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176057): 
https://lists.openembedded.org/g/openembedded-core/message/176057
Mute This Topic: https://lists.openembedded.org/mt/96322236/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 v2] scripts/oe-setup-layers: Make efficiently idempotent

Hi Alex,

On Tue, 17 Jan 2023 18:05:12 +0100
"Alexander Kanavin"  wrote:

> On Tue, 17 Jan 2023 at 18:03, Luca Ceresoli via lists.openembedded.org
>  wrote:
> 
> > I'm afraind I am unable to apply this patch on my testing branch as it
> > conflicts with another patch ("oe-setup-build: add a tool for
> > discovering config templates and setting up builds" by Alexander
> > Kanavin) which is already on my branch.
> >
> > You might want to rework your patch on top of Alex's, or just wait for
> > it to be on master and then send a v3.  
> 
> I think RP is not going to accept the oe-setup-build patch in its
> current form, so you can drop it for now.

Ah, sure, I had missed that, thanks for pointing out!

I removed Alex's patch from my branch and added Chuck's.

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176058): 
https://lists.openembedded.org/g/openembedded-core/message/176058
Mute This Topic: https://lists.openembedded.org/mt/96322236/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 v2] scripts/oe-setup-layers: Make efficiently idempotent

2023-01-17 Thread Chuck Wolber

On 1/17/23, 9:05 AM, "Alexander Kanavin" mailto:alex.kana...@gmail.com>> wrote:

> On Tue, 17 Jan 2023 at 18:03, Luca Ceresoli via lists.openembedded.org 
>  > wrote:
>
> > I'm afraind I am unable to apply this patch on my testing branch as it
> > conflicts with another patch ("oe-setup-build: add a tool for
> > discovering config templates and setting up builds" by Alexander
> > Kanavin) which is already on my branch.
> >
> > You might want to rework your patch on top of Alex's, or just wait for
> > it to be on master and then send a v3.
>
> I think RP is not going to accept the oe-setup-build patch in its
> current form, so you can drop it for now.

Agreed, it sounds like RP is holding Alex's patch back, so you should
probably go with my v2. Alex should not have any problems working
against my v2 patch when he updates his own patch.

..Ch:W..


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176059): 
https://lists.openembedded.org/g/openembedded-core/message/176059
Mute This Topic: https://lists.openembedded.org/mt/96322236/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] create-spdx: fix config build by adding dependency to enable reruns

2023-01-17 Thread Maanya Goenka via lists.openembedded.org

Also, signed off by Paul Eggleton: paul.eggle...@microsoft.com

From: maanyagoe...@linux.microsoft.com 
Sent: Tuesday, January 17, 2023 10:01 AM
To: openembedded-core@lists.openembedded.org 

Cc: Maanya Goenka ; Maanya Goenka 

Subject: [PATCH] create-spdx: fix config build by adding dependency to enable 
reruns

From: Maanya Goenka 

The issue encountered is about local stos builds failing (when these builds are
preceded by a local SoC OS or MOS build). Essentially, the failure is seen when
building two different configs with shared state, one where gcc-cross- 
has a dependency
and one where it doesn't (specifically, one where the abicheck class in 
meta-binaryaudit
is inherited and one where it isn't). Hence, the task signatures change but a 
rerun of those said tasks
does not occur. The result is that when the config with the dependency is built 
and then the one without
is built, due to incorrect dependencies, the SPDX manifest creation stage 
errors out.

create-spdx relies on BB_TASKDEPDATA to get dependencies and then adds that 
variable to
vardepsexclude. A change in dependencies therefore, does not result in a
re-execution of the tasks. This commit adds an explicit dependency on DEPENDS 
which influences
BB_TASKDEPDATA and triggers reruns for new config builds having different 
dependencies.

Signed-off-by: Maanya Goenka 
---
 meta/classes/create-spdx-2.2.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index f0513af..e2553b4 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -377,7 +377,7 @@ def collect_dep_recipes(d, doc, spdx_recipe):
 return dep_recipes

 collect_dep_recipes[vardepsexclude] += "BB_TASKDEPDATA"
-
+collect_dep_recipes[vardeps] += "DEPENDS"

 def collect_dep_sources(d, dep_recipes):
 import oe.sbom
--
1.8.3.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176060): 
https://lists.openembedded.org/g/openembedded-core/message/176060
Mute This Topic: https://lists.openembedded.org/mt/96336314/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] rust: Upgrade 1.66.0 -> 1.66.1


On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org wrote:
Rust community said the security fixes are only for the current stable 
relases.

https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older-releases/18152/3?u=sundeep-kokkonda
For old release we've to backport the patches ourselves.


The other alternatives are

1. upgrade to 1.66.1 on older branches,

2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older 
version for those who are risk averse,


3. add a mix-in layer (1) with the upgrade to 1.66.1.

For langdale, we'd update from 1.63 and for kirkstone, we'd update from 
1.59


See the link above for a discussion about what Fedora/RHEL and other 
distros are doing
and a description of the rust / crates.io test system known as crater 
that builds the

world for any significant rust change.


Is there any objection to doing 2 and if we don't see any problems after 
some time,

then removing the older version?

Sundeep,

If no one object, please update kirkstone and see if librsvg or 
python-cryptography or

anything else encounters a problem.

../Randy


1) 
https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS#LTS_.E2.80.9CMixin.E2.80.9D_repositories




So, for the Kirkstone & Langdale we've to back port the CVE fix.





--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176061): 
https://lists.openembedded.org/g/openembedded-core/message/176061
Mute This Topic: https://lists.openembedded.org/mt/96218038/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] rust: Upgrade 1.66.0 -> 1.66.1

2023-01-17 Thread Richard Purdie

On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote:
> On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org
> wrote:
>  
> >  Rust community said the security fixes are only for the current
> > stable relases.
> >  
> > https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older
> > -releases/18152/3?u=sundeep-kokkonda
> >  For old release we've to backport the patches ourselves.
> The other alternatives are
> 1. upgrade to 1.66.1 on older branches,
> 2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older
> version for those who are risk averse,
> 3. add a mix-in layer (1) with the upgrade to 1.66.1.
>  For langdale, we'd update from 1.63 and for kirkstone, we'd update
> from 1.59 
> See the link above for a discussion about what Fedora/RHEL and other
> distros are doing
>  and a description of the rust / crates.io test system known as
> crater that builds the 
>  world for any significant rust change.
> 
> Is there any objection to doing 2 and if we don't see any problems
> after some time,
>  then removing the older version?
> Sundeep, 
> If no one object, please update kirkstone and see if librsvg or
> python-cryptography or 
>  anything else encounters a problem. 

I'm afraid I don't like option 2. We don't do this for anything else so
we're now inventing some new policy. Either the upgrade is what we
decide is right or it isn't, I don't really like the idea of hedging
our bets and providing two versions, one of which nobody will use until
they're forced. It will also make security scans tricky as is the issue
dealt with or not?

Just for context, going back in time OE used to be awash with many
version of recipes and I'm reluctant to go back there as it was
horrible. They were added for exactly this kind of reasoning, which at
first seemed like a good idea.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176062): 
https://lists.openembedded.org/g/openembedded-core/message/176062
Mute This Topic: https://lists.openembedded.org/mt/96218038/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] rust: Upgrade 1.66.0 -> 1.66.1


On 2023-01-17 16:54, Richard Purdie wrote:

On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote:

On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org
wrote:
  

  Rust community said the security fixes are only for the current
stable relases.
  
https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older

-releases/18152/3?u=sundeep-kokkonda
  For old release we've to backport the patches ourselves.

The other alternatives are
1. upgrade to 1.66.1 on older branches,
2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older
version for those who are risk averse,
3. add a mix-in layer (1) with the upgrade to 1.66.1.
  For langdale, we'd update from 1.63 and for kirkstone, we'd update
from 1.59
See the link above for a discussion about what Fedora/RHEL and other
distros are doing
  and a description of the rust / crates.io test system known as
crater that builds the
  world for any significant rust change.

Is there any objection to doing 2 and if we don't see any problems
after some time,
  then removing the older version?
Sundeep,
If no one object, please update kirkstone and see if librsvg or
python-cryptography or
  anything else encounters a problem.


I'm afraid I don't like option 2. We don't do this for anything else so
we're now inventing some new policy. Either the upgrade is what we
decide is right or it isn't, I don't really like the idea of hedging
our bets and providing two versions, one of which nobody will use until
they're forced. It will also make security scans tricky as is the issue
dealt with or not?

Just for context, going back in time OE used to be awash with many
version of recipes and I'm reluctant to go back there as it was
horrible. They were added for exactly this kind of reasoning, which at
first seemed like a good idea.


Okay, make sense, option 1 it is!

../Randy


Cheers,

Richard




--
# Randy MacLeod
# Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176063): 
https://lists.openembedded.org/g/openembedded-core/message/176063
Mute This Topic: https://lists.openembedded.org/mt/96218038/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] rust: Upgrade 1.66.0 -> 1.66.1

Option 1 looks like a new policy too. If we can upgrade rust across
many major versions in a stable release, then why not other items?

Alex

On Tue, 17 Jan 2023 at 22:57, Randy MacLeod  wrote:
>
> On 2023-01-17 16:54, Richard Purdie wrote:
> > On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote:
> >> On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org
> >> wrote:
> >>
> >>>   Rust community said the security fixes are only for the current
> >>> stable relases.
> >>>
> >>> https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older
> >>> -releases/18152/3?u=sundeep-kokkonda
> >>>   For old release we've to backport the patches ourselves.
> >> The other alternatives are
> >> 1. upgrade to 1.66.1 on older branches,
> >> 2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older
> >> version for those who are risk averse,
> >> 3. add a mix-in layer (1) with the upgrade to 1.66.1.
> >>   For langdale, we'd update from 1.63 and for kirkstone, we'd update
> >> from 1.59
> >> See the link above for a discussion about what Fedora/RHEL and other
> >> distros are doing
> >>   and a description of the rust / crates.io test system known as
> >> crater that builds the
> >>   world for any significant rust change.
> >>
> >> Is there any objection to doing 2 and if we don't see any problems
> >> after some time,
> >>   then removing the older version?
> >> Sundeep,
> >> If no one object, please update kirkstone and see if librsvg or
> >> python-cryptography or
> >>   anything else encounters a problem.
> >
> > I'm afraid I don't like option 2. We don't do this for anything else so
> > we're now inventing some new policy. Either the upgrade is what we
> > decide is right or it isn't, I don't really like the idea of hedging
> > our bets and providing two versions, one of which nobody will use until
> > they're forced. It will also make security scans tricky as is the issue
> > dealt with or not?
> >
> > Just for context, going back in time OE used to be awash with many
> > version of recipes and I'm reluctant to go back there as it was
> > horrible. They were added for exactly this kind of reasoning, which at
> > first seemed like a good idea.
>
> Okay, make sense, option 1 it is!
>
> ../Randy
> >
> > Cheers,
> >
> > Richard
> >
> >
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176064): 
https://lists.openembedded.org/g/openembedded-core/message/176064
Mute This Topic: https://lists.openembedded.org/mt/96218038/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] rust: Upgrade 1.66.0 -> 1.66.1

On Tue, Jan 17, 2023 at 12:00 PM Alexander Kanavin
 wrote:
>
> Option 1 looks like a new policy too. If we can upgrade rust across
> many major versions in a stable release, then why not other items?

According to the stable release "rules" option 1 would require an
exception granted by the TSC.  Otherwise it is a no go.

So it seems to me that this is a classic case for using a mix-in layer.

Steve

> On Tue, 17 Jan 2023 at 22:57, Randy MacLeod  
> wrote:
> >
> > On 2023-01-17 16:54, Richard Purdie wrote:
> > > On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote:
> > >> On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org
> > >> wrote:
> > >>
> > >>>   Rust community said the security fixes are only for the current
> > >>> stable relases.
> > >>>
> > >>> https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older
> > >>> -releases/18152/3?u=sundeep-kokkonda
> > >>>   For old release we've to backport the patches ourselves.
> > >> The other alternatives are
> > >> 1. upgrade to 1.66.1 on older branches,
> > >> 2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older
> > >> version for those who are risk averse,
> > >> 3. add a mix-in layer (1) with the upgrade to 1.66.1.
> > >>   For langdale, we'd update from 1.63 and for kirkstone, we'd update
> > >> from 1.59
> > >> See the link above for a discussion about what Fedora/RHEL and other
> > >> distros are doing
> > >>   and a description of the rust / crates.io test system known as
> > >> crater that builds the
> > >>   world for any significant rust change.
> > >>
> > >> Is there any objection to doing 2 and if we don't see any problems
> > >> after some time,
> > >>   then removing the older version?
> > >> Sundeep,
> > >> If no one object, please update kirkstone and see if librsvg or
> > >> python-cryptography or
> > >>   anything else encounters a problem.
> > >
> > > I'm afraid I don't like option 2. We don't do this for anything else so
> > > we're now inventing some new policy. Either the upgrade is what we
> > > decide is right or it isn't, I don't really like the idea of hedging
> > > our bets and providing two versions, one of which nobody will use until
> > > they're forced. It will also make security scans tricky as is the issue
> > > dealt with or not?
> > >
> > > Just for context, going back in time OE used to be awash with many
> > > version of recipes and I'm reluctant to go back there as it was
> > > horrible. They were added for exactly this kind of reasoning, which at
> > > first seemed like a good idea.
> >
> > Okay, make sense, option 1 it is!
> >
> > ../Randy
> > >
> > > Cheers,
> > >
> > > Richard
> > >
> > >
> >
> > --
> > # Randy MacLeod
> > # Wind River Linux
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176065): 
https://lists.openembedded.org/g/openembedded-core/message/176065
Mute This Topic: https://lists.openembedded.org/mt/96218038/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/4] mdadm: Define alignof using _Alignof when using C11 or newer

Signed-off-by: Khem Raj 
---
 ...sing-_Alignof-when-using-C11-or-newe.patch | 52 +++
 meta/recipes-extended/mdadm/mdadm_4.2.bb  |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 
meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch

diff --git 
a/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
 
b/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
new file mode 100644
index 00..1c472886b3
--- /dev/null
+++ 
b/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
@@ -0,0 +1,52 @@
+From 82c893bb9e01f914a6bdef1bef943af746cfc3e1 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sun, 15 Jan 2023 12:42:18 -0800
+Subject: [PATCH] Define alignof using _Alignof when using C11 or newer
+
+WG14 N2350 made very clear that it is an UB having type definitions
+within "offsetof" [1]. This patch enhances the implementation of macro
+alignof_slot to use builtin "_Alignof" to avoid undefined behavior on
+when using std=c11 or newer
+
+clang 16+ has started to flag this [2]
+
+Fixes build when using -std >= gnu11 and using clang16+
+
+Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
+may support C11, exclude those compilers too
+
+[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
+[2] https://reviews.llvm.org/D133574
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj 
+---
+ sha1.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/sha1.c b/sha1.c
+index 89b32f4..1e4ad5d 100644
+--- a/sha1.c
 b/sha1.c
+@@ -229,7 +229,17 @@ sha1_process_bytes (const void *buffer, size_t len, 
struct sha1_ctx *ctx)
+   if (len >= 64)
+ {
+ #if !_STRING_ARCH_unaligned
+-# define alignof(type) offsetof (struct { char c; type x; }, x)
++/* GCC releases before GCC 4.9 had a bug in _Alignof.  See GCC bug 52023
++   .
++   clang versions < 8.0.0 have the same bug.  */
++# if (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112 \
++  || (defined __GNUC__ && __GNUC__ < 4 + (__GNUC_MINOR__ < 9) \
++   && !defined __clang__) \
++  || (defined __clang__ && __clang_major__ < 8))
++#  define alignof(type) offsetof (struct { char c; type x; }, x)
++# else
++#  define alignof(type) _Alignof(type)
++# endif
+ # define UNALIGNED_P(p) (((size_t) p) % alignof (sha1_uint32) != 0)
+   if (UNALIGNED_P (buffer))
+   while (len > 64)
+-- 
+2.39.0
+
diff --git a/meta/recipes-extended/mdadm/mdadm_4.2.bb 
b/meta/recipes-extended/mdadm/mdadm_4.2.bb
index 7298860241..1c4397509b 100644
--- a/meta/recipes-extended/mdadm/mdadm_4.2.bb
+++ b/meta/recipes-extended/mdadm/mdadm_4.2.bb
@@ -25,6 +25,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
file://0001-Fix-parsing-of-r-in-monitor-manager-mode.patch \
file://0001-Makefile-install-mdcheck.patch \

file://0001-restripe.c-Use-_FILE_OFFSET_BITS-to-enable-largefile.patch \
+   
file://0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
"
 
 SRC_URI[sha256sum] = 
"461c215670864bb74a4d1a3620684aa2b2f8296dffa06743f26dda5557acf01d"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176066): 
https://lists.openembedded.org/g/openembedded-core/message/176066
Mute This Topic: https://lists.openembedded.org/mt/96343396/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/4] python3-numpy: Define _ALIGN using _Alignof when using C11 or newer

Signed-off-by: Khem Raj 
---
 ...ing-_Alignof-when-using-C11-or-newer.patch | 77 +++
 .../python/python3-numpy_1.24.1.bb|  1 +
 2 files changed, 78 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch

diff --git 
a/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
 
b/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
new file mode 100644
index 00..97391e2c12
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
@@ -0,0 +1,77 @@
+From f9ac08a0fea543d68b2dba540093bd079e50be47 Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sun, 15 Jan 2023 15:49:09 -0800
+Subject: [PATCH] Define _ALIGN using _Alignof when using C11 or newer
+
+WG14 N2350 made very clear that it is an UB having type definitions
+within "offsetof" [1]. This patch enhances the implementation of macro
+_ALIGN to use builtin "_Alignof" to avoid undefined behavior on
+when using std=c11 or newer
+
+clang 16+ has started to flag this [2]
+
+Fixes build when using -std >= gnu11 and using clang16+
+
+Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
+may support C11, exclude those compilers too
+
+[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
+[2] https://reviews.llvm.org/D133574
+
+Upstream-Status: Submitted [https://github.com/numpy/numpy/pull/23016]
+Signed-off-by: Khem Raj 
+---
+ numpy/core/src/multiarray/arraytypes.c.src | 13 +++--
+ numpy/core/src/multiarray/common.h | 12 +++-
+ 2 files changed, 22 insertions(+), 3 deletions(-)
+
+diff --git a/numpy/core/src/multiarray/arraytypes.c.src 
b/numpy/core/src/multiarray/arraytypes.c.src
+index c03d09784..683917220 100644
+--- a/numpy/core/src/multiarray/arraytypes.c.src
 b/numpy/core/src/multiarray/arraytypes.c.src
+@@ -224,8 +224,17 @@ MyPyLong_AsUnsigned@Type@(PyObject *obj)
+  ** GETITEM AND SETITEM **
+  *
+  */
+-
+-#define _ALIGN(type) offsetof(struct {char c; type v;}, v)
++/* GCC releases before GCC 4.9 had a bug in _Alignof.  See GCC bug 52023
++   .
++   clang versions < 8.0.0 have the same bug.  */
++#if (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112 \
++ || (defined __GNUC__ && __GNUC__ < 4 + (__GNUC_MINOR__ < 9) \
++  && !defined __clang__) \
++ || (defined __clang__ && __clang_major__ < 8))
++# define _ALIGN(type) offsetof(struct {char c; type v;}, v)
++#else
++# define _ALIGN(type) _Alignof(type)
++#endif
+ /*
+  * Disable harmless compiler warning "4116: unnamed type definition in
+  * parentheses" which is caused by the _ALIGN macro.
+diff --git a/numpy/core/src/multiarray/common.h 
b/numpy/core/src/multiarray/common.h
+index 3de8c842d..d01074c45 100644
+--- a/numpy/core/src/multiarray/common.h
 b/numpy/core/src/multiarray/common.h
+@@ -178,7 +178,17 @@ check_and_adjust_axis(int *axis, int ndim)
+ }
+ 
+ /* used for some alignment checks */
+-#define _ALIGN(type) offsetof(struct {char c; type v;}, v)
++/* GCC releases before GCC 4.9 had a bug in _Alignof.  See GCC bug 52023
++   .
++   clang versions < 8.0.0 have the same bug.  */
++#if (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112 \
++ || (defined __GNUC__ && __GNUC__ < 4 + (__GNUC_MINOR__ < 9) \
++  && !defined __clang__) \
++ || (defined __clang__ && __clang_major__ < 8))
++# define _ALIGN(type) offsetof(struct {char c; type v;}, v)
++#else
++# define _ALIGN(type) _Alignof(type)
++#endif
+ #define _UINT_ALIGN(type) npy_uint_alignment(sizeof(type))
+ /*
+  * Disable harmless compiler warning "4116: unnamed type definition in
+-- 
+2.39.0
+
diff --git a/meta/recipes-devtools/python/python3-numpy_1.24.1.bb 
b/meta/recipes-devtools/python/python3-numpy_1.24.1.bb
index 83b8ac4232..adac08b3e1 100644
--- a/meta/recipes-devtools/python/python3-numpy_1.24.1.bb
+++ b/meta/recipes-devtools/python/python3-numpy_1.24.1.bb
@@ -10,6 +10,7 @@ SRCNAME = "numpy"
 SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/${SRCNAME}-${PV}.tar.gz \

file://0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch \
file://0001-numpy-core-Define-RISCV-32-support.patch \
+   
file://0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch \
file://run-ptest \
"
 SRC_URI[sha256sum] = 
"2386da9a471cc00a1f47845e27d916d5ec5346ae9696e01a8a34760858fe9dd2"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176067): 
https://lists.openembedded.org/g/openembedded-core/message/176067
Mute This Topic: https:/

[OE-core] [PATCH 3/4] vulkan-samples: Drop using u8string_view

Its deprecated in upstream fmt as well. Moreover it helps compile with
latest compiler

Signed-off-by: Khem Raj 
---
 .../0001-Deprecate-u8string_view.patch| 59 +++
 .../vulkan/vulkan-samples_git.bb  |  1 +
 2 files changed, 60 insertions(+)
 create mode 100644 
meta/recipes-graphics/vulkan/vulkan-samples/0001-Deprecate-u8string_view.patch

diff --git 
a/meta/recipes-graphics/vulkan/vulkan-samples/0001-Deprecate-u8string_view.patch
 
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-Deprecate-u8string_view.patch
new file mode 100644
index 00..c2304bdd48
--- /dev/null
+++ 
b/meta/recipes-graphics/vulkan/vulkan-samples/0001-Deprecate-u8string_view.patch
@@ -0,0 +1,59 @@
+From 93987b1ce7d6f91387202495aac61026070597df Mon Sep 17 00:00:00 2001
+From: Khem Raj 
+Date: Sun, 15 Jan 2023 21:37:52 -0800
+Subject: [PATCH] Deprecate u8string_view
+
+Use basic_string_view instead
+
+Upstream-Status: Backport 
[https://github.com/fmtlib/fmt/commit/dea7fde8b7d649923dd41b0766bdf076033c62a2]
+Signed-off-by: Khem Raj 
+---
+ include/spdlog/fmt/bundled/core.h   |  3 ++-
+ include/spdlog/fmt/bundled/format.h | 15 ++-
+ 2 files changed, 4 insertions(+), 14 deletions(-)
+
+diff --git a/include/spdlog/fmt/bundled/core.h 
b/include/spdlog/fmt/bundled/core.h
+index 50b79351..e8b029ef 100644
+--- a/include/spdlog/fmt/bundled/core.h
 b/include/spdlog/fmt/bundled/core.h
+@@ -1484,7 +1484,8 @@ FMT_API void vprint(wstring_view format_str, 
wformat_args args);
+ 
+ /**
+   \rst
+-  Prints formatted data to ``stdout``.
++  Formats ``args`` according to specifications in ``format_str`` and writes 
the
++  output to ``stdout``.
+ 
+   **Example**::
+ 
+diff --git a/include/spdlog/fmt/bundled/format.h 
b/include/spdlog/fmt/bundled/format.h
+index 1bb24a52..39426361 100644
+--- a/include/spdlog/fmt/bundled/format.h
 b/include/spdlog/fmt/bundled/format.h
+@@ -407,21 +407,10 @@ void basic_buffer::append(const U *begin, const U 
*end) {
+ enum char8_t: unsigned char {};
+ #endif
+ 
+-// A UTF-8 string view.
+-class u8string_view : public basic_string_view {
+- public:
+-  typedef char8_t char_type;
+-
+-  u8string_view(const char *s):
+-basic_string_view(reinterpret_cast(s)) {}
+-  u8string_view(const char *s, size_t count) FMT_NOEXCEPT:
+-basic_string_view(reinterpret_cast(s), count) {}
+-};
+-
+ #if FMT_USE_USER_DEFINED_LITERALS
+ inline namespace literals {
+-inline u8string_view operator"" _u(const char *s, std::size_t n) {
+-  return {s, n};
++inline basic_string_view operator"" _u(const char* s, std::size_t n) 
{
++  return {reinterpret_cast(s), n};
+ }
+ }
+ #endif
+-- 
+2.39.0
+
diff --git a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb 
b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
index 26300ecb1d..7f52cb66c9 100644
--- a/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
+++ b/meta/recipes-graphics/vulkan/vulkan-samples_git.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE;md5=48aa35cefb768436223a6e7f18dc2a2a"
 SRC_URI = 
"gitsm://github.com/KhronosGroup/Vulkan-Samples.git;branch=master;protocol=https;lfs=0
 \
file://debugfix.patch \

file://0001-Do-not-use-LFS64-functions-on-linux-musl.patch;patchdir=third_party/spdlog
 \
+   
file://0001-Deprecate-u8string_view.patch;patchdir=third_party/spdlog \
"
 
 UPSTREAM_CHECK_COMMITS = "1"
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176068): 
https://lists.openembedded.org/g/openembedded-core/message/176068
Mute This Topic: https://lists.openembedded.org/mt/96343399/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/4] musl-obstack: Update to 1.2.3

Switch to void-linux github handle, void-linux is the upstream anyway this 
brings

Signed-off-by: Khem Raj 
---
 meta/recipes-core/musl/musl-obstack.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-core/musl/musl-obstack.bb 
b/meta/recipes-core/musl/musl-obstack.bb
index 5c95ddbc94..4c71a141b2 100644
--- a/meta/recipes-core/musl/musl-obstack.bb
+++ b/meta/recipes-core/musl/musl-obstack.bb
@@ -8,9 +8,9 @@ LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=3d23e4eef8243efcaab6f0a438078932"
 SECTION = "libs"
 
-PV = "1.2"
-SRCREV = "466f773fe171da427e28be79b9cf48ccfddfb7e2"
-SRC_URI = "git://github.com/pullmoll/musl-obstack;branch=master;protocol=https"
+PV = "1.2.3"
+SRCREV = "f4385255be1615688c6a5f042277304d7ab288b1"
+SRC_URI = 
"git://github.com/void-linux/musl-obstack;branch=master;protocol=https"
 
 UPSTREAM_CHECK_COMMITS = "1"
 
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176069): 
https://lists.openembedded.org/g/openembedded-core/message/176069
Mute This Topic: https://lists.openembedded.org/mt/96343400/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] rust: Upgrade 1.66.0 -> 1.66.1

On 2023-01-17 17:37, Steve Sakoman wrote:

On Tue, Jan 17, 2023 at 12:00 PM Alexander Kanavin
wrote:

Option 1 looks like a new policy too. If we can upgrade rust across
many major versions in a stable release, then why not other items?

In oe-core we have a trivial exception for vim but of course it's an
application not a toolchain.

Similarly, in other layers, applications such as Chromium (and
Tensorflow?) only maintain one version and

users are expected to upgrade to get bug fixes.

The Rust developers / community seems to want their software to work in
a similar way.

They have a quite exhaustive test suite (Crater) to check for regressions.
I'll look for some actual test results from Crater and reply here when I
find them.
I not sure what to make of the "Rust Editions" and how they'd fit into
our distro support
but the clear mandate from upstream is that only the 'stable' release is
supported.

https://doc.rust-lang.org/edition-guide/editions/index.html

I think there's an argument to be made that until Rust releases 2.x, we
just update

to the latest version. If you haven't please read:

https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older-releases/18152/3?u=sundeep-kokkonda

Assuming that some day, Rust-2.x is released, then one would hope that
1.x would be maintained
for a few years on it's own branch but again the semantic versioning
rules would allow them to
release say 1.288, 1.289, ... and at that time, it would likely be more
clear that we should be following the

1.x releases for older branches and 2.x releases for newer branches.

According to the stable release "rules" option 1 would require an
exception granted by the TSC. Otherwise it is a no go.

So it seems to me that this is a classic case for using a mix-in layer.

Once I have enough data, I'll present it here and if it makes sense to ask
the TSC, we can do that.

Upstream is not backporting fixes for a CVE such as this or for less
notable bug fixes,

so we'd be giving up those improvements. I suppose we'd only backport
bug fixes should someone encounter the bug or it becomes equally notable.

So far, there haven't been many Rust/Cargo CVEs so maybe we're making
too big a deal out of this. I certainly don't miss the deluge of memory
management CVEs that

C/C++ applications suffer from!

Sundeep,

Please also try to backporting the fixes to say Cargo/Rust for kirkstone.
This CVE resulted in ~10 patches so it's hopefully one
of the more complicated back ports and will prove to be a good test case.

../Randy

Steve

On Tue, 17 Jan 2023 at 22:57, Randy MacLeod wrote:

On 2023-01-17 16:54, Richard Purdie wrote:

On Tue, 2023-01-17 at 15:29 -0500, Randy MacLeod wrote:

On 2023-01-16 10:20, Kokkonda, Sundeep via lists.openembedded.org
wrote:

Rust community said the security fixes are only for the current
stable relases.

https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older
-releases/18152/3?u=sundeep-kokkonda
For old release we've to backport the patches ourselves.

The other alternatives are
1. upgrade to 1.66.1 on older branches,
2. add 1.66.1, which will be the PREFERRED_VERSION but keep the older
version for those who are risk averse,
3. add a mix-in layer (1) with the upgrade to 1.66.1.
For langdale, we'd update from 1.63 and for kirkstone, we'd update
from 1.59
See the link above for a discussion about what Fedora/RHEL and other
distros are doing
and a description of the rust / crates.io test system known as
crater that builds the
world for any significant rust change.

Is there any objection to doing 2 and if we don't see any problems
after some time,
then removing the older version?
Sundeep,
If no one object, please update kirkstone and see if librsvg or
python-cryptography or
anything else encounters a problem.

I'm afraid I don't like option 2. We don't do this for anything else so
we're now inventing some new policy. Either the upgrade is what we
decide is right or it isn't, I don't really like the idea of hedging
our bets and providing two versions, one of which nobody will use until
they're forced. It will also make security scans tricky as is the issue
dealt with or not?

Just for context, going back in time OE used to be awash with many
version of recipes and I'm reluctant to go back there as it was
horrible. They were added for exactly this kind of reasoning, which at
first seemed like a good idea.

Okay, make sense, option 1 it is!

../Randy

Cheers,

Richard

--
# Randy MacLeod
# Wind River Linux

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

[OE-core] 4.1.2 Releasenote : The CVE in bind has already been fixed in the 4.1 release.

2023-01-17 Thread Takayasu Ito

I was checking the following RELEASENOTE contents, and the CVE for bind, 
which has already been addressed in Yocto 4.1, was shown again.

http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.2/RELEASENOTES

The commit for updating bind in this release is
https://git.yoctoproject.org/poky/commit/meta/recipes-connectivity/bind?h=langdale&id=90246ed04bdf7568c161e2f5698f954e0ac78191

The changelog is for 9.18.7 and was already fixed in the 4.1 release.


--
Takayasu Ito
Solution Department, Lineo Solutions, Inc.
https://www.lineo.co.jp/english/
Email: i...@lineo.co.jp
Yocto Project Ambassador

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176071): 
https://lists.openembedded.org/g/openembedded-core/message/176071
Mute This Topic: https://lists.openembedded.org/mt/96347453/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] [kirkstone][PATCH] bluez: CVE-2022-3637 A DoS exists in monitor/jlink.c

2023-01-17 Thread Hitendra Prajapati

Hi Team,

Gentle Reminder !

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176072): 
https://lists.openembedded.org/g/openembedded-core/message/176072
Mute This Topic: https://lists.openembedded.org/mt/94860718/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] 4.1.2 Releasenote : The CVE in bind has already been fixed in the 4.1 release.

2023-01-17 Thread Lee Chee Yang

Thanks for catching this, I overlooked the changelog version in the commit 
message.

> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Takayasu Ito
> Sent: Wednesday, January 18, 2023 11:53 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] 4.1.2 Releasenote : The CVE in bind has already been fixed
> in the 4.1 release.
> 
> I was checking the following RELEASENOTE contents, and the CVE for bind,
> which has already been addressed in Yocto 4.1, was shown again.
> http://downloads.yoctoproject.org/releases/yocto/yocto-
> 4.1.2/RELEASENOTES
> 
> The commit for updating bind in this release is
> https://git.yoctoproject.org/poky/commit/meta/recipes-
> connectivity/bind?h=langdale&id=90246ed04bdf7568c161e2f5698f954e0ac78
> 191
> 
> The changelog is for 9.18.7 and was already fixed in the 4.1 release.
> 
> 
> --
> Takayasu Ito
> Solution Department, Lineo Solutions, Inc.
> https://www.lineo.co.jp/english/
> Email: i...@lineo.co.jp
> Yocto Project Ambassador

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176073): 
https://lists.openembedded.org/g/openembedded-core/message/176073
Mute This Topic: https://lists.openembedded.org/mt/96347453/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/4] mdadm: Define alignof using _Alignof when using C11 or newer

Please submit the patch upstream first.

Alex

On Wed, 18 Jan 2023 at 00:18, Khem Raj  wrote:
>
> Signed-off-by: Khem Raj 
> ---
>  ...sing-_Alignof-when-using-C11-or-newe.patch | 52 +++
>  meta/recipes-extended/mdadm/mdadm_4.2.bb  |  1 +
>  2 files changed, 53 insertions(+)
>  create mode 100644 
> meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
>
> diff --git 
> a/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
>  
> b/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
> new file mode 100644
> index 00..1c472886b3
> --- /dev/null
> +++ 
> b/meta/recipes-extended/mdadm/files/0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch
> @@ -0,0 +1,52 @@
> +From 82c893bb9e01f914a6bdef1bef943af746cfc3e1 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sun, 15 Jan 2023 12:42:18 -0800
> +Subject: [PATCH] Define alignof using _Alignof when using C11 or newer
> +
> +WG14 N2350 made very clear that it is an UB having type definitions
> +within "offsetof" [1]. This patch enhances the implementation of macro
> +alignof_slot to use builtin "_Alignof" to avoid undefined behavior on
> +when using std=c11 or newer
> +
> +clang 16+ has started to flag this [2]
> +
> +Fixes build when using -std >= gnu11 and using clang16+
> +
> +Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
> +may support C11, exclude those compilers too
> +
> +[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
> +[2] https://reviews.llvm.org/D133574
> +
> +Upstream-Status: Pending
> +Signed-off-by: Khem Raj 
> +---
> + sha1.c | 12 +++-
> + 1 file changed, 11 insertions(+), 1 deletion(-)
> +
> +diff --git a/sha1.c b/sha1.c
> +index 89b32f4..1e4ad5d 100644
> +--- a/sha1.c
>  b/sha1.c
> +@@ -229,7 +229,17 @@ sha1_process_bytes (const void *buffer, size_t len, 
> struct sha1_ctx *ctx)
> +   if (len >= 64)
> + {
> + #if !_STRING_ARCH_unaligned
> +-# define alignof(type) offsetof (struct { char c; type x; }, x)
> ++/* GCC releases before GCC 4.9 had a bug in _Alignof.  See GCC bug 52023
> ++   .
> ++   clang versions < 8.0.0 have the same bug.  */
> ++# if (!defined __STDC_VERSION__ || __STDC_VERSION__ < 201112 \
> ++  || (defined __GNUC__ && __GNUC__ < 4 + (__GNUC_MINOR__ < 9) \
> ++   && !defined __clang__) \
> ++  || (defined __clang__ && __clang_major__ < 8))
> ++#  define alignof(type) offsetof (struct { char c; type x; }, x)
> ++# else
> ++#  define alignof(type) _Alignof(type)
> ++# endif
> + # define UNALIGNED_P(p) (((size_t) p) % alignof (sha1_uint32) != 0)
> +   if (UNALIGNED_P (buffer))
> +   while (len > 64)
> +--
> +2.39.0
> +
> diff --git a/meta/recipes-extended/mdadm/mdadm_4.2.bb 
> b/meta/recipes-extended/mdadm/mdadm_4.2.bb
> index 7298860241..1c4397509b 100644
> --- a/meta/recipes-extended/mdadm/mdadm_4.2.bb
> +++ b/meta/recipes-extended/mdadm/mdadm_4.2.bb
> @@ -25,6 +25,7 @@ SRC_URI = 
> "${KERNELORG_MIRROR}/linux/utils/raid/mdadm/${BPN}-${PV}.tar.xz \
> file://0001-Fix-parsing-of-r-in-monitor-manager-mode.patch \
> file://0001-Makefile-install-mdcheck.patch \
> 
> file://0001-restripe.c-Use-_FILE_OFFSET_BITS-to-enable-largefile.patch \
> +   
> file://0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
> "
>
>  SRC_URI[sha256sum] = 
> "461c215670864bb74a4d1a3620684aa2b2f8296dffa06743f26dda5557acf01d"
> --
> 2.39.0
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176074): 
https://lists.openembedded.org/g/openembedded-core/message/176074
Mute This Topic: https://lists.openembedded.org/mt/96343396/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] rust: Upgrade 1.66.0 -> 1.66.1