[OE-core] [PATCH] selftest/cases/glibc.py: fix the override syntax

[Anuj Mittal]

Fix the override so we actually pass the correct value to glibc.

Signed-off-by: Anuj Mittal 
---
 meta/lib/oeqa/selftest/cases/glibc.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/glibc.py 
b/meta/lib/oeqa/selftest/cases/glibc.py
index a446543a17..4ec4b85d67 100644
--- a/meta/lib/oeqa/selftest/cases/glibc.py
+++ b/meta/lib/oeqa/selftest/cases/glibc.py
@@ -28,7 +28,7 @@ class GlibcSelfTestBase(OESelftestTestCase, 
OEPTestResultTestCase):
 features.append('TOOLCHAIN_TEST_HOST_USER = "root"')
 features.append('TOOLCHAIN_TEST_HOST_PORT = "22"')
 # force single threaded test execution
-features.append('EGLIBCPARALLELISM_task-check:pn-glibc-testsuite = 
"PARALLELMFLAGS="-j1""')
+features.append('EGLIBCPARALLELISM:task-check:pn-glibc-testsuite = 
"PARALLELMFLAGS="-j1""')
 self.write_config("\n".join(features))
 
 bitbake("glibc-testsuite -c check")
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184667): 
https://lists.openembedded.org/g/openembedded-core/message/184667
Mute This Topic: https://lists.openembedded.org/mt/100271623/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 boost upgrade?

[Thomas Roos via lists.openembedded.org]

Hi,
we are hitting an issue with boost version 1.78 and like to ask if and how 
there is a boost upgrade on kirkstone branch?
Cheers, Thomas



Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284

Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, 
USt-ID DE317013094




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184666): 
https://lists.openembedded.org/g/openembedded-core/message/184666
Mute This Topic: https://lists.openembedded.org/mt/100271099/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] curl: Refine ptest perl RDEPENDS

[Robert Joslyn]

RDEPEND on the specific perl modules required for the tests rather than
the perl-modules meta package.

Signed-off-by: Robert Joslyn 
---
 meta/recipes-support/curl/curl_8.2.0.bb | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/curl/curl_8.2.0.bb 
b/meta/recipes-support/curl/curl_8.2.0.bb
index 69597440f9..9c16d3d515 100644
--- a/meta/recipes-support/curl/curl_8.2.0.bb
+++ b/meta/recipes-support/curl/curl_8.2.0.bb
@@ -100,8 +100,23 @@ do_install_ptest() {
cp -rf ${D}${bindir}/curl-config ${D}${PTEST_PATH}
 }
 
-RDEPENDS:${PN}-ptest += "bash perl-modules perl-module-time-hires 
perl-module-digest-md5 \
- perl-module-digest perl-module-ipc-open2"
+RDEPENDS:${PN}-ptest += " \
+   bash \
+   perl-module-b \
+   perl-module-base \
+   perl-module-cwd \
+   perl-module-digest \
+   perl-module-digest-md5 \
+   perl-module-file-basename \
+   perl-module-file-spec \
+   perl-module-file-temp \
+   perl-module-io-socket \
+   perl-module-ipc-open2 \
+   perl-module-list-util \
+   perl-module-memoize \
+   perl-module-storable \
+   perl-module-time-hires \
+"
 
 PACKAGES =+ "lib${BPN}"
 
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184665): 
https://lists.openembedded.org/g/openembedded-core/message/184665
Mute This Topic: https://lists.openembedded.org/mt/100270415/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] curl: Update from 8.1.2 to 8.2.0

[Robert Joslyn]

This is a feature and bugfix update. Full release notes available at:
https://curl.se/changes.html#8_2_0

Signed-off-by: Robert Joslyn 
---
 meta/recipes-support/curl/{curl_8.1.2.bb => curl_8.2.0.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/curl/{curl_8.1.2.bb => curl_8.2.0.bb} (98%)

diff --git a/meta/recipes-support/curl/curl_8.1.2.bb 
b/meta/recipes-support/curl/curl_8.2.0.bb
similarity index 98%
rename from meta/recipes-support/curl/curl_8.1.2.bb
rename to meta/recipes-support/curl/curl_8.2.0.bb
index d84f7d0f07..69597440f9 100644
--- a/meta/recipes-support/curl/curl_8.1.2.bb
+++ b/meta/recipes-support/curl/curl_8.2.0.bb
@@ -14,7 +14,7 @@ SRC_URI = " \
 file://run-ptest \
 file://disable-tests \
 "
-SRC_URI[sha256sum] = 
"31b1118eb8bfd43cd95d9a3f146f814ff874f6ed3999b29d94f4d1e7dbac5ef6"
+SRC_URI[sha256sum] = 
"2859ec79e2cd96e976a99493547359b8001af1d1e21f3a3a3b846544ef54500f"
 
 # Curl has used many names over the years...
 CVE_PRODUCT = "haxx:curl haxx:libcurl curl:curl curl:libcurl libcurl:libcurl 
daniel_stenberg:curl"
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184664): 
https://lists.openembedded.org/g/openembedded-core/message/184664
Mute This Topic: https://lists.openembedded.org/mt/100270410/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3_M2.rc1)

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-4.3_M2.rc1. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowBoard Turbot - 32bit
2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors)
3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors)
4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors)
5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors)
6. Beaglebone

 
ETA for completion next Wednesday, July 26.
 
Best regards,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Thursday, July 20, 2023 6:54 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.3_M2.rc1)
> 
> 
> A build flagged for QA (yocto-4.3_M2.rc1) was completed on the
> autobuilder and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.3_M2.rc1
> 
> 
> Build hash information:
> 
> bitbake: 64bc00a46d1aacc23fe7e8d9a46a126f3a4bc318
> meta-agl: f1bb0ee68b18a39917e06bfbb08d677bbf8bdf25
> meta-arm: e67d9c4dbc892ef688ff960d68e02627fc99bb53
> meta-aws: 2b834db25df1dd90e2b05f89cf1ddf3790bfc220
> meta-intel: f96c815a14dab58abce5d4ce69e8fa76c9f6de3a
> meta-mingw: 4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6
> meta-openembedded: d57c4655623a7271dc93cfb741ffdbf1b511a5c2
> meta-virtualization: 680f56d9e432c0cb7de41fe50610f218bf53ba1f
> oecore: 8bb047ad3bd93fcf655eeec53e6d1de1e7747140
> poky: f73ae292bc0b92df3cb76c6e8b220f18630f6bc7
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184663): 
https://lists.openembedded.org/g/openembedded-core/message/184663
Mute This Topic: https://lists.openembedded.org/mt/100268887/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][mickledore 02/26] dmidecode: fix CVE-2023-30630

[Randy MacLeod via lists.openembedded.org]

On 2023-07-18 18:32, Steve Sakoman wrote:

On Tue, Jul 18, 2023 at 11:49 AM Randy MacLeod
  wrote:

Add Kai,

On 2023-07-14 18:32, Steve Sakoman via lists.openembedded.org wrote:

From: Yogita Urade

Dmidecode before 3.5 allows -dump-bin to overwrite a local file.
This has security relevance because, for example, execution of
Dmidecode via Sudo is plausible.

References:
https://nvd.nist.gov/vuln/detail/CVE-2023-30630
https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00016.html
https://lists.nongnu.org/archive/html/dmidecode-devel/2023-04/msg00017.html

Signed-off-by: Yogita Urade
Signed-off-by: Steve Sakoman
---
  .../dmidecode/CVE-2023-30630_1.patch  | 237 ++
  .../dmidecode/CVE-2023-30630_2.patch  |  81 ++
  .../dmidecode/CVE-2023-30630_3.patch  |  69 +
  .../dmidecode/CVE-2023-30630_4.patch  | 137 ++


Summary:

 I think this can merge but we should agree on how to handle dmidecode.


Details:

These changes work but it's bringing back 4 patches rather than bumping the 
version to 3.5
and picking up 2 patches. My conclusion is that it's okay but we should 
probably talk
about how to maintain dmidecode since it just produces a bunch of programs for 
dumping
HW DMI/SMBIOS info and doesn't provide a runtime ABI, we can probably update to 
3.5
( or even 3.6 when that's out).

Do you agree Steve?

You'll always get the same answer from me: no version bumps that
implement new features/apis.  Bug/security fixes only.

If there is a strong case to be made for something outside this
policy, it should go to the TSC for consideration.

I don't want our stable branches to start resembling the kernel
"stable" branches ...

So, yes, I think we should merge this patch rather than version bump :-)

Steve


Fine with me!




There is no change to this commit and it will be merged so
read on only if you are interested in dmidecode maintenance and
my motivations in causing this bit of noise on the list. ;-)


I checked with the dmidecode upstream (1) about their versioning scheme 
and if they
have considered having a structured release numbering scheme and even a 
stable branch.


They said they increment versions at will and don't have a stable branch 
other than latest release.
As Richard and Steve have said, we should be more conservative and if we 
find that anyone needs
the additional hardware support that I was hoping to pick up, we can 
back port patches.


Sorry for the noise,

../Randy


1)

https://lists.nongnu.org/archive/html/dmidecode-devel/2023-07/msg6.html

--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184662): 
https://lists.openembedded.org/g/openembedded-core/message/184662
Mute This Topic: https://lists.openembedded.org/mt/100151225/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] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Thu, Jul 20, 2023 at 9:19 AM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Thu, Jul 20, 2023 at 9:16 AM Petr Gotthard
>  wrote:
> >
> > > My question was about CONFIG_LOCALVERSION_AUTO being something that you
> > > changed after the first issue popped up (I understood what it was 
> > > changing from
> > > your first description) I can't clearly see if you turned it on in 
> > > response to the
> > > breakage, but I'm assuming that the answer is yes.
> >
> > Oh, sorry for the consuion. Yes, I changed the CONFIG_LOCALVERSION_AUTO 
> > only to reduce the number of suffixes.
>
> Ack'd. Thanks for confirming.
>
> I'm coming up with something that will keep 6.3+ working, and not
> break older/existing recipes.
>

I have a fix under test. I'm just running into a bit of sstate
oddities that I need to sort out!

Bruce


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


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

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

[OE-core][PATCH v2] nfs-utils: upgrade 2.6.2 -> 2.6.3

[Trevor Gamblin]

Changelog: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog

Three patches were removed as they're now upstream:

2c0b5249 Replace statfs64 with statfs
167f2336 Fix function prototypes
896946e3 mountd: Check for return of stat function

do_compile still failed after removing these patches, reporting
undefined references to 'event_base_new', 'sqlite3_open_v2', etc. This
is fixed by backporting
0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch from
upstream.

