date:20231017

On Tue, 2023-10-17 at 16:00 +0200, Lukas Funke wrote:
> Hi Richard,
> 
> On 17.10.2023 15:53, Richard Purdie wrote:
> > On Tue, 2023-10-17 at 15:26 +0200, Lukas Funke wrote:
> > > From: Lukas Funke 
> > > 
> > > Signed-off-by: Lukas Funke 
> > > ---
> > >   scripts/lib/recipetool/create_go.py | 730 
> > >   1 file changed, 730 insertions(+)
> > >   create mode 100644 scripts/lib/recipetool/create_go.py
> > > 
> > > diff --git a/scripts/lib/recipetool/create_go.py 
> > > b/scripts/lib/recipetool/create_go.py
> > > new file mode 100644
> > > index 00..e0254f111b
> > > --- /dev/null
> > > +++ b/scripts/lib/recipetool/create_go.py
> > > @@ -0,0 +1,730 @@
> > > +# Recipe creation tool - go support plugin
> > > +#
> > > +# Copyright (C) 2023 Weidmueller GmbH & Co KG
> > > +# Author: Lukas Funke 
> > > +#
> > > +# SPDX-License-Identifier: GPL-2.0-only
> > > +#
> > > +# Copyright (c) 2009 The Go Authors. All rights reserved.
> > > +#
> > > +#  SPDX-License-Identifier: BSD-3-Clause
> > > +#
> > 
> > Can you clarify what this license information means please? Two
> > different license identifier lines seems rather confusing and
> > problematic.
> > 
> > I've not looked into the rest of the patches yet, this just caught my
> > eye.
> 
> Some of the ideas/code was ported from the original golang code to 
> python here. Thus, I had to copy the license information as well (I 
> guess?). If this is wrong or could be written in another way please 
> provide an example how it's done.

If the code is close enough to the original to be based off it, the new
code would be under the same license? We can't tell which is the old
code and which is the new code so the license header is rather
problematic and confusing so this does need to be fixed.

Perhaps this means it is all under BSD-3-Clause? That sounds easier but
we don't don't have a top level LICENSE.BSD-3-Clause to match this and
I'd prefer to keep the code under MIT/GPL-2.0 and not add another
license to the mix if we can help it.

Or is the code sufficiently different that you can say you took
inspiration from that code but the result is under GPL-2.0 as it was
different enough you can license it as you wish, the original license
becoming not relevant?

Either way the header needs some explanation of where this other
copyright comes from too. I would probably just credit it as a source
of inspiration but I don't know how similar it is/isn't.

Cheers,

Richard

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

