[OE-core] [kirkstone][PATCH v4] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Abe Kohandel
Depending on the host gcc version, libdnf fails to compile due to
missing cstdint inclusions. These issue have already been addressed
upstream, add the patches to resolve this for older versions of the
library.

These commits are taken directly from the libdnf project at
https://github.com/rpm-software-management/libdnf

Signed-off-by: Abe Kohandel 
---
v4: add upstream commit URL for backport commit trailers
v3: add 2 more patches from upstream that were missed as I incorrectly
tested this by building libdnf instead of libdnf-native
v2: change Upstream status to Backport as upstream pull is already
merged
 ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
 ...onNumber.hpp-add-missing-cstdint-inc.patch | 33 +++
 ...ite3-Sqlite3.hpp-add-missing-cstdint.patch | 36 
 meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  3 +
 4 files changed, 128 insertions(+)
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch

diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
new file mode 100644
index 00..277fd9fbf6
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
@@ -0,0 +1,56 @@
+From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
+From: ctxnop 
+Date: Mon, 15 May 2023 19:30:16 +0200
+Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
+
+With last versions of gcc, some headers don't include cstdint anymore,
+but some sources assume that it is.
+
+Upstream-Status: Backport 
[https://github.com/rpm-software-management/libdnf/commit/779ea105564b6d717300af2fcb02a399737a536f]
+Signed-off-by: ctxnop 
+---
+ libdnf/conf/ConfigMain.hpp| 1 +
+ libdnf/conf/ConfigRepo.hpp| 1 +
+ libdnf/conf/OptionSeconds.hpp | 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
+index 19395c71..59f65c48 100644
+--- a/libdnf/conf/ConfigMain.hpp
 b/libdnf/conf/ConfigMain.hpp
+@@ -32,6 +32,7 @@
+ #include "OptionString.hpp"
+ #include "OptionStringList.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
+index 2b198441..84cafbad 100644
+--- a/libdnf/conf/ConfigRepo.hpp
 b/libdnf/conf/ConfigRepo.hpp
+@@ -26,6 +26,7 @@
+ #include "ConfigMain.hpp"
+ #include "OptionChild.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
+index dc714b23..a80a973f 100644
+--- a/libdnf/conf/OptionSeconds.hpp
 b/libdnf/conf/OptionSeconds.hpp
+@@ -25,6 +25,8 @@
+ 
+ #include "OptionNumber.hpp"
+ 
++#include 
++
+ namespace libdnf {
+ 
+ /**
+-- 
+2.42.0
+
diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
new file mode 100644
index 00..abb9504e6e
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
@@ -0,0 +1,33 @@
+From f8af6399c4f6a65a35d33ecc191bb14094dc9e18 Mon Sep 17 00:00:00 2001
+From: Sergei Trofimovich 
+Date: Fri, 27 May 2022 22:13:48 +0100
+Subject: [PATCH] libdnf/conf/OptionNumber.hpp: add missing  include
+
+Without the change libdnf build fails on this week's gcc-13 snapshot as:
+
+In file included from /build/libdnf/libdnf/conf/ConfigMain.hpp:29,
+ from /build/libdnf/libdnf/conf/ConfigMain.cpp:21:
+/build/libdnf/libdnf/conf/OptionNumber.hpp:94:41: error: 'int32_t' is not 
a member of 'std'; did you mean 'int32_t'?
+   94 | extern template class OptionNumber;
+  | ^~~
+
+Upstream-Status: Backport 
[https://github.com/rpm-software-management/libdnf/commit/f8af6399c4f6a65a35d33ecc191bb14094dc9e18]
+---
+ libdnf/conf/OptionNumber.hpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libdnf/conf/OptionNumber.hpp b/libdnf/conf/OptionNumber.hpp
+index f7a7b3d6..a3a4dea6 100644
+--- a/libdnf/conf/OptionNumber.hpp
 b/libdnf/conf/OptionNumber.hpp
+@@ -25,6 +25,7 @@
+ 
+ #include "Option.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+-- 
+2.42.0
+
diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
new file mode 100644
index 00..adde48ee46
--- /dev/null
+++ 

Re: [OE-core] [kirkstone][PATCH v3] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Khem Raj
On Sun, Aug 27, 2023 at 8:23 PM Abe Kohandel  wrote:
>
> Depending on the host gcc version, libdnf fails to compile due to
> missing cstdint inclusions. These issue have already been addressed
> upstream, add the patches to resolve this for older versions of the
> library.
>
> These commits are taken directly from the libdnf project at
> https://github.com/rpm-software-management/libdnf
>
> Signed-off-by: Abe Kohandel 
> ---
> v3: add 2 more patches from upstream that were missed as I incorrectly
> tested this by building libdnf instead of libdnf-native
> v2: change Upstream status to Backport as upstream pull is already
> merged
>  ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
>  ...onNumber.hpp-add-missing-cstdint-inc.patch | 33 +++
>  ...ite3-Sqlite3.hpp-add-missing-cstdint.patch | 36 
>  meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  3 +
>  4 files changed, 128 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
>  create mode 100644 
> meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
>  create mode 100644 
> meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
>
> diff --git 
> a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
>  
> b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> new file mode 100644
> index 00..788bdd1020
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> @@ -0,0 +1,56 @@
> +From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
> +From: ctxnop 
> +Date: Mon, 15 May 2023 19:30:16 +0200
> +Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
> +
> +With last versions of gcc, some headers don't include cstdint anymore,
> +but some sources assume that it is.
> +
> +Upstream-Status: Backport

Backport [URL to upstream commit]

this wlll make it easy for future porters when these patches have to
dropped on next version upgrade

> +Signed-off-by: ctxnop 
> +---
> + libdnf/conf/ConfigMain.hpp| 1 +
> + libdnf/conf/ConfigRepo.hpp| 1 +
> + libdnf/conf/OptionSeconds.hpp | 2 ++
> + 3 files changed, 4 insertions(+)
> +
> +diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
> +index 19395c71..59f65c48 100644
> +--- a/libdnf/conf/ConfigMain.hpp
>  b/libdnf/conf/ConfigMain.hpp
> +@@ -32,6 +32,7 @@
> + #include "OptionString.hpp"
> + #include "OptionStringList.hpp"
> +
> ++#include 
> + #include 
> +
> + namespace libdnf {
> +diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
> +index 2b198441..84cafbad 100644
> +--- a/libdnf/conf/ConfigRepo.hpp
>  b/libdnf/conf/ConfigRepo.hpp
> +@@ -26,6 +26,7 @@
> + #include "ConfigMain.hpp"
> + #include "OptionChild.hpp"
> +
> ++#include 
> + #include 
> +
> + namespace libdnf {
> +diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
> +index dc714b23..a80a973f 100644
> +--- a/libdnf/conf/OptionSeconds.hpp
>  b/libdnf/conf/OptionSeconds.hpp
> +@@ -25,6 +25,8 @@
> +
> + #include "OptionNumber.hpp"
> +
> ++#include 
> ++
> + namespace libdnf {
> +
> + /**
> +--
> +2.42.0
> +
> diff --git 
> a/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
>  
> b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
> new file mode 100644
> index 00..b5424b28ea
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
> @@ -0,0 +1,33 @@
> +From f8af6399c4f6a65a35d33ecc191bb14094dc9e18 Mon Sep 17 00:00:00 2001
> +From: Sergei Trofimovich 
> +Date: Fri, 27 May 2022 22:13:48 +0100
> +Subject: [PATCH] libdnf/conf/OptionNumber.hpp: add missing  include
> +
> +Without the change libdnf build fails on this week's gcc-13 snapshot as:
> +
> +In file included from /build/libdnf/libdnf/conf/ConfigMain.hpp:29,
> + from /build/libdnf/libdnf/conf/ConfigMain.cpp:21:
> +/build/libdnf/libdnf/conf/OptionNumber.hpp:94:41: error: 'int32_t' is 
> not a member of 'std'; did you mean 'int32_t'?
> +   94 | extern template class OptionNumber;
> +  | ^~~
> +
> +Upstream-Status: Backport
> +---
> + libdnf/conf/OptionNumber.hpp | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/libdnf/conf/OptionNumber.hpp b/libdnf/conf/OptionNumber.hpp
> +index f7a7b3d6..a3a4dea6 100644
> +--- a/libdnf/conf/OptionNumber.hpp
>  b/libdnf/conf/OptionNumber.hpp
> +@@ -25,6 +25,7 @@
> +
> + #include "Option.hpp"
> +
> ++#include 
> + #include 
> +
> + namespace libdnf {
> +--
> +2.42.0
> +
> diff --git 
> 

[OE-core] [kirkstone][PATCH v3] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Abe Kohandel
Depending on the host gcc version, libdnf fails to compile due to
missing cstdint inclusions. These issue have already been addressed
upstream, add the patches to resolve this for older versions of the
library.

These commits are taken directly from the libdnf project at
https://github.com/rpm-software-management/libdnf

Signed-off-by: Abe Kohandel 
---
v3: add 2 more patches from upstream that were missed as I incorrectly
tested this by building libdnf instead of libdnf-native
v2: change Upstream status to Backport as upstream pull is already
merged
 ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
 ...onNumber.hpp-add-missing-cstdint-inc.patch | 33 +++
 ...ite3-Sqlite3.hpp-add-missing-cstdint.patch | 36 
 meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  3 +
 4 files changed, 128 insertions(+)
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch

diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
new file mode 100644
index 00..788bdd1020
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
@@ -0,0 +1,56 @@
+From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
+From: ctxnop 
+Date: Mon, 15 May 2023 19:30:16 +0200
+Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
+
+With last versions of gcc, some headers don't include cstdint anymore,
+but some sources assume that it is.
+
+Upstream-Status: Backport
+Signed-off-by: ctxnop 
+---
+ libdnf/conf/ConfigMain.hpp| 1 +
+ libdnf/conf/ConfigRepo.hpp| 1 +
+ libdnf/conf/OptionSeconds.hpp | 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
+index 19395c71..59f65c48 100644
+--- a/libdnf/conf/ConfigMain.hpp
 b/libdnf/conf/ConfigMain.hpp
+@@ -32,6 +32,7 @@
+ #include "OptionString.hpp"
+ #include "OptionStringList.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
+index 2b198441..84cafbad 100644
+--- a/libdnf/conf/ConfigRepo.hpp
 b/libdnf/conf/ConfigRepo.hpp
+@@ -26,6 +26,7 @@
+ #include "ConfigMain.hpp"
+ #include "OptionChild.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
+index dc714b23..a80a973f 100644
+--- a/libdnf/conf/OptionSeconds.hpp
 b/libdnf/conf/OptionSeconds.hpp
+@@ -25,6 +25,8 @@
+ 
+ #include "OptionNumber.hpp"
+ 
++#include 
++
+ namespace libdnf {
+ 
+ /**
+-- 
+2.42.0
+
diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
new file mode 100644
index 00..b5424b28ea
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-conf-OptionNumber.hpp-add-missing-cstdint-inc.patch
@@ -0,0 +1,33 @@
+From f8af6399c4f6a65a35d33ecc191bb14094dc9e18 Mon Sep 17 00:00:00 2001
+From: Sergei Trofimovich 
+Date: Fri, 27 May 2022 22:13:48 +0100
+Subject: [PATCH] libdnf/conf/OptionNumber.hpp: add missing  include
+
+Without the change libdnf build fails on this week's gcc-13 snapshot as:
+
+In file included from /build/libdnf/libdnf/conf/ConfigMain.hpp:29,
+ from /build/libdnf/libdnf/conf/ConfigMain.cpp:21:
+/build/libdnf/libdnf/conf/OptionNumber.hpp:94:41: error: 'int32_t' is not 
a member of 'std'; did you mean 'int32_t'?
+   94 | extern template class OptionNumber;
+  | ^~~
+
+Upstream-Status: Backport
+---
+ libdnf/conf/OptionNumber.hpp | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/libdnf/conf/OptionNumber.hpp b/libdnf/conf/OptionNumber.hpp
+index f7a7b3d6..a3a4dea6 100644
+--- a/libdnf/conf/OptionNumber.hpp
 b/libdnf/conf/OptionNumber.hpp
+@@ -25,6 +25,7 @@
+ 
+ #include "Option.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+-- 
+2.42.0
+
diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
new file mode 100644
index 00..a75995b82e
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-libdnf-utils-sqlite3-Sqlite3.hpp-add-missing-cstdint.patch
@@ -0,0 +1,36 @@
+From 24b5d7f154cac9e322dd3459f6d0a5016a57 Mon Sep 17 00:00:00 2001
+From: Sergei Trofimovich 
+Date: Fri, 27 May 2022 22:12:07 +0100

Re: [OE-core] [kirkstone][PATCH] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Abe Kohandel
On 23/08/27 03:42PM, Khem Raj wrote:
> On Sun, Aug 27, 2023 at 3:12 PM Abe Kohandel  wrote:
> 
> > Depending on the host gcc version, libdnf fails to compile due to
> > missing cstdint inclusion. The issue has already been addressed
> > upstream, add the patch to resolve this for older versions of the
> > library.
> >
> > This commit is taken directly from the libdnf project at
> > https://github.com/rpm-software-management/libdnf
> >
> > Signed-off-by: Abe Kohandel 
> > ---
> >  ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
> >  meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  1 +
> >  2 files changed, 57 insertions(+)
> >  create mode 100644
> > meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> >
> > diff --git
> > a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> > b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> > new file mode 100644
> > index 00..51fa141f79
> > --- /dev/null
> > +++
> > b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> > @@ -0,0 +1,56 @@
> > +From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
> > +From: ctxnop 
> > +Date: Mon, 15 May 2023 19:30:16 +0200
> > +Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
> > +
> > +With last versions of gcc, some headers don't include cstdint anymore,
> > +but some sources assume that it is.
> > +
> > +Upstream-Status: Submitted [
> > https://github.com/rpm-software-management/libdnf/pull/1602]
> 
> 
> This pull is already merged at this time so status should be marked
> Backport
> 

My apologies, this is my first submission to this project, v2 submitted at
https://lists.openembedded.org/g/openembedded-core/message/186810

Thanks,
Abe

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186811): 
https://lists.openembedded.org/g/openembedded-core/message/186811
Mute This Topic: https://lists.openembedded.org/mt/100999045/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 v2] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Abe Kohandel
Depending on the host gcc version, libdnf fails to compile due to
missing cstdint inclusion. The issue has already been addressed
upstream, add the patch to resolve this for older versions of the
library.

This commit is taken directly from the libdnf project at
https://github.com/rpm-software-management/libdnf

Signed-off-by: Abe Kohandel 
---
v2: change Upstream status to Backport as upstream pull is already
merged

 ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
 meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch

diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
new file mode 100644
index 00..788bdd1020
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
@@ -0,0 +1,56 @@
+From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
+From: ctxnop 
+Date: Mon, 15 May 2023 19:30:16 +0200
+Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
+
+With last versions of gcc, some headers don't include cstdint anymore,
+but some sources assume that it is.
+
+Upstream-Status: Backport
+Signed-off-by: ctxnop 
+---
+ libdnf/conf/ConfigMain.hpp| 1 +
+ libdnf/conf/ConfigRepo.hpp| 1 +
+ libdnf/conf/OptionSeconds.hpp | 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
+index 19395c71..59f65c48 100644
+--- a/libdnf/conf/ConfigMain.hpp
 b/libdnf/conf/ConfigMain.hpp
+@@ -32,6 +32,7 @@
+ #include "OptionString.hpp"
+ #include "OptionStringList.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
+index 2b198441..84cafbad 100644
+--- a/libdnf/conf/ConfigRepo.hpp
 b/libdnf/conf/ConfigRepo.hpp
+@@ -26,6 +26,7 @@
+ #include "ConfigMain.hpp"
+ #include "OptionChild.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
+index dc714b23..a80a973f 100644
+--- a/libdnf/conf/OptionSeconds.hpp
 b/libdnf/conf/OptionSeconds.hpp
+@@ -25,6 +25,8 @@
+ 
+ #include "OptionNumber.hpp"
+ 
++#include 
++
+ namespace libdnf {
+ 
+ /**
+-- 
+2.42.0
+
diff --git a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb 
b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
index 2558f96851..9ed4108777 100644
--- a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
+++ b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/libdnf;branch=dnf-4-master;p
file://enable_test_data_dir_set.patch \
file://0001-drop-FindPythonInstDir.cmake.patch \

file://0001-libdnf-dnf-context.cpp-do-not-try-to-access-BDB-data.patch \
+   file://0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch \
"
 
 SRCREV = "add5d5418b140a86d08667dd2b14793093984875"
-- 
2.42.0


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



Re: [OE-core] [kirkstone][PATCH] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Khem Raj
On Sun, Aug 27, 2023 at 3:12 PM Abe Kohandel  wrote:

> Depending on the host gcc version, libdnf fails to compile due to
> missing cstdint inclusion. The issue has already been addressed
> upstream, add the patch to resolve this for older versions of the
> library.
>
> This commit is taken directly from the libdnf project at
> https://github.com/rpm-software-management/libdnf
>
> Signed-off-by: Abe Kohandel 
> ---
>  ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
>  meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  1 +
>  2 files changed, 57 insertions(+)
>  create mode 100644
> meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
>
> diff --git
> a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> new file mode 100644
> index 00..51fa141f79
> --- /dev/null
> +++
> b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
> @@ -0,0 +1,56 @@
> +From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
> +From: ctxnop 
> +Date: Mon, 15 May 2023 19:30:16 +0200
> +Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
> +
> +With last versions of gcc, some headers don't include cstdint anymore,
> +but some sources assume that it is.
> +
> +Upstream-Status: Submitted [
> https://github.com/rpm-software-management/libdnf/pull/1602]


This pull is already merged at this time so status should be marked
Backport


> +Signed-off-by: ctxnop 
> +---
> + libdnf/conf/ConfigMain.hpp| 1 +
> + libdnf/conf/ConfigRepo.hpp| 1 +
> + libdnf/conf/OptionSeconds.hpp | 2 ++
> + 3 files changed, 4 insertions(+)
> +
> +diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
> +index 19395c71..59f65c48 100644
> +--- a/libdnf/conf/ConfigMain.hpp
>  b/libdnf/conf/ConfigMain.hpp
> +@@ -32,6 +32,7 @@
> + #include "OptionString.hpp"
> + #include "OptionStringList.hpp"
> +
> ++#include 
> + #include 
> +
> + namespace libdnf {
> +diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
> +index 2b198441..84cafbad 100644
> +--- a/libdnf/conf/ConfigRepo.hpp
>  b/libdnf/conf/ConfigRepo.hpp
> +@@ -26,6 +26,7 @@
> + #include "ConfigMain.hpp"
> + #include "OptionChild.hpp"
> +
> ++#include 
> + #include 
> +
> + namespace libdnf {
> +diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
> +index dc714b23..a80a973f 100644
> +--- a/libdnf/conf/OptionSeconds.hpp
>  b/libdnf/conf/OptionSeconds.hpp
> +@@ -25,6 +25,8 @@
> +
> + #include "OptionNumber.hpp"
> +
> ++#include 
> ++
> + namespace libdnf {
> +
> + /**
> +--
> +2.42.0
> +
> diff --git a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
> b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
> index 2558f96851..9ed4108777 100644
> --- a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
> +++ b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
> @@ -11,6 +11,7 @@ SRC_URI = "git://
> github.com/rpm-software-management/libdnf;branch=dnf-4-master;p
> file://enable_test_data_dir_set.patch \
> file://0001-drop-FindPythonInstDir.cmake.patch \
>
> file://0001-libdnf-dnf-context.cpp-do-not-try-to-access-BDB-data.patch \
> +   file://0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch \
> "
>
>  SRCREV = "add5d5418b140a86d08667dd2b14793093984875"
> --
> 2.42.0
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186809): 
https://lists.openembedded.org/g/openembedded-core/message/186809
Mute This Topic: https://lists.openembedded.org/mt/100999045/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] libdnf: resolve cstdint inclusion for newer gcc versions

2023-08-27 Thread Abe Kohandel
Depending on the host gcc version, libdnf fails to compile due to
missing cstdint inclusion. The issue has already been addressed
upstream, add the patch to resolve this for older versions of the
library.

This commit is taken directly from the libdnf project at
https://github.com/rpm-software-management/libdnf

Signed-off-by: Abe Kohandel 
---
 ...58-Don-t-assume-inclusion-of-cstdint.patch | 56 +++
 meta/recipes-devtools/libdnf/libdnf_0.66.0.bb |  1 +
 2 files changed, 57 insertions(+)
 create mode 100644 
meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch

diff --git 
a/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
new file mode 100644
index 00..51fa141f79
--- /dev/null
+++ 
b/meta/recipes-devtools/libdnf/libdnf/0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch
@@ -0,0 +1,56 @@
+From 779ea105564b6d717300af2fcb02a399737a536f Mon Sep 17 00:00:00 2001
+From: ctxnop 
+Date: Mon, 15 May 2023 19:30:16 +0200
+Subject: [PATCH] Fix #1558: Don't assume inclusion of cstdint
+
+With last versions of gcc, some headers don't include cstdint anymore,
+but some sources assume that it is.
+
+Upstream-Status: Submitted 
[https://github.com/rpm-software-management/libdnf/pull/1602]
+Signed-off-by: ctxnop 
+---
+ libdnf/conf/ConfigMain.hpp| 1 +
+ libdnf/conf/ConfigRepo.hpp| 1 +
+ libdnf/conf/OptionSeconds.hpp | 2 ++
+ 3 files changed, 4 insertions(+)
+
+diff --git a/libdnf/conf/ConfigMain.hpp b/libdnf/conf/ConfigMain.hpp
+index 19395c71..59f65c48 100644
+--- a/libdnf/conf/ConfigMain.hpp
 b/libdnf/conf/ConfigMain.hpp
+@@ -32,6 +32,7 @@
+ #include "OptionString.hpp"
+ #include "OptionStringList.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/ConfigRepo.hpp b/libdnf/conf/ConfigRepo.hpp
+index 2b198441..84cafbad 100644
+--- a/libdnf/conf/ConfigRepo.hpp
 b/libdnf/conf/ConfigRepo.hpp
+@@ -26,6 +26,7 @@
+ #include "ConfigMain.hpp"
+ #include "OptionChild.hpp"
+ 
++#include 
+ #include 
+ 
+ namespace libdnf {
+diff --git a/libdnf/conf/OptionSeconds.hpp b/libdnf/conf/OptionSeconds.hpp
+index dc714b23..a80a973f 100644
+--- a/libdnf/conf/OptionSeconds.hpp
 b/libdnf/conf/OptionSeconds.hpp
+@@ -25,6 +25,8 @@
+ 
+ #include "OptionNumber.hpp"
+ 
++#include 
++
+ namespace libdnf {
+ 
+ /**
+-- 
+2.42.0
+
diff --git a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb 
b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
index 2558f96851..9ed4108777 100644
--- a/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
+++ b/meta/recipes-devtools/libdnf/libdnf_0.66.0.bb
@@ -11,6 +11,7 @@ SRC_URI = 
"git://github.com/rpm-software-management/libdnf;branch=dnf-4-master;p
file://enable_test_data_dir_set.patch \
file://0001-drop-FindPythonInstDir.cmake.patch \

file://0001-libdnf-dnf-context.cpp-do-not-try-to-access-BDB-data.patch \
+   file://0001-Fix-1558-Don-t-assume-inclusion-of-cstdint.patch \
"
 
 SRCREV = "add5d5418b140a86d08667dd2b14793093984875"
-- 
2.42.0


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



Re: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"

2023-08-27 Thread Peter Kjellerstedt
> -Original Message-
> From: Max Krummenacher 
> Sent: den 27 augusti 2023 10:10
> To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
> 
> Cc: Max Krummenacher ; Randolph Sapp
> 
> Subject: [oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the
> default dependencies"
> 
> From: Max Krummenacher 
> 
> Hi
> 
> With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
> dependencies") applied I'm getting a lot of these errors, i.e. qa
> does miss libc and compiler provided libs:
> 
> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found
> in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> /usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs
> requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in
> RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue:
> /usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-
> umlibs requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers
> found in RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
> 
> Reverting the commit makes the build pass, alternatively adding
> to depends in the recipe which is using the bin_package class
> fixes it too:
> 
> DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"
> 
> I'd prefer reverting removing the default dependencies over fixing
> each of the recipes which do use the bin_package class to actually
> install binaries running in the target user space.
> 
> Any opinions?

Bummer. I guess we will have to update our recipes individually 
instead. :(

> 
> Max
> 
> Max Krummenacher (1):
>   Revert "bin_package.bbclass: Inhibit the default dependencies"
> 
>  meta/classes-recipe/bin_package.bbclass | 3 ---
>  1 file changed, 3 deletions(-)
> 
> --
> 2.35.3

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186807): 
https://lists.openembedded.org/g/openembedded-core/message/186807
Mute This Topic: https://lists.openembedded.org/mt/100987453/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] [meta-oe][PATCH] volatile-binds: Calculate the name of the /var/lib service

2023-08-27 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Stéphane Veyret
> Sent: den 27 augusti 2023 18:49
> To: openembedded-core@lists.openembedded.org
> Cc: Stéphane Veyret 
> Subject: [OE-core] [meta-oe][PATCH] volatile-binds: Calculate the name of the 
> /var/lib service
> 
> By default, /var/lib is bind mounted on /var/volatile/lib. If this is
> the case, the recipe adds conditions on systemd-random-seed in the
> service file mounting it. But as the VOLATILE_BINDS may be modified,
> /var/lib may be mounted elsewhere, for example in /persistent/var/lib.
> In this case, the conditions are not set because the service file name
> does not match expected one.
> This patch automatically records the name of the service mounting
> /var/lib, if any, in order to set the condition in the appropriate file.
> 
> Signed-off-by: Stéphane Veyret 
> ---
>  meta/recipes-core/volatile-binds/volatile-binds.bb | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
> b/meta/recipes-core/volatile-binds/volatile-binds.bb
> index 3fefa9abde..7a3f53c3ed 100644
> --- a/meta/recipes-core/volatile-binds/volatile-binds.bb
> +++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
> @@ -48,6 +48,7 @@ do_compile () {
> 
>  servicefile="${spec#/}"
>  servicefile="$(echo "$servicefile" | tr / -).service"

Those two line can be simplified to:

servicefile="$(echo ${spec#/} | tr / -).service"

> +[ "${mountpoint}" = /var/lib ] && var_lib_servicefile=$servicefile

You should use "${localstatedir}/lib" instead of "/var/lib". Actually 
${localstatedir} should be used instead of /var throughout the recipe). 
It is also a good idea to avoid && in constructs like the one above 
due to how shell evaluates and sets the exit status. Also avoid ${...} 
for shell variables in bitbake recipes where possible as they will 
otherwise be included in the task hash. All taken together:

[ "$mountpoint" != ${localstatedir}/lib ] || 
var_lib_servicefile=$servicefile

>  sed -e "s#@what@#$spec#g; s#@where@#$mountpoint#g" \
>  -e "s#@whatparent@#${spec%/*}#g; 
> s#@whereparent@#${mountpoint%/*}#g" \
>  -e "s#@avoid_overlayfs@#${@d.getVar('AVOID_OVERLAYFS')}#g" \
> @@ -56,12 +57,12 @@ do_compile () {
>  ${@d.getVar('VOLATILE_BINDS').replace("\\n", "\n")}
>  END
> 
> -if [ -e var-volatile-lib.service ]; then
> +if [ -n ${var_lib_servicefile} ] && [ -e ${var_lib_servicefile} ]; then

Variables that may be empty shall always be quoted. And when they are, 
you do not need to test that they have a value before using the -e test:

if [ -e "$var_lib_servicefile" ]; then

>  # As the seed is stored under /var/lib, ensure that this service runs
>  # after the volatile /var/lib is mounted.
>  sed -i -e "/^Before=/s/\$/ systemd-random-seed.service/" \
> -e "/^WantedBy=/s/\$/ systemd-random-seed.service/" \
> -   var-volatile-lib.service
> +   ${var_lib_servicefile}

Here too:

   "$var_lib_servicefile"

>  fi
>  }
>  do_compile[dirs] = "${WORKDIR}"
> --
> 2.41.0

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186806): 
https://lists.openembedded.org/g/openembedded-core/message/186806
Mute This Topic: https://lists.openembedded.org/mt/100993882/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] core-image-ptest: Define a fallback for SUMMARY field

2023-08-27 Thread Khem Raj
Fixes errors like below seen with bitbake core-image-ptest-fast

WARNING: core-image-ptest-apr-util-1.0-r0 do_recipe_qa: QA Issue: Recipe 
core-image-ptest-apr-util in 
/mnt/b/yoe/master/sources/poky/meta/recipes-core/images/core-image-ptest.bb 
does not contain a SUMMARY. Please a
dd an entry. [missing-metadata]

Signed-off-by: Khem Raj 
---
 meta/recipes-core/images/core-image-ptest.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/images/core-image-ptest.bb 
b/meta/recipes-core/images/core-image-ptest.bb
index 12cb8c0fdf2..0fbfce24a5b 100644
--- a/meta/recipes-core/images/core-image-ptest.bb
+++ b/meta/recipes-core/images/core-image-ptest.bb
@@ -4,6 +4,7 @@ REQUIRED_DISTRO_FEATURES = "ptest"
 require conf/distro/include/ptest-packagelists.inc
 
 DESCRIPTION += "Also including the ${MCNAME} ptest package."
+SUMMARY ?= "${MCNAME} ptest image."
 HOMEPAGE = "https://www.yoctoproject.org/;
 
 PTESTS = "${PTESTS_SLOW} ${PTESTS_FAST}"
-- 
2.42.0


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



[OE-core][kirkstone 8/8] python3-git: upgrade 3.1.27 -> 3.1.32

2023-08-27 Thread Steve Sakoman
From: Narpat Mali 

The delta between 3.1.27 & 3.1.32 contains the CVE-2022-24439 &
CVE-2023-40267 fixes and other bugfixes.

Changelog:
https://github.com/gitpython-developers/GitPython/releases/tag/3.1.32
https://gitpython.readthedocs.io/en/stable/changes.html#id5

- Bump cygwin/cygwin-install-action from 3 to 4 by @dependabot in #1572
- Fix up the commit trailers functionality by @itsluketwist in #1576
- Name top-level exceptions as private variables by @Hawk777 in #1590
- fix pypi long description by @eUgEntOptIc44 in #1603
- Don't rely on del by @r-darwish in #1606
- Block insecure non-multi options in clone/clone_from by @Beuc in #1609
- Fix Sphinx rendering errors by @stephan-cr in #1524
- tests: Use command -v instead of third-party which program by @mgorny in #1525
- fix/add allow_unsafe_* params in docstrings + fix typo by @obfusk in #1530
- use tempfile.TemporaryDirectory & fix clone_from_unsafe_protocol tests by 
@obfusk in #1531
- Fix some resource leaks by open file handles by @marlamb in #1532
- fix files list on file rename by @teknoraver in #1537
- Declare support for Python 3.11 by @hugovk in #1541
- Fix ignored by @Lightborne in #1545
- Fix timezone parsing functions for non-hour timezones by @jcowgill in #1547
- Enable user to override default diff -M arg by @mellowed100 in #1551
- Remove optional from two member variables by @Sineaggi in #1550
- Fix RecursionError when iterating streams by @eric-wieser in #1554
- Fix get_values() so it correctly loads section names by @Codym48 in #1555
- Add datetime.datetime type to commit_date and author_date by 
@SergeantMenacingGarlic in #1501
- Bump cygwin/cygwin-install-action from 2 to 3 by @dependabot in #1514
- Fix command injection by @stsewd in #1518
- Document PushInfoList by @skinitimski in #1522
- Fix type hint on create_tag by @drewcassidy in #1523
- Block insecure options and protocols by default by @stsewd in #1521
- Make the git.__version__ re-appear.

Signed-off-by: Narpat Mali 
Signed-off-by: Steve Sakoman 
---
 ...-git-CVE-2022-24439-fix-from-PR-1518.patch |  97 
 ...-git-CVE-2022-24439-fix-from-PR-1521.patch | 488 --
 ...n3-git_3.1.27.bb => python3-git_3.1.32.bb} |   6 +-
 3 files changed, 1 insertion(+), 590 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1521.patch
 rename meta/recipes-devtools/python/{python3-git_3.1.27.bb => 
python3-git_3.1.32.bb} (80%)

diff --git 
a/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 
b/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
deleted file mode 100644
index 16192b22c7..00
--- 
a/meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
+++ /dev/null
@@ -1,97 +0,0 @@
-From 6ebe9231cd34dacd32a964859bc509aaa1e3f5fd Mon Sep 17 00:00:00 2001
-From: Narpat Mali 
-Date: Fri, 6 Jan 2023 14:13:10 +
-Subject: [PATCH] python3-git: CVE-2022-24439 fix from PR 1518
-
-Fix command injection
-Add `--` in some commands that receive user input
-and if interpreted as options could lead to remote
-code execution (RCE).
-
-There may be more commands that could benefit from `--`
-so the input is never interpreted as an option,
-but most of those aren't dangerous.
-
-Fixed commands:
-
-- push
-- pull
-- fetch
-- clone/clone_from and friends
-- archive (not sure if this one can be exploited, but it doesn't hurt
-  adding `--` :))
-
-For anyone using GitPython and exposing any of the GitPython methods to users,
-make sure to always validate the input (like if starts with `--`).
-And for anyone allowing users to pass arbitrary options, be aware
-that some options may lead fo RCE, like `--exc`, `--upload-pack`,
-`--receive-pack`, `--config` (#1516).
-
-Ref #1517
-
-CVE: CVE-2022-24439
-
-Upstream-Status: Backport 
[https://github.com/gitpython-developers/GitPython/pull/1518]
-
-Signed-off-by: Narpat Mali 

- git/remote.py| 6 +++---
- git/repo/base.py | 4 ++--
- 2 files changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/git/remote.py b/git/remote.py
-index 56f3c5b..59681bc 100644
 a/git/remote.py
-+++ b/git/remote.py
-@@ -881,7 +881,7 @@ class Remote(LazyMixin, IterableObj):
- else:
- args = [refspec]
- 
--proc = self.repo.git.fetch(self, *args, as_process=True, 
with_stdout=False,
-+proc = self.repo.git.fetch("--", self, *args, as_process=True, 
with_stdout=False,
-universal_newlines=True, v=verbose, 
**kwargs)
- res = self._get_fetch_info_from_stderr(proc, progress,
-
kill_after_timeout=kill_after_timeout)
-@@ -905,7 +905,7 @@ class Remote(LazyMixin, IterableObj):
- # No argument refspec, then ensure the 

[OE-core][kirkstone 7/8] linux/cve-exclusion: remove obsolete manual entries

2023-08-27 Thread Steve Sakoman
From: Ross Burton 

The generated file covers all but one of these CVEs (which will be fixed
when [1] is resolved) so remove the redundant entries.

[1] https://github.com/nluedtke/linux_kernel_cves/issues/344

Signed-off-by: Ross Burton 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-kernel/linux/cve-exclusion.inc | 869 
 1 file changed, 869 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion.inc 
b/meta/recipes-kernel/linux/cve-exclusion.inc
index 45b7a3dffe..c34928e100 100644
--- a/meta/recipes-kernel/linux/cve-exclusion.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion.inc
@@ -1,875 +1,6 @@
-# Kernel CVE exclusion file
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-3759
-# Patched in kernel since v5.15 18319498fdd4cdf8c1c2c48cd432863b1f915d6f
-# Backported in version v5.4.224 bad83d55134e647a739ebef2082541963f2cbc92
-# Backported in version v5.10.154 836686e1a01d7e2fda6a5a18252243ff30a6e196
-CVE_CHECK_IGNORE += "CVE-2021-3759"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-4135
-# Patched in kernel since v5.16 481221775d53d6215a6e5e9ce1cce6d2b4ab9a46
-# Backported in version v5.4.168 699e794c12a3cd79045ff135bc87a53b97024e43
-# Backported in version v5.10.88 1a34fb9e2bf3029f7c0882069d67ff69cbd645d8
-# Backported in version v5.15.11 27358aa81a7d60e6bd36f0bb1db65cd084c2cad0
-CVE_CHECK_IGNORE += "CVE-2021-4135"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2021-4155
-# Patched in kernel since v5.16 983d8e60f50806f90534cc5373d0ce867e5aaf79
-# Backported in version v5.4.171 102af6edfd3a372db6e229177762a91f552e5f5e
-# Backported in version v5.10.91 16d8568378f9ee2d1e69216d39961aa72710209f
-# Backported in version v5.15.14 b0e72ba9e520b95346e68800afff0db65e766ca8
-CVE_CHECK_IGNORE += "CVE-2021-4155"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-0168
-# Patched in kernel since v5.18 b92e358757b91c2827af112cae9af513f26a3f34
-# Backported in version v5.10.110 9963ccea6087268e1275b992dca5d0dd4b938765
-# Backported in version v5.15.33 f143f8334fb9eb2f6c7c15b9da1472d9c965fd84
-CVE_CHECK_IGNORE += "CVE-2022-0168"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-0171
-# Patched in kernel since v5.18 683412ccf61294d727ead4a73d97397396e69a6b
-# Backported in version v5.10.146 a60babeb60ff276963d4756c7fd2e7bf242bb777
-# Backported in version v5.15.70 39b0235284c7aa33a64e07b825add7a2c108094a
-CVE_CHECK_IGNORE += "CVE-2022-0171"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1016
-# Patched in kernel since v5.18 4c905f6740a365464e91467aa50916555b28213d
-# Backported in version v5.4.188 06f0ff82c70241a766a811ae1acf07d6e2734dcb
-# Backported in version v5.10.109 2c74374c2e88c7b7992bf808d9f9391f7452f9d9
-# Backported in version v5.15.32 fafb904156fbb8f1dd34970cd5223e00b47c33be
-CVE_CHECK_IGNORE += "CVE-2022-1016"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1184
-# Patched in kernel since v6.1 61a1d87a324ad5e3ed27c6699dfc93218fcf3201
-# Backported in version v5.10.150 483831ad0440f62c10d1707c97ce824bd82d98ae
-# Backported in version v5.15.75 dd366295d1eca557e7a9000407ec3952f691d27b
-# Backported in version v5.19.17 edb71f055684f9023fd97e2f85c6f31380d163c1
-CVE_CHECK_IGNORE += "CVE-2022-1184"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1198
-# Patched in kernel since v5.17 efe4186e6a1b54bf38b9e05450d43b0da1fd7739
-# Backported in version v5.4.189 28c8fd84bea13cbf238d7b19d392de2fcc31331c
-# Backported in version v5.10.110 f67a1400788f550d201c71aeaf56706afe57f0da
-# Backported in version v5.15.33 3eb18f8a1d02a9462a0e4903efc674ca3d0406d1
-CVE_CHECK_IGNORE += "CVE-2022-1198"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1199
-# Patched in kernel since v5.17 71171ac8eb34ce7fe6b3267dce27c313ab3cb3ac
-# Backported in version v5.4.185 0a64aea5fe023cf1e4973676b11f49038b1f045b
-# Backported in version v5.10.106 e2201ef32f933944ee02e59205adb566bafcdf91
-# Backported in version v5.15.29 46ad629e58ce3a88c924ff3c5a7e9129b0df5659
-CVE_CHECK_IGNORE += "CVE-2022-1199"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1462
-# Patched in kernel since v5.19 a501ab75e7624d133a5a3c7ec010687c8b961d23
-# Backported in version v5.4.208 f7785092cb7f022f59ebdaa181651f7c877df132
-# Backported in version v5.10.134 08afa87f58d83dfe040572ed591b47e8cb9e225c
-# Backported in version v5.15.58 b2d1e4cd558cffec6bfe318f5d74e6cffc374d29
-CVE_CHECK_IGNORE += "CVE-2022-1462"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1734
-# Patched in kernel since v5.18 d270453a0d9ec10bb8a802a142fb1b3601a83098
-# Backported in version v5.4.193 33d3e76fc7a7037f402246c824d750542e2eb37f
-# Backported in version v5.10.115 1961c5a688edb53fe3bc25cbda57f47adf12563c
-# Backported in version v5.15.39 b8f2b836e7d0a553b886654e8b3925a85862d2eb
-CVE_CHECK_IGNORE += "CVE-2022-1734"
-
-# https://nvd.nist.gov/vuln/detail/CVE-2022-1852
-# Patched in kernel since v5.19 fee060cd52d69c114b62d1a2948ea9648b5131f9
-# Backported in version v5.10.120 3d8fc6e28f321d753ab727e3c3e740daf36a8fa3
-# Backported in version v5.15.45 531d1070d864c78283b7597449e60ddc53319d88

[OE-core][kirkstone 3/8] Qemu: Resolve undefined reference issue in CVE-2023-2861

2023-08-27 Thread Steve Sakoman
From: Siddharth 

The commit 
[https://github.com/openembedded/openembedded-core/commit/9bd4ddeb4b5efc65b0514d50d6991211271924c1]
 backports fix for CVE-2023-2861 for version 6.2.0.
The 'qemu_fstat' in `do_create_others' is not defined which leads to the 
undefined symbol error on certain architectures.

Also, the commit message says "(Mjt: drop adding qemu_fstat wrapper for 7.2 
where wrappers aren't used)". So either the wrapper has to be dropped or it has 
to be defined.

Hence, backported the main patch rather than the cherry picked one.

Signed-off-by: Siddharth Doshi 
Signed-off-by: Steve Sakoman 
---
 .../qemu/qemu/CVE-2023-2861.patch | 66 +++
 1 file changed, 37 insertions(+), 29 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
index 48f51f5d03..a86413fbad 100644
--- a/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-2861.patch
@@ -1,14 +1,16 @@
-From 10fad73a2bf1c76c8aa9d6322755e5f877d83ce5 Mon Sep 17 00:00:00 2001
+From f6b0de53fb87ddefed348a39284c8e2f28dc4eda Mon Sep 17 00:00:00 2001
 From: Christian Schoenebeck 
-Date: Wed Jun 7 18:29:33 2023 +0200
-Subject: [PATCH] 9pfs: prevent opening special files (CVE-2023-2861) The 9p
- protocol does not specifically define how server shall behave when client
- tries to open a special file, however from security POV it does make sense
- for 9p server to prohibit opening any special file on host side in general. A
- sane Linux 9p client for instance would never attempt to open a special file
- on host side, it would always handle those exclusively on its guest side. A
- malicious client however could potentially escape from the exported 9p tree
- by creating and opening a device file on host side.
+Date: Wed, 7 Jun 2023 18:29:33 +0200
+Subject: [PATCH] 9pfs: prevent opening special files (CVE-2023-2861)
+
+The 9p protocol does not specifically define how server shall behave when
+client tries to open a special file, however from security POV it does
+make sense for 9p server to prohibit opening any special file on host side
+in general. A sane Linux 9p client for instance would never attempt to
+open a special file on host side, it would always handle those exclusively
+on its guest side. A malicious client however could potentially escape
+from the exported 9p tree by creating and opening a device file on host
+side.
 
 With QEMU this could only be exploited in the following unsafe setups:
 
@@ -32,19 +34,16 @@ Signed-off-by: Christian Schoenebeck 

 Reviewed-by: Greg Kurz 
 Reviewed-by: Michael Tokarev 
 Message-Id: 
-(cherry picked from commit f6b0de5)
-Signed-off-by: Michael Tokarev 
-(Mjt: drop adding qemu_fstat wrapper for 7.2 where wrappers aren't used)
-
-Upstream-Status: Backport 
[https://github.com/qemu/qemu/commit/10fad73a2bf1c76c8aa9d6322755e5f877d83ce5]
 
+Upstream-Status: Backport from 
[https://github.com/qemu/qemu/commit/10fad73a2bf1c76c8aa9d6322755e5f877d83ce5]
 CVE: CVE-2023-2861
 
 Signed-off-by: Archana Polampalli 
+Signed-off-by: Siddharth Doshi 
 ---
- fsdev/virtfs-proxy-helper.c | 27 --
- hw/9pfs/9p-util.h   | 38 +
- 2 files changed, 63 insertions(+), 2 deletions(-)
+ fsdev/virtfs-proxy-helper.c | 27 +++--
+ hw/9pfs/9p-util.h   | 40 +
+ 2 files changed, 65 insertions(+), 2 deletions(-)
 
 diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
 index 15c0e79b0..f9e4669a5 100644
@@ -56,12 +55,12 @@ index 15c0e79b0..f9e4669a5 100644
  #include "hw/9pfs/9p-proxy.h"
 +#include "hw/9pfs/9p-util.h"
  #include "fsdev/9p-iov-marshal.h"
-
+ 
  #define PROGNAME "virtfs-proxy-helper"
 @@ -338,6 +339,28 @@ static void resetugid(int suid, int sgid)
  }
  }
-
+ 
 +/*
 + * Open regular file or directory. Attempts to open any special file are
 + * rejected.
@@ -106,22 +105,30 @@ index 15c0e79b0..f9e4669a5 100644
  ret = -errno;
  }
 diff --git a/hw/9pfs/9p-util.h b/hw/9pfs/9p-util.h
-index 546f46dc7..54e270ac6 100644
+index 546f46dc7..23000e917 100644
 --- a/hw/9pfs/9p-util.h
 +++ b/hw/9pfs/9p-util.h
-@@ -13,6 +13,8 @@
+@@ -13,12 +13,16 @@
  #ifndef QEMU_9P_UTIL_H
  #define QEMU_9P_UTIL_H
-
+ 
 +#include "qemu/error-report.h"
 +
  #ifdef O_PATH
  #define O_PATH_9P_UTIL O_PATH
  #else
-@@ -26,6 +28,38 @@ static inline void close_preserve_errno(int fd)
+ #define O_PATH_9P_UTIL 0
+ #endif
+ 
++#define qemu_fstat  fstat
++
+ static inline void close_preserve_errno(int fd)
+ {
+ int serrno = errno;
+@@ -26,6 +30,38 @@ static inline void close_preserve_errno(int fd)
  errno = serrno;
  }
-
+ 
 +/**
 + * close_if_special_file() - Close @fd if neither regular file nor directory.
 + *
@@ -157,10 +164,10 @@ index 546f46dc7..54e270ac6 100644
  static inline int openat_dir(int dirfd, const char *name)
  {
  return 

[OE-core][kirkstone 5/8] linux-yocto: add script to generate kernel CVE_CHECK_IGNORE entries

2023-08-27 Thread Steve Sakoman
From: Ross Burton 

Instead of manually looking up new CVEs and determining what point
releases the fixes are incorporated into, add a script to generate the
CVE_CHECK_IGNORE data automatically.

First, note that this is very much an interim solution until the
cve-check class fetches data from www.linuxkernelcves.com directly.

The script should be passed the path to a local clone of the
linuxkernelcves repository[1] and the kernel version number. It will
then write to standard output the CVE_STATUS entries for every known
kernel CVE.

The script should be periodically reran as CVEs are backported and
kernels upgraded frequently.

[1] https://github.com/nluedtke/linux_kernel_cves

Note: for the backport this is not a cherry-pick of the commit in master
as the variable names are different. This incorporates the following
commits:

linux/generate-cve-exclusions: add version check warning
linux/generate-cve-exclusions.py: fix comparison
linux-yocto: add script to generate kernel CVE_STATUS entries

Signed-off-by: Ross Burton 
Signed-off-by: Steve Sakoman 
---
 .../linux/generate-cve-exclusions.py  | 101 ++
 1 file changed, 101 insertions(+)
 create mode 100755 meta/recipes-kernel/linux/generate-cve-exclusions.py

diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py 
b/meta/recipes-kernel/linux/generate-cve-exclusions.py
new file mode 100755
index 00..b9b87f245d
--- /dev/null
+++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py
@@ -0,0 +1,101 @@
+#! /usr/bin/env python3
+
+# Generate granular CVE status metadata for a specific version of the kernel
+# using data from linuxkernelcves.com.
+#
+# SPDX-License-Identifier: GPL-2.0-only
+
+import argparse
+import datetime
+import json
+import pathlib
+import re
+
+from packaging.version import Version
+
+
+def parse_version(s):
+"""
+Parse the version string and either return a packaging.version.Version, or
+None if the string was unset or "unk".
+"""
+if s and s != "unk":
+# packaging.version.Version doesn't approve of versions like 
v5.12-rc1-dontuse
+s = s.replace("-dontuse", "")
+return Version(s)
+return None
+
+
+def main(argp=None):
+parser = argparse.ArgumentParser()
+parser.add_argument("datadir", type=pathlib.Path, help="Path to a clone of 
https://github.com/nluedtke/linux_kernel_cves;)
+parser.add_argument("version", type=Version, help="Kernel version number 
to generate data for, such as 6.1.38")
+
+args = parser.parse_args(argp)
+datadir = args.datadir
+version = args.version
+base_version = f"{version.major}.{version.minor}"
+
+with open(datadir / "data" / "kernel_cves.json", "r") as f:
+cve_data = json.load(f)
+
+with open(datadir / "data" / "stream_fixes.json", "r") as f:
+stream_data = json.load(f)
+
+print(f"""
+# Auto-generated CVE metadata, DO NOT EDIT BY HAND.
+# Generated at {datetime.datetime.now()} for version {version}
+
+python check_kernel_cve_status_version() {{
+this_version = "{version}"
+kernel_version = d.getVar("LINUX_VERSION")
+if kernel_version != this_version:
+bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
+}}
+do_cve_check[prefuncs] += "check_kernel_cve_status_version"
+""")
+
+for cve, data in cve_data.items():
+if "affected_versions" not in data:
+print(f"# Skipping {cve}, no affected_versions")
+print()
+continue
+
+affected = data["affected_versions"]
+first_affected, last_affected = re.search(r"(.+) to (.+)", 
affected).groups()
+first_affected = parse_version(first_affected)
+last_affected = parse_version(last_affected)
+
+handled = False
+if not last_affected:
+print(f"# {cve} has no known resolution")
+elif first_affected and version < first_affected:
+print(f"# fixed-version: only affects {first_affected} onwards")
+handled = True
+elif last_affected < version:
+print(f"# fixed-version: Fixed after version {last_affected}")
+handled = True
+else:
+if cve in stream_data:
+backport_data = stream_data[cve]
+if base_version in backport_data:
+backport_ver = 
Version(backport_data[base_version]["fixed_version"])
+if backport_ver <= version:
+print(f"# cpe-stable-backport: Backported in 
{backport_ver}")
+handled = True
+else:
+# TODO print a note that the kernel needs bumping
+print(f"# {cve} needs backporting (fixed from 
{backport_ver})")
+else:
+print(f"# {cve} needs backporting (fixed from 
{last_affected})")
+else:
+print(f"# {cve} needs 

[OE-core][kirkstone 4/8] nghttp2: fix CVE-2023-35945

2023-08-27 Thread Steve Sakoman
From: Yogita Urade 

Envoy is a cloud-native high-performance edge/middle/service
proxy. Envoy’s HTTP/2 codec may leak a header map and
bookkeeping structures upon receiving `RST_STREAM` immediately
followed by the `GOAWAY` frames from an upstream server. In
nghttp2, cleanup of pending requests due to receipt of the
`GOAWAY` frame skips de-allocation of the bookkeeping structure
and pending compressed header. The error return [code path] is
taken if connection is already marked for not sending more
requests due to `GOAWAY` frame. The clean-up code is right after
the return statement, causing memory leak. Denial of service
through memory exhaustion. This vulnerability was patched in
versions(s) 1.26.3, 1.25.8, 1.24.9, 1.23.11.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-35945
https://github.com/envoyproxy/envoy/security/advisories/GHSA-jfxv-29pc-x22r

Signed-off-by: Yogita Urade 
Signed-off-by: Steve Sakoman 
---
 .../nghttp2/nghttp2/CVE-2023-35945.patch  | 151 ++
 .../recipes-support/nghttp2/nghttp2_1.47.0.bb |   1 +
 2 files changed, 152 insertions(+)
 create mode 100644 meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch

diff --git a/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch 
b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch
new file mode 100644
index 00..e03915fda8
--- /dev/null
+++ b/meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch
@@ -0,0 +1,151 @@
+From ce385d3f55a4b76da976b3bdf71fe2deddf315ba Mon Sep 17 00:00:00 2001
+From: Tatsuhiro Tsujikawa 
+Date: Thu, 24 Aug 2023 09:34:26 +
+Subject: [PATCH] Fix memory leak
+
+This commit fixes memory leak that happens when PUSH_PROMISE or
+HEADERS frame cannot be sent, and nghttp2_on_stream_close_callback
+fails with a fatal error.  For example, if GOAWAY frame has been
+received, a HEADERS frame that opens new stream cannot be sent.
+
+This issue has already been made public via CVE-2023-35945 [1] issued
+by envoyproxy/envoy project.  During embargo period, the patch to fix
+this bug was accidentally submitted to nghttp2/nghttp2 repository [2].
+And they decided to disclose CVE early.  I was notified just 1.5 hours
+before disclosure.  I had no time to respond.
+
+PoC described in [1] is quite simple, but I think it is not enough to
+trigger this bug.  While it is true that receiving GOAWAY prevents a
+client from opening new stream, and nghttp2 enters error handling
+branch, in order to cause the memory leak,
+nghttp2_session_close_stream function must return a fatal error.
+nghttp2 defines 2 fatal error codes:
+
+- NGHTTP2_ERR_NOMEM
+- NGHTTP2_ERR_CALLBACK_FAILURE
+
+NGHTTP2_ERR_NOMEM, as its name suggests, indicates out of memory.  It
+is unlikely that a process gets short of memory with this simple PoC
+scenario unless application does something memory heavy processing.
+
+NGHTTP2_ERR_CALLBACK_FAILURE is returned from application defined
+callback function (nghttp2_on_stream_close_callback, in this case),
+which indicates something fatal happened inside a callback, and a
+connection must be closed immediately without any further action.  As
+nghttp2_on_stream_close_error_callback documentation says, any error
+code other than 0 or NGHTTP2_ERR_CALLBACK_FAILURE is treated as fatal
+error code.  More specifically, it is treated as if
+NGHTTP2_ERR_CALLBACK_FAILURE is returned.  I guess that envoy returns
+NGHTTP2_ERR_CALLBACK_FAILURE or other error code which is translated
+into NGHTTP2_ERR_CALLBACK_FAILURE.
+
+[1] https://github.com/envoyproxy/envoy/security/advisories/GHSA-jfxv-29pc-x22r
+[2] https://github.com/nghttp2/nghttp2/pull/1929
+
+CVE: CVE-2023-35945
+
+Upstream-Status: Backport 
[https://github.com/nghttp2/nghttp2/commit/ce385d3f55a4b76da976b3bdf71fe2deddf315ba]
+
+Signed-off-by: Yogita Urade 
+---
+ lib/nghttp2_session.c| 10 +-
+ tests/nghttp2_session_test.c | 34 ++
+ 2 files changed, 39 insertions(+), 5 deletions(-)
+
+diff --git a/lib/nghttp2_session.c b/lib/nghttp2_session.c
+index 380a47c..2d9285f 100644
+--- a/lib/nghttp2_session.c
 b/lib/nghttp2_session.c
+@@ -2940,6 +2940,7 @@ static ssize_t 
nghttp2_session_mem_send_internal(nghttp2_session *session,
+   if (rv < 0) {
+ int32_t opened_stream_id = 0;
+ uint32_t error_code = NGHTTP2_INTERNAL_ERROR;
++int rv2 = 0;
+
+ DEBUGF("send: frame preparation failed with %s\n",
+nghttp2_strerror(rv));
+@@ -2982,19 +2983,18 @@ static ssize_t 
nghttp2_session_mem_send_internal(nghttp2_session *session,
+ }
+ if (opened_stream_id) {
+   /* careful not to override rv */
+-  int rv2;
+   rv2 = nghttp2_session_close_stream(session, opened_stream_id,
+  error_code);
+-
+-  if (nghttp2_is_fatal(rv2)) {
+-return rv2;
+-  }
+ }
+
+ nghttp2_outbound_item_free(item, mem);
+ 

[OE-core][kirkstone 2/8] go: Fix CVE-2023-29409

2023-08-27 Thread Steve Sakoman
From: Soumya Sambu 

Extremely large RSA keys in certificate chains can cause a
client/server to expend significant CPU time verifying
signatures. With fix, the size of RSA keys transmitted
during handshakes is restricted to <= 8192 bits. Based on
a survey of publicly trusted RSA keys, there are currently
only three certificates in circulation with keys larger than
this, and all three appear to be test certificates that are
not actively deployed. It is possible there are larger keys
in use in private PKIs, but we target the web PKI, so causing
breakage here in the interests of increasing the default
safety of users of crypto/tls seems reasonable.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-29409

Signed-off-by: Soumya Sambu 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   1 +
 .../go/go-1.19/CVE-2023-29409.patch   | 175 ++
 2 files changed, 176 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index e0f02f3e28..91dd886cd0 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -42,6 +42,7 @@ SRC_URI += "\
 file://CVE-2023-24536_3.patch \
 file://CVE-2023-24531_1.patch \
 file://CVE-2023-24531_2.patch \
+file://CVE-2023-29409.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch 
b/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch
new file mode 100644
index 00..38451f7555
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch
@@ -0,0 +1,175 @@
+From 2300f7ef07718f6be4d8aa8486c7de99836e233f Mon Sep 17 00:00:00 2001
+From: Roland Shoemaker 
+Date: Wed, 23 Aug 2023 12:03:43 +
+Subject: [PATCH] crypto/tls: restrict RSA keys in certificates to <= 8192 bits
+
+Extremely large RSA keys in certificate chains can cause a client/server
+to expend significant CPU time verifying signatures. Limit this by
+restricting the size of RSA keys transmitted during handshakes to <=
+8192 bits.
+
+Based on a survey of publicly trusted RSA keys, there are currently only
+three certificates in circulation with keys larger than this, and all
+three appear to be test certificates that are not actively deployed. It
+is possible there are larger keys in use in private PKIs, but we target
+the web PKI, so causing breakage here in the interests of increasing the
+default safety of users of crypto/tls seems reasonable.
+
+Thanks to Mateusz Poliwczak for reporting this issue.
+
+Updates #61460
+Fixes #61579
+Fixes CVE-2023-29409
+
+Change-Id: Ie35038515a649199a36a12fc2c5df3af855dca6c
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1912161
+Reviewed-by: Damien Neil 
+Reviewed-by: Tatiana Bradley 
+Run-TryBot: Roland Shoemaker 
+(cherry picked from commit d865c715d92887361e4bd5596e19e513f27781b7)
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1965487
+Reviewed-on: https://go-review.googlesource.com/c/go/+/514915
+Run-TryBot: David Chase 
+Reviewed-by: Matthew Dempsky 
+TryBot-Bypass: David Chase 
+
+CVE: CVE-2023-29409
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/2300f7ef07718f6be4d8aa8486c7de99836e233f]
+
+Signed-off-by: Soumya Sambu 
+---
+ src/crypto/tls/handshake_client.go  |  8 +++
+ src/crypto/tls/handshake_client_test.go | 78 +
+ src/crypto/tls/handshake_server.go  |  4 ++
+ 3 files changed, 90 insertions(+)
+
+diff --git a/src/crypto/tls/handshake_client.go 
b/src/crypto/tls/handshake_client.go
+index 85622f1..828d2cb 100644
+--- a/src/crypto/tls/handshake_client.go
 b/src/crypto/tls/handshake_client.go