Signed-off-by: Trevor Gamblin 
---
v2 replaces the use of LDFLAGS:append with a backport from upstream that
fixes the issue by modifying configure.ac.

 .../0001-Replace-statfs64-with-statfs.patch   | 171 --
 ...event-and-libsqlite3-checked-when-nf.patch |  80 
 ...td-Check-for-return-of-stat-function.patch |  34 
 .../0006-Fix-function-prototypes.patch|  93 --
 ...{nfs-utils_2.6.2.bb => nfs-utils_2.6.3.bb} |   8 +-
 5 files changed, 84 insertions(+), 302 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
 create mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-configure.ac-libevent-and-libsqlite3-checked-when-nf.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0005-mountd-Check-for-return-of-stat-function.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0006-Fix-function-prototypes.patch
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.2.bb => 
nfs-utils_2.6.3.bb} (95%)

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
deleted file mode 100644
index 40ceff9ae9..00
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
+++ /dev/null
@@ -1,171 +0,0 @@
-From e89652b853ca7de671093ae44305fa3435e13d3d Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 15 Dec 2022 13:29:43 -0800
-Subject: [PATCH] Replace statfs64 with statfs
-
-autoconf AC_SYS_LARGEFILE is used by configure to add needed defines
-when needed for enabling 64bit off_t, therefore replacing statfs64 with
-statfs should be functionally same. Additionally this helps compiling
-with latest musl where 64bit LFS functions like statfs64 and friends are
-now moved under _LARGEFILE64_SOURCE feature test macro, this works on
-glibc systems because _GNU_SOURCE macros also enables
-_LARGEFILE64_SOURCE indirectly. This is not case with musl and this
-latest issue is exposed.
-
-Upstream-Status: Submitted 
[https://lore.kernel.org/linux-nfs/20221215213605.4061853-1-raj.k...@gmail.com/T/#u]
-Signed-off-by: Khem Raj 

- support/export/cache.c  | 14 +++---
- support/include/nfsd_path.h |  6 +++---
- support/misc/nfsd_path.c| 24 
- utils/exportfs/exportfs.c   |  4 ++--
- 4 files changed, 24 insertions(+), 24 deletions(-)
-
-diff --git a/support/export/cache.c b/support/export/cache.c
-index a5823e9..2497d4f 100644
 a/support/export/cache.c
-+++ b/support/export/cache.c
-@@ -346,27 +346,27 @@ static int uuid_by_path(char *path, int type, size_t 
uuidlen, char *uuid)
- 
-   /* Possible sources of uuid are
-* - blkid uuid
--   * - statfs64 uuid
-+   * - statfs uuid
-*
--   * On some filesystems (e.g. vfat) the statfs64 uuid is simply an
-+   * On some filesystems (e.g. vfat) the statfs uuid is simply an
-* encoding of the device that the filesystem is mounted from, so
-* it we be very bad to use that (as device numbers change).  blkid
-* must be preferred.
--   * On other filesystems (e.g. btrfs) the statfs64 uuid contains
-+   * On other filesystems (e.g. btrfs) the statfs uuid contains
-* important info that the blkid uuid cannot contain:  This happens
-* when multiple subvolumes are exported (they have the same
--   * blkid uuid but different statfs64 uuids).
-+   * blkid uuid but different statfs uuids).
-* We rely on get_uuid_blkdev *knowing* which is which and not returning
--   * a uuid for filesystems where the statfs64 uuid is better.
-+   * a uuid for filesystems where the statfs uuid is better.
-*
-*/
--  struct statfs64 st;
-+  struct statfs st;
-   char fsid_val[17];
-   const char *blkid_val = NULL;
-   const char *val;
-   int rc;
- 
--  rc = nfsd_path_statfs64(path, );
-+  rc = nfsd_path_statfs(path, );
- 
-   if (type == 0 && rc == 0) {
-   const unsigned long *bad;
-diff --git a/support/include/nfsd_path.h b/support/include/nfsd_path.h
-index 3b73aad..aa1e1dd 100644
 a/support/include/nfsd_path.h
-+++ b/support/include/nfsd_path.h
-@@ -7,7 +7,7 @@
- #include 
- 
- struct file_handle;
--struct statfs64;
-+struct statfs;
- 
- void  nfsd_path_init(void);
- 
-@@ -18,8 +18,8 @@ 

Re: [OE-core][PATCH] nfs-utils: upgrade 2.6.2 -> 2.6.3

[Trevor Gamblin]

On 2023-07-20 14:48, Alexander Kanavin wrote:

LDFLAGS issue is better addressed with a backport:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bc4a5deef9f820c55fdac3c0070364c17cd91cca

Thanks for the heads-up. v2 incoming.


Alex

On Thu, 20 Jul 2023 at 18:21, Trevor Gamblin  wrote:

Changelog: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog

Three patches were removed as they're now upstream:

2c0b5249 Replace statfs64 with statfs
167f2336 Fix function prototypes
896946e3 mountd: Check for return of stat function

do_compile still failed after removing these patches, reporting
undefined references to 'event_base_new', 'sqlite3_open_v2', etc. This
is fixed by adding the following line:

LDFLAGS:append = " -lsqlite3 -levent"

Signed-off-by: Trevor Gamblin 
---
  .../0001-Replace-statfs64-with-statfs.patch   | 171 --
  ...td-Check-for-return-of-stat-function.patch |  34 
  .../0006-Fix-function-prototypes.patch|  93 --
  ...{nfs-utils_2.6.2.bb => nfs-utils_2.6.3.bb} |   7 +-
  4 files changed, 3 insertions(+), 302 deletions(-)
  delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
  delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0005-mountd-Check-for-return-of-stat-function.patch
  delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0006-Fix-function-prototypes.patch
  rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.2.bb => 
nfs-utils_2.6.3.bb} (95%)

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
deleted file mode 100644
index 40ceff9ae9..00
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
+++ /dev/null
@@ -1,171 +0,0 @@
-From e89652b853ca7de671093ae44305fa3435e13d3d Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 15 Dec 2022 13:29:43 -0800
-Subject: [PATCH] Replace statfs64 with statfs
-
-autoconf AC_SYS_LARGEFILE is used by configure to add needed defines
-when needed for enabling 64bit off_t, therefore replacing statfs64 with
-statfs should be functionally same. Additionally this helps compiling
-with latest musl where 64bit LFS functions like statfs64 and friends are
-now moved under _LARGEFILE64_SOURCE feature test macro, this works on
-glibc systems because _GNU_SOURCE macros also enables
-_LARGEFILE64_SOURCE indirectly. This is not case with musl and this
-latest issue is exposed.
-
-Upstream-Status: Submitted 
[https://lore.kernel.org/linux-nfs/20221215213605.4061853-1-raj.k...@gmail.com/T/#u]
-Signed-off-by: Khem Raj 

- support/export/cache.c  | 14 +++---
- support/include/nfsd_path.h |  6 +++---
- support/misc/nfsd_path.c| 24 
- utils/exportfs/exportfs.c   |  4 ++--
- 4 files changed, 24 insertions(+), 24 deletions(-)
-
-diff --git a/support/export/cache.c b/support/export/cache.c
-index a5823e9..2497d4f 100644
 a/support/export/cache.c
-+++ b/support/export/cache.c
-@@ -346,27 +346,27 @@ static int uuid_by_path(char *path, int type, size_t 
uuidlen, char *uuid)
-
-   /* Possible sources of uuid are
-* - blkid uuid
--   * - statfs64 uuid
-+   * - statfs uuid
-*
--   * On some filesystems (e.g. vfat) the statfs64 uuid is simply an
-+   * On some filesystems (e.g. vfat) the statfs uuid is simply an
-* encoding of the device that the filesystem is mounted from, so
-* it we be very bad to use that (as device numbers change).  blkid
-* must be preferred.
--   * On other filesystems (e.g. btrfs) the statfs64 uuid contains
-+   * On other filesystems (e.g. btrfs) the statfs uuid contains
-* important info that the blkid uuid cannot contain:  This happens
-* when multiple subvolumes are exported (they have the same
--   * blkid uuid but different statfs64 uuids).
-+   * blkid uuid but different statfs uuids).
-* We rely on get_uuid_blkdev *knowing* which is which and not returning
--   * a uuid for filesystems where the statfs64 uuid is better.
-+   * a uuid for filesystems where the statfs uuid is better.
-*
-*/
--  struct statfs64 st;
-+  struct statfs st;
-   char fsid_val[17];
-   const char *blkid_val = NULL;
-   const char *val;
-   int rc;
-
--  rc = nfsd_path_statfs64(path, );
-+  rc = nfsd_path_statfs(path, );
-
-   if (type == 0 && rc == 0) {
-   const unsigned long *bad;
-diff --git a/support/include/nfsd_path.h b/support/include/nfsd_path.h
-index 3b73aad..aa1e1dd 100644
 a/support/include/nfsd_path.h
-+++ b/support/include/nfsd_path.h
-@@ -7,7 +7,7 @@
- #include 
-
- struct file_handle;
--struct statfs64;
-+struct statfs;
-
- void  nfsd_path_init(void);
-
-@@ -18,8 +18,8 @@ char *   

Re: [OE-core][PATCH] iproute2: upgrade 6.3.0 -> 6.4.0

[Trevor Gamblin]

On 2023-07-20 15:46, Alexander Kanavin wrote:

Please do not add Pending patches, if they're not actually pending
anything. You should submit upstream ahead of submitting to oe-core.
I'm going to attempt submitting it upstream, but I should've clarified 
that I am going to do so. I talked to the author and they said to go ahead.


Alex

On Thu, 20 Jul 2023 at 21:26, Trevor Gamblin  wrote:

Changelog: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/log/

Added a patch for including limits.h with musl builds, or else
we get failures such as:

| mdb.c: In function 'mdb_parse_vni':
| mdb.c:666:47: error: 'ULONG_MAX' undeclared (first use in this function)
|   666 | if ((endptr && *endptr) || vni_num == ULONG_MAX)
|   |   ^
| mdb.c:666:47: note: 'ULONG_MAX' is defined in header ''; did you forget 
to '#include '?

Signed-off-by: Trevor Gamblin 
---
  .../0001-bridge-mdb.c-include-limits.h.patch  | 31 +++
  .../{iproute2_6.3.0.bb => iproute2_6.4.0.bb}  |  3 +-
  2 files changed, 33 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
  rename meta/recipes-connectivity/iproute2/{iproute2_6.3.0.bb => 
iproute2_6.4.0.bb} (95%)

diff --git 
a/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
 
b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
new file mode 100644
index 00..0330163ae5
--- /dev/null
+++ 
b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
@@ -0,0 +1,31 @@
+From 3d6fee6b55992d185f3af4f254b86ea1ac11acfe Mon Sep 17 00:00:00 2001
+From: Trevor Gamblin 
+Date: Thu, 20 Jul 2023 14:32:23 -0400
+Subject: [PATCH] bridge/mdb.c: include limits.h
+
+Upstream-Status: Pending
+
+Based on
+https://git.alpinelinux.org/aports/commit/main/iproute2/include.patch?id=bd46efb8a8da54948639cebcfa5b37bd608f1069,
+but the author has no plans to submit it upstream.
+
+Signed-off-by: Trevor Gamblin 
+---
+ bridge/mdb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/bridge/mdb.c b/bridge/mdb.c
+index fbb4f704..18793458 100644
+--- a/bridge/mdb.c
 b/bridge/mdb.c
+@@ -15,6 +15,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+
+ #include "libnetlink.h"
+ #include "utils.h"
+--
+2.41.0
+
diff --git a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb 
b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
similarity index 95%
rename from meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
rename to meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
index 892fa854da..32e2f8176b 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
@@ -13,9 +13,10 @@ DEPENDS = "flex-native bison-native iptables libcap"

  SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
 file://0001-libc-compat.h-add-musl-workaround.patch \
+   file://0001-bridge-mdb.c-include-limits.h.patch \
 "

-SRC_URI[sha256sum] = 
"dfb2a98db96e7a653cffc6693335a1a466e29a34b6ac528be48f35e1d2766732"
+SRC_URI[sha256sum] = 
"4c51b8decbc7e4da159ffb066f590cfb93dbf9af7ff86b1647ce42b7c179a272"

  inherit update-alternatives bash-completion pkgconfig

--
2.41.0





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

Re: [OE-core][PATCH] iproute2: upgrade 6.3.0 -> 6.4.0

[Alexander Kanavin]

Please do not add Pending patches, if they're not actually pending
anything. You should submit upstream ahead of submitting to oe-core.

Alex

On Thu, 20 Jul 2023 at 21:26, Trevor Gamblin  wrote:
>
> Changelog: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/log/
>
> Added a patch for including limits.h with musl builds, or else
> we get failures such as:
>
> | mdb.c: In function 'mdb_parse_vni':
> | mdb.c:666:47: error: 'ULONG_MAX' undeclared (first use in this function)
> |   666 | if ((endptr && *endptr) || vni_num == ULONG_MAX)
> |   |   ^
> | mdb.c:666:47: note: 'ULONG_MAX' is defined in header ''; did you 
> forget to '#include '?
>
> Signed-off-by: Trevor Gamblin 
> ---
>  .../0001-bridge-mdb.c-include-limits.h.patch  | 31 +++
>  .../{iproute2_6.3.0.bb => iproute2_6.4.0.bb}  |  3 +-
>  2 files changed, 33 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
>  rename meta/recipes-connectivity/iproute2/{iproute2_6.3.0.bb => 
> iproute2_6.4.0.bb} (95%)
>
> diff --git 
> a/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
>  
> b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
> new file mode 100644
> index 00..0330163ae5
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
> @@ -0,0 +1,31 @@
> +From 3d6fee6b55992d185f3af4f254b86ea1ac11acfe Mon Sep 17 00:00:00 2001
> +From: Trevor Gamblin 
> +Date: Thu, 20 Jul 2023 14:32:23 -0400
> +Subject: [PATCH] bridge/mdb.c: include limits.h
> +
> +Upstream-Status: Pending
> +
> +Based on
> +https://git.alpinelinux.org/aports/commit/main/iproute2/include.patch?id=bd46efb8a8da54948639cebcfa5b37bd608f1069,
> +but the author has no plans to submit it upstream.
> +
> +Signed-off-by: Trevor Gamblin 
> +---
> + bridge/mdb.c | 1 +
> + 1 file changed, 1 insertion(+)
> +
> +diff --git a/bridge/mdb.c b/bridge/mdb.c
> +index fbb4f704..18793458 100644
> +--- a/bridge/mdb.c
>  b/bridge/mdb.c
> +@@ -15,6 +15,7 @@
> + #include 
> + #include 
> + #include 
> ++#include 
> +
> + #include "libnetlink.h"
> + #include "utils.h"
> +--
> +2.41.0
> +
> diff --git a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb 
> b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
> similarity index 95%
> rename from meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
> rename to meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
> index 892fa854da..32e2f8176b 100644
> --- a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
> +++ b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
> @@ -13,9 +13,10 @@ DEPENDS = "flex-native bison-native iptables libcap"
>
>  SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
> file://0001-libc-compat.h-add-musl-workaround.patch \
> +   file://0001-bridge-mdb.c-include-limits.h.patch \
> "
>
> -SRC_URI[sha256sum] = 
> "dfb2a98db96e7a653cffc6693335a1a466e29a34b6ac528be48f35e1d2766732"
> +SRC_URI[sha256sum] = 
> "4c51b8decbc7e4da159ffb066f590cfb93dbf9af7ff86b1647ce42b7c179a272"
>
>  inherit update-alternatives bash-completion pkgconfig
>
> --
> 2.41.0
>
>
> 
>

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

[Trevor Gamblin]

Changelog: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/log/

Added a patch for including limits.h with musl builds, or else
we get failures such as:

| mdb.c: In function 'mdb_parse_vni':
| mdb.c:666:47: error: 'ULONG_MAX' undeclared (first use in this function)
|   666 | if ((endptr && *endptr) || vni_num == ULONG_MAX)
|   |   ^
| mdb.c:666:47: note: 'ULONG_MAX' is defined in header ''; did you 
forget to '#include '?

Signed-off-by: Trevor Gamblin 
---
 .../0001-bridge-mdb.c-include-limits.h.patch  | 31 +++
 .../{iproute2_6.3.0.bb => iproute2_6.4.0.bb}  |  3 +-
 2 files changed, 33 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
 rename meta/recipes-connectivity/iproute2/{iproute2_6.3.0.bb => 
iproute2_6.4.0.bb} (95%)

diff --git 
a/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
 
b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
new file mode 100644
index 00..0330163ae5
--- /dev/null
+++ 
b/meta/recipes-connectivity/iproute2/iproute2/0001-bridge-mdb.c-include-limits.h.patch
@@ -0,0 +1,31 @@
+From 3d6fee6b55992d185f3af4f254b86ea1ac11acfe Mon Sep 17 00:00:00 2001
+From: Trevor Gamblin 
+Date: Thu, 20 Jul 2023 14:32:23 -0400
+Subject: [PATCH] bridge/mdb.c: include limits.h
+
+Upstream-Status: Pending
+
+Based on
+https://git.alpinelinux.org/aports/commit/main/iproute2/include.patch?id=bd46efb8a8da54948639cebcfa5b37bd608f1069,
+but the author has no plans to submit it upstream.
+
+Signed-off-by: Trevor Gamblin 
+---
+ bridge/mdb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/bridge/mdb.c b/bridge/mdb.c
+index fbb4f704..18793458 100644
+--- a/bridge/mdb.c
 b/bridge/mdb.c
+@@ -15,6 +15,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "libnetlink.h"
+ #include "utils.h"
+-- 
+2.41.0
+
diff --git a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb 
b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
similarity index 95%
rename from meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
rename to meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
index 892fa854da..32e2f8176b 100644
--- a/meta/recipes-connectivity/iproute2/iproute2_6.3.0.bb
+++ b/meta/recipes-connectivity/iproute2/iproute2_6.4.0.bb
@@ -13,9 +13,10 @@ DEPENDS = "flex-native bison-native iptables libcap"
 
 SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
file://0001-libc-compat.h-add-musl-workaround.patch \
+   file://0001-bridge-mdb.c-include-limits.h.patch \
"
 
-SRC_URI[sha256sum] = 
"dfb2a98db96e7a653cffc6693335a1a466e29a34b6ac528be48f35e1d2766732"
+SRC_URI[sha256sum] = 
"4c51b8decbc7e4da159ffb066f590cfb93dbf9af7ff86b1647ce42b7c179a272"
 
 inherit update-alternatives bash-completion pkgconfig
 
-- 
2.41.0


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

Re: [OE-core][PATCH] nfs-utils: upgrade 2.6.2 -> 2.6.3

[Alexander Kanavin]

LDFLAGS issue is better addressed with a backport:
http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commit;h=bc4a5deef9f820c55fdac3c0070364c17cd91cca

Alex

On Thu, 20 Jul 2023 at 18:21, Trevor Gamblin  wrote:
>
> Changelog: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog
>
> Three patches were removed as they're now upstream:
>
> 2c0b5249 Replace statfs64 with statfs
> 167f2336 Fix function prototypes
> 896946e3 mountd: Check for return of stat function
>
> do_compile still failed after removing these patches, reporting
> undefined references to 'event_base_new', 'sqlite3_open_v2', etc. This
> is fixed by adding the following line:
>
> LDFLAGS:append = " -lsqlite3 -levent"
>
> Signed-off-by: Trevor Gamblin 
> ---
>  .../0001-Replace-statfs64-with-statfs.patch   | 171 --
>  ...td-Check-for-return-of-stat-function.patch |  34 
>  .../0006-Fix-function-prototypes.patch|  93 --
>  ...{nfs-utils_2.6.2.bb => nfs-utils_2.6.3.bb} |   7 +-
>  4 files changed, 3 insertions(+), 302 deletions(-)
>  delete mode 100644 
> meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
>  delete mode 100644 
> meta/recipes-connectivity/nfs-utils/nfs-utils/0005-mountd-Check-for-return-of-stat-function.patch
>  delete mode 100644 
> meta/recipes-connectivity/nfs-utils/nfs-utils/0006-Fix-function-prototypes.patch
>  rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.2.bb => 
> nfs-utils_2.6.3.bb} (95%)
>
> diff --git 
> a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
>  
> b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
> deleted file mode 100644
> index 40ceff9ae9..00
> --- 
> a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
> +++ /dev/null
> @@ -1,171 +0,0 @@
> -From e89652b853ca7de671093ae44305fa3435e13d3d Mon Sep 17 00:00:00 2001
> -From: Khem Raj 
> -Date: Thu, 15 Dec 2022 13:29:43 -0800
> -Subject: [PATCH] Replace statfs64 with statfs
> -
> -autoconf AC_SYS_LARGEFILE is used by configure to add needed defines
> -when needed for enabling 64bit off_t, therefore replacing statfs64 with
> -statfs should be functionally same. Additionally this helps compiling
> -with latest musl where 64bit LFS functions like statfs64 and friends are
> -now moved under _LARGEFILE64_SOURCE feature test macro, this works on
> -glibc systems because _GNU_SOURCE macros also enables
> -_LARGEFILE64_SOURCE indirectly. This is not case with musl and this
> -latest issue is exposed.
> -
> -Upstream-Status: Submitted 
> [https://lore.kernel.org/linux-nfs/20221215213605.4061853-1-raj.k...@gmail.com/T/#u]
> -Signed-off-by: Khem Raj 
> 
> - support/export/cache.c  | 14 +++---
> - support/include/nfsd_path.h |  6 +++---
> - support/misc/nfsd_path.c| 24 
> - utils/exportfs/exportfs.c   |  4 ++--
> - 4 files changed, 24 insertions(+), 24 deletions(-)
> -
> -diff --git a/support/export/cache.c b/support/export/cache.c
> -index a5823e9..2497d4f 100644
>  a/support/export/cache.c
> -+++ b/support/export/cache.c
> -@@ -346,27 +346,27 @@ static int uuid_by_path(char *path, int type, size_t 
> uuidlen, char *uuid)
> -
> -   /* Possible sources of uuid are
> -* - blkid uuid
> --   * - statfs64 uuid
> -+   * - statfs uuid
> -*
> --   * On some filesystems (e.g. vfat) the statfs64 uuid is simply an
> -+   * On some filesystems (e.g. vfat) the statfs uuid is simply an
> -* encoding of the device that the filesystem is mounted from, so
> -* it we be very bad to use that (as device numbers change).  blkid
> -* must be preferred.
> --   * On other filesystems (e.g. btrfs) the statfs64 uuid contains
> -+   * On other filesystems (e.g. btrfs) the statfs uuid contains
> -* important info that the blkid uuid cannot contain:  This happens
> -* when multiple subvolumes are exported (they have the same
> --   * blkid uuid but different statfs64 uuids).
> -+   * blkid uuid but different statfs uuids).
> -* We rely on get_uuid_blkdev *knowing* which is which and not 
> returning
> --   * a uuid for filesystems where the statfs64 uuid is better.
> -+   * a uuid for filesystems where the statfs uuid is better.
> -*
> -*/
> --  struct statfs64 st;
> -+  struct statfs st;
> -   char fsid_val[17];
> -   const char *blkid_val = NULL;
> -   const char *val;
> -   int rc;
> -
> --  rc = nfsd_path_statfs64(path, );
> -+  rc = nfsd_path_statfs(path, );
> -
> -   if (type == 0 && rc == 0) {
> -   const unsigned long *bad;
> -diff --git a/support/include/nfsd_path.h b/support/include/nfsd_path.h
> -index 3b73aad..aa1e1dd 100644
>  a/support/include/nfsd_path.h
> -+++ b/support/include/nfsd_path.h
> -@@ -7,7 +7,7 @@
> - #include 
> -
> - struct file_handle;
> 

Re: [OE-core] [meta][kirkstone][PATCH] json-c: disable -Werror for x86-64

[Alexander Kanavin]

Also, does the issue occur on oe-core master?

Alex

On Thu, 20 Jul 2023 at 20:44, Alexander Kanavin  wrote:
>
> This needs to be reported upstream and the ticket linked (ideally,
> develop a patch to fix the issue). The tweak needs to be :class-native
> only.
>
> Alex
>
> On Thu, 20 Jul 2023 at 15:37, Rouven Czerwinski
>  wrote:
> >
> > From: Rouven Czerwinski 
> >
> > Disable -Werror using OECMAKE_C_FLAGS on x86-64. This ensures that json-c 
> > can
> > build on newer distributions where the host compiler is new enough to treat
> > implicit fallthrough warnings as errors:
> >   | NOTE: VERBOSE=1 cmake --build 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/build --target all --
> >   | [1/34] 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
> >  -D_GNU_SOURCE -Djson_c_EXPORTS 
> > -I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
> > -I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
> > -isystem/…/work/x86_64-linux/j
> >   son-c-native/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe 
> > -ffunction-sections -fdata-sections -Werror -Wall -Wcast-qual 
> > -Wno-error=deprecated-declarations -Wextra -Wwrite-strings 
> > -Wno-unused-parameter -Wstrict-prototypes -g -fPIC -D_REENTRANT -MD -MT 
> > CMakeFiles/json-c.dir/linkhash.c.o -MF CMakeFiles/json-c.dir/linkhash.c.o.d 
> > -o CMakeFiles/json-c.dir/linkhash.c.o -c 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c
> >   -0.15/linkhash.c
> >   | FAILED: CMakeFiles/json-c.dir/linkhash.c.o
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
> >  -D_GNU_SOURCE -Djson_c_EXPORTS 
> > -I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
> > -I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
> > -isystem/…/work/x86_64-linux/json-c-n
> >   ative/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe 
> > -ffunction-sections -fdata-sections -Werror -Wall -Wcast-qual 
> > -Wno-error=deprecated-declarations -Wextra -Wwrite-strings 
> > -Wno-unused-parameter -Wstrict-prototypes -g -fPIC -D_REENTRANT -MD -MT 
> > CMakeFiles/json-c.dir/linkhash.c.o -MF CMakeFiles/json-c.dir/linkhash.c.o.d 
> > -o CMakeFiles/json-c.dir/linkhash.c.o -c 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/l
> >   inkhash.c
> >   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c: In 
> > function 'hashlittle':
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:367:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:368:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:372:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:373:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:376:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:377:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:380:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:381:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:383:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:384:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:420:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:3: 
> > note: here
> >   | 
> > /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:13: 
> > error: this statement may fall through [-Werror=implicit-fallthrough=]
> >   | 
> > 

Re: [OE-core] [meta][kirkstone][PATCH] json-c: disable -Werror for x86-64

[Alexander Kanavin]

This needs to be reported upstream and the ticket linked (ideally,
develop a patch to fix the issue). The tweak needs to be :class-native
only.

Alex

On Thu, 20 Jul 2023 at 15:37, Rouven Czerwinski
 wrote:
>
> From: Rouven Czerwinski 
>
> Disable -Werror using OECMAKE_C_FLAGS on x86-64. This ensures that json-c can
> build on newer distributions where the host compiler is new enough to treat
> implicit fallthrough warnings as errors:
>   | NOTE: VERBOSE=1 cmake --build 
> /…/work/x86_64-linux/json-c-native/0.15-r0/build --target all --
>   | [1/34] 
> /…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
>  -D_GNU_SOURCE -Djson_c_EXPORTS 
> -I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
> -I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
> -isystem/…/work/x86_64-linux/j
>   son-c-native/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe 
> -ffunction-sections -fdata-sections -Werror -Wall -Wcast-qual 
> -Wno-error=deprecated-declarations -Wextra -Wwrite-strings 
> -Wno-unused-parameter -Wstrict-prototypes -g -fPIC -D_REENTRANT -MD -MT 
> CMakeFiles/json-c.dir/linkhash.c.o -MF CMakeFiles/json-c.dir/linkhash.c.o.d 
> -o CMakeFiles/json-c.dir/linkhash.c.o -c 
> /…/work/x86_64-linux/json-c-native/0.15-r0/json-c
>   -0.15/linkhash.c
>   | FAILED: CMakeFiles/json-c.dir/linkhash.c.o
>   | 
> /…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
>  -D_GNU_SOURCE -Djson_c_EXPORTS 
> -I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
> -I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
> -isystem/…/work/x86_64-linux/json-c-n
>   ative/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe 
> -ffunction-sections -fdata-sections -Werror -Wall -Wcast-qual 
> -Wno-error=deprecated-declarations -Wextra -Wwrite-strings 
> -Wno-unused-parameter -Wstrict-prototypes -g -fPIC -D_REENTRANT -MD -MT 
> CMakeFiles/json-c.dir/linkhash.c.o -MF CMakeFiles/json-c.dir/linkhash.c.o.d 
> -o CMakeFiles/json-c.dir/linkhash.c.o -c 
> /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/l
>   inkhash.c
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c: In 
> function 'hashlittle':
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:367:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:368:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:372:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:373:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:376:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:377:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:380:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:381:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:383:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:384:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:420:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:425:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:425:13: 
> error: this statement may fall through [-Werror=implicit-fallthrough=]
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:426:3: 
> note: here
>   | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:426:13: 
> error: this 

[OE-core] [mickledore][PATCH] tiff: upgrade to 4.5.1

[Nat Bailey via lists.openembedded.org]

From: Ross Burton 

Also remove old CVE_CHECK_IGNOREs which are no longer needed due to CPE
updates.

This is a backport from master. Mickledore had one extra CVE patch that
was not on master at the time of upgrade, so it had to be manually
removed here.

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Natasha Bailey 
---
 .../libtiff/files/CVE-2022-48281.patch|  29 
 .../libtiff/files/CVE-2023-25434.patch| 159 --
 .../libtiff/files/CVE-2023-26965.patch|  99 ---
 .../libtiff/files/CVE-2023-2731.patch |  39 -
 .../libtiff/{tiff_4.5.0.bb => tiff_4.5.1.bb}  |  14 +-
 5 files changed, 2 insertions(+), 338 deletions(-)
 delete mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2022-48281.patch
 delete mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-25434.patch
 delete mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-26965.patch
 delete mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-2731.patch
 rename meta/recipes-multimedia/libtiff/{tiff_4.5.0.bb => tiff_4.5.1.bb} (81%)

diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2022-48281.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2022-48281.patch
deleted file mode 100644
index e356d377ea..00
--- a/meta/recipes-multimedia/libtiff/files/CVE-2022-48281.patch
+++ /dev/null
@@ -1,29 +0,0 @@
-CVE: CVE-2022-48281
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From 97d65859bc29ee334012e9c73022d8a8e55ed586 Mon Sep 17 00:00:00 2001
-From: Su Laus 
-Date: Sat, 21 Jan 2023 15:58:10 +
-Subject: [PATCH] tiffcrop: Correct simple copy paste error. Fix #488.
-

- tools/tiffcrop.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
-index 14fa18da..7db69883 100644
 a/tools/tiffcrop.c
-+++ b/tools/tiffcrop.c
-@@ -8591,7 +8591,7 @@ static int processCropSelections(struct image_data 
*image,
- cropsize + NUM_BUFF_OVERSIZE_BYTES);
- else
- {
--prev_cropsize = seg_buffs[0].size;
-+prev_cropsize = seg_buffs[i].size;
- if (prev_cropsize < cropsize)
- {
- next_buff = _TIFFrealloc(
--- 
-GitLab
-
diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2023-25434.patch 
b/meta/recipes-multimedia/libtiff/files/CVE-2023-25434.patch
deleted file mode 100644
index a78c9709f9..00
--- a/meta/recipes-multimedia/libtiff/files/CVE-2023-25434.patch
+++ /dev/null
@@ -1,159 +0,0 @@
-From 69818e2f2d246e6631ac2a2da692c3706b849c38 Mon Sep 17 00:00:00 2001
-From: Su_Laus 
-Date: Sun, 29 Jan 2023 11:09:26 +0100
-Subject: [PATCH] tiffcrop: Amend rotateImage() not to toggle the input (main)
- image width and length parameters when only cropped image sections are
- rotated. Remove buffptr from region structure because never used.
-
-Closes #492 #493 #494 #495 #499 #518 #519
-
-Upstream-Status: Backport from 
[https://gitlab.com/libtiff/libtiff/-/commit/69818e2f2d246e6631ac2a2da692c3706b849c38]
-CVE: CVE-2023-25434
-
-Signed-off-by: Siddharth Doshi 

- tools/tiffcrop.c | 51 
- 1 file changed, 30 insertions(+), 21 deletions(-)
-
-diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
-index fc5b34b..6e1acc4 100644
 a/tools/tiffcrop.c
-+++ b/tools/tiffcrop.c
-@@ -296,7 +296,6 @@ struct region
- uint32_t width;/* width in pixels */
- uint32_t length;   /* length in pixels */
- uint32_t buffsize; /* size of buffer needed to hold the cropped region */
--unsigned char *buffptr; /* address of start of the region */
- };
- 
- /* Cropping parameters from command line and image data
-@@ -577,7 +576,7 @@ static int rotateContigSamples24bits(uint16_t, uint16_t, 
uint16_t, uint32_t,
- static int rotateContigSamples32bits(uint16_t, uint16_t, uint16_t, uint32_t,
-  uint32_t, uint32_t, uint8_t *, uint8_t 
*);
- static int rotateImage(uint16_t, struct image_data *, uint32_t *, uint32_t *,
--   unsigned char **);
-+   unsigned char **, int);
- static int mirrorImage(uint16_t, uint16_t, uint16_t, uint32_t, uint32_t,
-unsigned char *);
- static int invertImage(uint16_t, uint16_t, uint16_t, uint32_t, uint32_t,
-@@ -5779,7 +5778,6 @@ static void initCropMasks(struct crop_mask *cps)
- cps->regionlist[i].width = 0;
- cps->regionlist[i].length = 0;
- cps->regionlist[i].buffsize = 0;
--cps->regionlist[i].buffptr = NULL;
- cps->zonelist[i].position = 0;
- cps->zonelist[i].total = 0;
- }
-@@ -7221,8 +7219,13 @@ static int correct_orientation(struct image_data *image,
- return (-1);
- }
- 
--if (rotateImage(rotation, image, >width, >length,
--work_buff_ptr))
-+/* Dummy variable in order not to switch two times 

Re: [oe-core][RFC PATCH 0/3] Add packagefeed recipe class

[Alexander Kanavin]

On Wed, 19 Jul 2023 at 23:14, Charlie Johnston  wrote:
> I could see reusing the logic from the package_manager, but it would require
> changes to allow indices to be created for arbitrary directories (instead of 
> being
> hardcoded based on package type), and adding some mechanism to 
> create_packages_dir
> in the package_manager/__init__.py to handle feed creation tasks/feeds being
> dependent on other feeds.
>
> Are there limitations on changing the API of those classes and methods to add
> inputs? Alternatively, I could split the overlapping code into a helper method
> instead?

Thanks for the explanation!

The classes were written for the purpose of generating root
filesystems for images by constructing filtered package feeds in
images' ${WORKDIR}, but I think they should indeed be extended and
tweaked to allow generic feeds that can be then exported to
deploydirs. In particular create_packages_dir already does what is
needed for a filtered feed, and there really shouldn't be a second
implementation of that logic elsewhere.

Alex

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

Re: [OE-core][PATCH v9 0/3] CVE-check handling

[Marta Rybczynska]

On Wed, Jul 19, 2023 at 2:03 PM Andrej Valek via lists.openembedded.org
 wrote:

> Even better,
>
> So I will make one more rebase, just for "[OE-core][PATCH v9 3/3]
> cve_check:
> convert CVE_CHECK_IGNORE to CVE_STATUS"
>
>
This version looks best from all I've seen. Let's get it in in this
version. I'll have a pachset to fix a few issues after we get multiple
fetchers in. I *think* I will be able to use it with multi-fetchers.

Kind regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184650): 
https://lists.openembedded.org/g/openembedded-core/message/184650
Mute This Topic: https://lists.openembedded.org/mt/99716038/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] [RFC PATCH 0/4] Bump Protobuf/gRPC

[Martin Jansa]

These patches should be sent to openembedded-devel not openembedded-core.

> ERROR: abseil-cpp-20230125.3-r0 do_package: Variable Requires:
absl_config = 20230125, absl_core_headers = 20230125,
absl_log_internal_append_truncated = 20230125, absl_log_internal_config =
20230125, absl_log_internal_globals = 20230125, absl_log_severity =
20230125, absl_strings = 20230125, absl_str_format = 20230125, absl_time =
20230125, absl_span  contains an operation using the old override syntax.
Please convert this layer/metadata before attempting to use with a newer
bitbake.

Do you have this change in your build?
https://lists.openembedded.org/g/openembedded-core/message/179019

On Thu, Jul 20, 2023 at 6:25 PM Clément Péron  wrote:

> Hi,
>
> I'm trying to bump gRPC to a more recent version,
> but it requires a bump of protobuf.
>
> I'm strugling with the following issue when compiling:
>
> ERROR: abseil-cpp-20230125.3-r0 do_package: Variable Requires: absl_config
> = 20230125, absl_core_headers = 20230125,
> absl_log_internal_append_truncated = 20230125, absl_log_internal_config =
> 20230125, absl_log_internal_globals = 20230125, absl_log_severity =
> 20230125, absl_strings = 20230125, absl_str_format = 20230125, absl_time =
> 20230125, absl_span  contains an operation using the old override syntax.
> Please convert this layer/metadata before attempting to use with a newer
> bitbake.
> ERROR: Logfile of failure stored in:
> /build/tmp/work/armv8a-poky-linux/abseil-cpp/20230125.3-r0/temp/log.do_package.2192204
> ERROR: Task
> (/build/../meta-outsight/recipes-devtools/abseil-cpp/abseil-cpp_git.bb:do_package)
> failed with exit code '1'
>
> Do you have an idea of what is happening?
>
> Thanks for your help
>
> Clément Péron (4):
>   jsoncpp: extend with nativesdk
>   devtools: protobuf: add utf8-range recipe
>   protobuf: bump to 3.23.4
>   devtools: grpc: bump to 1.56.2
>
>  ...RPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch | 62 -
>  ...d-separate-export-for-plugin-targets.patch | 93 ---
>  .../grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb}   |  6 +-
>  .../recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb |  2 +-
>  .../0001-Fix-linking-error-with-ld-gold.patch | 69 --
>  ...e-respect-CXX-LDFLAGS-variables-fix-.patch |  4 +-
>  ...protobuf_3.21.12.bb => protobuf_3.23.4.bb} |  8 +-
>  .../protobuf/utf8-range_git.bb| 22 +
>  8 files changed, 32 insertions(+), 234 deletions(-)
>  delete mode 100644
> meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
>  delete mode 100644
> meta-oe/recipes-devtools/grpc/grpc/0001-cmake-add-separate-export-for-plugin-targets.patch
>  rename meta-oe/recipes-devtools/grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb}
> (92%)
>  delete mode 100644
> meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
>  rename meta-oe/recipes-devtools/protobuf/{protobuf_3.21.12.bb =>
> protobuf_3.23.4.bb} (95%)
>  create mode 100644 meta-oe/recipes-devtools/protobuf/utf8-range_git.bb
>
> --
> 2.41.0
>
>
> 
>
>

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

[OE-core] [RFC PATCH 4/4] devtools: grpc: bump to 1.56.2

[Clément Péron]

Remove merged patch that export plugin to a separate targets

Remove no more applicatable patch

Signed-off-by: Clément Péron 
---
 ...RPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch | 62 -
 ...d-separate-export-for-plugin-targets.patch | 93 ---
 .../grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb}   |  6 +-
 3 files changed, 2 insertions(+), 159 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
 delete mode 100644 
meta-oe/recipes-devtools/grpc/grpc/0001-cmake-add-separate-export-for-plugin-targets.patch
 rename meta-oe/recipes-devtools/grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb} (92%)

diff --git 
a/meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
 
b/meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
deleted file mode 100644
index b245ad865..0
--- 
a/meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From dc593958e556dd496b774f35c5992285510d6859 Mon Sep 17 00:00:00 2001
-From: Martin Jansa 
-Date: Tue, 19 Oct 2021 17:09:55 +0200
-Subject: [PATCH] Revert "Changed GRPCPP_ABSEIL_SYNC to GPR_ABSEIL_SYNC
- (#25681)"
-
-This reverts commit 931f91b745cd5b2864a0d1787815871d0bd844ae.
-
-Fixes sysdig from meta-oe and other recipes (like com.webos.service.tts
-libgoogleassistant from meta-webosose) failing with:
-
-| FAILED: userspace/sysdig/sysdig
-| : && 
/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot-native/usr/bin/x86_64-oe-linux/x86_64-oe-linux-g++
 -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong  
-O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-sec
-urity  
--sysroot=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot
  -O2 -pipe -g -feliminate-unused-debug-types 
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  -f
-debug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot=
  -fdebug-prefix-map=/OE/bu
-ild/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot-native=
  -fvisibility-inlines-hidden  -m64 -march=core2 -mtune=core2 -msse3 
-mfpmath=sse -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat 
-Wformat-security -Werror=format-security  --sysroot=/OE/build
-/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot 
-Wall -ggdb   -std=c++0x -O3 -fno-strict-aliasing -DNDEBUG  -m64 -march=core2 
-mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong  -O2 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
---sysroot=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot
  -O2 -pipe -g -feliminate-unused-debug-types 
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  -fdebug-p
-refix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot=
  -fdebug-prefix-map=/OE/build/oe-
-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot-native=  
-fvisibility-inlines-hidden  -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse 
-fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security 
-Werror=format-security  --sysroot=/OE/build/oe-cor
-e/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot -Wl,-O1 
-Wl,--hash-style=gnu -Wl,--as-needed 
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  -fdebug-prefix-map=/OE/build/oe-cor
-e/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot=
  -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-
-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot-native=  -Wl,-z,relro,-z,now 
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed 
-fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  -fdebug-prefix-map=/OE/build/
-oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0=/usr/src/debug/sysdig/0.27.1-r0
  
-fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/core2-64-oe-linux/sysdig/0.27.1-r0/recipe-sysroot=
  

[OE-core] [RFC PATCH 2/4] devtools: protobuf: add utf8-range recipe

[Clément Péron]

Utf8 range is a new algorithm that implement fast UTF8 validation.

It is required to compile examples for new protobuf.

Signed-off-by: Clément Péron 
---
 .../protobuf/utf8-range_git.bb| 22 +++
 1 file changed, 22 insertions(+)
 create mode 100644 meta-oe/recipes-devtools/protobuf/utf8-range_git.bb

diff --git a/meta-oe/recipes-devtools/protobuf/utf8-range_git.bb 
b/meta-oe/recipes-devtools/protobuf/utf8-range_git.bb
new file mode 100644
index 0..86ecb74d6
--- /dev/null
+++ b/meta-oe/recipes-devtools/protobuf/utf8-range_git.bb
@@ -0,0 +1,22 @@
+SUMMARY = "Fast UTF-8 validation with Range algorithm"
+DESCRIPTION = "This is a brand new algorithm to leverage SIMD for fast UTF-8 \
+string validation. Both NEON(armv8a) and SSE4 versions are implemented."
+HOMEPAGE = "https://github.com/protocolbuffers/utf8_range;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d4974d297231477b2ff507c35d61c13c"
+
+DEPENDS = "abseil-cpp"
+
+SRC_URI = 
"git://github.com/protocolbuffers/utf8_range.git;branch=main;protocol=https"
+SRCREV = "d863bc33e15cba6d873c878dcca9e6fe52b2f8cb"
+
+S = "${WORKDIR}/git"
+
+inherit cmake
+
+EXTRA_OECMAKE += "\
+-Dutf8_range_ENABLE_TESTS=OFF \
+"
+
+BBCLASSEXTEND = "native nativesdk"
+
-- 
2.41.0


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

[OE-core] [RFC PATCH 3/4] protobuf: bump to 3.23.4

[Clément Péron]

Bump to protobuf 3.23.4 with the following diff

- Add new abseil-cpp jsoncpp dependencies
- Linking with gold patch has been fixed see
  commit 462964ed322503af52638d54c00a0a67d7133349
- Refresh the patch that fix examples LDFLAGS

Signed-off-by: Clément Péron 
---
 .../0001-Fix-linking-error-with-ld-gold.patch | 69 ---
 ...e-respect-CXX-LDFLAGS-variables-fix-.patch |  4 +-
 ...protobuf_3.21.12.bb => protobuf_3.23.4.bb} |  8 ++-
 3 files changed, 7 insertions(+), 74 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
 rename meta-oe/recipes-devtools/protobuf/{protobuf_3.21.12.bb => 
protobuf_3.23.4.bb} (95%)

diff --git 
a/meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
 
b/meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
deleted file mode 100644
index 2bc44c898..0
--- 
a/meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
+++ /dev/null
@@ -1,69 +0,0 @@
-From a91130bb95528743a3f7253f8fe945b7505047d5 Mon Sep 17 00:00:00 2001
-From: Kyungjik Min 
-Date: Mon, 28 Dec 2020 15:56:09 +0900
-Subject: [PATCH] Fix linking error with ld-gold
-
-:Release Notes:
-
-:Detailed Notes:
-https://github.com/protocolbuffers/protobuf/issues/6113
-There's a bug in the CMake build leading it to not use the version
-scripts, which hides the problem (because all symbols are now public)
-but doesn't solve it properly.
-
-:Testing Performed:
-
-:QA Notes:
-N/A
-
-:Issues Addressed:
-[PLAT-130467] Fix build error for libgoogleassistant with latest
-  protobuf-3.11.4
-

-Upstream-Status: Pending
-
- src/libprotobuf-lite.map | 2 ++
- src/libprotobuf.map  | 2 ++
- src/libprotoc.map| 2 ++
- 3 files changed, 6 insertions(+)
-
-diff --git a/src/libprotobuf-lite.map b/src/libprotobuf-lite.map
-index 391554669..a1853ca6c 100644
 a/src/libprotobuf-lite.map
-+++ b/src/libprotobuf-lite.map
-@@ -3,6 +3,8 @@
- extern "C++" {
-   *google*;
- };
-+scc_info_*;
-+descriptor_table_*;
- 
-   local:
- *;
-diff --git a/src/libprotobuf.map b/src/libprotobuf.map
-index 391554669..a1853ca6c 100644
 a/src/libprotobuf.map
-+++ b/src/libprotobuf.map
-@@ -3,6 +3,8 @@
- extern "C++" {
-   *google*;
- };
-+scc_info_*;
-+descriptor_table_*;
- 
-   local:
- *;
-diff --git a/src/libprotoc.map b/src/libprotoc.map
-index 391554669..a1853ca6c 100644
 a/src/libprotoc.map
-+++ b/src/libprotoc.map
-@@ -3,6 +3,8 @@
- extern "C++" {
-   *google*;
- };
-+scc_info_*;
-+descriptor_table_*;
- 
-   local:
- *;
diff --git 
a/meta-oe/recipes-devtools/protobuf/protobuf/0001-examples-Makefile-respect-CXX-LDFLAGS-variables-fix-.patch
 
b/meta-oe/recipes-devtools/protobuf/protobuf/0001-examples-Makefile-respect-CXX-LDFLAGS-variables-fix-.patch
index 36c3c597a..f3eead39b 100644
--- 
a/meta-oe/recipes-devtools/protobuf/protobuf/0001-examples-Makefile-respect-CXX-LDFLAGS-variables-fix-.patch
+++ 
b/meta-oe/recipes-devtools/protobuf/protobuf/0001-examples-Makefile-respect-CXX-LDFLAGS-variables-fix-.patch
@@ -46,12 +46,12 @@ index 1c7ec8d63..85f591231 100644
  
  add_person_cpp: add_person.cc protoc_middleman
pkg-config --cflags protobuf  # fails if protobuf is not installed
--  c++ -std=c++11 add_person.cc addressbook.pb.cc -o add_person_cpp 
`pkg-config --cflags --libs protobuf`
+-  c++ -std=c++14 add_person.cc addressbook.pb.cc -o add_person_cpp 
`pkg-config --cflags --libs protobuf`
 +  $(CXX) $(CXXFLAGS) $(LDFLAGS) 
../src/google/protobuf/.libs/timestamp.pb.o $(PROTOBUF) add_person.cc 
addressbook.pb.cc -o add_person_cpp
  
  list_people_cpp: list_people.cc protoc_middleman
pkg-config --cflags protobuf  # fails if protobuf is not installed
--  c++ -std=c++11 list_people.cc addressbook.pb.cc -o list_people_cpp 
`pkg-config --cflags --libs protobuf`
+-  c++ -std=c++14 list_people.cc addressbook.pb.cc -o list_people_cpp 
`pkg-config --cflags --libs protobuf`
 +  $(CXX) $(CXXFLAGS) $(LDFLAGS) 
../src/google/protobuf/.libs/timestamp.pb.o $(PROTOBUF) list_people.cc 
addressbook.pb.cc -o list_people_cpp
  
  add_person_dart: add_person.dart protoc_middleman_dart
diff --git a/meta-oe/recipes-devtools/protobuf/protobuf_3.21.12.bb 
b/meta-oe/recipes-devtools/protobuf/protobuf_3.23.4.bb
similarity index 95%
rename from meta-oe/recipes-devtools/protobuf/protobuf_3.21.12.bb
rename to meta-oe/recipes-devtools/protobuf/protobuf_3.23.4.bb
index 343933033..a053afa78 100644
--- a/meta-oe/recipes-devtools/protobuf/protobuf_3.21.12.bb
+++ b/meta-oe/recipes-devtools/protobuf/protobuf_3.23.4.bb
@@ -7,12 +7,12 @@ SECTION = "console/tools"
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=37b5762e07f0af8c74ce80a8bda4266b"
 
-DEPENDS = "zlib"
+DEPENDS = "abseil-cpp jsoncpp zlib"
 DEPENDS:append:class-target = " protobuf-native"
 
-SRCREV = 

[OE-core] [RFC PATCH 1/4] jsoncpp: extend with nativesdk

[Clément Péron]

Jsoncpp doesn't extend for the moment with nativesdk

We will need jsoncpp in the next protobuf bump that will require
that.

Add the nativesdk to BBEXTENDS of the jsoncpp recipe.

Signed-off-by: Clément Péron 
---
 meta-oe/recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-oe/recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb 
b/meta-oe/recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb
index c54dc9466..086615649 100644
--- a/meta-oe/recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb
+++ b/meta-oe/recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb
@@ -22,4 +22,4 @@ inherit cmake
 
 EXTRA_OECMAKE += "-DBUILD_SHARED_LIBS=ON -DBUILD_OBJECT_LIBS=OFF 
-DJSONCPP_WITH_TESTS=OFF"
 
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
-- 
2.41.0


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

[OE-core] [RFC PATCH 0/4] Bump Protobuf/gRPC

[Clément Péron]

Hi,

I'm trying to bump gRPC to a more recent version,
but it requires a bump of protobuf.

I'm strugling with the following issue when compiling:

ERROR: abseil-cpp-20230125.3-r0 do_package: Variable Requires: absl_config = 
20230125, absl_core_headers = 20230125, absl_log_internal_append_truncated = 
20230125, absl_log_internal_config = 20230125, absl_log_internal_globals = 
20230125, absl_log_severity = 20230125, absl_strings = 20230125, 
absl_str_format = 20230125, absl_time = 20230125, absl_span  contains an 
operation using the old override syntax. Please convert this layer/metadata 
before attempting to use with a newer bitbake.
ERROR: Logfile of failure stored in: 
/build/tmp/work/armv8a-poky-linux/abseil-cpp/20230125.3-r0/temp/log.do_package.2192204
ERROR: Task 
(/build/../meta-outsight/recipes-devtools/abseil-cpp/abseil-cpp_git.bb:do_package)
 failed with exit code '1'

Do you have an idea of what is happening?

Thanks for your help

Clément Péron (4):
  jsoncpp: extend with nativesdk
  devtools: protobuf: add utf8-range recipe
  protobuf: bump to 3.23.4
  devtools: grpc: bump to 1.56.2

 ...RPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch | 62 -
 ...d-separate-export-for-plugin-targets.patch | 93 ---
 .../grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb}   |  6 +-
 .../recipes-devtools/jsoncpp/jsoncpp_1.9.5.bb |  2 +-
 .../0001-Fix-linking-error-with-ld-gold.patch | 69 --
 ...e-respect-CXX-LDFLAGS-variables-fix-.patch |  4 +-
 ...protobuf_3.21.12.bb => protobuf_3.23.4.bb} |  8 +-
 .../protobuf/utf8-range_git.bb| 22 +
 8 files changed, 32 insertions(+), 234 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/grpc/grpc/0001-Revert-Changed-GRPCPP_ABSEIL_SYNC-to-GPR_ABSEIL_SYNC.patch
 delete mode 100644 
meta-oe/recipes-devtools/grpc/grpc/0001-cmake-add-separate-export-for-plugin-targets.patch
 rename meta-oe/recipes-devtools/grpc/{grpc_1.50.1.bb => grpc_1.56.2.bb} (92%)
 delete mode 100644 
meta-oe/recipes-devtools/protobuf/protobuf/0001-Fix-linking-error-with-ld-gold.patch
 rename meta-oe/recipes-devtools/protobuf/{protobuf_3.21.12.bb => 
protobuf_3.23.4.bb} (95%)
 create mode 100644 meta-oe/recipes-devtools/protobuf/utf8-range_git.bb

-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184644): 
https://lists.openembedded.org/g/openembedded-core/message/184644
Mute This Topic: https://lists.openembedded.org/mt/100259348/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] nfs-utils: upgrade 2.6.2 -> 2.6.3

[Trevor Gamblin]

Changelog: http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog

Three patches were removed as they're now upstream:

2c0b5249 Replace statfs64 with statfs
167f2336 Fix function prototypes
896946e3 mountd: Check for return of stat function

do_compile still failed after removing these patches, reporting
undefined references to 'event_base_new', 'sqlite3_open_v2', etc. This
is fixed by adding the following line:

LDFLAGS:append = " -lsqlite3 -levent"

Signed-off-by: Trevor Gamblin 
---
 .../0001-Replace-statfs64-with-statfs.patch   | 171 --
 ...td-Check-for-return-of-stat-function.patch |  34 
 .../0006-Fix-function-prototypes.patch|  93 --
 ...{nfs-utils_2.6.2.bb => nfs-utils_2.6.3.bb} |   7 +-
 4 files changed, 3 insertions(+), 302 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0005-mountd-Check-for-return-of-stat-function.patch
 delete mode 100644 
meta/recipes-connectivity/nfs-utils/nfs-utils/0006-Fix-function-prototypes.patch
 rename meta/recipes-connectivity/nfs-utils/{nfs-utils_2.6.2.bb => 
nfs-utils_2.6.3.bb} (95%)

diff --git 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
 
b/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
deleted file mode 100644
index 40ceff9ae9..00
--- 
a/meta/recipes-connectivity/nfs-utils/nfs-utils/0001-Replace-statfs64-with-statfs.patch
+++ /dev/null
@@ -1,171 +0,0 @@
-From e89652b853ca7de671093ae44305fa3435e13d3d Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Thu, 15 Dec 2022 13:29:43 -0800
-Subject: [PATCH] Replace statfs64 with statfs
-
-autoconf AC_SYS_LARGEFILE is used by configure to add needed defines
-when needed for enabling 64bit off_t, therefore replacing statfs64 with
-statfs should be functionally same. Additionally this helps compiling
-with latest musl where 64bit LFS functions like statfs64 and friends are
-now moved under _LARGEFILE64_SOURCE feature test macro, this works on
-glibc systems because _GNU_SOURCE macros also enables
-_LARGEFILE64_SOURCE indirectly. This is not case with musl and this
-latest issue is exposed.
-
-Upstream-Status: Submitted 
[https://lore.kernel.org/linux-nfs/20221215213605.4061853-1-raj.k...@gmail.com/T/#u]
-Signed-off-by: Khem Raj 

- support/export/cache.c  | 14 +++---
- support/include/nfsd_path.h |  6 +++---
- support/misc/nfsd_path.c| 24 
- utils/exportfs/exportfs.c   |  4 ++--
- 4 files changed, 24 insertions(+), 24 deletions(-)
-
-diff --git a/support/export/cache.c b/support/export/cache.c
-index a5823e9..2497d4f 100644
 a/support/export/cache.c
-+++ b/support/export/cache.c
-@@ -346,27 +346,27 @@ static int uuid_by_path(char *path, int type, size_t 
uuidlen, char *uuid)
- 
-   /* Possible sources of uuid are
-* - blkid uuid
--   * - statfs64 uuid
-+   * - statfs uuid
-*
--   * On some filesystems (e.g. vfat) the statfs64 uuid is simply an
-+   * On some filesystems (e.g. vfat) the statfs uuid is simply an
-* encoding of the device that the filesystem is mounted from, so
-* it we be very bad to use that (as device numbers change).  blkid
-* must be preferred.
--   * On other filesystems (e.g. btrfs) the statfs64 uuid contains
-+   * On other filesystems (e.g. btrfs) the statfs uuid contains
-* important info that the blkid uuid cannot contain:  This happens
-* when multiple subvolumes are exported (they have the same
--   * blkid uuid but different statfs64 uuids).
-+   * blkid uuid but different statfs uuids).
-* We rely on get_uuid_blkdev *knowing* which is which and not returning
--   * a uuid for filesystems where the statfs64 uuid is better.
-+   * a uuid for filesystems where the statfs uuid is better.
-*
-*/
--  struct statfs64 st;
-+  struct statfs st;
-   char fsid_val[17];
-   const char *blkid_val = NULL;
-   const char *val;
-   int rc;
- 
--  rc = nfsd_path_statfs64(path, );
-+  rc = nfsd_path_statfs(path, );
- 
-   if (type == 0 && rc == 0) {
-   const unsigned long *bad;
-diff --git a/support/include/nfsd_path.h b/support/include/nfsd_path.h
-index 3b73aad..aa1e1dd 100644
 a/support/include/nfsd_path.h
-+++ b/support/include/nfsd_path.h
-@@ -7,7 +7,7 @@
- #include 
- 
- struct file_handle;
--struct statfs64;
-+struct statfs;
- 
- void  nfsd_path_init(void);
- 
-@@ -18,8 +18,8 @@ char *   nfsd_path_prepend_dir(const char *dir, 
const char *pathname);
- int   nfsd_path_stat(const char *pathname, struct stat *statbuf);
- int   nfsd_path_lstat(const char *pathname, struct stat *statbuf);
- 
--int   nfsd_path_statfs64(const char *pathname,
-- struct 

[OE-core] [PATCH 1/2] ltp: add RDEPENDS on findutils

[Ross Burton]

From: Ross Burton 

With busybox find some of the test script fails, so depend on GNU find.

Signed-off-by: Ross Burton 
---
 meta/recipes-extended/ltp/ltp_20230516.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-extended/ltp/ltp_20230516.bb 
b/meta/recipes-extended/ltp/ltp_20230516.bb
index ddc6523e302..e9407d3148e 100644
--- a/meta/recipes-extended/ltp/ltp_20230516.bb
+++ b/meta/recipes-extended/ltp/ltp_20230516.bb
@@ -93,6 +93,7 @@ RDEPENDS:${PN} = "\
 e2fsprogs-mke2fs \
 expect \
 file \
+findutils \
 gawk \
 gdb \
 gzip \
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184640): 
https://lists.openembedded.org/g/openembedded-core/message/184640
Mute This Topic: https://lists.openembedded.org/mt/100258694/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] oeqa/ltp: rewrote LTP testcase and parser

[Ross Burton]

From: Ross Burton 

The LTP test reporting appears to be a little fragile so I tried to make
it more reliable.

Primarily this is done by not passing -p to runltp, which results in
machine-readable logfiles instead of human-readable.  These are easier
to parse and have more context in, so we can also report correctly
skipped tests.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/runtime/cases/ltp.py | 17 +---
 meta/lib/oeqa/utils/logparser.py   | 62 +++---
 2 files changed, 51 insertions(+), 28 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/ltp.py 
b/meta/lib/oeqa/runtime/cases/ltp.py
index a66d5d13d75..29c26d7d324 100644
--- a/meta/lib/oeqa/runtime/cases/ltp.py
+++ b/meta/lib/oeqa/runtime/cases/ltp.py
@@ -65,29 +65,34 @@ class LtpTest(LtpTestBase):
 ltp_groups += ltp_fs
 
 def runltp(self, ltp_group):
-cmd = '/opt/ltp/runltp -f %s -p -q -r /opt/ltp -l 
/opt/ltp/results/%s -I 1 -d /opt/ltp' % (ltp_group, ltp_group)
+# LTP appends to log files, so ensure we start with a clean log
+self.target.deleteFiles("/opt/ltp/results/", ltp_group)
+
+cmd = '/opt/ltp/runltp -f %s -q -r /opt/ltp -l /opt/ltp/results/%s 
-I 1 -d /opt/ltp' % (ltp_group, ltp_group)
+
 starttime = time.time()
 (status, output) = self.target.run(cmd)
 endtime = time.time()
 
+# Write the console log to disk for convenience
 with open(os.path.join(self.ltptest_log_dir, "%s-raw.log" % 
ltp_group), 'w') as f:
 f.write(output)
 
+# Also put the console log into the test result JSON
 self.extras['ltpresult.rawlogs']['log'] = 
self.extras['ltpresult.rawlogs']['log'] + output
 
-# copy nice log from DUT
-dst = os.path.join(self.ltptest_log_dir, "%s" %  ltp_group )
+# Copy the machine-readable test results locally so we can parse it
+dst = os.path.join(self.ltptest_log_dir, ltp_group)
 remote_src = "/opt/ltp/results/%s" % ltp_group 
 (status, output) = self.target.copyFrom(remote_src, dst, True)
-msg = 'File could not be copied. Output: %s' % output
 if status:
+msg = 'File could not be copied. Output: %s' % output
 self.target.logger.warning(msg)
 
 parser = LtpParser()
 results, sections  = parser.parse(dst)
 
-runtime = int(endtime-starttime)
-sections['duration'] = runtime
+sections['duration'] = int(endtime-starttime)
 self.sections[ltp_group] =  sections
 
 failed_tests = {}
diff --git a/meta/lib/oeqa/utils/logparser.py b/meta/lib/oeqa/utils/logparser.py
index 8054acc853b..496d9e0c903 100644
--- a/meta/lib/oeqa/utils/logparser.py
+++ b/meta/lib/oeqa/utils/logparser.py
@@ -4,7 +4,7 @@
 # SPDX-License-Identifier: MIT
 #
 
-import sys
+import enum
 import os
 import re
 
@@ -106,30 +106,48 @@ class PtestParser(object):
 f.write(status + ": " + test_name + "\n")
 
 
-# ltp log parsing
-class LtpParser(object):
-def __init__(self):
-self.results = {}
-self.section = {'duration': "", 'log': ""}
-
+class LtpParser:
+"""
+Parse the machine-readable LTP log output into a ptest-friendly data 
structure.
+"""
 def parse(self, logfile):
-test_regex = {}
-test_regex['PASSED'] = re.compile(r"PASS")
-test_regex['FAILED'] = re.compile(r"FAIL")
-test_regex['SKIPPED'] = re.compile(r"SKIP")
-
-with open(logfile, errors='replace') as f:
+results = {}
+# Aaccumulate the duration here but as the log rounds quick tests down
+# to 0 seconds this is very much a lower bound. The caller can replace
+# the value.
+section = {"duration": 0, "log": ""}
+
+class LtpExitCode(enum.IntEnum):
+# Exit codes as defined in ltp/include/tst_res_flags.h
+TPASS = 0  # Test passed flag
+TFAIL = 1  # Test failed flag
+TBROK = 2  # Test broken flag
+TWARN = 4  # Test warning flag
+TINFO = 16 # Test information flag
+TCONF = 32 # Test not appropriate for configuration flag
+
+with open(logfile, errors="replace") as f:
+# Lines look like this:
+# tag=cfs_bandwidth01 stime=1689762564 dur=0 exit=exited stat=32 
core=no cu=0 cs=0
 for line in f:
-for t in test_regex:
-result = test_regex[t].search(line)
-if result:
-self.results[line.split()[0].strip()] = t
-
-for test in self.results:
-result = self.results[test]
-self.section['log'] = self.section['log'] + ("%s: %s\n" % 
(result.strip()[:-2], test.strip()))
+if not line.startswith("tag="):
+continue
 
-return self.results, 

[OE-core] [meta][kirkstone][PATCH] json-c: disable -Werror for x86-64

[Rouven Czerwinski]

From: Rouven Czerwinski 

Disable -Werror using OECMAKE_C_FLAGS on x86-64. This ensures that json-c can
build on newer distributions where the host compiler is new enough to treat
implicit fallthrough warnings as errors:
  | NOTE: VERBOSE=1 cmake --build 
/…/work/x86_64-linux/json-c-native/0.15-r0/build --target all --
  | [1/34] 
/…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
 -D_GNU_SOURCE -Djson_c_EXPORTS 
-I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
-I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
-isystem/…/work/x86_64-linux/j
  son-c-native/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe 
-ffunction-sections -fdata-sections -Werror -Wall -Wcast-qual 
-Wno-error=deprecated-declarations -Wextra -Wwrite-strings 
-Wno-unused-parameter -Wstrict-prototypes -g -fPIC -D_REENTRANT -MD -MT 
CMakeFiles/json-c.dir/linkhash.c.o -MF CMakeFiles/json-c.dir/linkhash.c.o.d -o 
CMakeFiles/json-c.dir/linkhash.c.o -c 
/…/work/x86_64-linux/json-c-native/0.15-r0/json-c
  -0.15/linkhash.c
  | FAILED: CMakeFiles/json-c.dir/linkhash.c.o
  | 
/…/work/x86_64-linux/json-c-native/0.15-r0/recipe-sysroot-native/usr/bin/ice/gcc
 -D_GNU_SOURCE -Djson_c_EXPORTS 
-I/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15 
-I/…/work/x86_64-linux/json-c-native/0.15-r0/build 
-isystem/…/work/x86_64-linux/json-c-n
  ative/0.15-r0/recipe-sysroot-native/usr/include -O2 -pipe -ffunction-sections 
-fdata-sections -Werror -Wall -Wcast-qual -Wno-error=deprecated-declarations 
-Wextra -Wwrite-strings -Wno-unused-parameter -Wstrict-prototypes -g -fPIC 
-D_REENTRANT -MD -MT CMakeFiles/json-c.dir/linkhash.c.o -MF 
CMakeFiles/json-c.dir/linkhash.c.o.d -o CMakeFiles/json-c.dir/linkhash.c.o -c 
/…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/l
  inkhash.c
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c: In 
function 'hashlittle':
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:367:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:368:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:372:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:373:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:376:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:377:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:380:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:381:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:383:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:384:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:420:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:421:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:422:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:423:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:424:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:425:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:425:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:426:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:426:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:427:3: 
note: here
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:427:13: 
error: this statement may fall through [-Werror=implicit-fallthrough=]
  | /…/work/x86_64-linux/json-c-native/0.15-r0/json-c-0.15/linkhash.c:428:3: 
note: 

Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Thu, Jul 20, 2023 at 9:16 AM Petr Gotthard
 wrote:
>
> > My question was about CONFIG_LOCALVERSION_AUTO being something that you
> > changed after the first issue popped up (I understood what it was changing 
> > from
> > your first description) I can't clearly see if you turned it on in response 
> > to the
> > breakage, but I'm assuming that the answer is yes.
>
> Oh, sorry for the consuion. Yes, I changed the CONFIG_LOCALVERSION_AUTO only 
> to reduce the number of suffixes.

Ack'd. Thanks for confirming.

I'm coming up with something that will keep 6.3+ working, and not
break older/existing recipes.

Cheers,

Bruce

>
>
> Cheers,
> Petr



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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184638): 
https://lists.openembedded.org/g/openembedded-core/message/184638
Mute This Topic: https://lists.openembedded.org/mt/100240236/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] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Petr Gotthard]

> My question was about CONFIG_LOCALVERSION_AUTO being something that you
> changed after the first issue popped up (I understood what it was changing 
> from
> your first description) I can't clearly see if you turned it on in response 
> to the
> breakage, but I'm assuming that the answer is yes.

Oh, sorry for the consuion. Yes, I changed the CONFIG_LOCALVERSION_AUTO only to 
reduce the number of suffixes.


Cheers,
Petr

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184637): 
https://lists.openembedded.org/g/openembedded-core/message/184637
Mute This Topic: https://lists.openembedded.org/mt/100240236/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] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Thu, Jul 20, 2023 at 6:06 AM Petr Gotthard
 wrote:
>
> > -Original Message-
> > From: Bruce Ashfield 
> > Sent: Wednesday, July 19, 2023 11:56 PM
> > To: Petr Gotthard 
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION
>
> > >
> > > The kernel is "linux-ti-staging_6.1" with quite standard settings.
> > > Recently I did explicitly set CONFIG_LOCALVERSION_AUTO=n which was "y"
> > > by default. With the default "y" setting I was getting a kernel version 
> > > with two
> > identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2", whereas the make-mod-
> > scripts used "6.1.33-g8f7f371be2").
> >
> > Did that only start happening recently ? because with the localversion_auto 
> > and a
> > set .scmversion, that's what I'd expect to happen (see below).
>
> > I'm curious if on-target module builds work on those boards, since as near 
> > as I can
> > tell the versions won't match (as the .scmversion file isn't captured, so 
> > the
> > vermagic will be different).
>
> The commit 
> https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
> seems to be the cause here.

I already described in detail about how that commit (which is mine),
is not the only cause.  I'm
quite aware of what is happening now. What is currently in place in
those recipes is about to break
and really was only working by a combination of careful dancing
through the fragility.

My question was about CONFIG_LOCALVERSION_AUTO being something that you changed
after the first issue popped up (I understood what it was changing
from your first description)
I can't clearly see if you turned it on in response to the breakage,
but I'm assuming that the
answer is yes.

Cheers,

Bruce

> Before this commit all modules (both out-of-tree and the standard ones) had a 
> version with one suffix ("6.1.33-g8f7f371be2") and could be loaded.
> After this commit:
>  - the standard modules have two suffxes ("6.1.33-g8f7f371be2-g8f7f371be2") 
> and work fine
>  - the out-of-tree modules have a "vermagic" with only one suffix 
> ("vermagic=6.1.33-g8f7f371be2") and fail due to the vermagic mismatch
>
> Setting CONFIG_LOCALVERSION_AUTO=n removes one suffix from everything, so the 
> mismatch for out-of-tree modules remains.
>
>
> Petr
>


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

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

[OE-core] About requirements on cross compiling rust package

[Frederic Martinsons]

Hello list,

In the course of YOCTO #15104
  , I finally
found the issue was due to a missing Cargo.lock file at the root of the
project (which is pretty usual for a Rust project from git since Cargo.lock
is only required when publishing on the crates registry).

With a Cargo.lock correctly placed, the patch process made by
cargo_common.bbclass works perfectly fine even with a virtual manifest.

I often encountered issues that were in the end due to a missing Cargo.lock
and I think we all agree on this list (I didn't crawl the mail archives, I
talked from my memory) that this file is absolutely required when building
a rust project under yocto.
(especially for reproducible build)

I'm currently testing a patch which will replace --offline cargo build
flags with --frozen (which supersedes --offline mode since it prevents
network access but also Cargo.lock to be present and up to date).

I have two questions though:
  1) rust-hello-world doesn't embed a Cargo.lock (and doesn't need to since
it had zero dependencies) , considering that we now have a more "real"
recipe (zvariant) that is used within selftest, would it be acceptable to
suppress rust-hello-world ?
  2) below is kind of message we will have when using --frozen with an
absent Cargo.lock:

| error: failed to get `glib` as a dependency of package `zvariant v3.12.0
(/home/fmartinsons/TAPOS_build/build-tapos/tmp/work/corei7-64-tapos-linux/zbus/3.11.0-r0/git/zvariant)`
|
| Caused by:
|   failed to load source for dependency `glib`
|
| Caused by:
|   Unable to update https://github.com/gtk-rs/glib?rev=c9ee583cea0
|
| Caused by:
|   failed to fetch into:
/home/fmartinsons/TAPOS_build/build-tapos/tmp/work/corei7-64-tapos-linux/zbus/3.11.0-r0/cargo_home/git/db/glib-928cf7b282977403
|
| Caused by:
|   attempting to update a git repository, but --frozen was specified

I think it is not very clear that the root cause is a missing Cargo.lock ,
so I'm wondering if a specific bitbake ops (do_compile_prepend) would not
be  better to check for Cargo.lock and output an explicit message (it
doesn't prevent to keep --frozen anyway). What do you think ?

PS: I copied Randy as the maintainer of rust-hello-world but also  the
ticket assignee.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184635): 
https://lists.openembedded.org/g/openembedded-core/message/184635
Mute This Topic: https://lists.openembedded.org/mt/100254129/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] Toolchain test results

[Richard Purdie]

On Tue, 2023-07-18 at 10:14 +0100, Richard Purdie via
lists.openembedded.org wrote:
> qemuarm has ~350 failures
> qemuarm64 has ~350 failures
> qemux86-64 has ~4000 (3900 in glibc)
> qemux86 has ~4000 (3500 in glibc)
> qemuppc has ~600 failures
> qemumips64 has ~5000 failures (all over)
> qemumips has ~1600 failures
> 
> Anuj: Can Intel look into the glibc test failures on x86?

I realised the glibc issues were due to the network being disabled for
the tests and have sent a patch to fix that. That reduces the failures
from ~3900 to ~330. We should really try and reduce that further but it
is a start!

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184634): 
https://lists.openembedded.org/g/openembedded-core/message/184634
Mute This Topic: https://lists.openembedded.org/mt/100212267/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] glibc-testsuite: Fix network restrictions causing test failures

[Richard Purdie]

The check target for the glibc testsuite uses networking to access
a QEMU in system mode. This was resulting in large numbers of test
failures for the x86 targets that use it.

Enable network access to resolve this.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/glibc/glibc-testsuite_2.37.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/glibc/glibc-testsuite_2.37.bb 
b/meta/recipes-core/glibc/glibc-testsuite_2.37.bb
index e8ad2a938b1..2e076f4b0f4 100644
--- a/meta/recipes-core/glibc/glibc-testsuite_2.37.bb
+++ b/meta/recipes-core/glibc/glibc-testsuite_2.37.bb
@@ -16,6 +16,7 @@ TOOLCHAIN_TEST_HOST_USER ??= "root"
 TOOLCHAIN_TEST_HOST_PORT ??= ""
 
 do_check[nostamp] = "1"
+do_check[network] = "1"
 do_check:append () {
 chmod 0755 ${WORKDIR}/check-test-wrapper
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184633): 
https://lists.openembedded.org/g/openembedded-core/message/184633
Mute This Topic: https://lists.openembedded.org/mt/100253633/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] kernel: Fix path comparison in kernel staging dir symlinking

[Staffan Rydén]

Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.

This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.

This patch resolves the issue by comparing the variables before they are
modified.

Signed-off-by: Staffan Rydén 
---
 meta/classes-recipe/kernel.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes-recipe/kernel.bbclass 
b/meta/classes-recipe/kernel.bbclass
index 2aedf3a31b..ea0ab491f0 100644
--- a/meta/classes-recipe/kernel.bbclass
+++ b/meta/classes-recipe/kernel.bbclass
@@ -181,13 +181,14 @@ do_unpack[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} 
${STAGING_KERNEL_BUILD
 do_clean[cleandirs] += " ${S} ${STAGING_KERNEL_DIR} ${B} 
${STAGING_KERNEL_BUILDDIR}"
 python do_symlink_kernsrc () {
 s = d.getVar("S")
-if s[-1] == '/':
-# drop trailing slash, so that os.symlink(kernsrc, s) doesn't use s as 
directory name and fail
-s=s[:-1]
 kernsrc = d.getVar("STAGING_KERNEL_DIR")
 if s != kernsrc:
 bb.utils.mkdirhier(kernsrc)
 bb.utils.remove(kernsrc, recurse=True)
+if s[-1] == '/':
+# drop trailing slash, so that os.symlink(kernsrc, s) doesn't use 
s as
+# directory name and fail
+s = s[:-1]
 if d.getVar("EXTERNALSRC"):
 # With EXTERNALSRC S will not be wiped so we can symlink to it
 os.symlink(s, kernsrc)
-- 
2.30.2


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

[OE-Core][PATCH v2 3/3] eudev: Add group sgx to eudev package

[Alex Kiernan]

Fix startup warning:

  udevd[171]: specified group 'sgx' unknown

This mirrors the change in bab455cd9b1b ("systemd: add group sgx to udev
package") for systemd-udev.

Signed-off-by: Alex Kiernan 
---

Changes in v2:
- Rework rpm handling so that the debugfs doesn't include a spurious
  copy of /etc which caused the gdbserver selftest to fail because of a
  duplicate /etc/gshadow file

 meta/recipes-core/udev/eudev_3.2.12.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/udev/eudev_3.2.12.bb 
b/meta/recipes-core/udev/eudev_3.2.12.bb
index 572ccecafd0c..4268bcc2c5de 100644
--- a/meta/recipes-core/udev/eudev_3.2.12.bb
+++ b/meta/recipes-core/udev/eudev_3.2.12.bb
@@ -18,7 +18,7 @@ SRC_URI[sha256sum] = 
"ccdd64ec3c381d3c3ed0e99d2e70d1f62988c7763de89ca7bdffafa5ea
 
 GITHUB_BASE_URI = "https://github.com/eudev-project/eudev/releases;
 
-inherit autotools update-rc.d qemu pkgconfig features_check manpages 
github-releases
+inherit autotools update-rc.d qemu pkgconfig features_check manpages 
github-releases useradd
 
 CONFLICT_DISTRO_FEATURES = "systemd"
 
@@ -85,3 +85,6 @@ pkg_postinst:${PN}-hwdb () {
 pkg_prerm:${PN}-hwdb () {
rm -f $D${sysconfdir}/udev/hwdb.bin
 }
+
+USERADD_PACKAGES = "${PN}"
+GROUPADD_PARAM:${PN} = "-r sgx"
-- 
2.39.0


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

[OE-Core][PATCH v2 2/3] rpm: Pick debugfs package db files/dirs explicitly

[Alex Kiernan]

Rather than copying the entire /etc hierarchy, specify the pieces we
actually need.

Signed-off-by: Alex Kiernan 
---

Changes in v2:
- New in v2

 meta/lib/oe/package_manager/rpm/rootfs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oe/package_manager/rpm/rootfs.py 
b/meta/lib/oe/package_manager/rpm/rootfs.py
index d4c415f68cad..3ba539632063 100644
--- a/meta/lib/oe/package_manager/rpm/rootfs.py
+++ b/meta/lib/oe/package_manager/rpm/rootfs.py
@@ -110,7 +110,7 @@ class PkgRootfs(Rootfs):
 if self.progress_reporter:
 self.progress_reporter.next_stage()
 
-self._setup_dbg_rootfs(['/etc', '/var/lib/rpm', '/var/cache/dnf', 
'/var/lib/dnf'])
+self._setup_dbg_rootfs(['/etc/rpm', '/etc/rpmrc', '/etc/dnf', 
'/var/lib/rpm', '/var/cache/dnf', '/var/lib/dnf'])
 
 execute_pre_post_process(self.d, rpm_post_process_cmds)
 
-- 
2.39.0


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

Re: [OE-Core][PATCH] eudev: Add group sgx to eudev package

[Alex Kiernan]

On Wed, Jul 19, 2023 at 8:58 PM Alex Kiernan via
lists.openembedded.org 
wrote:
>
> On Wed, Jul 19, 2023 at 7:48 PM Alex Kiernan via
> lists.openembedded.org 
> wrote:
> >
> > On Wed, Jul 19, 2023 at 1:30 PM Alexandre Belloni
> >  wrote:
> > >
> > > Hello,
> > >
> > > I had a bit of trouble to find this but this causes the following
> > > oe-selftest failure:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/2274/steps/14/logs/stdio
> > >
> > > 2023-07-18 20:56:16,128 - oe-selftest - INFO - 
> > > gdbserver.GdbServerTest.test_gdb_server (subunit.RemotedTestCase)
> > > 2023-07-18 20:56:16,129 - oe-selftest - INFO -  ... ERROR
> > > Stderr:
> > > 2023-07-18 20:32:39,581 - oe-selftest - INFO - Adding: "include 
> > > selftest.inc" in 
> > > /home/pokybuild/yocto-worker/oe-selftest/build/build-st-836115/conf/local.conf
> > > 2023-07-18 20:32:39,582 - oe-selftest - INFO - Adding: "include 
> > > bblayers.inc" in bblayers.conf
> > > 2023-07-18 20:56:16,129 - oe-selftest - INFO - 14: 7/58 224/529 (269.86s) 
> > > (0 failed) (gdbserver.GdbServerTest.test_gdb_server)
> > > 2023-07-18 20:56:16,129 - oe-selftest - INFO - 
> > > testtools.testresult.real._StringException: Traceback (most recent call 
> > > last):
> > >   File 
> > > "/home/pokybuild/yocto-worker/oe-selftest/build/meta/lib/oeqa/selftest/cases/gdbserver.py",
> > >  line 43, in test_gdb_server
> > > shutil.unpack_archive(filename, debugfs)
> > >   File "/usr/lib64/python3.11/shutil.py", line 1323, in unpack_archive
> > > func(filename, extract_dir, **kwargs)
> > >   File "/usr/lib64/python3.11/shutil.py", line 1244, in _unpack_tarfile
> > > tarobj.extractall(extract_dir, filter=filter)
> > >   File "/usr/lib64/python3.11/tarfile.py", line 2257, in extractall
> > > self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
> > >   File "/usr/lib64/python3.11/tarfile.py", line 2324, in _extract_one
> > > self._handle_fatal_error(e)
> > >   File "/usr/lib64/python3.11/tarfile.py", line 2320, in _extract_one
> > > self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
> > >   File "/usr/lib64/python3.11/tarfile.py", line 2403, in _extract_member
> > > self.makefile(tarinfo, targetpath)
> > >   File "/usr/lib64/python3.11/tarfile.py", line 2448, in makefile
> > > with bltn_open(targetpath, "wb") as target:
> > >  ^^^
> > > PermissionError: [Errno 13] Permission denied: 
> > > '/tmp/debugfs-j_xgxhkm/./etc/gshadow'
> > >
> >
> > That's interesting... really not sure why /etc/shadow doesn't trigger
> > this failure too (which is in the same set of tarballs). That said
> > I've no idea what the fix is, since this looks like collateral damage
> > rather than something which this change obviously broke. Will stare at
> > it a bit more.
> >
>
> If I read the pieces right, we do:
>
> self._setup_dbg_rootfs(['/etc', '/var/lib/rpm',
> '/var/cache/dnf', '/var/lib/dnf'])
>
> I assume in order to prime the RPM config, which then copies gshadow
> (and the rest of /etc - ignoring that its not using ${sysconfdir}),
> which then causes this failure...
>
> Something like:
>
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index 890ba5f03984..a2e81afb4f09 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -162,6 +162,9 @@ class Rootfs(object, metaclass=ABCMeta):
>  bb.note("  Install extra debug packages...")
>  self.pm.install(extra_debug_pkgs.split(), True)
>
> +sysconfdir = self.image_rootfs + self.d.getVar('sysconfdir')
> +shutil.rmtree(sysconfdir)
> +
>  bb.note("  Rename debug rootfs...")
>  try:
>  shutil.rmtree(self.image_rootfs + '-dbg')
>
> Would appear sensible, but it feels rather "nuclear" and is way out of
> my comfort zone of a proposed change!
>

Have sent a change to rework the way rpm is handled when building the
debugfs, which I think is the root cause of this failure.

> > > On 14/07/2023 15:09:55+0100, Alex Kiernan wrote:
> > > > Fix startup warning:
> > > >
> > > >   udevd[171]: specified group 'sgx' unknown
> > > >
> > > > This mirrors the change in bab455cd9b1b ("systemd: add group sgx to udev
> > > > package") for systemd-udev.
> > > >
> > > > Signed-off-by: Alex Kiernan 
> > > > ---
> > > >
> > > >  meta/recipes-core/udev/eudev_3.2.12.bb | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-core/udev/eudev_3.2.12.bb 
> > > > b/meta/recipes-core/udev/eudev_3.2.12.bb
> > > > index 572ccecafd0c..4268bcc2c5de 100644
> > > > --- a/meta/recipes-core/udev/eudev_3.2.12.bb
> > > > +++ b/meta/recipes-core/udev/eudev_3.2.12.bb
> > > > @@ -18,7 +18,7 @@ SRC_URI[sha256sum] = 
> > > > "ccdd64ec3c381d3c3ed0e99d2e70d1f62988c7763de89ca7bdffafa5ea
> > > >
> > > >  GITHUB_BASE_URI = "https://github.com/eudev-project/eudev/releases;
> > > >
> > > > -inherit autotools update-rc.d qemu pkgconfig 

[OE-Core][PATCH v2 1/3] rootfs: Add debugfs package db file copy and cleanup

[Alex Kiernan]

When copying the package database files for the debugfs, add individual
file copy as well as tree copying. After the debug rootfs has been
created, cleanup the package files.

This then allows us to avoid a problem where (for rpm at least)
extraneous files in the debug rootfs would cause failures during
oe-selftest because some files existed in both regular and debugfs
images.

Signed-off-by: Alex Kiernan 
---

Changes in v2:
- New in v2

 meta/lib/oe/rootfs.py | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 890ba5f03984..1a48ed10b3f6 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -106,7 +106,7 @@ class Rootfs(object, metaclass=ABCMeta):
 def _cleanup(self):
 pass
 
-def _setup_dbg_rootfs(self, dirs):
+def _setup_dbg_rootfs(self, package_paths):
 gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
 if gen_debugfs != '1':
return
@@ -122,11 +122,12 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.utils.mkdirhier(self.image_rootfs)
 
 bb.note("  Copying back package database...")
-for dir in dirs:
-if not os.path.isdir(self.image_rootfs + '-orig' + dir):
-continue
-bb.utils.mkdirhier(self.image_rootfs + os.path.dirname(dir))
-shutil.copytree(self.image_rootfs + '-orig' + dir, 
self.image_rootfs + dir, symlinks=True)
+for path in package_paths:
+bb.utils.mkdirhier(self.image_rootfs + os.path.dirname(path))
+if os.path.isdir(self.image_rootfs + '-orig' + path):
+shutil.copytree(self.image_rootfs + '-orig' + path, 
self.image_rootfs + path, symlinks=True)
+elif os.path.isfile(self.image_rootfs + '-orig' + path):
+shutil.copyfile(self.image_rootfs + '-orig' + path, 
self.image_rootfs + path)
 
 # Copy files located in /usr/lib/debug or /usr/src/debug
 for dir in ["/usr/lib/debug", "/usr/src/debug"]:
@@ -162,6 +163,13 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.note("  Install extra debug packages...")
 self.pm.install(extra_debug_pkgs.split(), True)
 
+bb.note("  Removing package database...")
+for path in package_paths:
+if os.path.isdir(self.image_rootfs + path):
+shutil.rmtree(self.image_rootfs + path)
+elif os.path.isfile(self.image_rootfs + path):
+os.remove(self.image_rootfs + path)
+
 bb.note("  Rename debug rootfs...")
 try:
 shutil.rmtree(self.image_rootfs + '-dbg')
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184628): 
https://lists.openembedded.org/g/openembedded-core/message/184628
Mute This Topic: https://lists.openembedded.org/mt/100252894/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] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Petr Gotthard]

> -Original Message-
> From: Bruce Ashfield 
> Sent: Wednesday, July 19, 2023 11:56 PM
> To: Petr Gotthard 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

> >
> > The kernel is "linux-ti-staging_6.1" with quite standard settings.
> > Recently I did explicitly set CONFIG_LOCALVERSION_AUTO=n which was "y"
> > by default. With the default "y" setting I was getting a kernel version 
> > with two
> identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2", whereas the make-mod-
> scripts used "6.1.33-g8f7f371be2").
> 
> Did that only start happening recently ? because with the localversion_auto 
> and a
> set .scmversion, that's what I'd expect to happen (see below).

> I'm curious if on-target module builds work on those boards, since as near as 
> I can
> tell the versions won't match (as the .scmversion file isn't captured, so the
> vermagic will be different).

The commit 
https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
seems to be the cause here.
Before this commit all modules (both out-of-tree and the standard ones) had a 
version with one suffix ("6.1.33-g8f7f371be2") and could be loaded.
After this commit:
 - the standard modules have two suffxes ("6.1.33-g8f7f371be2-g8f7f371be2") and 
work fine
 - the out-of-tree modules have a "vermagic" with only one suffix 
("vermagic=6.1.33-g8f7f371be2") and fail due to the vermagic mismatch

Setting CONFIG_LOCALVERSION_AUTO=n removes one suffix from everything, so the 
mismatch for out-of-tree modules remains.


Petr


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

[oe-core][mickledore][PATCH 1/1] vim: upgrade 9.0.1527 -> 9.0.1592

[Polampalli, Archana via lists.openembedded.org]

From: Trevor Gamblin 

Fixes:

https://nvd.nist.gov/vuln/detail/CVE-2023-2609
d1ae836 patch 9.0.1531: crash when register contents ends up being invalid
https://nvd.nist.gov/vuln/detail/CVE-2023-2610
ab9a2d8 patch 9.0.1532: crash when expanding "~" in substitute causes very long 
text

Signed-off-by: Trevor Gamblin 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
Signed-off-by: Archana Polampalli 
---
 meta/recipes-support/vim/vim.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc
index e1d2563316..33ae0d8079 100644
--- a/meta/recipes-support/vim/vim.inc
+++ b/meta/recipes-support/vim/vim.inc
@@ -19,8 +19,8 @@ SRC_URI = 
"git://github.com/vim/vim.git;branch=master;protocol=https \
file://no-path-adjust.patch \
"
 
-PV .= ".1527"
-SRCREV = "c28e7a2b2f23dbd246a1ad7ad7aaa6f7ab2e5887"
+PV .= ".1592"
+SRCREV = "29b4c513b11deb37f0e0538df53d195f602fa42c"
 
 # Remove when 8.3 is out
 UPSTREAM_VERSION_UNKNOWN = "1"
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184626): 
https://lists.openembedded.org/g/openembedded-core/message/184626
Mute This Topic: https://lists.openembedded.org/mt/100252286/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][dunfell][PATCH] qemu: backport Debian patch to fix CVE-2023-0330

[Philippe Mathieu-Daudé]

On 14/7/23 15:54, Vijay Anusuri wrote:

From: Vijay Anusuri 

import patch from ubuntu to fix
  CVE-2023-0330

Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/patches?h=ubuntu/focal-security
Upstream commit
https://gitlab.com/qemu-project/qemu/-/commit/b987718bbb1d0eabf95499b976212dd5f0120d75]

Signed-off-by: Vijay Anusuri 
---
  meta/recipes-devtools/qemu/qemu.inc   |  1 +
  .../qemu/qemu/CVE-2023-0330.patch | 77 +++
  2 files changed, 78 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch


Reviewed-by: Philippe Mathieu-Daudé 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184625): 
https://lists.openembedded.org/g/openembedded-core/message/184625
Mute This Topic: https://lists.openembedded.org/mt/100141528/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] qemu: backport Debian patch to fix CVE-2023-0330

[Philippe Mathieu-Daudé]

On 18/7/23 08:01, Vijay Anusuri wrote:

From: Vijay Anusuri 

import patch from ubuntu to fix
  CVE-2023-0330

Upstream-Status: Backport [import from ubuntu 
https://git.launchpad.net/ubuntu/+source/qemu/tree/debian/patches?h=ubuntu/jammy-security
Upstream commit 
https://gitlab.com/qemu-project/qemu/-/commit/b987718bbb1d0eabf95499b976212dd5f0120d75]

Signed-off-by: Vijay Anusuri 
---
  meta/recipes-devtools/qemu/qemu.inc   |  1 +
  .../qemu/qemu/CVE-2023-0330.patch | 75 +++
  2 files changed, 76 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch


Reviewed-by: Philippe Mathieu-Daudé 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184624): 
https://lists.openembedded.org/g/openembedded-core/message/184624
Mute This Topic: https://lists.openembedded.org/mt/100210714/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][mickledore][PATCH 1/1] qemu: fix CVE-2023-0330

[Philippe Mathieu-Daudé]

On 18/7/23 17:35, Polampalli, Archana via lists.openembedded.org wrote:

A vulnerability in the lsi53c895a device affects the latest version
of qemu. A DMA-MMIO reentrancy problem may lead to memory corruption
bugs like stack overflow or use-after-free.

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

Upstream patches:
https://gitlab.com/qemu-project/qemu/-/commit/b987718bbb1d0eabf95499b976212dd5f0120d75

Signed-off-by: Archana Polampalli 
---
  meta/recipes-devtools/qemu/qemu.inc   |  1 +
  .../qemu/qemu/CVE-2023-0330.patch | 75 +++
  2 files changed, 76 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-0330.patch


Reviewed-by: Philippe Mathieu-Daudé 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184623): 
https://lists.openembedded.org/g/openembedded-core/message/184623
Mute This Topic: https://lists.openembedded.org/mt/100217890/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] cve_check: convert CVE_CHECK_IGNORE to CVE_STATUS