Re: Kernel 6.5 ttyS1 hang with qemu (was Re: [OE-core] Summary of the remaining 6.5 kernel serial issue (and 6.5 summary)

On Tue, 2023-10-17 at 09:56 +0300, Tony Lindgren wrote:
> * Richard Purdie  [231016 08:10]:
> > The port sometimes doesn't come up properly at boot.
> > 
> > To be clear, the "\n\n" from the qemu side into the port doesn't seem
> > to help. The "echo helloB > /dev/ttyS1" inside the image does seem to
> > wake it up. 
> 
> So if I understand correctly, this issue still happens with kernel patched
> with commit 81a61051e0ce ("serial: core: Fix checks for tx runtime PM
> state"), and the issue now only happens sometimes.

The issue has always been intermittent and it appeared to happen less
frequently with 81a61051e0ce added but it was hard to know if I was
imagining that.

> I wonder if the following additional change might help?

I've added it into testing and have not reproduced the failure with it
applied yet, locally or on our autobuilder. We need to sort some
release pieces which have been delayed by these issues and we're going
with a workaround for that. Once that is built I can get back to
testing this change more extensively, see if we can still provoke the
issue or not. It may take a day or two of testing before we know with
any certainty if the issue is resolved or not.

Cheers,

Richard

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

On Tue, 2023-10-17 at 17:25 +0200, Marta Rybczynska wrote:
> Add a SECURITY.md filr with hints for security researchers and other
> parties who might report potential security vulnerabilities.
> 
> Signed-off-by: Marta Rybczynska 
> ---
>  SECURITY.md | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 SECURITY.md
> 
> diff --git a/SECURITY.md b/SECURITY.md
> new file mode 100644
> index 00..900da76e59
> --- /dev/null
> +++ b/SECURITY.md
> @@ -0,0 +1,17 @@
> +How to Report a Vulnerability?
> +==
> +
> +Please send a message to security AT yoctoproject DOT org, including as many 
> details
> +as possible: the layer or software module affected, the recipe and its 
> version,
> +and any example code, if available.

Rather than send everyone to the security address, can we suggest
bugzilla as the first port of call for anything public knowledge and
less urgent and to only to use the security address for non-public or
urgent issues?

We do have the ability to mark bugs as security and private and then
triage unlocks them too.

Cheers,

Richard

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

[OE-core][dunfell 10/10] systemd: Backport systemd-resolved: use hostname for certificate validation in DoT

From: Marek Vasut 

Widely accepted certificates for IP addresses are expensive and only
affordable for larger organizations. Therefore if the user provides
the hostname in the DNS= option, we should use it instead of the IP
address.

This fixes https://nvd.nist.gov/vuln/detail/CVE-2018-21029 per
suggestion https://github.com/systemd/systemd-stable/issues/72 .

CVE: CVE-2018-21029
Signed-off-by: Marek Vasut 
Signed-off-by: Steve Sakoman 
---
 .../systemd/systemd/CVE-2018-21029.patch  | 120 ++
 meta/recipes-core/systemd/systemd_244.5.bb|   1 +
 2 files changed, 121 insertions(+)
 create mode 100644 meta/recipes-core/systemd/systemd/CVE-2018-21029.patch

diff --git a/meta/recipes-core/systemd/systemd/CVE-2018-21029.patch 
b/meta/recipes-core/systemd/systemd/CVE-2018-21029.patch
new file mode 100644
index 00..8d3801a248
--- /dev/null
+++ b/meta/recipes-core/systemd/systemd/CVE-2018-21029.patch
@@ -0,0 +1,120 @@
+From 3f9d9289ee8730a81a0464539f4e1ba2d23d0ce9 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= 
+Date: Tue, 3 Mar 2020 23:31:25 +
+Subject: [PATCH] systemd-resolved: use hostname for certificate validation in
+ DoT
+
+Widely accepted certificates for IP addresses are expensive and only
+affordable for larger organizations. Therefore if the user provides
+the hostname in the DNS= option, we should use it instead of the IP
+address.
+
+(cherry picked from commit eec394f10bbfcc3d2fc8504ad8ff5be44231abd5)
+
+CVE: CVE-2018-21029
+Upstream-Status: Backport [ff26d281aec0877b43269f18c6282cd79a7f5529]
+Signed-off-by: Marek Vasut 
+---
+ man/resolved.conf.xml | 16 +++-
+ src/resolve/resolved-dnstls-gnutls.c  | 20 
+ src/resolve/resolved-dnstls-openssl.c | 15 +++
+ 3 files changed, 34 insertions(+), 17 deletions(-)
+
+diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
+index 818000145b..37161ebcbc 100644
+--- a/man/resolved.conf.xml
 b/man/resolved.conf.xml
+@@ -193,11 +193,17 @@
+   
+ DNSOverTLS=
+ 
+-Takes a boolean argument or opportunistic.
+-If true all connections to the server will be encrypted. Note that
+-this mode requires a DNS server that supports DNS-over-TLS and has
+-a valid certificate for it's IP. If the DNS server does not support
+-DNS-over-TLS all DNS requests will fail. When set to 
opportunistic
++Takes a boolean argument or opportunistic. If
++true all connections to the server will be encrypted. Note that this
++mode requires a DNS server that supports DNS-over-TLS and has a valid
++certificate. If the hostname was specified in DNS=
++by using the format format address#server_name it
++is used to validate its certificate and also to enable Server Name
++Indication (SNI) when opening a TLS connection. Otherwise
++the certificate is checked against the server's IP.
++If the DNS server does not support DNS-over-TLS all DNS requests will 
fail.
++
++When set to opportunistic
+ DNS request are attempted to send encrypted with DNS-over-TLS.
+ If the DNS server does not support TLS, DNS-over-TLS is disabled.
+ Note that this mode makes DNS-over-TLS vulnerable to "downgrade"
+diff --git a/src/resolve/resolved-dnstls-gnutls.c 
b/src/resolve/resolved-dnstls-gnutls.c
+index ed0a31e8bf..c7215723a7 100644
+--- a/src/resolve/resolved-dnstls-gnutls.c
 b/src/resolve/resolved-dnstls-gnutls.c
+@@ -56,15 +56,19 @@ int dnstls_stream_connect_tls(DnsStream *stream, DnsServer 
*server) {
+ }
+ 
+ if (server->manager->dns_over_tls_mode == DNS_OVER_TLS_YES) {
+-stream->dnstls_data.validation.type = GNUTLS_DT_IP_ADDRESS;
+-if (server->family == AF_INET) {
+-stream->dnstls_data.validation.data = (unsigned 
char*) >address.in.s_addr;
+-stream->dnstls_data.validation.size = 4;
+-} else {
+-stream->dnstls_data.validation.data = 
server->address.in6.s6_addr;
+-stream->dnstls_data.validation.size = 16;
++if (server->server_name)
++gnutls_session_set_verify_cert(gs, 
server->server_name, 0);
++else {
++stream->dnstls_data.validation.type = 
GNUTLS_DT_IP_ADDRESS;
++if (server->family == AF_INET) {
++stream->dnstls_data.validation.data = 
(unsigned char*) >address.in.s_addr;
++stream->dnstls_data.validation.size = 4;
++} else {
++stream->dnstls_data.validation.data = 
server->address.in6.s6_addr;
++stream->dnstls_data.validation.size = 16;
++}
++

[OE-core][dunfell 09/10] kernel.bbclass: Add force flag to rm calls

From: Ryan Eatmon 

The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it.  Simple fix is to add the
-f (force) flag to the call.

(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)

Signed-off-by: Ryan Eatmon 
Signed-off-by: Richard Purdie 
Signed-off-by: Alexander Sverdlin 
Signed-off-by: Steve Sakoman 

Backported from kirkstone commit 7e177848f97e.
Signed-off-by: Paul Barker 
Signed-off-by: Steve Sakoman 
---
 meta/classes/kernel.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index ba5b6cf384..ca7530095e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -405,8 +405,8 @@ kernel_do_install() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
if (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
oe_runmake DEPMOD=echo 
MODLIB=${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION} 
INSTALL_FW_PATH=${D}${nonarch_base_libdir}/firmware modules_install
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
-   rm "${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/build"
+   rm -f 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source"
# If the kernel/ directory is empty remove it to prevent QA 
issues
rmdir --ignore-fail-on-non-empty 
"${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel"
else
-- 
2.34.1


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

[OE-core][dunfell 08/10] libxpm: upgrade to 3.5.17

From: Siddharth Doshi 

- This upgrade includes multiple security fixes.
CVE-2022-4883
CVE-2022-44617
CVE-2022-46285
CVE-2022-44617
CVE-2023-43788
CVE-2023-43789

- Removed CVE-2022-46285 as it is already fixed by this upgrade.

- License-update: additional copyright holders
f0857c0 man pages: Correct Copyright/License notices
Due to this commit LIC_FILES_CHKSUM is changed

- Disable reading compressed files as that requires compress/uncompress 
executables.
Following the approach in oe-core/master:
7de4084634 libxpm: upgrade 3.5.14 -> 3.5.15

- Add XORG_EXT to specify tar.xz as upstream has switched from bz2 to xz 
compression.

Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 .../xorg-lib/libxpm/CVE-2022-46285.patch  | 40 ---
 .../{libxpm_3.5.13.bb => libxpm_3.5.17.bb}|  9 ++---
 2 files changed, 4 insertions(+), 45 deletions(-)
 delete mode 100644 meta/recipes-graphics/xorg-lib/libxpm/CVE-2022-46285.patch
 rename meta/recipes-graphics/xorg-lib/{libxpm_3.5.13.bb => libxpm_3.5.17.bb} 
(68%)

diff --git a/meta/recipes-graphics/xorg-lib/libxpm/CVE-2022-46285.patch 
b/meta/recipes-graphics/xorg-lib/libxpm/CVE-2022-46285.patch
deleted file mode 100644
index e8b654dfb2..00
--- a/meta/recipes-graphics/xorg-lib/libxpm/CVE-2022-46285.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-CVE: CVE-2022-46285
-Upstream-Status: Backport 
[https://gitlab.freedesktop.org/xorg/lib/libxpm/-/commit/a3a7c6dcc3b629d7650148 
]
-Signed-off-by: Lee Chee Yang 
-
-From a3a7c6dcc3b629d765014816c566c63165c63ca8 Mon Sep 17 00:00:00 2001
-From: Alan Coopersmith 
-Date: Sat, 17 Dec 2022 12:23:45 -0800
-Subject: [PATCH] Fix CVE-2022-46285: Infinite loop on unclosed comments
-
-When reading XPM images from a file with libXpm 3.5.14 or older, if a
-comment in the file is not closed (i.e. a C-style comment starts with
-"/*" and is missing the closing "*/"), the ParseComment() function will
-loop forever calling getc() to try to read the rest of the comment,
-failing to notice that it has returned EOF, which may cause a denial of
-service to the calling program.
-
-Reported-by: Marco Ivaldi 
-Signed-off-by: Alan Coopersmith 

- src/data.c | 4 
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/data.c b/src/data.c
-index 898889c..bfad4ff 100644
 a/src/data.c
-+++ b/src/data.c
-@@ -174,6 +174,10 @@ ParseComment(xpmData *data)
-   notend = 0;
-   Ungetc(data, *s, file);
-   }
-+  else if (c == EOF) {
-+  /* hit end of file before the end of the comment */
-+  return XpmFileInvalid;
-+  }
-   }
-   return 0;
- }
--- 
-GitLab
-
diff --git a/meta/recipes-graphics/xorg-lib/libxpm_3.5.13.bb 
b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
similarity index 68%
rename from meta/recipes-graphics/xorg-lib/libxpm_3.5.13.bb
rename to meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
index 8937e61cb5..4694f911be 100644
--- a/meta/recipes-graphics/xorg-lib/libxpm_3.5.13.bb
+++ b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
@@ -11,19 +11,18 @@ an extension of the monochrome XBM bitmap specificied in 
the X \
 protocol."
 
 LICENSE = "MIT"
-LIC_FILES_CHKSUM = "file://COPYING;md5=51f4270b012ecd4ab1a164f5f4ed6cf7"
+LIC_FILES_CHKSUM = "file://COPYING;md5=903942ebc9d807dfb68540f40bae5aff"
 DEPENDS += "libxext libsm libxt gettext-native"
 PE = "1"
 
 XORG_PN = "libXpm"
+XORG_EXT = "tar.xz"
+EXTRA_OECONF += "--disable-open-zfile"
 
 PACKAGES =+ "sxpm cxpm"
 FILES_cxpm = "${bindir}/cxpm"
 FILES_sxpm = "${bindir}/sxpm"
 
-SRC_URI += " file://CVE-2022-46285.patch"
-
-SRC_URI[md5sum] = "6f0ecf8d103d528cfc803aa475137afa"
-SRC_URI[sha256sum] = 
"9cd1da57588b6cb71450eff2273ef6b657537a9ac4d02d0014228845b935ac25"
+SRC_URI[sha256sum] = 
"64b31f81019e7d388c822b0b28af8d51c4622b83f1f0cb6fa3fc95e271226e43"
 
 BBCLASSEXTEND = "native"
-- 
2.34.1


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

[OE-core][dunfell 07/10] xorg-lib-common: Add variable to set tarball type

From: Siddharth Doshi 

Upstream has switched some new releases from bz2 to xz compression. Add
an XORG_EXT variable so recipes can set the file name extension needed
for the compression type.

Following the approach in oe-core/master: 
6a8068e036b4b2a40b38896275b936916b4db76e
xorg-lib-common: Add variable to set tarball type use a variable for the 
tarball suffix/compression format.

Signed-off-by: Robert Joslyn 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-graphics/xorg-lib/xorg-lib-common.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc 
b/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
index a566eaa45e..1e8525d874 100644
--- a/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
+++ b/meta/recipes-graphics/xorg-lib/xorg-lib-common.inc
@@ -6,8 +6,9 @@ LICENSE = "MIT-X"
 DEPENDS = "util-macros"
 
 XORG_PN = "${BPN}"
+XORG_EXT ?= "tar.bz2"
 
-SRC_URI = "${XORG_MIRROR}/individual/lib/${XORG_PN}-${PV}.tar.bz2"
+SRC_URI = "${XORG_MIRROR}/individual/lib/${XORG_PN}-${PV}.${XORG_EXT}"
 
 S = "${WORKDIR}/${XORG_PN}-${PV}"
 
-- 
2.34.1


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

[OE-core][dunfell 06/10] vim: Upgrade 9.0.1894 -> 9.0.2009

From: Siddharth Doshi 

This includes CVE fix for CVE-2023-5441.

Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 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 73e639d7b1..51247cbe0a 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -19,8 +19,8 @@ SRC_URI = 
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://no-path-adjust.patch \
"
 
-PV .= ".1894"
-SRCREV = "e5f7cd0a60d0eeab84f7aeb35c13d3af7e50072e"
+PV .= ".2009"
+SRCREV = "54844857fd6933fa4f6678e47610c4b9c9f7a091"
 
 # 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 (#189357): 
https://lists.openembedded.org/g/openembedded-core/message/189357
Mute This Topic: https://lists.openembedded.org/mt/102024335/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 04/10] glib-2.0: Fix multiple vulnerabilities

From: Siddharth Doshi 

CVE's Fixed:
CVE-2023-29499: glib: GVariant offset table entry size is not checked in 
is_normal()
CVE-2023-32611: glib: g_variant_byteswap() can take a long time with some 
non-normal inputs
CVE-2023-32636: glib: Timeout in fuzz_variant_text
CVE-2023-32643: glib: Heap-buffer-overflow in g_variant_serialised_get_child
CVE-2023-32665: glib: GVariant deserialisation does not match spec for 
non-normal data

Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 .../glib-2.0/glib-2.0/CVE-2023-29499.patch| 290 
 .../glib-2.0/CVE-2023-32611-0001.patch|  89 
 .../glib-2.0/CVE-2023-32611-0002.patch| 255 +++
 .../glib-2.0/glib-2.0/CVE-2023-32636.patch|  49 ++
 .../glib-2.0/glib-2.0/CVE-2023-32643.patch| 154 +++
 .../glib-2.0/CVE-2023-32665-0001.patch| 103 +
 .../glib-2.0/CVE-2023-32665-0002.patch| 210 +
 .../glib-2.0/CVE-2023-32665-0003.patch| 417 ++
 .../glib-2.0/CVE-2023-32665-0004.patch| 113 +
 .../glib-2.0/CVE-2023-32665-0005.patch|  80 
 .../glib-2.0/CVE-2023-32665-0006.patch| 396 +
 .../glib-2.0/CVE-2023-32665-0007.patch|  49 ++
 .../glib-2.0/CVE-2023-32665-0008.patch| 394 +
 .../glib-2.0/CVE-2023-32665-0009.patch|  97 
 meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb |  14 +
 15 files changed, 2710 insertions(+)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-29499.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32611-0001.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32611-0002.patch
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32636.patch
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32643.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0001.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0002.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0003.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0004.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0005.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0006.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0007.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0008.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0009.patch

diff --git a/meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-29499.patch 
b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-29499.patch
new file mode 100644
index 00..ce90586290
--- /dev/null
+++ b/meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-29499.patch
@@ -0,0 +1,290 @@
+From 5f4485c4ff57fdefb1661531788def7ca5a47328 Mon Sep 17 00:00:00 2001
+From: Philip Withnall 
+Date: Thu, 17 Aug 2023 04:19:44 +
+Subject: [PATCH] gvariant-serialiser: Check offset table entry size is minimal
+
+The entries in an offset table (which is used for variable sized arrays
+and tuples containing variable sized members) are sized so that they can
+address every byte in the overall variant.
+
+The specification requires that for a variant to be in normal form, its
+offset table entries must be the minimum width such that they can
+address every byte in the variant.
+
+That minimality requirement was not checked in
+`g_variant_is_normal_form()`, leading to two different byte arrays being
+interpreted as the normal form of a given variant tree. That kind of
+confusion could potentially be exploited, and is certainly a bug.
+
+Fix it by adding the necessary checks on offset table entry width, and
+unit tests.
+
+Spotted by William Manley.
+
+Signed-off-by: Philip Withnall 
+
+Fixes: #2794
+
+CVE: CVE-2023-29499
+Upstream-Status: Backport from 
[https://gitlab.gnome.org/GNOME/glib/-/commit/5f4485c4ff57fdefb1661531788def7ca5a47328]
+Signed-off-by: Siddharth Doshi 
+---
+ glib/gvariant-serialiser.c |  19 +++-
+ glib/tests/gvariant.c  | 176 +
+ 2 files changed, 194 insertions(+), 1 deletion(-)
+
+diff --git a/glib/gvariant-serialiser.c b/glib/gvariant-serialiser.c
+index 0bf7243..5aa2cbc 100644
+--- a/glib/gvariant-serialiser.c
 b/glib/gvariant-serialiser.c
+@@ -694,6 +694,10 @@ gvs_variable_sized_array_get_frame_offsets 
(GVariantSerialised value)
+   out.data_size = last_end;
+   out.array = value.data + last_end;
+   out.length = offsets_array_size / out.offset_size;
++
++  if (out.length > 0 && gvs_calculate_total_size (last_end, out.length) != 
value.size)
++return out;  /* offset size not minimal */
++
+   out.is_normal = TRUE;
+ 
+   return out;
+@@ -1201,6 +1205,7 @@ gvs_tuple_is_normal (GVariantSerialised value)
+   gsize length;
+   gsize offset;
+   gsize i;
++  gsize offset_table_size;
+ 
+   /* as per the

[OE-core][dunfell 05/10] libwebp: Update CVE ID CVE-2023-4863

From: Pawan 

Notice that it references different CVE id:
https://nvd.nist.gov/vuln/detail/CVE-2023-5129
which was marked as a rejected duplicate of:
https://nvd.nist.gov/vuln/detail/CVE-2023-4863
but it's the same issue. Hence update CVE ID CVE-2023-4863
to CVE-2023-5129.patch.

Signed-off-by: Pawan 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-multimedia/webp/files/CVE-2023-5129.patch | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch 
b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
index eb77e193c2..068c56 100644
--- a/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
+++ b/meta/recipes-multimedia/webp/files/CVE-2023-5129.patch
@@ -12,9 +12,16 @@ codes) streams are still decodable.
 Bug: chromium:1479274
 Change-Id: I31c36dbf3aa78d35ecf38706b50464fd3d375741
 
-CVE: CVE-2023-5129
+Notice that it references different CVE id:
+https://nvd.nist.gov/vuln/detail/CVE-2023-5129
+which was marked as a rejected duplicate of:
+https://nvd.nist.gov/vuln/detail/CVE-2023-4863
+but it's the same issue. Hence update CVE ID CVE-2023-4863
+
+CVE: CVE-2023-5129 CVE-2023-4863
 Upstream-Status: Backport 
[https://github.com/webmproject/libwebp/commit/2af26267cdfcb63a88e5c74a85927a12d6ca1d76]
 Signed-off-by: Colin McAllister 
+Signed-off-by: Pawan Badganchi 
 ---
  src/dec/vp8l_dec.c| 46 ++-
  src/dec/vp8li_dec.h   |  2 +-
-- 
2.34.1


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

[OE-core][dunfell 03/10] curl: Backport fix for CVE-2023-38546

From: Mike Crowe 

Take patch from Debian 7.64.0-4+deb10u7.

Signed-off-by: Mike Crowe 
CVE: CVE-2023-38546
Signed-off-by: Steve Sakoman 
---
 .../curl/curl/CVE-2023-38546.patch| 132 ++
 meta/recipes-support/curl/curl_7.69.1.bb  |   1 +
 2 files changed, 133 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-38546.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2023-38546.patch 
b/meta/recipes-support/curl/curl/CVE-2023-38546.patch
new file mode 100644
index 00..30ef2fd038
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-38546.patch
@@ -0,0 +1,132 @@
+From 7b67721f12cbe6ed1a41e7332f3b5a7186a5e23f Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Thu, 14 Sep 2023 23:28:32 +0200
+Subject: [PATCH] cookie: remove unnecessary struct fields
+To: libcurl development 
+
+Plus: reduce the hash table size from 256 to 63. It seems unlikely to
+make much of a speed difference for most use cases but saves 1.5KB of
+data per instance.
+
+Closes #11862
+
+This patch taken from Debian's 7.64.0-4+deb10u7 package which applied with
+only a little fuzz.
+
+CVE: CVE-2023-38546
+Upstream-Status: Backport [61275672b46d9abb32857404]
+Signed-off-by: Mike Crowe 
+---
+ lib/cookie.c | 13 +
+ lib/cookie.h |  7 ++-
+ lib/easy.c   |  4 +---
+ 3 files changed, 4 insertions(+), 20 deletions(-)
+
+diff --git a/lib/cookie.c b/lib/cookie.c
+index 68054e1c4..a378f28e1 100644
+--- a/lib/cookie.c
 b/lib/cookie.c
+@@ -114,7 +114,6 @@ static void freecookie(struct Cookie *co)
+   free(co->name);
+   free(co->value);
+   free(co->maxage);
+-  free(co->version);
+   free(co);
+ }
+ 
+@@ -641,11 +640,7 @@ Curl_cookie_add(struct Curl_easy *data,
+   }
+ }
+ else if(strcasecompare("version", name)) {
+-  strstore(>version, whatptr);
+-  if(!co->version) {
+-badcookie = TRUE;
+-break;
+-  }
++  /* just ignore */
+ }
+ else if(strcasecompare("max-age", name)) {
+   /* Defined in RFC2109:
+@@ -1042,7 +1037,6 @@ Curl_cookie_add(struct Curl_easy *data,
+ free(clist->path);
+ free(clist->spath);
+ free(clist->expirestr);
+-free(clist->version);
+ free(clist->maxage);
+ 
+ *clist = *co;  /* then store all the new data */
+@@ -,9 +1105,6 @@ struct CookieInfo *Curl_cookie_init(struct Curl_easy 
*data,
+ c = calloc(1, sizeof(struct CookieInfo));
+ if(!c)
+   return NULL; /* failed to get memory */
+-c->filename = strdup(file?file:"none"); /* copy the name just in case */
+-if(!c->filename)
+-  goto fail; /* failed to get memory */
+   }
+   else {
+ /* we got an already existing one, use that */
+@@ -1241,7 +1232,6 @@ static struct Cookie *dup_cookie(struct Cookie *src)
+ CLONE(name);
+ CLONE(value);
+ CLONE(maxage);
+-CLONE(version);
+ d->expires = src->expires;
+ d->tailmatch = src->tailmatch;
+ d->secure = src->secure;
+@@ -1457,7 +1447,6 @@ void Curl_cookie_cleanup(struct CookieInfo *c)
+ {
+   if(c) {
+ unsigned int i;
+-free(c->filename);
+ for(i = 0; i < COOKIE_HASH_SIZE; i++)
+   Curl_cookie_freelist(c->cookies[i]);
+ free(c); /* free the base struct as well */
+diff --git a/lib/cookie.h b/lib/cookie.h
+index b3865e601..2e667cda0 100644
+--- a/lib/cookie.h
 b/lib/cookie.h
+@@ -36,8 +36,6 @@ struct Cookie {
+   char *expirestr;   /* the plain text version */
+   bool tailmatch;/* whether we do tail-matching of the domain name */
+ 
+-  /* RFC 2109 keywords. Version=1 means 2109-compliant cookie sending */
+-  char *version; /* Version =  */
+   char *maxage;  /* Max-Age =  */
+ 
+   bool secure;   /* whether the 'secure' keyword was used */
+@@ -54,15 +52,14 @@ struct Cookie {
+ #define COOKIE_PREFIX__SECURE (1<<0)
+ #define COOKIE_PREFIX__HOST (1<<1)
+ 
+-#define COOKIE_HASH_SIZE 256
++#define COOKIE_HASH_SIZE 63
+ 
+ struct CookieInfo {
+   /* linked list of cookies we know of */
+   struct Cookie *cookies[COOKIE_HASH_SIZE];
+ 
+-  char *filename;  /* file we read from/write to */
+   bool running;/* state info, for cookie adding information */
+-  long numcookies; /* number of cookies in the "jar" */
++  int numcookies;  /* number of cookies in the "jar" */
+   bool newsession; /* new session, discard session cookies on load */
+   int lastct;  /* last creation-time used in the jar */
+ };
+diff --git a/lib/easy.c b/lib/easy.c
+index b648e80c1..cdca0fb03 100644
+--- a/lib/easy.c
 b/lib/easy.c
+@@ -840,9 +840,7 @@ struct Curl_easy *curl_easy_duphandle(struct Curl_easy 
*data)
+   if(data->cookies) {
+ /* If cookies are enabled in the parent handle, we enable them
+in the clone as well! */
+-outcurl->cookies = Curl_cookie_init(data,
+-data->cookies->filename,
+-outcurl->cookies,
++

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

Please review this set of changes for dunfell and have comments back by
end of day Thursday, October 19

Passed a-full on autobuilder:

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

with the exception of a reproducibility issue for the vim-common package
where we have:

"Content-Type:·text/plain;·charset=CP1251\n"

in the A build and:

"Content-Type:·text/plain;·charset=cp1251\n"

in the B build.

Dunfell autobuilder builds are currently using an older buildtools tarball
which is missing:

https://git.yoctoproject.org/poky/commit/?id=a2f1791f8d0118f44cf752341c4793d656a54a94

I'm sending a patch to the list to update dunfell to the latest buildtools 
tarball

The following changes since commit 0e167ef0eb7ac62ddb991ce80c27882863d8ee7c:

  cpio: Replace fix wrong CRC with ASCII CRC for large files with upstream 
backport (2023-10-09 07:30:51 -1000)

are available in the Git repository at:

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

Marek Vasut (2):
  libtiff: Add fix for tiffcrop CVE-2023-1916
  systemd: Backport systemd-resolved: use hostname for certificate
validation in DoT

Mike Crowe (2):
  curl: Backport fix for CVE-2023-38545
  curl: Backport fix for CVE-2023-38546

Pawan (1):
  libwebp: Update CVE ID CVE-2023-4863

Ryan Eatmon (1):
  kernel.bbclass: Add force flag to rm calls

Siddharth Doshi (4):
  glib-2.0: Fix multiple vulnerabilities
  vim: Upgrade 9.0.1894 -> 9.0.2009
  xorg-lib-common: Add variable to set tarball type
  libxpm: upgrade to 3.5.17

 meta/classes/kernel.bbclass   |   4 +-
 .../glib-2.0/glib-2.0/CVE-2023-29499.patch| 290 
 .../glib-2.0/CVE-2023-32611-0001.patch|  89 
 .../glib-2.0/CVE-2023-32611-0002.patch| 255 +++
 .../glib-2.0/glib-2.0/CVE-2023-32636.patch|  49 ++
 .../glib-2.0/glib-2.0/CVE-2023-32643.patch| 154 +++
 .../glib-2.0/CVE-2023-32665-0001.patch| 103 +
 .../glib-2.0/CVE-2023-32665-0002.patch| 210 +
 .../glib-2.0/CVE-2023-32665-0003.patch| 417 ++
 .../glib-2.0/CVE-2023-32665-0004.patch| 113 +
 .../glib-2.0/CVE-2023-32665-0005.patch|  80 
 .../glib-2.0/CVE-2023-32665-0006.patch| 396 +
 .../glib-2.0/CVE-2023-32665-0007.patch|  49 ++
 .../glib-2.0/CVE-2023-32665-0008.patch| 394 +
 .../glib-2.0/CVE-2023-32665-0009.patch|  97 
 meta/recipes-core/glib-2.0/glib-2.0_2.62.6.bb |  14 +
 .../systemd/systemd/CVE-2018-21029.patch  | 120 +
 meta/recipes-core/systemd/systemd_244.5.bb|   1 +
 .../xorg-lib/libxpm/CVE-2022-46285.patch  |  40 --
 .../{libxpm_3.5.13.bb => libxpm_3.5.17.bb}|   9 +-
 .../xorg-lib/xorg-lib-common.inc  |   3 +-
 .../libtiff/files/CVE-2023-1916.patch |  91 
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |   1 +
 .../webp/files/CVE-2023-5129.patch|   9 +-
 .../curl/curl/CVE-2023-38545.patch| 148 +++
 .../curl/curl/CVE-2023-38546.patch| 132 ++
 meta/recipes-support/curl/curl_7.69.1.bb  |   2 +
 meta/recipes-support/vim/vim.inc  |   4 +-
 28 files changed, 3223 insertions(+), 51 deletions(-)
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-29499.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32611-0001.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32611-0002.patch
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32636.patch
 create mode 100644 meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32643.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0001.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0002.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0003.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0004.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0005.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0006.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0007.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0008.patch
 create mode 100644 
meta/recipes-core/glib-2.0/glib-2.0/CVE-2023-32665-0009.patch
 create mode 100644 meta/recipes-core/systemd/systemd/CVE-2018-21029.patch
 delete mode 100644 meta/recipes-graphics/xorg-lib/libxpm/CVE-2022-46285.patch
 rename meta/recipes-graphics/xorg-lib/{libxpm_3.5.13.bb => libxpm_3.5.17.bb} 
(68%)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-1916.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-38545.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-38546.patch

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][dunfell 02/10] curl: Backport fix for CVE-2023-38545

From: Mike Crowe 

Backporting this change required tweaking the error value since the
two-level CURLE_PROXY error reporting was introduced after curl
7.69.1. The test required some tweaks to not rely on more-recent
improvements to the test infrastructure too.

Signed-off-by: Mike Crowe 
CVE: CVE-2023-38545
Signed-off-by: Steve Sakoman 
---
 .../curl/curl/CVE-2023-38545.patch| 148 ++
 meta/recipes-support/curl/curl_7.69.1.bb  |   1 +
 2 files changed, 149 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-38545.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2023-38545.patch 
b/meta/recipes-support/curl/curl/CVE-2023-38545.patch
new file mode 100644
index 00..c6b6726886
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-38545.patch
@@ -0,0 +1,148 @@
+From 600a1caeb2312fdee5ef1caf7d613c12a8b2424a Mon Sep 17 00:00:00 2001
+From: Mike Crowe 
+Date: Wed, 11 Oct 2023 20:50:28 +0100
+Subject: [PATCH] socks: return error if hostname too long for remote resolve
+To: libcurl development 
+
+Prior to this change the state machine attempted to change the remote
+resolve to a local resolve if the hostname was longer than 255
+characters. Unfortunately that did not work as intended and caused a
+security issue.
+
+Name resolvers cannot resolve hostnames longer than 255 characters.
+
+Bug: https://curl.se/docs/CVE-2023-38545.html
+
+Unfortunately CURLE_PROXY and CURLPX_LONG_HOSTNAME were introduced in
+7.73.0 so they can't be used in 7.69.1. Let's use
+CURLE_COULDNT_RESOLVE_HOST as the best available alternative and update
+the test appropriately.
+
+libcurl's test support has been improved considerably since 7.69.1 which
+means that the test must be modified to remove use of %VERSION and
+%TESTNUMBER and the stderr output can no longer be checked.
+
+CVE: CVE-2023-38545
+Upstream-Status: Backport [fb4415d8aee6c1045be932a34fe6107c2f5ed147]
+Signed-off-by: Mike Crowe 
+---
+ lib/socks.c | 13 +
+ tests/data/Makefile.inc |  2 +-
+ tests/data/test728  | 60 +
+ 3 files changed, 69 insertions(+), 6 deletions(-)
+ create mode 100644 tests/data/test728
+
+diff --git a/lib/socks.c b/lib/socks.c
+index 37099130e..f3bf40533 100644
+--- a/lib/socks.c
 b/lib/socks.c
+@@ -521,11 +521,14 @@ CURLcode Curl_SOCKS5(const char *proxy_user,
+   infof(conn->data, "SOCKS5: connecting to HTTP proxy %s port %d\n",
+ hostname, remote_port);
+ 
+-/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet */
++/* RFC1928 chapter 5 specifies max 255 chars for domain name in packet. */
+ if(!socks5_resolve_local && hostname_len > 255) {
+-  infof(conn->data, "SOCKS5: server resolving disabled for hostnames of "
+-"length > 255 [actual len=%zu]\n", hostname_len);
+-  socks5_resolve_local = TRUE;
++  failf(data, "SOCKS5: the destination hostname is too long to be "
++"resolved remotely by the proxy.");
++  /* This version of libcurl doesn't have CURLE_PROXY and
++   * therefore CURLPX_LONG_HOSTNAME, so let's report the best we
++   * can. */
++  return CURLE_COULDNT_RESOLVE_HOST;
+ }
+ 
+ if(auth & ~(CURLAUTH_BASIC | CURLAUTH_GSSAPI))
+@@ -837,7 +840,7 @@ CURLcode Curl_SOCKS5(const char *proxy_user,
+ 
+ if(!socks5_resolve_local) {
+   socksreq[len++] = 3; /* ATYP: domain name = 3 */
+-  socksreq[len++] = (char) hostname_len; /* one byte address length */
++  socksreq[len++] = (unsigned char) hostname_len; /* one byte length */
+   memcpy([len], hostname, hostname_len); /* address w/o NULL */
+   len += hostname_len;
+   infof(data, "SOCKS5 connect to %s:%d (remotely resolved)\n",
+diff --git a/tests/data/Makefile.inc b/tests/data/Makefile.inc
+index 3d8565c36..5ee2284ff 100644
+--- a/tests/data/Makefile.inc
 b/tests/data/Makefile.inc
+@@ -89,7 +89,7 @@ test662 test663 test664 test665 test666 test667 test668 \
+ test670 test671 test672 test673 \
+ \
+ test700 test701 test702 test703 test704 test705 test706 test707 test708 \
+-test709 test710 test711 test712 test713 test714 test715 test716 test717 \
++test709 test710 test711 test712 test713 test714 test715 test716 test717 
test728 \
+ \
+ test800 test801 test802 test803 test804 test805 test806 test807 test808 \
+ test809 test810 test811 test812 test813 test814 test815 test816 test817 \
+diff --git a/tests/data/test728 b/tests/data/test728
+new file mode 100644
+index 0..7b1d8b2f3
+--- /dev/null
 b/tests/data/test728
+@@ -0,0 +1,60 @@
++
++
++
++HTTP
++HTTP GET
++SOCKS5
++SOCKS5h
++followlocation
++
++
++
++#
++# Server-side
++
++# The hostname in this redirect is 256 characters and too long (> 255) for
++# SOCKS5 remote resolve. curl must return error CURLE_PROXY in this case.
++
++HTTP/1.1 301 Moved Permanently
++Location:

[OE-core][dunfell 01/10] libtiff: Add fix for tiffcrop CVE-2023-1916

2023-10-17 Thread Alexandre Belloni via lists.openembedded.org

From: Marek Vasut 

Add fix for tiffcrop tool CVE-2023-1916 [1].

A flaw was found in tiffcrop, a program distributed by the libtiff
package. A specially crafted tiff file can lead to an out-of-bounds
read in the extractImageSection function in tools/tiffcrop.c, resulting
in a denial of service and limited information disclosure. This issue
affects libtiff versions 4.x.

The tool is no longer part of newer libtiff distributions, hence the
fix is rejected by upstream in [2]. The backport is still applicable
to older versions of libtiff, pick the CVE fix from ubuntu 20.04 [3].

[1] https://nvd.nist.gov/vuln/detail/CVE-2023-1916
[2] https://gitlab.com/libtiff/libtiff/-/merge_requests/535
[3] https://packages.ubuntu.com/source/focal-updates/tiff

Signed-off-by: Marek Vasut 
Signed-off-by: Steve Sakoman 
---
 .../libtiff/files/CVE-2023-1916.patch | 91 +++
 meta/recipes-multimedia/libtiff/tiff_4.1.0.bb |  1 +
 2 files changed, 92 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-1916.patch

diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2023-1916.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2023-1916.patch
new file mode 100644
index 00..9915b77645
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2023-1916.patch
@@ -0,0 +1,91 @@
+From 848434a81c443f59ec90d41218eba6e48a450a11 Mon Sep 17 00:00:00 2001
+From: zhailiangliang 
+Date: Thu, 16 Mar 2023 16:16:54 +0800
+Subject: [PATCH] Fix heap-buffer-overflow in function extractImageSection
+
+CVE: CVE-2023-1916
+Upstream-Status: Submitted 
[https://gitlab.com/libtiff/libtiff/-/commit/848434a81c443f59ec90d41218eba6e48a450a11
 https://gitlab.com/libtiff/libtiff/-/merge_requests/535]
+Signed-off-by: Marek Vasut 
+---
+ archive/tools/tiffcrop.c | 62 +---
+ 1 file changed, 45 insertions(+), 17 deletions(-)
+
+--- tiff-4.1.0+git191117.orig/tools/tiffcrop.c
 tiff-4.1.0+git191117/tools/tiffcrop.c
+@@ -5549,6 +5549,15 @@ getCropOffsets(struct image_data *image,
+  crop->combined_width += (uint32)zwidth;
+else
+  crop->combined_width = (uint32)zwidth;
++
++   /* When the degrees clockwise rotation is 90 or 270, check the 
boundary */
++   if (((crop->rotation == 90) || (crop->rotation == 270))
++   && ((crop->combined_length > image->width) || 
(crop->combined_width > image->length)))
++   {
++   TIFFError("getCropOffsets", "The crop size exceeds the image 
boundary size");
++   return -1;
++   }
++
+break;
+   case EDGE_BOTTOM: /* width from left, zones from bottom to top */
+zwidth = offsets.crop_width;
+@@ -5579,6 +5588,15 @@ getCropOffsets(struct image_data *image,
+else
+  crop->combined_length = (uint32)zlength;
+crop->combined_width = (uint32)zwidth;
++
++   /* When the degrees clockwise rotation is 90 or 270, check the 
boundary */
++   if (((crop->rotation == 90) || (crop->rotation == 270))
++   && ((crop->combined_length > image->width) || 
(crop->combined_width > image->length)))
++   {
++   TIFFError("getCropOffsets", "The crop size exceeds the image 
boundary size");
++   return -1;
++   }
++
+break;
+   case EDGE_RIGHT: /* zones from right to left, length from top */
+zlength = offsets.crop_length;
+@@ -5606,6 +5624,15 @@ getCropOffsets(struct image_data *image,
+  crop->combined_width += (uint32)zwidth;
+else
+  crop->combined_width = (uint32)zwidth;
++
++   /* When the degrees clockwise rotation is 90 or 270, check the 
boundary */
++   if (((crop->rotation == 90) || (crop->rotation == 270))
++   && ((crop->combined_length > image->width) || 
(crop->combined_width > image->length)))
++   {
++   TIFFError("getCropOffsets", "The crop size exceeds the image 
boundary size");
++   return -1;
++   }
++
+break;
+   case EDGE_TOP: /* width from left, zones from top to bottom */
+   default:
+@@ -5632,6 +5659,15 @@ getCropOffsets(struct image_data *image,
+else
+  crop->combined_length = (uint32)zlength;
+crop->combined_width = (uint32)zwidth;
++
++   /* When the degrees clockwise rotation is 90 or 270, check the 
boundary */
++   if (((crop->rotation == 90) || (crop->rotation == 270))
++   && ((crop->combined_length > image->width) || 
(crop->combined_width > image->length)))
++   {
++   TIFFError("getCropOffsets", "The crop size exceeds the image 
boundary size");
++   return -1;
++   }
++
+break;
+   } /* end switch statement */
+ 
+@@ -6827,9 +6863,9 @@ extractImageSection(struct image_data *i
+  * regardless of the way the data are

Re: [OE-core] weston-init: how to debug with systemd

2023-10-17 Thread Khem Raj

I have systemd based system and I can see it in journal e.g. see

https://snips.sh/f/jleAzcqMVd

On Tue, Oct 17, 2023 at 6:05 AM Sean Nyekjaer  wrote:
>
> Hi,
>
> To my understanding the weston.service doesn’t log to journal. If I'm is 
> running the weston binary there is fine output on stdout.
>
> Looks like TTYPath is eating the logs, but I could be wrong.
>
> Adding:
> ExecStart=/usr/bin/weston --modules=systemd-notify.so --log=/tmp/weston.log
>
> Will of course give logs in that file
>
> /Sean

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189350): 
https://lists.openembedded.org/g/openembedded-core/message/189350
Mute This Topic: https://lists.openembedded.org/mt/102016986/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] packagegroup-core-tools-profile: Remove PROFILE_TOOLS_X

2023-10-17 Thread Fabio Estevam

Since commit d085e70eeedb ("sysprof: move recipe to meta-oe")
PROFILE_TOOLS_X is always set to an empty string.

Remove PROFILE_TOOLS_X as it is no longer needed.

Reported-by: Robert P. J. Day 
Signed-off-by: Fabio Estevam 
---
 .../packagegroups/packagegroup-core-tools-profile.bb  | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 62c22a35ab..b3a24b71de 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -9,16 +9,12 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 inherit packagegroup
 
-PROFILE_TOOLS_X = ""
 # sysprof doesn't support aarch64 and nios2
-PROFILE_TOOLS_X:aarch64 = ""
-PROFILE_TOOLS_X:nios2 = ""
 PROFILE_TOOLS_SYSTEMD = "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 
'systemd-analyze', '', d)}"
 
 RRECOMMENDS:${PN} = "\
 ${PERF} \
 blktrace \
-${PROFILE_TOOLS_X} \
 ${PROFILE_TOOLS_SYSTEMD} \
 "
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189349): 
https://lists.openembedded.org/g/openembedded-core/message/189349
Mute This Topic: https://lists.openembedded.org/mt/102023998/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][PATCH] binutils: CVE-2022-48063

2023-10-17 Thread Armin Kuster

From: Armin Kuster 

Source: Binutils
MR: 128800
Type: Security Fix
Disposition: Backport from 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=75393a2d54bcc40053e5262a3de9d70c5ebfbbfd
ChangeID: ab04e4ec62d054c90d94f82230adb2342ce1ee1b
Description:

Affects binutils < 2.40

Signed-off-by: Armin Kuster 
---
 .../binutils/binutils-2.38.inc|  1 +
 .../binutils/binutils/CVE-2022-48063.patch| 48 +++
 2 files changed, 49 insertions(+)
 create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2022-48063.patch

diff --git a/meta/recipes-devtools/binutils/binutils-2.38.inc 
b/meta/recipes-devtools/binutils/binutils-2.38.inc
index 638b1ba93d..2944972267 100644
--- a/meta/recipes-devtools/binutils/binutils-2.38.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.38.inc
@@ -59,5 +59,6 @@ SRC_URI = "\
  file://0029-CVE-2022-48065-1.patch \
  file://0029-CVE-2022-48065-2.patch \
  file://0029-CVE-2022-48065-3.patch \
+ file://CVE-2022-48063.patch \
 "
 S  = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2022-48063.patch 
b/meta/recipes-devtools/binutils/binutils/CVE-2022-48063.patch
new file mode 100644
index 00..ea2e030503
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2022-48063.patch
@@ -0,0 +1,48 @@
+From 75393a2d54bcc40053e5262a3de9d70c5ebfbbfd Mon Sep 17 00:00:00 2001
+From: Nick Clifton 
+Date: Wed, 21 Dec 2022 11:51:23 +
+Subject: [PATCH] Fix an attempt to allocate an unreasonably large amount of
+ memory when parsing a corrupt ELF file.
+
+   PR  29924
+   * objdump.c (load_specific_debug_section): Check for excessively
+   large sections.
+
+Upstream-Status: Backport
+CVE: CVE-2022-48063
+Signed-off-by: Armin Kuster 
+
+---
+ binutils/ChangeLog | 6 ++
+ binutils/objdump.c | 4 +++-
+ 2 files changed, 9 insertions(+), 1 deletion(-)
+
+Index: git/binutils/objdump.c
+===
+--- git.orig/binutils/objdump.c
 git/binutils/objdump.c
+@@ -3768,7 +3768,9 @@ load_specific_debug_section (enum dwarf_
+   section->size = bfd_section_size (sec);
+   /* PR 24360: On 32-bit hosts sizeof (size_t) < sizeof (bfd_size_type). */
+   alloced = amt = section->size + 1;
+-  if (alloced != amt || alloced == 0)
++  if (alloced != amt
++  || alloced == 0
++  || (bfd_get_size (abfd) != 0 && alloced >= bfd_get_size (abfd)))
+ {
+   section->start = NULL;
+   free_debug_section (debug);
+Index: git/binutils/ChangeLog
+===
+--- git.orig/binutils/ChangeLog
 git/binutils/ChangeLog
+@@ -1,3 +1,9 @@
++2022-12-21  Nick Clifton  
++
++   PR  29924
++   * objdump.c (load_specific_debug_section): Check for excessively
++   large sections.
++
+ 2022-03-23  Nick Clifton  
+ 
+   Import patch from mainline:
-- 
2.39.3


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189348): 
https://lists.openembedded.org/g/openembedded-core/message/189348
Mute This Topic: https://lists.openembedded.org/mt/102023024/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] strace: further clean up of ptest folders

From: Alexandre Belloni 

Removing the out files removes about 350MB of data which helps staying
in the currently allocated ptest image space as we are hitting disk
space issues after enabling the parallelization of tests.

Fixes [Yocto #15220]

Signed-off-by: Alexandre Belloni 
---
 meta/recipes-devtools/strace/strace/ptest-spacesave.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/strace/strace/ptest-spacesave.patch 
b/meta/recipes-devtools/strace/strace/ptest-spacesave.patch
index c5d8ff920789..4e86ccadc5b2 100644
--- a/meta/recipes-devtools/strace/strace/ptest-spacesave.patch
+++ b/meta/recipes-devtools/strace/strace/ptest-spacesave.patch
@@ -22,7 +22,7 @@ index 3540204..5e1e7c9 100755
$hdr
. "\${srcdir=.}/init.sh"
run_strace_match_diff $arg0 $args
-+  rm -rf log exp
++  rm -rf log exp out
EOF
;;
  
-- 
2.25.1


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

[OE-core] doesn't seem like "PROFILE_TOOLS_X" has any value

2023-10-17 Thread Robert P. J. Day


if you look here:

https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb#n12

it's not clear what PROFILE_TOOLS_X is doing, given that it's set to the
empty string, then conditionally set to the same thing. i don't see it 
being

referenced elsewhere.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189346): 
https://lists.openembedded.org/g/openembedded-core/message/189346
Mute This Topic: https://lists.openembedded.org/mt/102021731/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 0/4] patchtest: add to oe-core

2023-10-17 Thread Trevor Gamblin



On 2023-10-17 11:45, Michael Opdenacker wrote:

Hi Trevor

On 16.10.23 at 21:44, Trevor Gamblin wrote:

Add the patchtest core tools and supporting scripts to
openembedded-core. This will enable users to validate their changes
locally against the repository before submission to the mailing list,
reducing maintainer overhead and encouraging more consistent use of
important patch tags and information. Note that there are a few elements
of the tooling that are still under development, namely the
patchtest-send-results script, which is currently hard-coded to mail
test results to test-l...@lists.yoctoproject.org (and only that list),
while in the future it may be adjusted to directly reply to user
submissions.

A scripts/patchtest.README file is included for basic instructions on
how to use patchtest, as well as for submitting fixes should any bugs be
identified. The Yocto Project Contributor Guide will receive a single,
corresponding patch to provide similar details on why and how to use
patchtest. Finally, the patchtest layer itself will be reduced to only
those pieces that are required for building the core-image-patchtest
image, which makes special adjustments to kernel configurations and
initscripts that are only suitable for automation, and therefore outside
the scope of most contributors' usage.

Trevor Gamblin (4):
   patchtest/requirements.txt: update
   patchtest: add supporting modules
   patchtest: add scripts to oe-core
   patchtest: set default repo and testdir targets

  meta/lib/patchtest/data.py  | 100 
  meta/lib/patchtest/patch.py |  73 +
  meta/lib/patchtest/repo.py  | 185 ++
  meta/lib/patchtest/requirements.txt |   2 +
  meta/lib/patchtest/utils.py | 179 +
  scripts/patchtest   | 233 
  scripts/patchtest-get-branch    |  92 +++
  scripts/patchtest-get-series    | 125 +++
  scripts/patchtest-send-results  |  93 +++
  scripts/patchtest-setup-sharedir    |  95 
  scripts/patchtest.README    | 156 +++
  11 files changed, 1333 insertions(+)
  create mode 100644 meta/lib/patchtest/data.py
  create mode 100644 meta/lib/patchtest/patch.py
  create mode 100644 meta/lib/patchtest/repo.py
  create mode 100644 meta/lib/patchtest/utils.py
  create mode 100755 scripts/patchtest
  create mode 100755 scripts/patchtest-get-branch
  create mode 100755 scripts/patchtest-get-series
  create mode 100755 scripts/patchtest-send-results
  create mode 100755 scripts/patchtest-setup-sharedir
  create mode 100644 scripts/patchtest.README


Thanks for this!

I tried "patchtest --patch" with the attached patch, which had its 
"Signed-off-by" line intentionally removed.

However, it didn't find the issue (see the attached log).

Did I miss anything in the way I use it?


Hi Michael,

This is a little odd, I can't reproduce what you're seeing even with a 
fresh checkout of poky, so I'm wondering if maybe it's because Python 
modules are missing on the host. However, patchtest is currently only 
designed to work properly with oe-core patches, and trying to point it 
at yocto-docs will cause a failure because it expects the 
yocto-docs/scripts/lib path to exist for use (normally it will look in 
openembedded-core/scripts/lib for a few modules). This is one of the 
things I want to improve now that it's working again. In the meantime, 
This is some important info for the docs I had missed, so I'll send a 
patch with clarification about where patchtest can be used.


- Trevor


Thanks again
Michael.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189345): 
https://lists.openembedded.org/g/openembedded-core/message/189345
Mute This Topic: https://lists.openembedded.org/mt/102003998/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] Recent failures on master depmodwrapper-cross

2023-10-17 Thread Mark Hatle


I wanted to confirm, this did fix the problem for me.  Thanks!

On 10/16/23 10:54 AM, Yoann Congal wrote:

Le lun. 16 oct. 2023 à 17:37, Mark Hatle
 a écrit :

On 10/16/23 7:17 AM, Yoann Congal wrote:

Hi Mark,

Le lun. 16 oct. 2023 à 02:40, Mark Hatle via lists.openembedded.org
 a écrit :

Running a number of builds recently, a small number of them failed.  Note we 
ran about 20 builds and only 3 failed like this, the others completed.  I'm 
wondering if maybe there is a race condition with the new code?


FYI, RP did point me to this thread (that I did miss sorry) and I
(co-author of the "new code") will send two patches to prevent the
error the happen again.
RP's hypothesis is that this is linked to S=WORKDIR recipes. Did all
your crashed build happened on "depmodwrapper-cross" (Which is
S=WORKDIR) ?


Yes, they all failed on depmodwrapper-cross.


Realy looks like the S=WORKDIR case !


Happy to test changes for you.


Thanks!

I've sent patches here  :
[PATCH 1/2] insane: skip unimplemented-ptest on S=WORKDIR recipes
https://lists.openembedded.org/g/openembedded-core/message/189301
[PATCH 2/2] insane: unimplemented-ptest: ignore source file errors
https://lists.openembedded.org/g/openembedded-core/message/189302

I've tested that the depmodwrapper-cross recipe is now skipped for the
unimplemented-ptest check.

Regards,


--Mark


Thanks!


Error:

ERROR: depmodwrapper-cross-1.0-r0 do_patch: Error executing a python function 
in exec_func_python() autogenerated:

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: 
0001:
*** 0002:do_qa_patch(d)
0003:
File: 
'/scratch/jenkins-BUILDS-eSDK-dev_eSDK-eSDK-master-next-pipeline-8_ZynqMpDrFull/sources/poky/meta/classes-global/insane.bbclass',
 lineno: 1379, function: do_qa_patch
1375:elif os.path.exists(os.path.join(srcdir, "t")) and 
any(filename.endswith('.t') for filename in os.listdir(os.path.join(srcdir, 't'))):
1376:oe.qa.handle_error("unimplemented-ptest", "%s: perl Test:: based tests 
detected" % d.getVar('PN'), d)
1377:
1378:# Detect pytest-based tests
*** 1379:elif match_line_in_files(srcdir, "**/*.py", 
r'\s*(?:import\s*pytest|from\s*pytest)'):
1380:oe.qa.handle_error("unimplemented-ptest", "%s: pytest-based tests 
detected" % d.getVar('PN'), d)
1381:
1382:# Detect meson-based tests
1383:elif os.path.exists(os.path.join(srcdir, "meson.build")) and 
match_line_in_files(srcdir, "**/meson.build", r'\s*test\s*\('):
File: 
'/scratch/jenkins-BUILDS-eSDK-dev_eSDK-eSDK-master-next-pipeline-8_ZynqMpDrFull/sources/poky/meta/classes-global/insane.bbclass',
 lineno: 1357, function: match_line_in_files
1353:
###
1354:def match_line_in_files(toplevel, filename_glob, line_regex):
1355:import pathlib
1356:toppath = pathlib.Path(toplevel)
*** 1357:for entry in toppath.glob(filename_glob):
1358:try:
1359:with open(entry, 'r', encoding='utf-8', errors='ignore') 
as f:
1360:for line in f.readlines():
1361:if re.match(line_regex, line):
File: '/usr/lib/python3.10/pathlib.py', lineno: 1034, function: glob
1030:drv, root, pattern_parts = self._flavour.parse_parts((pattern,))
1031:if drv or root:
1032:raise NotImplementedError("Non-relative patterns are 
unsupported")
1033:selector = _make_selector(tuple(pattern_parts), self._flavour)
*** 1034:for p in selector.select_from(self):
1035:yield p
1036:
1037:def rglob(self, pattern):
1038:"""Recursively yield all existing files (of any kind, including
File: '/usr/lib/python3.10/pathlib.py', lineno: 493, function: _select_from
0489:yielded = set()
0490:try:
0491:successor_select = self.successor._select_from
0492:for starting_point in 
self._iterate_directories(parent_path, is_dir, scandir):
*** 0493:for p in successor_select(starting_point, is_dir, 
exists, scandir):
0494:if p not in yielded:
0495:yield p
0496:yielded.add(p)
0497:finally:
File: '/usr/lib/python3.10/pathlib.py', lineno: 440, function: _select_from
0436:_Selector.__init__(self, child_parts, flavour)
0437:
0438:def _select_from(self, parent_path, is_dir, exists, scandir):
0439:try:
*** 0440:with scandir(parent_path) as scandir_it:
0441:entries = list(scandir_it)
0442:for entry in entries:
0443:if self.dironly:
0444:try:
Exception: FileNotFoundError: [Errno 2] No such file or directory:

[OE-core][kirkstone][PATCH] tiff: Security fix for CVE-2023-40745

2023-10-17 Thread Siddharth via lists.openembedded.org

From: Siddharth Doshi 

Upstream-Status: Backport from 
[https://gitlab.com/libtiff/libtiff/-/commit/4fc16f649fa2875d5c388cf2edc295510a247ee5]
CVE: CVE-2023-40745
Signed-off-by: Siddharth Doshi 
---
 .../libtiff/tiff/CVE-2023-40745.patch | 34 +++
 meta/recipes-multimedia/libtiff/tiff_4.3.0.bb |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-multimedia/libtiff/tiff/CVE-2023-40745.patch

diff --git a/meta/recipes-multimedia/libtiff/tiff/CVE-2023-40745.patch 
b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-40745.patch
new file mode 100644
index 00..cb4656fd46
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/tiff/CVE-2023-40745.patch
@@ -0,0 +1,34 @@
+From 4fc16f649fa2875d5c388cf2edc295510a247ee5 Mon Sep 17 00:00:00 2001
+From: Arie Haenel 
+Date: Wed, 19 Jul 2023 19:34:25 +
+Subject: [PATCH] tiffcp: fix memory corruption (overflow) on hostile images
+ (fixes #591)
+
+Upstream-Status: Backport from 
[https://gitlab.com/libtiff/libtiff/-/commit/4fc16f649fa2875d5c388cf2edc295510a247ee5]
+CVE: CVE-2023-40745
+Signed-off-by: Siddharth Doshi 
+---
+ tools/tiffcp.c | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/tools/tiffcp.c b/tools/tiffcp.c
+index 57eef90..34b6ef2 100644
+--- a/tools/tiffcp.c
 b/tools/tiffcp.c
+@@ -1577,6 +1577,13 @@ DECLAREreadFunc(readSeparateTilesIntoBuffer)
+   TIFFError(TIFFFileName(in), "Error, cannot handle that much 
samples per tile row (Tile Width * Samples/Pixel)");
+   return 0;
+   }
++
++  if ( (imagew - tilew * spp) > INT_MAX ){
++  TIFFError(TIFFFileName(in),
++"Error, image raster scan line size is too large");
++  return 0;
++  }
++
+   iskew = imagew - tilew*spp;
+   tilebuf = limitMalloc(tilesize);
+   if (tilebuf == 0)
+-- 
+2.25.1
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb 
b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
index 61d8142e41..9071b407cf 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.3.0.bb
@@ -43,6 +43,7 @@ SRC_URI = 
"http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://CVE-2023-3618-1.patch \
file://CVE-2023-3618-2.patch \
file://CVE-2023-26966.patch \
+   file://CVE-2023-40745.patch \
"
 
 SRC_URI[sha256sum] = 
"0e46e5acb087ce7d1ac53cf4f56a09b221537fc86dfc5daaad1c2e89e1b37ac8"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189343): 
https://lists.openembedded.org/g/openembedded-core/message/189343
Mute This Topic: https://lists.openembedded.org/mt/102020787/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 0/4] patchtest: add to oe-core

2023-10-17 Thread Michael Opdenacker via lists.openembedded.org


Hi Trevor

On 16.10.23 at 21:44, Trevor Gamblin wrote:

Add the patchtest core tools and supporting scripts to
openembedded-core. This will enable users to validate their changes
locally against the repository before submission to the mailing list,
reducing maintainer overhead and encouraging more consistent use of
important patch tags and information. Note that there are a few elements
of the tooling that are still under development, namely the
patchtest-send-results script, which is currently hard-coded to mail
test results to test-l...@lists.yoctoproject.org (and only that list),
while in the future it may be adjusted to directly reply to user
submissions.

A scripts/patchtest.README file is included for basic instructions on
how to use patchtest, as well as for submitting fixes should any bugs be
identified. The Yocto Project Contributor Guide will receive a single,
corresponding patch to provide similar details on why and how to use
patchtest. Finally, the patchtest layer itself will be reduced to only
those pieces that are required for building the core-image-patchtest
image, which makes special adjustments to kernel configurations and
initscripts that are only suitable for automation, and therefore outside
the scope of most contributors' usage.

Trevor Gamblin (4):
   patchtest/requirements.txt: update
   patchtest: add supporting modules
   patchtest: add scripts to oe-core
   patchtest: set default repo and testdir targets

  meta/lib/patchtest/data.py  | 100 
  meta/lib/patchtest/patch.py |  73 +
  meta/lib/patchtest/repo.py  | 185 ++
  meta/lib/patchtest/requirements.txt |   2 +
  meta/lib/patchtest/utils.py | 179 +
  scripts/patchtest   | 233 
  scripts/patchtest-get-branch|  92 +++
  scripts/patchtest-get-series| 125 +++
  scripts/patchtest-send-results  |  93 +++
  scripts/patchtest-setup-sharedir|  95 
  scripts/patchtest.README| 156 +++
  11 files changed, 1333 insertions(+)
  create mode 100644 meta/lib/patchtest/data.py
  create mode 100644 meta/lib/patchtest/patch.py
  create mode 100644 meta/lib/patchtest/repo.py
  create mode 100644 meta/lib/patchtest/utils.py
  create mode 100755 scripts/patchtest
  create mode 100755 scripts/patchtest-get-branch
  create mode 100755 scripts/patchtest-get-series
  create mode 100755 scripts/patchtest-send-results
  create mode 100755 scripts/patchtest-setup-sharedir
  create mode 100644 scripts/patchtest.README


Thanks for this!

I tried "patchtest --patch" with the attached patch, which had its 
"Signed-off-by" line intentionally removed.

However, it didn't find the issue (see the attached log).

Did I miss anything in the way I use it?
Thanks again
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
From 2e1d43af896722a8788be102df1b975819ecf678 Mon Sep 17 00:00:00 2001
From: Michael Opdenacker 
Date: Tue, 17 Oct 2023 15:07:09 +0200
Subject: [PATCH] brief-yoctoprojectqs: use new CDN mirror for sstate

Recommended instead of the Yocto Project mirror, because expected
to be faster. Make sure you only set one such mirror.

CC: richard.pur...@linuxfoundation.org
---
 documentation/brief-yoctoprojectqs/index.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 0ccffccc60..df8d75edc2 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -254,7 +254,7 @@ an entire Linux distribution, including the toolchain, from source.
  BB_SIGNATURE_HANDLER = "OEEquivHash"
  BB_HASHSERVE = "auto"
  BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
- SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH;
+ SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH;
 
 #. **Start the Build:** Continue with the following command to build an OS
image for the target, which is ``core-image-sato`` in this example:
-- 
2.34.1

Testing patch /home/mike/work/git/git.yoctoproject.org/yocto-docs/documentation/0001-brief-yoctoprojectqs-use-new-CDN-mirror-for-sstate.patch
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
--
Ran 18 tests in 0.403s

OK
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None
NoneType: None
None

[OE-core] [PATCH] Add SECURITY.md

2023-10-17 Thread Marta Rybczynska

Add a SECURITY.md filr with hints for security researchers and other
parties who might report potential security vulnerabilities.

Signed-off-by: Marta Rybczynska 
---
 SECURITY.md | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 SECURITY.md

diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 00..900da76e59
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,17 @@
+How to Report a Vulnerability?
+==
+
+Please send a message to security AT yoctoproject DOT org, including as many 
details
+as possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release 
and LTS]
+for detailed info regarding the policies and maintenance of Stable branch.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list 
of all
+releases of the Yocto Project. Versions in grey are no longer actively 
maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189341): 
https://lists.openembedded.org/g/openembedded-core/message/189341
Mute This Topic: https://lists.openembedded.org/mt/102019988/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] patchtest/selftest: fix command arguments

2023-10-17 Thread Trevor Gamblin

Changes to patchtest's command-line arguments to work with oe-core by
default do not match the selftest script's argument list. Explicitly use
the --testdir and --repodir flags in selftest so that it is compatible
them.

Signed-off-by: Trevor Gamblin 
---
 meta/lib/patchtest/selftest/selftest | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/patchtest/selftest/selftest 
b/meta/lib/patchtest/selftest/selftest
index 79b12542488..006d1badf83 100755
--- a/meta/lib/patchtest/selftest/selftest
+++ b/meta/lib/patchtest/selftest/selftest
@@ -37,7 +37,7 @@ def test(root, patch):
 res = True
 patchpath = os.path.abspath(os.path.join(root, patch))
 
-cmd = 'patchtest %s %s/tests --patch %s' % (repodir, topdir, patchpath)
+cmd = 'patchtest --repodir %s --testdir %s/tests --patch %s' % 
(repodir, topdir, patchpath)
 results = subprocess.check_output(cmd, stderr=subprocess.STDOUT, 
universal_newlines=True, shell=True)
 
 return results
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189340): 
https://lists.openembedded.org/g/openembedded-core/message/189340
Mute This Topic: https://lists.openembedded.org/mt/102019747/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 October 2023 (WW42)

2023-10-17 Thread Neal Caidin

Current Dev Position: YP 4.3 M4 (Feature Freeze)

Next Deadline: 2nd October 2023 YP 4.3 M4 build date

Next Team Meetings:

Bug Triage meeting Thursday October 19th 7:30 am PDT (
https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
-

Weekly Project Engineering Sync Tuesday October 17th at 8 am PDT (
https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)

Twitch - See https://www.twitch.tv/theyoctojester

Key Status/Updates:

The YP 4.3 (M4) rc1 build is still pending
-

For the 4.3 release, the 6.5 serial port issues are still presenting a
challenge. We have merged a workaround which seems to fix things for the
majority of cases. There is also a second proposed patch from upstream
which may help. The dilemma is which option to go for in the release and
the time implications of the choice as one is tested and one is not.
-

The only other potential issue for 4.3 is the strace ptest image space
issues which is still being worked on.
-

Patchtest did merge to OE-Core and will be included in the release
allowing users to locally test their patches before submission using the
same code/tests we will ultimately run against mailing list submissions.
This is late in the cycle but important to help users and standalone code
so worthwhile adding since it was ready. Thanks Trevor!
-

There were multiple CVE fixes merged over the last week to ensure the
release had recent widely publicized CVEs addressed.
-

Toaster has had upgrades to key components which help address security
issues and patches are merging to enable testing to be resumed and
ultimately, automated.
-

There was a big improvement in reproducibility for rust. Unfortunately
this hasn’t addressed all the issues but is a big step forward and great to
see progress on what was a really difficult to track down issue, thanks
Sundeep.
-

The project is pleased to have a new content delivery network (CDN)
available to share sstate from the autobuilder with. See the entry in
local.conf.sample on how to use it.
-

After consultation and discussions the project is now about to document
its security processes to complete the work in this area. Please watch the
mailing lists such as the architecture list if you have an interest in this
area.

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.3. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.3_Unassigned_Enhancements.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/maintainers.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

We have a growing number of bugs in bugzilla, any help with them is
appreciated.

YP 4.3 Milestone Dates:

YP 4.3 M3 was released.
-

YP 4.3 M4 build date 2023/10/02
-

YP 4.3 M4 Release date 2023/10/27

YP 5.0 Milestone Dates:

YP 5.0 M1 build date 2023/12/04
-

YP 5.0 M1 Release date 2023/12/15
-

YP 5.0 M2 build date 2024/01/15
-

YP 5.0 M2 Release date 2024/01/24
-

YP 5.0 M3 build date 2024/02/19
-

YP 5.0 M3 Release date 2024/03/01
-

YP 5.0 M4 build date 2024/04/01
-

YP 5.0 M4 Release date 2024/04/30

Upcoming dot releases:

YP 3.1.29 build date 2023/10/30
-

YP 3.1.29 Release date 2023/11/10
-

YP 4.0.14 build date 2023/11/06
-

YP 4.0.14 Release date 2023/11/17
-

YP 4.2.4 build date 2023/11/13
-

YP 4.2.4 Release date 2023/11/24
-

YP 4.3.1 build date 2023/11/27
-

YP 4.3.1 Release date 2023/12/08
-

YP 3.1.30 build date 2023/12/11
-

YP 3.1.30 Release date 2023/12/22
-

YP 4.0.15 build date 2023/12/18
-

YP 4.0.15 Release date

Re: [OE-core] [PATCH 2/3] selftest/sstatetests: add tests for 'bitbake -S printdiff'

Thanks, I was completely sure in my head I had fixed this, but either
I haven't, or it has been somehow lost.

Alex

On Tue, 17 Oct 2023 at 16:06, Jose Quaresma  wrote:
>
>
>
> Alexander Kanavin  escreveu no dia terça, 17/10/2023 
> à(s) 14:31:
>>
>> 'bitbake -S printdiff' is a useful diagnostic facility for finding out
>> why sstate is not being reused, but until now it had no tests that would
>> ensure it works. This commit adds three basic scenarios:
>>
>> 1. make a change in a really basic, common recipe that is at the very root
>> of dependency trees (quilt-native), and ensure that change is correctly 
>> discovered when
>> building an image.
>>
>> 2. make a change in gcc-source recipe, which is somewhat special
>> (operates in work-shared), and ensure that gcc-runtime builds track
>> that down as well.
>>
>> 3. make a change in base_do_configure() definition from base.bbclass,
>> which is not recipe-specific, but affects many basic recipes, and ensure that
>> is correctly reported as well.
>>
>> The test itself actually runs twice:
>> - first against a fully populated build directory, where
>> the printdiff code is guaranteed to find the correct previous
>> stamp that can be compared with in a predictable manner.
>>
>> - then in an empty build directory where the printdiff code
>> goes to look in the sstate cache, and so the existence of the
>> previous signature can be tested, but not the difference with it
>> (what the exact difference would be is unpredictable as the
>> sstate cache is indeed shared between many builds).
>>
>> Signed-off-by: Alexander Kanavin 
>> ---
>>  .../base-do-configure-modified.bbclass|   3 +
>>  .../gcc-source/gcc-source_%.bbappend  |   2 +
>>  .../quilt-native/quilt-native_%.bbappend  |   2 +
>>  meta/lib/oeqa/selftest/cases/sstatetests.py   | 104 ++
>>  4 files changed, 111 insertions(+)
>>  create mode 100644 meta-selftest/classes/base-do-configure-modified.bbclass
>>  create mode 100644 
>> meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
>>  create mode 100644 
>> meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
>>
>> diff --git a/meta-selftest/classes/base-do-configure-modified.bbclass 
>> b/meta-selftest/classes/base-do-configure-modified.bbclass
>> new file mode 100644
>> index 000..3f96827a428
>> --- /dev/null
>> +++ b/meta-selftest/classes/base-do-configure-modified.bbclass
>> @@ -0,0 +1,3 @@
>> +base_do_configure:append () {
>> +   echo "this changes base_do_configure() definiton"
>> +}
>> diff --git a/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend 
>> b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
>> new file mode 100644
>> index 000..205720982cb
>> --- /dev/null
>> +++ b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
>> @@ -0,0 +1,2 @@
>> +# This bbappend is used to alter the recipe using the test_recipe.inc file 
>> created by tests.
>> +include test_recipe.inc
>> diff --git a/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend 
>> b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
>> new file mode 100644
>> index 000..205720982cb
>> --- /dev/null
>> +++ b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
>> @@ -0,0 +1,2 @@
>> +# This bbappend is used to alter the recipe using the test_recipe.inc file 
>> created by tests.
>> +include test_recipe.inc
>> diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
>> b/meta/lib/oeqa/selftest/cases/sstatetests.py
>> index bdad9088d37..29e31f2ef9f 100644
>> --- a/meta/lib/oeqa/selftest/cases/sstatetests.py
>> +++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
>> @@ -773,3 +773,107 @@ addtask tmptask2 before do_tmptask1
>>  latestfiles = sorted(filedates.keys(), key=lambda f: 
>> filedates[f])[-2:]
>>  bb.siggen.compare_sigfiles(latestfiles[-2], 
>> latestfiles[-1], recursecb)
>>  self.assertEqual(recursecb_count,1)
>> +
>> +class SStatePrintdiff(SStateBase):
>> +def run_test_printdiff_changerecipe(self, target, change_recipe, 
>> change_bbtask, change_content, expected_sametmp_output, 
>> expected_difftmp_output):
>> +self.write_config("""
>> +TMPDIR = "${TOPDIR}/tmp-sstateprintdiff"
>> +""")
>> +self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff")
>> +bitbake(target)
>> +bitbake("-S none {}".format(target))
>> +bitbake(change_bbtask)
>> +self.write_recipeinc(change_recipe, change_content)
>> +result_sametmp = bitbake("-S printdiff {}".format(target))
>> +
>> +self.write_config("""
>> +TMPDIR = "${TOPDIR}/tmp-sstateprintdiff-2"
>> +""")
>> +self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff-2")
>> +result_difftmp = bitbake("-S printdiff {}".format(target))
>> +
>> +self.delete_recipeinc(change_recipe)
>> +for item in expected_sametmp_output:
>> +self.assertIn(item,

Re: [OE-core] [PATCH 2/3] selftest/sstatetests: add tests for 'bitbake -S printdiff'

Alexander Kanavin  escreveu no dia terça,
17/10/2023 à(s) 14:31:

> 'bitbake -S printdiff' is a useful diagnostic facility for finding out
> why sstate is not being reused, but until now it had no tests that would
> ensure it works. This commit adds three basic scenarios:
>
> 1. make a change in a really basic, common recipe that is at the very root
> of dependency trees (quilt-native), and ensure that change is correctly
> discovered when
> building an image.
>
> 2. make a change in gcc-source recipe, which is somewhat special
> (operates in work-shared), and ensure that gcc-runtime builds track
> that down as well.
>
> 3. make a change in base_do_configure() definition from base.bbclass,
> which is not recipe-specific, but affects many basic recipes, and ensure
> that
> is correctly reported as well.
>
> The test itself actually runs twice:
> - first against a fully populated build directory, where
> the printdiff code is guaranteed to find the correct previous
> stamp that can be compared with in a predictable manner.
>
> - then in an empty build directory where the printdiff code
> goes to look in the sstate cache, and so the existence of the
> previous signature can be tested, but not the difference with it
> (what the exact difference would be is unpredictable as the
> sstate cache is indeed shared between many builds).
>
> Signed-off-by: Alexander Kanavin 
> ---
>  .../base-do-configure-modified.bbclass|   3 +
>  .../gcc-source/gcc-source_%.bbappend  |   2 +
>  .../quilt-native/quilt-native_%.bbappend  |   2 +
>  meta/lib/oeqa/selftest/cases/sstatetests.py   | 104 ++
>  4 files changed, 111 insertions(+)
>  create mode 100644
> meta-selftest/classes/base-do-configure-modified.bbclass
>  create mode 100644
> meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
>  create mode 100644
> meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
>
> diff --git a/meta-selftest/classes/base-do-configure-modified.bbclass
> b/meta-selftest/classes/base-do-configure-modified.bbclass
> new file mode 100644
> index 000..3f96827a428
> --- /dev/null
> +++ b/meta-selftest/classes/base-do-configure-modified.bbclass
> @@ -0,0 +1,3 @@
> +base_do_configure:append () {
> +   echo "this changes base_do_configure() definiton"
> +}
> diff --git a/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
> b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
> new file mode 100644
> index 000..205720982cb
> --- /dev/null
> +++ b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
> @@ -0,0 +1,2 @@
> +# This bbappend is used to alter the recipe using the test_recipe.inc
> file created by tests.
> +include test_recipe.inc
> diff --git
> a/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
> b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
> new file mode 100644
> index 000..205720982cb
> --- /dev/null
> +++ b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
> @@ -0,0 +1,2 @@
> +# This bbappend is used to alter the recipe using the test_recipe.inc
> file created by tests.
> +include test_recipe.inc
> diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py
> b/meta/lib/oeqa/selftest/cases/sstatetests.py
> index bdad9088d37..29e31f2ef9f 100644
> --- a/meta/lib/oeqa/selftest/cases/sstatetests.py
> +++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
> @@ -773,3 +773,107 @@ addtask tmptask2 before do_tmptask1
>  latestfiles = sorted(filedates.keys(), key=lambda f:
> filedates[f])[-2:]
>  bb.siggen.compare_sigfiles(latestfiles[-2],
> latestfiles[-1], recursecb)
>  self.assertEqual(recursecb_count,1)
> +
> +class SStatePrintdiff(SStateBase):
> +def run_test_printdiff_changerecipe(self, target, change_recipe,
> change_bbtask, change_content, expected_sametmp_output,
> expected_difftmp_output):
> +self.write_config("""
> +TMPDIR = "${TOPDIR}/tmp-sstateprintdiff"
> +""")
> +self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff")
> +bitbake(target)
> +bitbake("-S none {}".format(target))
> +bitbake(change_bbtask)
> +self.write_recipeinc(change_recipe, change_content)
> +result_sametmp = bitbake("-S printdiff {}".format(target))
> +
> +self.write_config("""
> +TMPDIR = "${TOPDIR}/tmp-sstateprintdiff-2"
> +""")
> +self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff-2")
> +result_difftmp = bitbake("-S printdiff {}".format(target))
> +
> +self.delete_recipeinc(change_recipe)
> +for item in expected_sametmp_output:
> +self.assertIn(item, result_sametmp.output)
> +for item in expected_difftmp_output:
> +self.assertIn(item, result_difftmp.output)
> +
> +def run_test_printdiff_changeconfig(self, target, change_content,
> expected_sametmp_output, expected_difftmp_output):
> +self.write_config("""
> +TMPDIR =

Re: [OE-Core][PATCH v2 4/4] recipetool: Add handler to create go recipes


Hi Richard,

On 17.10.2023 15:53, Richard Purdie wrote:

On Tue, 2023-10-17 at 15:26 +0200, Lukas Funke wrote:

From: Lukas Funke 

Signed-off-by: Lukas Funke 
---
  scripts/lib/recipetool/create_go.py | 730 
  1 file changed, 730 insertions(+)
  create mode 100644 scripts/lib/recipetool/create_go.py

diff --git a/scripts/lib/recipetool/create_go.py 
b/scripts/lib/recipetool/create_go.py
new file mode 100644
index 00..e0254f111b
--- /dev/null
+++ b/scripts/lib/recipetool/create_go.py
@@ -0,0 +1,730 @@
+# Recipe creation tool - go support plugin
+#
+# Copyright (C) 2023 Weidmueller GmbH & Co KG
+# Author: Lukas Funke 
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (c) 2009 The Go Authors. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-3-Clause
+#


Can you clarify what this license information means please? Two
different license identifier lines seems rather confusing and
problematic.

I've not looked into the rest of the patches yet, this just caught my
eye.


Some of the ideas/code was ported from the original golang code to 
python here. Thus, I had to copy the license information as well (I 
guess?). If this is wrong or could be written in another way please 
provide an example how it's done.


Best regards,
Lukas



Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189336): 
https://lists.openembedded.org/g/openembedded-core/message/189336
Mute This Topic: https://lists.openembedded.org/mt/102017392/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] Move Go architecture mapping to a library

2023-10-17 Thread Joshua Watt

Other spaces uses the Go architecture definitions as their own (for
example, container arches are defined to be Go arches). To make it
easier for other places to use this mapping, move the code that does the
translation of OpenEmbedded arches to Go arches to a library.

Signed-off-by: Joshua Watt 
---
 meta/classes-recipe/goarch.bbclass | 29 +++--
 meta/lib/oe/__init__.py|  2 +-
 meta/lib/oe/go.py  | 34 ++
 3 files changed, 38 insertions(+), 27 deletions(-)
 create mode 100644 meta/lib/oe/go.py

diff --git a/meta/classes-recipe/goarch.bbclass 
b/meta/classes-recipe/goarch.bbclass
index 5fb6051bde..1ebe03864f 100644
--- a/meta/classes-recipe/goarch.bbclass
+++ b/meta/classes-recipe/goarch.bbclass
@@ -68,33 +68,10 @@ SECURITY_NOPIE_CFLAGS ??= ""
 CCACHE_DISABLE ?= "1"
 
 def go_map_arch(a, d):
-import re
-if re.match('i.86', a):
-return '386'
-elif a == 'x86_64':
-return 'amd64'
-elif re.match('arm.*', a):
-return 'arm'
-elif re.match('aarch64.*', a):
-return 'arm64'
-elif re.match('mips64el.*', a):
-return 'mips64le'
-elif re.match('mips64.*', a):
-return 'mips64'
-elif a == 'mips':
-return 'mips'
-elif a == 'mipsel':
-return 'mipsle'
-elif re.match('p(pc|owerpc)(64le)', a):
-return 'ppc64le'
-elif re.match('p(pc|owerpc)(64)', a):
-return 'ppc64'
-elif a == 'riscv64':
-return 'riscv64'
-elif a == 'loongarch64':
-return 'loong64'
-else:
+arch = oe.go.map_arch(a)
+if not arch:
 raise bb.parse.SkipRecipe("Unsupported CPU architecture: %s" % a)
+return arch
 
 def go_map_arm(a, d):
 if a.startswith("arm"):
diff --git a/meta/lib/oe/__init__.py b/meta/lib/oe/__init__.py
index da7cbab308..6eb536ad28 100644
--- a/meta/lib/oe/__init__.py
+++ b/meta/lib/oe/__init__.py
@@ -9,4 +9,4 @@ __path__ = extend_path(__path__, __name__)
 
 BBIMPORTS = ["data", "path", "utils", "types", "package", "packagedata", \
  "packagegroup", "sstatesig", "lsb", "cachedpath", "license", \
- "qa", "reproducible", "rust", "buildcfg"]
+ "qa", "reproducible", "rust", "buildcfg", "go"]
diff --git a/meta/lib/oe/go.py b/meta/lib/oe/go.py
new file mode 100644
index 00..dfd957d157
--- /dev/null
+++ b/meta/lib/oe/go.py
@@ -0,0 +1,34 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import re
+
+def map_arch(a):
+if re.match('i.86', a):
+return '386'
+elif a == 'x86_64':
+return 'amd64'
+elif re.match('arm.*', a):
+return 'arm'
+elif re.match('aarch64.*', a):
+return 'arm64'
+elif re.match('mips64el.*', a):
+return 'mips64le'
+elif re.match('mips64.*', a):
+return 'mips64'
+elif a == 'mips':
+return 'mips'
+elif a == 'mipsel':
+return 'mipsle'
+elif re.match('p(pc|owerpc)(64le)', a):
+return 'ppc64le'
+elif re.match('p(pc|owerpc)(64)', a):
+return 'ppc64'
+elif a == 'riscv64':
+return 'riscv64'
+elif a == 'loongarch64':
+return 'loong64'
+return ''
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189335): 
https://lists.openembedded.org/g/openembedded-core/message/189335
Mute This Topic: https://lists.openembedded.org/mt/102018089/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 4/4] recipetool: Add handler to create go recipes

On Tue, 2023-10-17 at 15:26 +0200, Lukas Funke wrote:
> From: Lukas Funke 
> 
> Signed-off-by: Lukas Funke 
> ---
>  scripts/lib/recipetool/create_go.py | 730 
>  1 file changed, 730 insertions(+)
>  create mode 100644 scripts/lib/recipetool/create_go.py
> 
> diff --git a/scripts/lib/recipetool/create_go.py 
> b/scripts/lib/recipetool/create_go.py
> new file mode 100644
> index 00..e0254f111b
> --- /dev/null
> +++ b/scripts/lib/recipetool/create_go.py
> @@ -0,0 +1,730 @@
> +# Recipe creation tool - go support plugin
> +#
> +# Copyright (C) 2023 Weidmueller GmbH & Co KG
> +# Author: Lukas Funke 
> +#
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Copyright (c) 2009 The Go Authors. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-3-Clause
> +#

Can you clarify what this license information means please? Two
different license identifier lines seems rather confusing and
problematic.

I've not looked into the rest of the patches yet, this just caught my
eye.

Cheers,

Richard


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

[OE-core] [PATCH 2/3] selftest/sstatetests: add tests for 'bitbake -S printdiff'

'bitbake -S printdiff' is a useful diagnostic facility for finding out
why sstate is not being reused, but until now it had no tests that would
ensure it works. This commit adds three basic scenarios:

1. make a change in a really basic, common recipe that is at the very root
of dependency trees (quilt-native), and ensure that change is correctly 
discovered when
building an image.

2. make a change in gcc-source recipe, which is somewhat special
(operates in work-shared), and ensure that gcc-runtime builds track
that down as well.

3. make a change in base_do_configure() definition from base.bbclass,
which is not recipe-specific, but affects many basic recipes, and ensure that
is correctly reported as well.

The test itself actually runs twice:
- first against a fully populated build directory, where
the printdiff code is guaranteed to find the correct previous
stamp that can be compared with in a predictable manner.

- then in an empty build directory where the printdiff code
goes to look in the sstate cache, and so the existence of the
previous signature can be tested, but not the difference with it
(what the exact difference would be is unpredictable as the
sstate cache is indeed shared between many builds).

Signed-off-by: Alexander Kanavin 
---
 .../base-do-configure-modified.bbclass|   3 +
 .../gcc-source/gcc-source_%.bbappend  |   2 +
 .../quilt-native/quilt-native_%.bbappend  |   2 +
 meta/lib/oeqa/selftest/cases/sstatetests.py   | 104 ++
 4 files changed, 111 insertions(+)
 create mode 100644 meta-selftest/classes/base-do-configure-modified.bbclass
 create mode 100644 meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
 create mode 100644 
meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend

diff --git a/meta-selftest/classes/base-do-configure-modified.bbclass 
b/meta-selftest/classes/base-do-configure-modified.bbclass
new file mode 100644
index 000..3f96827a428
--- /dev/null
+++ b/meta-selftest/classes/base-do-configure-modified.bbclass
@@ -0,0 +1,3 @@
+base_do_configure:append () {
+   echo "this changes base_do_configure() definiton"
+}
diff --git a/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend 
b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
new file mode 100644
index 000..205720982cb
--- /dev/null
+++ b/meta-selftest/recipes-test/gcc-source/gcc-source_%.bbappend
@@ -0,0 +1,2 @@
+# This bbappend is used to alter the recipe using the test_recipe.inc file 
created by tests.
+include test_recipe.inc
diff --git a/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend 
b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
new file mode 100644
index 000..205720982cb
--- /dev/null
+++ b/meta-selftest/recipes-test/quilt-native/quilt-native_%.bbappend
@@ -0,0 +1,2 @@
+# This bbappend is used to alter the recipe using the test_recipe.inc file 
created by tests.
+include test_recipe.inc
diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index bdad9088d37..29e31f2ef9f 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -773,3 +773,107 @@ addtask tmptask2 before do_tmptask1
 latestfiles = sorted(filedates.keys(), key=lambda f: 
filedates[f])[-2:]
 bb.siggen.compare_sigfiles(latestfiles[-2], latestfiles[-1], 
recursecb)
 self.assertEqual(recursecb_count,1)
+
+class SStatePrintdiff(SStateBase):
+def run_test_printdiff_changerecipe(self, target, change_recipe, 
change_bbtask, change_content, expected_sametmp_output, 
expected_difftmp_output):
+self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-sstateprintdiff"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff")
+bitbake(target)
+bitbake("-S none {}".format(target))
+bitbake(change_bbtask)
+self.write_recipeinc(change_recipe, change_content)
+result_sametmp = bitbake("-S printdiff {}".format(target))
+
+self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-sstateprintdiff-2"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff-2")
+result_difftmp = bitbake("-S printdiff {}".format(target))
+
+self.delete_recipeinc(change_recipe)
+for item in expected_sametmp_output:
+self.assertIn(item, result_sametmp.output)
+for item in expected_difftmp_output:
+self.assertIn(item, result_difftmp.output)
+
+def run_test_printdiff_changeconfig(self, target, change_content, 
expected_sametmp_output, expected_difftmp_output):
+self.write_config("""
+TMPDIR = "${TOPDIR}/tmp-sstateprintdiff"
+""")
+self.track_for_cleanup(self.topdir + "/tmp-sstateprintdiff")
+bitbake(target)
+bitbake("-S none {}".format(target))
+self.append_config(change_content)
+result_sametmp = bitbake("-S printdiff

[OE-core] [PATCH 3/3] scripts/bitbake-whatchanged: remove

This is not documented or tested, and indeed hasn't been producing useful 
reports
for some time.

The script works by redirecting STAMPS_DIR into a separate location,
then running bitbake -S none, then comparing the two sets of stamp
filenames with regexes:

 Match the stamp's filename
 group(1): PE_PV (may no PE)
 group(2): PR
 group(3): TASK
 group(4): HASH
stamp_re = 
re.compile("(?P.*)-(?Pr\d+)\.(?Pdo_\w+)\.(?P[^\.]*)")

Then there's some code that finds out what changed in the above between the two 
sets.

Messing about with STAMPS_DIR like that isn't supported, and will either do 
nothing,
or remove the original stamps. Also stamp filenames aren't really a 'public 
API'.

For finding out the changes between two builds, 'bitbake -s printdiff' is a 
supported
and tested option. It may be a bit too verbose, but that can be more easily 
fixed than
rewriting bitbake-whatchanged into a working state.

Signed-off-by: Alexander Kanavin 
---
 scripts/bitbake-whatchanged | 318 
 1 file changed, 318 deletions(-)
 delete mode 100755 scripts/bitbake-whatchanged

diff --git a/scripts/bitbake-whatchanged b/scripts/bitbake-whatchanged
deleted file mode 100755
index cdb730dbdb9..000
--- a/scripts/bitbake-whatchanged
+++ /dev/null
@@ -1,318 +0,0 @@
-#!/usr/bin/env python3
-#
-# Copyright (c) 2013 Wind River Systems, Inc.
-#
-# SPDX-License-Identifier: GPL-2.0-only
-#
-
-import os
-import sys
-import getopt
-import shutil
-import re
-import warnings
-import subprocess
-import argparse
-
-scripts_path = os.path.abspath(os.path.dirname(os.path.abspath(sys.argv[0])))
-lib_path = scripts_path + '/lib'
-sys.path = sys.path + [lib_path]
-
-import scriptpath
-
-# Figure out where is the bitbake/lib/bb since we need bb.siggen and bb.process
-bitbakepath = scriptpath.add_bitbake_lib_path()
-if not bitbakepath:
-sys.stderr.write("Unable to find bitbake by searching parent directory of 
this script or PATH\n")
-sys.exit(1)
-scriptpath.add_oe_lib_path()
-import argparse_oe
-
-import bb.siggen
-import bb.process
-
-# Match the stamp's filename
-# group(1): PE_PV (may no PE)
-# group(2): PR
-# group(3): TASK
-# group(4): HASH
-stamp_re = 
re.compile("(?P.*)-(?Pr\d+)\.(?Pdo_\w+)\.(?P[^\.]*)")
-sigdata_re = re.compile(".*\.sigdata\..*")
-
-def gen_dict(stamps):
-"""
-Generate the dict from the stamps dir.
-The output dict format is:
-{fake_f: {pn: PN, pv: PV, pr: PR, task: TASK, path: PATH}}
-Where:
-fake_f: pv + task + hash
-path: the path to the stamp file
-"""
-# The member of the sub dict (A "path" will be appended below)
-sub_mem = ("pv", "pr", "task")
-d = {}
-for dirpath, _, files in os.walk(stamps):
-for f in files:
-# The "bitbake -S" would generate ".sigdata", but no "_setscene".
-fake_f = re.sub('_setscene.', '.', f)
-fake_f = re.sub('.sigdata', '', fake_f)
-subdict = {}
-tmp = stamp_re.match(fake_f)
-if tmp:
-for i in sub_mem:
-subdict[i] = tmp.group(i)
-if len(subdict) != 0:
-pn = os.path.basename(dirpath)
-subdict['pn'] = pn
-# The path will be used by os.stat() and bb.siggen
-subdict['path'] = dirpath + "/" + f
-fake_f = tmp.group('pv') + tmp.group('task') + 
tmp.group('hash')
-d[fake_f] = subdict
-return d
-
-# Re-construct the dict
-def recon_dict(dict_in):
-"""
-The output dict format is:
-{pn_task: {pv: PV, pr: PR, path: PATH}}
-"""
-dict_out = {}
-for k in dict_in.keys():
-subdict = {}
-# The key
-pn_task = "%s_%s" % (dict_in.get(k).get('pn'), 
dict_in.get(k).get('task'))
-# If more than one stamps are found, use the latest one.
-if pn_task in dict_out:
-full_path_pre = dict_out.get(pn_task).get('path')
-full_path_cur = dict_in.get(k).get('path')
-if os.stat(full_path_pre).st_mtime > 
os.stat(full_path_cur).st_mtime:
-continue
-subdict['pv'] = dict_in.get(k).get('pv')
-subdict['pr'] = dict_in.get(k).get('pr')
-subdict['path'] = dict_in.get(k).get('path')
-dict_out[pn_task] = subdict
-
-return dict_out
-
-def split_pntask(s):
-"""
-Split the pn_task in to (pn, task) and return it
-"""
-tmp = re.match("(.*)_(do_.*)", s)
-return (tmp.group(1), tmp.group(2))
-
-
-def print_added(d_new = None, d_old = None):
-"""
-Print the newly added tasks
-"""
-added = {}
-for k in list(d_new.keys()):
-if k not in d_old:
-# Add the new one to added dict, and remove it from
-# d_new, so the remaining ones are the changed ones
-added[k] = d_new.get(k)
-del(d_new[k])
-
-if not added:
-return 0
-
-# Format the output, the dict

[OE-core] [PATCH 1/3] lib/oe/sstatesig.py: dump locked.sigs.inc only when explicitly asked via -S lockedsigs

This was writing out locked-sigs.inc into cwd with every
'bitbake -S' invocation. When the intent is only to to get task
stamps (-S none), or print the difference between them (-S printdiff),
the file is unnecessary clutter.

A couple of selftests were however relying on this, so they're
adjusted to explicitly request the file.

eSDK code calls dump_lockedsigs() separately via
oe.copy_buildsystem.generate_locked_sigs() and so isn't affected.

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oe/sstatesig.py | 7 ---
 meta/lib/oeqa/selftest/cases/archiver.py | 2 +-
 meta/lib/oeqa/selftest/cases/signing.py  | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 5bf1697e727..63d792efe9d 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -142,9 +142,10 @@ class SignatureGeneratorOEBasicHashMixIn(object):
 super().set_taskdata(data[3:])
 
 def dump_sigs(self, dataCache, options):
-sigfile = os.getcwd() + "/locked-sigs.inc"
-bb.plain("Writing locked sigs to %s" % sigfile)
-self.dump_lockedsigs(sigfile)
+if 'lockedsigs' in options:
+sigfile = os.getcwd() + "/locked-sigs.inc"
+bb.plain("Writing locked sigs to %s" % sigfile)
+self.dump_lockedsigs(sigfile)
 return super(bb.siggen.SignatureGeneratorBasicHash, 
self).dump_sigs(dataCache, options)
 
 
diff --git a/meta/lib/oeqa/selftest/cases/archiver.py 
b/meta/lib/oeqa/selftest/cases/archiver.py
index 3fa59fff510..3cb888c5067 100644
--- a/meta/lib/oeqa/selftest/cases/archiver.py
+++ b/meta/lib/oeqa/selftest/cases/archiver.py
@@ -141,7 +141,7 @@ class Archiver(OESelftestTestCase):
 pn = 'gcc-source-%s' % get_bb_vars(['PV'], 'gcc')['PV']
 
 # Generate the tasks signatures
-bitbake('mc:mc1:%s mc:mc2:%s -c %s -S none' % (pn, pn, task))
+bitbake('mc:mc1:%s mc:mc2:%s -c %s -S lockedsigs' % (pn, pn, task))
 
 # Check the tasks signatures
 # To be machine agnostic the tasks needs to generate the same 
signature for each machine
diff --git a/meta/lib/oeqa/selftest/cases/signing.py 
b/meta/lib/oeqa/selftest/cases/signing.py
index 322e753ed3b..18cce0ba258 100644
--- a/meta/lib/oeqa/selftest/cases/signing.py
+++ b/meta/lib/oeqa/selftest/cases/signing.py
@@ -191,7 +191,7 @@ class LockedSignatures(OESelftestTestCase):
 
 bitbake(test_recipe)
 # Generate locked sigs include file
-bitbake('-S none %s' % test_recipe)
+bitbake('-S lockedsigs %s' % test_recipe)
 
 feature = 'require %s\n' % locked_sigs_file
 feature += 'SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn"\n'
-- 
2.39.2


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

[OE-Core][PATCH v2 2/4] selftest: recipetool: Add test for go recipe handler

From: Lukas Funke 

This commit adds a test for the go recipetool handler. The choosen go
project to test the created recipe was picked randomly. The SRC_URIs and
the LIC_FILES_CHKSUMs are checked against there reference values.

Signed-off-by: Lukas Funke 
---
 meta/lib/oeqa/selftest/cases/recipetool.py | 163 +
 1 file changed, 163 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 48661bee6f..6f3d5df50c 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -532,6 +532,169 @@ class RecipetoolTests(RecipetoolBase):
 libpath = os.path.join(get_bb_var('COREBASE'), 'scripts', 'lib', 
'recipetool')
 sys.path.insert(0, libpath)
 
+def test_recipetool_create_go(self):
+# Basic test to check go recipe generation
+def urifiy(url, version, modulepath = None, pathmajor = None, subdir = 
None):
+modulepath = ",path='%s'" % modulepath if len(modulepath) else ''
+pathmajor = ",pathmajor='%s'" % pathmajor if len(pathmajor) else ''
+subdir = ",subdir='%s'" % subdir if len(subdir) else ''
+return "${@go_src_uri('%s','%s'%s%s%s)}" % (url, version, 
modulepath, pathmajor, subdir)
+
+temprecipe = os.path.join(self.tempdir, 'recipe')
+os.makedirs(temprecipe)
+recipefile = os.path.join(temprecipe, 'edgex-go_git.bb')
+srcuri = 'https://github.com/edgexfoundry/edgex-go.git'
+srcrev = "v3.0.0"
+result = runCmd('recipetool create -o %s %s -S %s' % (temprecipe, 
srcuri, srcrev))
+self.assertTrue(os.path.isfile(recipefile))
+checkvars = {}
+src_uri = 
{'git://${GO_IMPORT};destsuffix=git/src/${GO_IMPORT};nobranch=1;name=${BPN};protocol=https',
+   'file://modules.txt'}
+checkvars['LIC_FILES_CHKSUM'] = set(
+
['file://src/${GO_IMPORT}/LICENSE;md5=8f8bc924cf73f6a32381e5fd4c58d603',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/Microsoft/go-winio/LICENSE;md5=69205ff73858f2c22b2ca135b557e8ef',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/armon/go-metrics/LICENSE;md5=d2d77030c0183e3d1e66d26dc1f243be',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/cenkalti/backoff/LICENSE;md5=1571d94433e3f3aa05267efd4dbea68b',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/davecgh/go-spew/LICENSE;md5=c06795ed54b2a35ebeeb543cd3a73e56',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/eclipse/paho.mqtt.golang/LICENSE;md5=dcdb33474b60c38efd27356d8f2edec7',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/eclipse/paho.mqtt.golang/edl-v10;md5=3adfcc70f5aeb7a44f3f9b495aa1fbf3',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-bootstrap/v3/LICENSE;md5=0d6dae39976133b2851fba4c1e1275ff',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-configuration/v3/LICENSE;md5=0d6dae39976133b2851fba4c1e1275ff',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-core-contracts/v3/LICENSE;md5=0d6dae39976133b2851fba4c1e1275ff',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-messaging/v3/LICENSE;md5=0d6dae39976133b2851fba4c1e1275ff',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-registry/v3/LICENSE;md5=0d6dae39976133b2851fba4c1e1275ff',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/edgexfoundry/go-mod-secrets/v3/LICENSE;md5=f9fa2f4f8e0ef8cc7b5dd150963eb457',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/fatih/color/LICENSE.md;md5=316e6d590bdcde7993fb175662c0dd5a',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/fxamacker/cbor/v2/LICENSE;md5=827f5a2fa861382d35a3943adf9ebb86',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-jose/go-jose/v3/LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-jose/go-jose/v3/json/LICENSE;md5=591778525c869cdde0ab5a1bf283cd81',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-kit/log/LICENSE;md5=5b7c15ad5fffe2ff6e9d58a6c161f082',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-logfmt/logfmt/LICENSE;md5=98e39517c38127f969de33057067091e',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-playground/locales/LICENSE;md5=3ccbda375ee345400ad1da85ba522301',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-playground/universal-translator/LICENSE;md5=2e2b21ef8f61057977d27c727c84bef1',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-playground/validator/v10/LICENSE;md5=a718a0f318d76f7c5d510cbae84f0b60',
+ 
'file://src/${GO_IMPORT}/vendor/github.com/go-redis/redis/v7/LICENSE;md5=58103aa5ea1ee9b7a369c9c4a95ef9b5',
+

[OE-Core][PATCH v2 4/4] recipetool: Add handler to create go recipes

From: Lukas Funke 

Signed-off-by: Lukas Funke 
---
 scripts/lib/recipetool/create_go.py | 730 
 1 file changed, 730 insertions(+)
 create mode 100644 scripts/lib/recipetool/create_go.py

diff --git a/scripts/lib/recipetool/create_go.py 
b/scripts/lib/recipetool/create_go.py
new file mode 100644
index 00..e0254f111b
--- /dev/null
+++ b/scripts/lib/recipetool/create_go.py
@@ -0,0 +1,730 @@
+# Recipe creation tool - go support plugin
+#
+# Copyright (C) 2023 Weidmueller GmbH & Co KG
+# Author: Lukas Funke 
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# Copyright (c) 2009 The Go Authors. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-3-Clause
+#
+
+
+from collections import namedtuple
+from enum import Enum
+from html.parser import HTMLParser
+from recipetool.create import RecipeHandler, handle_license_vars
+from recipetool.create import guess_license, tidy_licenses, fixup_license
+from urllib.error import URLError
+
+import bb.utils
+import json
+import logging
+import os
+import re
+import subprocess
+import sys
+import shutil
+import tempfile
+import urllib.parse
+import urllib.request
+
+
+GoImport = namedtuple('GoImport', 'root vcs url suffix')
+logger = logging.getLogger('recipetool')
+CodeRepo = namedtuple(
+'CodeRepo', 'path codeRoot codeDir pathMajor pathPrefix pseudoMajor')
+
+tinfoil = None
+
+# Regular expression to parse pseudo semantic version
+# see https://go.dev/ref/mod#pseudo-versions
+re_pseudo_semver = re.compile(
+
r"^v[0-9]+\.(0\.0-|\d+\.\d+-([^+]*\.)?0\.)(?P\d{14})-(?P[A-Za-z0-9]+)(\+[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*)?$")
+# Regular expression to parse semantic version
+re_semver = re.compile(
+
r"^v(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)\.(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$")
+
+
+def tinfoil_init(instance):
+global tinfoil
+tinfoil = instance
+
+
+class GoRecipeHandler(RecipeHandler):
+"""Class to handle the go recipe creation"""
+
+@staticmethod
+def __ensure_go():
+"""Check if the 'go' command is available in the recipes"""
+recipe = "go-native"
+if not tinfoil.recipes_parsed:
+tinfoil.parse_recipes()
+try:
+rd = tinfoil.parse_recipe(recipe)
+except bb.providers.NoProvider:
+bb.error(
+"Nothing provides '%s' which is required for the build" % 
(recipe))
+bb.note(
+"You will likely need to add a layer that provides '%s'" % 
(recipe))
+return None
+
+bindir = rd.getVar('STAGING_BINDIR_NATIVE')
+gopath = os.path.join(bindir, 'go')
+
+if not os.path.exists(gopath):
+tinfoil.build_targets(recipe, 'addto_recipe_sysroot')
+
+if not os.path.exists(gopath):
+logger.error(
+'%s required to process specified source, but %s did not 
seem to populate it' % 'go', recipe)
+return None
+
+return bindir
+
+def __resolve_repository_static(self, modulepath):
+"""Resolve the repository in a static manner
+
+The method is based on the go implementation of
+`repoRootFromVCSPaths` in
+
https://github.com/golang/go/blob/master/src/cmd/go/internal/vcs/vcs.go
+"""
+
+url = urllib.parse.urlparse("https://; + modulepath)
+req = urllib.request.Request(url.geturl())
+
+try:
+resp = urllib.request.urlopen(req)
+# Some modulepath are just redirects to github (or some other vcs
+# hoster). Therefore, we check if this modulepath redirects to
+# somewhere else
+if resp.geturl() != url.geturl():
+bb.debug(1, "%s is redirectred to %s" %
+ (url.geturl(), resp.geturl()))
+url = urllib.parse.urlparse(resp.geturl())
+modulepath = url.netloc + url.path
+
+except URLError as url_err:
+# This is probably because the module path
+# contains the subdir and major path. Thus,
+# we ignore this error for now
+logger.debug(
+1, "Failed to fetch page from [%s]: %s" % (url, str(url_err)))
+
+host, _, _ = modulepath.partition('/')
+
+class vcs(Enum):
+pathprefix = "pathprefix"
+regexp = "regexp"
+type = "type"
+repo = "repo"
+check = "check"
+schemelessRepo = "schemelessRepo"
+
+# GitHub
+vcsGitHub = {}
+vcsGitHub[vcs.pathprefix] = "github.com"
+vcsGitHub[vcs.regexp] = re.compile(
+
r'^(?Pgithub\.com/[A-Za-z0-9_.\-]+/[A-Za-z0-9_.\-]+)(/(?P[A-Za-z0-9_.\-]+))*$')
+vcsGitHub[vcs.type] = "git"
+vcsGitHub[vcs.repo] = "https://\\g"
+
+# Bitbucket
+vcsBitbucket = {}
+

[OE-Core][PATCH v2 1/4] classes: go-vendor: Add go-vendor class

From: Lukas Funke 

Signed-off-by: Lukas Funke 
---
 meta/classes/go-vendor.bbclass | 135 +
 1 file changed, 135 insertions(+)
 create mode 100644 meta/classes/go-vendor.bbclass

diff --git a/meta/classes/go-vendor.bbclass b/meta/classes/go-vendor.bbclass
new file mode 100644
index 00..13f1b8b2be
--- /dev/null
+++ b/meta/classes/go-vendor.bbclass
@@ -0,0 +1,135 @@
+#
+# Copyright 2023 (C) Weidmueller GmbH & Co KG
+# Author: Lukas Funke 
+#
+# Handle Go vendor support for offline builds
+#
+# When importing Go modules, Go downloads the imported module using
+# a network (proxy) connection ahead of the compile stage. This contradicts 
+# the yocto build concept of fetching every source ahead of build-time
+# and supporting offline builds.
+#
+# To support offline builds, we use Go 'vendoring': module dependencies are 
+# downloaded during the fetch-phase and unpacked into the modules 'vendor'
+# folder. Additinally a manifest file is generated for the 'vendor' folder
+# 
+
+inherit go-mod
+
+def go_src_uri(repo, version, path=None, subdir=None, \
+vcs='git', replaces=None, pathmajor=None):
+
+destsuffix = "git/src/import/vendor.fetch"
+go_module_path = repo if not path else path
+
+src_uri = "{}://{}" \
+  ";name={}" \
+  "".format(vcs, repo, \
+go_module_path.replace('/', '.'))
+
+src_uri += ";destsuffix={}/{}@{}".format(destsuffix, \
+go_module_path, \
+version)
+
+if vcs == "git":
+src_uri += ";nobranch=1;protocol=https"
+if replaces:
+src_uri += ";go_module_replacement={}".format(replaces)
+if subdir:
+src_uri += ";go_subdir={}".format(subdir)
+if pathmajor:
+src_uri += ";go_pathmajor={}".format(pathmajor)
+
+return src_uri
+
+
+python do_go_vendor() {
+import shutil
+
+src_uri = (d.getVar('SRC_URI') or "").split()
+
+if len(src_uri) == 0:
+bb.error("SRC_URI is empty")
+return
+
+default_destsuffix = "git/src/import/vendor.fetch"
+fetcher = bb.fetch2.Fetch(src_uri, d)
+go_import = d.getVar('GO_IMPORT')
+source_dir = d.getVar('S')
+
+vendor_dir = os.path.join(source_dir, *['src', go_import, 'vendor'])
+import_dir = os.path.join(source_dir, *['src', 'import', 'vendor.fetch'])
+
+bb.utils.mkdirhier(vendor_dir)
+modules = {}
+
+for url in fetcher.urls:
+srcuri = fetcher.ud[url].host + fetcher.ud[url].path
+
+# Skip main module for which the recipe is actually created
+if srcuri == go_import:
+continue
+
+# Skip local files
+if fetcher.ud[url].type == 'file':
+continue
+
+destsuffix = fetcher.ud[url].parm.get('destsuffix')
+# We derive the module path / version in the following manner 
(exmaple):
+# 
+# destsuffix = git/src/import/vendor.fetch/github.com/foo/bar@v1.2.3
+# p = github.com/foo/bar@v1.2.3
+# path = github.com/foo/bar
+# version = v1.2.3
+
+p = destsuffix[len(default_destsuffix)+1:]
+path, version = p.split('@')
+
+subdir = fetcher.ud[url].parm.get('go_subdir')
+subdir = "" if not subdir else subdir
+
+pathMajor = fetcher.ud[url].parm.get('go_pathmajor')
+pathMajor = "" if not pathMajor else pathMajor
+
+base = path[:-(len(subdir)+len(pathMajor))-1]
+r = fetcher.ud[url].parm.get('go_module_replacement')
+
+if not path in modules and not r:
+modules[path] =   {
+"version": version,
+"src": os.path.join(import_dir, *[p, subdir]),
+"subdir": subdir,
+"pathMajor": pathMajor,
+  }
+
+for module_key in sorted(modules):
+
+# only take the version which is explicitly listed
+# as a dependency in the go.mod
+module = modules[module_key]
+src = module['src']
+
+# If the module is released at major version 2 or higher, the module
+# path must end with a major version suffix like /v2.
+# This may or may not be part of the subdirectory name
+#
+# https://go.dev/ref/mod#modules-overview
+srcMajorVersion = os.path.join(src, module['pathMajor'].strip('/'))
+if os.path.exists(srcMajorVersion):
+src = srcMajorVersion
+dst = os.path.join(vendor_dir, module_key)
+if os.path.exists(dst):
+shutil.rmtree(dst)
+
+bb.debug(1, "cp %s --> %s" % (src, dst))
+shutil.copytree(src, dst, symlinks=True, \
+ignore=shutil.ignore_patterns(".git", \
+"vendor", \
+"*.md", \
+

[OE-Core][PATCH v2 0/4] recipetool: Add handler to create go recipes

From: Lukas Funke 

This patch series adds a recipetool handler in order to create 'go' recipes.
Each recipe contains a list of dependencies in their SRC_URI
variable which are derived from the projects `go.mod` file. For each
dependency the corresponding license file uri/hash is added.

The recipe may not work ad-hoc, but is a good starting point to create
a working recipe and have a working offline-build.

Lukas Funke (4):
  classes: go-vendor: Add go-vendor class
  selftest: recipetool: Add test for go recipe handler
  recipetool: Ignore *.go files while scanning for licenses
  recipetool: Add handler to create go recipes

 meta/classes/go-vendor.bbclass | 135 
 meta/lib/oeqa/selftest/cases/recipetool.py | 163 +
 scripts/lib/recipetool/create.py   |   2 +-
 scripts/lib/recipetool/create_go.py| 730 +
 4 files changed, 1029 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/go-vendor.bbclass
 create mode 100644 scripts/lib/recipetool/create_go.py

-- 
2.30.2


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

[OE-Core][PATCH v2 3/4] recipetool: Ignore *.go files while scanning for licenses

From: Lukas Funke 

Signed-off-by: Lukas Funke 
---
 scripts/lib/recipetool/create.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 143bc63e9d..293198d1c8 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -1212,7 +1212,7 @@ def guess_license(srctree, d):
 
 licenses = []
 licspecs = ['*LICEN[CS]E*', 'COPYING*', '*[Ll]icense*', 'LEGAL*', 
'[Ll]egal*', '*GPL*', 'README.lic*', 'COPYRIGHT*', '[Cc]opyright*', 
'e[dp]l-v10']
-skip_extensions = (".html", ".js", ".json", ".svg", ".ts")
+skip_extensions = (".html", ".js", ".json", ".svg", ".ts", ".go")
 licfiles = []
 for root, dirs, files in os.walk(srctree):
 for fn in files:
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189327): 
https://lists.openembedded.org/g/openembedded-core/message/189327
Mute This Topic: https://lists.openembedded.org/mt/102017389/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] patchtest: update SPDX identifiers

2023-10-17 Thread Trevor Gamblin

Replace full license headers with SPDX identifiers and adjust all
patchtest-related code to use GPL-2.0-only.

Signed-off-by: Trevor Gamblin 
---
 meta/lib/patchtest/data.py  | 15 +--
 meta/lib/patchtest/patch.py | 13 +
 meta/lib/patchtest/repo.py  | 12 +---
 meta/lib/patchtest/selftest/selftest|  2 +-
 meta/lib/patchtest/tests/base.py|  2 +-
 meta/lib/patchtest/tests/pyparsing/common.py|  2 +-
 .../patchtest/tests/pyparsing/parse_cve_tags.py |  2 +-
 .../patchtest/tests/pyparsing/parse_shortlog.py |  2 +-
 .../tests/pyparsing/parse_signed_off_by.py  |  2 +-
 .../tests/pyparsing/parse_upstream_status.py|  2 +-
 meta/lib/patchtest/tests/test_mbox_author.py|  2 +-
 meta/lib/patchtest/tests/test_mbox_bugzilla.py  |  2 +-
 meta/lib/patchtest/tests/test_mbox_cve.py   | 14 +-
 .../patchtest/tests/test_mbox_description.py|  2 +-
 meta/lib/patchtest/tests/test_mbox_format.py|  2 +-
 .../patchtest/tests/test_mbox_mailinglist.py|  2 +-
 meta/lib/patchtest/tests/test_mbox_merge.py |  2 +-
 meta/lib/patchtest/tests/test_mbox_shortlog.py  |  2 +-
 .../patchtest/tests/test_mbox_signed_off_by.py  |  2 +-
 .../tests/test_metadata_lic_files_chksum.py |  2 +-
 .../patchtest/tests/test_metadata_license.py|  2 +-
 .../patchtest/tests/test_metadata_max_length.py |  2 +-
 .../patchtest/tests/test_metadata_src_uri.py|  2 +-
 .../patchtest/tests/test_metadata_summary.py|  2 +-
 meta/lib/patchtest/tests/test_patch_cve.py  | 14 +-
 .../patchtest/tests/test_patch_signed_off_by.py |  2 +-
 .../tests/test_patch_upstream_status.py |  2 +-
 meta/lib/patchtest/tests/test_python_pylint.py  |  2 +-
 meta/lib/patchtest/utils.py | 12 +---
 scripts/patchtest   | 15 +--
 scripts/patchtest-get-branch| 12 +---
 scripts/patchtest-get-series| 12 +---
 scripts/patchtest-send-results  | 17 ++---
 scripts/patchtest-setup-sharedir| 14 +-
 34 files changed, 35 insertions(+), 161 deletions(-)

diff --git a/meta/lib/patchtest/data.py b/meta/lib/patchtest/data.py
index 12f36aa14d9..25a9a57dfb1 100644
--- a/meta/lib/patchtest/data.py
+++ b/meta/lib/patchtest/data.py
@@ -6,20 +6,7 @@
 #
 # Copyright (C) 2016 Intel Corporation
 #
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2 as
-# published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-#
-# Author: Leo Sandoval 
+# SPDX-License-Identifier: GPL-2.0-only
 #
 # NOTE: Strictly speaking, unit test should be isolated from outside,
 #   but patchtest test suites uses command line input data and
diff --git a/meta/lib/patchtest/patch.py b/meta/lib/patchtest/patch.py
index c0e7d579eba..baf62838730 100644
--- a/meta/lib/patchtest/patch.py
+++ b/meta/lib/patchtest/patch.py
@@ -5,18 +5,7 @@
 #
 # Copyright (C) 2016 Intel Corporation
 #
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2 as
-# published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+# SPDX-License-Identifier: GPL-2.0-only
 #
 
 import logging
diff --git a/meta/lib/patchtest/repo.py b/meta/lib/patchtest/repo.py
index 5c85c65ffb8..8a11af5fd66 100644
--- a/meta/lib/patchtest/repo.py
+++ b/meta/lib/patchtest/repo.py
@@ -5,18 +5,8 @@
 #
 # Copyright (C) 2016 Intel Corporation
 #
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2 as
-# published by the Free Software Foundation.
+# SPDX-License-Identifier: GPL-2.0-only
 #
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU

[OE-core] Dependency on packages

2023-10-17 Thread Vyacheslav Yurkov

Hey everyone.

As you know, DEPENDS operates on a recipe name basis, and RDEPENDS on a package 
name basis. I'm working on a dependency issue in meta-openembedded, where I 
need to indicate a package dependency during a build stage. Any advice how 
should I do it? (if any details necessary it's 
nativesdk-grpc/nativesdk-protobuf recipes)

Regards,
Slava

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

[OE-core] weston-init: how to debug with systemd

2023-10-17 Thread Sean Nyekjaer

Hi,

To my understanding the weston.service doesn’t log to journal. If I'm is 
running the weston binary there is fine output on stdout.

Looks like TTYPath is eating the logs, but I could be wrong.

Adding:
ExecStart=/usr/bin/weston --modules=systemd-notify.so --log=/tmp/weston.log

Will of course give logs in that file

/Sean
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189323): 
https://lists.openembedded.org/g/openembedded-core/message/189323
Mute This Topic: https://lists.openembedded.org/mt/102016986/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] why is it PROVIDES = "udev" and not PROVIDES = "virtual/udev"?

On Tue, 2023-10-17 at 02:30 -0400, Robert P. J. Day wrote:
> given that the PREFERRED_PROVIDER feature is typically used for 
> "virtual" entities:
> 
> * virtual/kernel
> * virtual/xserver
> * virtual/libgl
> 
> and so on, is there a reason that this pattern is not followed for the 
> selection
> of a udev provider, which is referred to as just 
> "PREFERRED_PROVIDER_udev", and
> can be provided by either of systemd or eudev?

udev was once a real recipe and still kind of is it just became eudev.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189322): 
https://lists.openembedded.org/g/openembedded-core/message/189322
Mute This Topic: https://lists.openembedded.org/mt/102012999/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] systemd: add p11kit package config

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd_254.4.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_254.4.bb 
b/meta/recipes-core/systemd/systemd_254.4.bb
index 578d3b463d..fc42787555 100644
--- a/meta/recipes-core/systemd/systemd_254.4.bb
+++ b/meta/recipes-core/systemd/systemd_254.4.bb
@@ -186,6 +186,7 @@ PACKAGECONFIG[oomd] = "-Doomd=true,-Doomd=false"
 PACKAGECONFIG[openssl] = "-Dopenssl=true,-Dopenssl=false,openssl"
 PACKAGECONFIG[pam] = "-Dpam=true,-Dpam=false,libpam,${PAM_PLUGINS}"
 PACKAGECONFIG[pcre2] = "-Dpcre2=true,-Dpcre2=false,libpcre2"
+PACKAGECONFIG[p11kit] = "-Dp11kit=true,-Dp11kit=false,p11-kit"
 PACKAGECONFIG[polkit] = "-Dpolkit=true,-Dpolkit=false"
 # If polkit is disabled and networkd+hostnamed are in use, enabling this 
option and
 # using dbus-broker will allow networkd to be authorized to change the
-- 
2.42.0


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

[OE-core][PATCH 3/4] systemd: add cryptsetup-plugins package config

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd_254.4.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/systemd/systemd_254.4.bb 
b/meta/recipes-core/systemd/systemd_254.4.bb
index 2146c130d5..578d3b463d 100644
--- a/meta/recipes-core/systemd/systemd_254.4.bb
+++ b/meta/recipes-core/systemd/systemd_254.4.bb
@@ -135,6 +135,7 @@ PACKAGECONFIG[bzip2] = "-Dbzip2=true,-Dbzip2=false,bzip2"
 PACKAGECONFIG[cgroupv2] = 
"-Ddefault-hierarchy=unified,-Ddefault-hierarchy=hybrid"
 PACKAGECONFIG[coredump] = "-Dcoredump=true,-Dcoredump=false"
 PACKAGECONFIG[cryptsetup] = 
"-Dlibcryptsetup=true,-Dlibcryptsetup=false,cryptsetup,,cryptsetup"
+PACKAGECONFIG[cryptsetup-plugins] = 
"-Dlibcryptsetup-plugins=true,-Dlibcryptsetup-plugins=false,cryptsetup,,cryptsetup"
 PACKAGECONFIG[tpm2] = "-Dtpm2=true,-Dtpm2=false,tpm2-tss,tpm2-tss libtss2 
libtss2-tcti-device"
 # If multiple compression libraries are enabled, the format to use for 
compression is chosen implicitly,
 # so if you want to compress with e.g. lz4 you cannot enable zstd, so you 
cannot read zstd-compressed journal files.
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189320): 
https://lists.openembedded.org/g/openembedded-core/message/189320
Mute This Topic: https://lists.openembedded.org/mt/102014260/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] systemd: sort packages before pn

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd_254.4.bb | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/recipes-core/systemd/systemd_254.4.bb 
b/meta/recipes-core/systemd/systemd_254.4.bb
index 77724eb822..d24bf0cb06 100644
--- a/meta/recipes-core/systemd/systemd_254.4.bb
+++ b/meta/recipes-core/systemd/systemd_254.4.bb
@@ -384,20 +384,20 @@ python populate_packages:prepend (){
 PACKAGES_DYNAMIC += "^lib(udev|systemd|nss).*"
 
 PACKAGE_BEFORE_PN = "\
-${PN}-gui \
-${PN}-vconsole-setup \
-${PN}-initramfs \
 ${PN}-analyze \
-${PN}-kernel-install \
-${PN}-rpm-macros \
 ${PN}-binfmt \
-${PN}-zsh-completion \
 ${PN}-container \
+${PN}-extra-utils \
+${PN}-gui \
+${PN}-initramfs \
 ${PN}-journal-gatewayd \
 ${PN}-journal-upload \
 ${PN}-journal-remote \
-${PN}-extra-utils \
+${PN}-kernel-install \
+${PN}-rpm-macros \
 ${PN}-udev-rules \
+${PN}-vconsole-setup \
+${PN}-zsh-completion \
 libsystemd-shared \
 udev \
 udev-hwdb \
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189318): 
https://lists.openembedded.org/g/openembedded-core/message/189318
Mute This Topic: https://lists.openembedded.org/mt/102014258/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] systemd: add systemd-crypt package

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd_254.4.bb | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_254.4.bb 
b/meta/recipes-core/systemd/systemd_254.4.bb
index d24bf0cb06..2146c130d5 100644
--- a/meta/recipes-core/systemd/systemd_254.4.bb
+++ b/meta/recipes-core/systemd/systemd_254.4.bb
@@ -387,6 +387,7 @@ PACKAGE_BEFORE_PN = "\
 ${PN}-analyze \
 ${PN}-binfmt \
 ${PN}-container \
+${PN}-crypt \
 ${PN}-extra-utils \
 ${PN}-gui \
 ${PN}-initramfs \
@@ -446,6 +447,11 @@ USERADD_PARAM:${PN}-journal-upload = "--system -d / -M 
--shell /sbin/nologin sys
 
 FILES:${PN}-analyze = "${bindir}/systemd-analyze"
 
+FILES:${PN}-crypt = "${bindir}/systemd-cryptenroll \
+ ${nonarch_libdir}/cryptsetup \
+"
+RRECOMMENDS:${PN} += "${PN}-crypt"
+
 FILES:${PN}-initramfs = "/init"
 RDEPENDS:${PN}-initramfs = "${PN}"
 
@@ -552,7 +558,6 @@ FILES:${PN}-extra-utils = "\
 ${bindir}/systemd-run \
 ${bindir}/systemd-cat \
 ${bindir}/systemd-creds \
-${bindir}/systemd-cryptenroll \
 ${bindir}/systemd-delta \
 ${bindir}/systemd-cgls \
 ${bindir}/systemd-cgtop \
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189319): 
https://lists.openembedded.org/g/openembedded-core/message/189319
Mute This Topic: https://lists.openembedded.org/mt/102014259/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] systemd: fix packaging tpm2 plugin for cryptsetup