Re: [OE-core] [PATCH 18/26] boost: update 1.77.0 -> 1.78.0
On Thu, 16 Dec 2021 at 00:28, Khem Raj wrote:
> > Drop 0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch as
> > it is difficult to rebase and needs to land upstream first.
>
> It's not that rebasing is too hard for this patch but this patch is an
> incorrect way to fix what it's trying to solve and that's why I am
> fine with dropping it.
> landing upstream is not a precondition for submitting patches to
> OpenEmbedded but good to have. All distributions carry patches and as
> long as patches are working
> their way upstream asynchronously its ok. Let's not make it too hard
> for contributors and chase them away.
>
Yes, rather than 'land upstream' I should've said 'submitted upstream' -
that patch is dated 16 October 2020, and it never happened. While myself
and everyone else enormously appreciate your toolchain and target work,
there's a problem with amassing invasive pending patches related to that:
no one except you truly understands them. So what I'm asking is just a bit
more rigor going forward: submit patches upstream at the same time you
submit them to core, and steadily work your way towards reducing the pile
that's already there.
Alex
>
> >
> > Signed-off-by: Alexander Kanavin
> > ---
> > .../{boost-1.77.0.inc => boost-1.78.0.inc}| 2 +-
> > cmake-allow-searching-for-python310.patch | 50 --
> > ...h-instruction-set-flags-we-do-that-o.patch | 15 +-
> > ...efine-SYS_futex-if-it-does-not-exist.patch | 54 ---
> > ...th_no_atomic_int-on-the-command-line.patch | 53 --
> > ...oft-failure-in-bernoulli_details_hpp.patch | 151 --
> > ...7e01635306085488290ea83de541ec393f8b.patch | 30
> > meta/recipes-support/boost/boost_1.77.0.bb| 12 --
> > meta/recipes-support/boost/boost_1.78.0.bb| 9 ++
> > 9 files changed, 50 insertions(+), 326 deletions(-)
> > rename meta/recipes-support/boost/{boost-1.77.0.inc =>
> boost-1.78.0.inc} (90%)
> > delete mode 100644
> meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
> > delete mode 100644
> meta/recipes-support/boost/boost/0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch
> > delete mode 100644
> meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
> > delete mode 100644
> meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch
> > create mode 100644
> meta/recipes-support/boost/boost/de657e01635306085488290ea83de541ec393f8b.patch
> > delete mode 100644 meta/recipes-support/boost/boost_1.77.0.bb
> > create mode 100644 meta/recipes-support/boost/boost_1.78.0.bb
> >
> > diff --git a/meta/recipes-support/boost/boost-1.77.0.inc
> b/meta/recipes-support/boost/boost-1.78.0.inc
> > similarity index 90%
> > rename from meta/recipes-support/boost/boost-1.77.0.inc
> > rename to meta/recipes-support/boost/boost-1.78.0.inc
> > index 6df06e76c7..729a47b54f 100644
> > --- a/meta/recipes-support/boost/boost-1.77.0.inc
> > +++ b/meta/recipes-support/boost/boost-1.78.0.inc
> > @@ -12,7 +12,7 @@ BOOST_MAJ =
> "${@"_".join(d.getVar("PV").split(".")[0:2])}"
> > BOOST_P = "boost_${BOOST_VER}"
> >
> > SRC_URI = "
> https://boostorg.jfrog.io/artifactory/main/release/${PV}/source/${BOOST_P}.tar.bz2
> "
> > -SRC_URI[sha256sum] =
> "fc9f85fc030e233142908241af7a846e60630aa7388de9a5fafb1f3a26840854"
> > +SRC_URI[sha256sum] =
> "8681f175d4bdb26c5665793eef08490d7758529330f98d3b29dd0735bccc"
> >
> > UPSTREAM_CHECK_URI = "http://www.boost.org/users/download/";
> > UPSTREAM_CHECK_REGEX = "release/(?P.*)/source/"
> > diff --git
> a/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
> b/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
> > deleted file mode 100644
> > index 0a9ee2cc95..00
> > ---
> a/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
> > +++ /dev/null
> > @@ -1,50 +0,0 @@
> > -From e193f080c7d209516ac9b712fa0c50bb08026fa2 Mon Sep 17 00:00:00 2001
> > -From: Martin Jansa
> > -Date: Tue, 19 Oct 2021 12:24:31 +
> > -Subject: [PATCH] BoostConfig.cmake: allow searching for python310
> > -
> > -* accept double digits in Python3_VERSION_MINOR
> > -
> > -* if someone is using e.g.:
> > - find_package(Python3 REQUIRED)
> > - find_package(Boost REQUIRED
> python${Python3_VERSION_MAJOR}${Python3_VERSION_MINOR})
> > -
> > - with python-3.10 then it currently fails with:
> > -
> > - -- Found PythonLibs: /usr/lib/libpython3.10.so (found version
> "3.10.0")
> > - -- Found Python3: -native/usr/bin/python3-native/python3 (found
> version "3.10.0") found components: Interpreter
> > - CMake Error at /usr/lib/cmake/Boost-1.77.0/BoostConfig.cmake:141
> (find_package):
> > -Could not find a package configuration file provided by
> "boost_python310"
> > -(requested version 1.77.0) with any of the followin
[OE-core] [PATCH] rust: fix arm64 link failures when building rust apps
Typical error when trying to build a rust app (for example, librsvg)
for aarch64 targets looks like:
undefined references to `__aarch64_ldadd8_rel'
The upstream rust commit
"add target feature outline-atomics" 0f9f241aac21bc77fb9e757da18207abefdc841d
has caused a number of such link failure regressions on platforms with aarch64
toolchains that are not able to cope with -moutline-atomics flag. This includes
musl toolchains [1] but some glibc toolchains also are not able to handle this
flag [2,3]
OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able to
handle outline-atomics this patch should go away, to take advantage of the
reported performance benefit.
[1] https://github.com/rust-lang/git2-rs/issues/706
[2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
Signed-off-by: S. Lockwood-Childs
---
meta/recipes-devtools/rust/rust-target.inc| 2 +
.../rust/rust-disable-outline-atomics.patch | 50 +++
2 files changed, 52 insertions(+)
create mode 100644
meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
diff --git a/meta/recipes-devtools/rust/rust-target.inc
b/meta/recipes-devtools/rust/rust-target.inc
index 3f637b3ba5..bac743f66d 100644
--- a/meta/recipes-devtools/rust/rust-target.inc
+++ b/meta/recipes-devtools/rust/rust-target.inc
@@ -2,6 +2,8 @@ require rust.inc
DEPENDS += "rust-llvm (=${PV})"
+SRC_URI += "file://rust-disable-outline-atomics.patch"
+
# Otherwise we'll depend on what we provide
INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
# We don't need to depend on gcc-native because yocto assumes it exists
diff --git a/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
new file mode 100644
index 00..fc99a06a6a
--- /dev/null
+++ b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
@@ -0,0 +1,50 @@
+rust: fix arm64 link failures when building rust apps
+
+Typical error when trying to build a rust app looks like:
+ undefined references to `__aarch64_ldadd8_rel'
+
+The upstream rust commit
+"add target feature outline-atomics" 0f9f241aac21bc77fb9e757da18207abefdc841d
+has caused a number of such link failure regressions on platforms with aarch64
+toolchains that are not able to cope with -moutline-atomics flag. This includes
+musl toolchains [1] but some glibc toolchains also are not able to handle this
+flag [2,3]
+
+OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able to
+handle outline-atomics this patch should go away, to take advantage of the
+reported performance benefit.
+
+[1] https://github.com/rust-lang/git2-rs/issues/706
+[2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
+[3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
+
+Upstream-Status: Inappropriate [other]
+
+Signed-off-by: S. Lockwood-Childs
+
+diff --git a/compiler/rustc_codegen_llvm/src/llvm_util.rs
b/compiler/rustc_codegen_llvm/src/llvm_util.rs
+index c2136f161..ca221eb4a 100644
+--- a/compiler/rustc_codegen_llvm/src/llvm_util.rs
b/compiler/rustc_codegen_llvm/src/llvm_util.rs
+@@ -416,13 +416,14 @@ pub fn llvm_global_features(sess: &Session) ->
Vec {
+ // -Ctarget-features
+ features.extend(sess.opts.cg.target_feature.split(',').flat_map(&filter));
+
+-// FIXME: Move outline-atomics to target definition when earliest
supported LLVM is 12.
+-if get_version() >= (12, 0, 0)
+-&& sess.target.llvm_target.contains("aarch64-unknown-linux")
+-&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
+-{
+-features.push("+outline-atomics".to_string());
+-}
++//// FIXME: Move outline-atomics to target definition when earliest
supported LLVM is 12.
++//if get_version() >= (12, 0, 0)
++//&& sess.target.llvm_target.contains("aarch64-unknown-linux")
++//&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
++//{
++//features.push("+outline-atomics".to_string());
++//}
++
+
+ features
+ }
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159774):
https://lists.openembedded.org/g/openembedded-core/message/159774
Mute This Topic: https://lists.openembedded.org/mt/87763768/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: fix arm64 link failures when building rust apps
Discussion in https://github.com/rust-lang/git2-rs/pull/759 doesn't exactly
fill one with confidence, but still, can this be handled and fixed in rust
upstream? Non-upstreamable patches for what is a common use case aren't a
good idea.
Alex
On Thu, 16 Dec 2021 at 10:19, S. Lockwood-Childs wrote:
> Typical error when trying to build a rust app (for example, librsvg)
> for aarch64 targets looks like:
> undefined references to `__aarch64_ldadd8_rel'
>
> The upstream rust commit
> "add target feature outline-atomics"
> 0f9f241aac21bc77fb9e757da18207abefdc841d
> has caused a number of such link failure regressions on platforms with
> aarch64
> toolchains that are not able to cope with -moutline-atomics flag. This
> includes
> musl toolchains [1] but some glibc toolchains also are not able to handle
> this
> flag [2,3]
>
> OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able
> to
> handle outline-atomics this patch should go away, to take advantage of the
> reported performance benefit.
>
> [1] https://github.com/rust-lang/git2-rs/issues/706
> [2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
>
> Signed-off-by: S. Lockwood-Childs
> ---
> meta/recipes-devtools/rust/rust-target.inc| 2 +
> .../rust/rust-disable-outline-atomics.patch | 50 +++
> 2 files changed, 52 insertions(+)
> create mode 100644
> meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
>
> diff --git a/meta/recipes-devtools/rust/rust-target.inc
> b/meta/recipes-devtools/rust/rust-target.inc
> index 3f637b3ba5..bac743f66d 100644
> --- a/meta/recipes-devtools/rust/rust-target.inc
> +++ b/meta/recipes-devtools/rust/rust-target.inc
> @@ -2,6 +2,8 @@ require rust.inc
>
> DEPENDS += "rust-llvm (=${PV})"
>
> +SRC_URI += "file://rust-disable-outline-atomics.patch"
> +
> # Otherwise we'll depend on what we provide
> INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
> # We don't need to depend on gcc-native because yocto assumes it exists
> diff --git
> a/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> new file mode 100644
> index 00..fc99a06a6a
> --- /dev/null
> +++ b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> @@ -0,0 +1,50 @@
> +rust: fix arm64 link failures when building rust apps
> +
> +Typical error when trying to build a rust app looks like:
> + undefined references to `__aarch64_ldadd8_rel'
> +
> +The upstream rust commit
> +"add target feature outline-atomics"
> 0f9f241aac21bc77fb9e757da18207abefdc841d
> +has caused a number of such link failure regressions on platforms with
> aarch64
> +toolchains that are not able to cope with -moutline-atomics flag. This
> includes
> +musl toolchains [1] but some glibc toolchains also are not able to handle
> this
> +flag [2,3]
> +
> +OE gcc-cross-aarch64 is currently one of the latter, but when it *is*
> able to
> +handle outline-atomics this patch should go away, to take advantage of the
> +reported performance benefit.
> +
> +[1] https://github.com/rust-lang/git2-rs/issues/706
> +[2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> +[3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
> +
> +Upstream-Status: Inappropriate [other]
> +
> +Signed-off-by: S. Lockwood-Childs
> +
> +diff --git a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> +index c2136f161..ca221eb4a 100644
> +--- a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> +@@ -416,13 +416,14 @@ pub fn llvm_global_features(sess: &Session) ->
> Vec {
> + // -Ctarget-features
> + features.extend(sess.opts.cg
> .target_feature.split(',').flat_map(&filter));
> +
> +-// FIXME: Move outline-atomics to target definition when earliest
> supported LLVM is 12.
> +-if get_version() >= (12, 0, 0)
> +-&& sess.target.llvm_target.contains("aarch64-unknown-linux")
> +-&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
> +-{
> +-features.push("+outline-atomics".to_string());
> +-}
> ++//// FIXME: Move outline-atomics to target definition when earliest
> supported LLVM is 12.
> ++//if get_version() >= (12, 0, 0)
> ++//&& sess.target.llvm_target.contains("aarch64-unknown-linux")
> ++//&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
> ++//{
> ++//features.push("+outline-atomics".to_string());
> ++//}
> ++
> +
> + features
> + }
> --
> 2.20.1
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159775):
https://lists.openembedded.org/g/openembedded-core/message/159775
Mute This Topic: https://lists.openembedded.org/mt/87763768/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembe
[OE-core] [PATCH 1/3] cmake.bbclass: support android os
From: "Hsia-Jun(Randy) Li"
Signed-off-by: Randy Li
Signed-off-by: Hsia-Jun(Randy) Li
---
meta/classes/cmake.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index 92b9197c48..40ae4fba08 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -69,6 +69,8 @@ OECMAKE_TARGET_COMPILE ?= "all"
OECMAKE_TARGET_INSTALL ?= "install"
def map_host_os_to_system_name(host_os):
+if host_os.startswith('android'):
+return 'Android'
if host_os.startswith('mingw'):
return 'Windows'
if host_os.startswith('linux'):
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159777):
https://lists.openembedded.org/g/openembedded-core/message/159777
Mute This Topic: https://lists.openembedded.org/mt/87764531/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 0/3] support Android target in all build system
From: "Hsia-Jun(Randy) Li" Both meson and cmake would work fine, left those GNU autotools, customer script projects. The behaviour of meson would become that as the following for the Android target: lib/libfoo.so is the real binary library lib/libfoo.so.x -> libfoo.so lib/libfoo.so.x.y -> libfoo.so But when you tell the autotools the target host is android, it won't make any difference in its output library. I would like to fix that but I am not good at m4 script. Hsia-Jun(Randy) Li (3): cmake.bbclass: support android os classes/meson: support Android os [WIP]: openssl: fix Android target meta/classes/cmake.bbclass | 2 ++ meta/classes/meson-routines.bbclass| 2 ++ meta/recipes-connectivity/openssl/openssl_3.0.0.bb | 4 3 files changed, 8 insertions(+) -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159776): https://lists.openembedded.org/g/openembedded-core/message/159776 Mute This Topic: https://lists.openembedded.org/mt/87764530/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] classes/meson: support Android os
From: "Hsia-Jun(Randy) Li" Signed-off-by: Randy Li Signed-off-by: Hsia-Jun(Randy) Li --- meta/classes/meson-routines.bbclass | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meta/classes/meson-routines.bbclass b/meta/classes/meson-routines.bbclass index be3aeedeba..f9a06a16d8 100644 --- a/meta/classes/meson-routines.bbclass +++ b/meta/classes/meson-routines.bbclass @@ -32,6 +32,8 @@ def meson_cpu_family(var, d): # https://mesonbuild.com/Reference-tables.html#operating-system-names def meson_operating_system(var, d): os = d.getVar(var) +if "android" in os: +return "android" if "mingw" in os: return "windows" # avoid e.g 'linux-gnueabi' -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159778): https://lists.openembedded.org/g/openembedded-core/message/159778 Mute This Topic: https://lists.openembedded.org/mt/87764532/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] [WIP]: openssl: fix Android target
From: "Hsia-Jun(Randy) Li"
It is fair to regard Android as Linux target, we repack
the sysroot, so we don't need to bother those helper
from openssl.
Signed-off-by: Hsia-Jun(Randy) Li
---
meta/recipes-connectivity/openssl/openssl_3.0.0.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
b/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
index da73ed6bc3..c2e07fcb0a 100644
--- a/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
+++ b/meta/recipes-connectivity/openssl/openssl_3.0.0.bb
@@ -58,6 +58,10 @@ DEPRECATED_CRYPTO_FLAGS ?= ""
do_configure () {
os=${HOST_OS}
case $os in
+linux-androideabi | \
+linux-android )
+ os=linux
+ ;;
linux-gnueabi |\
linux-gnuspe |\
linux-musleabi |\
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159779):
https://lists.openembedded.org/g/openembedded-core/message/159779
Mute This Topic: https://lists.openembedded.org/mt/87764533/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 15/26] dpkg: update 1.20.9 -> 1.21.1
Hi Alexander,
> From: Alexander Kanavin
> Sent: Thursday, December 16, 2021 1:40 AM
> To: openembedded-core@lists.openembedded.org
>
> Cc: Alexander Kanavin ; Alexey Brodkin
>
> Subject: [PATCH 15/26] dpkg: update 1.20.9 -> 1.21.1
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-devtools/dpkg/dpkg.inc | 2 +
> ...ild.c-ignore-return-of-1-from-tar-cf.patch | 8 +--
> .../0014-arch-Add-support-for-ARCv2-CPU.patch | 68 ---
> .../dpkg/{dpkg_1.20.9.bb => dpkg_1.21.1.bb} | 5 +-
> 4 files changed, 8 insertions(+), 75 deletions(-)
> delete mode 100644
> meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch
> rename meta/recipes-devtools/dpkg/{dpkg_1.20.9.bb => dpkg_1.21.1.bb} (88%)
...
> ---
> a/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch
> +++ /dev/null
Thanks for taking care of that and ...
Reviewed-by: Alexey Brodkin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159780):
https://lists.openembedded.org/g/openembedded-core/message/159780
Mute This Topic: https://lists.openembedded.org/mt/87755572/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 0/2] qemu.bbclass: drop OLDEST_KERNEL reference
This addresses an issue with allarch recipes that use meson, where inheriting qemu.bbclass causes task signature changes when built with MACHINEs with different architectures due to the reference to the OLDEST_KERNEL variable for setting up qemu wrapper invocations. V2: * Backport Khem's qemu patch to set minimum kernel version for riscv32. With this patch, qemu for all supported archs should have a built-in oldest kernel setting, eliminating the need for putting it on the command line. Matt Madison (2): qemu.bbclass: drop OLDEST_KERNEL reference qemu: add patch to set minimum kernel version for riscv32 meta/classes/qemu.bbclass | 2 +- meta/recipes-devtools/qemu/qemu.inc | 1 + ...s-minimum-kernel-version-for-riscv32.patch | 40 +++ 3 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 meta/recipes-devtools/qemu/qemu/0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159781): https://lists.openembedded.org/g/openembedded-core/message/159781 Mute This Topic: https://lists.openembedded.org/mt/87765278/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH v2 2/2] qemu: add patch to set minimum kernel version for riscv32
which enables us to drop the -r option on qemu-static-riscv32
invocations.
Signed-off-by: Matt Madison
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
...s-minimum-kernel-version-for-riscv32.patch | 40 +++
2 files changed, 41 insertions(+)
create mode 100644
meta/recipes-devtools/qemu/qemu/0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index fe35f94acf..584c9482e9 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -27,6 +27,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://determinism.patch \
file://0001-tests-meson.build-use-relative-path-to-refer-to-file.patch \
file://0001-linux-user-Replace-__u64-with-uint64_t.patch \
+
file://0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git
a/meta/recipes-devtools/qemu/qemu/0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch
b/meta/recipes-devtools/qemu/qemu/0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch
new file mode 100644
index 00..ac4b6dcc44
--- /dev/null
+++
b/meta/recipes-devtools/qemu/qemu/0001-riscv-Set-5.4-as-minimum-kernel-version-for-riscv32.patch
@@ -0,0 +1,40 @@
+From 359dc12eb32b2395cf10796157002024e6a58054 Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Wed, 15 Dec 2021 23:31:11 -0800
+Subject: [PATCH] riscv: Set 5.4 as minimum kernel version for riscv32
+
+5.4 is first stable API as far as rv32 is concerned see [1]
+
+[1]
https://sourceware.org/git/?p=glibc.git;a=commit;h=7a55dd3fb6d2c307a002a16776be84310b9c8989
+
+Upstream-Status: Submitted
[https://lists.nongnu.org/archive/html/qemu-devel/2021-12/msg02495.html]
+
+Signed-off-by: Khem Raj
+Cc: Palmer Dabbelt
+Cc: Alistair Francis
+Cc: Bin Meng
+Signed-off-by: Matt Madison
+---
+ linux-user/riscv/target_syscall.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/linux-user/riscv/target_syscall.h
b/linux-user/riscv/target_syscall.h
+index dc597c897..9b1316132 100644
+--- a/linux-user/riscv/target_syscall.h
b/linux-user/riscv/target_syscall.h
+@@ -45,10 +45,11 @@ struct target_pt_regs {
+
+ #ifdef TARGET_RISCV32
+ #define UNAME_MACHINE "riscv32"
++#define UNAME_MINIMUM_RELEASE "5.4.0"
+ #else
+ #define UNAME_MACHINE "riscv64"
+-#endif
+ #define UNAME_MINIMUM_RELEASE "4.15.0"
++#endif
+
+ #define TARGET_MINSIGSTKSZ 2048
+ #define TARGET_MCL_CURRENT 1
+--
+2.32.0
+
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159783):
https://lists.openembedded.org/g/openembedded-core/message/159783
Mute This Topic: https://lists.openembedded.org/mt/87765280/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 1/2] qemu.bbclass: drop OLDEST_KERNEL reference
which is introducing task hash changes for some
allarch package builds, and should no longer
be needed with recent versions of qemu.
Signed-off-by: Matt Madison
---
meta/classes/qemu.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/qemu.bbclass b/meta/classes/qemu.bbclass
index 01a7b86ae1..333202b7c4 100644
--- a/meta/classes/qemu.bbclass
+++ b/meta/classes/qemu.bbclass
@@ -54,7 +54,7 @@ def qemu_run_binary(data, rootfs_path, binary):
# this dance). For others (e.g. arm) a -cpu option is not necessary, since the
# qemu-arm default CPU supports all required architecture levels.
-QEMU_OPTIONS = "-r ${OLDEST_KERNEL} ${@d.getVar("QEMU_EXTRAOPTIONS_%s" %
d.getVar('PACKAGE_ARCH')) or ""}"
+QEMU_OPTIONS = "${@d.getVar("QEMU_EXTRAOPTIONS_%s" % d.getVar('PACKAGE_ARCH'))
or ""}"
QEMU_OPTIONS[vardeps] += "QEMU_EXTRAOPTIONS_${PACKAGE_ARCH}"
QEMU_EXTRAOPTIONS_ppce500v2 = " -cpu e500v2"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159782):
https://lists.openembedded.org/g/openembedded-core/message/159782
Mute This Topic: https://lists.openembedded.org/mt/87765279/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][RFC PATCH v2] insane: Inappropriate patch reasoning
if a patch uses Upstream-Status: Inappropriate it should provide a machine
readable reasoning in square brackets.
According to latest wiki entry that would be
not author
native
licensing
configuration
enable feature
disable feature
bugfix .*
embedded specific
no upstream
other
a detailed reasoning could be provided as part of the commit message,
but format of the metadata line is fixed.
This patch adds a check to insane.bbclass and warns if there is a
non-compliant reasoning given, or none at all.
In a follow-up this should be turned into an error, as it was done
with missing Upstream-Status
Can be skipped with newly added patch-metadata key via INSANE_SKIP
Signed-off-by: Konrad Weihmann
---
v2: add possibility to skip with patch-metadata in INSANE_SKIP
meta/classes/insane.bbclass | 25 +
1 file changed, 25 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..eae8e0e549 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1124,6 +1124,8 @@ python do_qa_staging() {
python do_qa_patch() {
import subprocess
+skip = (d.getVar('INSANE_SKIP') or "").split()
+
###
# Check patch.log for fuzz warnings
#
@@ -1191,6 +1193,29 @@ python do_qa_patch() {
bb.error("Malformed Upstream-Status in patch\n%s\nPlease
correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
else:
bb.error("Missing Upstream-Status in patch\n%s\nPlease add
according to %s ." % (fullpath, guidelines))
+
+ if 'patch-metadata' in skip:
+ continue
+
+ inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
+ inappr_reasons = [
+'not author',
+'native',
+'licensing',
+'configuration',
+'enable feature',
+'disable feature',
+'bugfix .*',
+'embedded specific',
+'no upstream',
+'other',
+ ]
+ for match_inappr in re.finditer(inappr_message_re, content,
re.IGNORECASE | re.MULTILINE):
+
+ if 'reason' not in match_inappr.groupdict():
+ bb.warning("Missing Upstream-Status: Inappropriate reasoning in
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
+ elif not any(re.match(x, match_inappr.groupdict().get('reason', '')
or '') for x in inappr_reasons):
+ bb.warning("Malformed Upstream-Status: Inappropriate in
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines,
match_inappr.group(0)))
}
python do_qa_configure() {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159784):
https://lists.openembedded.org/g/openembedded-core/message/159784
Mute This Topic: https://lists.openembedded.org/mt/87765780/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] python3-idna: Drop from OE-Core
The only recipe mentioning python3-idna in OE-Core is python3-jsonschema.
python3-jsonschema only depends on it if the nongpl package config option
is set. We don't set this option.
The idna recipe has license issues with questions around the Unicode license
(still in meta-oe) and which version variant it should mean. We see QA warnings
in automated testing from this:
do_populate_lic: QA Issue: python3-idna: No generic license file exists for:
Unicode in any provider [license-exists]
Lets drop the recipe and if needed, it can be in meta-oe.
Signed-off-by: Richard Purdie
---
meta/conf/distro/include/maintainers.inc | 1 -
.../python/python3-idna_3.3.bb| 19 ---
2 files changed, 20 deletions(-)
delete mode 100644 meta/recipes-devtools/python/python3-idna_3.3.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 8e86ea45d2f..85d8a5396aa 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -605,7 +605,6 @@ RECIPE_MAINTAINER:pn-python3-extras = "Oleksandr Kravchuk
https://github.com/kjd/idna";
-LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
-LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
-
-SRC_URI[sha256sum] =
"9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
-
-inherit pypi setuptools3
-
-# Remove bundled egg-info
-do_compile:prepend() {
-rm -rf ${S}/idna.egg-info
-}
-
-RDEPENDS:${PN}:class-target = "\
-${PYTHON_PN}-codecs \
-"
-
-BBCLASSEXTEND = "native nativesdk"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159785):
https://lists.openembedded.org/g/openembedded-core/message/159785
Mute This Topic: https://lists.openembedded.org/mt/87766621/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][RFC PATCH v2 1/2] oe.lib.recipeutils: add get_layer_name method
On Wed, 2021-12-15 at 13:12 +0100, Konrad Weihmann wrote:
> so one can get the layer name from a filepath
>
> Signed-off-by: Konrad Weihmann
> ---
> v2: order by path length to correctly map nested layer
>
> meta/lib/oe/recipeutils.py | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
> index a0c6974f04..557e0f9bd5 100644
> --- a/meta/lib/oe/recipeutils.py
> +++ b/meta/lib/oe/recipeutils.py
> @@ -21,7 +21,7 @@ import glob
> import bb.tinfoil
>
> from collections import OrderedDict, defaultdict
> -from bb.utils import vercmp_string
> +from bb.utils import vercmp_string, get_collection_res
>
> # Help us to find places to insert values
> recipe_progression = ['SUMMARY', 'DESCRIPTION', 'AUTHOR', 'HOMEPAGE',
> 'BUGTRACKER', 'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM',
> 'PROVIDES', 'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S',
> 'do_fetch()', 'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE',
> 'EXTRA_OESCONS', 'do_configure()', 'EXTRA_OEMAKE', 'do_compile()',
> 'do_install()', 'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD',
> 'PACKAGES', 'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES',
> 'RREPLACES', 'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()',
> 'do_package()', 'do_deploy()', 'BBCLASSEXTEND']
> @@ -928,6 +928,15 @@ def find_layerdir(fn):
> return None
> return layerdir
>
> +def get_layer_name(fn, d):
> +""" Get the layer name from a filename """
> +pth = os.path.abspath(fn)
> +collection = get_collection_res(d)
> +# reverse ordering by length to catch nested layers
> +for k, v in dict(sorted(collection.items(), key=lambda item:
> len(item[1]), reverse=True)).items():
> +if re.match(v, pth):
> +return k
> +return ""
>
> def replace_dir_vars(path, d):
> """Replace common directory paths with appropriate variable references
> (e.g. /etc becomes ${sysconfdir})"""
I suspect we should add something in bb.utils for this? I also think we should
probably do this at the bitbake level entirely, i.e. set some kind of variable
to the layername rather than having lots of metadata code trying to do it,
potentially badly?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159786):
https://lists.openembedded.org/g/openembedded-core/message/159786
Mute This Topic: https://lists.openembedded.org/mt/87742384/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] cargo fetcher, SRCPV, and setscene issues
On Wed, Dec 15, 2021 at 8:16 AM Matt Madison wrote:
>
> I'm finding that none of the Rust recipes are getting setscened in my builds
> off
> master due to the the SRCPV hack that was added to make the cargo fetcher
> visible during parsing. There's no error reported about it, but by adding an
> exception handler into the sstate code I tracked it down to pstaging_fetch()'s
> using d.getVar('SRCPV'). Since the cargo fetcher doesn't advertise
> srcrev support,
> the base fetcher class raises an exception on this, causing the
> mostly-silent failure.
Hmm, this is strange. I have this recipe:
https://github.com/JPEWdev/meta-phosh/blob/master/recipes-graphics/squeekboard/squeekboard_git.bb
that is using the cargo fetcher and it is definitely using sstate like
I would expect; perhaps there is some other strange interaction with
another class?
>
> There's no issue if the sstate package is already in the local cache;
> it only affects
> builds where I need to fetch from my sstate mirror.
>
> I'd submit a patch, but I'm not sure what the right solution would be.
>
> Regards,
> -Matt
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159787):
https://lists.openembedded.org/g/openembedded-core/message/159787
Mute This Topic: https://lists.openembedded.org/mt/87744591/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.13.rc1)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.13.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion next Monday, Dec 20. Thanks, Jay >-Original Message- >From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Richard Purdie >Sent: Wednesday, 15 December, 2021 3:40 PM >To: >Cc: qa-build-notification >Subject: [qa-build-notification] QA notification for completed autobuilder >build >(yocto-3.1.13.rc1) > >A build flagged for QA (yocto-3.1.13.rc1) was completed on the autobuilder and >is >available at: > > >https://autobuilder.yocto.io/pub/releases/yocto-3.1.13.rc1 > > >Build hash information: > >bitbake: f18b65d0b9a6b983d53bde491e1bf2ca56949444 >meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559 >meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c >meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319 >meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac >meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82 >meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 >meta-openembedded: 69f94af4d91215e7d4e225bab54bf3bcfee42f1c >oecore: 90a07178ea26be453d101c2e8b33d3a0f437635d >poky: 795339092f87672e4f68e4d3bc4cfd0e252d1831 > > > >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 (#159788): https://lists.openembedded.org/g/openembedded-core/message/159788 Mute This Topic: https://lists.openembedded.org/mt/87768099/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [honister][PATCH 00/17] Pull request
Please merge these changes.
Thanks,
Anuj
The following changes since commit b8fa0c446ecb3f65d7c134426a07c6244959cdf7:
libdrm: upgrade 2.4.108 -> 2.4.109 (2021-12-09 09:17:26 +0800)
are available in the Git repository at:
git://push.openembedded.org/openembedded-core-contrib stable/honister-next
Anuj Mittal (1):
python3: upgrade 3.9.7 -> 3.9.9
Bruce Ashfield (4):
linux-yocto/5.14: update to v5.14.21
linux-yocto/5.10: update to v5.10.82
linux-yocto-rt/5.10: update to -rt56
kern-tools: bug fixes and kgit-gconfig
Changqing Li (1):
openssh: fix CVE-2021-41617
Mingli Yu (3):
ncurses: fix CVE-2021-39537
bind: fix CVE-2021-25219
packagedata.py: silence a DeprecationWarning
Richard Purdie (1):
gcc: Add CVE-2021-37322 to the list of CVEs to ignore
Ross Burton (3):
runqemu: check the qemu PID has been set before kill()ing it
oe/license: implement ast.NodeVisitor.visit_Constant
license.bbclass: implement ast.NodeVisitor.visit_Constant
Stefan Herbrechtsmeier (2):
recipetool: Set master branch only as fallback
selftest/devtool: Check branch in git fetch
Steve Sakoman (1):
cve-extra-exclusions: add db CVEs to exclusion list
Thomas Perrot (1):
uboot-sign: fix the concatenation when multiple U-BOOT configurations
are specified
meta/classes/license.bbclass | 4 +
meta/classes/uboot-sign.bbclass | 16 +++-
.../distro/include/cve-extra-exclusions.inc | 9 ++-
meta/lib/oe/license.py| 6 ++
meta/lib/oe/packagedata.py| 2 +-
meta/lib/oeqa/selftest/cases/devtool.py | 5 +-
.../bind/bind-9.16.20/CVE-2021-25219-1.patch | 76 +++
.../bind/bind-9.16.20/CVE-2021-25219-2.patch | 65
.../recipes-connectivity/bind/bind_9.16.20.bb | 2 +
.../openssh/openssh/CVE-2021-41617.patch | 48
.../openssh/openssh_8.7p1.bb | 1 +
.../ncurses/files/CVE-2021-39537.patch| 65
meta/recipes-core/ncurses/ncurses_6.2.bb | 1 +
meta/recipes-devtools/gcc/gcc-11.2.inc| 3 +
...-detection-of-mips-architecture-for-.patch | 20 +++--
.../{python3_3.9.7.bb => python3_3.9.9.bb}| 2 +-
.../kern-tools/kern-tools-native_git.bb | 5 +-
.../linux/linux-yocto-rt_5.10.bb | 6 +-
.../linux/linux-yocto-rt_5.14.bb | 6 +-
.../linux/linux-yocto-tiny_5.10.bb| 8 +-
.../linux/linux-yocto-tiny_5.14.bb| 8 +-
meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 +++---
meta/recipes-kernel/linux/linux-yocto_5.14.bb | 26 +++
scripts/lib/recipetool/create.py | 15 ++--
scripts/runqemu | 3 +-
25 files changed, 358 insertions(+), 68 deletions(-)
create mode 100644
meta/recipes-connectivity/bind/bind-9.16.20/CVE-2021-25219-1.patch
create mode 100644
meta/recipes-connectivity/bind/bind-9.16.20/CVE-2021-25219-2.patch
create mode 100644
meta/recipes-connectivity/openssh/openssh/CVE-2021-41617.patch
create mode 100644 meta/recipes-core/ncurses/files/CVE-2021-39537.patch
rename meta/recipes-devtools/python/{python3_3.9.7.bb => python3_3.9.9.bb}
(99%)
--
2.33.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159789):
https://lists.openembedded.org/g/openembedded-core/message/159789
Mute This Topic: https://lists.openembedded.org/mt/87768120/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][RFC PATCH v2 1/2] oe.lib.recipeutils: add get_layer_name method
On 16.12.21 15:41, Richard Purdie wrote:
On Wed, 2021-12-15 at 13:12 +0100, Konrad Weihmann wrote:
so one can get the layer name from a filepath
Signed-off-by: Konrad Weihmann
---
v2: order by path length to correctly map nested layer
meta/lib/oe/recipeutils.py | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oe/recipeutils.py b/meta/lib/oe/recipeutils.py
index a0c6974f04..557e0f9bd5 100644
--- a/meta/lib/oe/recipeutils.py
+++ b/meta/lib/oe/recipeutils.py
@@ -21,7 +21,7 @@ import glob
import bb.tinfoil
from collections import OrderedDict, defaultdict
-from bb.utils import vercmp_string
+from bb.utils import vercmp_string, get_collection_res
# Help us to find places to insert values
recipe_progression = ['SUMMARY', 'DESCRIPTION', 'AUTHOR', 'HOMEPAGE',
'BUGTRACKER', 'SECTION', 'LICENSE', 'LICENSE_FLAGS', 'LIC_FILES_CHKSUM',
'PROVIDES', 'DEPENDS', 'PR', 'PV', 'SRCREV', 'SRCPV', 'SRC_URI', 'S',
'do_fetch()', 'do_unpack()', 'do_patch()', 'EXTRA_OECONF', 'EXTRA_OECMAKE',
'EXTRA_OESCONS', 'do_configure()', 'EXTRA_OEMAKE', 'do_compile()',
'do_install()', 'do_populate_sysroot()', 'INITSCRIPT', 'USERADD', 'GROUPADD',
'PACKAGES', 'FILES', 'RDEPENDS', 'RRECOMMENDS', 'RSUGGESTS', 'RPROVIDES',
'RREPLACES', 'RCONFLICTS', 'ALLOW_EMPTY', 'populate_packages()',
'do_package()', 'do_deploy()', 'BBCLASSEXTEND']
@@ -928,6 +928,15 @@ def find_layerdir(fn):
return None
return layerdir
+def get_layer_name(fn, d):
+""" Get the layer name from a filename """
+pth = os.path.abspath(fn)
+collection = get_collection_res(d)
+# reverse ordering by length to catch nested layers
+for k, v in dict(sorted(collection.items(), key=lambda item: len(item[1]),
reverse=True)).items():
+if re.match(v, pth):
+return k
+return ""
def replace_dir_vars(path, d):
"""Replace common directory paths with appropriate variable references (e.g. /etc
becomes ${sysconfdir})"""
I suspect we should add something in bb.utils for this? I also think we should
probably do this at the bitbake level entirely, i.e. set some kind of variable
to the layername rather than having lots of metadata code trying to do it,
potentially badly?
That would indeed make sense, in the end the could be easily moved to
bitbake - not sure about the variable per layer as we have already
BBFILE_PATTERN and BBCOLLECTION (both used here indirectly) and what I
wanted to have is a way to ask from what layer a particular file
originates. In the current form it's pretty straight forward as it
doesn't mind overloads from layers (and therefore no layer priority or
order from bblayers.conf) - I'm not sure how complicated we would like
something like this to be - so for now I would be fine if we take this
piece, add something fully featured in bitbake and then removed this one
here
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159790):
https://lists.openembedded.org/g/openembedded-core/message/159790
Mute This Topic: https://lists.openembedded.org/mt/87742384/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][RFC PATCH v2] insane: Inappropriate patch reasoning
On Thu, 2021-12-16 at 13:26 +0100, Konrad Weihmann wrote:
> if a patch uses Upstream-Status: Inappropriate it should provide a machine
> readable reasoning in square brackets.
>
> According to latest wiki entry that would be
>
> not author
> native
> licensing
> configuration
> enable feature
> disable feature
> bugfix .*
> embedded specific
> no upstream
> other
>
> a detailed reasoning could be provided as part of the commit message,
> but format of the metadata line is fixed.
>
> This patch adds a check to insane.bbclass and warns if there is a
> non-compliant reasoning given, or none at all.
>
> In a follow-up this should be turned into an error, as it was done
> with missing Upstream-Status
>
> Can be skipped with newly added patch-metadata key via INSANE_SKIP
>
> Signed-off-by: Konrad Weihmann
> ---
> v2: add possibility to skip with patch-metadata in INSANE_SKIP
>
> meta/classes/insane.bbclass | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 240f3aad62..eae8e0e549 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -1124,6 +1124,8 @@ python do_qa_staging() {
> python do_qa_patch() {
> import subprocess
>
> +skip = (d.getVar('INSANE_SKIP') or "").split()
> +
>
> ###
> # Check patch.log for fuzz warnings
> #
> @@ -1191,6 +1193,29 @@ python do_qa_patch() {
> bb.error("Malformed Upstream-Status in patch\n%s\nPlease
> correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
> else:
> bb.error("Missing Upstream-Status in patch\n%s\nPlease add
> according to %s ." % (fullpath, guidelines))
> +
> + if 'patch-metadata' in skip:
> + continue
> +
> + inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
> + inappr_reasons = [
> +'not author',
> +'native',
> +'licensing',
> +'configuration',
> +'enable feature',
> +'disable feature',
> +'bugfix .*',
> +'embedded specific',
> +'no upstream',
> +'other',
> + ]
> + for match_inappr in re.finditer(inappr_message_re, content,
> re.IGNORECASE | re.MULTILINE):
> +
> + if 'reason' not in match_inappr.groupdict():
> + bb.warning("Missing Upstream-Status: Inappropriate reasoning
> in patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
> + elif not any(re.match(x, match_inappr.groupdict().get('reason',
> '') or '') for x in inappr_reasons):
> + bb.warning("Malformed Upstream-Status: Inappropriate in
> patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines,
> match_inappr.group(0)))
> }
>
> python do_qa_configure() {
I appreciate the intent here but I think there are details we need to look at
first.
Whilst this list of inappropriate reasons looks like a good start, I'm not sure
it is exactly the list of things we want to encourage people to mark patches
with. The wiki was written a long time ago and I think we want to make sure it
is right before we go through the work of classifying a large number of patches.
I'm very much in favour of an approach which looks at actions we could take
based upon a given classification.
I'm also worried we actually lose information with any "forced" transition like
this. There may be links to discussion in the current [] field and I'd much
rather keep those links that force people into changing them and them being
lost. Common sense says people would move them to the patch description but that
isn't any guarantee that it would happen.
Also, this isn't really how we go about making transitions like this. Usually
we'd make some decision about a direction and then we'd migrate to it over time.
This patch will start generating hundreds of warnings on the autobuilder to the
point that all warnings would become meaningless. Currently it operates mostly
warning free and where we do hit them, usually intermittently, we get them
fixed. Once things start to fail, they "rot" quickly as one warning turns into
many more unnoticed.
In some ways I'd prefer we add a new field, something other than Inappropriate
and then over time we could classify patches. We'd use the approach we're using
with Pending where we gradually encourage movement over time.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159791):
https://lists.openembedded.org/g/openembedded-core/message/159791
Mute This Topic: https://lists.openembedded.org/mt/87765780/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/3] support Android target in all build system
On Thu, 2021-12-16 at 18:38 +0800, Hsia-Jun Li wrote: > From: "Hsia-Jun(Randy) Li" > > Both meson and cmake would work fine, left those GNU autotools, > customer script projects. > > The behaviour of meson would become that as the following for > the Android target: > lib/libfoo.so is the real binary library > lib/libfoo.so.x -> libfoo.so > lib/libfoo.so.x.y -> libfoo.so > > But when you tell the autotools the target host is android, > it won't make any difference in its output library. I would > like to fix that but I am not good at m4 script. > > Hsia-Jun(Randy) Li (3): > cmake.bbclass: support android os > classes/meson: support Android os > [WIP]: openssl: fix Android target The first couple of patches look ok but I'd like to understand whether there is real world usable output from the build after applying them? If not, I think we should probably wait until we can see the bigger picture of what other changes would be needed to make this work rather than making tweaks piecemeal. Can you describe what level of functionality these patches give to a build? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159792): https://lists.openembedded.org/g/openembedded-core/message/159792 Mute This Topic: https://lists.openembedded.org/mt/87764530/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 4/4] core: udev: udev-extraconf: rename mount.blacklist* to mount.blocklist.*
On 12/8/21 01:57, Eero Aaltonen wrote: On Mon, 2021-12-06 at 23:31 +, Richard Purdie via lists.openembedded.org wrote: On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote: blocklist has a more obvious meaning than blacklist and is also not an issue wrt inclusivity, so let's use that naming instead. A "blocklist" with a filesystem is unfortunately confusing (a list of block numbers on the filesystem?). "ignorelist" or even "ignore-devices" may be better? (or skip) I offer "denylist". I have recently added a list of patches and files that have problematic language to the Inclusive Language Wiki [0], this is one of them, I had proposed mount.disallow So we can see that everyone has a different idea. Once we have an approved rename, we can revisit this patch. Thanks Sau! [0] https://wiki.yoctoproject.org/wiki/Inclusive_language#Patch_Files Cheers, Eero -- Sau! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159793): https://lists.openembedded.org/g/openembedded-core/message/159793 Mute This Topic: https://lists.openembedded.org/mt/87542276/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][RFC PATCH v2] insane: Inappropriate patch reasoning
On 16.12.21 15:54, Richard Purdie wrote:
On Thu, 2021-12-16 at 13:26 +0100, Konrad Weihmann wrote:
if a patch uses Upstream-Status: Inappropriate it should provide a machine
readable reasoning in square brackets.
According to latest wiki entry that would be
not author
native
licensing
configuration
enable feature
disable feature
bugfix .*
embedded specific
no upstream
other
a detailed reasoning could be provided as part of the commit message,
but format of the metadata line is fixed.
This patch adds a check to insane.bbclass and warns if there is a
non-compliant reasoning given, or none at all.
In a follow-up this should be turned into an error, as it was done
with missing Upstream-Status
Can be skipped with newly added patch-metadata key via INSANE_SKIP
Signed-off-by: Konrad Weihmann
---
v2: add possibility to skip with patch-metadata in INSANE_SKIP
meta/classes/insane.bbclass | 25 +
1 file changed, 25 insertions(+)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..eae8e0e549 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1124,6 +1124,8 @@ python do_qa_staging() {
python do_qa_patch() {
import subprocess
+skip = (d.getVar('INSANE_SKIP') or "").split()
+
###
# Check patch.log for fuzz warnings
#
@@ -1191,6 +1193,29 @@ python do_qa_patch() {
bb.error("Malformed Upstream-Status in patch\n%s\nPlease correct
according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
else:
bb.error("Missing Upstream-Status in patch\n%s\nPlease add
according to %s ." % (fullpath, guidelines))
+
+ if 'patch-metadata' in skip:
+ continue
+
+ inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
+ inappr_reasons = [
+'not author',
+'native',
+'licensing',
+'configuration',
+'enable feature',
+'disable feature',
+'bugfix .*',
+'embedded specific',
+'no upstream',
+'other',
+ ]
+ for match_inappr in re.finditer(inappr_message_re, content,
re.IGNORECASE | re.MULTILINE):
+
+ if 'reason' not in match_inappr.groupdict():
+ bb.warning("Missing Upstream-Status: Inappropriate reasoning in
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
+ elif not any(re.match(x, match_inappr.groupdict().get('reason', '')
or '') for x in inappr_reasons):
+ bb.warning("Malformed Upstream-Status: Inappropriate in
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines,
match_inappr.group(0)))
}
python do_qa_configure() {
I appreciate the intent here but I think there are details we need to look at
first.
Whilst this list of inappropriate reasons looks like a good start, I'm not sure
it is exactly the list of things we want to encourage people to mark patches
with. The wiki was written a long time ago and I think we want to make sure it
is right before we go through the work of classifying a large number of patches.
I'm very much in favour of an approach which looks at actions we could take
based upon a given classification.
I'm also worried we actually lose information with any "forced" transition like
this. There may be links to discussion in the current [] field and I'd much
rather keep those links that force people into changing them and them being
lost. Common sense says people would move them to the patch description but that
isn't any guarantee that it would happen.
Also, this isn't really how we go about making transitions like this. Usually
we'd make some decision about a direction and then we'd migrate to it over time.
This patch will start generating hundreds of warnings on the autobuilder to the
point that all warnings would become meaningless. Currently it operates mostly
warning free and where we do hit them, usually intermittently, we get them
fixed. Once things start to fail, they "rot" quickly as one warning turns into
many more unnoticed.
In some ways I'd prefer we add a new field, something other than Inappropriate
and then over time we could classify patches. We'd use the approach we're using
with Pending where we gradually encourage movement over time.
Cheers,
Richard
Fine - I'm also in favor of a transition phase - I just wanted to
highlight that Inappropriate lost almost all of its meaning as the grep
output from an earlier mail showed.
One thing I could think about is to at least flag the patch that doesn't
even provide a reasoning.
At this point we could do the very same for core as for the
Upstream-Status and do a hard error when not even a one is given.
Then in a second round fix all the misspellings - and maybe rethink the
way the classification is done -- any I'm fully with you -- find
Re: [OE-core] cargo fetcher, SRCPV, and setscene issues
On Thu, Dec 16, 2021 at 6:47 AM Joshua Watt wrote:
>
> On Wed, Dec 15, 2021 at 8:16 AM Matt Madison wrote:
> >
> > I'm finding that none of the Rust recipes are getting setscened in my
> > builds off
> > master due to the the SRCPV hack that was added to make the cargo fetcher
> > visible during parsing. There's no error reported about it, but by adding an
> > exception handler into the sstate code I tracked it down to
> > pstaging_fetch()'s
> > using d.getVar('SRCPV'). Since the cargo fetcher doesn't advertise
> > srcrev support,
> > the base fetcher class raises an exception on this, causing the
> > mostly-silent failure.
>
> Hmm, this is strange. I have this recipe:
> https://github.com/JPEWdev/meta-phosh/blob/master/recipes-graphics/squeekboard/squeekboard_git.bb
> that is using the cargo fetcher and it is definitely using sstate like
> I would expect; perhaps there is some other strange interaction with
> another class?
I'm just talking about the rust toolchain, libstd-rs, cargo, etc.
It's simple enough for me to reproduce with a bare-bones setup:
1. clone openembedded-core and bitbake
2. init build environment
3. set MACHINE="qemuarm64" in local.conf
4. bitbake librsvg
5. Copy sstate-cache contents to a web server
6. Wipe build workspace, re-init, and set SSTATE_MIRRORS to point to
the web server
7. bitbake --setscene-only librsvg
I've attached the cooker log of a sample build. You'll see from the
sstate summary that everything was found, but there will be warnings
when executing the setscenes.
-Matt
>
> >
> > There's no issue if the sstate package is already in the local cache;
> > it only affects
> > builds where I need to fetch from my sstate mirror.
> >
> > I'd submit a patch, but I'm not sure what the right solution would be.
> >
> > Regards,
> > -Matt
> >
> >
> >
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.53.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "ubuntu-21.10"
TARGET_SYS = "aarch64-oe-linux"
MACHINE = "qemuarm64"
DISTRO = "nodistro"
DISTRO_VERSION = "nodistro.0"
TUNE_FEATURES= "aarch64 armv8a crc cortexa57"
TARGET_FPU = ""
meta = "qemu-patch:c2da77c6aa63b26b5b7ea9fdc749b6009820f1f1"
Sstate summary: Wanted 427 Local 0 Mirrors 427 Missed 0 Current 0 (100% match, 0% complete)
NOTE: Executing Tasks
NOTE: Running setscene task 1 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/librsvg/librsvg_2.52.4.bb:do_package_qa_setscene)
NOTE: Running setscene task 2 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/librsvg/librsvg_2.52.4.bb:do_package_write_ipk_setscene)
NOTE: Running setscene task 3 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/librsvg/librsvg_2.52.4.bb:do_populate_lic_setscene)
NOTE: Running setscene task 4 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/librsvg/librsvg_2.52.4.bb:do_populate_sysroot_setscene)
NOTE: Running setscene task 5 of 427 (virtual:native:/build/madison/openembedded-core/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot_setscene)
NOTE: recipe librsvg-2.52.4-r0: task do_package_qa_setscene: Started
NOTE: recipe librsvg-2.52.4-r0: task do_package_write_ipk_setscene: Started
NOTE: recipe librsvg-2.52.4-r0: task do_populate_lic_setscene: Started
NOTE: recipe librsvg-2.52.4-r0: task do_populate_sysroot_setscene: Started
NOTE: recipe pseudo-native-1.9.0+gitAUTOINC+d34f2f6ced-r0: task do_populate_sysroot_setscene: Started
NOTE: recipe pseudo-native-1.9.0+gitAUTOINC+d34f2f6ced-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: recipe librsvg-2.52.4-r0: task do_package_qa_setscene: Succeeded
NOTE: recipe librsvg-2.52.4-r0: task do_populate_lic_setscene: Succeeded
NOTE: recipe librsvg-2.52.4-r0: task do_package_write_ipk_setscene: Succeeded
NOTE: Running setscene task 7 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/librsvg/librsvg_2.52.4.bb:do_packagedata_setscene)
NOTE: Running setscene task 8 of 427 (virtual:native:/build/madison/openembedded-core/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb:do_populate_sysroot_setscene)
NOTE: recipe librsvg-2.52.4-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: recipe librsvg-2.52.4-r0: task do_packagedata_setscene: Started
NOTE: recipe opkg-utils-native-0.5.0-r0: task do_populate_sysroot_setscene: Started
NOTE: recipe opkg-utils-native-0.5.0-r0: task do_populate_sysroot_setscene: Succeeded
NOTE: recipe librsvg-2.52.4-r0: task do_packagedata_setscene: Succeeded
NOTE: Running setscene task 11 of 427 (/build/madison/openembedded-core/meta/recipes-devtools/rust/libstd-rs_1.57.0.bb:do_packagedata_setscene)
NOTE: Running setscene task 12 of 427 (/build/madison/openembedded-core/meta/recipes-devtools/rust/libstd-rs_1.57.0.bb:do_populate_sysroot_setscene)
NOTE: Running setscene task 13 of 427 (/build/madison/openembedded-core/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.6.bb:do_packageda
[OE-core] [PATCH] python3-pyelftools: Depend on debugger, pprint
python3-pyelftools uses python3-debugger, python3-pprint.
So add dependencies on these packages.
Signed-off-by: Chaitanya Vadrevu
---
meta/recipes-devtools/python/python3-pyelftools_0.27.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
index 0cfd99504b..f8b9d420a5 100644
--- a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
+++ b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
@@ -11,3 +11,5 @@ PYPI_PACKAGE = "pyelftools"
inherit pypi setuptools3
BBCLASSEXTEND = "native"
+
+RDEPENDS_${PN} += "${PYTHON_PN}-debugger ${PYTHON_PN}-pprint"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159796):
https://lists.openembedded.org/g/openembedded-core/message/159796
Mute This Topic: https://lists.openembedded.org/mt/87771402/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 18/26] boost: update 1.77.0 -> 1.78.0
On Thu, Dec 16, 2021 at 12:29 AM Alexander Kanavin
wrote:
>
> On Thu, 16 Dec 2021 at 00:28, Khem Raj wrote:
>>
>> > Drop 0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch as
>> > it is difficult to rebase and needs to land upstream first.
>>
>> It's not that rebasing is too hard for this patch but this patch is an
>> incorrect way to fix what it's trying to solve and that's why I am
>> fine with dropping it.
>> landing upstream is not a precondition for submitting patches to
>> OpenEmbedded but good to have. All distributions carry patches and as
>> long as patches are working
>> their way upstream asynchronously its ok. Let's not make it too hard
>> for contributors and chase them away.
>
>
> Yes, rather than 'land upstream' I should've said 'submitted upstream' - that
> patch is dated 16 October 2020, and it never happened. While myself and
> everyone else enormously appreciate your toolchain and target work, there's a
> problem with amassing invasive pending patches related to that: no one except
> you truly understands them. So what I'm asking is just a bit more rigor going
> forward: submit patches upstream at the same time you submit them to core,
> and steadily work your way towards reducing the pile that's already there.
>
you are preaching to the choir :) However new patches will be required
as the packages are upgraded/updates, lot of upstream
do not support/test architectures that OE supports ( which is one of
USPs of OE ) so its bound to happen that something will regress for OE
and we have to patch it.
and we do not have developer strength like other distributions. By not
being accepting of this situation, we are effectively making it hard
for OE to be used on such architectures
which are either new or specific and they could be the reason for OE
to thrive in the future. There is a fine line to tread here.
> Alex
>
>
>>
>>
>> >
>> > Signed-off-by: Alexander Kanavin
>> > ---
>> > .../{boost-1.77.0.inc => boost-1.78.0.inc}| 2 +-
>> > cmake-allow-searching-for-python310.patch | 50 --
>> > ...h-instruction-set-flags-we-do-that-o.patch | 15 +-
>> > ...efine-SYS_futex-if-it-does-not-exist.patch | 54 ---
>> > ...th_no_atomic_int-on-the-command-line.patch | 53 --
>> > ...oft-failure-in-bernoulli_details_hpp.patch | 151 --
>> > ...7e01635306085488290ea83de541ec393f8b.patch | 30
>> > meta/recipes-support/boost/boost_1.77.0.bb| 12 --
>> > meta/recipes-support/boost/boost_1.78.0.bb| 9 ++
>> > 9 files changed, 50 insertions(+), 326 deletions(-)
>> > rename meta/recipes-support/boost/{boost-1.77.0.inc => boost-1.78.0.inc}
>> > (90%)
>> > delete mode 100644
>> > meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
>> > delete mode 100644
>> > meta/recipes-support/boost/boost/0001-fiber-libs-Define-SYS_futex-if-it-does-not-exist.patch
>> > delete mode 100644
>> > meta/recipes-support/boost/boost/0002-math-allow-definition-of-boost_math_no_atomic_int-on-the-command-line.patch
>> > delete mode 100644
>> > meta/recipes-support/boost/boost/0003-math-make-no-atomics-a-soft-failure-in-bernoulli_details_hpp.patch
>> > create mode 100644
>> > meta/recipes-support/boost/boost/de657e01635306085488290ea83de541ec393f8b.patch
>> > delete mode 100644 meta/recipes-support/boost/boost_1.77.0.bb
>> > create mode 100644 meta/recipes-support/boost/boost_1.78.0.bb
>> >
>> > diff --git a/meta/recipes-support/boost/boost-1.77.0.inc
>> > b/meta/recipes-support/boost/boost-1.78.0.inc
>> > similarity index 90%
>> > rename from meta/recipes-support/boost/boost-1.77.0.inc
>> > rename to meta/recipes-support/boost/boost-1.78.0.inc
>> > index 6df06e76c7..729a47b54f 100644
>> > --- a/meta/recipes-support/boost/boost-1.77.0.inc
>> > +++ b/meta/recipes-support/boost/boost-1.78.0.inc
>> > @@ -12,7 +12,7 @@ BOOST_MAJ =
>> > "${@"_".join(d.getVar("PV").split(".")[0:2])}"
>> > BOOST_P = "boost_${BOOST_VER}"
>> >
>> > SRC_URI =
>> > "https://boostorg.jfrog.io/artifactory/main/release/${PV}/source/${BOOST_P}.tar.bz2";
>> > -SRC_URI[sha256sum] =
>> > "fc9f85fc030e233142908241af7a846e60630aa7388de9a5fafb1f3a26840854"
>> > +SRC_URI[sha256sum] =
>> > "8681f175d4bdb26c5665793eef08490d7758529330f98d3b29dd0735bccc"
>> >
>> > UPSTREAM_CHECK_URI = "http://www.boost.org/users/download/";
>> > UPSTREAM_CHECK_REGEX = "release/(?P.*)/source/"
>> > diff --git
>> > a/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
>> >
>> > b/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
>> > deleted file mode 100644
>> > index 0a9ee2cc95..00
>> > ---
>> > a/meta/recipes-support/boost/boost/0001-BoostConfig.cmake-allow-searching-for-python310.patch
>> > +++ /dev/null
>> > @@ -1,50 +0,0 @@
>> > -From e193f080c7d209516ac9b712fa0c50bb08026fa2 Mon Sep 17 00:00:00 2001
>> > -From: Martin Jansa
>> > -Date: Tue, 19 Oct 2021 12:24
Re: [OE-core] cargo fetcher, SRCPV, and setscene issues
On Thu, Dec 16, 2021 at 7:53 AM Matt Madison via
lists.openembedded.org
wrote:
>
> On Thu, Dec 16, 2021 at 6:47 AM Joshua Watt wrote:
> >
> > On Wed, Dec 15, 2021 at 8:16 AM Matt Madison wrote:
> > >
> > > I'm finding that none of the Rust recipes are getting setscened in my
> > > builds off
> > > master due to the the SRCPV hack that was added to make the cargo fetcher
> > > visible during parsing. There's no error reported about it, but by adding
> > > an
> > > exception handler into the sstate code I tracked it down to
> > > pstaging_fetch()'s
> > > using d.getVar('SRCPV'). Since the cargo fetcher doesn't advertise
> > > srcrev support,
> > > the base fetcher class raises an exception on this, causing the
> > > mostly-silent failure.
> >
> > Hmm, this is strange. I have this recipe:
> > https://github.com/JPEWdev/meta-phosh/blob/master/recipes-graphics/squeekboard/squeekboard_git.bb
> > that is using the cargo fetcher and it is definitely using sstate like
> > I would expect; perhaps there is some other strange interaction with
> > another class?
>
> I'm just talking about the rust toolchain, libstd-rs, cargo, etc.
> It's simple enough for me to reproduce with a bare-bones setup:
>
> 1. clone openembedded-core and bitbake
> 2. init build environment
> 3. set MACHINE="qemuarm64" in local.conf
> 4. bitbake librsvg
> 5. Copy sstate-cache contents to a web server
> 6. Wipe build workspace, re-init, and set SSTATE_MIRRORS to point to
> the web server
> 7. bitbake --setscene-only librsvg
>
> I've attached the cooker log of a sample build. You'll see from the
> sstate summary that everything was found, but there will be warnings
> when executing the setscenes.
And if I apply the following patch:
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 0326d27c74..ffc3b08b7d 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -761,7 +761,12 @@ def pstaging_fetch(sstatefetch, d):
localdata.setVar('FILESPATH', dldir)
localdata.setVar('DL_DIR', dldir)
localdata.setVar('PREMIRRORS', mirrors)
-localdata.setVar('SRCPV', d.getVar('SRCPV'))
+try:
+curpv = d.getVar('SRCPV')
+except Exception as e:
+bb.warn("Failed to get SRCPV: %s" % e)
+curpv = ''
+localdata.setVar('SRCPV', curpv)
the setscenes work, and the warning is:
WARNING: libstd-rs-1.57.0-r0 do_packagedata_setscene: Failed to get
SRCPV: Failure expanding variable SRCPV, expression was
${@crate_get_srcrev(d)} which triggered exception FetchError: Fetcher
failure: SRCREV was used yet no valid SCM was found in SRC_URI
The variable dependency chain for the failure is: SRCPV
I'm just not sure whether that's the right place to fix this.
-M
>
> -Matt
>
> >
> > >
> > > There's no issue if the sstate package is already in the local cache;
> > > it only affects
> > > builds where I need to fetch from my sstate mirror.
> > >
> > > I'd submit a patch, but I'm not sure what the right solution would be.
> > >
> > > Regards,
> > > -Matt
> > >
> > >
> > >
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159798):
https://lists.openembedded.org/g/openembedded-core/message/159798
Mute This Topic: https://lists.openembedded.org/mt/87744591/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 4/4] core: udev: udev-extraconf: rename mount.blacklist* to mount.blocklist.*
Hi all, On December 16, 2021 4:03:14 PM GMT+01:00, Saul Wold wrote: > > >On 12/8/21 01:57, Eero Aaltonen wrote: >> On Mon, 2021-12-06 at 23:31 +, Richard Purdie via >> lists.openembedded.org wrote: >>> On Mon, 2021-12-06 at 16:35 +0100, Quentin Schulz wrote: blocklist has a more obvious meaning than blacklist and is also not an issue wrt inclusivity, so let's use that naming instead. >>> >>> A "blocklist" with a filesystem is unfortunately confusing (a list of >>> block >>> numbers on the filesystem?). "ignorelist" or even "ignore-devices" >>> may be >>> better? (or skip) >> >> I offer "denylist". >> >I have recently added a list of patches and files that have problematic >language to the Inclusive Language Wiki [0], this is one of them, I had >proposed mount.disallow > >So we can see that everyone has a different idea. Once we have an >approved rename, we can revisit this patch. > I'm lagging behind a bit sorry. I'd suggest to rename mount.blacklist to automount.something. I find it more explicit that just mount with ignore, deny or disallow as "extension" as suggested before. If I haven't sent a V2 by Saturday, feel free anyone to rework this patch if you want as I won't have much time before next year. Cheers, Quentin >Thanks > >Sau! > >[0] https://wiki.yoctoproject.org/wiki/Inclusive_language#Patch_Files > > >> Cheers, >> Eero >> >> >> >> >> > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159799): https://lists.openembedded.org/g/openembedded-core/message/159799 Mute This Topic: https://lists.openembedded.org/mt/87542276/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] python3-idna: Drop from OE-Core
Hi Richard,
On December 16, 2021 2:22:18 PM GMT+01:00, Richard Purdie
wrote:
>The only recipe mentioning python3-idna in OE-Core is python3-jsonschema.
>python3-jsonschema only depends on it if the nongpl package config option
>is set. We don't set this option.
>
That is unfortunately incorrect, it is also part of the format PACKAGECONFIG
which is by default included.
>The idna recipe has license issues with questions around the Unicode license
>(still in meta-oe) and which version variant it should mean. We see QA warnings
>in automated testing from this:
>
I still shall open an issue on the GitHub tracker of the project to raise this.
Cheers,
Quentin
>do_populate_lic: QA Issue: python3-idna: No generic license file exists for:
>Unicode in any provider [license-exists]
>
>Lets drop the recipe and if needed, it can be in meta-oe.
>
>Signed-off-by: Richard Purdie
>---
> meta/conf/distro/include/maintainers.inc | 1 -
> .../python/python3-idna_3.3.bb| 19 ---
> 2 files changed, 20 deletions(-)
> delete mode 100644 meta/recipes-devtools/python/python3-idna_3.3.bb
>
>diff --git a/meta/conf/distro/include/maintainers.inc
>b/meta/conf/distro/include/maintainers.inc
>index 8e86ea45d2f..85d8a5396aa 100644
>--- a/meta/conf/distro/include/maintainers.inc
>+++ b/meta/conf/distro/include/maintainers.inc
>@@ -605,7 +605,6 @@ RECIPE_MAINTAINER:pn-python3-extras = "Oleksandr Kravchuk
> RECIPE_MAINTAINER:pn-python3-git = "Oleksandr Kravchuk
> "
> RECIPE_MAINTAINER:pn-python3-gitdb = "Oleksandr Kravchuk
> "
> RECIPE_MAINTAINER:pn-python3-hypothesis = "Tim Orling
> "
>-RECIPE_MAINTAINER:pn-python3-idna = "Bruce Ashfield
>"
> RECIPE_MAINTAINER:pn-python3-importlib-metadata = "Tim Orling
> "
> RECIPE_MAINTAINER:pn-python3-iniconfig = "Tim Orling
> "
> RECIPE_MAINTAINER:pn-python3-iniparse = "Oleksandr Kravchuk
> "
>diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb
>b/meta/recipes-devtools/python/python3-idna_3.3.bb
>deleted file mode 100644
>index a0e6b79a565..000
>--- a/meta/recipes-devtools/python/python3-idna_3.3.bb
>+++ /dev/null
>@@ -1,19 +0,0 @@
>-SUMMARY = "Internationalised Domain Names in Applications"
>-HOMEPAGE = "https://github.com/kjd/idna";
>-LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
>-LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
>-
>-SRC_URI[sha256sum] =
>"9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
>-
>-inherit pypi setuptools3
>-
>-# Remove bundled egg-info
>-do_compile:prepend() {
>-rm -rf ${S}/idna.egg-info
>-}
>-
>-RDEPENDS:${PN}:class-target = "\
>-${PYTHON_PN}-codecs \
>-"
>-
>-BBCLASSEXTEND = "native nativesdk"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159800):
https://lists.openembedded.org/g/openembedded-core/message/159800
Mute This Topic: https://lists.openembedded.org/mt/87766621/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] busybox: refresh the defconfig from 1.33.0
Hi Martin, I just noticed that since this change, syslogd is compiled in by default, even I have SRC_URI:remove = "file://syslog.cfg" in a bbappend. Is this intentional? Otherwise, I'd prefer change the back to disabled by default (SRC_URI still contains syslog.cfg by default). Regards, Jan On Wed, 2021-03-10 at 14:37 +0100, Martin Jansa wrote: > -# CONFIG_LOGREAD is not set > -# CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING is not set > -# CONFIG_SYSLOGD is not set > -# CONFIG_FEATURE_ROTATE_LOGFILE is not set > -# CONFIG_FEATURE_REMOTE_LOG is not set > -# CONFIG_FEATURE_SYSLOGD_DUP is not set > -# CONFIG_FEATURE_SYSLOGD_CFG is not set > -CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=0 > -# CONFIG_FEATURE_IPC_SYSLOG is not set > -CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=0 > -# CONFIG_FEATURE_KMSG_SYSLOG is not set > +CONFIG_LOGREAD=y > +CONFIG_FEATURE_LOGREAD_REDUCED_LOCKING=y > +CONFIG_SYSLOGD=y > +CONFIG_FEATURE_ROTATE_LOGFILE=y > +CONFIG_FEATURE_REMOTE_LOG=y > +CONFIG_FEATURE_SYSLOGD_DUP=y > +CONFIG_FEATURE_SYSLOGD_CFG=y > +# CONFIG_FEATURE_SYSLOGD_PRECISE_TIMESTAMPS is not set > +CONFIG_FEATURE_SYSLOGD_READ_BUFFER_SIZE=256 > +CONFIG_FEATURE_IPC_SYSLOG=y > +CONFIG_FEATURE_IPC_SYSLOG_BUFFER_SIZE=64 > +CONFIG_FEATURE_KMSG_SYSLOG=y -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159801): https://lists.openembedded.org/g/openembedded-core/message/159801 Mute This Topic: https://lists.openembedded.org/mt/81226966/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] python3-idna: Update license to Unicode-TOU
The correct SPDX license for the test data contained in this code appears to be Unicode-TOU. Update the LICENSE field to match and avoid package QA warnings. Signed-off-by: Richard Purdie --- meta/recipes-devtools/python/python3-idna_3.3.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/python/python3-idna_3.3.bb b/meta/recipes-devtools/python/python3-idna_3.3.bb index a0e6b79a565..ee92f44fd58 100644 --- a/meta/recipes-devtools/python/python3-idna_3.3.bb +++ b/meta/recipes-devtools/python/python3-idna_3.3.bb @@ -1,6 +1,6 @@ SUMMARY = "Internationalised Domain Names in Applications" HOMEPAGE = "https://github.com/kjd/idna"; -LICENSE = "BSD-3-Clause & Python-2.0 & Unicode" +LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-TOU" LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1" SRC_URI[sha256sum] = "9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d" -- 2.32.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159802): https://lists.openembedded.org/g/openembedded-core/message/159802 Mute This Topic: https://lists.openembedded.org/mt/87772688/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] CMAKE_SYSTEM_PROCESSOR inconsistent in SDK
A colleague notes a cmake problem in the SDK due to CMAKE_SYSTEM_PROCESSOR being set to 'cortexa53-crypto', which the package doesn't recognize. The package builds fine with bitbake because CMAKE_SYSTEM_PROCESSOR is set to 'aarch64', which the package does recognize. The value for the SDK comes from this commit: https://github.com/openembedded/openembedded-core/commit/4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb#diff-68a2f5f7520be29f69417255d4067d5e97b8681596cd851d946d241c8a1dda76 Is there a problem with this commit? Or is there something missing that prevents 'cortexa53-crypto' to resolve to the more general 'aarch64'? Tom <> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159803): https://lists.openembedded.org/g/openembedded-core/message/159803 Mute This Topic: https://lists.openembedded.org/mt/87773810/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] CMAKE_SYSTEM_PROCESSOR inconsistent in SDK
Hello Tom, Em qui., 16 de dez. de 2021 às 15:55, Tom Hochstein escreveu: > A colleague notes a cmake problem in the SDK due to CMAKE_SYSTEM_PROCESSOR > being set to 'cortexa53-crypto', which the package doesn't recognize. The > package builds fine with bitbake because CMAKE_SYSTEM_PROCESSOR is set to > 'aarch64', which the package does recognize. > > The value for the SDK comes from this commit: > > https://github.com/openembedded/openembedded-core/commit/4143f3b0ce0d0c52f5b0babc1bb16ac0ac9610eb#diff-68a2f5f7520be29f69417255d4067d5e97b8681596cd851d946d241c8a1dda76 > > Is there a problem with this commit? Or is there something missing that > prevents 'cortexa53-crypto' to resolve to the more general 'aarch64'? I believe this is indeed a bug as the SDK and OE environment should be consistent. I think we ought to fix the CMake SDK support so it is consistent on both environments. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159804): https://lists.openembedded.org/g/openembedded-core/message/159804 Mute This Topic: https://lists.openembedded.org/mt/87773810/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Canceled: OpenEmbedded Happy Hour December 29
Hi, The next OpenEmbedded Happy Hour is being canceled due to the Holidays and since we had the last one on December 3. The next Happy Hour will take place on January 26 2022: https://www.openembedded.org/wiki/Calendar -- Regards, Denys Dmytriyenko PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159805): https://lists.openembedded.org/g/openembedded-core/message/159805 Mute This Topic: https://lists.openembedded.org/mt/87775439/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] python3-idna: Drop from OE-Core
On Thu, 2021-12-16 at 18:25 +0100, Quentin Schulz wrote: > Hi Richard, > > On December 16, 2021 2:22:18 PM GMT+01:00, Richard Purdie > wrote: > > The only recipe mentioning python3-idna in OE-Core is python3-jsonschema. > > python3-jsonschema only depends on it if the nongpl package config option > > is set. We don't set this option. > > > > That is unfortunately incorrect, it is also part of the format PACKAGECONFIG > which is by default included. > > > The idna recipe has license issues with questions around the Unicode license > > (still in meta-oe) and which version variant it should mean. We see QA > > warnings > > in automated testing from this: > > > > I still shall open an issue on the GitHub tracker of the project to raise > this. I don't know how I didn't see the line in the format PACKAGECONFIG. I've sent a patch to update it to Unicode-TOC as I think that matches what the header talks about. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159806): https://lists.openembedded.org/g/openembedded-core/message/159806 Mute This Topic: https://lists.openembedded.org/mt/87766621/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] linux-yocto-dev: add qemuriscv32
Signed-off-by: Jon Mason
---
meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 80f62a0412ad..744b74ce3749 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -50,7 +50,7 @@ PACKAGECONFIG[dt-validation] = ",,python3-dtschema-native"
# we need the wrappers if validation isn't in the packageconfig
DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'dt-validation', '',
'python3-dtschema-wrapper-native', d)}"
-COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv64)"
+COMPATIBLE_MACHINE =
"(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)"
KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159807):
https://lists.openembedded.org/g/openembedded-core/message/159807
Mute This Topic: https://lists.openembedded.org/mt/8809/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] linux-yocto-dev: add qemuriscv32
On Thu, Dec 16, 2021 at 2:07 PM Jon Mason wrote:
>
> Signed-off-by: Jon Mason
> ---
> meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> index 80f62a0412ad..744b74ce3749 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> @@ -50,7 +50,7 @@ PACKAGECONFIG[dt-validation] = ",,python3-dtschema-native"
> # we need the wrappers if validation isn't in the packageconfig
> DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'dt-validation', '',
> 'python3-dtschema-wrapper-native', d)}"
>
> -COMPATIBLE_MACHINE =
> "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv64)"
> +COMPATIBLE_MACHINE =
> "(qemuarm|qemux86|qemuppc|qemumips|qemumips64|qemux86-64|qemuriscv32|qemuriscv64)"
lgtm.
>
> KERNEL_DEVICETREE:qemuarmv5 = "versatile-pb.dtb"
>
> --
> 2.20.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159808):
https://lists.openembedded.org/g/openembedded-core/message/159808
Mute This Topic: https://lists.openembedded.org/mt/8809/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] python3-pyelftools: Depend on debugger, pprint
On Thu, Dec 16, 2021 at 9:00 AM Chaitanya Vadrevu
wrote:
>
> python3-pyelftools uses python3-debugger, python3-pprint.
> So add dependencies on these packages.
>
> Signed-off-by: Chaitanya Vadrevu
> ---
> meta/recipes-devtools/python/python3-pyelftools_0.27.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
> b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
> index 0cfd99504b..f8b9d420a5 100644
> --- a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
> +++ b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
> @@ -11,3 +11,5 @@ PYPI_PACKAGE = "pyelftools"
> inherit pypi setuptools3
>
> BBCLASSEXTEND = "native"
> +
> +RDEPENDS_${PN} += "${PYTHON_PN}-debugger ${PYTHON_PN}-pprint"
this should use new override separator. It should be RDEPENDS:${PN}
> --
> 2.17.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159809):
https://lists.openembedded.org/g/openembedded-core/message/159809
Mute This Topic: https://lists.openembedded.org/mt/87771402/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: fix arm64 link failures when building rust apps
Patch withdrawn: turns out meta-tegra was pulling in an old toolchain
for CUDA reasons, and that just got fixed. Probably there isn't another
aarch64 platform still using a non-fixed toolchain, and if there happens
to be one maybe they will run across this patch to carry it in their own
layer.
Note: apologies for not CC-ing Alexander Kanavin, but I couldn't figure
out how to directly reply to his question from this list's web UI & I don't
have a copy of his email in my inbox.
https://lists.openembedded.org/g/openembedded-core/message/159775
On Thu, Dec 16, 2021 at 01:19:45AM -0800, S. Lockwood-Childs wrote:
> Typical error when trying to build a rust app (for example, librsvg)
> for aarch64 targets looks like:
> undefined references to `__aarch64_ldadd8_rel'
>
> The upstream rust commit
> "add target feature outline-atomics" 0f9f241aac21bc77fb9e757da18207abefdc841d
> has caused a number of such link failure regressions on platforms with aarch64
> toolchains that are not able to cope with -moutline-atomics flag. This
> includes
> musl toolchains [1] but some glibc toolchains also are not able to handle this
> flag [2,3]
>
> OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able to
> handle outline-atomics this patch should go away, to take advantage of the
> reported performance benefit.
>
> [1] https://github.com/rust-lang/git2-rs/issues/706
> [2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
>
> Signed-off-by: S. Lockwood-Childs
> ---
> meta/recipes-devtools/rust/rust-target.inc| 2 +
> .../rust/rust-disable-outline-atomics.patch | 50 +++
> 2 files changed, 52 insertions(+)
> create mode 100644
> meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
>
> diff --git a/meta/recipes-devtools/rust/rust-target.inc
> b/meta/recipes-devtools/rust/rust-target.inc
> index 3f637b3ba5..bac743f66d 100644
> --- a/meta/recipes-devtools/rust/rust-target.inc
> +++ b/meta/recipes-devtools/rust/rust-target.inc
> @@ -2,6 +2,8 @@ require rust.inc
>
> DEPENDS += "rust-llvm (=${PV})"
>
> +SRC_URI += "file://rust-disable-outline-atomics.patch"
> +
> # Otherwise we'll depend on what we provide
> INHIBIT_DEFAULT_RUST_DEPS:class-native = "1"
> # We don't need to depend on gcc-native because yocto assumes it exists
> diff --git
> a/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> new file mode 100644
> index 00..fc99a06a6a
> --- /dev/null
> +++ b/meta/recipes-devtools/rust/rust/rust-disable-outline-atomics.patch
> @@ -0,0 +1,50 @@
> +rust: fix arm64 link failures when building rust apps
> +
> +Typical error when trying to build a rust app looks like:
> + undefined references to `__aarch64_ldadd8_rel'
> +
> +The upstream rust commit
> +"add target feature outline-atomics" 0f9f241aac21bc77fb9e757da18207abefdc841d
> +has caused a number of such link failure regressions on platforms with
> aarch64
> +toolchains that are not able to cope with -moutline-atomics flag. This
> includes
> +musl toolchains [1] but some glibc toolchains also are not able to handle
> this
> +flag [2,3]
> +
> +OE gcc-cross-aarch64 is currently one of the latter, but when it *is* able to
> +handle outline-atomics this patch should go away, to take advantage of the
> +reported performance benefit.
> +
> +[1] https://github.com/rust-lang/git2-rs/issues/706
> +[2] https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg661738.html
> +[3] https://bugzilla.redhat.com/show_bug.cgi?id=1830472
> +
> +Upstream-Status: Inappropriate [other]
> +
> +Signed-off-by: S. Lockwood-Childs
> +
> +diff --git a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> +index c2136f161..ca221eb4a 100644
> +--- a/compiler/rustc_codegen_llvm/src/llvm_util.rs
> b/compiler/rustc_codegen_llvm/src/llvm_util.rs
> +@@ -416,13 +416,14 @@ pub fn llvm_global_features(sess: &Session) ->
> Vec {
> + // -Ctarget-features
> +
> features.extend(sess.opts.cg.target_feature.split(',').flat_map(&filter));
> +
> +-// FIXME: Move outline-atomics to target definition when earliest
> supported LLVM is 12.
> +-if get_version() >= (12, 0, 0)
> +-&& sess.target.llvm_target.contains("aarch64-unknown-linux")
> +-&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
> +-{
> +-features.push("+outline-atomics".to_string());
> +-}
> ++//// FIXME: Move outline-atomics to target definition when earliest
> supported LLVM is 12.
> ++//if get_version() >= (12, 0, 0)
> ++//&& sess.target.llvm_target.contains("aarch64-unknown-linux")
> ++//&& sess.target.llvm_target != "aarch64-unknown-linux-musl"
> ++//{
> ++//features.push("+outline-atomics".to_string());
> ++//}
> ++
> +
> + features
> + }
> --
> 2.20.1
>
-=-=-=-=-=-
[OE-core] [PATCH v2] python3-pyelftools: Depend on debugger, pprint
python3-pyelftools uses python3-debugger, python3-pprint.
So add dependencies on these packages.
Signed-off-by: Chaitanya Vadrevu
---
meta/recipes-devtools/python/python3-pyelftools_0.27.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
index 0cfd99504b..e2d0e18277 100644
--- a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
+++ b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
@@ -11,3 +11,5 @@ PYPI_PACKAGE = "pyelftools"
inherit pypi setuptools3
BBCLASSEXTEND = "native"
+
+RDEPENDS:${PN} += "${PYTHON_PN}-debugger ${PYTHON_PN}-pprint"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159811):
https://lists.openembedded.org/g/openembedded-core/message/159811
Mute This Topic: https://lists.openembedded.org/mt/87779680/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [hardknott][PATCH] python3-pyelftools: Depend on debugger, pprint
python3-pyelftools uses python3-debugger, python3-pprint.
So add dependencies on these packages.
Signed-off-by: Chaitanya Vadrevu
---
meta/recipes-devtools/python/python3-pyelftools_0.27.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
index 0cfd99504b..f8b9d420a5 100644
--- a/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
+++ b/meta/recipes-devtools/python/python3-pyelftools_0.27.bb
@@ -11,3 +11,5 @@ PYPI_PACKAGE = "pyelftools"
inherit pypi setuptools3
BBCLASSEXTEND = "native"
+
+RDEPENDS_${PN} += "${PYTHON_PN}-debugger ${PYTHON_PN}-pprint"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159812):
https://lists.openembedded.org/g/openembedded-core/message/159812
Mute This Topic: https://lists.openembedded.org/mt/87779892/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 3/3] tzdata: Clean up
* Whitespace and indentation clean up.
* Change shell variables from "${foo}" to "$foo".
* Remove "/*" from directories specified in FILES.
* Remove RCONFLICTS:${PN} for the packages from the timezones recipe,
which was dropped from OE-Classic in 2007...
Signed-off-by: Peter Kjellerstedt
---
PATCHv2:
* Removed the RCONFLICTS:${PN} for the packages from the timezones
recipe after I realized it was dropped from OE-Classic in 2007.
* Removed commented "pacificnew" timezone. It has been commented
sinze the recipe was introduced in 2007.
meta/recipes-extended/timezone/tzdata.bb | 298 +++
1 file changed, 149 insertions(+), 149 deletions(-)
diff --git a/meta/recipes-extended/timezone/tzdata.bb
b/meta/recipes-extended/timezone/tzdata.bb
index 64135ef8aa..7f4322d867 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -4,199 +4,199 @@ DEPENDS = "tzcode-native"
inherit allarch
-RCONFLICTS:${PN} = "timezones timezone-africa timezone-america
timezone-antarctica \
- timezone-arctic timezone-asia timezone-atlantic \
- timezone-australia timezone-europe timezone-indian \
- timezone-iso3166.tab timezone-pacific timezone-zone.tab"
-
S = "${WORKDIR}"
DEFAULT_TIMEZONE ?= "Universal"
INSTALL_TIMEZONE_FILE ?= "1"
-TZONES= "africa antarctica asia australasia europe northamerica southamerica \
- factory etcetera backward \
-"
-# pacificnew
+TZONES = " \
+africa antarctica asia australasia europe northamerica southamerica \
+factory etcetera backward \
+"
# "slim" is the default since 2020b
# "fat" is needed by e.g. MariaDB's mysql_tzinfo_to_sql
ZIC_FMT ?= "slim"
-do_compile () {
-for zone in ${TZONES}; do \
-${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo -L /dev/null \
-${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null \
-${S}/${zone} ; \
-${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds \
-${S}/${zone} ; \
-done
+do_compile() {
+ for zone in ${TZONES}; do
+ ${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo -L /dev/null ${S}/${zone}
+ ${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo/posix -L /dev/null ${S}/${zone}
+ ${STAGING_BINDIR_NATIVE}/zic -b ${ZIC_FMT} -d
${WORKDIR}${datadir}/zoneinfo/right -L ${S}/leapseconds ${S}/${zone}
+ done
}
-do_install () {
-install -d ${D}$exec_prefix ${D}${datadir}/zoneinfo
-cp -pPR ${WORKDIR}$exec_prefix ${D}${base_prefix}
-# libc is removing zoneinfo files from package
-cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo
-cp -pP "${S}/zone1970.tab" ${D}${datadir}/zoneinfo
-cp -pP "${S}/iso3166.tab" ${D}${datadir}/zoneinfo
-cp -pP "${S}/leapseconds" ${D}${datadir}/zoneinfo
-cp -pP "${S}/leap-seconds.list" ${D}${datadir}/zoneinfo
-
-# Install default timezone
-if [ -e ${D}${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ]; then
-install -d ${D}${sysconfdir}
-if [ "${INSTALL_TIMEZONE_FILE}" = "1" ]; then
-echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
-fi
-ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE}
${D}${sysconfdir}/localtime
-else
-bberror "DEFAULT_TIMEZONE is set to an invalid value."
-exit 1
-fi
-
-chown -R root:root ${D}
+do_install() {
+ install -d ${D}$exec_prefix ${D}${datadir}/zoneinfo
+ cp -pPR ${WORKDIR}$exec_prefix ${D}${base_prefix}
+ # libc is removing zoneinfo files from package
+ cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo
+ cp -pP "${S}/zone1970.tab" ${D}${datadir}/zoneinfo
+ cp -pP "${S}/iso3166.tab" ${D}${datadir}/zoneinfo
+ cp -pP "${S}/leapseconds" ${D}${datadir}/zoneinfo
+ cp -pP "${S}/leap-seconds.list" ${D}${datadir}/zoneinfo
+
+ # Install default timezone
+ if [ -e ${D}${datadir}/zoneinfo/${DEFAULT_TIMEZONE} ]; then
+ install -d ${D}${sysconfdir}
+ if [ "${INSTALL_TIMEZONE_FILE}" = "1" ]; then
+ echo ${DEFAULT_TIMEZONE} > ${D}${sysconfdir}/timezone
+ fi
+ ln -s ${datadir}/zoneinfo/${DEFAULT_TIMEZONE}
${D}${sysconfdir}/localtime
+ else
+ bberror "DEFAULT_TIMEZONE is set to an invalid value."
+ exit 1
+ fi
+
+ chown -R root:root ${D}
}
-pkg_postinst:${PN} () {
+pkg_postinst:${PN}() {
etc_lt="$D${sysconfdir}/localtime"
src="$D${sysconfdir}/timezone"
- if [ -e ${src} ] ; then
- tz=$(sed -e 's:#.*::' -e 's:[[:space:]]*::g' -e '/^$/d'
"${src}")
+
[OE-core] [PATCHv2 1/3] tzdata: Make it compatible with devtool modify
This avoids the following build error after having run `devtool modify
tzdata`:
cp: cannot stat '.../qemux86-64/workspace/sources/tzdata//usr': No
such file or directory
Signed-off-by: Peter Kjellerstedt
---
PATCHv2: No changes.
meta/recipes-extended/timezone/tzdata.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-extended/timezone/tzdata.bb
b/meta/recipes-extended/timezone/tzdata.bb
index c2b019922a..09cb14a855 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -35,8 +35,8 @@ do_compile () {
}
do_install () {
-install -d ${D}/$exec_prefix ${D}${datadir}/zoneinfo
-cp -pPR ${S}/$exec_prefix ${D}/
+install -d ${D}$exec_prefix ${D}${datadir}/zoneinfo
+cp -pPR ${WORKDIR}$exec_prefix ${D}${base_prefix}
# libc is removing zoneinfo files from package
cp -pP "${S}/zone.tab" ${D}${datadir}/zoneinfo
cp -pP "${S}/zone1970.tab" ${D}${datadir}/zoneinfo
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159814):
https://lists.openembedded.org/g/openembedded-core/message/159814
Mute This Topic: https://lists.openembedded.org/mt/87781811/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCHv2 2/3] tzdata: Remove unnecessary RPROVIDES
The name of the package is provided automatically.
Signed-off-by: Peter Kjellerstedt
---
PATCHv2: No changes.
meta/recipes-extended/timezone/tzdata.bb | 12
1 file changed, 12 deletions(-)
diff --git a/meta/recipes-extended/timezone/tzdata.bb
b/meta/recipes-extended/timezone/tzdata.bb
index 09cb14a855..64135ef8aa 100644
--- a/meta/recipes-extended/timezone/tzdata.bb
+++ b/meta/recipes-extended/timezone/tzdata.bb
@@ -89,7 +89,6 @@ TZ_PACKAGES = " \
PACKAGES = "${TZ_PACKAGES} ${PN}"
FILES:tzdata-africa += "${datadir}/zoneinfo/Africa/*"
-RPROVIDES:tzdata-africa = "tzdata-africa"
FILES:tzdata-americas += "${datadir}/zoneinfo/America/* \
${datadir}/zoneinfo/US/*\
@@ -97,36 +96,26 @@ FILES:tzdata-americas += "${datadir}/zoneinfo/America/* \
${datadir}/zoneinfo/Canada/*\
${datadir}/zoneinfo/Mexico/*\
${datadir}/zoneinfo/Chile/*"
-RPROVIDES:tzdata-americas = "tzdata-americas"
FILES:tzdata-antarctica += "${datadir}/zoneinfo/Antarctica/*"
-RPROVIDES:tzdata-antarctica = "tzdata-antarctica"
FILES:tzdata-arctic += "${datadir}/zoneinfo/Arctic/*"
-RPROVIDES:tzdata-arctic = "tzdata-arctic"
FILES:tzdata-asia += "${datadir}/zoneinfo/Asia/*\
${datadir}/zoneinfo/Indian/*\
${datadir}/zoneinfo/Mideast/*"
-RPROVIDES:tzdata-asia = "tzdata-asia"
FILES:tzdata-atlantic += "${datadir}/zoneinfo/Atlantic/*"
-RPROVIDES:tzdata-atlantic = "tzdata-atlantic"
FILES:tzdata-australia += "${datadir}/zoneinfo/Australia/*"
-RPROVIDES:tzdata-australia = "tzdata-australia"
FILES:tzdata-europe += "${datadir}/zoneinfo/Europe/*"
-RPROVIDES:tzdata-europe = "tzdata-europe"
FILES:tzdata-pacific += "${datadir}/zoneinfo/Pacific/*"
-RPROVIDES:tzdata-pacific = "tzdata-pacific"
FILES:tzdata-posix += "${datadir}/zoneinfo/posix/*"
-RPROVIDES:tzdata-posix = "tzdata-posix"
FILES:tzdata-right += "${datadir}/zoneinfo/right/*"
-RPROVIDES:tzdata-right = "tzdata-right"
FILES:tzdata-misc += "${datadir}/zoneinfo/Cuba \
${datadir}/zoneinfo/Egypt\
@@ -146,7 +135,6 @@ FILES:tzdata-misc += "${datadir}/zoneinfo/Cuba \
${datadir}/zoneinfo/Portugal \
${datadir}/zoneinfo/Singapore\
${datadir}/zoneinfo/Turkey"
-RPROVIDES:tzdata-misc = "tzdata-misc"
FILES:tzdata-core += " \
${sysconfdir}/localtime \
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159815):
https://lists.openembedded.org/g/openembedded-core/message/159815
Mute This Topic: https://lists.openembedded.org/mt/87781812/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 0/3] support Android target in all build system
On 12/16/21 22:56, Richard Purdie wrote: CAUTION: Email originated externally, do not click links or open attachments unless you recognize the sender and know the content is safe. On Thu, 2021-12-16 at 18:38 +0800, Hsia-Jun Li wrote: From: "Hsia-Jun(Randy) Li" Both meson and cmake would work fine, left those GNU autotools, customer script projects. The behaviour of meson would become that as the following for the Android target: lib/libfoo.so is the real binary library lib/libfoo.so.x -> libfoo.so lib/libfoo.so.x.y -> libfoo.so But when you tell the autotools the target host is android, it won't make any difference in its output library. I would like to fix that but I am not good at m4 script. Hsia-Jun(Randy) Li (3): cmake.bbclass: support android os classes/meson: support Android os [WIP]: openssl: fix Android target The first couple of patches look ok but I'd like to understand whether there is real world usable output from the build after applying them? If not, I think we https://github.com/hizukiayaka/meta-android-ndk https://github.com/hizukiayaka/meta-android-ndk/blob/master/recipes-core/proxy-libintl/proxy-libintl_git.bb Which provides the 'virtual/libintl' in Android, that would need meson. should probably wait until we can see the bigger picture of what other changes would be needed to make this work rather than making tweaks piecemeal. The target is building a Gstreamer(media service) for Android VNDK(in /vendor partition). Now, I still fight with glib-2.0 and python3, the dependency of python3 need to be patched, some of them as I said they are using autotools, it would still product library links likes ERROR: ncurses-6.3-r0 do_package: QA Issue: ncurses: Files/directories were installed but not shipped in any package: /usr/lib/libtic.so /usr/lib/libcurses.so /usr/lib/libpanel.so /usr/lib/libmenu.so /usr/lib/libform.so /usr/lib/libticw.so /usr/lib/libpanelw.so /usr/lib/libmenuw.so /usr/lib/libformw.so /usr/lib/libncurses.so /usr/lib/libncursesw.so /usr/lib/libtermcap.so /usr/lib/libtinfo.so Can you describe what level of functionality these patches give to a build? At lease we could have a few simple applications that would work in Android, likes the unit test from libpng. Cheers, Richard -- Hsia-Jun(Randy) Li -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159816): https://lists.openembedded.org/g/openembedded-core/message/159816 Mute This Topic: https://lists.openembedded.org/mt/87764530/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [poky][dunfell][PATCH 1/2] openssh: Fix CVE-2021-41617
Add patch to fix CVE-2021-41617
Link: https://bugzilla.suse.com/attachment.cgi?id=854015
Signed-off-by: Sana Kazi
Signed-off-by: Sana Kazi
---
.../openssh/openssh/CVE-2021-41617.patch | 52 +++
.../openssh/openssh_8.2p1.bb | 1 +
2 files changed, 53 insertions(+)
create mode 100644
meta/recipes-connectivity/openssh/openssh/CVE-2021-41617.patch
diff --git a/meta/recipes-connectivity/openssh/openssh/CVE-2021-41617.patch
b/meta/recipes-connectivity/openssh/openssh/CVE-2021-41617.patch
new file mode 100644
index 00..bda896f581
--- /dev/null
+++ b/meta/recipes-connectivity/openssh/openssh/CVE-2021-41617.patch
@@ -0,0 +1,52 @@
+From a6414400ec94a17871081f7df24f910a6ee01b8b Mon Sep 17 00:00:00 2001
+From: Ali Abdallah
+Date: Wed, 24 Nov 2021 13:33:39 +0100
+Subject: [PATCH] CVE-2021-41617 fix
+
+backport of the following two upstream commits
+
+f3cbe43e28fe71427d41cfe3a17125b972710455
+bf944e3794eff5413f2df1ef37cddf96918c6bde
+
+CVE-2021-41617 failed to correctly initialise supplemental groups
+when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand,
+where a AuthorizedKeysCommandUser or AuthorizedPrincipalsCommandUser
+directive has been set to run the command as a different user. Instead
+these commands would inherit the groups that sshd(8) was started with.
+---
+ auth.c | 8
+ 1 file changed, 8 insertions(+)
+
+CVE: CVE-2021-41617
+Upstream-Status: Backport [https://bugzilla.suse.com/attachment.cgi?id=854015]
+Comment: No change in any hunk
+Signed-off-by: Sana Kazi
+
+diff --git a/auth.c b/auth.c
+index 163038f..a47b267 100644
+--- a/auth.c
b/auth.c
+@@ -52,6 +52,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include "xmalloc.h"
+ #include "match.h"
+@@ -851,6 +852,13 @@ subprocess(const char *tag, struct passwd *pw, const char
*command,
+ }
+ closefrom(STDERR_FILENO + 1);
+
++ if (geteuid() == 0 &&
++ initgroups(pw->pw_name, pw->pw_gid) == -1) {
++ error("%s: initgroups(%s, %u): %s", tag,
++ pw->pw_name, (u_int)pw->pw_gid, strerror(errno));
++ _exit(1);
++ }
++
+ /* Don't use permanently_set_uid() here to avoid fatal() */
+ if (setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) == -1) {
+ error("%s: setresgid %u: %s", tag, (u_int)pw->pw_gid,
+--
+2.26.2
diff --git a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
index b60d1a6bd4..e903ec487d 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb
@@ -26,6 +26,7 @@ SRC_URI =
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://add-test-support-for-busybox.patch \
file://CVE-2020-14145.patch \
file://CVE-2021-28041.patch \
+ file://CVE-2021-41617.patch \
"
SRC_URI[md5sum] = "3076e6413e8dbe56d33848c1054ac091"
SRC_URI[sha256sum] =
"43925151e6cf6cee1450190c0e9af4dc36b41c12737619edff8bcebdff64e671"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159817):
https://lists.openembedded.org/g/openembedded-core/message/159817
Mute This Topic: https://lists.openembedded.org/mt/87784954/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [poky][dunfell][PATCH 2/2] openssh: Whitelist CVE-2016-20012
Whitelist CVE-2016-20012 as the upstream OpenSSH developers see this as an important security feature and do not intend to 'fix' it. Link: https://security-tracker.debian.org/tracker/CVE-2016-20012 https://ubuntu.com/security/CVE-2016-20012 Signed-off-by: Sana Kazi Signed-off-by: Sana Kazi --- meta/recipes-connectivity/openssh/openssh_8.2p1.bb | 9 + 1 file changed, 9 insertions(+) diff --git a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb index e903ec487d..ddc9ed0b32 100644 --- a/meta/recipes-connectivity/openssh/openssh_8.2p1.bb +++ b/meta/recipes-connectivity/openssh/openssh_8.2p1.bb @@ -51,6 +51,15 @@ CVE_CHECK_WHITELIST += "CVE-2020-15778" # https://www.securityfocus.com/bid/30794 CVE_CHECK_WHITELIST += "CVE-2008-3844" +# openssh-ssh1 is provided for compatibility with old devices that +# cannot be upgraded to modern protocols. Thus they may not provide security +# support for this package because doing so would prevent access to equipment. +# The upstream OpenSSH developers see this as an important +# security feature and do not intend to 'fix' it. +# https://security-tracker.debian.org/tracker/CVE-2016-20012 +# https://ubuntu.com/security/CVE-2016-20012 +CVE_CHECK_WHITELIST += "CVE-2016-20012" + PAM_SRC_URI = "file://sshd" inherit manpages useradd update-rc.d update-alternatives systemd -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159818): https://lists.openembedded.org/g/openembedded-core/message/159818 Mute This Topic: https://lists.openembedded.org/mt/87784964/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