[Andrej Valek via lists.openembedded.org]

- Try to add convert and apply statuses for old CVEs
- Drop some obsolete ignores, while they are not relevant for current
  version

Signed-off-by: Andrej Valek 
Reviewed-by: Peter Marko 
---
 .../distro/include/cve-extra-exclusions.inc   | 149 
 meta/recipes-bsp/grub/grub2.inc   |   6 +-
 meta/recipes-connectivity/avahi/avahi_0.8.bb  |   3 +-
 .../recipes-connectivity/bind/bind_9.18.16.bb |   2 +-
 .../bluez5/bluez5_5.68.bb |   4 +-
 .../openssh/openssh_9.3p1.bb  |   9 +-
 .../openssl/openssl_3.1.1.bb  |   3 +-
 meta/recipes-core/coreutils/coreutils_9.3.bb  |   4 +-
 meta/recipes-core/glibc/glibc_2.37.bb |  17 +-
 meta/recipes-core/libxml/libxml2_2.11.4.bb|   4 -
 meta/recipes-core/systemd/systemd_253.3.bb|   3 -
 meta/recipes-devtools/cmake/cmake.inc |   4 +-
 meta/recipes-devtools/flex/flex_2.6.4.bb  |   6 +-
 meta/recipes-devtools/gcc/gcc-13.1.inc|   3 +-
 meta/recipes-devtools/git/git_2.39.3.bb   |   7 -
 meta/recipes-devtools/jquery/jquery_3.6.3.bb  |   5 +-
 meta/recipes-devtools/ninja/ninja_1.11.1.bb   |   3 +-
 .../recipes-devtools/python/python3_3.11.4.bb |  16 +-
 meta/recipes-devtools/qemu/qemu.inc   |  13 +-
 meta/recipes-devtools/rsync/rsync_3.2.7.bb|   3 -
 meta/recipes-devtools/tcltk/tcl_8.6.13.bb |   4 -
 meta/recipes-extended/cpio/cpio_2.14.bb   |   3 +-
 meta/recipes-extended/cups/cups.inc   |  17 +-
 .../iputils/iputils_20221126.bb   |   5 +-
 .../libtirpc/libtirpc_1.3.3.bb|   3 +-
 meta/recipes-extended/procps/procps_4.0.3.bb  |   4 -
 meta/recipes-extended/shadow/shadow_4.13.bb   |   7 +-
 meta/recipes-extended/unzip/unzip_6.0.bb  |   3 +-
 .../xinetd/xinetd_2.3.15.4.bb |   2 +-
 meta/recipes-extended/zip/zip_3.0.bb  |   7 +-
 .../libnotify/libnotify_0.8.2.bb  |   2 +-
 meta/recipes-gnome/librsvg/librsvg_2.56.1.bb  |   3 +-
 meta/recipes-graphics/builder/builder_0.1.bb  |   3 +-
 .../xorg-xserver/xserver-xorg.inc |  19 +-
 .../linux/cve-exclusion_6.1.inc   | 361 --
 .../libpng/libpng_1.6.40.bb   |   3 +-
 meta/recipes-multimedia/libtiff/tiff_4.5.1.bb |   4 +-
 .../libgcrypt/libgcrypt_1.10.2.bb |   4 +-
 .../recipes-support/libxslt/libxslt_1.1.38.bb |   4 +-
 meta/recipes-support/lz4/lz4_1.9.4.bb |   3 +-
 meta/recipes-support/sqlite/sqlite3_3.42.0.bb |   6 -
 41 files changed, 310 insertions(+), 421 deletions(-)

