[OE-core] Rust crate checksums

[Alex Kiernan]

Unless I'm missing something, I just realised that we're not
validating downloaded crate checksums when we fetch them with crate://
- Surely we should be?

-- 
Alex Kiernan

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

[Jing Hui Tham]

Hi All,
 
QA for yocto-3.1.22.rc1 is completed. This is the full report for this release: 
 
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Saturday, 14 January, 2023 10:11 AM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder 
> build
> (yocto-3.1.22.rc1)
> 
> 
> A build flagged for QA (yocto-3.1.22.rc1) was completed on the autobuilder and
> is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.1.22.rc1
> 
> 
> Build hash information:
> 
> bitbake: e3db9c2e9eded3c5cb6040714a6054b44f6b3880
> meta-agl: ae982d798a979ee5690bee00ca90a2855bab4802
> meta-arm: d13be36099aff7ea2975a1a197564e2e801707a3
> meta-aws: c013258cecbf99528291e55005e1db360d7eb40b
> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> meta-intel: 6c202291925bb179d2d08b5bde80192f9b032b88
> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
> meta-openembedded: 7952135f650b4a754e2255f5aa03973a32344123
> meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
> oecore: db81e3c7e7f1d4d9eba52ac35ac97627d0240b63
> poky: 6b8a307b7843af23d189d7ffcecf32c05afac850
> 
> 
> 
> 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 (#176124): 
https://lists.openembedded.org/g/openembedded-core/message/176124
Mute This Topic: https://lists.openembedded.org/mt/96322176/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [kirkstone][PATCH v2] go: fix CVE-2022-41717 Excessive memory use in got server

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://github.com/golang/go/commit/618120c165669c00a1606505defea6ca755cdc27

Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |  1 +
 .../go/go-1.18/CVE-2022-41717.patch   | 89 +++
 2 files changed, 90 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.18/CVE-2022-41717.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index a1942e9f15..99662bd298 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -19,6 +19,7 @@ SRC_URI += "\
 file://CVE-2022-27664.patch \
 file://0001-net-http-httputil-avoid-query-parameter-smuggling.patch \
 file://CVE-2022-41715.patch \
+file://CVE-2022-41717.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.18/CVE-2022-41717.patch 
b/meta/recipes-devtools/go/go-1.18/CVE-2022-41717.patch
new file mode 100644
index 00..e2ab92ed00
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.18/CVE-2022-41717.patch
@@ -0,0 +1,89 @@
+From 618120c165669c00a1606505defea6ca755cdc27 Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Wed, 30 Nov 2022 16:46:33 -0500
+Subject: [PATCH] [release-branch.go1.19] net/http: update bundled
+ golang.org/x/net/http2
+
+Disable cmd/internal/moddeps test, since this update includes PRIVATE
+track fixes.
+
+For #56350.
+For #57009.
+Fixes CVE-2022-41717.
+
+Change-Id: I5c6ce546add81f361dcf0d5123fa4eaaf8f0a03b
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1663835
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Julie Qiu 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/455363
+TryBot-Result: Gopher Robot 
+Run-TryBot: Jenny Rakoczy 
+Reviewed-by: Michael Pratt 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/618120c165669c00a1606505defea6ca755cdc27]
+CVE: CVE-2022-41717
+Signed-off-by: Hitendra Prajapati 
+---
+ src/cmd/internal/moddeps/moddeps_test.go |  1 +
+ src/net/http/h2_bundle.go| 18 +++---
+ 2 files changed, 12 insertions(+), 7 deletions(-)
+
+diff --git a/src/cmd/internal/moddeps/moddeps_test.go 
b/src/cmd/internal/moddeps/moddeps_test.go
+index 3306e29..d48d43f 100644
+--- a/src/cmd/internal/moddeps/moddeps_test.go
 b/src/cmd/internal/moddeps/moddeps_test.go