+@@ -852,6 +852,10 @@ func (hs *clientHandshakeState) sendFinished(out []byte) 
error {
+   return nil
+ }
+
++// maxRSAKeySize is the maximum RSA key size in bits that we are willing
++// to verify the signatures of during a TLS handshake.
++const maxRSAKeySize = 8192
++
+ // verifyServerCertificate parses and verifies the provided chain, setting
+ // c.verifiedChains and c.peerCertificates or sending the appropriate alert.
+ func (c *Conn) verifyServerCertificate(certificates [][]byte) error {
+@@ -862,6 +866,10 @@ func (c *Conn) verifyServerCertificate(certificates 
[][]byte) error {
+   c.sendAlert(alertBadCertificate)
+   return errors.New("tls: failed to parse certificate 
from server: " + err.Error())
+   }
++  if cert.PublicKeyAlgorithm == x509.RSA && 
cert.PublicKey.(*rsa.PublicKey).N.BitLen() > maxRSAKeySize {
++  c.sendAlert(alertBadCertificate)
++  return fmt.Errorf("tls: server sent certificate 
containing RSA key larger than %d bits", maxRSAKeySize)
++  }
+  

[OE-core][kirkstone 1/8] ffmpeg: add CVE_CHECK_IGNORE for CVE-2023-39018

2023-08-27 Thread Steve Sakoman
From: Narpat Mali 

CVE-2023-39018 belongs to ffmpeg-cli-wrapper (Java wrapper around the FFmpeg 
CLI)
and not ffmpeg itself. As per CVE description, it is mentioned as FFmpeg 0.7.0 
which
is the version for ffmpeg-cli-wrapper and ffmpeg don't have 0.7.0 version at 
all.

Debian & Bugzilla trackers have already marked as NOT-FOR-US/RESOLVED-INVALID.
As it won't be affecting the ffmpeg package so, we can ignore the CVE-2023-39018
in ffmpeg recipe.

References:
https://github.com/bramp/ffmpeg-cli-wrapper
https://github.com/FFmpeg/FFmpeg
https://security-tracker.debian.org/tracker/CVE-2023-39018
https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-39018

Upstream master patch:
https://git.openembedded.org/openembedded-core/commit/?id=c21ed498b423c13463a4ae0bb475883cc7901847

Signed-off-by: Narpat Mali 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb 
b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
index 6ece34fcfd..1295d5cdf1 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
@@ -33,6 +33,12 @@ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
 
 SRC_URI[sha256sum] = 
"ef2efae259ce80a240de48ec85ecb062cecca26e4352ffb3fda562c21a93007b"
 
+# CVE-2023-39018 issue belongs to ffmpeg-cli-wrapper (Java wrapper around the 
FFmpeg CLI)
+# and not ffmepg itself.
+# https://security-tracker.debian.org/tracker/CVE-2023-39018
+# https://bugzilla.suse.com/show_bug.cgi?id=CVE-2023-39018
+CVE_CHECK_IGNORE += "CVE-2023-39018"
+
 # Build fails when thumb is enabled: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7717
 ARM_INSTRUCTION_SET:armv4 = "arm"
 ARM_INSTRUCTION_SET:armv5 = "arm"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186797): 
https://lists.openembedded.org/g/openembedded-core/message/186797
Mute This Topic: https://lists.openembedded.org/mt/100997852/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 0/8] Patch review

2023-08-27 Thread Steve Sakoman
Please review this set of changes for kirkstone and have comments back by
end of day Tuesday, August 29.

Passed a-full on autobuilder:

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

The following changes since commit ea920e3c8075f3a1b79039341f8c889f6197a07f:

  glibc-locale: use stricter matching for metapackages' runtime dependencies 
(2023-08-22 07:07:13 -1000)

are available in the Git repository at:

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

Narpat Mali (2):
  ffmpeg: add CVE_CHECK_IGNORE for CVE-2023-39018
  python3-git: upgrade 3.1.27 -> 3.1.32

Ross Burton (3):
  linux-yocto: add script to generate kernel CVE_CHECK_IGNORE entries
  linux/cve-exclusion: add generated CVE_CHECK_IGNORES.
  linux/cve-exclusion: remove obsolete manual entries

Siddharth (1):
  Qemu: Resolve undefined reference issue in CVE-2023-2861

Soumya Sambu (1):
  go: Fix CVE-2023-29409

Yogita Urade (1):
  nghttp2: fix CVE-2023-35945

 meta/recipes-devtools/go/go-1.17.13.inc   |1 +
 .../go/go-1.19/CVE-2023-29409.patch   |  175 +
 ...-git-CVE-2022-24439-fix-from-PR-1518.patch |   97 -
 ...-git-CVE-2022-24439-fix-from-PR-1521.patch |  488 --
 ...n3-git_3.1.27.bb => python3-git_3.1.32.bb} |6 +-
 .../qemu/qemu/CVE-2023-2861.patch |   66 +-
 meta/recipes-kernel/linux/cve-exclusion.inc   |  869 --
 .../linux/cve-exclusion_5.15.inc  | 7193 +
 .../linux/generate-cve-exclusions.py  |  101 +
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |1 +
 .../recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |6 +
 .../nghttp2/nghttp2/CVE-2023-35945.patch  |  151 +
 .../recipes-support/nghttp2/nghttp2_1.47.0.bb |1 +
 13 files changed, 7667 insertions(+), 1488 deletions(-)
 create mode 100644 meta/recipes-devtools/go/go-1.19/CVE-2023-29409.patch
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1518.patch
 delete mode 100644 
