[OE-core] [PATCH] binutils: apply override toolchain-clang last
From: Kai Kang
It disables gprofng for toolchain clang, so it should clear GPROFNG_ALTS
when clang is used. But override 'toolchain-clang' is applied before
overrides 'TRANSLATED_TARGET_ARCH' such as x86-64, then GPROFNG_ALTS is
still set and not cleared. Append 'forcevariable' to apply it last then
make it work as expected.
Signed-off-by: Kai Kang
---
meta/recipes-devtools/binutils/binutils.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/binutils/binutils.inc
b/meta/recipes-devtools/binutils/binutils.inc
index 4dde387a8a..c7113f8a1f 100644
--- a/meta/recipes-devtools/binutils/binutils.inc
+++ b/meta/recipes-devtools/binutils/binutils.inc
@@ -50,7 +50,7 @@ GPROFNG_ALTS:x86-64 = "${GPROFNGS}"
GPROFNG_ALTS:aarch64 = "${GPROFNGS}"
# it disables gprofng for clang and musl in the bb file
-GPROFNG_ALTS:toolchain-clang = ""
+GPROFNG_ALTS:toolchain-clang:forcevariable = ""
GPROFNG_ALTS:libc-musl = ""
LDGOLD_ALTS ?= "ld.gold dwp"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171165):
https://lists.openembedded.org/g/openembedded-core/message/171165
Mute This Topic: https://lists.openembedded.org/mt/93987802/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 v3] meson: make wrapper options sub-command specific
The meson-wrapper adds setup options to facilitate cross-compilation.
The current options are exclusive to the setup sub-command and might
cause issues with other sub-commands.
Update the wrapper to make options sub-command specific.
Signed-off-by: Liam Beguin
---
.../meson/meson/meson-wrapper | 21 +++
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper
b/meta/recipes-devtools/meson/meson/meson-wrapper
index c62007f5077e..fca64a569299 100755
--- a/meta/recipes-devtools/meson/meson/meson-wrapper
+++ b/meta/recipes-devtools/meson/meson/meson-wrapper
@@ -5,7 +5,7 @@ if [ -z "$OECORE_NATIVE_SYSROOT" ]; then
fi
if [ -z "$SSL_CERT_DIR" ]; then
-export SSL_CERT_DIR="${OECORE_NATIVE_SYSROOT}/etc/ssl/certs/"
+export SSL_CERT_DIR="$OECORE_NATIVE_SYSROOT/etc/ssl/certs/"
fi
# If these are set to a cross-compile path, meson will get confused and try to
@@ -13,7 +13,20 @@ fi
# config is already in meson.cross.
unset CC CXX CPP LD AR NM STRIP
+for arg in "$@"; do
+case "$arg" in
+-*) continue ;;
+*) SUBCMD="$arg"; break ;;
+esac
+done
+
+if [ "$SUBCMD" = "setup" ] || [ -d "$SUBCMD" ]; then
+MESON_SUB_OPTS=" \
+
--cross-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/${TARGET_PREFIX}meson.cross"
\
+--native-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/meson.native" \
+"
+fi
+
exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
- --cross-file
"${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross" \
- --native-file "${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
- "$@"
+"$@" \
+$MESON_SUB_OPTS
base-commit: a2659cc2bf5d3f1cedf5c52c3b45e0427d40732d
--
2.37.1.223.g6a475b71f8c4
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171164):
https://lists.openembedded.org/g/openembedded-core/message/171164
Mute This Topic: https://lists.openembedded.org/mt/93987385/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 3/3] create-pull-request: don't switch the git remote protocol to git://
From: Martin Jansa
Many git repos prefer https:// nowadays and many removed support
for git://.
This breaks the script when using github.com even when selected remote
is ssh (g...@github.com:openembedded/...), it will re-write it to git://
before calling git pull-request causing:
openembedded-core $ scripts/create-pull-request -u github -b jansa/artifacts -o
pull-kernel
NOTE: Assuming local branch HEAD, use -l to override.
fatal: unable to connect to github.com:
github.com[0: 140.82.121.3]: errno=Connection timed out
warn: No match for commit ea003bd026aa24bb4c8b7562f44ed6512e921259 found at
git://github.com/shr-distribution/oe-core
warn: Are you sure you pushed 'jansa/artifacts' there?
ERROR: git request-pull reported an error
Signed-off-by: Martin Jansa
Signed-off-by: Richard Purdie
(cherry picked from commit 64c466920b808c35d1ac87b47cf438bc79becea7)
Signed-off-by: Steve Sakoman
---
scripts/create-pull-request | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/create-pull-request b/scripts/create-pull-request
index 8eefcf63a5..2f91a355b0 100755
--- a/scripts/create-pull-request
+++ b/scripts/create-pull-request
@@ -128,7 +128,7 @@ PROTO_RE="[a-z][a-z+]*://"
GIT_RE="\(^\($PROTO_RE\)\?\)\($USER_RE@\)\?\([^:/]*\)[:/]\(.*\)"
REMOTE_URL=${REMOTE_URL%.git}
REMOTE_REPO=$(echo $REMOTE_URL | sed "s#$GIT_RE#\5#")
-REMOTE_URL=$(echo $REMOTE_URL | sed "s#$GIT_RE#git://\4/\5#")
+REMOTE_URL=$(echo $REMOTE_URL | sed "s#$GIT_RE#https://\4/\5#;)
if [ -z "$BRANCH" ]; then
BRANCH=$(git branch | grep -e "^\* " | cut -d' ' -f2)
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171163):
https://lists.openembedded.org/g/openembedded-core/message/171163
Mute This Topic: https://lists.openembedded.org/mt/93986857/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 2/3] vim: Upgrade 9.0.0541 -> 9.0.0598
From: Richard Purdie Includes a fix for CVE-2022-3278. Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 98c40271692147873a622e168e8b2e90a9fcc54c) Signed-off-by: Steve Sakoman --- meta/recipes-support/vim/vim.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-support/vim/vim.inc b/meta/recipes-support/vim/vim.inc index 8a914ae524..f2cd235329 100644 --- a/meta/recipes-support/vim/vim.inc +++ b/meta/recipes-support/vim/vim.inc @@ -20,8 +20,8 @@ SRC_URI = "git://github.com/vim/vim.git;branch=master;protocol=https \ file://no-path-adjust.patch \ " -PV .= ".0541" -SRCREV = "ee7c8d999beb847457f768757b1bdcd76391c1f4" +PV .= ".0598" +SRCREV = "8279af514ca7e5fd3c31cf13b0864163d1a0bfeb" # Remove when 8.3 is out UPSTREAM_VERSION_UNKNOWN = "1" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171162): https://lists.openembedded.org/g/openembedded-core/message/171162 Mute This Topic: https://lists.openembedded.org/mt/93986856/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][dunfell 1/3] bluez: CVE-2022-39176 BlueZ allows physically proximate attackers
From: Hitendra Prajapati
Source: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1977968
MR: 122140
Type: Security Fix
Disposition: Backport from
https://launchpad.net/ubuntu/+source/bluez/5.53-0ubuntu3.6
ChangeID: b989c7670a9b2bd1d11221e981eab0d162f3271c
Description:
CVE-2022-39176 bluez: BlueZ allows physically proximate attackers to
obtain sensitive information because profiles/audio/avrcp.c does not validate
params_len.
Affects "bluez < 5.59"
Signed-off-by: Hitendra Prajapati
Signed-off-by: Steve Sakoman
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
.../bluez5/bluez5/CVE-2022-39176.patch| 126 ++
2 files changed, 127 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 4d4348898a..eaac9ee849 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -56,6 +56,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://CVE-2021-3588.patch \
file://CVE-2021-3658.patch \
file://CVE-2022-0204.patch \
+ file://CVE-2022-39176.patch \
"
S = "${WORKDIR}/bluez-${PV}"
diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
new file mode 100644
index 00..7bd1f5f80f
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
@@ -0,0 +1,126 @@
+From 752c7f707c3cc1eb12eadc13bc336a5c484d4bdf Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Wed, 28 Sep 2022 10:45:53 +0530
+Subject: [PATCH] CVE-2022-39176
+
+Upstream-Status: Backport
[https://launchpad.net/ubuntu/+source/bluez/5.53-0ubuntu3.6]
+CVE: CVE-2022-39176
+Signed-off-by: Hitendra Prajapati
+---
+ profiles/audio/avdtp.c | 56 +++---
+ profiles/audio/avrcp.c | 8 ++
+ 2 files changed, 44 insertions(+), 20 deletions(-)
+
+diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
+index 782268c..0adf413 100644
+--- a/profiles/audio/avdtp.c
b/profiles/audio/avdtp.c
+@@ -1261,43 +1261,53 @@ struct avdtp_remote_sep *avdtp_find_remote_sep(struct
avdtp *session,
+ return NULL;
+ }
+
+-static GSList *caps_to_list(uint8_t *data, int size,
++static GSList *caps_to_list(uint8_t *data, size_t size,
+ struct avdtp_service_capability **codec,
+ gboolean *delay_reporting)
+ {
++ struct avdtp_service_capability *cap;
+ GSList *caps;
+- int processed;
+
+ if (delay_reporting)
+ *delay_reporting = FALSE;
+
+- for (processed = 0, caps = NULL; processed + 2 <= size;) {
+- struct avdtp_service_capability *cap;
+- uint8_t length, category;
++ if (size < sizeof(*cap))
++ return NULL;
++
++ for (caps = NULL; size >= sizeof(*cap);) {
++ struct avdtp_service_capability *cpy;
+
+- category = data[0];
+- length = data[1];
++ cap = (struct avdtp_service_capability *)data;
+
+- if (processed + 2 + length > size) {
++ if (sizeof(*cap) + cap->length > size) {
+ error("Invalid capability data in getcap resp");
+ break;
+ }
+
+- cap = g_malloc(sizeof(struct avdtp_service_capability) +
+- length);
+- memcpy(cap, data, 2 + length);
++ if (cap->category == AVDTP_MEDIA_CODEC &&
++ cap->length < sizeof(**codec)) {
++ error("Invalid codec data in getcap resp");
++ break;
++ }
++
++ cpy = btd_malloc(sizeof(*cpy) + cap->length);
++ memcpy(cpy, cap, sizeof(*cap) + cap->length);
+
+- processed += 2 + length;
+- data += 2 + length;
++ size -= sizeof(*cap) + cap->length;
++ data += sizeof(*cap) + cap->length;
+
+- caps = g_slist_append(caps, cap);
++ caps = g_slist_append(caps, cpy);
+
+- if (category == AVDTP_MEDIA_CODEC &&
+- length >=
+- sizeof(struct avdtp_media_codec_capability))
+- *codec = cap;
+- else if (category == AVDTP_DELAY_REPORTING && delay_reporting)
+- *delay_reporting = TRUE;
++ switch (cap->category) {
++ case AVDTP_MEDIA_CODEC:
++ if (codec)
++ *codec = cpy;
++ break;
++ case AVDTP_DELAY_REPORTING:
++ if (delay_reporting)
++
[OE-core][dunfell 0/3] Patch review
Please review this set of patches for dunfell and have comments back by end of day Thursday. Passed a-full on autobuilder: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4278 The following changes since commit 6227efbf03d2e7ca773ab29177705203f2550722: linux-firmware: package new Qualcomm firmware (2022-09-26 12:29:44 -1000) are available in the Git repository at: https://git.openembedded.org/openembedded-core-contrib stable/dunfell-nut http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-nut Hitendra Prajapati (1): bluez: CVE-2022-39176 BlueZ allows physically proximate attackers Martin Jansa (1): create-pull-request: don't switch the git remote protocol to git:// Richard Purdie (1): vim: Upgrade 9.0.0541 -> 9.0.0598 meta/recipes-connectivity/bluez5/bluez5.inc | 1 + .../bluez5/bluez5/CVE-2022-39176.patch| 126 ++ meta/recipes-support/vim/vim.inc | 4 +- scripts/create-pull-request | 2 +- 4 files changed, 130 insertions(+), 3 deletions(-) create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171160): https://lists.openembedded.org/g/openembedded-core/message/171160 Mute This Topic: https://lists.openembedded.org/mt/93986852/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] scripts/oe-setup-builddir: do not read TEMPLATECONF from templateconf.cfg
> -Original Message- > From: openembedded-core@lists.openembedded.org > On Behalf Of Alexander Kanavin > Sent: den 28 september 2022 23:19 > To: openembedded-core@lists.openembedded.org > Cc: Alexander Kanavin > Subject: [OE-core] [PATCH] scripts/oe-setup-builddir: do not read > TEMPLATECONF from templateconf.cfg > > Also, write to it only if it does not already exist. > > As discussed here[1], reading from templateconf.cfg serves no purpose: > it exists only if the build directory has already been initialized, and so > the scripts will not change anything in the build directory anyway. > > My adjustment is to keep the file however; it is useful as a pointer > to the original template, which can be utilized by config management > tools in the future. > > [1] > https://lists.openembedded.org/g/openembedded-architecture/topic/template_handling_in_oe_core/93968540 > > Signed-off-by: Alexander Kanavin > --- > scripts/oe-setup-builddir | 14 +++--- > 1 file changed, 3 insertions(+), 11 deletions(-) > > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir > index e3c8c6d437..3a91bbf5b1 100755 > --- a/scripts/oe-setup-builddir > +++ b/scripts/oe-setup-builddir > @@ -34,16 +34,6 @@ chmod -st "$BUILDDIR/conf" 2>/dev/null || echo > "WARNING: unable to chmod $BUILDD > > cd "$BUILDDIR" || die "Failed to change directory to $BUILDDIR!" > > -if [ -z "$TEMPLATECONF" ] && [ -f "$BUILDDIR/conf/templateconf.cfg" ]; then > -TEMPLATECONF=$(cat "$BUILDDIR/conf/templateconf.cfg") > -# The following two are no longer valid; unsetting them will > automatically get them replaced > -# with correct ones. > -if [ "$TEMPLATECONF" = meta/conf ] || [ "$TEMPLATECONF" = meta-poky/conf > ]; then > -unset TEMPLATECONF > -rm "$BUILDDIR/conf/templateconf.cfg" > -fi > -fi > - > . "$OEROOT/.templateconf" > > # Keep the original TEMPLATECONF before possibly prefixing it with > $OEROOT below. > @@ -132,4 +122,6 @@ fi > [ ! -r "$OECORENOTESCONF" ] || cat "$OECORENOTESCONF" > unset OECORENOTESCONF > > -echo "$ORG_TEMPLATECONF" >"$BUILDDIR/conf/templateconf.cfg" > +if [ ! -f "$BUILDDIR/conf/templateconf.cfg" ]; then > + echo "$ORG_TEMPLATECONF" >"$BUILDDIR/conf/templateconf.cfg" The rest of the file uses four spaces for indentation. RP: I saw you have this in master-next already so I guess it's easiest for you to fix it there. > +fi > -- > 2.30.2 //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171159): https://lists.openembedded.org/g/openembedded-core/message/171159 Mute This Topic: https://lists.openembedded.org/mt/93982355/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/3] systemd: generate manpages indexes
From: Daniel McGregor
Now that python3-lxml is in core, use it to generate
systemd.directives and systemd.index manual pages.
Signed-off-by: Daniel McGregor
---
meta/recipes-core/systemd/systemd_251.4.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/systemd/systemd_251.4.bb
b/meta/recipes-core/systemd/systemd_251.4.bb
index 910ea71bf64..b4ad7e45eb0 100644
--- a/meta/recipes-core/systemd/systemd_251.4.bb
+++ b/meta/recipes-core/systemd/systemd_251.4.bb
@@ -159,7 +159,10 @@ PACKAGECONFIG[localed] = "-Dlocaled=true,-Dlocaled=false"
PACKAGECONFIG[logind] = "-Dlogind=true,-Dlogind=false"
PACKAGECONFIG[lz4] = "-Dlz4=true,-Dlz4=false,lz4"
PACKAGECONFIG[machined] = "-Dmachined=true,-Dmachined=false"
-PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,libxslt-native xmlto-native
docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
+PACKAGECONFIG[manpages] = "-Dman=true,-Dman=false,python3-lxml-native
xmlto-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
+# Ensure we're seeing the XML catalog from the build system and not the host.
+# Otherwise, the build may fail generating the manpages.
+export XML_CATALOG_FILES="${STAGING_ETCDIR_NATIVE}/xml/catalog"
PACKAGECONFIG[microhttpd] =
"-Dmicrohttpd=true,-Dmicrohttpd=false,libmicrohttpd"
PACKAGECONFIG[myhostname] =
"-Dnss-myhostname=true,-Dnss-myhostname=false,,libnss-myhostname"
PACKAGECONFIG[networkd] = "-Dnetworkd=true,-Dnetworkd=false"
--
2.37.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171158):
https://lists.openembedded.org/g/openembedded-core/message/171158
Mute This Topic: https://lists.openembedded.org/mt/93983398/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/3] gcc: set the default target arch
From: Daniel McGregor
The default x86-64 architecture for target gcc (ie, the one in poky
build appliances) is native. Since we have a variety of build systems
it will occasionally produce instructions that don't work on all of
our development system.
Instead, set gcc's default architecture to the one specified in
TUNE_CC_ARCH, that guarantees that gcc-runtime and any binaries
produced are compatible with the target machine type.
Signed-off-by: Daniel McGregor
---
meta/recipes-devtools/gcc/gcc-common.inc | 10 ++
meta/recipes-devtools/gcc/gcc-target.inc | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index 2abc0e355d7..d3b36937bf4 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -32,6 +32,16 @@ def get_gcc_float_setting(bb, d):
get_gcc_float_setting[vardepvalue] = "${@get_gcc_float_setting(bb, d)}"
+def get_gcc_x86_64_arch_setting(bb, d):
+import re
+march = re.match(r'^.*-march=([^\s]*)', d.getVar('TUNE_CCARGS'))
+if march:
+return "--with-arch=%s " % march.group(1)
+# The earliest supported x86-64 CPU
+return "--with-arch=core2"
+
+get_gcc_x86_64_arch_setting[vardepvalue] = "${@get_gcc_x86_64_arch_setting(bb,
d)}"
+
def get_gcc_mips_plt_setting(bb, d):
if d.getVar('TRANSLATED_TARGET_ARCH') in [ 'mips', 'mipsel' ] and
bb.utils.contains('DISTRO_FEATURES', 'mplt', True, False, d):
return "--with-mips-plt"
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
b/meta/recipes-devtools/gcc/gcc-target.inc
index cc65e995c30..7dac3ef422c 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -19,7 +19,7 @@ EXTRA_OECONF:append:armv6:class-target = "
--with-arch=armv6${ARMFPARCHEXT}"
EXTRA_OECONF:append:armv7a:class-target = " --with-arch=armv7-a${ARMFPARCHEXT}"
EXTRA_OECONF:append:armv7ve:class-target = "
--with-arch=armv7ve${ARMFPARCHEXT}"
EXTRA_OECONF:append:arc:class-target = " --with-cpu=${TUNE_PKGARCH}"
-EXTRA_OECONF:append:x86-64:class-target = " --with-arch=native"
+EXTRA_OECONF:append:x86-64:class-target = " ${@get_gcc_x86_64_arch_setting(bb,
d)}"
# libcc1 requres gcc_cv_objdump when cross build, but gcc_cv_objdump is
# set in subdir gcc, so subdir libcc1 can't use it, export it here to
--
2.37.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171157):
https://lists.openembedded.org/g/openembedded-core/message/171157
Mute This Topic: https://lists.openembedded.org/mt/93983396/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/3] coreutils: add openssl PACKAGECONFIG
From: Daniel McGregor coreutils-native will pick up openssl on the host if it's GPL compatible (version >= 3), which causes uninative failures with hosts that don't have openssl3. Add a PACKAGECONFIG entry for openssl so it can be enabled, but isn't by default. Signed-off-by: Daniel McGregor --- meta/recipes-core/coreutils/coreutils_9.1.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-core/coreutils/coreutils_9.1.bb b/meta/recipes-core/coreutils/coreutils_9.1.bb index 55663c77136..4807eefd04d 100644 --- a/meta/recipes-core/coreutils/coreutils_9.1.bb +++ b/meta/recipes-core/coreutils/coreutils_9.1.bb @@ -46,6 +46,7 @@ PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl," PACKAGECONFIG[xattr] = "--enable-xattr,--disable-xattr,attr," PACKAGECONFIG[single-binary] = "--enable-single-binary,--disable-single-binary,," PACKAGECONFIG[selinux] = "--with-selinux,--without-selinux,libselinux" +PACKAGECONFIG[openssl] = "--with-openssl=yes,--with-openssl=no,openssl" # [ df mktemp nice printenv base64 gets a special treatment and is not included in this bindir_progs = "arch basename chcon cksum comm csplit cut dir dircolors dirname du \ -- 2.37.3 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171156): https://lists.openembedded.org/g/openembedded-core/message/171156 Mute This Topic: https://lists.openembedded.org/mt/93983391/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] glibc-locale: explicitly remove empty dirs in ${libdir}
glibc-locale defaults to ENABLE_BINARY_LOCALE_GENERATION ?= "0", but gets
changed to "1" in the default-distrovars.inc
When it is explicitly set back to "0", it fails with this error:
ERROR: glibc-locale-2.36-r0 do_package: QA Issue: glibc-locale:
Files/directories were installed but not shipped in any package:
/usr/lib/locale
Please set FILES such that these items are packaged. Alternatively if they are
unneeded, avoid installing them or delete them within do_install.
glibc-locale: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: glibc-locale-2.36-r0 do_package: Fatal QA errors were found, failing
task.
There's a code to remove empty dirs in ${libdir}, but it's keyed off of
PACKAGE_NO_GCONV to clean up $[libdir]/gconv, just extend it to also cover
other empty dirs, including ${libdir}/locale.
Signed-off-by: Denys Dmytriyenko
---
meta/recipes-core/glibc/glibc-locale.inc | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-core/glibc/glibc-locale.inc
b/meta/recipes-core/glibc/glibc-locale.inc
index b8de7d3192..7c14abfe99 100644
--- a/meta/recipes-core/glibc/glibc-locale.inc
+++ b/meta/recipes-core/glibc/glibc-locale.inc
@@ -87,10 +87,9 @@ do_install() {
if [ ${PACKAGE_NO_GCONV} -eq 0 ]; then
copy_locale_files ${libdir}/gconv 0755
copy_locale_files ${datadir}/i18n 0644
- else
- # Remove the libdir if it is empty when gconv is not copied
- find ${D}${libdir} -type d -empty -delete
fi
+ # Remove empty dirs in libdir when gconv or locales are not copied
+ find ${D}${libdir} -type d -empty -delete
copy_locale_files ${datadir}/locale 0644
install -m 0644 ${LOCALETREESRC}/SUPPORTED ${WORKDIR}/SUPPORTED
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171155):
https://lists.openembedded.org/g/openembedded-core/message/171155
Mute This Topic: https://lists.openembedded.org/mt/93983239/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] scripts/oe-setup-builddir: do not read TEMPLATECONF from templateconf.cfg
Also, write to it only if it does not already exist. As discussed here[1], reading from templateconf.cfg serves no purpose: it exists only if the build directory has already been initialized, and so the scripts will not change anything in the build directory anyway. My adjustment is to keep the file however; it is useful as a pointer to the original template, which can be utilized by config management tools in the future. [1] https://lists.openembedded.org/g/openembedded-architecture/topic/template_handling_in_oe_core/93968540 Signed-off-by: Alexander Kanavin --- scripts/oe-setup-builddir | 14 +++--- 1 file changed, 3 insertions(+), 11 deletions(-) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index e3c8c6d437..3a91bbf5b1 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -34,16 +34,6 @@ chmod -st "$BUILDDIR/conf" 2>/dev/null || echo "WARNING: unable to chmod $BUILDD cd "$BUILDDIR" || die "Failed to change directory to $BUILDDIR!" -if [ -z "$TEMPLATECONF" ] && [ -f "$BUILDDIR/conf/templateconf.cfg" ]; then -TEMPLATECONF=$(cat "$BUILDDIR/conf/templateconf.cfg") -# The following two are no longer valid; unsetting them will automatically get them replaced -# with correct ones. -if [ "$TEMPLATECONF" = meta/conf ] || [ "$TEMPLATECONF" = meta-poky/conf ]; then -unset TEMPLATECONF -rm "$BUILDDIR/conf/templateconf.cfg" -fi -fi - . "$OEROOT/.templateconf" # Keep the original TEMPLATECONF before possibly prefixing it with $OEROOT below. @@ -132,4 +122,6 @@ fi [ ! -r "$OECORENOTESCONF" ] || cat "$OECORENOTESCONF" unset OECORENOTESCONF -echo "$ORG_TEMPLATECONF" >"$BUILDDIR/conf/templateconf.cfg" +if [ ! -f "$BUILDDIR/conf/templateconf.cfg" ]; then + echo "$ORG_TEMPLATECONF" >"$BUILDDIR/conf/templateconf.cfg" +fi -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171154): https://lists.openembedded.org/g/openembedded-core/message/171154 Mute This Topic: https://lists.openembedded.org/mt/93982355/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH] externalsrc:git submodule--helper list unsupported
From: John Edward Broadbent
Git has removed support for "git submodule--helper list".
https://github.com/git/git/commit/31955475d1c283120d5d84247eb3fd55d9f5fdd9
This change provides an alternate method for gathering the submodules
information.
Tested:
Build recipes with and without submodules
Signed-off-by: Carson Labrado
Signed-off-by: John Edward Broadbent
---
meta/classes-recipe/externalsrc.bbclass | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/meta/classes-recipe/externalsrc.bbclass
b/meta/classes-recipe/externalsrc.bbclass
index ce753fce76..06a9548a20 100644
--- a/meta/classes-recipe/externalsrc.bbclass
+++ b/meta/classes-recipe/externalsrc.bbclass
@@ -230,15 +230,16 @@ def srctree_hash_files(d, srcdir=None):
env['GIT_INDEX_FILE'] = tmp_index.name
subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir,
env=env)
git_sha1 = subprocess.check_output(['git', 'write-tree'],
cwd=s_dir, env=env).decode("utf-8")
-submodule_helper = subprocess.check_output(['git',
'submodule--helper', 'list'], cwd=s_dir, env=env).decode("utf-8")
-for line in submodule_helper.splitlines():
-module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
-if os.path.isdir(module_dir):
-proc = subprocess.Popen(['git', 'add', '-A', '.'],
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
-proc.communicate()
-proc = subprocess.Popen(['git', 'write-tree'],
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
-stdout, _ = proc.communicate()
-git_sha1 += stdout.decode("utf-8")
+if os.path.exists(".gitmodules"):
+submodule_helper = subprocess.check_output(["git", "config",
"--file", ".gitmodules", "--get-regexp", "path"], cwd=s_dir,
env=env).decode("utf-8")
+for line in submodule_helper.splitlines():
+module_dir = os.path.join(s_dir,
line.rsplit(maxsplit=1)[1])
+if os.path.isdir(module_dir):
+proc = subprocess.Popen(['git', 'add', '-A', '.'],
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'],
cwd=module_dir, env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
with open(oe_hash_file, 'w') as fobj:
fobj.write(sha1)
--
2.37.3.998.g577e59143f-goog
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171153):
https://lists.openembedded.org/g/openembedded-core/message/171153
Mute This Topic: https://lists.openembedded.org/mt/93979781/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] opkg: enable zstd support
Thanks for doing the research.
What was the build time on the zstd L19 compression vs. xz? Was there
still an improvement?
On 9/28/22 11:50, Etienne Cordonnier wrote:
I tested it a bit more today. I used the standard poky's local.conf
and added those lines. You can see that at zstd level 9 there is still
a significant difference in the compression ratio with xz for gcc-dbg
which is a big file. At zstd level 19, gcc-dbg is 241MB big instead of
214MB with xz (12.6% more).
PACKAGE_CLASSES = "package_ipk"
ZSTD_DEFAULTS = "-T0 -19"
PACKAGECONFIG:append:pn-opkg-native = " zstd"
OPKGBUILDCMD = "opkg-build -Z zstd -a ${ZSTD_DEFAULTS}"
Zstd at level 9:
build$ ls -lh tmp-zstd-level9/deploy/ipk/core2-64/ --sort=size | head
-n10
total 1.5G
-rw-r--r-- 3 ecordonnier ecordonnier 302M Sep 28 18:33
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 249M Sep 28 18:33
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 106M Sep 28 18:33
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 44M Sep 28 18:33
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 26M Sep 28 18:33
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 23M Sep 28 18:33
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:32
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:33
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 28 18:33
coreutils-dbg_9.1-r0_core2-64.ipk
zstd at level 19:
build$ ls -lh tmp-zstd-level19/deploy/ipk/core2-64/ --sort=size |
head -n10
total 1.1G
-rw-r--r-- 3 ecordonnier ecordonnier 241M Sep 28 18:04
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 213M Sep 28 18:03
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 36M Sep 28 17:58
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 30M Sep 28 18:00
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 22M Sep 28 17:59
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 28 17:58
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 14M Sep 28 17:57
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:58
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:57
g++_12.2.0-r0_core2-64.ipk
xz at level 9 (the default):
build$ ls -lh tmp-xz/deploy/ipk/core2-64/ --sort=size | head -n10
total 963M
-rw-r--r-- 3 ecordonnier ecordonnier 214M Sep 14 10:44
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 193M Sep 14 10:44
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 35M Sep 14 10:44
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 32M Sep 14 10:44
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 14 10:44
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 19M Sep 14 10:44
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 14 10:44
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 14 10:44
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 11M Sep 14 10:44
g++_12.2.0-r0_core2-64.ipk
On Wed, Sep 14, 2022 at 5:42 PM Khem Raj wrote:
On Wed, Sep 14, 2022 at 8:37 AM Alex Stewart
wrote:
>
> Thanks for checking.
>
> I'd be interested to know if setting a higher compression level
for zstd
> can get us to a similar compression ratio to xz. If so, then I
think it
> could be some real value to distro maintainers to be able to *tune*
> their compression.
yeah it will be interesting to say try something like level 9 but
I think times
might regress with that but it might be good to know the balance
and perhaps
suggest size mode and performance mode of zstd instead of xz
--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)
alex.stew...@ni.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171152):
https://lists.openembedded.org/g/openembedded-core/message/171152
Mute This Topic: https://lists.openembedded.org/mt/93654146/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] opkg: enable zstd support
I tested it a bit more today. I used the standard poky's local.conf and
added those lines. You can see that at zstd level 9 there is still a
significant difference in the compression ratio with xz for gcc-dbg which
is a big file. At zstd level 19, gcc-dbg is 241MB big instead of 214MB with
xz (12.6% more).
PACKAGE_CLASSES = "package_ipk"
ZSTD_DEFAULTS = "-T0 -19"
PACKAGECONFIG:append:pn-opkg-native = " zstd"
OPKGBUILDCMD = "opkg-build -Z zstd -a ${ZSTD_DEFAULTS}"
Zstd at level 9:
build$ ls -lh tmp-zstd-level9/deploy/ipk/core2-64/ --sort=size | head -n10
total 1.5G
-rw-r--r-- 3 ecordonnier ecordonnier 302M Sep 28 18:33
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 249M Sep 28 18:33
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 106M Sep 28 18:33
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 44M Sep 28 18:33
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 26M Sep 28 18:33
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 23M Sep 28 18:33
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:32
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 15M Sep 28 18:33
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 28 18:33
coreutils-dbg_9.1-r0_core2-64.ipk
zstd at level 19:
build$ ls -lh tmp-zstd-level19/deploy/ipk/core2-64/ --sort=size | head -n10
total 1.1G
-rw-r--r-- 3 ecordonnier ecordonnier 241M Sep 28 18:04
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 213M Sep 28 18:03
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 36M Sep 28 17:58
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 30M Sep 28 18:00
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 22M Sep 28 17:59
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 28 17:58
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 14M Sep 28 17:57
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:58
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 28 17:57
g++_12.2.0-r0_core2-64.ipk
xz at level 9 (the default):
build$ ls -lh tmp-xz/deploy/ipk/core2-64/ --sort=size | head -n10
total 963M
-rw-r--r-- 3 ecordonnier ecordonnier 214M Sep 14 10:44
gcc-dbg_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 193M Sep 14 10:44
openssl-dbg_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 35M Sep 14 10:44
openssl-ptest_3.0.5-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 32M Sep 14 10:44
binutils-dbg_2.39-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 20M Sep 14 10:44
perl-ptest_5.36.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 19M Sep 14 10:44
gcc_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 13M Sep 14 10:44
elfutils-ptest_0.187-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 12M Sep 14 10:44
gcc-src_12.2.0-r0_core2-64.ipk
-rw-r--r-- 3 ecordonnier ecordonnier 11M Sep 14 10:44
g++_12.2.0-r0_core2-64.ipk
On Wed, Sep 14, 2022 at 5:42 PM Khem Raj wrote:
> On Wed, Sep 14, 2022 at 8:37 AM Alex Stewart wrote:
> >
> > Thanks for checking.
> >
> > I'd be interested to know if setting a higher compression level for zstd
> > can get us to a similar compression ratio to xz. If so, then I think it
> > could be some real value to distro maintainers to be able to *tune*
> > their compression.
>
> yeah it will be interesting to say try something like level 9 but I think
> times
> might regress with that but it might be good to know the balance and
> perhaps
> suggest size mode and performance mode of zstd instead of xz
>
> >
> > That's not blocking for your new PR though.
> >
> >
> > On 9/14/22 05:08, Etienne Cordonnier wrote:
> > > Also note that zstd's default compression level is 3 per default (from
> > > a 1 to 19 scale). I did not test other compression levels.
> > >
> > > On Wed, Sep 14, 2022 at 11:58 AM Etienne Cordonnier
> > > wrote:
> > >
> > > I ran a build of core-image-full-cmdline using xz and zstd, using
> > > pre-populated downloads and sstate-cache directories but with
> > > empty tmp directory. Here are the numbers:
> > > zstd:
> > > bitbake core-image-full-cmdline took 2m52.768s (real), the
> > > resulting directory tmp/deploy/ipk is 1.6GB big.
> > > xz:
> > > bitbake core-image-full-cmdline took 4m14.214s (real), the
> > > resulting directory tmp/deploy/ipk/ is 996M big
> > >
> > > So the build with xz is 47% slower (254/172) than with zstd for
> > > this "incremental build" use-case.
> > >
> > > See the 5 biggest packages, the difference in compression-ratio
> > > increases with big files:
> > > build$ ls -lh tmp-zstd/deploy/ipk/core2-64/ --sort=size | head -n5
> > > total 1.6G
> > > -rw-r--r-- 3 ecordonnier
Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
On Wed, 28 Sept 2022 at 14:45, Peter Kjellerstedt wrote: > Because, while we want the layers fetched to be present in bblayers.conf > by default, it is still expected that developers during development can > add and remove layers. And if a developer has, e.g., removed a layer, it > is not expected that sourcing oe-init-build-env again should restore the > removed layer. I wonder if we can somehow make oe-init-build-env indicate (in a way that is programmatically robust, e.g. perhaps not a marker in stdout) that it has initialized a new build directory. Ideas? > Since our wrapper is expected to behave as oe-init-build-env it must > also calculate the build directory as oe-init-build-env would. And no, > it is not hard to do, but it means code duplication and that we are > susceptible to upstream changes. It is not a major problem and it is > the way I will solve this if I cannot get a change accepted upstream, > but every such small addition adds to the maintenance burden. All you need is: os.path.exists(os.path.abspath(build_dir)) (probably abspath is unneeded either, it's just there to make clear what the full path is in case it does not exist) And no, that logic is not going to change upstream - it's far too basic and pervasive. Tweaking the list of layers by directly manipulating the config file content when there are tools that do this for you is, I think, a worse example of duplication. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171150): https://lists.openembedded.org/g/openembedded-core/message/171150 Mute This Topic: https://lists.openembedded.org/mt/93847437/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 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
> -Original Message- > From: Alexander Kanavin > Sent: den 28 september 2022 13:00 > To: Peter Kjellerstedt > Cc: Richard Purdie ; OE-core > > Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode > invalid paths for templates > > On Wed, 28 Sept 2022 at 11:54, Peter Kjellerstedt > wrote: > > If it is the latter, it wouldn't work (unless I yet again duplicate the > > code to figure out the build directory before sourcing the real > > oe-init-build-env) since before sourcing the real oe-init-build-env I > > cannot tell if there already is a bblayers.conf file in which case the > > wrapper should not add/remove any layers, and after sourcing the real > > oe-init-build-env it is too late as I then cannot distinguish between > > this being the first time oe-init-build-env is sourced or just a > > reinitialization of an already existing environment. > > Yes this is the scenario I was thinking of: what should happen inside > the wrapper: > > . oe-init-build-env (this takes the original poky template) > bitbake-layers add-layer meta-a > bitbake-layers add-layer meta-b > ... > > Why would you want to distinguish between whether this is against a > newly made dir or an older one? I just checked: adding a layer that > is already in bblayers.conf does nothing. Because, while we want the layers fetched to be present in bblayers.conf by default, it is still expected that developers during development can add and remove layers. And if a developer has, e.g., removed a layer, it is not expected that sourcing oe-init-build-env again should restore the removed layer. > > I'm also unsure why are you so adamantly against checking if the build > dir already exists before the fact. It's not that difficult (either > it's relative to `pwd` or an absolute path), and not likely to change > upstream. Since our wrapper is expected to behave as oe-init-build-env it must also calculate the build directory as oe-init-build-env would. And no, it is not hard to do, but it means code duplication and that we are susceptible to upstream changes. It is not a major problem and it is the way I will solve this if I cannot get a change accepted upstream, but every such small addition adds to the maintenance burden. > Alex //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171149): https://lists.openembedded.org/g/openembedded-core/message/171149 Mute This Topic: https://lists.openembedded.org/mt/93847437/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] gtk-icon-cache: Fix GTKIC_CMD if-else condition
GTKIC_CMD variable gets the wrong assignation leading into a post
install script error. Fix if-else condition in GTKIC_CMD variable
to assign gtk4-update-icon-cache when GTKIC_VERSION is 4 but
gtk-update-icon-cache when is 3.
Also, rename gtk-update-icon-cache-3.0.0 to gtk-update-icon-cache-3.0
to match the gtk-update-icon-cache binary name deployed in
meta/recipes-gnome/gtk+/gtk+3.inc.
Signed-off-by: Daniel Gomez
---
meta/classes-recipe/gtk-icon-cache.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes-recipe/gtk-icon-cache.bbclass
b/meta/classes-recipe/gtk-icon-cache.bbclass
index 17c7eb7a33..9ecb49916c 100644
--- a/meta/classes-recipe/gtk-icon-cache.bbclass
+++ b/meta/classes-recipe/gtk-icon-cache.bbclass
@@ -9,7 +9,7 @@ FILES:${PN} += "${datadir}/icons/hicolor"
GTKIC_VERSION ??= '3'
GTKPN = "${@ 'gtk4' if d.getVar('GTKIC_VERSION') == '4' else 'gtk+3' }"
-GTKIC_CMD = "${@ 'gtk-update-icon-cache-3.0.0' if d.getVar('GTKIC_VERSION') ==
'4' else 'gtk4-update-icon-cache' }"
+GTKIC_CMD = "${@ 'gtk4-update-icon-cache' if d.getVar('GTKIC_VERSION') == '4'
else 'gtk-update-icon-cache-3.0' }"
#gtk+3/gtk4 require GTK3DISTROFEATURES, DEPENDS on it make all the
#recipes inherit this class require GTK3DISTROFEATURES
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171148):
https://lists.openembedded.org/g/openembedded-core/message/171148
Mute This Topic: https://lists.openembedded.org/mt/93970944/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 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
On Wed, 28 Sept 2022 at 13:00, Alexander Kanavin via lists.openembedded.org wrote: > I'm also unsure why are you so adamantly against checking if the build > dir already exists before the fact. It's not that difficult (either > it's relative to `pwd` or an absolute path), and not likely to change > upstream. Which is a trivial one-liner in python: os.path.exists(os.path.abspath(build_dir)) Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171147): https://lists.openembedded.org/g/openembedded-core/message/171147 Mute This Topic: https://lists.openembedded.org/mt/93847437/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 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
On Wed, 28 Sept 2022 at 11:54, Peter Kjellerstedt wrote: > If it is the latter, it wouldn't work (unless I yet again duplicate the > code to figure out the build directory before sourcing the real > oe-init-build-env) since before sourcing the real oe-init-build-env I > cannot tell if there already is a bblayers.conf file in which case the > wrapper should not add/remove any layers, and after sourcing the real > oe-init-build-env it is too late as I then cannot distinguish between > this being the first time oe-init-build-env is sourced or just a > reinitialization of an already existing environment. Yes this is the scenario I was thinking of: what should happen inside the wrapper: . oe-init-build-env (this takes the original poky template) bitbake-layers add-layer meta-a bitbake-layers add-layer meta-b ... Why would you want to distinguish between whether this is against a newly made dir or an older one? I just checked: adding a layer that is already in bblayers.conf does nothing. I'm also unsure why are you so adamantly against checking if the build dir already exists before the fact. It's not that difficult (either it's relative to `pwd` or an absolute path), and not likely to change upstream. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171146): https://lists.openembedded.org/g/openembedded-core/message/171146 Mute This Topic: https://lists.openembedded.org/mt/93847437/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][Patch 1/2] webkitgtk: Upgrade to 2.36.6 minor update
From: Khem Raj
(From OE-Core rev: bee36428a45c6c0c24d4c0fcf64bd890f3481c4a)
Signed-off-by: Khem Raj
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
.../webkit/{webkitgtk_2.36.5.bb => webkitgtk_2.36.6.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-sato/webkit/{webkitgtk_2.36.5.bb => webkitgtk_2.36.6.bb}
(98%)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.36.5.bb
b/meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
similarity index 98%
rename from meta/recipes-sato/webkit/webkitgtk_2.36.5.bb
rename to meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
index b3fe357010..37b977f9ba 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.36.5.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
@@ -17,7 +17,7 @@ SRC_URI =
"https://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
file://0001-When-building-introspection-files-do-not-quote-CFLAG.patch \
"
-SRC_URI[sha256sum] =
"d5532fa884c943dc48f1911473dd663aba407a3b35caa7b04bac1419b41e5908"
+SRC_URI[sha256sum] =
"1193bc821946336776f0dfa5e0dca5651f1e57157eda12da4721d2441f24a61a"
inherit cmake pkgconfig gobject-introspection perlnative features_check
upstream-version-is-even gtk-doc
--
2.37.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171144):
https://lists.openembedded.org/g/openembedded-core/message/171144
Mute This Topic: https://lists.openembedded.org/mt/93969445/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][Patch 2/2] webkitgtk: Update to 2.36.7
From: Khem Raj
including fixes for CVE-2022-32893
(From OE-Core rev: edbfd06927ef4a9bb1ea1ff80fbc901ede89ce42)
Signed-off-by: Khem Raj
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
Signed-off-by: Teoh Jay Shen
---
.../webkit/{webkitgtk_2.36.6.bb => webkitgtk_2.36.7.bb}| 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-sato/webkit/{webkitgtk_2.36.6.bb => webkitgtk_2.36.7.bb}
(98%)
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
b/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
similarity index 98%
rename from meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
rename to meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
index 37b977f9ba..026e24ae39 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.36.6.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.36.7.bb
@@ -16,8 +16,7 @@ SRC_URI =
"https://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
file://reproducibility.patch \
file://0001-When-building-introspection-files-do-not-quote-CFLAG.patch \
"
-
-SRC_URI[sha256sum] =
"1193bc821946336776f0dfa5e0dca5651f1e57157eda12da4721d2441f24a61a"
+SRC_URI[sha256sum] =
"0c260cf2b32f0481d017670dfed1b61e554967cd067195606c9f9eb5fe731743"
inherit cmake pkgconfig gobject-introspection perlnative features_check
upstream-version-is-even gtk-doc
--
2.37.3
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171145):
https://lists.openembedded.org/g/openembedded-core/message/171145
Mute This Topic: https://lists.openembedded.org/mt/93969446/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 2/2] oe-setup-builddir: Do not hardcode invalid paths for templates
> -Original Message- > From: Alexander Kanavin > Sent: den 27 september 2022 23:50 > To: Peter Kjellerstedt > Cc: Richard Purdie ; OE-core > > Subject: Re: [OE-core] [PATCH 2/2] oe-setup-builddir: Do not hardcode > invalid paths for templates > > On Tue, 27 Sept 2022 at 23:31, Peter Kjellerstedt > wrote: > > I am not too fond of the "writing the config directly" idea. The reason > > for that is that things change upstream (as you are well aware of, that's > > after all the whole reason for the discussion). This is why I prefer to > > go through the templates and basically only provide the list of layers > > to add. That way when things change upstream in the template files, we > > automatically follow. (And if it has not been obvious before, our wrapper > > uses the bblayers.conf.sample file from meta-poky and just replaces the > > list of layers with our list of layers. Which of course sounds like then > > we could just write the final config file directly, but we also want to > > continue to rely on oe-init-build-env for determining _where_ to write > > the final files.) > > Wait, wait, wait. If so, you can initialize using the template from > poky, then you get BBPATH or BUILDDIR placed in the environment (by > oe-init-build-env) telling where the config files are. So you can > write to them directly (e.g. local.conf), or use 'bitbake-layers > add-layer' (or 'remove-layer') to tweak the list of layers using > supported tooling - after the initialization, but before any builds. > No? > > Alex I am not sure if you are suggesting that the user shall run `bitbake-layers add-layer` after sourcing oe-init-build-env, or if you mean that our wrapper should do it. If it is the former, then that is obviously not how we want things to work. The layers that are fetched shall by default be part of the build. That is an absolute requirement. There is no expectancy (or want) that the user shall have to add/remove the layers manually. If it is the latter, it wouldn't work (unless I yet again duplicate the code to figure out the build directory before sourcing the real oe-init-build-env) since before sourcing the real oe-init-build-env I cannot tell if there already is a bblayers.conf file in which case the wrapper should not add/remove any layers, and after sourcing the real oe-init-build-env it is too late as I then cannot distinguish between this being the first time oe-init-build-env is sourced or just a reinitialization of an already existing environment. Our philosophy when we originally set this up was to keep it simple and as close to how OE/Poky works as possible. That way, if the developers have any questions and look at the Yocto documentation, the commands suggested there should work the same for us. And that is what we get from using the templates and letting the init scripts provided by OE do the work. The fact that we use the bblayers.conf.sample file from meta-poky rather than providing our own shouldn't change that. It is just a way to avoid having to manually keep our sample file in sync with what happens in OE Core. //Peter -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#171143): https://lists.openembedded.org/g/openembedded-core/message/171143 Mute This Topic: https://lists.openembedded.org/mt/93847437/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] stress-cpu: disable float128 math on powerpc64 to avoid SIGILL
float128 requires instructions of xsmaddqp and xsmsubqp which are added to
qemu since v7.0 by the following commit.
https://github.com/qemu/qemu/commit/3bb1aed246d7b59ceee625a82628f7369d492a8f
While kirkstone is still at v6.2 and thus experiences SIGILL as follow
root@qemuppc64:~# stress-ng --cpu 2 --timeout 30s
stress-ng: info: [972] setting to a 30 second run per stressor
stress-ng: info: [972] dispatching hogs: 2 cpu
stress-ng: info: [973] stressor terminated with unexpected signal signal 4
'SIGILL'
This is specific to kirkstone since qemu on master branch has upgraded to v7.1.
Signed-off-by: He Zhe
---
...le-float128-math-on-powerpc64-to-avo.patch | 43 +++
.../stress-ng/stress-ng_0.13.12.bb| 4 +-
2 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch
diff --git
a/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch
b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch
new file mode 100644
index 00..bb35b3030a
--- /dev/null
+++
b/meta/recipes-extended/stress-ng/stress-ng-0.13.12/0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch
@@ -0,0 +1,43 @@
+From ea9ee4dd64ee88e03a959b2c694aa8feb53c7e78 Mon Sep 17 00:00:00 2001
+From: He Zhe
+Date: Wed, 28 Sep 2022 16:47:24 +0800
+Subject: [PATCH] stress-cpu: disable float128 math on powerpc64 to avoid
+ SIGILL
+
+float128 requires instructions of xsmaddqp and xsmsubqp which are added to
+qemu since v7.0 by the following commit.
+https://github.com/qemu/qemu/commit/3bb1aed246d7b59ceee625a82628f7369d492a8f
+
+While kirkstone is still at v6.2 and thus experiences SIGILL as follow
+root@qemuppc64:~# stress-ng --cpu 2 --timeout 30s
+stress-ng: info: [972] setting to a 30 second run per stressor
+stress-ng: info: [972] dispatching hogs: 2 cpu
+stress-ng: info: [973] stressor terminated with unexpected signal signal 4
'SIGILL'
+
+
+Upstream-Status: Inappropriate [This is specific to kirkstone since qemu on
+master branch has upgraded to v7.1.]
+
+Signed-off-by: He Zhe
+---
+ stress-cpu.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/stress-cpu.c b/stress-cpu.c
+index 0a08f1d1..2849e715 100644
+--- a/stress-cpu.c
b/stress-cpu.c
+@@ -41,6 +41,10 @@
+ #undef HAVE_FLOAT_DECIMAL128
+ #endif
+
++#if defined(STRESS_ARCH_PPC64)
++#undef HAVE_FLOAT128
++#endif
++
+ #define GAMMA
(0.57721566490153286060651209008240243104215933593992L)
+ #define OMEGA (0.5671432904097838726866221035554975381578718651L)
+ #define PSI (3.35988566624317755317201130291892717968890513373197L)
+--
+2.25.1
+
diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
index fe177a4de0..807ecd3466 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.13.12.bb
@@ -5,7 +5,9 @@ HOMEPAGE = "https://github.com/ColinIanKing/stress-ng#readme;
LICENSE = "GPL-2.0-only"
LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
-SRC_URI =
"git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master"
+SRC_URI =
"git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master \
+
file://0001-stress-cpu-disable-float128-math-on-powerpc64-to-avo.patch \
+ "
SRCREV = "f59bcb2fe1e25042e77d5e4942f72bfa026fa305"
S = "${WORKDIR}/git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171142):
https://lists.openembedded.org/g/openembedded-core/message/171142
Mute This Topic: https://lists.openembedded.org/mt/93968982/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] meson: make wrapper options sub-command specific
> -Original Message-
> From: openembedded-core@lists.openembedded.org
> On Behalf Of Liam Beguin
> Sent: den 28 september 2022 04:52
> To: liambeg...@gmail.com; openembedded-core@lists.openembedded.org
> Cc: alexandre.bell...@bootlin.com
> Subject: [OE-core] [PATCH v2] meson: make wrapper options sub-command specific
>
> The meson-wrapper adds setup options to facilitate cross-compilation.
> The current options are exclusive to the setup sub-command and might
> cause issues with other sub-commands.
>
> Update the wrapper to make options sub-command specific.
>
> Signed-off-by: Liam Beguin
> ---
> .../meson/meson/meson-wrapper | 19 ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/meta/recipes-devtools/meson/meson/meson-wrapper
> b/meta/recipes-devtools/meson/meson/meson-wrapper
> index c62007f5077e..866dc33cf4be 100755
> --- a/meta/recipes-devtools/meson/meson/meson-wrapper
> +++ b/meta/recipes-devtools/meson/meson/meson-wrapper
> @@ -13,7 +13,20 @@ fi
> # config is already in meson.cross.
> unset CC CXX CPP LD AR NM STRIP
>
> +for arg in "${@}"; do
> +case ${arg} in
> +-*) continue ;;
> +*) SUBCMD=${arg}; break ;;
> +esac
> +done
Change all "${...}" to "$..." above.
> +
> +if [ "x${SUBCMD}" == "xsetup" ] || [ -d ${SUBCMD} ]; then
== is a bashism, use = instead. Also, you know that $SUBCMD will never
have a - as its first character (due to the case statement above) so it
is safe to simplify the above to:
if [ "$SUBCMD" = setup ] || [ -d "$SUBCMD" ]; then
> +MESON_SUB_OPTS=" \
> +
> --cross-file="${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross"
> \
> +
> --native-file="${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
Change "${OECORE_NATIVE_SYSROOT}" to "$OECORE_NATIVE_SYSROOT".
And while at it, change it in the export line earlier in the file
as well.
> +"
> +fi
> +
> exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
> - --cross-file
> "${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross" \
> - --native-file "${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
> - "$@"
> +"$@" \
> +${MESON_SUB_OPTS}
Change "${MESON_SUB_OPTS}" to "$MESON_SUB_OPTS".
>
> base-commit: a2659cc2bf5d3f1cedf5c52c3b45e0427d40732d
> --
> 2.37.1.223.g6a475b71f8c4
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171141):
https://lists.openembedded.org/g/openembedded-core/message/171141
Mute This Topic: https://lists.openembedded.org/mt/93965305/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][master][kirkstone][PATCH] useradd-example: do not use unsupported clear text password
The clear text password support has been dropped. So let's just
use a normal ecrypted one. The password remains to be 'user3'.
Signed-off-by: Chen Qi
---
meta-skeleton/recipes-skeleton/useradd/useradd-example.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
b/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
index 3f4c42d714..cff624e2f9 100644
--- a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
+++ b/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
@@ -33,8 +33,8 @@ USERADD_PACKAGES = "${PN} ${PN}-user3"
USERADD_PARAM:${PN} = "-u 1200 -d /home/user1 -r -s /bin/bash user1; -u 1201
-d /home/user2 -r -s /bin/bash user2"
# user3 will be managed in the useradd-example-user3 pacakge:
-# As an example, we use the -P option to set clear text password for user3
-USERADD_PARAM:${PN}-user3 = "-u 1202 -d /home/user3 -r -s /bin/bash -P 'user3'
user3"
+# As an example, we use the -p option to set password ('user3') for user3
+USERADD_PARAM:${PN}-user3 = "-u 1202 -d /home/user3 -r -s /bin/bash -p
'\$6\$XAWr.8nc\$bUE4pYYaVb8n6BbnBitU0zeJMtfhTpFpiOBLL9zRl4e4YQo88UU4r/1kjRzmTimCy.BvDh4xoFwVqcO.pihLa1'
user3"
# GROUPADD_PARAM works the same way, which you set to the options
# you'd normally pass to the groupadd command. This will create
--
2.37.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171140):
https://lists.openembedded.org/g/openembedded-core/message/171140
Mute This Topic: https://lists.openembedded.org/mt/93968558/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [dunfell][PATCH] bluez: CVE-2022-39176 BlueZ allows physically proximate attackers
Source: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1977968
MR: 122140
Type: Security Fix
Disposition: Backport from
https://launchpad.net/ubuntu/+source/bluez/5.53-0ubuntu3.6
ChangeID: b989c7670a9b2bd1d11221e981eab0d162f3271c
Description:
CVE-2022-39176 bluez: BlueZ allows physically proximate attackers to
obtain sensitive information because profiles/audio/avrcp.c does not validate
params_len.
Affects "bluez < 5.59"
Signed-off-by: Hitendra Prajapati
---
meta/recipes-connectivity/bluez5/bluez5.inc | 1 +
.../bluez5/bluez5/CVE-2022-39176.patch| 126 ++
2 files changed, 127 insertions(+)
create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 4d4348898a..eaac9ee849 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -56,6 +56,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
file://CVE-2021-3588.patch \
file://CVE-2021-3658.patch \
file://CVE-2022-0204.patch \
+ file://CVE-2022-39176.patch \
"
S = "${WORKDIR}/bluez-${PV}"
diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
new file mode 100644
index 00..7bd1f5f80f
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2022-39176.patch
@@ -0,0 +1,126 @@
+From 752c7f707c3cc1eb12eadc13bc336a5c484d4bdf Mon Sep 17 00:00:00 2001
+From: Hitendra Prajapati
+Date: Wed, 28 Sep 2022 10:45:53 +0530
+Subject: [PATCH] CVE-2022-39176
+
+Upstream-Status: Backport
[https://launchpad.net/ubuntu/+source/bluez/5.53-0ubuntu3.6]
+CVE: CVE-2022-39176
+Signed-off-by: Hitendra Prajapati
+---
+ profiles/audio/avdtp.c | 56 +++---
+ profiles/audio/avrcp.c | 8 ++
+ 2 files changed, 44 insertions(+), 20 deletions(-)
+
+diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
+index 782268c..0adf413 100644
+--- a/profiles/audio/avdtp.c
b/profiles/audio/avdtp.c
+@@ -1261,43 +1261,53 @@ struct avdtp_remote_sep *avdtp_find_remote_sep(struct
avdtp *session,
+ return NULL;
+ }
+
+-static GSList *caps_to_list(uint8_t *data, int size,
++static GSList *caps_to_list(uint8_t *data, size_t size,
+ struct avdtp_service_capability **codec,
+ gboolean *delay_reporting)
+ {
++ struct avdtp_service_capability *cap;
+ GSList *caps;
+- int processed;
+
+ if (delay_reporting)
+ *delay_reporting = FALSE;
+
+- for (processed = 0, caps = NULL; processed + 2 <= size;) {
+- struct avdtp_service_capability *cap;
+- uint8_t length, category;
++ if (size < sizeof(*cap))
++ return NULL;
++
++ for (caps = NULL; size >= sizeof(*cap);) {
++ struct avdtp_service_capability *cpy;
+
+- category = data[0];
+- length = data[1];
++ cap = (struct avdtp_service_capability *)data;
+
+- if (processed + 2 + length > size) {
++ if (sizeof(*cap) + cap->length > size) {
+ error("Invalid capability data in getcap resp");
+ break;
+ }
+
+- cap = g_malloc(sizeof(struct avdtp_service_capability) +
+- length);
+- memcpy(cap, data, 2 + length);
++ if (cap->category == AVDTP_MEDIA_CODEC &&
++ cap->length < sizeof(**codec)) {
++ error("Invalid codec data in getcap resp");
++ break;
++ }
++
++ cpy = btd_malloc(sizeof(*cpy) + cap->length);
++ memcpy(cpy, cap, sizeof(*cap) + cap->length);
+
+- processed += 2 + length;
+- data += 2 + length;
++ size -= sizeof(*cap) + cap->length;
++ data += sizeof(*cap) + cap->length;
+
+- caps = g_slist_append(caps, cap);
++ caps = g_slist_append(caps, cpy);
+
+- if (category == AVDTP_MEDIA_CODEC &&
+- length >=
+- sizeof(struct avdtp_media_codec_capability))
+- *codec = cap;
+- else if (category == AVDTP_DELAY_REPORTING && delay_reporting)
+- *delay_reporting = TRUE;
++ switch (cap->category) {
++ case AVDTP_MEDIA_CODEC:
++ if (codec)
++ *codec = cpy;
++ break;
++ case AVDTP_DELAY_REPORTING:
++ if (delay_reporting)
++ *delay_reporting = TRUE;
++ break;
++