+@@ -34,6 +34,7 @@ import (
+ // See issues 36852, 41409, and 43687.
+ // (Also see golang.org/issue/27348.)
+ func TestAllDependencies(t *testing.T) {
++  t.Skip("TODO(#57009): 1.19.4 contains unreleased changes from vendored 
modules")
+   t.Skip("TODO(#53977): 1.18.5 contains unreleased changes from vendored 
modules")
+ 
+   goBin := testenv.GoToolPath(t)
+diff --git a/src/net/http/h2_bundle.go b/src/net/http/h2_bundle.go
+index 6e2ef30..9d6abd8 100644
+--- a/src/net/http/h2_bundle.go
 b/src/net/http/h2_bundle.go
+@@ -4189,6 +4189,7 @@ type http2serverConn struct {
+   headerTableSize uint32
+   peerMaxHeaderListSize   uint32// zero means unknown 
(default)
+   canonHeader map[string]string // http2-lower-case -> 
Go-Canonical-Case
++  canonHeaderKeysSize int   // canonHeader keys size 
in bytes
+   writingFramebool  // started writing a 
frame (on serve goroutine or separate)
+   writingFrameAsync   bool  // started a frame on its 
own goroutine but haven't heard back on wroteFrameCh
+   needsFrameFlush bool  // last frame write 
wasn't a flush
+@@ -4368,6 +4369,13 @@ func (sc *http2serverConn) condlogf(err error, format 
string, args ...interface{
+   }
+ }
+ 
++// maxCachedCanonicalHeadersKeysSize is an arbitrarily-chosen limit on the 
size
++// of the entries in the canonHeader cache.
++// This should be larger than the size of unique, uncommon header keys likely 
to
++// be sent by the peer, while not so high as to permit unreasonable memory 
usage
++// if the peer sends an unbounded number of unique header keys.
++const http2maxCachedCanonicalHeadersKeysSize = 2048
++
+ func (sc *http2serverConn) canonicalHeader(v string) string {
+   sc.serveG.check()
+   http2buildCommonHeaderMapsOnce()
+@@ -4383,14 +4391,10 @@ func (sc *http2serverConn) canonicalHeader(v string) 
string {
+   sc.canonHeader = make(map[string]string)
+   }
+   cv = CanonicalHeaderKey(v)
+-  // maxCachedCanonicalHeaders is an arbitrarily-chosen limit on the 
number of
+-  // entries in the canonHeader cache. This should be larger than the 
number
+-  // of unique, uncommon header keys likely to be sent by the peer, while 
not
+-  // so high as to permit unreaasonable memory usage if the peer sends an 
unbounded
+-  // number of unique header keys.
+-  const maxCachedCanonicalHeaders 

[OE-Core][master][kirkstone][PATCH] numactl: skip test case when target platform doesn't have 2 CPU node

[Xiangyu Chen]

From: Xiangyu Chen 

when current test platform doesn't have 2 or more CPU node, the test
case would report FAIL, according to numa test script and numademo
code, when return code=77 should be skip test, so using SKIP instead
of FAIL in test script.

Signed-off-by: Xiangyu Chen 
---
 .../numactl/numactl/Fix-the-test-output-format.patch| 3 ++-
 meta/recipes-support/numactl/numactl/run-ptest  | 6 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-support/numactl/numactl/Fix-the-test-output-format.patch 
b/meta/recipes-support/numactl/numactl/Fix-the-test-output-format.patch
index 9812ecc8b3..a7bc8d322e 100644
--- a/meta/recipes-support/numactl/numactl/Fix-the-test-output-format.patch
+++ b/meta/recipes-support/numactl/numactl/Fix-the-test-output-format.patch
@@ -7,6 +7,7 @@ Upstream-Status: Pending
 
 Signed-off-by: Roy Li 
 Signed-off-by: Li Xin 
+Signed-off-by: Xiangyu Chen 
 ---
  test/regress  |  6 +++---
  test/regress2 | 11 +--
@@ -20,7 +21,7 @@ index 2ce1705..d086a47 100755
if [ $numnodes -lt 2 ] ; then
echo "need at least two nodes with at least $NEEDPAGES each of"
echo "free memory for mempolicy regression tests"
-+  echo "FAIL: numa regress"
++  echo "SKIP: numa regress"
exit 77  # Skip test
fi
  }
diff --git a/meta/recipes-support/numactl/numactl/run-ptest 
b/meta/recipes-support/numactl/numactl/run-ptest
index bf269da755..e019b0d364 100755
--- a/meta/recipes-support/numactl/numactl/run-ptest
+++ b/meta/recipes-support/numactl/numactl/run-ptest
@@ -8,7 +8,11 @@ if ! numactl -s | grep -q "No NUMA support available on this 
system."; then
if  numademo -t -e 10M; then
echo "PASS: numademo"
else
-   echo "FAIL: numademo"
+   if [ "$?" = 77 ] ; then
+   echo "SKIP: numademo"
+   else
+   echo "FAIL: numademo"
+   fi
fi
 else
echo "SKIP: ./../test/bind_range"
-- 
2.34.1


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

Re: [OE-core] [PATCH v2 5/5] defaultsetup: Enable largefile and 64bit time_t support systemwide

[Khem Raj]

On Wed, Jan 18, 2023 at 7:59 AM Richard Purdie
 wrote:
>
> On Tue, 2023-01-03 at 12:05 -0800, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/distro/defaultsetup.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/distro/defaultsetup.conf 
> > b/meta/conf/distro/defaultsetup.conf
> > index f6894f3ab5..1abb509629 100644
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -2,7 +2,7 @@ include conf/distro/include/default-providers.inc
> >  include conf/distro/include/default-versions.inc
> >  include conf/distro/include/default-distrovars.inc
> >  include conf/distro/include/maintainers.inc
> > -
> > +include conf/distro/include/time64.inc
> >  require conf/distro/include/tcmode-${TCMODE}.inc
> >  require conf/distro/include/tclibc-${TCLIBC}.inc
> >
>
>
> I tried this as requested. I saw:
>
> x86 binutils do_compile failure:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/6562/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/103/builds/5424/steps/12/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/6572/steps/12/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/6493/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/6528/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/5304/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio
>
> lib32-binutils do_compile failure:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/4042/steps/12/logs/stdio
>
> mingw binutils do_compile:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/6562/steps/13/logs/stdio
>

all binutils errors reduce to a single problem, its in gprofng and
uses *64 versions of syscall
functions which are not available when using 64bit off_t. I have some
ideas about fixing it

> meta-virt xen-tools do_compile:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/1166/steps/20/logs/stdio
>

This looks like a simple printf format error which can be fixed easily
by using %j printf format
and typecasting now - conn->ta_start_time to intmax_t(now - conn->ta_start_time)

> qemuarm glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6539/steps/19/logs/stdio
>
> qemumips glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/6500/steps/20/logs/stdio
>
> qemux86 glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/20/logs/stdio
>

as mentioned in previous email. We can try it with upcoming glibc.

> Close, but not quite there!

indeed

>
>
> Cheers,
>
> Richard

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

Re: [OE-core] [PATCH v2 5/5] defaultsetup: Enable largefile and 64bit time_t support systemwide

[Khem Raj]

On Wed, Jan 18, 2023 at 7:59 AM Richard Purdie
 wrote:
>
> On Tue, 2023-01-03 at 12:05 -0800, Khem Raj wrote:
> > Signed-off-by: Khem Raj 
> > ---
> >  meta/conf/distro/defaultsetup.conf | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/distro/defaultsetup.conf 
> > b/meta/conf/distro/defaultsetup.conf
> > index f6894f3ab5..1abb509629 100644
> > --- a/meta/conf/distro/defaultsetup.conf
> > +++ b/meta/conf/distro/defaultsetup.conf
> > @@ -2,7 +2,7 @@ include conf/distro/include/default-providers.inc
> >  include conf/distro/include/default-versions.inc
> >  include conf/distro/include/default-distrovars.inc
> >  include conf/distro/include/maintainers.inc
> > -
> > +include conf/distro/include/time64.inc
> >  require conf/distro/include/tcmode-${TCMODE}.inc
> >  require conf/distro/include/tclibc-${TCLIBC}.inc
> >
>
>
> I tried this as requested. I saw:
>
> x86 binutils do_compile failure:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/6562/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/103/builds/5424/steps/12/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/6572/steps/12/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/6493/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/6528/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/5304/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio
>
> lib32-binutils do_compile failure:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/4042/steps/12/logs/stdio
>
> mingw binutils do_compile:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/6562/steps/13/logs/stdio
>
> meta-virt xen-tools do_compile:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/1166/steps/20/logs/stdio
>
> qemuarm glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6539/steps/19/logs/stdio
>
> qemumips glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/6500/steps/20/logs/stdio
>
> qemux86 glibc-testsuite issue:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/20/logs/stdio
>
> Close, but not quite there!

Thanks for trying it out. I did realize that we will be better off
trying with upcoming glibc 2.37
I have a patch for the upgrade on the yoe/mut  poky-contrib branch. cherry-pick

[WIP] glibc: Upgrade to 2.37

on

https://git.yoctoproject.org/poky-contrib/log/?h=yoe/mut

as is with glibc upgrade, there might be other gotchas e.g. uninative
generation etc. but
meta-oe AB job has been using this glibc for some time now.

>
>
> Cheers,
>
> Richard

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

[Khem Raj]

Backport needed patches and remove local workaround

Signed-off-by: Khem Raj 
---
 .../elfutils/elfutils_0.188.bb|  4 +-
 ...od-Fix-usage-of-deprecated-CURLINFO_.patch | 49 +++
 ...t-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch | 34 +
 3 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch
 create mode 100644 
meta/recipes-devtools/elfutils/files/0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.188.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.188.bb
index 084908a38c..65cae868c7 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.188.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.188.bb
@@ -21,6 +21,8 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://0001-skip-the-test-when-gcc-not-deployed.patch \
file://ptest.patch \

file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
+   
file://0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch \
+   
file://0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch \
"
 SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
@@ -33,8 +35,6 @@ inherit autotools gettext ptest pkgconfig
 EXTRA_OECONF = "--program-prefix=eu-"
 
 BUILD_CFLAGS += "-Wno-error=stringop-overflow"
-# compatibility with curl 7.87; can be removed when elfutils upstream fixes 
the deprecation fails
-CFLAGS:append = " -Wno-error=deprecated-declarations"
 
 DEPENDS_BZIP2 = "bzip2-replacement-native"
 DEPENDS_BZIP2:class-target = "bzip2"
diff --git 
a/meta/recipes-devtools/elfutils/files/0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch
 
b/meta/recipes-devtools/elfutils/files/0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch
new file mode 100644
index 00..ee192e3581
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch
@@ -0,0 +1,49 @@
+From d2bf497b12fbd49b4996ccf0744303ffd67735b1 Mon Sep 17 00:00:00 2001
+From: Andrew Paprocki 
+Date: Wed, 21 Dec 2022 11:15:00 -0500
+Subject: [PATCH] PR29926: debuginfod: Fix usage of deprecated CURLINFO_*
+
+The `CURLINFO_SIZE_DOWNLOAD_T` and `CURLINFO_CONTENT_LENGTH_DOWNLOAD_T`
+identifiers are `enum`s, not pre-processor definitions, so the current
+`#ifdef` logic is not selecting the newer API.  This results in the
+older identifiers being used and they now generate errors when compiled
+against Curl 7.87, which has silently deprecated them, causing GCC to
+emit `-Werror=deprecated-declarations`.
+
+Instead, the newer identifiers were added in Curl 7.55, so explicitly
+check for `CURL_AT_LEAST_VERSION(7, 55, 0)` instead of the current
+logic.  This eliminates the error when compiling against Curl 7.87.
+
+Ref: https://github.com/curl/curl/pull/1511
+
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=elfutils.git;a=commit;h=d2bf497b12fbd49b4996ccf0744303ffd67735b1]
+Signed-off-by: Andrew Paprocki 
+---
+ debuginfod/debuginfod-client.c | 4 ++--
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
+index 8873fcc8..692aecce 100644
+--- a/debuginfod/debuginfod-client.c
 b/debuginfod/debuginfod-client.c
+@@ -1456,7 +1456,7 @@ debuginfod_query_server (debuginfod_client *c,
+  deflate-compressing proxies, this number is likely to be
+  unavailable, so -1 may show. */
+   CURLcode curl_res;
+-#ifdef CURLINFO_CONTENT_LENGTH_DOWNLOAD_T
++#if CURL_AT_LEAST_VERSION(7, 55, 0)
+   curl_off_t cl;
+   curl_res = curl_easy_getinfo(target_handle,
+CURLINFO_CONTENT_LENGTH_DOWNLOAD_T,
+@@ -1491,7 +1491,7 @@ debuginfod_query_server (debuginfod_client *c,
+   if (target_handle) /* we've committed to a server; report its 
download progress */
+ {
+   CURLcode curl_res;
+-#ifdef CURLINFO_SIZE_DOWNLOAD_T
++#if CURL_AT_LEAST_VERSION(7, 55, 0)
+   curl_off_t dl;
+   curl_res = curl_easy_getinfo(target_handle,
+CURLINFO_SIZE_DOWNLOAD_T,
+-- 
+2.39.1
+
diff --git 
a/meta/recipes-devtools/elfutils/files/0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch
 
b/meta/recipes-devtools/elfutils/files/0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch
new file mode 100644
index 00..2d4c912e82
--- /dev/null
+++ 
b/meta/recipes-devtools/elfutils/files/0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch
@@ -0,0 +1,34 @@
+From 6560fb26a62ef135a804357ef4f15a47de3e49b3 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard 
+Date: Tue, 10 Jan 2023 23:20:41 +0100
+Subject: [PATCH] debuginfod-client: Use 

[OE-core] [PATCH v2 2/3] binutils: Package libsframe

[Khem Raj]

libsframe is newly added in binutils 2.40

Signed-off-by: Khem Raj 
---
v1 -> v2:
- Rebase

 meta/recipes-devtools/binutils/binutils_2.40.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/binutils/binutils_2.40.bb 
b/meta/recipes-devtools/binutils/binutils_2.40.bb
index 67240383f7..9087af87c5 100644
--- a/meta/recipes-devtools/binutils/binutils_2.40.bb
+++ b/meta/recipes-devtools/binutils/binutils_2.40.bb
@@ -66,7 +66,7 @@ PACKAGE_BEFORE_PN += "libbfd libopcodes gprofng"
 FILES:libbfd = "${libdir}/libbfd-*.so.* ${libdir}/libbfd-*.so"
 FILES:libopcodes = "${libdir}/libopcodes-*.so.* ${libdir}/libopcodes-*.so"
 FILES:gprofng = "${sysconfdir}/gprofng.rc ${libdir}/gprofng/libgp-*.so 
${libdir}/gprofng/libgprofng.so.* ${bindir}/gp-* ${bindir}/gprofng"
-FILES:${PN}-dev += "${libdir}/gprofng/libgprofng.so"
+FILES:${PN}-dev += "${libdir}/gprofng/libgprofng.so ${libdir}/libsframe.so"
 SRC_URI:append:class-nativesdk =  " 
file://0003-binutils-nativesdk-Search-for-alternative-ld.so.conf.patch "
 
 USE_ALTERNATIVES_FOR:class-nativesdk = ""
-- 
2.39.1


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

[OE-core] [kirkstone][PATCH] glibc: explicit use the internal __time64_t type

[Yu, Mingli]

From: Mingli Yu 

Backport a patch [1] to explicit use the internal __time64_t type
to fix the issue that nscd wrongly cut /etc/hosts to be /hosts on
32bits system.

Before the patch:
  root@qemux86:~# systemctl status nscd
* nscd.service - Name Service Cache Daemon
 Loaded: loaded (/lib/systemd/system/nscd.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Mon 2022-07-25 09:17:41 UTC; 41s ago
Process: 264 ExecStart=/usr/sbin/nscd (code=exited, status=0/SUCCESS)
   Main PID: 267 (nscd)
  Tasks: 10 (limit: 4810)
 Memory: 992.0K
 CGroup: /system.slice/nscd.service
 `-267 /usr/sbin/nscd

Jul 25 09:17:57 qemux86 nscd[267]: 267 checking for monitored file `/hosts': No 
such file or directory
Jul 25 09:17:59 qemux86 nscd[267]: 267 checking for monitored file 
`/nsswitch.conf': No such file or directory
Jul 25 09:17:59 qemux86 nscd[267]: 267 checking for monitored file `/services': 
No such file or directory
Jul 25 09:18:13 qemux86 nscd[267]: 267 checking for monitored file 
`/nsswitch.conf': No such file or directory
Jul 25 09:18:13 qemux86 nscd[267]: 267 checking for monitored file 
`/resolv.conf': No such file or directory
Jul 25 09:18:13 qemux86 nscd[267]: 267 checking for monitored file `/hosts': No 
such file or directory
Jul 25 09:18:14 qemux86 nscd[267]: 267 checking for monitored file 
`/nsswitch.conf': No such file or directory
Jul 25 09:18:14 qemux86 nscd[267]: 267 checking for monitored file `/services': 
No such file or directory
Jul 25 09:18:18 qemux86 nscd[267]: 267 checking for monitored file 
`/nsswitch.conf': No such file or directory
Jul 25 09:18:18 qemux86 nscd[267]: 267 checking for monitored file `/passwd': 
No such file or directory
Jul 25 09:18:28 qemux86 nscd[267]: 267 checking for monitored file 
`/nsswitch.conf': No such file or directory
Jul 25 09:18:28 qemux86 nscd[267]: 267 checking for monitored file 
`/resolv.conf': No such file or directory
Jul 25 09:18:28 qemux86 nscd[267]: 267 checking for monitored file `/hosts': No 
such file or directory

After the patch:
  root@qemux86:~# systemctl status nscd
* nscd.service - Name Service Cache Daemon
 Loaded: loaded (/lib/systemd/system/nscd.service; enabled; vendor preset: 
enabled)
 Active: active (running) since Wed 2022-10-26 05:24:41 UTC; 55s ago
Process: 235 ExecStart=/usr/sbin/nscd (code=exited, status=0/SUCCESS)
   Main PID: 240 (nscd)
  Tasks: 10 (limit: 4812)
 Memory: 716.0K
 CGroup: /system.slice/nscd.service
 `- 240 /usr/sbin/nscd

Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring directory `/etc` (2)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring file `/etc/passwd` (1)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring directory `/etc` (2)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring file `/etc/nsswitch.conf` (6)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring directory `/etc` (2)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring file `/etc/group` (3)
Oct 26 05:24:45 qemux86 nscd[240]: 240 monitoring directory `/etc` (2)
Oct 26 05:24:58 qemux86 nscd[240]: 240 monitored file `/etc/resolv.conf` 
changed (mtime)
Oct 26 05:24:58 qemux86 nscd[240]: 240 monitoring file `/etc/resolv.conf` (7)
Oct 26 05:24:58 qemux86 nscd[240]: 240 monitoring directory `/etc` (2)

[1] 
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa4a19277842fd09a4815a986f70e0fe0903836f;hp=545eefc2f5da61801ba82b7a32ca2589b769ec90

Signed-off-by: Mingli Yu 
---
 ...time_t-on-libc-nscd-routines-BZ-2940.patch | 46 +++
 meta/recipes-core/glibc/glibc_2.35.bb |  1 +
 2 files changed, 47 insertions(+)
 create mode 100644 
meta/recipes-core/glibc/glibc/0001-nscd-Use-64-bit-time_t-on-libc-nscd-routines-BZ-2940.patch

diff --git 
a/meta/recipes-core/glibc/glibc/0001-nscd-Use-64-bit-time_t-on-libc-nscd-routines-BZ-2940.patch
 
b/meta/recipes-core/glibc/glibc/0001-nscd-Use-64-bit-time_t-on-libc-nscd-routines-BZ-2940.patch
new file mode 100644
index 00..8d324a3074
--- /dev/null
+++ 
b/meta/recipes-core/glibc/glibc/0001-nscd-Use-64-bit-time_t-on-libc-nscd-routines-BZ-2940.patch
@@ -0,0 +1,46 @@
+From 3d89d36bb2c7f91fee0d81226234205126971eb7 Mon Sep 17 00:00:00 2001
+From: Adhemerval Zanella Netto 
+Date: Wed, 26 Oct 2022 12:29:18 +0800
+Subject: [PATCH] nscd: Use 64 bit time_t on libc nscd routines (BZ# 29402)
+
+Although the nscd module is built with 64 bit time_t, the routines
+linked direct to libc.so need to use the internal symbols.
+Reviewed-by: DJ Delorie 
+
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=fa4a19277842fd09a4815a986f70e0fe0903836f;hp=545eefc2f5da61801ba82b7a32ca2589b769ec90]
+
+Signed-off-by: Mingli Yu 
+---
+ nscd/nscd.h  | 2 +-
+ nscd/nscd_gethst_r.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/nscd/nscd.h b/nscd/nscd.h
+index 368091aef8..f15321585b 100644
+--- a/nscd/nscd.h
 b/nscd/nscd.h
+@@ -65,7 +65,7 @@ typedef enum
+ struct 

Re: [OE-core][PATCH 1/2] gobject-introspection: check for GI_DATA_ENABLED

[Randy MacLeod]

On 2023-01-17 07:58, Petr Kubizňák via lists.openembedded.org wrote:

This issue was actually caused by missing host dependencies. Shame on me...


Do you mean standard host dependencies from our documented list:

https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html#build-host-packages
?
--
# Randy MacLeod
# Wind River Linux


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

Re: [OE-core] [PATCH] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Peter Kjellerstedt]

> -Original Message-
> From: Luca Ceresoli 
> Sent: den 18 januari 2023 17:22
> To: Peter Kjellerstedt 
> Cc: openembedded-core@lists.openembedded.org; Richard Purdie
> 
> Subject: Re: [OE-core] [PATCH] librsvg: Only enable the Vala bindings if
> GObject Introspection is enabled
> 
> Hello Peter,
> 
> On Wed, 18 Jan 2023 12:27:59 +0100
> "Peter Kjellerstedt"  wrote:
> 
> > This avoids the following error:
> >
> >   configure: error: Vala bindings require GObject Introspection
> >
> > Signed-off-by: Peter Kjellerstedt 
> 
> A different patch [0] to address the same bug is already in my testing
> branch and is possibly being merged soon on master by Richard. Can you
> please check whether your think your patch is better and let us know?

I had not seen that patch when I sent mine. I think mine is a little better 
since it defines and uses a PACKAGECONFIG for the vala support, which should 
make it easier for anyone wanting to, e.g., disable the vala support even if 
it is enabled by default.

> 
> [0] 
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next-success=e9e761146b52658c06aae150332db666ce2f25a8
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176114): 
https://lists.openembedded.org/g/openembedded-core/message/176114
Mute This Topic: https://lists.openembedded.org/mt/96351645/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] pseudo.c: Avoid patch mismatch errors for NAMELESS file entries

[Alexandre Belloni via lists.openembedded.org]

On 18/01/2023 14:00:47+, Richard Purdie wrote:
> In rare cases we see failures, often in linux-libc-headers for things like:
> 
> |   INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include
> | abort()ing pseudo client by server request. See 
> https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.
> 
> Pseudo log:
> path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req 
> '/XXX/linux-libc-headers/6.1-r0/image/usr'.
> Setup complete, sending SIGUSR1 to pid 3630890.
> 
> Whilst this doesn't easily reproduce, the issue is that multiple different 
> processes are
> likely working on the directory and the creation in pseudo might not match 
> accesses
> made by other processes.
> 
> Ultimately, the "NAMELESS FILE" is harmless and pseudo will reconcile things
> so rather than error out, we should ignore this case.
> 

[ YOCTO #14932 ]

> Signed-off-by: Richard Purdie 
> ---
>  pseudo.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/pseudo.c b/pseudo.c
> index 528fe1b..4f36786 100644
> --- a/pseudo.c
> +++ b/pseudo.c
> @@ -682,7 +682,8 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const 
> char *tag, char **respon
>   }
>   break;
>   default:
> - if (strcmp(msg->path, path_by_ino)) {
> + /* Ignore NAMELESS FILE entries since those 
> could be created by other threads on new files */
> + if (strcmp(msg->path, path_by_ino) && 
> !strcmp(path_by_ino, "NAMELESS FILE")) {
>   mismatch = 1;
>   }
>   break;
> -- 
> 2.37.2
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

[Khem Raj]

Signed-off-by: Khem Raj 
---
v2: Update patch status

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

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

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


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

Re: [OE-core] [PATCH] rust: Upgrade 1.66.0 -> 1.66.1

[Kokkonda, Sundeep]

@Randy,

To summarize the discussion, I should try -
1. Upgrade Kirkstone/Lagdale rust to 1.66.1 and
2. backporting the fixes of Cargo/Rust for kirkstone (patches given in 
https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2022-46176
 )

Is this correct?

--
Sundeep K.

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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Alex Kiernan]

On Wed, Jan 18, 2023 at 5:05 PM Kokkonda, Sundeep
 wrote:
>
> Without 'binutils' the required linker 'x86_64-poky-linux-ld' will not be 
> added to the image (getting error - cannot find 'ld').
> And, 'g++' also a required package along with 'gcc'. When removed 'g++' some 
> required libs are missing. See below error.
>
> root@qemux86-64:~/hello# cargo run
>Compiling hello v0.1.0 (/home/root/hello)
> error: linking with `x86_64-poky-linux-gcc` failed: exit status: 1
>   |
>   = note: "x86_64-poky-linux-gcc" "/tmp/rustcZTUudY/symbols.o" 
> "/home/root/hello/target/debug/deps/hello-366ba9a14b055dd9.1rbu6cyq0fbr2z03.rcgu.o"
>  "/home/root/hello/target/debug/deps/hello-366ba9a1"
>   = note: 
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find Scrt1.o: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find crti.o: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find crtbeginS.o: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lgcc_s: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lutil: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lrt: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lpthread: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lm: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -ldl: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find -lc: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find crtendS.o: No such file or directory
>   
> /usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
> cannot find crtn.o: No such file or directory
>   collect2: error: ld returned 1 exit status
>

Those look like glibc-dev to me - something like add a dependency on
${LIBC_DEPENDENCIES}?

-- 
Alex Kiernan

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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Kokkonda, Sundeep]

Without 'binutils' the required linker 'x86_64-poky-linux-ld' will not be added 
to the image (getting error - cannot find 'ld').
And, 'g++' also a required package along with 'gcc'. When removed 'g++' some 
required libs are missing. See below error.

root@qemux86-64:~/hello# cargo run
Compiling hello v0.1.0 (/home/root/hello)
error: linking with `x86_64-poky-linux-gcc` failed: exit status: 1
|
= note: "x86_64-poky-linux-gcc" "/tmp/rustcZTUudY/symbols.o" 
"/home/root/hello/target/debug/deps/hello-366ba9a14b055dd9.1rbu6cyq0fbr2z03.rcgu.o"
 "/home/root/hello/target/debug/deps/hello-366ba9a1"
= note: 
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find Scrt1.o: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find crti.o: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find crtbeginS.o: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lgcc_s: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lutil: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lrt: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lpthread: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lm: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -ldl: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find -lc: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find crtendS.o: No such file or directory
/usr/lib/gcc/x86_64-poky-linux/12.2.0/../../../../x86_64-poky-linux/bin/ld: 
cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status

error: could not compile `hello` due to previous error

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

Re: [OE-core] [PATCH 3/3] pseudo: Switch back to the master branch

[Richard Purdie]

On Wed, 2023-01-18 at 17:46 +0100, Luca Ceresoli wrote:
> Hello Richard,
> 
> On Wed, 18 Jan 2023 14:22:21 +
> "Richard Purdie"  wrote:
> 
> > OE is the main user of pseudo and we've had the changes in the oe-core 
> > branch
> > around long enough that we're going to run with them. Swicth back to 
> > directly
> > using the master branch.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
> > b/meta/recipes-devtools/pseudo/pseudo_git.bb
> > index c9386c3f090..553f0254ee4 100644
> > --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> > +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> > @@ -1,6 +1,6 @@
> >  require pseudo.inc
> >  
> > -SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
> > +SRC_URI = "git://git.yoctoproject.org/pseudo \
> 
> Triggers "URL: ... does not set any branch parameter. The future is
> uncertain and the end is always near" ;)
> 
> I'm fixing it on my testing branch for the moment.

Thanks, that will teach me to quickly add another patch when cleaning
things up to send!

Cheers,

Richard

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

Re: [OE-core] [PATCH 3/3] pseudo: Switch back to the master branch

[Luca Ceresoli via lists.openembedded.org]

Hello Richard,

On Wed, 18 Jan 2023 14:22:21 +
"Richard Purdie"  wrote:

> OE is the main user of pseudo and we've had the changes in the oe-core branch
> around long enough that we're going to run with them. Swicth back to directly
> using the master branch.
> 
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-devtools/pseudo/pseudo_git.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
> b/meta/recipes-devtools/pseudo/pseudo_git.bb
> index c9386c3f090..553f0254ee4 100644
> --- a/meta/recipes-devtools/pseudo/pseudo_git.bb
> +++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
> @@ -1,6 +1,6 @@
>  require pseudo.inc
>  
> -SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
> +SRC_URI = "git://git.yoctoproject.org/pseudo \

Triggers "URL: ... does not set any branch parameter. The future is
uncertain and the end is always near" ;)

I'm fixing it on my testing branch for the moment.

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176107): 
https://lists.openembedded.org/g/openembedded-core/message/176107
Mute This Topic: https://lists.openembedded.org/mt/96354586/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] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Luca Ceresoli via lists.openembedded.org]

Hello Peter,

On Wed, 18 Jan 2023 12:27:59 +0100
"Peter Kjellerstedt"  wrote:

> This avoids the following error:
> 
>   configure: error: Vala bindings require GObject Introspection
> 
> Signed-off-by: Peter Kjellerstedt 

A different patch [0] to address the same bug is already in my testing
branch and is possibly being merged soon on master by Richard. Can you
please check whether your think your patch is better and let us know?

[0]
https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next-success=e9e761146b52658c06aae150332db666ce2f25a8

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

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

Re: [OE-core] [PATCH v2 5/5] defaultsetup: Enable largefile and 64bit time_t support systemwide

[Richard Purdie]

On Tue, 2023-01-03 at 12:05 -0800, Khem Raj wrote:
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/distro/defaultsetup.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/conf/distro/defaultsetup.conf 
> b/meta/conf/distro/defaultsetup.conf
> index f6894f3ab5..1abb509629 100644
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -2,7 +2,7 @@ include conf/distro/include/default-providers.inc
>  include conf/distro/include/default-versions.inc
>  include conf/distro/include/default-distrovars.inc
>  include conf/distro/include/maintainers.inc
> -
> +include conf/distro/include/time64.inc
>  require conf/distro/include/tcmode-${TCMODE}.inc
>  require conf/distro/include/tclibc-${TCLIBC}.inc
>  


I tried this as requested. I saw:

x86 binutils do_compile failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/6562/steps/11/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/103/builds/5424/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/6572/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/6493/steps/11/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/61/builds/6528/steps/11/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/5304/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio

lib32-binutils do_compile failure:
https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/6437/steps/11/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/108/builds/4042/steps/12/logs/stdio

mingw binutils do_compile:
https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/6562/steps/13/logs/stdio

meta-virt xen-tools do_compile:
https://autobuilder.yoctoproject.org/typhoon/#/builders/128/builds/1166/steps/20/logs/stdio

qemuarm glibc-testsuite issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/53/builds/6539/steps/19/logs/stdio

qemumips glibc-testsuite issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/6500/steps/20/logs/stdio

qemux86 glibc-testsuite issue:
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6481/steps/20/logs/stdio

Close, but not quite there!


Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176105): 
https://lists.openembedded.org/g/openembedded-core/message/176105
Mute This Topic: https://lists.openembedded.org/mt/96036256/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] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Jose Quaresma]

Peter Kjellerstedt  escreveu no dia quarta,
18/01/2023 à(s) 14:44:

> gobject-instrospection is not enabled by default in DISTRO_FEATURES_NATIVE
> and DISTRO_FEATURES_NATIVESDK so unless you explicitly enable it yourself
> (which seems unlikely to me), it will not be enabled in the
> native/nativesdk cases.
>

Right, makes sense.
Thanks for explaining.

Jose


>
>
> //Peter
>
>
>
> *From:* Jose Quaresma 
> *Sent:* den 18 januari 2023 13:13
> *To:* Peter Kjellerstedt 
> *Cc:* openembedded-core@lists.openembedded.org
> *Subject:* Re: [OE-core] [PATCH] librsvg: Only enable the Vala bindings
> if GObject Introspection is enabled
>
>
>
> Hi Peter,
>
>
>
> Peter Kjellerstedt  escreveu no dia quarta,
> 18/01/2023 à(s) 11:28:
>
> This avoids the following error:
>
>   configure: error: Vala bindings require GObject Introspection
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> index b2e93a2684..c55aa250e9 100644
> --- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> +++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> @@ -42,8 +42,6 @@ do_configure[postfuncs] += "cargo_common_do_configure"
>
>  inherit rust-target-config
>
> -EXTRA_OECONF:class-target = "--enable-vala"
> -
>  # rust-cross writes the target linker binary into target json definition
> without any flags.
>  # This breaks here because the linker isn't going to work without at
> least knowing where
>  # the sysroot is. So copy the json to workdir, and patch in the path to
> wrapper from rust class
> @@ -57,9 +55,10 @@ CVE_CHECK_IGNORE += "CVE-2018-141"
>
>  CACHED_CONFIGUREVARS =
> "ac_cv_path_GDK_PIXBUF_QUERYLOADERS=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders"
>
> -PACKAGECONFIG ??= "gdkpixbuf"
> +PACKAGECONFIG ??= "gdkpixbuf ${@bb.utils.contains('GI_DATA_ENABLED',
> 'True', 'vala', '', d)}"
>  # The gdk-pixbuf loader
>  PACKAGECONFIG[gdkpixbuf] =
> "--enable-pixbuf-loader,--disable-pixbuf-loader,gdk-pixbuf-native"
> +PACKAGECONFIG[vala] = "--enable-vala,--disable-vala"
>
>
>
> This will be enabled in the native builds too and before it is only
> defined for target.
>
>
>
> Jose
>
>
>
>
>  do_install:append() {
> # Loadable modules don't need .a or .la on Linux
>
> 
>
>
>
>
> --
>
> Best regards,
>
>
> José Quaresma
>


-- 
Best regards,

José Quaresma

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

Re: [OE-Core][langdale][PATCH v2 1/2] kernel-fitimage: Adjust order of dtb/dtbo files

[Steve Sakoman]

On Tue, Jan 17, 2023 at 6:35 AM Sandeep Gundlupet Raju via
lists.openembedded.org
 wrote:
>
> Hi All,
>
> Can someone merge these patches to langdale branch?

I already have them in my current test queue, which you can monitor at:

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

Steve

> On 1/13/2023 9:51 AM, Gundlupet Raju, Sandeep wrote:
> > Hi Richard, Alex,
> >
> > Thanks for merging the patches in master. Can you merge these patches
> > to langdale release as well?
> >
> > Thanks,
> >
> > Sandeep
> >
> > On 1/12/2023 7:19 PM, Gundlupet Raju, Sandeep wrote:
> >> Hi Michael,
> >>
> >> Any updates on patch merge?
> >>
> >> Thanks,
> >>
> >> Sandeep
> >>
> >> On 1/8/2023 10:25 AM, sandeep.gundlupet-r...@amd.com wrote:
> >>> From: Sandeep Gundlupet Raju 
> >>>
> >>> The dtb files must be before the dtbo files, otherwise the overlays may
> >>> not be applied correctly.
> >>>
> >>>  From Bruce Ashfield:
> >>>
> >>>We can split between dtbs and dtbos, they just need to be sorted
> >>>for reproducibility reasons.
> >>>
> >>>Of course, this was only working by luck previously (before the
> >>>sort), since it has always been gathering dtbs and dtbo's with
> >>>find, depending on filesystem ordering for the order in the
> >>>fitimage).
> >>>
> >>> Signed-off-by: Sandeep Gundlupet Raju 
> >>> ---
> >>>
> >>> Changes in v2:
> >>>   - Remove 2 loops and use single loop for dtb and dtbo with same
> >>> logic.
> >>>
> >>> ---
> >>>   meta/classes-recipe/kernel-fitimage.bbclass | 5 +++--
> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/classes-recipe/kernel-fitimage.bbclass
> >>> b/meta/classes-recipe/kernel-fitimage.bbclass
> >>> index 8ddebf8dd8..06cdc4f1ec 100644
> >>> --- a/meta/classes-recipe/kernel-fitimage.bbclass
> >>> +++ b/meta/classes-recipe/kernel-fitimage.bbclass
> >>> @@ -546,10 +546,11 @@ fitimage_assemble() {
> >>> if [ -n "${EXTERNAL_KERNEL_DEVICETREE}" ]; then
> >>>   dtbcount=1
> >>> -for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" \( -name
> >>> '*.dtb' -o -name '*.dtbo' \) -printf '%P\n' | sort); do
> >>> +for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name
> >>> '*.dtb' -printf '%P\n' | sort) \
> >>> +$(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtbo'
> >>> -printf '%P\n' | sort); do
> >>>   DTB=$(echo "$DTB" | tr '/' '_')
> >>>   -# Skip DTB if we've picked it up previously
> >>> +# Skip DTB/DTBO if we've picked it up previously
> >>>   echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
> >>> DTBS="$DTBS $DTB"
>
> 
>

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

Re: [OE-core] [PATCH] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Peter Kjellerstedt]

gobject-instrospection is not enabled by default in DISTRO_FEATURES_NATIVE and 
DISTRO_FEATURES_NATIVESDK so unless you explicitly enable it yourself (which 
seems unlikely to me), it will not be enabled in the native/nativesdk cases.

//Peter

From: Jose Quaresma 
Sent: den 18 januari 2023 13:13
To: Peter Kjellerstedt 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] librsvg: Only enable the Vala bindings if 
GObject Introspection is enabled

Hi Peter,

Peter Kjellerstedt 
mailto:peter.kjellerst...@axis.com>> escreveu no 
dia quarta, 18/01/2023 à(s) 11:28:
This avoids the following error:

  configure: error: Vala bindings require GObject Introspection

Signed-off-by: Peter Kjellerstedt 
mailto:peter.kjellerst...@axis.com>>
---
 meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 5 
++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git 
a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
index b2e93a2684..c55aa250e9 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
@@ -42,8 +42,6 @@ do_configure[postfuncs] += "cargo_common_do_configure"

 inherit rust-target-config

-EXTRA_OECONF:class-target = "--enable-vala"
-
 # rust-cross writes the target linker binary into target json definition 
without any flags.
 # This breaks here because the linker isn't going to work without at least 
knowing where
 # the sysroot is. So copy the json to workdir, and patch in the path to 
wrapper from rust class
@@ -57,9 +55,10 @@ CVE_CHECK_IGNORE += "CVE-2018-141"

 CACHED_CONFIGUREVARS = 
"ac_cv_path_GDK_PIXBUF_QUERYLOADERS=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders"

-PACKAGECONFIG ??= "gdkpixbuf"
+PACKAGECONFIG ??= "gdkpixbuf 
${@bb.utils.contains('GI_DATA_ENABLED',
 'True', 'vala', '', d)}"
 # The gdk-pixbuf loader
 PACKAGECONFIG[gdkpixbuf] = 
"--enable-pixbuf-loader,--disable-pixbuf-loader,gdk-pixbuf-native"
+PACKAGECONFIG[vala] = "--enable-vala,--disable-vala"

This will be enabled in the native builds too and before it is only defined for 
target.

Jose


 do_install:append() {
# Loadable modules don't need .a or .la on Linux




--
Best regards,

José Quaresma

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

[OE-core] [PATCH 1/3] insane: Improve patch warning/error handling

[Richard Purdie]

Currently, whilst patch errors or warnings are shown, the errors don't stop 
builds.
The configuration isn't very configurable from WARN_QA and ERROR_QA either.

This patch:
 * Uses the standard mechanisms to handle the patch fuzz warnings/errors
 * Makes Upstream-Status checking configurable from WARN/ERROR_QA
 * Allows that checking to be used with non-core layers
 * Makes patch-fuzz an error by default
 * Enables warnings for missing Upstream-Status in non-core layer patches by 
default

Signed-off-by: Richard Purdie 
---
 meta/classes-global/insane.bbclass | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/meta/classes-global/insane.bbclass 
b/meta/classes-global/insane.bbclass
index ada8a7ef4e4..e1295f85392 100644
--- a/meta/classes-global/insane.bbclass
+++ b/meta/classes-global/insane.bbclass
@@ -29,11 +29,12 @@
 WARN_QA ?= " libdir xorg-driver-abi buildpaths \
 textrel incompatible-license files-invalid \
 infodir build-deps src-uri-bad symlink-to-sysroot multilib \
-invalid-packageconfig host-user-contaminated uppercase-pn 
patch-fuzz \
+invalid-packageconfig host-user-contaminated uppercase-pn \
 mime mime-xdg unlisted-pkg-lics unhandled-features-check \
 missing-update-alternatives native-last missing-ptest \
 license-exists license-no-generic license-syntax license-format \
 license-incompatible license-file-missing obsolete-license \
+patch-status-noncore \
 "
 ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch pkgconfig la \
 perms dep-cmp pkgvarcheck perm-config perm-line perm-link \
@@ -44,6 +45,7 @@ ERROR_QA ?= "dev-so debug-deps dev-deps debug-files arch 
pkgconfig la \
 already-stripped installed-vs-shipped ldflags compile-host-path \
 install-host-path pn-overrides unknown-configure-option \
 useless-rpaths rpaths staticdev empty-dirs \
+patch-fuzz patch-status-core\
 "
 # Add usrmerge QA check based on distro feature
 ERROR_QA:append = "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', ' 
usrmerge', '', d)}"
@@ -1334,24 +1336,27 @@ python do_qa_patch() {
 msg += "devtool modify %s\n" % d.getVar('PN')
 msg += "devtool finish --force-patch-refresh %s 
\n\n" % d.getVar('PN')
 msg += "Don't forget to review changes done by devtool!\n"
-if bb.utils.filter('ERROR_QA', 'patch-fuzz', d):
-bb.error(msg)
-elif bb.utils.filter('WARN_QA', 'patch-fuzz', d):
-bb.warn(msg)
-msg = "Patch log indicates that patches do not apply cleanly."
+msg += "\nPatch log indicates that patches do not apply cleanly."
 oe.qa.handle_error("patch-fuzz", msg, d)
 
 # Check if the patch contains a correctly formatted and spelled 
Upstream-Status
 import re
 from oe import patch
 
+allpatches = False
+if bb.utils.filter('ERROR_QA', 'patch-status-noncore', d) or 
bb.utils.filter('WARN_QA', 'patch-status-noncore', d):
+allpatches = True
+
 coremeta_path = os.path.join(d.getVar('COREBASE'), 'meta', '')
 for url in patch.src_patches(d):
(_, _, fullpath, _, _, _) = bb.fetch.decodeurl(url)
 
# skip patches not in oe-core
+   patchtype = "patch-status-core"
if not os.path.abspath(fullpath).startswith(coremeta_path):
-   continue
+   patchtype = "patch-status-noncore"
+   if not allpatches:
+   continue
 
kinda_status_re = re.compile(r"^.*upstream.*status.*$", re.IGNORECASE | 
re.MULTILINE)
strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport|Inactive-Upstream)( 
.+)?$", re.MULTILINE)
@@ -1364,9 +1369,13 @@ python do_qa_patch() {
 
if not match_strict:
if match_kinda:
-   bb.error("Malformed Upstream-Status in patch\n%s\nPlease 
correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
+   msg = "Malformed Upstream-Status in patch\n%s\nPlease 
correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0))
+   oe.qa.handle_error(patchtype, msg, d)
else:
-   bb.error("Missing Upstream-Status in patch\n%s\nPlease add 
according to %s ." % (fullpath, guidelines))
+   msg = "Missing Upstream-Status in patch\n%s\nPlease add 
according to %s ." % (fullpath, guidelines)
+   oe.qa.handle_error(patchtype, msg, d)
+
+oe.qa.exit_if_errors(d)
 }
 
 python do_qa_configure() {
-- 
2.37.2


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

[OE-core] [PATCH 2/3] pseudo: Update to pull in linux-libc-headers race fix

[Richard Purdie]

Update to pull in:

pseudo.c: Avoid patch mismatch errors for NAMELESS file entries

In rare cases we see failures, often in linux-libc-headers for things like:

|   INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include
| abort()ing pseudo client by server request. See 
https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.

Pseudo log:
path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req 
'/XXX/linux-libc-headers/6.1-r0/image/usr'.
Setup complete, sending SIGUSR1 to pid 3630890.

Whilst this doesn't easily reproduce, the issue is that multiple different 
processes are
likely working on the directory and the creation in pseudo might not match 
accesses
made by other processes.

Ultimately, the "NAMELESS FILE" is harmless and pseudo will reconcile things
so rather than error out, we should ignore this case.

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

diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index 1a708066f73..c9386c3f090 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -13,7 +13,7 @@ SRC_URI:append:class-nativesdk = " \
 file://older-glibc-symbols.patch"
 SRC_URI[prebuilt.sha256sum] = 
"ed9f456856e9d86359f169f46a70ad7be4190d6040282b84c8d97b99072485aa"
 
-SRCREV = "c9670c27ff67ab899007ce749254b16091577e55"
+SRCREV = "cc1f6167cb5065daba1462056e2dce8ff72aa855"
 S = "${WORKDIR}/git"
 PV = "1.9.0+git${SRCPV}"
 
-- 
2.37.2


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

[OE-core] [PATCH 3/3] pseudo: Switch back to the master branch

[Richard Purdie]

OE is the main user of pseudo and we've had the changes in the oe-core branch
around long enough that we're going to run with them. Swicth back to directly
using the master branch.

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

diff --git a/meta/recipes-devtools/pseudo/pseudo_git.bb 
b/meta/recipes-devtools/pseudo/pseudo_git.bb
index c9386c3f090..553f0254ee4 100644
--- a/meta/recipes-devtools/pseudo/pseudo_git.bb
+++ b/meta/recipes-devtools/pseudo/pseudo_git.bb
@@ -1,6 +1,6 @@
 require pseudo.inc
 
-SRC_URI = "git://git.yoctoproject.org/pseudo;branch=oe-core \
+SRC_URI = "git://git.yoctoproject.org/pseudo \
file://0001-configure-Prune-PIE-flags.patch \
file://fallback-passwd \
file://fallback-group \
-- 
2.37.2


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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Alex Kiernan]

On Wed, Jan 18, 2023 at 12:09 PM Kokkonda, Sundeep
 wrote:
>
> Removed not required pkgs autoconf, make, pkgconfig... etc and not removed 
> 'g++'. Have to check specifically for this package. Let me check for it and 
> i'll update here.

Thanks!

I'd probably start from the other end - my guess would be you only
need gcc (and whatever transitive dependencies it brings).

-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176097): 
https://lists.openembedded.org/g/openembedded-core/message/176097
Mute This Topic: https://lists.openembedded.org/mt/96110740/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] pseudo.c: Avoid patch mismatch errors for NAMELESS file entries

[Richard Purdie]

In rare cases we see failures, often in linux-libc-headers for things like:

|   INSTALL /XXX/linux-libc-headers/6.1-r0/image/usr/include
| abort()ing pseudo client by server request. See 
https://wiki.yoctoproject.org/wiki/Pseudo_Abort for more details on this.

Pseudo log:
path mismatch [2 links]: ino 46662476 db 'NAMELESS FILE' req 
'/XXX/linux-libc-headers/6.1-r0/image/usr'.
Setup complete, sending SIGUSR1 to pid 3630890.

Whilst this doesn't easily reproduce, the issue is that multiple different 
processes are
likely working on the directory and the creation in pseudo might not match 
accesses
made by other processes.

Ultimately, the "NAMELESS FILE" is harmless and pseudo will reconcile things
so rather than error out, we should ignore this case.

Signed-off-by: Richard Purdie 
---
 pseudo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pseudo.c b/pseudo.c
index 528fe1b..4f36786 100644
--- a/pseudo.c
+++ b/pseudo.c
@@ -682,7 +682,8 @@ pseudo_op(pseudo_msg_t *msg, const char *program, const 
char *tag, char **respon
}
break;
default:
-   if (strcmp(msg->path, path_by_ino)) {
+   /* Ignore NAMELESS FILE entries since those 
could be created by other threads on new files */
+   if (strcmp(msg->path, path_by_ino) && 
!strcmp(path_by_ino, "NAMELESS FILE")) {
mismatch = 1;
}
break;
-- 
2.37.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176096): 
https://lists.openembedded.org/g/openembedded-core/message/176096
Mute This Topic: https://lists.openembedded.org/mt/96354064/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] rm_work: adjust dependency to make do_rm_work_all depend on do_rm_work

[Richard Purdie]

On Wed, 2023-01-18 at 13:10 +, Jose Quaresma wrote:
> Hi Chen,
> 
> Jose Quaresma via lists.openembedded.org
>  escreveu no dia
> sexta, 13/01/2023 à(s) 15:39:
> > Hi Chen,
> > 
> > Just for your information,
> > This patch introduces a regression that breaks the do_create_spdx
> > tasks when building with multiconfig machines.
> > 
> > I am investigating it more deeply and will come back with my
> > findings.
> > 
> 
> 
> I don't understand the reason for this regression but I am thinking
> of sending a revert for this patch.
> 
> Here are the steps to reproduce:
> 
> git clone https://git.yoctoproject.org/git/poky
> cd poky
> git clone https://git.yoctoproject.org/git/meta-arm 
> git clone https://git.yoctoproject.org/git/meta-ti 
> source oe-init-build-env
> bitbake-layers add-layer ../meta-arm/meta-arm-toolchain
> bitbake-layers add-layer ../meta-arm/meta-arm
> bitbake-layers add-layer ../meta-ti/meta-ti-bsp
> bitbake-layers add-layer ../meta-ti/meta-ti-extras
> echo 'INHERIT += "rm_work"' >>conf/local.conf
> echo 'INHERIT += "create-spdx"' >>conf/local.conf
> 
> MACHINE=am64xx-evm bitbake core-image-minimal
> MACHINE=am62xx-evm bitbake core-image-minimal
> 
> At least these two machines are broken.
> 

Do you have a pointer to the actual errors that result?

I'm not sure I would take a revert as I did carefully check this patch
and I think it does fix a number of problems.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176095): 
https://lists.openembedded.org/g/openembedded-core/message/176095
Mute This Topic: https://lists.openembedded.org/mt/95462765/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] mesa: update submitted patch with backported version

[Martin Jansa]

On Wed, Jan 18, 2023 at 1:55 PM Luca Ceresoli 
wrote:

> Hello Martin,
>
> On Mon, 16 Jan 2023 16:30:35 +0100
> "Martin Jansa"  wrote:
>
> > * this version was merged to main in:
> >
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911
> >   and cherry-picked to staging/23.0 as well in:
> >
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/54cfb552abc50e8167cdc46d87455a9a414d7c65
> >
> >   and as a bonus it doesn't break the build with DEBUG_BUILD
> >   for newer toolchain, so we can apply it for target build as well, see:
> >   https://lists.openembedded.org/g/openembedded-core/message/169002
> >   https://lists.openembedded.org/g/openembedded-core/message/170930
> >
> > Signed-off-by: Martin Jansa 
>
> There was a conflict while applying this patch on my testing branch due
> to a previous patch touching mesa.inc. It was simple enough so I have
> fixed it, but you might want to double check the resulting commit:
>
>
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next-success=259d433461e246fa85ff0c0ffa98b91209e15d31


git log --oneline contrib/lucaceresoli/master-next --
meta/recipes-graphics/mesa/ | head -n 3
8b328a698cc mesa: update submitted patch with backported version
ab86331bf4a mesa: allow mesa (gbm) to compile without backend
256173b0245 mesa: update 22.2.3 -> 22.3.3

^^^ LGTM

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176094): 
https://lists.openembedded.org/g/openembedded-core/message/176094
Mute This Topic: https://lists.openembedded.org/mt/96308437/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] rm_work: adjust dependency to make do_rm_work_all depend on do_rm_work

[Chen Qi]

You may need to check with the layer maintainers to find out why these two 
layers are not working.
It does not feel right if you revert a patch but cannot prove it’s wrong.

Regards,
Qi

From: Jose Quaresma 
Sent: Wednesday, January 18, 2023 9:10 PM
To: quaresma.j...@gmail.com
Cc: Chen, Qi ; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] rm_work: adjust dependency to make do_rm_work_all 
depend on do_rm_work

Hi Chen,

Jose Quaresma via 
lists.openembedded.org
 
mailto:gmail@lists.openembedded.org>>
 escreveu no dia sexta, 13/01/2023 à(s) 15:39:
Hi Chen,

Just for your information,
This patch introduces a regression that breaks the do_create_spdx tasks when 
building with multiconfig machines.

I am investigating it more deeply and will come back with my findings.

I don't understand the reason for this regression but I am thinking of sending 
a revert for this patch.

Here are the steps to reproduce:

git clone 
https://git.yoctoproject.org/git/poky
cd poky
git clone 
https://git.yoctoproject.org/git/meta-arm
git clone 
https://git.yoctoproject.org/git/meta-ti
source oe-init-build-env
bitbake-layers add-layer ../meta-arm/meta-arm-toolchain
bitbake-layers add-layer ../meta-arm/meta-arm
bitbake-layers add-layer ../meta-ti/meta-ti-bsp
bitbake-layers add-layer ../meta-ti/meta-ti-extras
echo 'INHERIT += "rm_work"' >>conf/local.conf
echo 'INHERIT += "create-spdx"' >>conf/local.conf

MACHINE=am64xx-evm bitbake core-image-minimal
MACHINE=am62xx-evm bitbake core-image-minimal

At least these two machines are broken.

Jose


Jose

Chen Qi mailto:qi.c...@windriver.com>> escreveu no dia 
segunda, 5/12/2022 à(s) 04:59:
For now, if we use rm_work and `bitbake core-image-minimal', some
recipes' WORKDIRs are not cleaned up, e.g., makedevs-native.

Adjust the dependency to make do_rm_work_all depend on do_rm_work
to solve this problem.

Below are the detailed explanation of why this would work.

Without this patch, the dependency chain is like:
[other deps] -> [do_rm_work] -+-> [do_build]
  |
[do_rm_work_all] -+

With this patch, the depedency chain is like:
[other deps] -> [do_rm_work] -> [do_rm_work_all] -> [do_build]

Such dependency chain adjustment fixes the issue because do_rm_work_all
now depends on [other deps] and thus the [depends] of these [other deps].
Take core-image-minimal as an example. Before this adjustment,
do_rm_work_all does not have any relationship with do_rootfs, and we have
do_rootfs[depends] += "makedevs-native:do_populate_sysroot ..."
This essentially prevents 'recrdeptask' setting of do_rm_work_all extend
to makedevs-native. With this patch, the do_rm_work_all now depends
on do_rm_work which in turn depends on do_rootfs, and so do_rm_work_all's
recrdeptask could have effect on makedevs-native.

With this patch, all built recipes WORKDIR will be cleaned up with
a few expected exceptions such as kernel and qemu-helper-native.

Signed-off-by: Chen Qi mailto:qi.c...@windriver.com>>
---
 meta/classes/rm_work.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
index 4121a13279..1f28bc7187 100644
--- a/meta/classes/rm_work.bbclass
+++ b/meta/classes/rm_work.bbclass
@@ -180,7 +180,7 @@ python inject_rm_work() {
 # other recipes and thus will typically run much later than completion 
of
 # work in the recipe itself.
 # In practice, addtask() here merely updates the dependencies.
-bb.build.addtask('do_rm_work', 'do_build', ' '.join(deps), d)
+bb.build.addtask('do_rm_work', 'do_rm_work_all do_build', ' 
'.join(deps), d)

 # Always update do_build_without_rm_work dependencies.
 bb.build.addtask('do_build_without_rm_work', '', ' '.join(deps), d)
--
2.37.1





--
Best regards,

José Quaresma




--
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176093): 
https://lists.openembedded.org/g/openembedded-core/message/176093
Mute This Topic: https://lists.openembedded.org/mt/95462765/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] rm_work: adjust dependency to make do_rm_work_all depend on do_rm_work

[Jose Quaresma]

Hi Chen,

Jose Quaresma via lists.openembedded.org  escreveu no dia sexta, 13/01/2023 à(s)
15:39:

> Hi Chen,
>
> Just for your information,
> This patch introduces a regression that breaks the do_create_spdx tasks
> when building with multiconfig machines.
>
> I am investigating it more deeply and will come back with my findings.
>

I don't understand the reason for this regression but I am thinking of
sending a revert for this patch.

Here are the steps to reproduce:

git clone https://git.yoctoproject.org/git/poky
cd poky
git clone https://git.yoctoproject.org/git/meta-arm
git clone https://git.yoctoproject.org/git/meta-ti
source oe-init-build-env
bitbake-layers add-layer ../meta-arm/meta-arm-toolchain
bitbake-layers add-layer ../meta-arm/meta-arm
bitbake-layers add-layer ../meta-ti/meta-ti-bsp
bitbake-layers add-layer ../meta-ti/meta-ti-extras
echo 'INHERIT += "rm_work"' >>conf/local.conf
echo 'INHERIT += "create-spdx"' >>conf/local.conf

MACHINE=am64xx-evm bitbake core-image-minimal
MACHINE=am62xx-evm bitbake core-image-minimal

At least these two machines are broken.

Jose


>
> Jose
>
>
> Chen Qi  escreveu no dia segunda, 5/12/2022 à(s)
> 04:59:
>
>> For now, if we use rm_work and `bitbake core-image-minimal', some
>> recipes' WORKDIRs are not cleaned up, e.g., makedevs-native.
>>
>> Adjust the dependency to make do_rm_work_all depend on do_rm_work
>> to solve this problem.
>>
>> Below are the detailed explanation of why this would work.
>>
>> Without this patch, the dependency chain is like:
>> [other deps] -> [do_rm_work] -+-> [do_build]
>>   |
>> [do_rm_work_all] -+
>>
>> With this patch, the depedency chain is like:
>> [other deps] -> [do_rm_work] -> [do_rm_work_all] -> [do_build]
>>
>> Such dependency chain adjustment fixes the issue because do_rm_work_all
>> now depends on [other deps] and thus the [depends] of these [other deps].
>> Take core-image-minimal as an example. Before this adjustment,
>> do_rm_work_all does not have any relationship with do_rootfs, and we have
>> do_rootfs[depends] += "makedevs-native:do_populate_sysroot ..."
>> This essentially prevents 'recrdeptask' setting of do_rm_work_all extend
>> to makedevs-native. With this patch, the do_rm_work_all now depends
>> on do_rm_work which in turn depends on do_rootfs, and so do_rm_work_all's
>> recrdeptask could have effect on makedevs-native.
>>
>> With this patch, all built recipes WORKDIR will be cleaned up with
>> a few expected exceptions such as kernel and qemu-helper-native.
>>
>> Signed-off-by: Chen Qi 
>> ---
>>  meta/classes/rm_work.bbclass | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/rm_work.bbclass b/meta/classes/rm_work.bbclass
>> index 4121a13279..1f28bc7187 100644
>> --- a/meta/classes/rm_work.bbclass
>> +++ b/meta/classes/rm_work.bbclass
>> @@ -180,7 +180,7 @@ python inject_rm_work() {
>>  # other recipes and thus will typically run much later than
>> completion of
>>  # work in the recipe itself.
>>  # In practice, addtask() here merely updates the dependencies.
>> -bb.build.addtask('do_rm_work', 'do_build', ' '.join(deps), d)
>> +bb.build.addtask('do_rm_work', 'do_rm_work_all do_build', '
>> '.join(deps), d)
>>
>>  # Always update do_build_without_rm_work dependencies.
>>  bb.build.addtask('do_build_without_rm_work', '', ' '.join(deps), d)
>> --
>> 2.37.1
>>
>>
>>
>>
>>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176092): 
https://lists.openembedded.org/g/openembedded-core/message/176092
Mute This Topic: https://lists.openembedded.org/mt/95462765/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] mesa: update submitted patch with backported version

[Luca Ceresoli via lists.openembedded.org]

Hello Martin,

On Mon, 16 Jan 2023 16:30:35 +0100
"Martin Jansa"  wrote:

> * this version was merged to main in:
>   
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911
>   and cherry-picked to staging/23.0 as well in:
>   
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/54cfb552abc50e8167cdc46d87455a9a414d7c65
> 
>   and as a bonus it doesn't break the build with DEBUG_BUILD
>   for newer toolchain, so we can apply it for target build as well, see:
>   https://lists.openembedded.org/g/openembedded-core/message/169002
>   https://lists.openembedded.org/g/openembedded-core/message/170930
> 
> Signed-off-by: Martin Jansa 

There was a conflict while applying this patch on my testing branch due
to a previous patch touching mesa.inc. It was simple enough so I have
fixed it, but you might want to double check the resulting commit:

https://git.openembedded.org/openembedded-core-contrib/commit/?h=lucaceresoli/master-next-success=259d433461e246fa85ff0c0ffa98b91209e15d31

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176091): 
https://lists.openembedded.org/g/openembedded-core/message/176091
Mute This Topic: https://lists.openembedded.org/mt/96308437/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] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Jose Quaresma]

Hi Peter,

Peter Kjellerstedt  escreveu no dia quarta,
18/01/2023 à(s) 11:28:

> This avoids the following error:
>
>   configure: error: Vala bindings require GObject Introspection
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> index b2e93a2684..c55aa250e9 100644
> --- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> +++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
> @@ -42,8 +42,6 @@ do_configure[postfuncs] += "cargo_common_do_configure"
>
>  inherit rust-target-config
>
> -EXTRA_OECONF:class-target = "--enable-vala"
> -
>  # rust-cross writes the target linker binary into target json definition
> without any flags.
>  # This breaks here because the linker isn't going to work without at
> least knowing where
>  # the sysroot is. So copy the json to workdir, and patch in the path to
> wrapper from rust class
> @@ -57,9 +55,10 @@ CVE_CHECK_IGNORE += "CVE-2018-141"
>
>  CACHED_CONFIGUREVARS =
> "ac_cv_path_GDK_PIXBUF_QUERYLOADERS=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders"
>
> -PACKAGECONFIG ??= "gdkpixbuf"
> +PACKAGECONFIG ??= "gdkpixbuf ${@bb.utils.contains('GI_DATA_ENABLED',
> 'True', 'vala', '', d)}"
>  # The gdk-pixbuf loader
>  PACKAGECONFIG[gdkpixbuf] =
> "--enable-pixbuf-loader,--disable-pixbuf-loader,gdk-pixbuf-native"
> +PACKAGECONFIG[vala] = "--enable-vala,--disable-vala"
>

This will be enabled in the native builds too and before it is only defined
for target.

Jose


>
>  do_install:append() {
> # Loadable modules don't need .a or .la on Linux
>
> 
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Kokkonda, Sundeep]

Removed not required pkgs autoconf, make, pkgconfig... etc and not removed 
'g++'. Have to check specifically for this package. Let me check for it and 
i'll update here.

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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Alex Kiernan]

On Wed, Jan 18, 2023 at 11:43 AM Kokkonda, Sundeep
 wrote:
>
> Yes, linker is needed by 'rust' and we checked that linker issue is solved by 
> adding minimal required pkgs 'gcc g++ & binutils' instead of complete pkgs 
> provided by 'packagegroup-core-buildessential'.

Does it really need g++? If it does, it does, it just seems surprising to me.

> 
>


-- 
Alex Kiernan

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

Re: [OE-core] [PATCH v2] rust: Merge all rustc-source patches into rust-source.inc

[Kokkonda, Sundeep]

Yes, linker is needed by 'rust' and we checked that linker issue is solved by 
adding minimal required pkgs 'gcc g++ & binutils' instead of complete pkgs 
provided by ' packagegroup-core-buildessential'.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176087): 
https://lists.openembedded.org/g/openembedded-core/message/176087
Mute This Topic: https://lists.openembedded.org/mt/96110740/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] librsvg: Only enable the Vala bindings if GObject Introspection is enabled

[Peter Kjellerstedt]

This avoids the following error:

  configure: error: Vala bindings require GObject Introspection

Signed-off-by: Peter Kjellerstedt 
---
 meta/recipes-gnome/librsvg/librsvg_2.54.5.bb | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
index b2e93a2684..c55aa250e9 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.54.5.bb
@@ -42,8 +42,6 @@ do_configure[postfuncs] += "cargo_common_do_configure"
 
 inherit rust-target-config
 
-EXTRA_OECONF:class-target = "--enable-vala"
-
 # rust-cross writes the target linker binary into target json definition 
without any flags.
 # This breaks here because the linker isn't going to work without at least 
knowing where
 # the sysroot is. So copy the json to workdir, and patch in the path to 
wrapper from rust class
@@ -57,9 +55,10 @@ CVE_CHECK_IGNORE += "CVE-2018-141"
 
 CACHED_CONFIGUREVARS = 
"ac_cv_path_GDK_PIXBUF_QUERYLOADERS=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders"
 
-PACKAGECONFIG ??= "gdkpixbuf"
+PACKAGECONFIG ??= "gdkpixbuf ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 
'vala', '', d)}"
 # The gdk-pixbuf loader
 PACKAGECONFIG[gdkpixbuf] = 
"--enable-pixbuf-loader,--disable-pixbuf-loader,gdk-pixbuf-native"
+PACKAGECONFIG[vala] = "--enable-vala,--disable-vala"
 
 do_install:append() {
# Loadable modules don't need .a or .la on Linux

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

[OE-core] [langdale][PATCH] libksba: update 1.6.2 -> 1.6.3

[Lee Chee Yang]

From: Alexander Kanavin 

ChangeLog  (libksba-1.6.3)

2022-12-06  Werner Koch  

   Release 1.6.3.
   + commit bffa9b346071725363a483db547e7dced9721cb5

2022-11-23  Werner Koch  

   Fix an integer overflow in the CRL signature parser.
   + commit f61a5ea4e0f6a80fd4b28ef0174bee77793cf070
   * src/crl.c (parse_signature): N+N2 now checked for overflow.

   * src/ocsp.c (parse_response_extensions): Do not accept too
large
   values.
   (parse_single_extensions): Ditto.

2022-11-02  NIIBE Yutaka  

   build: Update m4/libgcrypt.m4.
   + commit 4076b60f7cef4fddc3d30f6e6d4078081dbc7167
   * m4/libgcrypt.m4: Update from libgcrypt master.

2022-11-01  NIIBE Yutaka  

   build: Prefer gpgrt-config when available.
   + commit 13307b22882a220d206341e1196e74fd37418c2f
   * src/ksba.m4: Overriding the decision by
--with-libksba-prefix, use
   gpgrt-config ksba when gpgrt-config is available.

2022-10-24  NIIBE Yutaka  

   build: Update gpg-error.m4.
   + commit c3c1627f34234e3d54fe1f3411ac499dd7e3b3b0
   * m4/gpg-error.m4: Update from libgpg-error 1.46.

(From OE-Core rev: 83f3f21b1b84ab9e7b461ac966691c80f4ed4e97)

Signed-off-by: Alexander Kanavin 
Signed-off-by: Alexandre Belloni 
Signed-off-by: Richard Purdie 
Signed-off-by: Chee Yang Lee 
---

add changelog to commit message

 .../libksba/libksba/ksba-add-pkgconfig-support.patch| 6 +++---
 .../libksba/{libksba_1.6.2.bb => libksba_1.6.3.bb}  | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-support/libksba/{libksba_1.6.2.bb => libksba_1.6.3.bb} 
(94%)

diff --git 
a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch 
b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
index af96bd57cd..bdb80ff34d 100644
--- a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
+++ b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
@@ -1,4 +1,4 @@
-From 6081640895b6d566fa21123e2de7d111eeab5c4c Mon Sep 17 00:00:00 2001
+From ca8174aa81d7bf364b33f7254a9e887735c4996d Mon Sep 17 00:00:00 2001
 From: Chen Qi 
 Date: Mon, 3 Dec 2012 18:17:31 +0800
 Subject: [PATCH] libksba: add pkgconfig support
@@ -16,7 +16,7 @@ Signed-off-by: Chen Qi 
  1 file changed, 4 insertions(+), 86 deletions(-)
 
 diff --git a/src/ksba.m4 b/src/ksba.m4
-index 6b55bb8..6e7336f 100644
+index 452c245..aa96255 100644
 --- a/src/ksba.m4
 +++ b/src/ksba.m4
 @@ -23,37 +23,6 @@ dnl with a changed API.
@@ -44,7 +44,7 @@ index 6b55bb8..6e7336f 100644
 -  fi
 -
 -  use_gpgrt_config=""
--  if test x"$KSBA_CONFIG" = x -a x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != 
"no"; then
+-  if test x"$GPGRT_CONFIG" != x -a "$GPGRT_CONFIG" != "no"; then
 -if $GPGRT_CONFIG ksba --exists; then
 -  KSBA_CONFIG="$GPGRT_CONFIG ksba"
 -  AC_MSG_NOTICE([Use gpgrt-config as ksba-config])
diff --git a/meta/recipes-support/libksba/libksba_1.6.2.bb 
b/meta/recipes-support/libksba/libksba_1.6.3.bb
similarity index 94%
rename from meta/recipes-support/libksba/libksba_1.6.2.bb
rename to meta/recipes-support/libksba/libksba_1.6.3.bb
index f6ecb9aec4..dc39693be4 100644
--- a/meta/recipes-support/libksba/libksba_1.6.2.bb
+++ b/meta/recipes-support/libksba/libksba_1.6.3.bb
@@ -24,7 +24,7 @@ UPSTREAM_CHECK_URI = "https://gnupg.org/download/index.html;
 SRC_URI = "${GNUPG_MIRROR}/${BPN}/${BPN}-${PV}.tar.bz2 \
file://ksba-add-pkgconfig-support.patch"
 
-SRC_URI[sha256sum] = 
"fce01ccac59812bddadffacff017dac2e4762bdb6ebc6ffe06f6ed4f6192c971"
+SRC_URI[sha256sum] = 
"3f72c68db30971ebbf14367527719423f0a4d5f8103fc9f4a1c01a9fa440de5c"
 
 do_configure:prepend () {
# Else these could be used in preference to those in aclocal-copy
-- 
2.37.3


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

Re: [OE-core] [PATCH] rust: Upgrade 1.66.0 -> 1.66.1

[Alex Kiernan]

On Wed, Jan 18, 2023 at 8:08 AM Mikko Rapeli  wrote:
>
> Hi,
>
> On Wed, Jan 18, 2023 at 08:45:56AM +0100, Alexander Kanavin wrote:
> > On Wed, 18 Jan 2023 at 03:08, Randy MacLeod  
> > wrote:
> > > So far, there haven't been many Rust/Cargo CVEs so maybe we're making
> > > too big a deal out of this. I certainly don't miss the deluge of memory 
> > > management CVEs that
> > > C/C++ applications suffer from!
> >
> > For what it's worth I'm with you here, and I actually have an even
> > more radical view (that may offend some - apologies). I think this
> > whole 'CVE backporting' business is both enormously wasteful and never
> > complete (or even close to it). Backporting CVEs and the stable
> > release policy is basically a cover-up for bad (or altogether absent)
> > CI at the project users side. If you upgrade a component, and it
> > causes trouble, the trouble should be caught by pipeline, and not in
> > the end product when the update has shipped.
>
> It's usually not lack of CI, continuous integration, but lack of testing
> coverage which is visible as risk management where any changes are
> avoided and someties FUD replaces hard facts. A CI run may not show that
> SW compatibility or some use cases are broken.

We've been running with rust in production for a couple of years, I
think we hit our first instance of an upgrade issue last week - a ureq
crate upgrade changed something (I suspect in its pooling code) which
meant that we ended up using all file descriptors. Wasn't caught in CI
as nothing ran for long enough, but was caught in test (we still need
to get to the root cause - right now we just rolled back that crate).

But over that time we've aggressively upgraded rust from something
like 1.48 to 1.66.1, all the crates we build against and to the best
of my knowledge this is the first time we've been tripped up.

> > The saner policy would have been 'a Yocto stable release contains
> > component versions all within their support windows by respective
> > upstreams'. If the only supported version is the latest one, then so
> > be it.
>
> When mainting yocto SW stack for a long time, I made the distinction
> between development tools and target SW. Basically all -native and
> nativesdk- recipes and those target recipes which are not in the product
> by default are development tools.
>
> Development tools can be updated to new versions to fix severe bugs and
> CVEs. For target SW, this can be done if ABI compatibility is preserved,
> or in case of severe issues where ABI is part of the problem or
> backporting the fix is more risky than an update, but this requires a
> managed transition with the product platform where all users of the SW
> are checked. ABI compatibility is important because frequently real
> products often need to integrate binaries where source code is not available
> to the bitbake build.
>
> With this approach, I've updated tools and compiler versions. I would
> not mind similar policy in upstream. Maintaining multiple rust/cargo
> versions well is not likely going to happen so I'd accept this and
> accept same updates in all branches.
>
> If the same tool version works well and is tested in another yocto
> branch and there are no major issues porting the same changes to another
> LTS branch, this gives confidence that the update is ok.
>

For vendor reasons, we're stuck on thud (I know...), however we've a
pile of backports so we can mostly just pick current recipes out of
master or stable branches (python packages are the one which we're
coming up against now as a blocker - fortunately we've expunged python
from our target code base).

My view for a very long time has been that you basically have to stay
very close to the most current release of whatever upstream code
you're consuming, otherwise you're doomed to spending more and more of
your life finding/fixing issues (security or otherwise) which were
long since addressed upstream.

-- 
Alex Kiernan

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

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

[Luca Ceresoli via lists.openembedded.org]

Hello Maanya,

On Tue, 17 Jan 2023 18:02:52 +
"Maanya Goenka via lists.openembedded.org"
 wrote:

> Also, signed off by Paul Eggleton: paul.eggle...@microsoft.com
> 
> From: maanyagoe...@linux.microsoft.com 
> Sent: Tuesday, January 17, 2023 10:01 AM
> To: openembedded-core@lists.openembedded.org 
> 
> Cc: Maanya Goenka ; Maanya Goenka 
> 
> Subject: [PATCH] create-spdx: fix config build by adding dependency to enable 
> reruns

Here you seem to be replying to a patch, but the original patch does
not appear neither in my inbox nor in the archives (I checked on
lore.kernel.org).

Can you send the patch again? A "[PATCH][RESEND]" tag would be OK I
guess.

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

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

Re: [OE-core] [PATCH 3/3] binutils: Delete gdb and supporting sources

[Richard Purdie]

On Wed, 2023-01-18 at 01:13 -0800, Khem Raj wrote:
> On Wed, Jan 18, 2023 at 12:47 AM Alejandro Hernandez  wrote:
> > 
> > Hey Khem,
> > 
> > On Sun, 15 Jan 2023 at 11:44, Khem Raj  wrote:
> > > 
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/recipes-devtools/binutils/binutils.inc | 10 ++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/meta/recipes-devtools/binutils/binutils.inc 
> > > b/meta/recipes-devtools/binutils/binutils.inc
> > > index 98acf0a222..2b38aeb62d 100644
> > > --- a/meta/recipes-devtools/binutils/binutils.inc
> > > +++ b/meta/recipes-devtools/binutils/binutils.inc
> > > @@ -140,6 +140,16 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
> > > 
> > >  MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", 
> > > "yes", "no", d)}"
> > >  do_configure[vardeps] += "MULTIARCH"
> > > +
> > > +addtask do_prepare_sources after do_patch before do_configure
> > > +
> > > +# Remove gdb and supporting source directories, they are detected by
> > > +# configure otherwise and demands additional gdb deps e.g. gmp, mpc, mpfr
> > > +do_prepare_sources () {
> > > +   rm -rf ${S}/gdb ${S}/gdbserver ${S}/gdbsupport ${S}/gnulib \
> > > +   ${S}/libbacktrace ${S}/libdecnumber ${S}/readline ${S}/sim
> > > +}
> > > +
> > 
> > 
> > This seems to have been fixed upstream, I wonder if its better to backport 
> > that patch to 2.40 so it aligns properly with the --disable-gdb flag we are 
> > passing:
> > https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5fb0e308577143ceb313fde5538dc9ecb038f29f
> > 
> 
> Thanks yes its better to backport it, I will add it to v2.

I'm happier with that as I was worried how the other approach was going
to interact with the archiver and other code.

Thanks,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176082): 
https://lists.openembedded.org/g/openembedded-core/message/176082
Mute This Topic: https://lists.openembedded.org/mt/96291245/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] mesa: update submitted patch with backported version

[Kai Kang]

On 1/16/23 23:33, Martin Jansa wrote:

Kai: can you please test it on ubuntu-18.04?


Hi Martin,

It works for me with & without DEBUG_BUILD on ubuntu-18.04.6(gcc 7.5.0).

Regards,
Kai



I've tested it with DEBUG_BUILD in native and target build on a host 
with new toolchain (gentoo with gcc-12.2.1) and according to 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439 
 
it works with old toolchain as well.


On Mon, Jan 16, 2023 at 4:30 PM Martin Jansa via 
lists.openembedded.org 
 
 wrote:


* this version was merged to main in:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911


  and cherry-picked to staging/23.0 as well in:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/54cfb552abc50e8167cdc46d87455a9a414d7c65



  and as a bonus it doesn't break the build with DEBUG_BUILD
  for newer toolchain, so we can apply it for target build as
well, see:
https://lists.openembedded.org/g/openembedded-core/message/169002


https://lists.openembedded.org/g/openembedded-core/message/170930



Signed-off-by: Martin Jansa 
---
 ...ove-fix-ALWAYS_INLINE-compiler-error.patch | 81
++-
 meta/recipes-graphics/mesa/mesa.inc           |  5 +-
 2 files changed, 26 insertions(+), 60 deletions(-)

diff --git

a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch

b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
index 7989843eb4..1cf23492fe 100644
---

a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
+++

b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
@@ -1,67 +1,36 @@
-From da6e47f1717f34c73de388c56ffaf4861a07fdc5 Mon Sep 17 00:00:00
2001
-From: t bettler 
-Date: Sat, 9 Jul 2022 09:28:51 +
+From 267dd1f4d571ee606141aa66f1665aa152b4e911 Mon Sep 17 00:00:00
2001
+From: t0b3 
+Date: Sat, 10 Dec 2022 14:32:53 +0100
 Subject: [PATCH] nir/nir_opt_move: fix ALWAYS_INLINE compiler error
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit

-Backport merge request to fix mesa compile error when debug build
-enabled.
-
-Upstream-Status: Submitted
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439

]
-
-Signed-off-by: Kai Kang 
-
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-fix call to ‘always_inline’ ‘src_is_ssa’
-
-Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6825


-Fixes: f1d20ec67c3f186886b97de94f74484650f8fda1
("nir/nir_opt_move: handle non-SSA defs ")
+Reviewed-by: Iago Toral Quiroga 
+Reviewed-by: Adam Jackson 
+Closes: #6825
+Fixes: f1d20ec6 ("nir/nir_opt_move: handle non-SSA defs ")
+Part-of:
>

+Upstream-Status: Backport

Re: [OE-core] [PATCH 3/3] binutils: Delete gdb and supporting sources

[Khem Raj]

On Wed, Jan 18, 2023 at 12:47 AM Alejandro Hernandez  wrote:
>
> Hey Khem,
>
> On Sun, 15 Jan 2023 at 11:44, Khem Raj  wrote:
>>
>> Signed-off-by: Khem Raj 
>> ---
>>  meta/recipes-devtools/binutils/binutils.inc | 10 ++
>>  1 file changed, 10 insertions(+)
>>
>> diff --git a/meta/recipes-devtools/binutils/binutils.inc 
>> b/meta/recipes-devtools/binutils/binutils.inc
>> index 98acf0a222..2b38aeb62d 100644
>> --- a/meta/recipes-devtools/binutils/binutils.inc
>> +++ b/meta/recipes-devtools/binutils/binutils.inc
>> @@ -140,6 +140,16 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
>>
>>  MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes", 
>> "no", d)}"
>>  do_configure[vardeps] += "MULTIARCH"
>> +
>> +addtask do_prepare_sources after do_patch before do_configure
>> +
>> +# Remove gdb and supporting source directories, they are detected by
>> +# configure otherwise and demands additional gdb deps e.g. gmp, mpc, mpfr
>> +do_prepare_sources () {
>> +   rm -rf ${S}/gdb ${S}/gdbserver ${S}/gdbsupport ${S}/gnulib \
>> +   ${S}/libbacktrace ${S}/libdecnumber ${S}/readline ${S}/sim
>> +}
>> +
>
>
> This seems to have been fixed upstream, I wonder if its better to backport 
> that patch to 2.40 so it aligns properly with the --disable-gdb flag we are 
> passing:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5fb0e308577143ceb313fde5538dc9ecb038f29f
>

Thanks yes its better to backport it, I will add it to v2.

> Cheers,
>
> Alejandro
>>
>>  do_configure () {
>> (cd ${S} && gnu-configize)
>>
>> --
>> 2.39.0
>>
>>
>> 
>>

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

Re: [OE-core] [PATCH 3/3] binutils: Delete gdb and supporting sources

[Alejandro Hernandez Samaniego]

Hey Khem,

On Sun, 15 Jan 2023 at 11:44, Khem Raj  wrote:

> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-devtools/binutils/binutils.inc | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/meta/recipes-devtools/binutils/binutils.inc
> b/meta/recipes-devtools/binutils/binutils.inc
> index 98acf0a222..2b38aeb62d 100644
> --- a/meta/recipes-devtools/binutils/binutils.inc
> +++ b/meta/recipes-devtools/binutils/binutils.inc
> @@ -140,6 +140,16 @@ export CC_FOR_BUILD = "LD_LIBRARY_PATH= ${BUILD_CC}"
>
>  MULTIARCH := "${@bb.utils.contains("DISTRO_FEATURES", "multiarch", "yes",
> "no", d)}"
>  do_configure[vardeps] += "MULTIARCH"
> +
> +addtask do_prepare_sources after do_patch before do_configure
> +
> +# Remove gdb and supporting source directories, they are detected by
> +# configure otherwise and demands additional gdb deps e.g. gmp, mpc, mpfr
> +do_prepare_sources () {
> +   rm -rf ${S}/gdb ${S}/gdbserver ${S}/gdbsupport ${S}/gnulib \
> +   ${S}/libbacktrace ${S}/libdecnumber ${S}/readline ${S}/sim
> +}
> +
>

This seems to have been fixed upstream, I wonder if its better to backport
that patch to 2.40 so it aligns properly with the --disable-gdb flag we are
passing:
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5fb0e308577143ceb313fde5538dc9ecb038f29f

Cheers,

Alejandro

>  do_configure () {
> (cd ${S} && gnu-configize)
>
> --
> 2.39.0
>
>
> 
>
>

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

Re: [OE-core] [PATCH 1/3] binutils: Upgrade to 2.40 release

[Luca Ceresoli via lists.openembedded.org]

Hi Khem,

On Tue, 17 Jan 2023 14:55:31 +0100
"Luca Ceresoli via lists.openembedded.org"
 wrote:

> Hi Khem,
> 
> On Sun, 15 Jan 2023 10:43:55 -0800
> "Khem Raj"  wrote:
> 
> > Signed-off-by: Khem Raj   
> 
> This patchset (perhaps this one specific patch) seems to be causing
> failures on the autobuilders with meta-mingw:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/6556/steps/16/logs/stdio
> 

Another failure that was possibly caused by this series, and which
disappeared when I ran tests without this series, is:

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/4562/steps/13/logs/stdio

WARNING: core-image-ptest-all-1.0-r0 do_testimage: There were failing ptests.
...
AssertionError: Failed ptests:
{'elfutils': ['run-native-test.sh']}

And the ptest log says:

/usr/lib/elfutils/ptest/tests/funcretval: dwfl_module_return_value_location: 
cannot handle DWARF type description
FAIL: run-native-test.sh

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

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

Re: [OE-core] [PATCH] rust: Upgrade 1.66.0 -> 1.66.1

[Mikko Rapeli]

Hi,

On Wed, Jan 18, 2023 at 08:45:56AM +0100, Alexander Kanavin wrote:
> On Wed, 18 Jan 2023 at 03:08, Randy MacLeod  
> wrote:
> > So far, there haven't been many Rust/Cargo CVEs so maybe we're making
> > too big a deal out of this. I certainly don't miss the deluge of memory 
> > management CVEs that
> > C/C++ applications suffer from!
> 
> For what it's worth I'm with you here, and I actually have an even
> more radical view (that may offend some - apologies). I think this
> whole 'CVE backporting' business is both enormously wasteful and never
> complete (or even close to it). Backporting CVEs and the stable
> release policy is basically a cover-up for bad (or altogether absent)
> CI at the project users side. If you upgrade a component, and it
> causes trouble, the trouble should be caught by pipeline, and not in
> the end product when the update has shipped.

It's usually not lack of CI, continuous integration, but lack of testing
coverage which is visible as risk management where any changes are
avoided and someties FUD replaces hard facts. A CI run may not show that
SW compatibility or some use cases are broken. In the worst case this is
detected by customers after SW has been deployed in the field.

> The saner policy would have been 'a Yocto stable release contains
> component versions all within their support windows by respective
> upstreams'. If the only supported version is the latest one, then so
> be it.

When mainting yocto SW stack for a long time, I made the distinction
between development tools and target SW. Basically all -native and
nativesdk- recipes and those target recipes which are not in the product
by default are development tools.

Development tools can be updated to new versions to fix severe bugs and
CVEs. For target SW, this can be done if ABI compatibility is preserved,
or in case of severe issues where ABI is part of the problem or
backporting the fix is more risky than an update, but this requires a
managed transition with the product platform where all users of the SW
are checked. ABI compatibility is important because frequently real
products often need to integrate binaries where source code is not available
to the bitbake build.

With this approach, I've updated tools and compiler versions. I would
not mind similar policy in upstream. Maintaining multiple rust/cargo
versions well is not likely going to happen so I'd accept this and
accept same updates in all branches.

If the same tool version works well and is tested in another yocto
branch and there are no major issues porting the same changes to another
LTS branch, this gives confidence that the update is ok.

Cheers,

-Mikko

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

Re: [OE-core] [kirkstone][PATCH] bluez: CVE-2022-3637 A DoS exists in monitor/jlink.c

[Hitendra Prajapati]

Hi Team,
Please ignore previous mail.

Regards,
Hitendra

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