meta/recipes-devtools/python/python3-git/0001-python3-git-CVE-2022-24439-fix-from-PR-1521.patch
 rename meta/recipes-devtools/python/{python3-git_3.1.27.bb => 
python3-git_3.1.32.bb} (80%)
 create mode 100644 meta/recipes-kernel/linux/cve-exclusion_5.15.inc
 create mode 100755 meta/recipes-kernel/linux/generate-cve-exclusions.py
 create mode 100644 meta/recipes-support/nghttp2/nghttp2/CVE-2023-35945.patch

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186796): 
https://lists.openembedded.org/g/openembedded-core/message/186796
Mute This Topic: https://lists.openembedded.org/mt/100997850/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] libtraceevent: build with Meson

2023-08-27 Thread Ross Burton
From: Ross Burton 

After what I presume is the recent kernel upgrade, perf started to fail
to configure.  This was actually due to libtraceevent racing during its
build and failing to put one of the .o files into the .so (reminder:
Make is terrible). This doesn't cause the libtraceevent build to fail so
once the broken .so is in sstate, it causes all future perf builds to
fail.

Instead of rewriting the Makefile rules to fix this race it's easier to
switch to Meson which doesn't have this sort of problem. However the
Meson support is pretty new and has some rough edges, so we need a patch
to make it do the right thing.