diff --git a/meta/conf/distro/include/cve-extra-exclusions.inc 
b/meta/conf/distro/include/cve-extra-exclusions.inc
index 0ae63e2c63..61fb08dbeb 100644
--- a/meta/conf/distro/include/cve-extra-exclusions.inc
+++ b/meta/conf/distro/include/cve-extra-exclusions.inc
@@ -15,44 +15,43 @@
 # the aim of sharing that work and ensuring we don't duplicate it.
 #
 
+# strace https://nvd.nist.gov/vuln/detail/CVE-2000-0006
+CVE_STATUS[CVE-2000-0006] = "upstream-wontfix: CVE is more than 20 years old \
+with no resolution evident. Broken links in CVE database references make 
resolution impractical."
 
-# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
-# CVE is more than 20 years old with no resolution evident
-# broken links in CVE database references make resolution impractical
-CVE_CHECK_IGNORE += "CVE-2000-0006"
-
-# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238
-# The issue here is spoofing of domain names using characters from other 
character sets.
-# There has been much discussion amongst the epiphany and webkit developers and
-# whilst there are improvements about how domains are handled and displayed to 
the user
-# there is unlikely ever to be a single fix to webkit or epiphany which 
addresses this
-# problem. Ignore this CVE as there isn't any mitigation or fix or way to 
progress this further
-# we can seem to take.
-CVE_CHECK_IGNORE += "CVE-2005-0238"
-
-# glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756
-# Issue is memory exhaustion via glob() calls, e.g. from within an ftp server
-# Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681
-# Upstream don't see it as a security issue, ftp servers shouldn't be passing
-# this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT 
or similar
-CVE_CHECK_IGNORE += "CVE-2010-4756"
-
-# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509
-# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511
-# The encoding/xml package in go can potentially be used for security exploits 
if not used correctly
-# CVE applies to a netapp product as well as flagging a general issue. We 
don't ship anything
-# exposing this interface in an exploitable way
-CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511"
+# epiphany https://nvd.nist.gov/vuln/detail/CVE-2005-0238
+CVE_STATUS[CVE-2005-0238] = "upstream-wontfix: \
+The issue here is spoofing 

