[OE-core] [PATCH] mesa: Fix build on ARM systems without Neon
See [1]
[1] https://github.com/YoeDistro/yoe-distro/issues/626
Signed-off-by: Khem Raj
Cc: Ross Burton
---
...ormat-Check-for-NEON-before-using-it.patch | 49 +++
meta/recipes-graphics/mesa/mesa.inc | 1 +
2 files changed, 50 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
new file mode 100644
index 000..80b9af08e8f
--- /dev/null
+++
b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
@@ -0,0 +1,49 @@
+From 4febda271c6bb0dc69ebf573446c6922a1ec35fb Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Thu, 2 Dec 2021 19:57:42 -0800
+Subject: [PATCH] util/format: Check for NEON before using it
+
+This fixes build on rpi0-w and any other machine which does not have
+neon unit and is not used as FPU unit
+
+Fixes errors e.g.
+
+In file included from ../mesa-21.3.0/src/util/format/u_format_unpack_neon.c:35:
+/mnt/b/yoe/master/build/tmp/work/arm1176jzfshf-vfp-yoe-linux-gnueabi/mesa/2_21.3.0-r0/recipe-sysroot-native/usr/lib/clang/13.0.1/include/arm_neon.h:32:2:
error: "NEON support not enabled"
+
+Upstream-Status: Submitted
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14032]
+Signed-off-by: Khem Raj
+---
+ src/util/format/u_format.c | 2 +-
+ src/util/format/u_format_unpack_neon.c | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/util/format/u_format.c b/src/util/format/u_format.c
+index 36c5e52008e..f0a00971691 100644
+--- a/src/util/format/u_format.c
b/src/util/format/u_format.c
+@@ -1138,7 +1138,7 @@ static void
+ util_format_unpack_table_init(void)
+ {
+for (enum pipe_format format = PIPE_FORMAT_NONE; format <
PIPE_FORMAT_COUNT; format++) {
+-#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) &&
!defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
++#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) &&
defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM)
+ const struct util_format_unpack_description *unpack =
util_format_unpack_description_neon(format);
+ if (unpack) {
+ util_format_unpack_table[format] = unpack;
+diff --git a/src/util/format/u_format_unpack_neon.c
b/src/util/format/u_format_unpack_neon.c
+index a4a5cb1f723..1e4f794a295 100644
+--- a/src/util/format/u_format_unpack_neon.c
b/src/util/format/u_format_unpack_neon.c
+@@ -23,7 +23,7 @@
+
+ #include
+
+-#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) &&
!defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
++#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) &&
defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM)
+
+ /* armhf builds default to vfp, not neon, and refuses to compile neon
intrinsics
+ * unless you tell it "no really".
+--
+2.34.1
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index ed60d982504..30b9e93f630 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -19,6 +19,7 @@ SRC_URI =
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0002-meson.build-make-TLS-ELF-optional.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-futex.h-Define-__NR_futex-if-it-does-not-exist.patch \
+ file://0001-util-format-Check-for-NEON-before-using-it.patch \
"
SRC_URI[sha256sum] =
"a2753c09deef0ba14d35ae8a2ceff3fe5cd13698928c7bb62c2ec8736eb09ce1"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159110):
https://lists.openembedded.org/g/openembedded-core/message/159110
Mute This Topic: https://lists.openembedded.org/mt/87470454/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] sstate: don't limit the thread pool size when checking mirrors
On Thu, 2021-12-02 at 22:05 +, Jose Quaresma wrote:
> This improves the time needed to check the mirrors,
> reducing it from 50s to 8s when building the core-image-minimal
> using the yocto upstream sstate and hashequivlance servers
> on a machine with 8 cpu cores.
>
> Tested with:
>
> SSTATE_MIRRORS = "file://.*
> http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH";
> BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
> bitbake core-image-minimal
>
> Signed-off-by: Jose Quaresma
> ---
> meta/classes/sstate.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> index 0326d27c74..5e404d7cd8 100644
> --- a/meta/classes/sstate.bbclass
> +++ b/meta/classes/sstate.bbclass
> @@ -1005,7 +1005,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False,
> currentcount=0, summary=True,
> tasklist.append((tid, sstatefile))
>
> if tasklist:
> -nproc = min(int(d.getVar("BB_NUMBER_THREADS")), len(tasklist))
> +nproc = len(tasklist)
>
> progress = len(tasklist) >= 100
> if progress:
No, we're not doing that. That opens a ton (thousands) of parallel connections
to the servers and isn't fair on the systems hosting the data. In many cases
that would look like a DoS attack.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159109):
https://lists.openembedded.org/g/openembedded-core/message/159109
Mute This Topic: https://lists.openembedded.org/mt/87464090/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] glslang: upgrade 11.7.0 -> 11.7.1
changelog:
1f8c8b88 Revert port of GL_EXT_shader_realtime_clock to GL_EXT_spirv_intrinsics
Signed-off-by: Jose Quaresma
---
.../glslang/{glslang_11.7.0.bb => glslang_11.7.1.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/glslang/{glslang_11.7.0.bb => glslang_11.7.1.bb}
(95%)
diff --git a/meta/recipes-graphics/glslang/glslang_11.7.0.bb
b/meta/recipes-graphics/glslang/glslang_11.7.1.bb
similarity index 95%
rename from meta/recipes-graphics/glslang/glslang_11.7.0.bb
rename to meta/recipes-graphics/glslang/glslang_11.7.1.bb
index 0b4bf21bca..30d9954ea5 100644
--- a/meta/recipes-graphics/glslang/glslang_11.7.0.bb
+++ b/meta/recipes-graphics/glslang/glslang_11.7.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE =
"https://www.khronos.org/opengles/sdk/tools/Reference-Compiler";
LICENSE = "BSD-3-Clause & BSD-2-Clause & MIT & Apache-2.0 &
GPL-3-with-bison-exception"
LIC_FILES_CHKSUM = "file://LICENSE.txt;md5=c5ce49c0456e9b413b98a4368c378229"
-SRCREV = "925503088e2bcd76921b1e102c37fc320bace254"
+SRCREV = "c9706bdda0ac22b9856f1aa8261e5b9e15cd20c5"
SRC_URI =
"git://github.com/KhronosGroup/glslang.git;protocol=https;branch=master \
file://0001-generate-glslang-pkg-config.patch"
UPSTREAM_CHECK_GITTAGREGEX = "^(?P\d+(\.\d+)+)$"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159108):
https://lists.openembedded.org/g/openembedded-core/message/159108
Mute This Topic: https://lists.openembedded.org/mt/87464106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] sstate: don't limit the thread pool size when checking mirrors
This improves the time needed to check the mirrors,
reducing it from 50s to 8s when building the core-image-minimal
using the yocto upstream sstate and hashequivlance servers
on a machine with 8 cpu cores.
Tested with:
SSTATE_MIRRORS = "file://.*
http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH";
BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
bitbake core-image-minimal
Signed-off-by: Jose Quaresma
---
meta/classes/sstate.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 0326d27c74..5e404d7cd8 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -1005,7 +1005,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False,
currentcount=0, summary=True,
tasklist.append((tid, sstatefile))
if tasklist:
-nproc = min(int(d.getVar("BB_NUMBER_THREADS")), len(tasklist))
+nproc = len(tasklist)
progress = len(tasklist) >= 100
if progress:
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159106):
https://lists.openembedded.org/g/openembedded-core/message/159106
Mute This Topic: https://lists.openembedded.org/mt/87464090/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] sstate: use nproc for tasklist size on mirrors
Signed-off-by: Jose Quaresma
---
meta/classes/sstate.bbclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 5e404d7cd8..9efd334a59 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -997,7 +997,7 @@ def sstate_checkhashes(sq_data, d, siginfo=False,
currentcount=0, summary=True,
bb.error("SState: cannot test %s: %s" % (srcuri, e))
if progress:
-bb.event.fire(bb.event.ProcessProgress(msg, len(tasklist) -
thread_worker.tasks.qsize()), d)
+bb.event.fire(bb.event.ProcessProgress(msg, nproc -
thread_worker.tasks.qsize()), d)
tasklist = []
for tid in missed:
@@ -1007,13 +1007,13 @@ def sstate_checkhashes(sq_data, d, siginfo=False,
currentcount=0, summary=True,
if tasklist:
nproc = len(tasklist)
-progress = len(tasklist) >= 100
+progress = nproc >= 100
if progress:
msg = "Checking sstate mirror object availability"
-bb.event.fire(bb.event.ProcessStarted(msg, len(tasklist)), d)
+bb.event.fire(bb.event.ProcessStarted(msg, nproc), d)
bb.event.enable_threadlock()
-pool = oe.utils.ThreadedPool(nproc, len(tasklist),
+pool = oe.utils.ThreadedPool(nproc, nproc,
worker_init=checkstatus_init, worker_end=checkstatus_end,
name="sstate_checkhashes-")
for t in tasklist:
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159107):
https://lists.openembedded.org/g/openembedded-core/message/159107
Mute This Topic: https://lists.openembedded.org/mt/87464092/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] tune-cortexa72.inc: Add tune for nocrypto case
On Thu, Dec 2, 2021 at 1:32 PM Peter Kjellerstedt
wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org
> > On Behalf Of Khem Raj
> > Sent: den 2 december 2021 21:21
> > To: openembedded-core@lists.openembedded.org
> > Cc: Khem Raj
> > Subject: [OE-core] [PATCH] tune-cortexa72.inc: Add tune for nocrypto case
> >
> > RPI4 based on BCM2711 soc which does not enable AES extentions
> > in hardware see [1] fixes [2]
> >
> > [1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
> > [2] https://github.com/agherzan/meta-raspberrypi/issues/964
> >
> > [YOCTO #14641]
> >
> > Signed-off-by: Khem Raj
> > ---
> > meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> > b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> > index 2a510bd45bd..b2eb35f111b 100644
> > --- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> > +++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> > @@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
> > 'cortexa72', ' -mcpu=corte
> > require conf/machine/include/arm/arch-armv8a.inc
> >
> > # Little Endian base configs
> > -AVAILTUNES += "cortexa72"
> > +AVAILTUNES += "cortexa72 cortexa72-nocrypto"
> > ARMPKGARCH:tune-cortexa72 = "cortexa72"
> > TUNE_FEATURES:tune-cortexa72 =
> > "${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
> > PACKAGE_EXTRA_ARCHS:tune-cortexa72=
> > "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
> > BASE_LIB:tune-cortexa72 = "lib64"
> > +
> > +# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
> > +ARMPKGARCH:tune-cortexa72-nocrypto= "cortexa72"
> > +TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc}
> > cortexa72"
> > +PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto =
> > "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
> > +BASE_LIB:tune-cortexa72-nocrypto = "lib64"
> > --
> > 2.34.1
>
> I do realize renaming cortexa72 to cortexa72-crypto would not be backwards
> compatible, but is it really a good idea to introduce a name like this
> that does not follow the naming other tunes use?
yeah I thought about it but its an exception than norm. We also have
novfp usecases.
>
> //Peter
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159105):
https://lists.openembedded.org/g/openembedded-core/message/159105
Mute This Topic: https://lists.openembedded.org/mt/87461755/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] tune-cortexa72.inc: Add tune for nocrypto case
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Khem Raj
> Sent: den 2 december 2021 21:21
> To: openembedded-core@lists.openembedded.org
> Cc: Khem Raj
> Subject: [OE-core] [PATCH] tune-cortexa72.inc: Add tune for nocrypto case
>
> RPI4 based on BCM2711 soc which does not enable AES extentions
> in hardware see [1] fixes [2]
>
> [1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
> [2] https://github.com/agherzan/meta-raspberrypi/issues/964
>
> [YOCTO #14641]
>
> Signed-off-by: Khem Raj
> ---
> meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> index 2a510bd45bd..b2eb35f111b 100644
> --- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> +++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
> @@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
> 'cortexa72', ' -mcpu=corte
> require conf/machine/include/arm/arch-armv8a.inc
>
> # Little Endian base configs
> -AVAILTUNES += "cortexa72"
> +AVAILTUNES += "cortexa72 cortexa72-nocrypto"
> ARMPKGARCH:tune-cortexa72 = "cortexa72"
> TUNE_FEATURES:tune-cortexa72 =
> "${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
> PACKAGE_EXTRA_ARCHS:tune-cortexa72=
> "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
> BASE_LIB:tune-cortexa72 = "lib64"
> +
> +# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
> +ARMPKGARCH:tune-cortexa72-nocrypto= "cortexa72"
> +TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc}
> cortexa72"
> +PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto =
> "${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
> +BASE_LIB:tune-cortexa72-nocrypto = "lib64"
> --
> 2.34.1
I do realize renaming cortexa72 to cortexa72-crypto would not be backwards
compatible, but is it really a good idea to introduce a name like this
that does not follow the naming other tunes use?
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159104):
https://lists.openembedded.org/g/openembedded-core/message/159104
Mute This Topic: https://lists.openembedded.org/mt/87461755/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] distutils3: fix bindir mangling to stop breaking symlinks
I've not looked at that series yet (the Summit is eating time) but if
it does the same logic then yes.
Ross
On Thu, 2 Dec 2021 at 17:31, Konrad Weihmann wrote:
>
>
>
> On 02.12.21 18:17, Ross Burton wrote:
> > distutils3_do_install wants to sed out build directory references from
> > all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
> > symlinks by doing 'test -f' on the files as it iterates, but test always
> > dereferences symlinks so this will touch both real files and symlinks to
> > real files.
> >
> > The end result of this is that recipes which ship a script /usr/bin/foo
> > and a symlink /usr/bin/bar -> foo, bar will be replaced with a real file
> > which is a duplicate of foo, wasting disk space.
> >
> > Replace the loop with a find loop which can look at the real file type,
> > not the target type.
> >
> > Signed-off-by: Ross Burton
> > ---
> > meta/classes/distutils3.bbclass | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/classes/distutils3.bbclass
> > b/meta/classes/distutils3.bbclass
> > index be645d37bd..0973d304f4 100644
> > --- a/meta/classes/distutils3.bbclass
> > +++ b/meta/classes/distutils3.bbclass
> > @@ -43,11 +43,9 @@ distutils3_do_install() {
> > find ${D} -name "*.py" -exec grep -q ${D} {} \; \
> > -exec sed -i -e s:${D}::g {} \;
> >
> > -for i in ${D}${bindir}/* ${D}${sbindir}/*; do
> > -if [ -f "$i" ]; then
> > -sed -i -e s:${PYTHON}:${USRBINPATH}/env\
> > ${DISTUTILS_PYTHON}:g $i
> > -sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
> > -fi
> > +for bin in $(find ${D}${bindir} ${D}${sbindir} -type f -maxdepth
> > 1); do
> > +sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g
> > $bin
> > +sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $bin
>
> Does the same also apply to setuptools as in Tim's distutils deprecation
> series?
> If so it should definitely we be merged there
>
> > done
> >
> > rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
> >
> >
> >
> >
> >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159103):
https://lists.openembedded.org/g/openembedded-core/message/159103
Mute This Topic: https://lists.openembedded.org/mt/87457521/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] tune-cortexa72.inc: Add tune for nocrypto case
RPI4 based on BCM2711 soc which does not enable AES extentions
in hardware see [1] fixes [2]
[1] https://forums.raspberrypi.com/viewtopic.php?t=207888&start=25#p1642862
[2] https://github.com/agherzan/meta-raspberrypi/issues/964
[YOCTO #14641]
Signed-off-by: Khem Raj
---
meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
index 2a510bd45bd..b2eb35f111b 100644
--- a/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
+++ b/meta/conf/machine/include/arm/armv8a/tune-cortexa72.inc
@@ -6,8 +6,14 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES',
'cortexa72', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-nocrypto"
ARMPKGARCH:tune-cortexa72 = "cortexa72"
TUNE_FEATURES:tune-cortexa72 =
"${TUNE_FEATURES:tune-armv8a-crc-crypto} cortexa72"
PACKAGE_EXTRA_ARCHS:tune-cortexa72=
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc-crypto} cortexa72"
BASE_LIB:tune-cortexa72 = "lib64"
+
+# Some implementations do not enabled crypto ( e.g. BCM2837B0 in rpi4 )
+ARMPKGARCH:tune-cortexa72-nocrypto= "cortexa72"
+TUNE_FEATURES:tune-cortexa72-nocrypto = "${TUNE_FEATURES:tune-armv8a-crc}
cortexa72"
+PACKAGE_EXTRA_ARCHS:tune-cortexa72-nocrypto =
"${PACKAGE_EXTRA_ARCHS:tune-armv8a-crc} cortexa72"
+BASE_LIB:tune-cortexa72-nocrypto = "lib64"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159102):
https://lists.openembedded.org/g/openembedded-core/message/159102
Mute This Topic: https://lists.openembedded.org/mt/87461755/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [dunfell][PATCH] go-helloworld: test at runtime
On Thu, Dec 2, 2021 at 1:21 AM Alexander Kanavin wrote:
>
> From: Alexander Kanavin
>
> This adds a smoke check for whether the Go toolchain actually
> produces working executables across a range of architectures.
I'm getting a failure during autobuilder testing (qemuarm64-ptest):
DEBUG: Executing shell function do_configure
# Building C bootstrap tool.
cmd/dist
go tool dist: unknown architecture: aarch64
WARNING: exit code 1 from a shell command.
ERROR: Execution of
'TOPDIR/tmp/work/aarch64-linux/go-native/1.14.15-r0/temp/run.do_configure.318086'
failed with exit code 1
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2609
Steve
> (From OE-Core rev: 2819bb2cf22c6cfcaeaee79f0280097ec9cb9327)
>
> Signed-off-by: Alexander Kanavin
> Signed-off-by: Richard Purdie
> ---
> meta/classes/testimage.bbclass| 2 +-
> meta/lib/oeqa/runtime/cases/go.py | 19 +++
> .../packagegroup-core-tools-testapps.bb | 7 +++
> 3 files changed, 27 insertions(+), 1 deletion(-)
> create mode 100644 meta/lib/oeqa/runtime/cases/go.py
>
> diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
> index b1aef626f7..80c19b1e60 100644
> --- a/meta/classes/testimage.bbclass
> +++ b/meta/classes/testimage.bbclass
> @@ -58,7 +58,7 @@ BASICTESTSUITE = "\
> ping date df ssh scp python perl gi ptest parselogs \
> logrotate connman systemd oe_syslog pam stap ldd xorg \
> kernelmodule gcc buildcpio buildlzip buildgalculator \
> -dnf rpm opkg apt weston"
> +dnf rpm opkg apt weston go"
>
> DEFAULT_TEST_SUITES = "${BASICTESTSUITE}"
>
> diff --git a/meta/lib/oeqa/runtime/cases/go.py
> b/meta/lib/oeqa/runtime/cases/go.py
> new file mode 100644
> index 00..89ba2c3ecb
> --- /dev/null
> +++ b/meta/lib/oeqa/runtime/cases/go.py
> @@ -0,0 +1,19 @@
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +from oeqa.runtime.case import OERuntimeTestCase
> +from oeqa.core.decorator.depends import OETestDepends
> +from oeqa.runtime.decorator.package import OEHasPackage
> +
> +class GoHelloworldTest(OERuntimeTestCase):
> +@OETestDepends(['ssh.SSHTest.test_ssh'])
> +@OEHasPackage(['go-helloworld'])
> +def test_gohelloworld(self):
> +cmd = "go-helloworld"
> +status, output = self.target.run(cmd)
> +msg = 'Exit status was not 0. Output: %s' % output
> +self.assertEqual(status, 0, msg=msg)
> +
> +msg = 'Incorrect output: %s' % output
> +self.assertEqual(output, "Hello, Go examples!", msg=msg)
> diff --git
> a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
> b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
> index a5fc152859..3c946c57ef 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
> @@ -17,6 +17,12 @@ KEXECTOOLS_microblaze ?= ""
> KEXECTOOLS_nios2 ?= ""
> KEXECTOOLS_riscv64 ?= ""
>
> +# go does not support ppc32, only ppc64
> +# https://github.com/golang/go/issues/22885
> +# gccgo may do better
> +GOTOOLS ?= "go-helloworld"
> +GOTOOLS:powerpc ?= ""
> +
> GSTEXAMPLES ?= "gst-examples"
> GSTEXAMPLES_riscv64 = ""
>
> @@ -48,4 +54,5 @@ RDEPENDS_${PN} = "\
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', "${X11TOOLS}", "", d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', "${X11GLTOOLS}",
> "", d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', '3g', "${3GTOOLS}", "", d)} \
> +${GOTOOLS} \
> "
> --
> 2.20.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159101):
https://lists.openembedded.org/g/openembedded-core/message/159101
Mute This Topic: https://lists.openembedded.org/mt/87450623/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OpenEmbedded Developer Virtual Meeting (OEDVM) - Tomorrow
Reminder There will be an OpenEmbedded Developer Virtual Meeting (OEDVM) held tomorrow (Friday, 03 December 2021) The scheduled time will match the YP Summit's start at 12 UTC/7AM Eastern, and run until 20 UTC/3PM (or earlier if we run out of topics, but then will most likely turn into a happy hour). We will be using Automotive Grade Linux's Zoom (and many thanks to AGL for this!) https://zoom.us/j/99151508871 There current topics of discussion are listed at: https://www.openembedded.org/wiki/OEDVM_Nov_2021 There will be no given order, but priority will be given to topics with moderators. If you want to add something to the list, please do so as soon as possible. If there is a topic you would like to comment on but have difficulties at given times, please comment on Libera IRC at #oe (or respond to this email if you are lacking IRC access). No promises given but we will do our best to accommodate. Please forward this email to anyone who might be interested. As always, if you are not an OpenEmbedded Member (but are interested in joining), please attend OEDVM and you can be voted in. If there are any questions, please feel free to email me and/or the entire OE board (bo...@openembedded.org). Thanks, Jon -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159100): https://lists.openembedded.org/g/openembedded-core/message/159100 Mute This Topic: https://lists.openembedded.org/mt/87460961/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] perf: Enable libunwind packageconfig on riscv64
libunwind now supports risc64 Signed-off-by: Khem Raj --- meta/recipes-kernel/perf/perf.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb index f473272096f..7bbc1ad70c5 100644 --- a/meta/recipes-kernel/perf/perf.bb +++ b/meta/recipes-kernel/perf/perf.bb @@ -31,7 +31,6 @@ PACKAGECONFIG[coresight] = "CORESIGHT=1,,opencsd" # libunwind is not yet ported for some architectures PACKAGECONFIG:remove:arc = "libunwind" -PACKAGECONFIG:remove:riscv64 = "libunwind" PACKAGECONFIG:remove:riscv32 = "libunwind" DEPENDS = " \ -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159099): https://lists.openembedded.org/g/openembedded-core/message/159099 Mute This Topic: https://lists.openembedded.org/mt/87457888/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] distutils3: fix bindir mangling to stop breaking symlinks
On 02.12.21 18:17, Ross Burton wrote:
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch both real files and symlinks to
real files.
The end result of this is that recipes which ship a script /usr/bin/foo
and a symlink /usr/bin/bar -> foo, bar will be replaced with a real file
which is a duplicate of foo, wasting disk space.
Replace the loop with a find loop which can look at the real file type,
not the target type.
Signed-off-by: Ross Burton
---
meta/classes/distutils3.bbclass | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index be645d37bd..0973d304f4 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -43,11 +43,9 @@ distutils3_do_install() {
find ${D} -name "*.py" -exec grep -q ${D} {} \; \
-exec sed -i -e s:${D}::g {} \;
-for i in ${D}${bindir}/* ${D}${sbindir}/*; do
-if [ -f "$i" ]; then
-sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g
$i
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-fi
+for bin in $(find ${D}${bindir} ${D}${sbindir} -type f -maxdepth 1); do
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $bin
+sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $bin
Does the same also apply to setuptools as in Tim's distutils deprecation
series?
If so it should definitely we be merged there
done
rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159098):
https://lists.openembedded.org/g/openembedded-core/message/159098
Mute This Topic: https://lists.openembedded.org/mt/87457521/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] libunwind: Enable for rv64
1.6.0+ has rv64 supports now.
Signed-off-by: Khem Raj
---
meta/recipes-support/libunwind/libunwind_1.6.0.bb | 1 -
1 file changed, 1 deletion(-)
diff --git a/meta/recipes-support/libunwind/libunwind_1.6.0.bb
b/meta/recipes-support/libunwind/libunwind_1.6.0.bb
index 81b364fc5ef..91189fdb71c 100644
--- a/meta/recipes-support/libunwind/libunwind_1.6.0.bb
+++ b/meta/recipes-support/libunwind/libunwind_1.6.0.bb
@@ -16,7 +16,6 @@ EXTRA_OECONF:append:libc-musl = " --disable-documentation
--disable-tests --enab
ARM_INSTRUCTION_SET:armv4 = "arm"
ARM_INSTRUCTION_SET:armv5 = "arm"
-COMPATIBLE_HOST:riscv64 = "null"
COMPATIBLE_HOST:riscv32 = "null"
LDFLAGS += "-Wl,-z,relro,-z,now ${@bb.utils.contains('DISTRO_FEATURES',
'ld-is-gold', ' -fuse-ld=bfd ', '', d)}"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159097):
https://lists.openembedded.org/g/openembedded-core/message/159097
Mute This Topic: https://lists.openembedded.org/mt/87457802/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] distutils3: fix bindir mangling to stop breaking symlinks
distutils3_do_install wants to sed out build directory references from
all binaries in ${bindir} and ${sbindir}. It tries to avoid touching
symlinks by doing 'test -f' on the files as it iterates, but test always
dereferences symlinks so this will touch both real files and symlinks to
real files.
The end result of this is that recipes which ship a script /usr/bin/foo
and a symlink /usr/bin/bar -> foo, bar will be replaced with a real file
which is a duplicate of foo, wasting disk space.
Replace the loop with a find loop which can look at the real file type,
not the target type.
Signed-off-by: Ross Burton
---
meta/classes/distutils3.bbclass | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/meta/classes/distutils3.bbclass b/meta/classes/distutils3.bbclass
index be645d37bd..0973d304f4 100644
--- a/meta/classes/distutils3.bbclass
+++ b/meta/classes/distutils3.bbclass
@@ -43,11 +43,9 @@ distutils3_do_install() {
find ${D} -name "*.py" -exec grep -q ${D} {} \; \
-exec sed -i -e s:${D}::g {} \;
-for i in ${D}${bindir}/* ${D}${sbindir}/*; do
-if [ -f "$i" ]; then
-sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g
$i
-sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
-fi
+for bin in $(find ${D}${bindir} ${D}${sbindir} -type f -maxdepth 1); do
+sed -i -e s:${PYTHON}:${USRBINPATH}/env\ ${DISTUTILS_PYTHON}:g $bin
+sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $bin
done
rm -f ${D}${PYTHON_SITEPACKAGES_DIR}/easy-install.pth
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159096):
https://lists.openembedded.org/g/openembedded-core/message/159096
Mute This Topic: https://lists.openembedded.org/mt/87457521/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] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend
On Wed, 2021-12-01 at 20:20 +, Mike Crowe via lists.openembedded.org wrote:
> On Wednesday 01 December 2021 at 14:18:19 -0500, Justin Bronder wrote:
> > On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote:
> > > I'm building for a specific chip and therefore don't wish to waste time
> > > and
> > > electricity building and disk space on the target installing unwanted mesa
> > > drivers. However, mesa.inc contains:
> > >
> > > GALLIUMDRIVERS = "swrast"
> > > GALLIUMDRIVERS:x86-x32 = ""
> > > GALLIUMDRIVERS:append:x86:class-target = ",i915,iris,crocus"
> > > GALLIUMDRIVERS:append:x86-64:class-target = ",i915,iris,crocus"
> > >
> > > and mesa_21.3.0.bb contains:
> > >
> > > DRIDRIVERS ??= ""
> > > DRIDRIVERS:append:x86:class-target = ",r100,r200,nouveau,i965"
> > > DRIDRIVERS:append:x86-64:class-target = ",r100,r200,nouveau,i965"
> > >
> > > I'm unable to find a way to override these values. Using (for example):
> >
> > You can use an anonymous python function which runs after parsing.
> > https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#anonymous-python-functions
> >
> > python __anonymous () {
> > d.setVar("DRIDRIVERS", "i965")
> > }
>
> Thanks for the suggestion. It solves my problem. However, it seems like
> quite a subversive way to do the sort of external customisation that
> recipes normally support.
I would like to work our how we can improve this situation, I'm just struggling
to see what we should do :/
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159095):
https://lists.openembedded.org/g/openembedded-core/message/159095
Mute This Topic: https://lists.openembedded.org/mt/87432435/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] python: python3-idna: fix non-existent Unicode license
I think the Unicode should be clear, as the tool (in)directly uses
downloads from unicode, but kindly ignores the licensing part of that
operation.
Looking into the history of that lib I found
https://github.com/kjd/idna/commit/dd8841d50fd506a0b4986542c21fff32ba1779d1,
which explains the Python-2.0 part. Not sure, but I think that one can
be dropped now.
Maybe someone should raise a ticket upstream to tell them, that even
though they convert the upstream unicode data, they still have to apply
the unicode terms and conditions
On 02.12.21 17:37, Khem Raj wrote:
On Wed, Dec 1, 2021 at 8:14 AM Quentin Schulz
wrote:
In addition to not being an SPDX license, Unicode license also isn't
available in any of the LICENSE_PATH available in openembedded, meaning
the following warning is printed:
python3-idna: No generic license file exists for: Unicode in any provider
[license-exists]
Unfortunately the license is not really explicit in the project. After
looking at the code, it seems that this license gets pulled by
idna/idnadata.py and idna/uts46data.py which are auto-generated by
tools/idna-data which downloads data from
http://www.unicode.org/Public/{version}/ucd/ and
http://www.unicode.org/Public/idna/ which are covered by
https://www.unicode.org/license.txt as mentioned in
https://www.unicode.org/copyright.html.
Comparing https://www.unicode.org/license.txt to Unicode-DFS-2016
resulted in a match so let's point to that SPDX license instead.
Cc: Quentin Schulz
Signed-off-by: Quentin Schulz
---
meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
1 file changed, 6 insertions(+), 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 a0e6b79a56..f3c53a8717 100644
--- a/meta/recipes-devtools/python/python3-idna_3.3.bb
+++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
@@ -1,6 +1,11 @@
SUMMARY = "Internationalised Domain Names in Applications"
HOMEPAGE = "https://github.com/kjd/idna";
-LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
+# Note: Unicode license is pulled in by idna/idnadata.py and idna/uts46data.py
+# files auto-generated by tools/idna-data which downloads data from
+# http://www.unicode.org/Public/{version}/ucd/ and
http://www.unicode.org/Public/idna/
+# which are covered by https://www.unicode.org/license.txt as mentioned by
+# https://www.unicode.org/copyright.html
+LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-DFS-2016"
LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
I looked at
https://github.com/kjd/idna/blob/master/LICENSE.md
https://pypi.org/project/idna/
and they seem to indicate that it is BSD-3-Clause so where do the
other licenses come from ?
SRC_URI[sha256sum] =
"9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
--
2.33.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159094):
https://lists.openembedded.org/g/openembedded-core/message/159094
Mute This Topic: https://lists.openembedded.org/mt/87431709/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] python: python3-idna: fix non-existent Unicode license
On Wed, Dec 1, 2021 at 8:14 AM Quentin Schulz
wrote:
>
> In addition to not being an SPDX license, Unicode license also isn't
> available in any of the LICENSE_PATH available in openembedded, meaning
> the following warning is printed:
>
> python3-idna: No generic license file exists for: Unicode in any provider
> [license-exists]
>
> Unfortunately the license is not really explicit in the project. After
> looking at the code, it seems that this license gets pulled by
> idna/idnadata.py and idna/uts46data.py which are auto-generated by
> tools/idna-data which downloads data from
> http://www.unicode.org/Public/{version}/ucd/ and
> http://www.unicode.org/Public/idna/ which are covered by
> https://www.unicode.org/license.txt as mentioned in
> https://www.unicode.org/copyright.html.
>
> Comparing https://www.unicode.org/license.txt to Unicode-DFS-2016
> resulted in a match so let's point to that SPDX license instead.
>
> Cc: Quentin Schulz
> Signed-off-by: Quentin Schulz
> ---
> meta/recipes-devtools/python/python3-idna_3.3.bb | 7 ++-
> 1 file changed, 6 insertions(+), 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 a0e6b79a56..f3c53a8717 100644
> --- a/meta/recipes-devtools/python/python3-idna_3.3.bb
> +++ b/meta/recipes-devtools/python/python3-idna_3.3.bb
> @@ -1,6 +1,11 @@
> SUMMARY = "Internationalised Domain Names in Applications"
> HOMEPAGE = "https://github.com/kjd/idna";
> -LICENSE = "BSD-3-Clause & Python-2.0 & Unicode"
> +# Note: Unicode license is pulled in by idna/idnadata.py and
> idna/uts46data.py
> +# files auto-generated by tools/idna-data which downloads data from
> +# http://www.unicode.org/Public/{version}/ucd/ and
> http://www.unicode.org/Public/idna/
> +# which are covered by https://www.unicode.org/license.txt as mentioned by
> +# https://www.unicode.org/copyright.html
> +LICENSE = "BSD-3-Clause & Python-2.0 & Unicode-DFS-2016"
> LIC_FILES_CHKSUM = "file://LICENSE.md;md5=239668a7c6066d9e0c5382e9c8c6c0e1"
I looked at
https://github.com/kjd/idna/blob/master/LICENSE.md
https://pypi.org/project/idna/
and they seem to indicate that it is BSD-3-Clause so where do the
other licenses come from ?
>
> SRC_URI[sha256sum] =
> "9d643ff0a55b762d5cdb124b8eaa99c66322e2157b69160bc32796e824360e6d"
> --
> 2.33.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159093):
https://lists.openembedded.org/g/openembedded-core/message/159093
Mute This Topic: https://lists.openembedded.org/mt/87431709/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] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend
Hi Alex, It's not a case of simply deleting the so files we don't need since the mesa build system stuffs everything into a small number of files and then hard links them together. For example, the current unmodified oe-core build for qemux86-64 yields: $ ls -l tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk -rw-r--r-- 2 mac mac 7993248 Dec 2 09:13 tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk $ dpkg-deb -c tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/ -rwxr-xr-x root/root 17728664 2021-11-17 20:17 ./usr/lib/dri/crocus_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/i915_dri.so link to ./usr/lib/dri/crocus_dri.so -rwxr-xr-x root/root 15903952 2021-11-17 20:17 ./usr/lib/dri/i965_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/iris_dri.so link to ./usr/lib/dri/crocus_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/kms_swrast_dri.so link to ./usr/lib/dri/crocus_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/nouveau_vieux_dri.so link to ./usr/lib/dri/i965_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/r200_dri.so link to ./usr/lib/dri/i965_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/radeon_dri.so link to ./usr/lib/dri/i965_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/crocus_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/virtio_gpu_dri.so link to ./usr/lib/dri/crocus_dri.so drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/drirc.d/ -rw-r--r-- root/root 44273 2021-11-17 20:16 ./usr/share/drirc.d/00-mesa-defaults.conf If I prune the default configuration do_install:append so I only keep swrast_dri.so then I get: $ ls -l tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk -rw-r--r-- 2 mac mac 4247362 Dec 2 15:29 tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk $ dpkg-deb -c tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/ -rwxr-xr-x root/root 17728664 2021-11-17 20:17 ./usr/lib/dri/swrast_dri.so drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/drirc.d/ -rw-r--r-- root/root 44273 2021-11-17 20:16 ./usr/share/drirc.d/00-mesa-defaults.conf If I do no pruning but force: DRIDRIVERS = "" GALLIUMDRIVERS = "swrast" then I get: $ ls -l tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk -rw-r--r-- 2 mac mac 2590320 Dec 2 15:15 tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk $ dpkg-deb -c tmp-glibc/deploy/ipk/core2-64/mesa-megadriver_21.3.0-r0_core2-64.ipk drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/ -rwxr-xr-x root/root 11981240 2021-11-17 20:17 ./usr/lib/dri/kms_swrast_dri.so hrwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/lib/dri/swrast_dri.so link to ./usr/lib/dri/kms_swrast_dri.so drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/ drwxr-xr-x root/root 0 2021-11-17 20:17 ./usr/share/drirc.d/ -rw-r--r-- root/root 44273 2021-11-17 20:16 ./usr/share/drirc.d/00-mesa-defaults.conf This is an uncompressed saving of over five megabytes (32%) and a compressed saving of 1.6MiB (39%) (assuming that the ipk compression is indicative of whatever rootfs compression is used.) I tried just crocus and just iris and there were still savings, albeit not quite as large as for swrast. (I have to admit that when I first started investigating this I misread the numbers and thought they were a factor of ten higher. Nevertheless, it's clear that there is a difference.) Justin Bronder's suggestion has given me a workaround if you don't believe that the space saving is more generally useful. Thanks. Mike. On Wednesday 01 December 2021 at 21:33:39 +0100, Alexander Kanavin wrote: > I'd like to see specifics though to understand the use case better. What > kind of target you're on, how much space will be saved by only building the > driver you need and which driver is that? If the drivers are in separate > .so objects, you can simply delete the ones you don't need from > do_install_append. The build time savings would be very minimal. > > Alex > > > On Wed, 1 Dec 2021 at 19:06, Mike Crowe wrote: > > > Hi Alex, > > > > Thanks for responding. > > > > Just to make sure I understand,
[OE-core][dunfell 00/25] Pull request (cover letter only)
After some discussion with Richard on #yocto irc we've decided to drop the patch
status updates from this series.
The following changes since commit 44b1970c40e9d73f6e63fb10cdc55837a26f5921:
build-appliance-image: Update to dunfell head revision (2021-11-15 15:00:44
+)
are available in the Git repository at:
git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next
Alexander Kanavin (2):
linux-firmware: upgrade 20210919 -> 20211027
libpcre/libpcre2: correct SRC_URI
Anuj Mittal (1):
glibc-version.inc: remove branch= from GLIBC_GIT_URI
Bruce Ashfield (4):
linux-yocto/5.4: update to v5.4.154
linux-yocto/5.4: update to v5.4.155
linux-yocto/5.4: update to v5.4.156
linux-yocto/5.4: update to v5.4.158
Claus Stovgaard (1):
cups: Fix missing installation of cups sysv init scripts
Daniel Gomez (1):
os-release: Add DISTRO_CODENAME as vardeps for do_compile
Denys Dmytriyenko (1):
make-mod-scripts: pass CROSS_COMPILE to configure and build
Jon Mason (1):
scripts/lib/wic/help.py: Update Fedora Kickstart URLs
Khem Raj (1):
lrzsz: Use Cross AR during compile
Marta Rybczynska (1):
python3: upgrade 3.8.11 -> 3.8.12
Minjae Kim (1):
git: fix CVE-2021-40330
Peter Bergin (1):
systemd: add packageconfig for wheel-group
Richard Purdie (2):
scripts/oe-package-browser: Handle no packages being built
reproducible_build/package_XXX: Ensure SDE task is in dependency chain
Ross Burton (5):
vim: fix CVE-2021-3796, CVE-2021-3872, and CVE-2021-3875
vim: add patch number to CVE-2021-3778 patch
vim: fix CVE-2021-3927 and CVE-2021-3928
gmp: fix CVE-2021-43618
openssh: remove redundant BSD license
Steve Sakoman (1):
Revert "vim: fix 2021-3796"
Wang Mingyu (1):
openssh: Improve LICENSE to show BSD license variants.
Yi Zhao (1):
oeqa: fix warnings for append operators combined with +=
meta/classes/package_deb.bbclass | 4 +-
meta/classes/package_ipk.bbclass | 3 +-
meta/classes/package_rpm.bbclass | 3 +-
meta/classes/reproducible_build.bbclass | 2 +
meta/lib/oeqa/runtime/cases/ksample.py| 2 +-
meta/lib/oeqa/selftest/cases/imagefeatures.py | 2 +-
...mpilation-using-autoconf-detected-AR.patch | 36 ++
meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb | 1 +
.../openssh/openssh_8.2p1.bb | 2 +-
meta/recipes-core/glibc/glibc-version.inc | 2 +-
meta/recipes-core/os-release/os-release.bb| 4 +-
meta/recipes-core/systemd/systemd_244.5.bb| 2 +
.../git/files/CVE-2021-40330.patch| 108 ++
meta/recipes-devtools/git/git.inc | 4 +-
.../{python3_3.8.11.bb => python3_3.8.12.bb} | 4 +-
meta/recipes-extended/cups/cups.inc | 2 +-
...20210919.bb => linux-firmware_20211027.bb} | 4 +-
.../linux/linux-yocto-rt_5.4.bb | 6 +-
.../linux/linux-yocto-tiny_5.4.bb | 8 +-
meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 ++--
.../make-mod-scripts/make-mod-scripts_1.0.bb | 2 +-
.../gmp/gmp/cve-2021-43618.patch | 27 +
meta/recipes-support/gmp/gmp_6.2.0.bb | 1 +
.../recipes-support/libpcre/libpcre2_10.34.bb | 2 +-
meta/recipes-support/libpcre/libpcre_8.44.bb | 2 +-
...1-reading-character-past-end-of-line.patch | 62 ++
...28-using-freed-memory-when-replacing.patch | 83 ++
...eading-uninitialized-memory-when-giv.patch | 63 ++
...llegal-memory-access-if-buffer-name-.patch | 86 ++
...ml_get-error-after-search-with-range.patch | 72
...nvalid-memory-access-when-scrolling-.patch | 97
.../vim/files/CVE-2021-3778.patch | 24 +++-
.../vim/files/CVE-2021-3796.patch | 50
meta/recipes-support/vim/vim.inc | 10 +-
scripts/lib/wic/help.py | 4 +-
scripts/oe-pkgdata-browser| 2 +
36 files changed, 712 insertions(+), 96 deletions(-)
create mode 100644
meta/recipes-bsp/lrzsz/lrzsz-0.12.20/0001-Fix-cross-compilation-using-autoconf-detected-AR.patch
create mode 100644 meta/recipes-devtools/git/files/CVE-2021-40330.patch
rename meta/recipes-devtools/python/{python3_3.8.11.bb => python3_3.8.12.bb}
(99%)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20210919.bb =>
linux-firmware_20211027.bb} (99%)
create mode 100644 meta/recipes-support/gmp/gmp/cve-2021-43618.patch
create mode 100644
meta/recipes-support/vim/files/0001-patch-8.2.3581-reading-character-past-end-of-line.patch
create mode 100644
meta/recipes-support/vim/files/0002-patch-8.2.3428-using-freed-memory-when-replacing.patch
create mode 100644
meta/recipes-support/vim/files/0002-patch-8.2.3582-reading-uninitialized-memory-when-giv.patch
create mode 100644
meta/recipes-support/vim/files/0003-patch-8.2.3487-illegal-memo
Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries
On 12/2/21 12:09, Richard Purdie wrote:
> On Thu, 2021-12-02 at 12:03 +0100, Jacob Kroon wrote:
>> On 12/2/21 11:51, Richard Purdie wrote:
>>> On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
On 12/2/21 00:11, Richard Purdie wrote:
> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
>> Try to make sure that the RUNTIME dynamic entry size is the same for all
>> binaries produced with the native compiler. This is necessary in order to
>> produce identical binaries when using differently sized buildpaths. I've
>> tried using only patchelf, and keeping the linker flags as they are, but
>> I am unable to produce identical binaries. Has anyone else managed to do
>> this with patchelf ? If not, maybe we can write a new tool that can
>> handle it ?
>>
>> The build-id also needs to be removed since it is calculated based on
>> the data present at link time. This includes STAGING_LIBDIR_NATIVE
>> and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
>> temporarily
>> preserved since some recipes will execute the binaries during
>> do_install()
>> (for example python3-native). Later on these are removed in
>> chrpath.bbclass.
>>
>> This hack is the first step for producing identical native binaries when
>> using
>> different build paths. 'zstd-native' is a working example.
>>
>> Signed-off-by: Jacob Kroon
>> ---
>> meta/classes/chrpath.bbclass | 3 +++
>> meta/conf/bitbake.conf | 5 -
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> I'm a little torn on this. Our other option would be to hardcoded a
> specific
> dummy path and then edit it later to the correct value. That may be
> neater than
> adding the padding. It will change the end binaries but hopefully only
> after
> they're installed so should give the same net end result more neatly?
>
Hmm not sure I follow. This patch adds a new dummy rpath entry,
"/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
other value we would like to put there. If I understand you correctly,
we could perhaps pad one of the ones we already pass
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
with spaces, like:
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
>>>
>>>
>>> I'm wondering if:
>>>
>>> -Wl,-rpath,/not/exist/our-native-libdir-marker
>>> -Wl,-rpath,/not/exist/our-native-base-libdir-marker
>>>
>>> would work.
>>>
>>
>> Right, I'll give it a try.
>>
Unfortunatley this breaks building python3-native. Although it compiles,
during the build the python build scripts tries to import the created
modules, and if this fails (which it does) it renames the modules:
> *** WARNING: renaming "_curses" since importing it failed: libncurses.so.5:
> cannot open shared object file: No such file or directory
> *** WARNING: renaming "_curses_panel" since importing it failed:
> libpanel.so.5: cannot open shared object file: No such file or directory
> *** WARNING: renaming "_ssl" since importing it failed: libssl.so.3: cannot
> open shared object file: No such file or directory
> *** WARNING: renaming "_hashlib" since importing it failed: libssl.so.3:
> cannot open shared object file: No such file or directory
> *** WARNING: renaming "nis" since importing it failed: libnsl.so.3: cannot
> open shared object file: No such file or directory
> *** WARNING: renaming "_ctypes" since importing it failed: libffi.so.8:
> cannot open shared object file: No such file or directory
I suppose it tries to import using the built python which has those
phony rpaths, and can't find the per-recipe-sysroot
lbncurses.so.5/libpanel.so.5/etc and fails.
The new modules will be called:
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu_failed.so
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu_failed.so
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/_hashlib.cpython-310-x86_64-linux-gnu_failed.so
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/_ssl.cpython-310-x86_64-linux-gnu_failed.so
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/_curses_panel.cpython-310-x86_64-linux-gnu_failed.so
> sysroots-components/x86_64/python3-native/usr/lib/python3.10/lib-dynload/_curses.cpython-310-x86_64-linux-gnu_failed.so
which means any subsequent recipe that uses python3-native will fail to
import any of those modules.
I suspect it might not just be python that wants to run the produced
binaries during the build itself.
If that works that would be less intrusive I think.
> If we separate out the build-id patch we could hopefully get that piece
> merge
Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license
Cc'ing licens...@lists.yoctoproject.org to hopefully get knowledgeable people on the topic? Thanks, Quentin On Wed, Dec 01, 2021 at 06:30:39PM +0100, Konrad Weihmann wrote: > > > On 01.12.21 18:20, Quentin Schulz wrote: > > Hi Konrad, > > > > On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad Weihmann wrote: > > > I'm kind of following the argumentation in the commit message, still I see > > > differences between the Unicode-DFS-2016 template file and the text > > > downloadable from > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM&e= > > > . > > > > > > Not much, but enough to make me think, if we wouldn't instead need a > > > Unicode-DFS-2021 file and reference to that. > > > > > > > We'd need to upload the new license to spdx and I've absolutely no clue > > if the differences are enough to warrant a new SPDX entry... especially > > since AFAICT, it's just that some of the content is moved to > > copyright.txt (which is linked in the new license.txt) resulting to me > > to basically a noop? But me stating it was a match was incorrect, thanks > > for pointing this out. > > Yeah, I'm also not a 100% sure if that's worth all the hustle - maybe > someone with a more legal like background could just add her/his two cents, > so things could be cleaned up in a followup > > > > > > Anyway I fully support that change > > > > > > On a different note - I think any unicode license reference would also > > > need > > > a copy of > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA&e= > > > , as all the downloads point to that (and the license in just a subset of > > > a > > > broader scope of rights and regulations) - INAL, but from my limited legal > > > understanding we should reference both > > > > > > > AFAICT, this looks like it would be Unicode-TOU but it's again not a > > perfect match. > > > > So /me shrugs, don't know what we should be doing with that except > > fixing the warning one way or the other (preferrably the best one :) ). > > same here - *calling for lawyers to jump into the discussion* :) > > Still I think the patch should be picked as it is, as it clearly solves an > issue, that I've seen as well. > > > > > Cheers, > > Quentin > > > > > On 01.12.21 17:13, Quentin Schulz wrote: > > > > In addition to not being an SPDX license, Unicode license also isn't > > > > available in any of the LICENSE_PATH available in openembedded, meaning > > > > the following warning is printed: > > > > > > > > python3-idna: No generic license file exists for: Unicode in any > > > > provider [license-exists] > > > > > > > > Unfortunately the license is not really explicit in the project. After > > > > looking at the code, it seems that this license gets pulled by > > > > idna/idnadata.py and idna/uts46data.py which are auto-generated by > > > > tools/idna-data which downloads data from > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_-257Bversion-257D_ucd_&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=NVUVu2hKfeamx4mn_29KhgBwY_drrHGSIiEbbTpoUsk&e= > > > > and > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unicode.org_Public_idna_&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=XmJGToF17xNKllS2M3Zw4q82BF0PBORm7gMWm2E6sgA&e= > > > > which are covered by > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvVz0ry1MulM&e= > > > > as mentioned in > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_copyright.html&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=GCcxTAmd-wOZF6SPpTOHW392veMDM8RBwO_IAMvDbZA&e= > > > > . > > > > > > > > Comparing > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.unicode.org_license.txt&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=-XEY2f17PVO0eg4ZpVBl4VpV5wPmG0K8z8LDsTQAPRs7x2MriQXaHDjlbwAVuKMk&s=TL5gUxzxy8LLKVu26a2BDDq1J8fal1pDvV
Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision
On Thu, Dec 02, 2021 at 07:31:52AM -0500, Bruce Ashfield wrote: > > That would be great if you can do so. > > ok. Let's solve this with an explicit KBRANCH with your pinned SRCREVs > for now, and I'll update -dev to use versioned branches for the current > 5.16 cycle and all new versions that follow. Thanks Bruce. Kevin signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159088): https://lists.openembedded.org/g/openembedded-core/message/159088 Mute This Topic: https://lists.openembedded.org/mt/87421079/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: Make -dev kernel work for a fixed revision
On Thu, Dec 2, 2021 at 2:23 AM Kevin Hao wrote:
>
> On Wed, Dec 01, 2021 at 04:27:44PM -0500, Bruce Ashfield wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> >
> > On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie
> > wrote:
> > >
> > > On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote:
> > > > By default the -dev kernel uses the "AUTOREV" to pull in the branch
> > > > head as the revision. Some of our BSPs are based on the -dev kernel and
> > > > we choose to nail down the kernel to a specific revision when releasing
> > > > our product by using some setting like below:
> > > > PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev"
> > > > SRCREV_machine:pn-linux-yocto-dev =
> > > > "6fb48ae18a10770702266dd1f1aa500149e361ec"
> > > > KBRANCH:pn-linux-yocto-dev = "standard/x86"
> > > > LINUX_VERSION = "5.15"
> > > >
> > > > Since all the standard/* branches will be rebased after each kernel
> > > > version bump, we would get bitbake fetch failure due to that specific
> > > > commit is not reachable in the new version branch. This kind of issue
> > > > can be fixed by setting the "nobranch" parameter in the SRC_URI because
> > > > it will cause the fetcher to skip the SHA validation for the branch.
> > > > And this also won't cause other side effect because all the branches
> > > > will be created in the do_kernel_checkout() and the current branch will
> > > > be reset to the reversion we want in do_validate_branches().
> > > >
> > > > Signed-off-by: Kevin Hao
> > > > ---
> > > > meta/recipes-kernel/linux/linux-yocto-dev.bb | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > > b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > > index 6b6ea9a7e864..7204c3eddc11 100644
> > > > --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > > +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
> > > > @@ -19,7 +19,8 @@ include
> > > > recipes-kernel/linux/linux-yocto-dev-revisions.inc
> > > > KBRANCH = "standard/base"
> > > > KMETA = "kernel-meta"
> > > >
> > > > -SRC_URI =
> > > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine
> > > > \
> > > > +# Set nobranch to skip the SHA validation for branch if a fixed
> > > > revesion is used
> > > > +SRC_URI =
> > > > "git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name=machine;nobranch=1
> > > > \
> > > >
> > > > git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=master;destsuffix=${KMETA}"
> > > >
> > > > # Set default SRCREVs. Both the machine and meta SRCREVs are
> > > > statically set
> > >
> > > I'm afraid this looks to be a bit of a horrible workaround/hack. It
> > > happens that
> > > if you specify a branch and set nobranch it might do what you want but
> > > that
> > > certainly isn't by design.
> > >
> > > Either the revision is in the branch or it isn't. The error is telling
> > > you the
> > > configuration you set isn't valid and you really need to set a valid
> > > configuration, i.e. a revision and a branch or a revision and set
> > > nobranch but
> > > not both.
> > >
> > > I'm not sure I understand why the kernel would be rebasing after each
> > > kernel
> > > release? Is this because it is one of the unversioned branches?
> >
> > Yah, it is exactly that. The -dev kernel has always been a rebase
> > tree, like linux-next upstream.
> >
> > Since the BSP work started against it (the -dev tree), when I move on
> > from a -dev version, I've been saving all work into versioned branches
> > ... versus removing them (and storing the history in the
> > kernel-cache).
> >
> > That being said, we merged some code some time ago that allows the
> > -dev kernel to automatically switch to the versioned branches, versus
> > the rebased "standard/*" branches. (that supports existing releases
> > with the -dev kernel as I move the one in master to new versions).
> > Have a look at do_validate_branches(), but unfortunately the fetcher
> > error will have already been thrown and we can't adjust to the fixed
> > SRCREV.
> >
> > The issue here is the attempt to pin the revision (like Richard is
> > saying), since if you use AUTOREV the code I just mentioned code kicks
> > in to make sure a versioned branch is used. Nothing should be released
> > against -dev, so any issues with pinned SRCREVs and branches should be
> > transient.
> >
> > I've floated the idea a few times that now that versioned branches are
> > being created (to keep older dev kernels around) I could just create
> > the branches from the start as versioned, and then you wouldn't have
> > the issue you are seeing, even with a pinned SRCREV.
>
> That would be great if you can do so.
ok. Let's solve this with an explicit KBRANCH with your pinned SRCREVs
for now, and I'll update -dev to use versioned branches for the current
5.16 cycle and all new versions that follow.
Bruce
>
> > We ar
[OE-core] [dunfell][PATCH] go-helloworld: test at runtime
From: Alexander Kanavin
This adds a smoke check for whether the Go toolchain actually
produces working executables across a range of architectures.
(From OE-Core rev: 2819bb2cf22c6cfcaeaee79f0280097ec9cb9327)
Signed-off-by: Alexander Kanavin
Signed-off-by: Richard Purdie
---
meta/classes/testimage.bbclass| 2 +-
meta/lib/oeqa/runtime/cases/go.py | 19 +++
.../packagegroup-core-tools-testapps.bb | 7 +++
3 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 meta/lib/oeqa/runtime/cases/go.py
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index b1aef626f7..80c19b1e60 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -58,7 +58,7 @@ BASICTESTSUITE = "\
ping date df ssh scp python perl gi ptest parselogs \
logrotate connman systemd oe_syslog pam stap ldd xorg \
kernelmodule gcc buildcpio buildlzip buildgalculator \
-dnf rpm opkg apt weston"
+dnf rpm opkg apt weston go"
DEFAULT_TEST_SUITES = "${BASICTESTSUITE}"
diff --git a/meta/lib/oeqa/runtime/cases/go.py
b/meta/lib/oeqa/runtime/cases/go.py
new file mode 100644
index 00..89ba2c3ecb
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/go.py
@@ -0,0 +1,19 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.runtime.decorator.package import OEHasPackage
+
+class GoHelloworldTest(OERuntimeTestCase):
+@OETestDepends(['ssh.SSHTest.test_ssh'])
+@OEHasPackage(['go-helloworld'])
+def test_gohelloworld(self):
+cmd = "go-helloworld"
+status, output = self.target.run(cmd)
+msg = 'Exit status was not 0. Output: %s' % output
+self.assertEqual(status, 0, msg=msg)
+
+msg = 'Incorrect output: %s' % output
+self.assertEqual(output, "Hello, Go examples!", msg=msg)
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
index a5fc152859..3c946c57ef 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb
@@ -17,6 +17,12 @@ KEXECTOOLS_microblaze ?= ""
KEXECTOOLS_nios2 ?= ""
KEXECTOOLS_riscv64 ?= ""
+# go does not support ppc32, only ppc64
+# https://github.com/golang/go/issues/22885
+# gccgo may do better
+GOTOOLS ?= "go-helloworld"
+GOTOOLS:powerpc ?= ""
+
GSTEXAMPLES ?= "gst-examples"
GSTEXAMPLES_riscv64 = ""
@@ -48,4 +54,5 @@ RDEPENDS_${PN} = "\
${@bb.utils.contains('DISTRO_FEATURES', 'x11', "${X11TOOLS}", "", d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', "${X11GLTOOLS}", "",
d)} \
${@bb.utils.contains('DISTRO_FEATURES', '3g', "${3GTOOLS}", "", d)} \
+${GOTOOLS} \
"
--
2.20.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159086):
https://lists.openembedded.org/g/openembedded-core/message/159086
Mute This Topic: https://lists.openembedded.org/mt/87450623/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries
On Thu, 2021-12-02 at 12:03 +0100, Jacob Kroon wrote:
> On 12/2/21 11:51, Richard Purdie wrote:
> > On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
> > > On 12/2/21 00:11, Richard Purdie wrote:
> > > > On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
> > > > > Try to make sure that the RUNTIME dynamic entry size is the same for
> > > > > all
> > > > > binaries produced with the native compiler. This is necessary in
> > > > > order to
> > > > > produce identical binaries when using differently sized buildpaths.
> > > > > I've
> > > > > tried using only patchelf, and keeping the linker flags as they are,
> > > > > but
> > > > > I am unable to produce identical binaries. Has anyone else managed to
> > > > > do
> > > > > this with patchelf ? If not, maybe we can write a new tool that can
> > > > > handle it ?
> > > > >
> > > > > The build-id also needs to be removed since it is calculated based on
> > > > > the data present at link time. This includes STAGING_LIBDIR_NATIVE
> > > > > and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
> > > > > temporarily
> > > > > preserved since some recipes will execute the binaries during
> > > > > do_install()
> > > > > (for example python3-native). Later on these are removed in
> > > > > chrpath.bbclass.
> > > > >
> > > > > This hack is the first step for producing identical native binaries
> > > > > when using
> > > > > different build paths. 'zstd-native' is a working example.
> > > > >
> > > > > Signed-off-by: Jacob Kroon
> > > > > ---
> > > > > meta/classes/chrpath.bbclass | 3 +++
> > > > > meta/conf/bitbake.conf | 5 -
> > > > > 2 files changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > I'm a little torn on this. Our other option would be to hardcoded a
> > > > specific
> > > > dummy path and then edit it later to the correct value. That may be
> > > > neater than
> > > > adding the padding. It will change the end binaries but hopefully only
> > > > after
> > > > they're installed so should give the same net end result more neatly?
> > > >
> > >
> > > Hmm not sure I follow. This patch adds a new dummy rpath entry,
> > > "/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
> > > other value we would like to put there. If I understand you correctly,
> > > we could perhaps pad one of the ones we already pass
> > >
> > > -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
> > > -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
> > >
> > > with spaces, like:
> > >
> > > -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
> > > -Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
> >
> >
> > I'm wondering if:
> >
> > -Wl,-rpath,/not/exist/our-native-libdir-marker
> > -Wl,-rpath,/not/exist/our-native-base-libdir-marker
> >
> > would work.
> >
>
> Right, I'll give it a try.
>
> > > If that works that would be less intrusive I think.
> > >
> > > > If we separate out the build-id patch we could hopefully get that piece
> > > > merged
> > > > as that shouldn't be controversial?
> > > >
> > >
> > > Yes, I can split it out into a separate patch.
> > >
> > > But now that I've looked at this for a while, I've asked myself what
> > > good does all this do ? The only optimization I can think of is that if
> > > we rebuild a native recipes, and the sysroot component turns out the
> > > same, then we don't need to create a new sstate cache entry. So we save
> > > disk space, but disk space is cheap. We still need to build it. What I
> > > would like is to have a common sstate dir for multiple build
> > > directories. So if I build libtool-native in one build path, then at my
> > > other build path it would just pick it up from sstate cache when I build
> > > there. In the end, is that something that would be possible ?
> >
> > We originally started here with gcc-cross so lets consider that and multiple
> > build directories where a patch changes gcc-cross in a way that is
> > irrelavent to
> > the output.
> >
> > The "win" is that regardless of whether I build in location A or B, I get
> > the
> > same gcc-cross binary. Hash-equiv will then not rebuild the target binaries.
> > Yes, I pay the price of a gcc-cross rebuild but hashequiv saves the targets
> > rebuilding.
> >
> > Currently it would only happen if you always build gcc-cross in a specific
> > build
> > path.
> >
>
> I know the build path will change if I upgrade to a new version of gcc,
> but then the output is most definitely gonna change as well.
>
> > Like everything, it is a question of looking at the changes and deciding
> > whether
> > they are worth any maintenance burden/code complication or additional
> > overhead
> > they generate. I don't know the answer here yet but I do appreciate the
> > research
> > in helping get us data to make decisions on!
> >
>
> I was thinking if it was possible to add a "build-path-does-not-matter"
> .bbclass that would make the signatures independent of build path and
> then scan the output to make sure it
Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries
On 12/2/21 11:51, Richard Purdie wrote:
> On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
>> On 12/2/21 00:11, Richard Purdie wrote:
>>> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
Try to make sure that the RUNTIME dynamic entry size is the same for all
binaries produced with the native compiler. This is necessary in order to
produce identical binaries when using differently sized buildpaths. I've
tried using only patchelf, and keeping the linker flags as they are, but
I am unable to produce identical binaries. Has anyone else managed to do
this with patchelf ? If not, maybe we can write a new tool that can handle
it ?
The build-id also needs to be removed since it is calculated based on
the data present at link time. This includes STAGING_LIBDIR_NATIVE
and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
temporarily
preserved since some recipes will execute the binaries during do_install()
(for example python3-native). Later on these are removed in
chrpath.bbclass.
This hack is the first step for producing identical native binaries when
using
different build paths. 'zstd-native' is a working example.
Signed-off-by: Jacob Kroon
---
meta/classes/chrpath.bbclass | 3 +++
meta/conf/bitbake.conf | 5 -
2 files changed, 7 insertions(+), 1 deletion(-)
>>>
>>> I'm a little torn on this. Our other option would be to hardcoded a specific
>>> dummy path and then edit it later to the correct value. That may be neater
>>> than
>>> adding the padding. It will change the end binaries but hopefully only after
>>> they're installed so should give the same net end result more neatly?
>>>
>>
>> Hmm not sure I follow. This patch adds a new dummy rpath entry,
>> "/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
>> other value we would like to put there. If I understand you correctly,
>> we could perhaps pad one of the ones we already pass
>>
>> -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
>> -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
>>
>> with spaces, like:
>>
>> -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
>> -Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
>
>
> I'm wondering if:
>
> -Wl,-rpath,/not/exist/our-native-libdir-marker
> -Wl,-rpath,/not/exist/our-native-base-libdir-marker
>
> would work.
>
Right, I'll give it a try.
>> If that works that would be less intrusive I think.
>>
>>> If we separate out the build-id patch we could hopefully get that piece
>>> merged
>>> as that shouldn't be controversial?
>>>
>>
>> Yes, I can split it out into a separate patch.
>>
>> But now that I've looked at this for a while, I've asked myself what
>> good does all this do ? The only optimization I can think of is that if
>> we rebuild a native recipes, and the sysroot component turns out the
>> same, then we don't need to create a new sstate cache entry. So we save
>> disk space, but disk space is cheap. We still need to build it. What I
>> would like is to have a common sstate dir for multiple build
>> directories. So if I build libtool-native in one build path, then at my
>> other build path it would just pick it up from sstate cache when I build
>> there. In the end, is that something that would be possible ?
>
> We originally started here with gcc-cross so lets consider that and multiple
> build directories where a patch changes gcc-cross in a way that is irrelavent
> to
> the output.
>
> The "win" is that regardless of whether I build in location A or B, I get the
> same gcc-cross binary. Hash-equiv will then not rebuild the target binaries.
> Yes, I pay the price of a gcc-cross rebuild but hashequiv saves the targets
> rebuilding.
>
> Currently it would only happen if you always build gcc-cross in a specific
> build
> path.
>
I know the build path will change if I upgrade to a new version of gcc,
but then the output is most definitely gonna change as well.
> Like everything, it is a question of looking at the changes and deciding
> whether
> they are worth any maintenance burden/code complication or additional overhead
> they generate. I don't know the answer here yet but I do appreciate the
> research
> in helping get us data to make decisions on!
>
I was thinking if it was possible to add a "build-path-does-not-matter"
.bbclass that would make the signatures independent of build path and
then scan the output to make sure it didn't contain any references to
the build path. Then those recipes who didn't depend on build path could
inherit from that class, and then maybe their sstate could be reused
from multiple build directories ? Not sure reliable it would be though..
Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159084):
https://lists.openembedded.org/g/openembedded-core/message/159084
Mute This Topic: https://lists.openembedded.org/mt/87415016/21656
Group Owner:
Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries
On Thu, 2021-12-02 at 11:19 +0100, Jacob Kroon wrote:
> On 12/2/21 00:11, Richard Purdie wrote:
> > On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
> > > Try to make sure that the RUNTIME dynamic entry size is the same for all
> > > binaries produced with the native compiler. This is necessary in order to
> > > produce identical binaries when using differently sized buildpaths. I've
> > > tried using only patchelf, and keeping the linker flags as they are, but
> > > I am unable to produce identical binaries. Has anyone else managed to do
> > > this with patchelf ? If not, maybe we can write a new tool that can
> > > handle it ?
> > >
> > > The build-id also needs to be removed since it is calculated based on
> > > the data present at link time. This includes STAGING_LIBDIR_NATIVE
> > > and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
> > > temporarily
> > > preserved since some recipes will execute the binaries during do_install()
> > > (for example python3-native). Later on these are removed in
> > > chrpath.bbclass.
> > >
> > > This hack is the first step for producing identical native binaries when
> > > using
> > > different build paths. 'zstd-native' is a working example.
> > >
> > > Signed-off-by: Jacob Kroon
> > > ---
> > > meta/classes/chrpath.bbclass | 3 +++
> > > meta/conf/bitbake.conf | 5 -
> > > 2 files changed, 7 insertions(+), 1 deletion(-)
> >
> > I'm a little torn on this. Our other option would be to hardcoded a specific
> > dummy path and then edit it later to the correct value. That may be neater
> > than
> > adding the padding. It will change the end binaries but hopefully only after
> > they're installed so should give the same net end result more neatly?
> >
>
> Hmm not sure I follow. This patch adds a new dummy rpath entry,
> "/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
> other value we would like to put there. If I understand you correctly,
> we could perhaps pad one of the ones we already pass
>
> -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
> -Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
>
> with spaces, like:
>
> -Wl,-rpath,${STAGING_LIBDIR_NATIVE}
> -Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
I'm wondering if:
-Wl,-rpath,/not/exist/our-native-libdir-marker
-Wl,-rpath,/not/exist/our-native-base-libdir-marker
would work.
> If that works that would be less intrusive I think.
>
> > If we separate out the build-id patch we could hopefully get that piece
> > merged
> > as that shouldn't be controversial?
> >
>
> Yes, I can split it out into a separate patch.
>
> But now that I've looked at this for a while, I've asked myself what
> good does all this do ? The only optimization I can think of is that if
> we rebuild a native recipes, and the sysroot component turns out the
> same, then we don't need to create a new sstate cache entry. So we save
> disk space, but disk space is cheap. We still need to build it. What I
> would like is to have a common sstate dir for multiple build
> directories. So if I build libtool-native in one build path, then at my
> other build path it would just pick it up from sstate cache when I build
> there. In the end, is that something that would be possible ?
We originally started here with gcc-cross so lets consider that and multiple
build directories where a patch changes gcc-cross in a way that is irrelavent to
the output.
The "win" is that regardless of whether I build in location A or B, I get the
same gcc-cross binary. Hash-equiv will then not rebuild the target binaries.
Yes, I pay the price of a gcc-cross rebuild but hashequiv saves the targets
rebuilding.
Currently it would only happen if you always build gcc-cross in a specific build
path.
Like everything, it is a question of looking at the changes and deciding whether
they are worth any maintenance burden/code complication or additional overhead
they generate. I don't know the answer here yet but I do appreciate the research
in helping get us data to make decisions on!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159083):
https://lists.openembedded.org/g/openembedded-core/message/159083
Mute This Topic: https://lists.openembedded.org/mt/87415016/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries
On 12/2/21 00:11, Richard Purdie wrote:
> On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote:
>> Try to make sure that the RUNTIME dynamic entry size is the same for all
>> binaries produced with the native compiler. This is necessary in order to
>> produce identical binaries when using differently sized buildpaths. I've
>> tried using only patchelf, and keeping the linker flags as they are, but
>> I am unable to produce identical binaries. Has anyone else managed to do
>> this with patchelf ? If not, maybe we can write a new tool that can handle
>> it ?
>>
>> The build-id also needs to be removed since it is calculated based on
>> the data present at link time. This includes STAGING_LIBDIR_NATIVE
>> and STAGING_BASE_LIBDIR_NATIVE. Both will differ and they need to be
>> temporarily
>> preserved since some recipes will execute the binaries during do_install()
>> (for example python3-native). Later on these are removed in chrpath.bbclass.
>>
>> This hack is the first step for producing identical native binaries when
>> using
>> different build paths. 'zstd-native' is a working example.
>>
>> Signed-off-by: Jacob Kroon
>> ---
>> meta/classes/chrpath.bbclass | 3 +++
>> meta/conf/bitbake.conf | 5 -
>> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> I'm a little torn on this. Our other option would be to hardcoded a specific
> dummy path and then edit it later to the correct value. That may be neater
> than
> adding the padding. It will change the end binaries but hopefully only after
> they're installed so should give the same net end result more neatly?
>
Hmm not sure I follow. This patch adds a new dummy rpath entry,
"/rpath-padding-xxx...", then we remove it in chrpath. I don't know what
other value we would like to put there. If I understand you correctly,
we could perhaps pad one of the ones we already pass
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,${STAGING_BASE_LIBDIR_NATIVE}
with spaces, like:
-Wl,-rpath,${STAGING_LIBDIR_NATIVE}
-Wl,-rpath,"${STAGING_BASE_LIBDIR_NATIVE}${RPATH_PADDING}"
If that works that would be less intrusive I think.
> If we separate out the build-id patch we could hopefully get that piece merged
> as that shouldn't be controversial?
>
Yes, I can split it out into a separate patch.
But now that I've looked at this for a while, I've asked myself what
good does all this do ? The only optimization I can think of is that if
we rebuild a native recipes, and the sysroot component turns out the
same, then we don't need to create a new sstate cache entry. So we save
disk space, but disk space is cheap. We still need to build it. What I
would like is to have a common sstate dir for multiple build
directories. So if I build libtool-native in one build path, then at my
other build path it would just pick it up from sstate cache when I build
there. In the end, is that something that would be possible ?
Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159082):
https://lists.openembedded.org/g/openembedded-core/message/159082
Mute This Topic: https://lists.openembedded.org/mt/87415016/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][dunfell][PATCH 3/3] libsolv: update tag for missing CVEs
From: Ranjitsinh Rathod It seems like CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and CVE-2021-33938 are pointing to same patch as CVE-2021-3200 So add CVE tag inside the patch file which is the remedy for CVE-2021-33928, CVE-2021-33929, CVE-2021-33930 and CVE-2021-33938 Link: https://ubuntu.com/security/CVE-2021-3200 https://ubuntu.com/security/CVE-2021-33928 https://ubuntu.com/security/CVE-2021-33929 https://ubuntu.com/security/CVE-2021-33930 https://ubuntu.com/security/CVE-2021-33938 Signed-off-by: Ranjitsinh Rathod Signed-off-by: Ranjitsinh Rathod --- meta/recipes-extended/libsolv/files/CVE-2021-3200.patch | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/meta/recipes-extended/libsolv/files/CVE-2021-3200.patch b/meta/recipes-extended/libsolv/files/CVE-2021-3200.patch index 74164ab495..cc8f53cefd 100644 --- a/meta/recipes-extended/libsolv/files/CVE-2021-3200.patch +++ b/meta/recipes-extended/libsolv/files/CVE-2021-3200.patch @@ -11,9 +11,14 @@ been added. (Jobs may point inside the whatproviedes array, so we must not invalidate this area.) -Upstream-Status: Backport -https://github.com/openSUSE/libsolv/commit/0077ef29eb46d2e1df2f230fc95a1d9748d49dec +Upstream-Status: Backport [https://github.com/openSUSE/libsolv/commit/0077ef29eb46d2e1df2f230fc95a1d9748d49dec] CVE: CVE-2021-3200 +CVE: CVE-2021-33928 +CVE: CVE-2021-33929 +CVE: CVE-2021-33930 +CVE: CVE-2021-33938 +Signed-off-by: Ranjitsinh Rathod + Signed-off-by: Chee Yang Lee --- ext/testcase.c | 21 + -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#159081): https://lists.openembedded.org/g/openembedded-core/message/159081 Mute This Topic: https://lists.openembedded.org/mt/87449898/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][dunfell][PATCH 2/3] ncurses: Fix for CVE-2021-39537
From: Ranjitsinh Rathod
Add patch to fix CVE-2021-39537
Link:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/ncurses/patches/Attic/patch-ncurses_tinfo_captoinfo.c?rev=1.1&content-type=text/x-cvsweb-markup
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Ranjitsinh Rathod
---
.../ncurses/files/CVE-2021-39537.patch| 30 +++
meta/recipes-core/ncurses/ncurses_6.2.bb | 1 +
2 files changed, 31 insertions(+)
create mode 100644 meta/recipes-core/ncurses/files/CVE-2021-39537.patch
diff --git a/meta/recipes-core/ncurses/files/CVE-2021-39537.patch
b/meta/recipes-core/ncurses/files/CVE-2021-39537.patch
new file mode 100644
index 00..7655200350
--- /dev/null
+++ b/meta/recipes-core/ncurses/files/CVE-2021-39537.patch
@@ -0,0 +1,30 @@
+$NetBSD: patch-ncurses_tinfo_captoinfo.c,v 1.1 2021/10/09 07:52:36 wiz Exp $
+
+Fix for CVE-2021-39537 from upstream:
+https://github.com/ThomasDickey/ncurses-snapshots/commit/63ca9e061f4644795d6f3f559557f3e1ed8c738b#diff-7e95c7bc5f213e9be438e69a9d5d0f261a14952bcbd692f7b9014217b8047340
+
+CVE: CVE-2021-39537
+Upstream-Status: Backport
[http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/ncurses/patches/Attic/patch-ncurses_tinfo_captoinfo.c?rev=1.1&content-type=text/x-cvsweb-markup]
+Signed-off-by: Ranjitsinh Rathod
+
+--- a/ncurses/tinfo/captoinfo.c 2020-02-02 23:34:34.0 +
b/ncurses/tinfo/captoinfo.c
+@@ -216,12 +216,15 @@ cvtchar(register const char *sp)
+ }
+ break;
+ case '^':
++ len = 2;
+ c = UChar(*++sp);
+- if (c == '?')
++if (c == '?') {
+ c = 127;
+- else
++} else if (c == '\0') {
++len = 1;
++} else {
+ c &= 0x1f;
+- len = 2;
++ }
+ break;
+ default:
+ c = UChar(*sp);
diff --git a/meta/recipes-core/ncurses/ncurses_6.2.bb
b/meta/recipes-core/ncurses/ncurses_6.2.bb
index 76f0cf97f4..700464f70b 100644
--- a/meta/recipes-core/ncurses/ncurses_6.2.bb
+++ b/meta/recipes-core/ncurses/ncurses_6.2.bb
@@ -3,6 +3,7 @@ require ncurses.inc
SRC_URI += "file://0001-tic-hang.patch \
file://0002-configure-reproducible.patch \
file://0003-gen-pkgconfig.in-Do-not-include-LDFLAGS-in-generated.patch \
+ file://CVE-2021-39537.patch \
"
# commit id corresponds to the revision in package version
SRCREV = "a669013cd5e9d6434e5301348ea51baf306c93c4"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159080):
https://lists.openembedded.org/g/openembedded-core/message/159080
Mute This Topic: https://lists.openembedded.org/mt/87449897/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][dunfell][PATCH 1/3] gmp: Fix for CVE-2021-43618
From: Ranjitsinh Rathod
Add patch to fix CVE-2021-43618
Link: https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e
Signed-off-by: Ranjitsinh Rathod
Signed-off-by: Ranjitsinh Rathod
---
.../gmp/gmp/CVE-2021-43618.patch | 29 +++
meta/recipes-support/gmp/gmp_6.2.0.bb | 1 +
2 files changed, 30 insertions(+)
create mode 100644 meta/recipes-support/gmp/gmp/CVE-2021-43618.patch
diff --git a/meta/recipes-support/gmp/gmp/CVE-2021-43618.patch
b/meta/recipes-support/gmp/gmp/CVE-2021-43618.patch
new file mode 100644
index 00..0323a45c27
--- /dev/null
+++ b/meta/recipes-support/gmp/gmp/CVE-2021-43618.patch
@@ -0,0 +1,29 @@
+
+# HG changeset patch
+# User Marco Bodrato
+# Date 1634836009 -7200
+# Node ID 561a9c25298e17bb01896801ff353546c6923dbd
+# Parent e1fd9db13b475209a864577237ea4b9105b3e96e
+mpz/inp_raw.c: Avoid bit size overflows
+
+CVE: CVE-2021-43618
+Upstream-Status: Backport [https://gmplib.org/repo/gmp-6.2/rev/561a9c25298e]
+Signed-off-by: Ranjitsinh Rathod
+
+diff -r e1fd9db13b47 -r 561a9c25298e mpz/inp_raw.c
+--- a/mpz/inp_raw.cTue Dec 22 23:49:51 2020 +0100
b/mpz/inp_raw.cThu Oct 21 19:06:49 2021 +0200
+@@ -88,8 +88,11 @@
+
+ abs_csize = ABS (csize);
+
++ if (UNLIKELY (abs_csize > ~(mp_bitcnt_t) 0 / 8))
++return 0; /* Bit size overflows */
++
+ /* round up to a multiple of limbs */
+- abs_xsize = BITS_TO_LIMBS (abs_csize*8);
++ abs_xsize = BITS_TO_LIMBS ((mp_bitcnt_t) abs_csize * 8);
+
+ if (abs_xsize != 0)
+ {
+
diff --git a/meta/recipes-support/gmp/gmp_6.2.0.bb
b/meta/recipes-support/gmp/gmp_6.2.0.bb
index a19c74fca8..bd88aa95ef 100644
--- a/meta/recipes-support/gmp/gmp_6.2.0.bb
+++ b/meta/recipes-support/gmp/gmp_6.2.0.bb
@@ -12,6 +12,7 @@ SRC_URI =
"https://gmplib.org/download/${BPN}/${BP}${REVISION}.tar.bz2 \
file://use-includedir.patch \
file://0001-Append-the-user-provided-flags-to-the-auto-detected-.patch \
file://0001-confiure.ac-Believe-the-cflags-from-environment.patch \
+ file://CVE-2021-43618.patch \
"
SRC_URI[md5sum] = "c24161e0dd44cae78cd5f67193492a21"
SRC_URI[sha256sum] =
"f51c99cb114deb21a60075ffb494c1a210eb9d7cb729ed042ddb7de9534451ea"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159079):
https://lists.openembedded.org/g/openembedded-core/message/159079
Mute This Topic: https://lists.openembedded.org/mt/87449895/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] native/cross: make ar wrapper support to read options from file
On 12/2/21 4:49 PM, Jacob Kroon wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On 12/2/21 09:37, Hongxu Jia wrote:
>> If ar input params starts with @, it means to read options from file
>> $ ar -h
>> ...
>>@ - read options from
>> ...
>>
>> It failed to call ar wrapper to read options from file:
>> $ path_to/oe-core/scripts/native-intercept/ar
>> @bazel-out/k8-opt/bin/external/llvm-project/llvm/libSupport.a-2.params
>> |path_to/oe-core/scripts/native-intercept/ar: invalid option -- '@'
>> | Usage: path_to/oe-core/scripts/native-intercept/ar [emulation options]
>> [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin ] [member-name] [count]
>> archive-file file...
>>
>> If input params start with @, append option -D to argv list
>>
>> Signed-off-by: Hongxu Jia
>> ---
>> scripts/native-intercept/ar | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/scripts/native-intercept/ar b/scripts/native-intercept/ar
>> index dcc623e3ed..32f45171d6 100755
>> --- a/scripts/native-intercept/ar
>> +++ b/scripts/native-intercept/ar
>> @@ -19,6 +19,8 @@ argv = sys.argv
>> if argv[1].startswith('--'):
>> # No modifier given
>> None
>> +elif argv[1].startswith('@'):
>> +argv.append('-D')
>> else:
>> # remove the optional '-'
>> if argv[1][0] == '-':
>>
> I am a little surprised this works, since "-D" would be placed after any
> archive/member parameters. But if does, ok.
I've several tries, and append -D works well
> Otherwise maybe we should just give up if there is a '@' and fallback to
> not modifying the args, unless we want to process the file itself in the
> wrapper.
This is my original trying, if above failed in some cases, we have to
give up to support determinism for @
//Hongxu
> Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159078):
https://lists.openembedded.org/g/openembedded-core/message/159078
Mute This Topic: https://lists.openembedded.org/mt/87448903/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] native/cross: make ar wrapper support to read options from file
On 12/2/21 09:37, Hongxu Jia wrote:
> If ar input params starts with @, it means to read options from file
> $ ar -h
> ...
> @ - read options from
> ...
>
> It failed to call ar wrapper to read options from file:
> $ path_to/oe-core/scripts/native-intercept/ar
> @bazel-out/k8-opt/bin/external/llvm-project/llvm/libSupport.a-2.params
> |path_to/oe-core/scripts/native-intercept/ar: invalid option -- '@'
> | Usage: path_to/oe-core/scripts/native-intercept/ar [emulation options]
> [-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin ] [member-name] [count]
> archive-file file...
>
> If input params start with @, append option -D to argv list
>
> Signed-off-by: Hongxu Jia
> ---
> scripts/native-intercept/ar | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/native-intercept/ar b/scripts/native-intercept/ar
> index dcc623e3ed..32f45171d6 100755
> --- a/scripts/native-intercept/ar
> +++ b/scripts/native-intercept/ar
> @@ -19,6 +19,8 @@ argv = sys.argv
> if argv[1].startswith('--'):
> # No modifier given
> None
> +elif argv[1].startswith('@'):
> +argv.append('-D')
> else:
> # remove the optional '-'
> if argv[1][0] == '-':
>
I am a little surprised this works, since "-D" would be placed after any
archive/member parameters. But if does, ok.
Otherwise maybe we should just give up if there is a '@' and fallback to
not modifying the args, unless we want to process the file itself in the
wrapper.
Jacob
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159077):
https://lists.openembedded.org/g/openembedded-core/message/159077
Mute This Topic: https://lists.openembedded.org/mt/87448903/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] native/cross: make ar wrapper support to read options from file
If ar input params starts with @, it means to read options from file
$ ar -h
...
@ - read options from
...
It failed to call ar wrapper to read options from file:
$ path_to/oe-core/scripts/native-intercept/ar
@bazel-out/k8-opt/bin/external/llvm-project/llvm/libSupport.a-2.params
|path_to/oe-core/scripts/native-intercept/ar: invalid option -- '@'
| Usage: path_to/oe-core/scripts/native-intercept/ar [emulation options]
[-]{dmpqrstx}[abcDfilMNoPsSTuvV] [--plugin ] [member-name] [count]
archive-file file...
If input params start with @, append option -D to argv list
Signed-off-by: Hongxu Jia
---
scripts/native-intercept/ar | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/native-intercept/ar b/scripts/native-intercept/ar
index dcc623e3ed..32f45171d6 100755
--- a/scripts/native-intercept/ar
+++ b/scripts/native-intercept/ar
@@ -19,6 +19,8 @@ argv = sys.argv
if argv[1].startswith('--'):
# No modifier given
None
+elif argv[1].startswith('@'):
+argv.append('-D')
else:
# remove the optional '-'
if argv[1][0] == '-':
--
2.33.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159076):
https://lists.openembedded.org/g/openembedded-core/message/159076
Mute This Topic: https://lists.openembedded.org/mt/87448903/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