I will submit the libtraceevent fixes upstream shortly.

[ YOCTO #15201 ]

Signed-off-by: Ross Burton 
---
 ...not-preserve-ownership-in-cp-command.patch | 40 --
 .../libtraceevent/libtraceevent/meson.patch   | 74 +++
 .../libtraceevent/libtraceevent_1.7.3.bb  | 10 +--
 3 files changed, 77 insertions(+), 47 deletions(-)
 delete mode 100644 
meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
 create mode 100644 meta/recipes-kernel/libtraceevent/libtraceevent/meson.patch

diff --git 
a/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
 
b/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
deleted file mode 100644
index 5e88048817e..000
--- 
a/meta/recipes-kernel/libtraceevent/libtraceevent/0001-makefile-Do-not-preserve-ownership-in-cp-command.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From ed0a31000305d937abe47c44d705b5b52bb36f79 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 22 Dec 2022 18:32:17 -0800
-Subject: [PATCH] makefile: Do not preserve ownership in cp command
-
-Fixes
-
-ERROR: libtraceevent-1.7.0-r0 do_package_qa: QA Issue: libtraceevent: 
/usr/lib/libtraceevent.a is owned by uid 1000, which is the same as the user 
running bitbake. This may be due to host contamination [host-user-contaminated]
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj 

- Makefile | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/Makefile b/Makefile
-index 965ff47..0e782cb 100644
 a/Makefile
-+++ b/Makefile
-@@ -287,7 +287,7 @@ $(BUILD_PREFIX): force
-   $(Q)$(call build_prefix,$(prefix))
- 
- define do_make_pkgconfig_file
--  cp -f ${PKG_CONFIG_SOURCE_FILE}.template ${PKG_CONFIG_FILE};\
-+  install -m 0644 ${PKG_CONFIG_SOURCE_FILE}.template ${PKG_CONFIG_FILE};  
\
-   sed -i "s|INSTALL_PREFIX|${1}|g" ${PKG_CONFIG_FILE};\
-   sed -i "s|LIB_VERSION|${EVENT_PARSE_VERSION}|g" ${PKG_CONFIG_FILE}; \
-   sed -i "s|LIB_DIR|${libdir_relative}|g" ${PKG_CONFIG_FILE}; \
-@@ -335,7 +335,7 @@ install: install_libs install_plugins
- 
- install_libs: libs install_headers install_pkgconfig
-   $(Q)$(call do_install,$(LIBTRACEEVENT_SHARED),$(libdir_SQ)); \
--  cp -fpR $(LIB_INSTALL) $(DESTDIR)$(libdir_SQ)
-+  cp --no-preserve=ownership --recursive $(LIB_INSTALL) 
$(DESTDIR)$(libdir_SQ)
-   $(Q)$(call install_ld_config)
- 
- install_pkgconfig: $(PKG_CONFIG_FILE)
--- 
-2.39.0
-
diff --git a/meta/recipes-kernel/libtraceevent/libtraceevent/meson.patch 
b/meta/recipes-kernel/libtraceevent/libtraceevent/meson.patch
new file mode 100644
index 000..38b6107136f
--- /dev/null
+++ b/meta/recipes-kernel/libtraceevent/libtraceevent/meson.patch
@@ -0,0 +1,74 @@
+Fixes for the Meson build of libtraceevent:
+
+- Make the plugin directory the same as the Makefiles
+- Install the plugins as modules not static and versioned shared libraries
+- Add an option to disable building the documentation (needs asciidoc and 
xmlto)
+
+Upstream-Status: Pending
+Signed-off-by: Ross Burton 
+
+diff --git a/meson.build b/meson.build
+index b61c873..4bba4d8 100644
+--- a/meson.build
 b/meson.build
+@@ -25,7 +25,7 @@ htmldir = join_paths(prefixdir, get_option('htmldir'))
+ libdir = join_paths(prefixdir, get_option('libdir'))
+ plugindir = get_option('plugindir')
+ if plugindir == ''
+-plugindir = join_paths(libdir, 'libtraceevent/plugins')
++plugindir = join_paths(libdir, 'traceevent/plugins')
+ endif
+ 
+ add_project_arguments(
+@@ -45,10 +45,13 @@ if cunit_dep.found()
+ subdir('utest')
+ endif
+ subdir('samples')
+-subdir('Documentation')
+ 
+-custom_target(
+-'docs',
+-output: 'docs',
+-depends: [html, man],
+-command: ['echo'])
++if get_option('docs')
++subdir('Documentation')
++
++custom_target(
++'docs',
++output: 'docs',
++depends: [html, man],
++command: ['echo'])
++endif
+diff --git a/meson_options.txt b/meson_options.txt
+index b2294f6..0611216 100644
+--- a/meson_options.txt
 b/meson_options.txt
+@@ -4,6 +4,10 @@
+ 
+ option('plugindir', type : 'string',
+description : 'set the plugin dir')
++
++option('docs', type : 'boolean', value: true,

Re: [OE-core] [PATCH v3 01/13] vscode: add minimal configuration

2023-08-27 Thread Adrian Freihofer
On Sat, 2023-08-26 at 10:31 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From:
> > openembedded-core@lists.openembedded.org 
> >  > > On Behalf Of Adrian Freihofer
> > Sent: den 26 augusti 2023 00:26
> > To: openembedded-core@lists.openembedded.org
> > Cc: Adrian Freihofer 
> > Subject: [OE-core] [PATCH v3 01/13] vscode: add minimal
> > configuration
> > 
> > It is essential to configure VSCode indexer plugins to ignore the
> > build
> > folder of bitbake. Otherwise, the indexer plugins run with 100% CPU
> > load
> > until an OOM exception occurs. In practice, this makes VSCode more
> > or
> > less unusable for working with Yocto until a file like the one
> > added by
> > this commit is deployed before VSCode starts. From the user's point
> > of
> > view, it is not obvious why the system runs at 100% CPU load and
> > eventually crashes.
> > 
> > It is even more misleading that VSCode starts the indexers
> > immediately,
> > but does not stop or reconfigure them when the ignore list is
> > updated.
> > In practice, this means that every time the ignore list is changed,
> > VSCode immediately starts indexing the build folder until the OOM
> > exception stops it. Depending on the system's OOM handler, the
> > entire
> > build machine may crash.
> > Particularly annoying is the Python plugin that ignores the general
> > ignore list and requires an extra ignore section.
> > 
> > Signed-off-by: Adrian Freihofer 
> > ---
> >  .gitignore    |  2 ++
> >  .vscode/settings.json | 29 +
> >  2 files changed, 31 insertions(+)
> >  create mode 100644 .vscode/settings.json
> > 
> > diff --git a/.gitignore b/.gitignore
> > index 8f48d452dab..f6ce090b5fc 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -36,3 +36,5 @@ _toaster_clones/
> >  downloads/
> >  sstate-cache/
> >  toaster.sqlite
> > +.vscode/
> > +vscode-bitbake-build/
> > diff --git a/.vscode/settings.json b/.vscode/settings.json
> > new file mode 100644
> > index 000..4c941d47444
> > --- /dev/null
> > +++ b/.vscode/settings.json
> > @@ -0,0 +1,29 @@
> > +{
> > +    "files.watcherExclude": {
> > +    "**/.git/**": true,
> > +    "**/cache/**": true,
> > +    "**/tmp*/**": true,
> > +    "**/downloads/**": true,
> > +    "**/sstate-cache/**": true,
> > +    "**/vscode-bitbake-build/**": true,
> > +    "**/workspace/sources/**": true
> 
> You should include workspace/attic here and below as well.

Thank you. Fixed with v4.

Regards,
Adrian

> 
> > +    },
> > +    "files.exclude": {
> > +    "**/.git/**": true,
> > +    "**/cache/**": true,
> > +    "**/tmp*/**": true,
> > +    "**/downloads/**": true,
> > +    "**/sstate-cache/**": true,
> > +    "**/vscode-bitbake-build/**": true,
> > +    "**/workspace/sources/**": true
> > +    },
> > +    "python.analysis.exclude": [
> > +    "**/.git/**",
> > +    "**/cache/**",
> > +    "**/tmp*/**",
> > +    "**/downloads/**",
> > +    "**/sstate-cache/**",
> > +    "**/vscode-bitbake-build/**",
> > +    "**/workspace/sources/**"
> > +    ]
> > +}
> > --
> > 2.41.0
> 
> //Peter
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186794): 
https://lists.openembedded.org/g/openembedded-core/message/186794
Mute This Topic: https://lists.openembedded.org/mt/100965614/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 v4 12/13] oe-selftest devtool: ide tests

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 meta/lib/oeqa/selftest/cases/devtool.py | 133 
 1 file changed, 133 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/devtool.py 
b/meta/lib/oeqa/selftest/cases/devtool.py
index a2b77e528de..21644ef7bc2 100644
--- a/meta/lib/oeqa/selftest/cases/devtool.py
+++ b/meta/lib/oeqa/selftest/cases/devtool.py
@@ -11,6 +11,7 @@ import tempfile
 import glob
 import fnmatch
 import unittest
+import json
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, create_temp_layer
@@ -2192,3 +2193,135 @@ class DevtoolUpgradeTests(DevtoolBase):
 
 #Step 4.5
 runCmd("grep %s %s" % (modconfopt, codeconfigfile))
+
+
+class DevtoolIdeTests(DevtoolBase):
+
+def __devtool_ide_recipe(self):
+tempdir = tempfile.mkdtemp(prefix='devtoolqa')
+self.track_for_cleanup(tempdir)
+self.track_for_cleanup(self.workspacedir)
+self.add_command_to_tearDown('bitbake -c clean %s' % self.recipe_name)
+self.add_command_to_tearDown('bitbake-layers remove-layer */workspace')
+
+conf_lines = [
+'IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"',
+'IMAGE_CLASSES += "image-combined-dbg"',
+'IMAGE_GEN_DEBUGFS = "1"',
+'IMAGE_INSTALL += "gdbserver %s-ptest"' % self.recipe_name
+]
+self.write_config("\n".join(conf_lines))
+
+result = runCmd('devtool modify %s -x %s' % (self.recipe_name, 
tempdir))
+self.assertExists(os.path.join(tempdir, self.build_file),
+  'Extracted source could not be found')
+self.assertExists(os.path.join(self.workspacedir, 'conf',
+  'layer.conf'), 'Workspace directory not created')
+matches = glob.glob(os.path.join(self.workspacedir,
+'appends', self.recipe_name + '.bbappend'))
+self.assertTrue(matches, 'bbappend not created %s' % result.output)
+
+# Test devtool status
+result = runCmd('devtool status')
+self.assertIn(self.recipe_name, result.output)
+self.assertIn(tempdir, result.output)
+self._check_src_repo(tempdir)
+
+result = runCmd('devtool ide %s core-image-minimal -c --ide=code' % 
self.recipe_name)
+return tempdir
+
+def __devtool_ide_qemu(self):
+# Verify do_install works
+with open(os.path.join(self.tempdir, '.vscode', 'tasks.json')) as 
tasks_j:
+tasks_d = json.load(tasks_j)
+tasks = tasks_d["tasks"]
+task_install = next((task for task in tasks if task["label"] == 
"install && deploy-target %s"  % self.recipe_name), None)
+self.assertIsNot(task_install, None)
+install_deploy_cmd = task_install["command"]
+# execute only the bb_run_do_install script since the deploy would 
require e.g. Qemu running.
+install_cmd = install_deploy_cmd.replace("install_and_deploy", 
"bb_run_do_install")
+runCmd(install_cmd, cwd=self.tempdir)
+
+# Verify if re-building the SDK still works and the deploy and install 
script gets generated
+runCmd('devtool ide %s core-image-minimal -c --ide=code' % 
self.recipe_name)
+self.assertExists(install_deploy_cmd, 'install_and_deploy script not 
found')
+
+# Verify deployment to Qemu works
+with runqemu("core-image-minimal", runqemuparams = "nographic") as 
qemu:
+MAGIC_STRING_ORIG = "Magic: 123456789"
+MAGIC_STRING_NEW = "Magic: 987654321"
+
+# Verify the unmodified example prints the magic string
+status, output = qemu.run(self.example_exe)
+self.assertEqual(status, 0)
+self.assertIn(MAGIC_STRING_ORIG, output)
+
+# Verify the unmodified ptests work
+status, output = qemu.run("ptest-runner " + self.recipe_name)
+self.assertEqual(status, 0, msg=output)
+self.assertIn("PASS: cpp-example-lib", output)
+
+# Replace the Magic String in the code, compile and deploy to Qemu
+cpp_example_lib_hpp = os.path.join(self.tempdir, 
'cpp-example-lib.hpp')
+with open(cpp_example_lib_hpp, 'r') as file:
+cpp_code = file.read()
+cpp_code = cpp_code.replace(MAGIC_STRING_ORIG, 
MAGIC_STRING_NEW)
+with open(cpp_example_lib_hpp, 'w') as file:
+file.write(cpp_code)
+runCmd(install_deploy_cmd, cwd=self.tempdir)
+
+# Verify the modified example prints the modified magic string
+status, output = qemu.run(self.example_exe)
+self.assertEqual(status, 0)
+self.assertNotIn(MAGIC_STRING_ORIG, output)
+self.assertIn(MAGIC_STRING_NEW, output)
+
+# Verify the modified example ptests work
+status, output = qemu.run("ptest-runner " + self.recipe_name)
+

[OE-core] [PATCH v4 13/13] docs: cover devtool ide

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 documentation/sdk-manual/extensible.rst | 97 -
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/documentation/sdk-manual/extensible.rst 
b/documentation/sdk-manual/extensible.rst
index 9e08e57a4e7..d05d4e36aa7 100644
--- a/documentation/sdk-manual/extensible.rst
+++ b/documentation/sdk-manual/extensible.rst
@@ -237,7 +237,7 @@ all the commands.
devtool
quick reference.
 
-Three ``devtool`` subcommands provide entry-points into
+Four ``devtool`` subcommands provide entry-points into
 development:
 
 -  *devtool add*: Assists in adding new software to be built.
@@ -245,6 +245,8 @@ development:
 -  *devtool modify*: Sets up an environment to enable you to modify
the source of an existing component.
 
+-  *devtool ide*: Generates a configuration for an IDE.
+
 -  *devtool upgrade*: Updates an existing recipe so that you can
build it for an updated set of source files.
 
@@ -632,6 +634,99 @@ command:
   proceed with your work. If you do use this command, realize that
   the source tree is preserved.
 
+Use ``devtool ide`` to generate an configuration for the IDE
+
+
+``devtool ide`` automatically configures the IDE for cross-compiling and 
remote debugging.
+The IDE is configured to call for example cmake directly. This has several 
advantages.
+First of all it is much faster than using e.g. ``devtool build``. But it also 
allows to
+use the very good integration of build tools like cmake or gdb with VSCode 
directly.
+
+Two different use cases are supported:
+
+- Generate the IDE configuration for a workspace created by ``devtool modify``.
+
+- Generate the IDE configuration for using a cross-toolchain as provided by
+  ``bitbake meta-ide-support build-sysroots``.
+
+Assuming the development environment is set up correctly and a workspace has 
been created
+for the recipe using ``devtool modify recipe``, the following command can 
create the
+configuration for VSCode in the recipe workspace:
+
+   $ devtool ide recipe core-image-minimal --target root@192.168.7.2
+
+What this command does exactly depends on the recipe or the build tool used by 
the recipe.
+Currently, only CMake and Meson are supported natively.
+
+For a recipe which inherits cmake it does:
+
+- Prepare the SDK by calling bitbake core-image-minimal, gdb-cross, 
qemu-native...
+
+- Generate a cmake-preset with configures cmake to use exactly the same 
environent and
+  the same cmake-cache configuration as used by ``bitbake recipe``. The 
cmake-preset referres
+  to the per-recipe-sysroot of the recipe.
+
+  Currently Configure, Build and Test presets are supported. Test presets 
execute the test
+  binaries with Qemu.
+
+- Generates a helper script to handle the do_install with pseudo
+
+- Generates some helper scripts to start the gdbserver on the target device
+
+- Generates the ``.vscode`` folder containing the following files:
+
+  - c_ccp_properties.json: configure the code navigation
+
+  - extensions.json: Recommend the extensions which are used.
+
+  - launch.json: Provide a configuration for remote debugging with gdb-cross 
and gdbserver.
+The debug-symbols are searched in the build-folder, the per-recipe-sysroot 
and the rootfs-dbg
+folder which is provided by the image.
+
+  - settings.json: confgure the indexer to ignore the build folders
+
+  - tasks.json: Provide some helpers for running
+
+- do_install and ``devtool deploy-target``
+
+- start the gdbserver via ssh
+
+For a recipe which inherits meson a similar configuration is generated.
+Because there is nothing like a meson-preset a wrapper script for meson is 
generated.
+
+For some special recipes and use cases a per-recipe-sysroot based SDK is not 
suitable.
+Therefore devtool ide also supports setting up the shared sysroots environment 
and generating
+a IDE configurations referring to the shared sysroots. Recipes leading to a 
shared sysroot
+are for example meta-ide-support or shared-sysroots. Also passing none as a 
recipe name leads
+to a shared sysroot SDK.
+
+   $ devtool ide none core-image-minimal
+
+In case of a shared sysroot SDK the configuration which gets generated for 
VSCode exposes the
+cross-tool-chain as a cmake-kit. If a cmake project is loaded into VSCode the 
cross-toolchain
+can be selected for compiling.
+
+The default IDE is VSCode. Some hints about using VSCode:
+
+- To work with cmake press ``Ctrl + Shift + p``, type cmake.
+  This will show some possible commands like selecting a cmake preset, 
compiling or running ctest.
+  A cmake kit might be activated by ``Ctrl + Shift + p``, type cmake quick 
start,
+  if not preset file is in the wokspace.
+
+- To work with meson press ``Ctrl + Shift + p``, type meson.
+  This will show some possible commands like compiling or executing the unit 
tests.
+
+- For the deployment to the target device, just press ``Ctrl + Shift + p``, 

[OE-core] [PATCH v4 09/13] refactor: make strip_execs callable without d

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 meta/classes-global/staging.bbclass | 3 ++-
 meta/lib/oe/package.py  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes-global/staging.bbclass 
b/meta/classes-global/staging.bbclass
index 3a300c32e7c..7f4075a5f6e 100644
--- a/meta/classes-global/staging.bbclass
+++ b/meta/classes-global/staging.bbclass
@@ -92,7 +92,8 @@ python sysroot_strip () {
 qa_already_stripped = 'already-stripped' in (d.getVar('INSANE_SKIP:' + pn) 
or "").split()
 strip_cmd = d.getVar("STRIP")
 
-oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d,
+max_process = oe.utils.multiprocess_launch_max_process(d)
+oe.package.strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
max_process,
qa_already_stripped=qa_already_stripped)
 }
 
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index ffca7559ba7..1dd20f85ebd 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -114,7 +114,7 @@ def is_static_lib(path):
 return start == magic
 return False
 
-def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, d, 
qa_already_stripped=False):
+def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, max_process, 
qa_already_stripped=False):
 """
 Strip executable code (like executables, shared libraries) _in_place_
 - Based on sysroot_strip in staging.bbclass
@@ -122,6 +122,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 :param strip_cmd: Strip command (usually ${STRIP})
 :param libdir: ${libdir} - strip .so files in this directory
 :param base_libdir: ${base_libdir} - strip .so files in this directory
+:param max_process: number of stripping processes started in parallel
 :param qa_already_stripped: Set to True if already-stripped' in 
${INSANE_SKIP}
 This is for proper logging and messages only.
 """