[OE-core] [dunfell][PATCH] ruby/cgi-gem: CVE-2021-33621 HTTP response splitting in CGI

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://github.com/ruby/cgi/commit/64c5045c0a6b84fdb938a8465a0890e5f7162708

Signed-off-by: Hitendra Prajapati 
---
 .../ruby/ruby/CVE-2021-33621.patch| 139 ++
 meta/recipes-devtools/ruby/ruby_2.7.6.bb  |   1 +
 2 files changed, 140 insertions(+)
 create mode 100644 meta/recipes-devtools/ruby/ruby/CVE-2021-33621.patch

diff --git a/meta/recipes-devtools/ruby/ruby/CVE-2021-33621.patch 
b/meta/recipes-devtools/ruby/ruby/CVE-2021-33621.patch
new file mode 100644
index 00..cc2f9853db
--- /dev/null
+++ b/meta/recipes-devtools/ruby/ruby/CVE-2021-33621.patch
@@ -0,0 +1,139 @@
+From 64c5045c0a6b84fdb938a8465a0890e5f7162708 Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh 
+Date: Tue, 22 Nov 2022 10:49:27 +0900
+Subject: [PATCH] Prevent CRLF injection
+
+Throw a RuntimeError if the HTTP response header contains CR or LF to
+prevent HTTP response splitting.
+
+https://hackerone.com/reports/1204695
+
+Upstream-Status: Backport 
[https://github.com/ruby/cgi/commit/64c5045c0a6b84fdb938a8465a0890e5f7162708]
+CVE: CVE-2021-33621
+Signed-off-by: Hitendra Prajapati 
+---
+ lib/cgi/core.rb | 45 +++--
+ test/cgi/test_cgi_header.rb |  8 +++
+ 2 files changed, 36 insertions(+), 17 deletions(-)
+
+diff --git a/lib/cgi/core.rb b/lib/cgi/core.rb
+index bec76e0..62e6068 100644
+--- a/lib/cgi/core.rb
 b/lib/cgi/core.rb
+@@ -188,17 +188,28 @@ class CGI
+   # Using #header with the HTML5 tag maker will create a  element.
+   alias :header :http_header
+ 
++  def _no_crlf_check(str)
++if str
++  str = str.to_s
++  raise "A HTTP status or header field must not include CR and LF" if str 
=~ /[\r\n]/
++  str
++else
++  nil
++end
++  end
++  private :_no_crlf_check
++
+   def _header_for_string(content_type) #:nodoc:
+ buf = ''.dup
+ if nph?()
+-  buf << "#{$CGI_ENV['SERVER_PROTOCOL'] || 'HTTP/1.0'} 200 OK#{EOL}"
++  buf << "#{_no_crlf_check($CGI_ENV['SERVER_PROTOCOL']) || 'HTTP/1.0'} 
200 OK#{EOL}"
+   buf << "Date: #{CGI.rfc1123_date(Time.now)}#{EOL}"
+-  buf << "Server: #{$CGI_ENV['SERVER_SOFTWARE']}#{EOL}"
++  buf << "Server: #{_no_crlf_check($CGI_ENV['SERVER_SOFTWARE'])}#{EOL}"
+   buf << "Connection: close#{EOL}"
+ end
+-buf << "Content-Type: #{content_type}#{EOL}"
++buf << "Content-Type: #{_no_crlf_check(content_type)}#{EOL}"
+ if @output_cookies
+-  @output_cookies.each {|cookie| buf << "Set-Cookie: #{cookie}#{EOL}" }
++  @output_cookies.each {|cookie| buf << "Set-Cookie: 
#{_no_crlf_check(cookie)}#{EOL}" }
+ end
+ return buf
+   end # _header_for_string
+@@ -213,9 +224,9 @@ class CGI
+ ## NPH
+ options.delete('nph') if defined?(MOD_RUBY)
+ if options.delete('nph') || nph?()
+-  protocol = $CGI_ENV['SERVER_PROTOCOL'] || 'HTTP/1.0'
++  protocol = _no_crlf_check($CGI_ENV['SERVER_PROTOCOL']) || 'HTTP/1.0'
+   status = options.delete('status')
+-  status = HTTP_STATUS[status] || status || '200 OK'
++  status = HTTP_STATUS[status] || _no_crlf_check(status) || '200 OK'
+   buf << "#{protocol} #{status}#{EOL}"
+   buf << "Date: #{CGI.rfc1123_date(Time.now)}#{EOL}"
+   options['server'] ||= $CGI_ENV['SERVER_SOFTWARE'] || ''
+@@ -223,38 +234,38 @@ class CGI
+ end
+ ## common headers
+ status = options.delete('status')
+-buf << "Status: #{HTTP_STATUS[status] || status}#{EOL}" if status
++buf << "Status: #{HTTP_STATUS[status] || _no_crlf_check(status)}#{EOL}" 
if status
+ server = options.delete('server')
+-buf << "Server: #{server}#{EOL}" if server
++buf << "Server: #{_no_crlf_check(server)}#{EOL}" if server
+ connection = options.delete('connection')
+-buf << "Connection: #{connection}#{EOL}" if connection
++buf << "Connection: #{_no_crlf_check(connection)}#{EOL}" if connection
+ type = options.delete('type')
+-buf << "Content-Type: #{type}#{EOL}" #if type
++buf << "Content-Type: #{_no_crlf_check(type)}#{EOL}" #if type
+ length = options.delete('length')
+-buf << "Content-Length: #{length}#{EOL}" if length
++buf << "Content-Length: #{_no_crlf_check(length)}#{EOL}" if length
+ language = options.delete('language')
+-buf << "Content-Language: #{language}#{EOL}" if language
++buf << "Content-Language: #{_no_crlf_check(language)}#{EOL}" if language
+ expires = options.delete('expires')
+ buf << "Expires: #{CGI.rfc1123_date(expires)}#{EOL}" if expires
+ ## cookie
+ if cookie = options.delete('cookie')
+   case cookie
+   when String, Cookie
+-buf << "Set-Cookie: #{cookie}#{EOL}"
++buf << "Set-Cookie: #{_no_crlf_check(cookie)}#{EOL}"
+   when Array
+ arr = cookie
+-arr.each {|c| buf << "Set-Cookie: #{c}#{EOL}" }
++arr.each {|c| buf << "Set-Cookie: #{_no_crlf_check(c)}#{EOL}" }
+   when Hash
+ hash = cookie
+-hash.each_value {|c|