@@ -164,7 +165,6 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 # ...but is it ELF, and is it already stripped?
 checkelf.append(file)
 inodecache[file] = s.st_ino
-max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
 results = oe.utils.multiprocess_launch_mp(is_elf, checkelf, max_process)
 for (file, elf_file) in results:
 #elf_file = is_elf(file)
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186789): 
https://lists.openembedded.org/g/openembedded-core/message/186789
Mute This Topic: https://lists.openembedded.org/mt/100996590/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 v4 04/13] cmake.bbclass: support qemu

2023-08-27 Thread Adrian Freihofer
Define the CMAKE_CROSSCOMPILING_EMULATOR variable similar to what the
meson bbclass does. This allows for example to execute cross compilied
unit tests on the build machine.

CMAKE_CROSSCOMPILING_EMULATOR is a semi colon separated list of
paramters which could directly handle the -L and the -E parameters.
Creating a wrapper script is not absolutely mandatory. But anyway lets
do it similar to what the meson.bbclass does and also disable pseudo.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 21 +
 1 file changed, 21 insertions(+)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index c63b0a80b18..944b0d8fefd 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -4,6 +4,13 @@
 # SPDX-License-Identifier: MIT
 #
 
+inherit qemu
+
+EXEWRAPPER_ENABLED:class-native = "False"
+EXEWRAPPER_ENABLED:class-nativesdk = "False"
+EXEWRAPPER_ENABLED ?= "${@bb.utils.contains('MACHINE_FEATURES', 
'qemu-usermode', 'True', 'False', d)}"
+DEPENDS:append = "${@' qemu-native' if d.getVar('EXEWRAPPER_ENABLED') == 
'True' else ''}"
+
 # Path to the CMake file to process.
 OECMAKE_SOURCEPATH ??= "${S}"
 
@@ -156,6 +163,20 @@ EOF
 
 addtask generate_toolchain_file after do_patch before do_configure
 
+cmake_do_generate_toolchain_file:append:class-target() {
+if [ "${EXEWRAPPER_ENABLED}" = "True" ]; then
+# Write out a qemu wrapper that will be used as exe_wrapper so that 
camake
+# can run target helper binaries through that. This also allows to 
execute ctest.
+qemu_binary="${@qemu_wrapper_cmdline(d, '${STAGING_DIR_HOST}', 
['${STAGING_DIR_HOST}/${libdir}','${STAGING_DIR_HOST}/${base_libdir}'])}"
+echo "#!/bin/sh" > "${WORKDIR}/cmake-qemuwrapper"
+echo "$qemu_binary \"\$@\"" >> "${WORKDIR}/cmake-qemuwrapper"
+chmod +x "${WORKDIR}/cmake-qemuwrapper"
+echo "set( CMAKE_CROSSCOMPILING_EMULATOR 
${WORKDIR}/cmake-qemuwrapper)" \
+  >> ${WORKDIR}/toolchain.cmake
+fi
+}
+
+
 CONFIGURE_FILES = "CMakeLists.txt"
 
 do_configure[cleandirs] = "${@d.getVar('B') if d.getVar('S') != d.getVar('B') 
else ''}"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186784): 
https://lists.openembedded.org/g/openembedded-core/message/186784
Mute This Topic: https://lists.openembedded.org/mt/100996583/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 v4 11/13] devtool: ide make deploy-target quicker

2023-08-27 Thread Adrian Freihofer
Instead of calling devtool deploy-target which starts a bitbake server
to get some variables the previous refactoring allows to generate a
simple script which does no longer depend on variables from bitbake.
This is much faster.
---
 scripts/lib/devtool/ide.py | 115 ++---
 1 file changed, 55 insertions(+), 60 deletions(-)

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
index 7c7040232c4..9c724509d48 100755
--- a/scripts/lib/devtool/ide.py
+++ b/scripts/lib/devtool/ide.py
@@ -9,6 +9,7 @@
 
 import os
 import stat
+import sys
 import logging
 import json
 import re
@@ -360,15 +361,19 @@ class RecipeModified:
 self.bbappend = None
 # recipe variables from d.getVar
 self.b = None
+self.base_libdir = None
 self.bpn = None
 self.d = None
 self.fakerootcmd = None
 self.fakerootenv = None
+self.libdir = None
+self.max_process = None
 self.package_arch = None
 self.path = None
 self.recipe_sysroot = None
 self.recipe_sysroot_native = None
 self.staging_incdir = None
+self.strip_cmd = None
 self.target_arch = None
 self.workdir = None
 # replicate bitbake build environment
@@ -387,11 +392,6 @@ class RecipeModified:
 self.meson_cross_file = None
 # vscode
 self.dot_code_dir = None
-# TODO: remove calling devtool
-self.bb_env_passthrough_additions = None
-self.bbpath = None
-self.bitbakepath = None
-self.topdir = None
 
 def initialize(self, config, workspace, tinfoil):
 recipe_d = parse_recipe(
@@ -413,10 +413,14 @@ class RecipeModified:
 shutil.rmtree(self.temp_dir)
 
 self.b = recipe_d.getVar('B')
+self.base_libdir = recipe_d.getVar('base_libdir')
 self.bpn = recipe_d.getVar('BPN')
 self.d = recipe_d.getVar('D')
 self.fakerootcmd = recipe_d.getVar('FAKEROOTCMD')
 self.fakerootenv = recipe_d.getVar('FAKEROOTENV')
+self.libdir = recipe_d.getVar('libdir'),
+self.max_process = int(recipe_d.getVar(
+"BB_NUMBER_THREADS") or os.cpu_count() or 1)
 self.package_arch = recipe_d.getVar('PACKAGE_ARCH')
 self.path = recipe_d.getVar('PATH')
 self.recipe_sysroot = os.path.realpath(
@@ -425,15 +429,10 @@ class RecipeModified:
 recipe_d.getVar('RECIPE_SYSROOT_NATIVE'))
 self.staging_incdir = os.path.realpath(
 recipe_d.getVar('STAGING_INCDIR'))
+self.strip_cmd = recipe_d.getVar('STRIP')
 self.target_arch = recipe_d.getVar('TARGET_ARCH')
 self.workdir = os.path.realpath(recipe_d.getVar('WORKDIR'))
 
-self.bb_env_passthrough_additions = recipe_d.getVar(
-'BB_ENV_PASSTHROUGH_ADDITIONS')
-self.bbpath = recipe_d.getVar('BBPATH')
-self.bitbakepath = recipe_d.getVar('BITBAKEPATH')
-self.topdir = recipe_d.getVar('TOPDIR')
-
 self.__init_exported_variables(recipe_d)
 
 if bb.data.inherits_class('cmake', recipe_d):
@@ -971,6 +970,38 @@ class RecipeModified:
 cmd_lines.append(install_cmd)
 return self.write_script(cmd_lines, 'bb_run_do_install')
 
+def gen_deploy_target_script(self, args):
+"""Generate a quicker (works without tinfoil) variant of devtool 
target-deploy"""
+cmd_lines = ['#!/usr/bin/env python3']
+cmd_lines.append('import sys')
+cmd_lines.append('devtool_sys_path = %s' % str(sys.path))
+cmd_lines.append('devtool_sys_path.reverse()')
+cmd_lines.append('for p in devtool_sys_path:')
+cmd_lines.append('if p not in sys.path:')
+cmd_lines.append('sys.path.insert(0, p)')
+cmd_lines.append('from devtool.deploy import deploy_cached')
+args_filter = ['debug', 'dry_run', 'key', 'no_check_space', 
'no_host_check',
+   'no_preserve', 'port', 'recipename', 'show_status', 
'ssh_exec', 'strip', 'target']
+filtered_args_dict = {key: value for key, value in vars(
+args).items() if key in args_filter}
+cmd_lines.append('filtered_args_dict = %s' % str(filtered_args_dict))
+cmd_lines.append('class Dict2Class(object):')
+cmd_lines.append('def __init__(self, my_dict):')
+cmd_lines.append('for key in my_dict:')
+cmd_lines.append('setattr(self, key, my_dict[key])')
+cmd_lines.append('filtered_args = Dict2Class(filtered_args_dict)')
+cmd_lines.append('deploy_cached("%s", "%s", "%s", "%s", "%s", "%s", 
%d, "%s", "%s", filtered_args)' %
+ (self.d, self.workdir, self.path, self.strip_cmd,
+  self.libdir, self.base_libdir, self.max_process,
+  self.fakerootcmd, self.fakerootenv))
+return self.write_script(cmd_lines, 'deploy_target')
+
+def 

[OE-core] [PATCH v4 10/13] devtool: refactor deploy-target

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/__init__.py |   5 +-
 scripts/lib/devtool/deploy.py   | 230 +---
 2 files changed, 124 insertions(+), 111 deletions(-)

diff --git a/scripts/lib/devtool/__init__.py b/scripts/lib/devtool/__init__.py
index 702db669de3..7d64547616e 100644
--- a/scripts/lib/devtool/__init__.py
+++ b/scripts/lib/devtool/__init__.py
@@ -78,12 +78,15 @@ def exec_fakeroot(d, cmd, **kwargs):
 """Run a command under fakeroot (pseudo, in fact) so that it picks up the 
appropriate file permissions"""
 # Grab the command and check it actually exists
 fakerootcmd = d.getVar('FAKEROOTCMD')
+fakerootenv = d.getVar('FAKEROOTENV')
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, kwargs)
+
+def exec_fakeroot_no_d(fakerootcmd, fakerootenv, cmd, **kwargs):
 if not os.path.exists(fakerootcmd):
 logger.error('pseudo executable %s could not be found - have you run a 
build yet? pseudo-native should install this and if you have run any build then 
that should have been built')
 return 2
 # Set up the appropriate environment
 newenv = dict(os.environ)
-fakerootenv = d.getVar('FAKEROOTENV')
 for varvalue in fakerootenv.split():
 if '=' in varvalue:
 splitval = varvalue.split('=', 1)
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e14a5874177..ea7e2cb1ae8 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -16,7 +16,7 @@ import bb.utils
 import argparse_oe
 import oe.types
 
-from devtool import exec_fakeroot, setup_tinfoil, check_workspace_recipe, 
DevtoolError
+from devtool import exec_fakeroot_no_d, setup_tinfoil, check_workspace_recipe, 
DevtoolError
 
 logger = logging.getLogger('devtool')
 
@@ -133,16 +133,11 @@ def _prepare_remote_script(deploy, verbose=False, 
dryrun=False, undeployall=Fals
 
 return '\n'.join(lines)
 
-
-
-def deploy(args, config, basepath, workspace):
-"""Entry point for the devtool 'deploy' subcommand"""
+def deploy_cached(srcdir, workdir, path, strip_cmd, libdir, base_libdir, 
max_process, fakerootcmd, fakerootenv, args):
 import math
 import oe.recipeutils
 import oe.package
 
-check_workspace_recipe(workspace, args.recipename, checksrc=False)
-
 try:
 host, destdir = args.target.split(':')
 except ValueError:
@@ -152,116 +147,131 @@ def deploy(args, config, basepath, workspace):
 if not destdir.endswith('/'):
 destdir += '/'
 
+recipe_outdir = srcdir
+if not os.path.exists(recipe_outdir) or not os.listdir(recipe_outdir):
+raise DevtoolError('No files to deploy - have you built the %s '
+'recipe? If so, the install step has not installed '
+'any files.' % args.recipename)
+
+if args.strip and not args.dry_run:
+# Fakeroot copy to new destination
+srcdir = recipe_outdir
+recipe_outdir = os.path.join(workdir, 'devtool-deploy-target-stripped')
+if os.path.isdir(recipe_outdir):
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "rm -rf %s" % 
recipe_outdir, shell=True)
+exec_fakeroot_no_d(fakerootcmd, fakerootenv, "cp -af %s %s" % 
(os.path.join(srcdir, '.'), recipe_outdir), shell=True)
+os.environ['PATH'] = ':'.join([os.environ['PATH'], path or ''])
+oe.package.strip_execs(args.recipename, recipe_outdir, strip_cmd, 
libdir, base_libdir, max_process)
+
+filelist = []
+inodes = set({})
+ftotalsize = 0
+for root, _, files in os.walk(recipe_outdir):
+for fn in files:
+fstat = os.lstat(os.path.join(root, fn))
+# Get the size in kiB (since we'll be comparing it to the output 
of du -k)
+# MUST use lstat() here not stat() or getfilesize() since we don't 
want to
+# dereference symlinks
+if fstat.st_ino in inodes:
+fsize = 0
+else:
+fsize = int(math.ceil(float(fstat.st_size)/1024))
+inodes.add(fstat.st_ino)
+ftotalsize += fsize
+# The path as it would appear on the target
+fpath = os.path.join(destdir, os.path.relpath(root, 
recipe_outdir), fn)
+filelist.append((fpath, fsize))
+
+if args.dry_run:
+print('Files to be deployed for %s on target %s:' % (args.recipename, 
args.target))
+for item, _ in filelist:
+print('  %s' % item)
+return 0
+
+extraoptions = ''
+if args.no_host_check:
+extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+if not args.show_status:
+extraoptions += ' -q'
+
+scp_sshexec = ''
+ssh_sshexec = 'ssh'
+if args.ssh_exec:
+scp_sshexec = "-S %s" % args.ssh_exec
+ssh_sshexec = args.ssh_exec
+scp_port = ''
+ssh_port = ''
+if args.port:
+scp_port = "-P %s" % args.port
+ssh_port = 

[OE-core] [PATCH v4 07/13] cmake-example: workaround for pseudo breakeage

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/cmake-example.bb | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
index 96d543180b4..fbf1f266721 100644
--- a/meta-selftest/recipes-test/cpp/cmake-example.bb
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -15,3 +15,9 @@ SRC_URI += "\
 "
 
 FILES:${PN}-ptest += "${bindir}/test-cmake-example"
+
+# This is a workaround for packages with sources in-tree
+# Without this bitbake ... does not work after running the install script.
+# newenv['PSEUDO_IGNORE_PATHS'] = newenv['PSEUDO_IGNORE_PATHS'] + ""
+# path mismatch [3 links]: ino 37529096 db 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/tmp/work/cortexa57-poky-linux/cmake-example/1.0-r0/package/usr/src/debug/cmake-example/1.0-r0/oe-local-files/cmake-example-lib.cpp'
 req 
'/home/adrian/projects/oss/meta-yocto-upstream/projects/poky-oe-glibc-sd/workspace/sources/cmake-example/oe-local-files/cmake-example-lib.cpp'.
+PACKAGE_DEBUG_SPLIT_STYLE = "debug-without-src"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186787): 
https://lists.openembedded.org/g/openembedded-core/message/186787
Mute This Topic: https://lists.openembedded.org/mt/100996588/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 v4 08/13] refactor: make multiprocess_launch callable without d

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 meta/lib/oe/package.py |  5 +++--
 meta/lib/oe/utils.py   | 12 +---
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index 9d70925b9b7..ffca7559ba7 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -164,7 +164,8 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 # ...but is it ELF, and is it already stripped?
 checkelf.append(file)
 inodecache[file] = s.st_ino
-results = oe.utils.multiprocess_launch(is_elf, checkelf, d)
+max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
+results = oe.utils.multiprocess_launch_mp(is_elf, checkelf, max_process)
 for (file, elf_file) in results:
 #elf_file = is_elf(file)
 if elf_file & 1:
@@ -192,7 +193,7 @@ def strip_execs(pn, dstdir, strip_cmd, libdir, base_libdir, 
d, qa_already_stripp
 elf_file = int(elffiles[file])
 sfiles.append((file, elf_file, strip_cmd))
 
-oe.utils.multiprocess_launch(runstrip, sfiles, d)
+oe.utils.multiprocess_launch_mp(runstrip, sfiles, max_process)
 
 
 def file_translate(file):
diff --git a/meta/lib/oe/utils.py b/meta/lib/oe/utils.py
index 69ca8987f3d..430e874d90a 100644
--- a/meta/lib/oe/utils.py
+++ b/meta/lib/oe/utils.py
@@ -264,10 +264,17 @@ def execute_pre_post_process(d, cmds):
 bb.note("Executing %s ..." % cmd)
 bb.build.exec_func(cmd, d)
 
-# For each item in items, call the function 'target' with item as the first 
+def multiprocess_launch_max_process(d):
+return int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
+
+def multiprocess_launch(target, items, d, extraargs=None):
+max_process = multiprocess_launch_max_process(d)
+return multiprocess_launch_mp(target, items, max_process, extraargs)
+
+# For each item in items, call the function 'target' with item as the first
 # argument, extraargs as the other arguments and handle any exceptions in the
 # parent thread
-def multiprocess_launch(target, items, d, extraargs=None):
+def multiprocess_launch_mp(target, items, max_process, extraargs=None):
 
 class ProcessLaunch(multiprocessing.Process):
 def __init__(self, *args, **kwargs):
@@ -302,7 +309,6 @@ def multiprocess_launch(target, items, d, extraargs=None):
 self.update()
 return self._result
 
-max_process = int(d.getVar("BB_NUMBER_THREADS") or os.cpu_count() or 1)
 launched = []
 errors = []
 results = []
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186788): 
https://lists.openembedded.org/g/openembedded-core/message/186788
Mute This Topic: https://lists.openembedded.org/mt/100996589/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 v4 06/13] tests: add a C++ example recipe

2023-08-27 Thread Adrian Freihofer
This simple C++ project supports compilation with cmake and with meson.
It's supposed to be used with oe-selftest for the devtool ide plugin.

Signed-off-by: Adrian Freihofer 
---
 meta-selftest/recipes-test/cpp/.gitignore |  1 +
 .../recipes-test/cpp/cmake-example.bb | 17 ++
 .../recipes-test/cpp/cmake-example/run-ptest  | 10 
 .../recipes-test/cpp/cpp-example.inc  | 24 
 .../recipes-test/cpp/files/CMakeLists.txt | 60 +++
 .../cpp/files/cpp-example-lib.cpp | 17 ++
 .../cpp/files/cpp-example-lib.hpp | 16 +
 .../recipes-test/cpp/files/cpp-example.cpp| 16 +
 .../recipes-test/cpp/files/meson.build| 34 +++
 .../cpp/files/test-cpp-example.cpp| 19 ++
 .../recipes-test/cpp/meson-example.bb | 17 ++
 .../recipes-test/cpp/meson-example/run-ptest  | 10 
 12 files changed, 241 insertions(+)
 create mode 100644 meta-selftest/recipes-test/cpp/.gitignore
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/cmake-example/run-ptest
 create mode 100644 meta-selftest/recipes-test/cpp/cpp-example.inc
 create mode 100644 meta-selftest/recipes-test/cpp/files/CMakeLists.txt
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example-lib.hpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/files/meson.build
 create mode 100644 meta-selftest/recipes-test/cpp/files/test-cpp-example.cpp
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example.bb
 create mode 100644 meta-selftest/recipes-test/cpp/meson-example/run-ptest

diff --git a/meta-selftest/recipes-test/cpp/.gitignore 
b/meta-selftest/recipes-test/cpp/.gitignore
new file mode 100644
index 000..30d388a12b7
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/.gitignore
@@ -0,0 +1 @@
+build*
\ No newline at end of file
diff --git a/meta-selftest/recipes-test/cpp/cmake-example.bb 
b/meta-selftest/recipes-test/cpp/cmake-example.bb
new file mode 100644
index 000..96d543180b4
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example.bb
@@ -0,0 +1,17 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+SUMMARY = "A C++ example compiled with cmake."
+
+inherit cmake
+
+require cpp-example.inc
+
+SRC_URI += "\
+file://CMakeLists.txt \
+"
+
+FILES:${PN}-ptest += "${bindir}/test-cmake-example"
diff --git a/meta-selftest/recipes-test/cpp/cmake-example/run-ptest 
b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
new file mode 100644
index 000..94b620a1984
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cmake-example/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+test-cmake-example
+
+# Note: run-ptests exits with exit value from test-cmake-example
diff --git a/meta-selftest/recipes-test/cpp/cpp-example.inc 
b/meta-selftest/recipes-test/cpp/cpp-example.inc
new file mode 100644
index 000..39c61cf4ceb
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/cpp-example.inc
@@ -0,0 +1,24 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
+
+inherit ptest
+
+DEPENDS += "json-c"
+
+PV = "1.0"
+
+S = "${WORKDIR}"
+
+SRC_URI = "\
+file://cpp-example.cpp \
+file://cpp-example-lib.hpp \
+file://cpp-example-lib.cpp \
+file://test-cpp-example.cpp \
+file://run-ptest \
+"
diff --git a/meta-selftest/recipes-test/cpp/files/CMakeLists.txt 
b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
new file mode 100644
index 000..839aa59b5e3
--- /dev/null
+++ b/meta-selftest/recipes-test/cpp/files/CMakeLists.txt
@@ -0,0 +1,60 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+cmake_minimum_required(VERSION 3.22)
+
+project(cmake-example
+  VERSION 1.0.0
+  LANGUAGES CXX
+)
+
+option(BUILD_SHARED_LIBS "Build using shared libraries" ON)
+
+set(CMAKE_CXX_STANDARD 17)
+set(CMAKE_CXX_STANDARD_REQUIRED On)
+set(CMAKE_CXX_EXTENSIONS Off)
+
+include(GNUInstallDirs)
+
+# Find json-c
+# find_package(PkgConfig REQUIRED)
+# pkg_check_modules(JSONC REQUIRED json-c)
+find_package(json-c)
+
+# A simple library linking json-c library found by pkgconfig
+add_library(cmake-example-lib cpp-example-lib.cpp cpp-example-lib.hpp)
+set_target_properties(cmake-example-lib PROPERTIES 
+VERSION ${PROJECT_VERSION}
+SOVERSION ${PROJECT_VERSION_MAJOR}
+)
+target_link_libraries(cmake-example-lib PRIVATE json-c::json-c)
+# target_link_libraries(cmake-example-lib ${JSONC_LIBRARIES})
+# target_include_directories(cmake-example-lib PUBLIC ${JSONC_INCLUDE_DIRS})
+# target_compile_options(cmake-example-lib PUBLIC 

[OE-core] [PATCH v4 05/13] devtool: new ide plugin

2023-08-27 Thread Adrian Freihofer
The new devtool ide plugin configures an IDE to work with the eSDK.

With this initial implementation VSCode is the default IDE.
The plugin works for recipes inheriting the cmake or the meson bbclass.
Support for more programming languages and build tools may be added in
the future.

Using the plugin in recipe modes:
$ devtool modify a-recipe
$ devtool ide a-recipe a-image
$ code "$BUILDDIR/workspace/sources/a-recipe"
Work in VSCode, after installing the proposed plugins

Using the plugin without a recipe
$ devtool ide none a-image
vscode where/the/sources/are
Use the cross tool-chain which is provided as a cmake-kit.

The goal of this implementation is to create a configuration for VSCode
(or other IDEs) that allows to work on the code of a recipe completely
independent from bitbake. bitbake is only called if the configuration or
the whole SDK has to be regenerated. But bitbake should not need to be
called while working in the IDE. This has two major advantages over
calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example.
  These features are usable, which would not be the case if bitbake or
  devtool are called from within the IDE.
- It is much faster.

Signed-off-by: Adrian Freihofer 
---
 scripts/lib/devtool/ide.py | 1190 
 1 file changed, 1190 insertions(+)
 create mode 100755 scripts/lib/devtool/ide.py

diff --git a/scripts/lib/devtool/ide.py b/scripts/lib/devtool/ide.py
new file mode 100755
index 000..7c7040232c4
--- /dev/null
+++ b/scripts/lib/devtool/ide.py
@@ -0,0 +1,1190 @@
+#! /usr/bin/env python3
+#
+# Copyright (C) 2023 Siemens AG
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+"""Devtool ide plugin"""
+
+import os
+import stat
+import logging
+import json
+import re
+import shutil
+from argparse import RawTextHelpFormatter
+from enum import IntEnum, auto
+
+import bb
+from devtool import exec_build_env_command, setup_tinfoil, 
check_workspace_recipe, DevtoolError, parse_recipe
+from devtool.standard import get_real_srctree
+
+SHARED_SYSROOT_RECIPES = ['none', 'meta-ide-support', 'build-sysroots']
+SUPPORTED_IDES = ['code', 'none']
+
+logger = logging.getLogger('devtool')
+
+
+class TargetDevice:
+"""SSH remote login parameters"""
+
+def __init__(self, args):
+self.extraoptions = ''
+if args.no_host_check:
+self.extraoptions += '-o UserKnownHostsFile=/dev/null -o 
StrictHostKeyChecking=no'
+self.ssh_sshexec = 'ssh'
+if args.ssh_exec:
+self.ssh_sshexec = args.ssh_exec
+self.ssh_port = ''
+if args.port:
+self.ssh_port = "-p %s" % args.port
+if args.key:
+self.extraoptions += ' -i %s' % args.key
+
+self.target = args.target
+target_sp = args.target.split('@')
+if len(target_sp) == 1:
+self.login = ""
+self.host = target_sp[0]
+elif len(target_sp) == 2:
+self.login = target_sp[0]
+self.host = target_sp[1]
+else:
+logger.error("Invalid target argument: %s" % args.target)
+
+
+class RecipeNative:
+def __init__(self, name, target_arch=None):
+self.name = name
+self.target_arch = target_arch
+self.bootstrap_tasks = [self.name + ':do_addto_recipe_sysroot']
+self.staging_bindir_native = None
+self.target_sys = None
+self.__native_bin = None
+
+def initialize(self, config, workspace, tinfoil):
+recipe_d = parse_recipe(
+config, tinfoil, self.name, appends=True, filter_workspace=False)
+if not recipe_d:
+raise DevtoolError("Parsing %s recipe failed" % self.name)
+self.staging_bindir_native = os.path.realpath(
+recipe_d.getVar('STAGING_BINDIR_NATIVE'))
+self.target_sys = recipe_d.getVar('TARGET_SYS')
+
+@property
+def native_bin(self):
+if not self.__native_bin:
+raise DevtoolError("native binary name is not defined.")
+return self.__native_bin
+
+
+class RecipeGdbCross(RecipeNative):
+def __init__(self, args, target_arch, target_device, gdbserver_multi=True):
+super().__init__('gdb-cross-' + target_arch, target_arch)
+self.target_device = target_device
+self.gdb = None
+self.gdbserver_port_next = int(args.gdbserver_port_start)
+self.gdbserver_multi = gdbserver_multi
+self.config_db = {}
+
+def initialize(self, config, workspace, tinfoil):
+super().initialize(config, workspace, tinfoil)
+gdb_bin = self.target_sys + '-gdb'
+gdb_path = os.path.join(
+self.staging_bindir_native, self.target_sys, gdb_bin)
+self.gdb = gdb_path
+
+@property
+def host(self):
+return self.target_device.host
+
+def __gdbserver_start_cmd(self, binary, port):
+if self.gdbserver_multi:
+gdbserver_cmd = "/usr/bin/gdbserver --multi :%s" % (

[OE-core] [PATCH v4 02/13] cmake.bbclass: refactor cmake args

2023-08-27 Thread Adrian Freihofer
Make the details of the cmake configure arguments available to
d.getVar(). This allows to share them with devtool via tinfoil.

Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 43 +--
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index 0dda104a695..7c40df4cdbf 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -158,6 +158,29 @@ CONFIGURE_FILES = "CMakeLists.txt"
 
 do_configure[cleandirs] = "${@d.getVar('B') if d.getVar('S') != d.getVar('B') 
else ''}"
 
+OECMAKE_ARGS = "\
+-DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
+-DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
+
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
+-DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
+-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
+-DPYTHON_EXECUTABLE:PATH=${PYTHON} \
+-DPython_EXECUTABLE:PATH=${PYTHON} \
+-DPython3_EXECUTABLE:PATH=${PYTHON} \
+-DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
+-DCMAKE_INSTALL_SO_NO_EXE=0 \
+-DCMAKE_TOOLCHAIN_FILE:FILEPATH=${WORKDIR}/toolchain.cmake \
+-DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
+-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
+-DFETCHCONTENT_FULLY_DISCONNECTED=ON \
+-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON \
+"
+
 cmake_do_configure() {
if [ "${OECMAKE_BUILDPATH}" ]; then
bbnote "cmake.bbclass no longer uses OECMAKE_BUILDPATH.  The 
default behaviour is now out-of-tree builds with B=WORKDIR/build."
@@ -178,25 +201,7 @@ cmake_do_configure() {
  ${OECMAKE_GENERATOR_ARGS} \
  $oecmake_sitefile \
  ${OECMAKE_SOURCEPATH} \
- -DCMAKE_INSTALL_PREFIX:PATH=${prefix} \
- -DCMAKE_INSTALL_BINDIR:PATH=${@os.path.relpath(d.getVar('bindir'), 
d.getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_SBINDIR:PATH=${@os.path.relpath(d.getVar('sbindir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_LIBEXECDIR:PATH=${@os.path.relpath(d.getVar('libexecdir'), 
d.getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_SYSCONFDIR:PATH=${sysconfdir} \
- 
-DCMAKE_INSTALL_SHAREDSTATEDIR:PATH=${@os.path.relpath(d.getVar('sharedstatedir'),
 d.  getVar('prefix') + '/')} \
- -DCMAKE_INSTALL_LOCALSTATEDIR:PATH=${localstatedir} \
- -DCMAKE_INSTALL_LIBDIR:PATH=${@os.path.relpath(d.getVar('libdir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_INCLUDEDIR:PATH=${@os.path.relpath(d.getVar('includedir'), 
d.getVar('prefix') + '/')} \
- 
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix') + '/')} \
- -DPYTHON_EXECUTABLE:PATH=${PYTHON} \
- -DPython_EXECUTABLE:PATH=${PYTHON} \
- -DPython3_EXECUTABLE:PATH=${PYTHON} \
- -DLIB_SUFFIX=${@d.getVar('baselib').replace('lib', '')} \
- -DCMAKE_INSTALL_SO_NO_EXE=0 \
- -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
- -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
- -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON \
- -DFETCHCONTENT_FULLY_DISCONNECTED=ON \
+ ${OECMAKE_ARGS} \
  ${EXTRA_OECMAKE} \
  -Wno-dev
 }
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186782): 
https://lists.openembedded.org/g/openembedded-core/message/186782
Mute This Topic: https://lists.openembedded.org/mt/100996578/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 v4 03/13] cmake.bbclass: cleanup spaces and tabs

2023-08-27 Thread Adrian Freihofer
Signed-off-by: Adrian Freihofer 
---
 meta/classes-recipe/cmake.bbclass | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/cmake.bbclass 
b/meta/classes-recipe/cmake.bbclass
index 7c40df4cdbf..c63b0a80b18 100644
--- a/meta/classes-recipe/cmake.bbclass
+++ b/meta/classes-recipe/cmake.bbclass
@@ -90,12 +90,14 @@ def map_host_arch_to_uname_arch(host_arch):
 return "ppc64"
 return host_arch
 
+
 cmake_do_generate_toolchain_file() {
if [ "${BUILD_SYS}" = "${HOST_SYS}" ]; then
cmake_crosscompiling="set( CMAKE_CROSSCOMPILING FALSE )"
-   else
-   cmake_sysroot="set( CMAKE_SYSROOT \"${RECIPE_SYSROOT}\" )"
+   else
+   cmake_sysroot="set( CMAKE_SYSROOT \"${RECIPE_SYSROOT}\" )"
fi
+
cat > ${WORKDIR}/toolchain.cmake <
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186783): 
https://lists.openembedded.org/g/openembedded-core/message/186783
Mute This Topic: https://lists.openembedded.org/mt/100996581/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 v4 00/13] devtool ide plugin

2023-08-27 Thread Adrian Freihofer
Changes in comparison to v3:
- Add workspace/attic fodler to vscode ignore lists.

Changes in comparison to v2:
- Fix the oe-selftests to run on a mchine without vscode installed


According to 
https://www.yoctoproject.org/community/yocto-project-engineering-request-for-quotation/
one of the proposed areas for development of the Yocto project is "VSCode IDE 
Integration - New developer tooling".
One aspect of this larger topic is helping application developers configure the 
IDE to work on a recipe's source code using Yocto's eSDK. This patchset 
provides a new devtool plugin (devtool ide) that does this fully automatically 
for recipes inheriting the cmake or the meson bbclass. Support for more 
programming languages and build tools may be added in the future.

Let's start with a brief introduction of how it looks like from a user's 
perspective.

Reference setup
---

$ . oe-init-build-env

Add the following layers to bblayers.conf file:
- meta
- meta-poky
- meta-yocto-bsp
- meta-selftest
  
Add the following to the local.conf

IMAGE_CLASSES += "image-combined-dbg"
IMAGE_GEN_DEBUGFS = "1"
IMAGE_FEATURES += "ssh-server-dropbear debug-tweaks"
IMAGE_INSTALL:append = "\
cmake-example-ptest \
meson-example-ptest \
gdbserver \
"

Working on a recipe
---

Note for those who "hate cmake with passion": Replace cmake by meson in the 
following commands.

1. Add the recipe which should be modified to the workspace

   $ devtool modify cmake-example

2. Build the eSDK. This provides all the host tools as well as an image which 
can be used on the target device.
   Since everything is built with one bitbake command also all the debug 
symbols are expected to be consistent.

   $ devtool ide cmake-example core-image-minimal

3. Install the image on the target device or simply use Qemu

   $ runqemu

4. Start VSCode

   $ code "$BUILDDIR/workspace/sources/cmake-example"

5. Work in VSCode, after installing the proposed plugins

   Ctrl + Shift + p, cmake Select Configure Preset
   Ctrl + Shift + p, cmake Build

6. Execute the unit tests on the host works with Qemu even for cross compiled 
test executables.

   Ctrl + Shift + p, cmake Test

7. Remote debugging with GDB

   Ctrl + Shift + p, Run Task --> install && deploy-target cmake-example
   F5 (Debug configuration might be selected before)

8. Work on the recipes and call bitbake again to get the SDK updated.
   Building the application by calling cmake (from the IDE) or by calling 
bitbake or by calling devtool build is expected to produce the exact same 
results. To make that possible, the devtool ide plugin is designed to configure 
the IDE to call cmake with the exact same configuration as used by bitbake when 
building the recipe. Unlike the eSDK, the goal here is clearly that there is no 
longer a separation between the SDK and the application development process. 
Regardless of which tool is called, the same source files are edited and the 
same o-files are generated and re-used.

Working with a SDK without a recipe
---

If devtool ide is called for a recipe named none or meta-ide-support the eSDK 
with its generic environment file gets generated.
In case of using VSCode and cmake in addition to the well known environment 
file a cmake-kit
https://vector-of-bool.github.io/docs/vscode-cmake-tools/kits.html is added to 
the User-Local Kits.
This allows to work with cmake calling the cross-toolchain out of VSCode or a 
shell with the environment file sourced.

Design
--

The goal of this implementation is to create a configuration for VSCode (or 
other IDEs) that allows to work on the code of a recipe completely independent 
from bitbake. bitbake is only called if the configuration or the whole SDK has 
to be regenerated. But bitbake should not need to be called while working in 
the IDE. This has two major advantages over calling devtool build from the IDE:
- The IDE provides plugins for integration with cmake, for example. These 
features are usable, which would not be the case if bitbake or devtool are 
called from within the IDE.
- It is much faster.

Supporting other IDEs
-

Focus is currently VSCode. But a paramter "--ide=none" is already supported.
With this paramter passed, no VSCode specific config files are generated.
Instead, simple scripts are generated, which should be suitable for integration 
with other IDEs.

Testing
---

Reasonable but not yet complete test coverage is provided by:

$ oe-selftest -r devtool.DevtoolIdeTests

What's next?


- There is still a lot of room for improvement. But nonetheless, it provides a 
first implementation that could be integrated into the core, I think. 
Unfortunately there was no feedback on my RFC at 
https://lists.openembedded.org/g/openembedded-core/message/183819 so far.
- Support for more build-tools and programming languages as well as more IDEs 
should be possible. To prove the extendability 2 

[OE-core] [PATCH v4 01/13] vscode: add minimal configuration

2023-08-27 Thread Adrian Freihofer
It is essential to configure VSCode indexer plugins to ignore the build
folder of bitbake. Otherwise, the indexer plugins run with 100% CPU load
until an OOM exception occurs. In practice, this makes VSCode more or
less unusable for working with Yocto until a file like the one added by
this commit is deployed before VSCode starts. From the user's point of
view, it is not obvious why the system runs at 100% CPU load and
eventually crashes.

It is even more misleading that VSCode starts the indexers immediately,
but does not stop or reconfigure them when the ignore list is updated.
In practice, this means that every time the ignore list is changed,
VSCode immediately starts indexing the build folder until the OOM
exception stops it. Depending on the system's OOM handler, the entire
build machine may crash.
Particularly annoying is the Python plugin that ignores the general
ignore list and requires an extra ignore section.

The settings are suitable for workflows like bitbake, devtool modify,
devtool reset. The settings are not intended to work on the source code
of a recipe. It is assumed that a separate instance of VSCode is used
per workspace folder. These per workspace instances can have different
settings depending on the details of the sources that come with the
recipe. The new devtool ide plugin will generate settings to match this.

Signed-off-by: Adrian Freihofer 
---
 .gitignore|  2 ++
 .vscode/settings.json | 32 
 2 files changed, 34 insertions(+)
 create mode 100644 .vscode/settings.json

diff --git a/.gitignore b/.gitignore
index 8f48d452dab..f6ce090b5fc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,3 +36,5 @@ _toaster_clones/
 downloads/
 sstate-cache/
 toaster.sqlite
+.vscode/
+vscode-bitbake-build/
diff --git a/.vscode/settings.json b/.vscode/settings.json
new file mode 100644
index 000..517a86d1bfa
--- /dev/null
+++ b/.vscode/settings.json
@@ -0,0 +1,32 @@
+{
+"files.watcherExclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true,
+"**/workspace/attic/**": true
+},
+"files.exclude": {
+"**/.git/**": true,
+"**/cache/**": true,
+"**/tmp*/**": true,
+"**/downloads/**": true,
+"**/sstate-cache/**": true,
+"**/vscode-bitbake-build/**": true,
+"**/workspace/sources/**": true,
+"**/workspace/attic/**": true
+},
+"python.analysis.exclude": [
+"**/.git/**",
+"**/cache/**",
+"**/tmp*/**",
+"**/downloads/**",
+"**/sstate-cache/**",
+"**/vscode-bitbake-build/**",
+"**/workspace/sources/**",
+"**/workspace/attic/**"
+]
+}
-- 
2.41.0


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



[OE-core] [meta-oe][PATCH] volatile-binds: Calculate the name of the /var/lib service

2023-08-27 Thread Stéphane Veyret
By default, /var/lib is bind mounted on /var/volatile/lib. If this is
the case, the recipe adds conditions on systemd-random-seed in the
service file mounting it. But as the VOLATILE_BINDS may be modified,
/var/lib may be mounted elsewhere, for example in /persistent/var/lib.
In this case, the conditions are not set because the service file name
does not match expected one.
This patch automatically records the name of the service mounting
/var/lib, if any, in order to set the condition in the appropriate file.

Signed-off-by: Stéphane Veyret 
---
 meta/recipes-core/volatile-binds/volatile-binds.bb | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
b/meta/recipes-core/volatile-binds/volatile-binds.bb
index 3fefa9abde..7a3f53c3ed 100644
--- a/meta/recipes-core/volatile-binds/volatile-binds.bb
+++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
@@ -48,6 +48,7 @@ do_compile () {
 
 servicefile="${spec#/}"
 servicefile="$(echo "$servicefile" | tr / -).service"
+[ "${mountpoint}" = /var/lib ] && var_lib_servicefile=$servicefile
 sed -e "s#@what@#$spec#g; s#@where@#$mountpoint#g" \
 -e "s#@whatparent@#${spec%/*}#g; 
s#@whereparent@#${mountpoint%/*}#g" \
 -e "s#@avoid_overlayfs@#${@d.getVar('AVOID_OVERLAYFS')}#g" \
@@ -56,12 +57,12 @@ do_compile () {
 ${@d.getVar('VOLATILE_BINDS').replace("\\n", "\n")}
 END
 
-if [ -e var-volatile-lib.service ]; then
+if [ -n ${var_lib_servicefile} ] && [ -e ${var_lib_servicefile} ]; then
 # As the seed is stored under /var/lib, ensure that this service runs
 # after the volatile /var/lib is mounted.
 sed -i -e "/^Before=/s/\$/ systemd-random-seed.service/" \
-e "/^WantedBy=/s/\$/ systemd-random-seed.service/" \
-   var-volatile-lib.service
+   ${var_lib_servicefile}
 fi
 }
 do_compile[dirs] = "${WORKDIR}"
-- 
2.41.0


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



[OE-core] [meta-oe][PATCH] volatile-binds: Allow creation of subdirectories

2023-08-27 Thread Stéphane Veyret
The mount-copybind script will create the parent directory of the bind
mount if it does not exist. But actually, if this is the case, the
service will not even start because of the ConditionPathIsReadWrite.
This patch adds a "or" condition to allow the service to start also if
the parent directory of the bind mount does not exist.

Signed-off-by: Stéphane Veyret 
---
 .../volatile-binds/files/volatile-binds.service.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/volatile-binds/files/volatile-binds.service.in 
b/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
index 52384c8264..5a0055bec3 100644
--- a/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
+++ b/meta/recipes-core/volatile-binds/files/volatile-binds.service.in
@@ -3,7 +3,8 @@ Description=Bind mount volatile @where@
 DefaultDependencies=no
 Before=local-fs.target
 RequiresMountsFor=@whatparent@ @whereparent@
-ConditionPathIsReadWrite=@whatparent@
+ConditionPathIsReadWrite=|@whatparent@
+ConditionPathExists=|!@whatparent@
 ConditionPathExists=@where@
 ConditionPathIsReadWrite=!@where@
 
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186778): 
https://lists.openembedded.org/g/openembedded-core/message/186778
Mute This Topic: https://lists.openembedded.org/mt/100993740/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] qemu: Fix CVE-2023-40360

2023-08-27 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 ...w-nvme-fix-null-pointer-access-in-di.patch | 39 +++
 2 files changed, 40 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-CVE-2023-40360-hw-nvme-fix-null-pointer-access-in-di.patch

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

file://0010-hw-pvrdma-Protect-against-buggy-or-malicious-guest-d.patch \

file://0002-linux-user-Replace-use-of-lfs64-related-functions-an.patch \

file://0001-tracetool-use-relative-paths-for-line-preprocessor-d.patch \
+  
file://0001-CVE-2023-40360-hw-nvme-fix-null-pointer-access-in-di.patch \
file://qemu-guest-agent.init \
file://qemu-guest-agent.udev \
"
diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-CVE-2023-40360-hw-nvme-fix-null-pointer-access-in-di.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2023-40360-hw-nvme-fix-null-pointer-access-in-di.patch
new file mode 100644
index 000..731b0281f43
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-CVE-2023-40360-hw-nvme-fix-null-pointer-access-in-di.patch
@@ -0,0 +1,39 @@
+From 83dd3da9fac872fac9739b9dcb96232c93675824 Mon Sep 17 00:00:00 2001
+From: Klaus Jensen 
+Date: Tue, 8 Aug 2023 17:16:13 +0200
+Subject: [PATCH] CVE-2023-40360 hw/nvme: fix null pointer access in directive
+ receive
+
+nvme_directive_receive() does not check if an endurance group has been
+configured (set) prior to testing if flexible data placement is enabled
+or not.
+
+Fix this.
+
+CVE: CVE-2023-40360
+Upstream-Status: Backport 
[https://gitlab.com/birkelund/qemu/-/commit/6c8f8456cb0b239812dee5211881426496da7b98]
+Cc: qemu-sta...@nongnu.org
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1815
+Fixes: 73064edfb864 ("hw/nvme: flexible data placement emulation")
+Reviewed-by: Jesper Wendel Devantier 
+Signed-off-by: Klaus Jensen 
+---
+ hw/nvme/ctrl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
+index 2097fb131..36a2846c3 100644
+--- a/hw/nvme/ctrl.c
 b/hw/nvme/ctrl.c
+@@ -6862,7 +6862,7 @@ static uint16_t nvme_directive_receive(NvmeCtrl *n, 
NvmeRequest *req)
+ case NVME_DIRECTIVE_IDENTIFY:
+ switch (doper) {
+ case NVME_DIRECTIVE_RETURN_PARAMS:
+-if (ns->endgrp->fdp.enabled) {
++if (ns->endgrp && ns->endgrp->fdp.enabled) {
+ id.supported |= 1 << NVME_DIRECTIVE_DATA_PLACEMENT;
+ id.enabled |= 1 << NVME_DIRECTIVE_DATA_PLACEMENT;
+ id.persistent |= 1 << NVME_DIRECTIVE_DATA_PLACEMENT;
+-- 
+2.42.0
+
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186777): 
https://lists.openembedded.org/g/openembedded-core/message/186777
Mute This Topic: https://lists.openembedded.org/mt/100993659/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/2] inetutils: Apply devtool formatting suggestions

2023-08-27 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 meta/recipes-connectivity/inetutils/inetutils_2.4.bb | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb 
b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
index 19fc3bfde68..85e9f642b30 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_2.4.bb
@@ -15,7 +15,7 @@ SRC_URI[sha256sum] = 
"1789d6b1b1a57dfe2a7ab7b533ee9f5dfd9cbf5b59bb1bb3c2612ed08d
 SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.xz \

file://inetutils-1.8-0001-printf-parse-pull-in-features.h-for-__GLIBC__.patch \
file://inetutils-1.8-0003-wchar.patch \
-   file://rexec.xinetd.inetutils  \
+   file://rexec.xinetd.inetutils \
file://rlogin.xinetd.inetutils \
file://rsh.xinetd.inetutils \
file://telnet.xinetd.inetutils \
@@ -24,14 +24,13 @@ SRC_URI = "${GNU_MIRROR}/inetutils/inetutils-${PV}.tar.xz \
file://inetutils-only-check-pam_appl.h-when-pam-enabled.patch \

file://0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch \
file://0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch \
-"
+   ${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', '', 
'file://fix-disable-ipv6.patch', d)} \
+   "
 
 inherit autotools gettext update-alternatives texinfo
 
 acpaths = "-I ./m4"
 
-SRC_URI += "${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', '', 
'file://fix-disable-ipv6.patch', d)}"
-
 PACKAGECONFIG ??= "ftp uucpd \
${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'ipv6', 'ipv6 
ping6', '', d)} \
-- 
2.42.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#186776): 
https://lists.openembedded.org/g/openembedded-core/message/186776
Mute This Topic: https://lists.openembedded.org/mt/100993487/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/2] inetutils: Fix CVE-2023-40303

2023-08-27 Thread Khem Raj
Signed-off-by: Khem Raj 
---
 ...tpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch | 279 ++
 ...03-Indent-changes-in-previous-commit.patch | 253 
 .../inetutils/inetutils_2.4.bb|   2 +
 3 files changed, 534 insertions(+)
 create mode 100644 
meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
 create mode 100644 
meta/recipes-connectivity/inetutils/inetutils/0002-CVE-2023-40303-Indent-changes-in-previous-commit.patch

diff --git 
a/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
 
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
new file mode 100644
index 000..70bd98897de
--- /dev/null
+++ 
b/meta/recipes-connectivity/inetutils/inetutils/0001-CVE-2023-40303-ftpd-rcp-rlogin-rsh-rshd-uucpd-fix-ch.patch
@@ -0,0 +1,279 @@
+From 703418fe9d2e3b1e8d594df5788d8001a8116265 Mon Sep 17 00:00:00 2001
+From: Jeffrey Bencteux 
+Date: Fri, 30 Jun 2023 19:02:45 +0200
+Subject: [PATCH] CVE-2023-40303: ftpd,rcp,rlogin,rsh,rshd,uucpd: fix: check
+ set*id() return values
+
+Several setuid(), setgid(), seteuid() and setguid() return values
+were not checked in ftpd/rcp/rlogin/rsh/rshd/uucpd code potentially
+leading to potential security issues.
+
+CVE: CVE-2023-40303
+Upstream-Status: Backport 
[https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=e4e65c03f4c11292a3e40ef72ca3f194c8bffdd6]
+Signed-off-by: Jeffrey Bencteux 
+Signed-off-by: Simon Josefsson 
+Signed-off-by: Khem Raj 
+---
+ ftpd/ftpd.c  | 10 +++---
+ src/rcp.c| 39 +--
+ src/rlogin.c | 11 +--
+ src/rsh.c| 25 +
+ src/rshd.c   | 20 +---
+ src/uucpd.c  | 15 +--
+ 6 files changed, 100 insertions(+), 20 deletions(-)
+
+diff --git a/ftpd/ftpd.c b/ftpd/ftpd.c
+index 92b2cca5..28dd523f 100644
+--- a/ftpd/ftpd.c
 b/ftpd/ftpd.c
+@@ -862,7 +862,9 @@ end_login (struct credentials *pcred)
+   char *remotehost = pcred->remotehost;
+   int atype = pcred->auth_type;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
++
+   if (pcred->logged_in)
+ {
+   logwtmp_keep_open (ttyline, "", "");
+@@ -1151,7 +1153,8 @@ getdatasock (const char *mode)
+ 
+   if (data >= 0)
+ return fdopen (data, mode);
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   s = socket (ctrl_addr.ss_family, SOCK_STREAM, 0);
+   if (s < 0)
+ goto bad;
+@@ -1978,7 +1981,8 @@ passive (int epsv, int af)
+   else/* !AF_INET6 */
+ ((struct sockaddr_in *) _addr)->sin_port = 0;
+ 
+-  seteuid ((uid_t) 0);
++  if (seteuid ((uid_t) 0) == -1)
++_exit (EXIT_FAILURE);
+   if (bind (pdata, (struct sockaddr *) _addr, pasv_addrlen) < 0)
+ {
+   if (seteuid ((uid_t) cred.uid))
+diff --git a/src/rcp.c b/src/rcp.c
+index 75adb253..cdcf8500 100644
+--- a/src/rcp.c
 b/src/rcp.c
+@@ -345,14 +345,23 @@ main (int argc, char *argv[])
+   if (from_option)
+ { /* Follow "protocol", send data. */
+   response ();
+-  setuid (userid);
++
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   source (argc, argv);
+   exit (errs);
+ }
+ 
+   if (to_option)
+ { /* Receive data. */
+-  setuid (userid);
++  if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
++
+   sink (argc, argv);
+   exit (errs);
+ }
+@@ -537,7 +546,11 @@ toremote (char *targ, int argc, char *argv[])
+ if (response () < 0)
+   exit (EXIT_FAILURE);
+ free (bp);
+-setuid (userid);
++
++if (setuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (setuid() 
failed)");
++  }
+   }
+ source (1, argv + i);
+ close (rem);
+@@ -630,7 +643,12 @@ tolocal (int argc, char *argv[])
+ ++errs;
+ continue;
+   }
+-  seteuid (userid);
++
++  if (seteuid (userid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (seteuid() 
failed)");
++  }
++
+ #if defined IP_TOS && defined IPPROTO_IP && defined IPTOS_THROUGHPUT
+   sslen = sizeof (ss);
+   (void) getpeername (rem, (struct sockaddr *) , );
+@@ -643,7 +661,12 @@ tolocal (int argc, char *argv[])
+ #endif
+   vect[0] = target;
+   sink (1, vect);
+-  seteuid (effuid);
++
++  if (seteuid (effuid) == -1)
++  {
++error (EXIT_FAILURE, 0, "Could not drop privileges (seteuid() 
failed)");
++  }
++
+   close (rem);
+   rem = -1;
+ #ifdef SHISHI
+@@ -1441,7 +1464,11 @@ 

[OE-core] OE-core CVE metrics for mickledore on Sun 27 Aug 2023 04:00:01 AM HST

2023-08-27 Thread Steve Sakoman
Branch: mickledore

New this week: 10 CVEs
CVE-2014-1737 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1737 *
CVE-2014-3153 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3153 *
CVE-2014-3534 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3534 *
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2022-0850 (CVSS3: 7.1 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0850 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-40283 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40283 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *
CVE-2023-40360 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 *

Removed this week: 2 CVEs
CVE-2023-2235 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2235 *
CVE-2023-32001 (CVSS3: N/A): curl:curl-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-32001 *

Full list:  Found 133 unpatched CVEs
CVE-2014-1737 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1737 *
CVE-2014-3153 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3153 *
CVE-2014-3534 (CVSS3: N/A): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3534 *
CVE-2015-8955 (CVSS3: 7.3 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-8955 *
CVE-2018-10878 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-10878 *
CVE-2020-11935 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-11935 *
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2020-25668 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25668 *
CVE-2020-2 (CVSS3: 6.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-2 *
CVE-2020-27815 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27815 *
CVE-2021-28972 (CVSS3: 6.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-28972 *
CVE-2021-3640 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3640 *
CVE-2021-3714 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2021-4083 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-4083 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-0850 (CVSS3: 7.1 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0850 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3202 (CVSS3: 7.1 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3202 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-3533 (CVSS3: 5.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3533 *
CVE-2022-3606 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3606 *
CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-3964 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3964 *
CVE-2022-3965 (CVSS3: 8.1 HIGH): ffmpeg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3965 *
CVE-2022-41858 (CVSS3: 7.1 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-41858 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2022-48425 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48425 *
CVE-2022-48502 (CVSS3: 7.1 HIGH): linux-yocto 

Re: [OE-core] [kirkstone][PATCH] Qemu: Resolve undefined reference issue in CVE-2023-2861

2023-08-27 Thread Steve Sakoman
On Sat, Aug 26, 2023 at 10:08 PM Weihmann, Konrad (Avnet Embedded)
 wrote:
>
> Hi all,
>
>
>
> this mentioned patch is needed to fix the currently broken Yocto 4.0.12 
> release.
>
> This there a plan to issue a hotfix tag release, or will this be part of the 
> next 4.0.13 in roughly 6 weeks?

The above referenced patch is in my current test queue. If all goes
well in testing it should be pushed to the poky kirkstone branch
mid-week.

> I’m also wondering how the original patch could have not failed at least two 
> times on the auto-builder (patch and release level).
> That might need to be investigated.

The fix patch mentions that the issue leads to "undefined symbol error
on certain architectures", but doesn't identify which architectures
specifically.

Siddarth, Archana: Do you know which architectures display the issue?

Once we know this, I can comment on why local and autobuilder testing
didn't catch this.  At this point all I can say is that none of the
architectures tested on my local machine or the autobuilder displayed
this issue.

Steve

> Regards
>
> Konrad
>
>
>
> We continuously commit to comply with the applicable data protection laws and 
> ensure fair and transparent processing of your personal data.
> Please read our privacy statement including an information notice and data 
> protection policy for detailed information on our website.

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



[OE-core] OE-core CVE metrics for kirkstone on Sun 27 Aug 2023 03:00:01 AM HST

2023-08-27 Thread Steve Sakoman
Branch: kirkstone

New this week: 22 CVEs
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2020-22219 (CVSS3: 9.8 CRITICAL): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2021-32292 (CVSS3: 9.8 CRITICAL): json-c 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-32292 *
CVE-2022-36648 (CVSS3: 10.0 CRITICAL): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36648 *
CVE-2022-40090 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-40090 *
CVE-2022-44840 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-44840 *
CVE-2022-45703 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-45703 *
CVE-2022-47007 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47007 *
CVE-2022-47008 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47008 *
CVE-2022-47010 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47010 *
CVE-2022-47011 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47011 *
CVE-2022-47673 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47673 *
CVE-2022-47695 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47695 *
CVE-2022-47696 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47696 *
CVE-2022-48063 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48063 *
CVE-2022-48064 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48064 *
CVE-2022-48065 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48065 *
CVE-2022-48554 (CVSS3: 5.5 MEDIUM): file:file-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48554 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *
CVE-2023-40360 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 *

Removed this week: 2 CVEs
CVE-2023-2829 (CVSS3: 7.5 HIGH): bind 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-2829 *
CVE-2023-38633 (CVSS3: 5.5 MEDIUM): librsvg:librsvg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38633 *

Full list:  Found 52 unpatched CVEs
CVE-2020-22218 (CVSS3: 7.5 HIGH): libssh2:libssh2-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22218 *
CVE-2020-22219 (CVSS3: 9.8 CRITICAL): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2021-32292 (CVSS3: 9.8 CRITICAL): json-c 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-32292 *
CVE-2021-35937 (CVSS3: 6.4 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35937 *
CVE-2021-35938 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35938 *
CVE-2021-35939 (CVSS3: 6.7 MEDIUM): rpm:rpm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-35939 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-3515 (CVSS3: 9.8 CRITICAL): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3515 *
CVE-2022-3553 (CVSS3: 6.5 MEDIUM): xserver-xorg 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3553 *
CVE-2022-3563 (CVSS3: 5.7 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3563 *
CVE-2022-3637 (CVSS3: 5.5 MEDIUM): bluez5 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3637 *
CVE-2022-36648 (CVSS3: 10.0 CRITICAL): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36648 *
CVE-2022-3872 (CVSS3: 8.6 HIGH): 

[OE-core] OE-core CVE metrics for dunfell on Sun 27 Aug 2023 02:00:01 AM HST

2023-08-27 Thread Steve Sakoman
Branch: dunfell

New this week: 26 CVEs
CVE-2020-21686 (CVSS3: 5.5 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-21686 *
CVE-2020-22219 (CVSS3: 9.8 CRITICAL): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2021-32292 (CVSS3: 9.8 CRITICAL): json-c 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-32292 *
CVE-2021-46174 (CVSS3: 7.5 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-46174 *
CVE-2022-29654 (CVSS3: 5.5 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-29654 *
CVE-2022-36648 (CVSS3: 10.0 CRITICAL): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36648 *
CVE-2022-40090 (CVSS3: 6.5 MEDIUM): tiff 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-40090 *
CVE-2022-44840 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-44840 *
CVE-2022-45703 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-45703 *
CVE-2022-47007 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47007 *
CVE-2022-47008 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47008 *
CVE-2022-47010 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47010 *
CVE-2022-47011 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47011 *
CVE-2022-47673 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47673 *
CVE-2022-47695 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47695 *
CVE-2022-47696 (CVSS3: 7.8 HIGH): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-47696 *
CVE-2022-48063 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48063 *
CVE-2022-48064 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48064 *
CVE-2022-48065 (CVSS3: 5.5 MEDIUM): 
binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48065 *
CVE-2022-48554 (CVSS3: 5.5 MEDIUM): file:file-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48554 *
CVE-2022-48560 (CVSS3: 7.5 HIGH): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48560 *
CVE-2022-48564 (CVSS3: 6.5 MEDIUM): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-48564 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *
CVE-2023-40360 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 *

Removed this week: 0 CVEs

Full list:  Found 122 unpatched CVEs
CVE-2020-15705 (CVSS3: 6.4 MEDIUM): grub:grub-efi:grub-efi-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15705 *
CVE-2020-21686 (CVSS3: 5.5 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-21686 *
CVE-2020-22219 (CVSS3: 9.8 CRITICAL): flac 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-22219 *
CVE-2020-25742 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25742 *
CVE-2020-25743 (CVSS3: 3.2 LOW): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25743 *
CVE-2020-27918 (CVSS3: 7.8 HIGH): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27918 *
CVE-2020-29623 (CVSS3: 3.3 LOW): webkitgtk 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29623 *
CVE-2020-35503 (CVSS3: 6.0 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 *
CVE-2020-35506 (CVSS3: 6.7 MEDIUM): qemu:qemu-native:qemu-system-native 

[OE-core] OE-core CVE metrics for master on Sun 27 Aug 2023 01:00:01 AM HST

2023-08-27 Thread Steve Sakoman
Branch: master

New this week: 4 CVEs
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *
CVE-2023-40360 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 *

Removed this week: 5 CVEs
CVE-2023-1206 (CVSS3: 5.7 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1206 *
CVE-2023-36632 (CVSS3: 7.5 HIGH): python3:python3-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-36632 *
CVE-2023-4004 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4004 *
CVE-2023-4016 (CVSS3: 5.5 MEDIUM): procps 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4016 *
CVE-2023-4147 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4147 *

Full list:  Found 28 unpatched CVEs
CVE-2019-14899 (CVSS3: 7.4 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-14899 *
CVE-2021-3714 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3714 *
CVE-2021-3864 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3864 *
CVE-2022-0400 (CVSS3: 7.5 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-0400 *
CVE-2022-1247 (CVSS3: 7.0 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-1247 *
CVE-2022-3219 (CVSS3: 3.3 LOW): gnupg:gnupg-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *
CVE-2022-33065 (CVSS3: 7.8 HIGH): libsndfile1 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-33065 *
CVE-2022-36402 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-36402 *
CVE-2022-38096 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-38096 *
CVE-2022-4543 (CVSS3: 5.5 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4543 *
CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *
CVE-2023-0687 (CVSS3: 9.8 CRITICAL): glibc 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0687 *
CVE-2023-1386 (CVSS3: 7.8 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-1386 *
CVE-2023-28736 (CVSS3: 6.7 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28736 *
CVE-2023-28938 (CVSS3: 4.4 MEDIUM): mdadm 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28938 *
CVE-2023-3019 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3019 *
CVE-2023-3180 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3180 *
CVE-2023-3354 (CVSS3: 7.5 HIGH): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3354 *
CVE-2023-3640 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3640 *
CVE-2023-36664 (CVSS3: 7.8 HIGH): ghostscript 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-36664 *
CVE-2023-3772 (CVSS3: 4.4 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3772 *
CVE-2023-3773 (CVSS3: 4.4 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-3773 *
CVE-2023-37769 (CVSS3: 6.5 MEDIUM): pixman:pixman-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-37769 *
CVE-2023-4010 (CVSS3: 4.6 MEDIUM): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4010 *
CVE-2023-40303 (CVSS3: 7.8 HIGH): inetutils 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40303 *
CVE-2023-40360 (CVSS3: 5.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-40360 *
CVE-2023-4128 (CVSS3: 7.8 HIGH): linux-yocto 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4128 *
CVE-2023-4135 (CVSS3: 6.5 MEDIUM): qemu:qemu-native:qemu-system-native 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-4135 *

For further information see: 
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

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



[oe][OE-core][Patch 1/1] Revert "bin_package.bbclass: Inhibit the default dependencies"

2023-08-27 Thread Max Krummenacher
From: Max Krummenacher 

This reverts commit d1d09bd4d7be88f0e341d5fccbfbefeb98d4b727.

The commit not only removes the dependencies on the cross compiler
but also does not depend on e.g. virtual/${TARGET_PREFIX}compilerlibs
and virtual/libc which in turn makes the file-rdeps qa check fail
if installing binaries linked against e.g. libc or libstdc++.

Signed-off-by: Max Krummenacher 
---
 meta/classes-recipe/bin_package.bbclass | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/meta/classes-recipe/bin_package.bbclass 
b/meta/classes-recipe/bin_package.bbclass
index 9dd2489725..3a1befc29c 100644
--- a/meta/classes-recipe/bin_package.bbclass
+++ b/meta/classes-recipe/bin_package.bbclass
@@ -20,9 +20,6 @@
 # they would be in ${WORKDIR}.
 #
 
-# Nothing is being built so there is no need for the cross-compiler.
-INHIBIT_DEFAULT_DEPS = "1"
-
 # Skip the unwanted steps
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"
-- 
2.35.3


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



[oe][OE-core][Patch 0/1] Revert "bin_package.bbclass: Inhibit the default dependencies"

2023-08-27 Thread Max Krummenacher
From: Max Krummenacher 

Hi

With commit d1d09bd4d7 ("bin_package.bbclass: Inhibit the default
dependencies") applied I'm getting a lot of these errors, i.e. qa
does miss libc and compiler provided libs:

ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue: 
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs 
requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found in 
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue: 
/usr/lib/libusc.so.23.1.6404501 contained in package ti-img-rogue-umlibs 
requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in 
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]
ERROR: ti-img-rogue-umlibs-23.1.6404501-r2 do_package_qa: QA Issue: 
/usr/lib/libufwriter.so.23.1.6404501 contained in package ti-img-rogue-umlibs 
requires libstdc++.so.6(GLIBCXX_3.4.14)(64bit), but no providers found in 
RDEPENDS:ti-img-rogue-umlibs? [file-rdeps]

Reverting the commit makes the build pass, alternatively adding
to depends in the recipe which is using the bin_package class
fixes it too:

DEPENDS += " virtual/${TARGET_PREFIX}compilerlibs virtual/libc"

I'd prefer reverting removing the default dependencies over fixing
each of the recipes which do use the bin_package class to actually
install binaries running in the target user space.

Any opinions?

Max

Max Krummenacher (1):
  Revert "bin_package.bbclass: Inhibit the default dependencies"

 meta/classes-recipe/bin_package.bbclass | 3 ---
 1 file changed, 3 deletions(-)

-- 
2.35.3


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