[OE-core] [PATCH] packagegroups: remove strace and lttng-tools for rv32/musl
These tools are not yet ported to rv32/musl
Signed-off-by: Khem Raj
---
.../packagegroups/packagegroup-core-tools-debug.bb | 5 -
.../packagegroups/packagegroup-core-tools-profile.bb | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
index 81fbdf4608..283c1f1a35 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-debug.bb
@@ -13,9 +13,12 @@ PR = "r3"
MTRACE = ""
MTRACE_libc-glibc = "libc-mtrace"
+STRACE = "strace"
+STRACE_riscv32_libc-musl = ""
+
RDEPENDS_${PN} = "\
gdb \
gdbserver \
-strace \
${MTRACE} \
+${STRACE} \
"
diff --git a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
index 17b1391a47..1c94653d72 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-tools-profile.bb
@@ -37,6 +37,7 @@ SYSTEMTAP_riscv64 = ""
LTTNGTOOLS = "lttng-tools"
LTTNGTOOLS_arc = ""
+LTTNGTOOLS_riscv32_libc-musl = ""
BABELTRACE = "babeltrace"
BABELTRACE2 = "babeltrace2"
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142632):
https://lists.openembedded.org/g/openembedded-core/message/142632
Mute This Topic: https://lists.openembedded.org/mt/76904416/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] bind: remove -r option for rndc-confgen
From: Mingli Yu The named service fail to start as below: # systemctl status named.service ● named.service - Berkeley Internet Name Domain (DNS) Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-09-16 06:07:49 UTC; 9s ago Process: 134206 ExecStartPre=/usr/sbin/generate-rndc-key.sh (code=exited, status=1/FAILURE) Sep 16 06:07:49 intel-x86-64 systemd[1]: Starting Berkeley Internet Name Domain (DNS)... Sep 16 06:07:49 intel-x86-64 generate-rndc-key.sh[134206]: Generating /etc/bind/rndc.key: Sep 16 06:07:49 intel-x86-64 generate-rndc-key.sh[134207]: rndc-confgen: The -r option has been deprecated. Sep 16 06:07:49 intel-x86-64 generate-rndc-key.sh[134208]: chown: cannot access '/etc/bind/rndc.key': No such file or directory Sep 16 06:07:49 intel-x86-64 generate-rndc-key.sh[134209]: chmod: cannot access '/etc/bind/rndc.key': No such file or directory Sep 16 06:07:49 intel-x86-64 systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE Sep 16 06:07:49 intel-x86-64 systemd[1]: named.service: Failed with result 'exit-code'. Sep 16 06:07:49 intel-x86-64 systemd[1]: Failed to start Berkeley Internet Name Domain (DNS). It is because fail to execute "/usr/sbin/generate-rndc-key.sh" as -r is deprecated since bind 9.13.x and the random function changes in [1], so remove -r option to fix the above issue. [1]: https://gitlab.isc.org/isc-projects/bind9/-/commit/3a4f820d625c214cfb21f5e6d18ce9160d2a193b Signed-off-by: Mingli Yu --- meta/recipes-connectivity/bind/bind-9.16.5/generate-rndc-key.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-connectivity/bind/bind-9.16.5/generate-rndc-key.sh b/meta/recipes-connectivity/bind/bind-9.16.5/generate-rndc-key.sh index ef915c0ae5..633e29c0e6 100644 --- a/meta/recipes-connectivity/bind/bind-9.16.5/generate-rndc-key.sh +++ b/meta/recipes-connectivity/bind/bind-9.16.5/generate-rndc-key.sh @@ -2,7 +2,7 @@ if [ ! -s /etc/bind/rndc.key ]; then echo -n "Generating /etc/bind/rndc.key:" -/usr/sbin/rndc-confgen -a -b 512 -r /dev/urandom +/usr/sbin/rndc-confgen -a -b 512 chown root:bind /etc/bind/rndc.key chmod 0640 /etc/bind/rndc.key fi -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142631): https://lists.openembedded.org/g/openembedded-core/message/142631 Mute This Topic: https://lists.openembedded.org/mt/76904388/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] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF
Just for the sake of knowing, how do you reference multiconfig directories? Do you copy them manually to $BUILDDIR/conf after setup-env is done? I mean when I run `bitbake multiconfig:configA:core-image-minimal' there should be "$BUILDDIR/conf/multiconfig/configA.conf" file, right? On Thu, Sep 17, 2020 at 12:42 AM Mark Hatle wrote: > > In my configurations, we refernce the multiconfig directories inside of our > many > layers. I definitely don't want the copied into the conf/* directory > structure, > since I don't want users modifying the prebuilt ones. > > --Mark > > On 9/16/20 12:08 PM, gr embeter wrote: > >> Why copy this from TEMPLATECONF when they can be supplied by any layer in > >> your BBLAYERS? > > > > At the stage of creating build directory I think it is logically to > > use TEMPLATECONF both for "local.conf" and "multiconfig" > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142630): https://lists.openembedded.org/g/openembedded-core/message/142630 Mute This Topic: https://lists.openembedded.org/mt/76889431/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 00/23] Pull request (cover letter only)
The following changes since commit 210ebed1e9c2285d6e457bf03d1f1a1f3ddc7fda:
package: get_package_mapping: avoid dependency mapping if renamed package
provides original name (2020-09-04 04:31:45 -1000)
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
Adrian Freihofer (1):
oe-publish-sdk: fix layers init via ssh
Chris Laplante (4):
cve-update-db-native: add progress handler
cve-check/cve-update-db-native: use lockfile to fix usage under
multiconfig
cve-update-db-native: use context manager for cve_f
cve-check: avoid FileNotFoundError if no do_cve_check task has run
Khem Raj (2):
uninative: Upgrade to 2.9
rpcbind: Use update-alternatives for rpcinfo
Lee Chee Yang (3):
xserver-xorg: fix CVE-2020-14347
qemu: fix CVE-2020-14364 CVE-2020-14415
libx11 : fix CVE-2020-14344
Matt Madison (1):
image.bbclass: fix REPRODUCIBLE_TIMESTAMP_ROOTFS reference
Oleksandr Kravchuk (1):
ell: update to 0.33
Ovidiu Panait (1):
libxml2: Fix CVE-2020-24977
Richard Purdie (3):
runqemu: Add a hook to allow it to renice
selftest/signing: Ensure build path relocation is safe
oeqa/concurrencytest: Improve builddir path manipulations
Ross Burton (5):
gdk-pixbuf: add tests PACKAGECONFIG
insane: only load real files as ELF
autoconf: consolidate DEPENDS
curl: add vendors to CVE_PRODUCT to exclude false positives
cmake: whitelist CVE-2016-10642
Zhixiong Chi (1):
gnutls: CVE-2020-24659
akuster (1):
cve-check.bbclass: always save cve report
meta/classes/cve-check.bbclass| 34 ++
meta/classes/image.bbclass| 2 +-
meta/classes/insane.bbclass | 13 +-
meta/conf/distro/include/yocto-uninative.inc | 10 +-
meta/lib/oeqa/selftest/cases/signing.py | 4 +-
meta/lib/oeqa/selftest/context.py | 4 +-
.../ell/{ell_0.32.bb => ell_0.33.bb} | 2 +-
.../libxml/libxml2/CVE-2020-24977.patch | 41 +++
meta/recipes-core/libxml/libxml2_2.9.10.bb| 1 +
.../recipes-core/meta/cve-update-db-native.bb | 96 +++---
meta/recipes-devtools/autoconf/autoconf.inc | 5 +-
meta/recipes-devtools/cmake/cmake.inc | 4 +
meta/recipes-devtools/qemu/qemu.inc | 2 +
.../qemu/qemu/CVE-2020-14364.patch| 93 +
.../qemu/qemu/CVE-2020-14415.patch| 37 ++
.../recipes-extended/rpcbind/rpcbind_1.2.5.bb | 5 +-
.../gdk-pixbuf/gdk-pixbuf_2.40.0.bb | 8 +-
.../xorg-lib/libx11/CVE-2020-14344.patch | 321 ++
.../recipes-graphics/xorg-lib/libx11_1.6.9.bb | 4 +-
.../xserver-xorg/CVE-2020-14347.patch | 38 +++
.../xorg-xserver/xserver-xorg_1.20.8.bb | 1 +
meta/recipes-support/curl/curl_7.69.1.bb | 4 +-
.../gnutls/gnutls/CVE-2020-24659.patch| 117 +++
meta/recipes-support/gnutls/gnutls_3.6.14.bb | 1 +
scripts/oe-publish-sdk| 2 +-
scripts/runqemu | 5 +
26 files changed, 781 insertions(+), 73 deletions(-)
rename meta/recipes-core/ell/{ell_0.32.bb => ell_0.33.bb} (89%)
create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2020-24977.patch
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-14364.patch
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-14415.patch
create mode 100644 meta/recipes-graphics/xorg-lib/libx11/CVE-2020-14344.patch
create mode 100644
meta/recipes-graphics/xorg-xserver/xserver-xorg/CVE-2020-14347.patch
create mode 100644 meta/recipes-support/gnutls/gnutls/CVE-2020-24659.patch
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142629):
https://lists.openembedded.org/g/openembedded-core/message/142629
Mute This Topic: https://lists.openembedded.org/mt/76903020/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] less:upgrade 562 -> 563
Signed-off-by: Zang Ruochen
---
meta/recipes-extended/less/{less_562.bb => less_563.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-extended/less/{less_562.bb => less_563.bb} (89%)
diff --git a/meta/recipes-extended/less/less_562.bb
b/meta/recipes-extended/less/less_563.bb
similarity index 89%
rename from meta/recipes-extended/less/less_562.bb
rename to meta/recipes-extended/less/less_563.bb
index c900574674..4a1e951756 100644
--- a/meta/recipes-extended/less/less_562.bb
+++ b/meta/recipes-extended/less/less_563.bb
@@ -28,8 +28,8 @@ DEPENDS = "ncurses"
SRC_URI = "http://www.greenwoodsoftware.com/${BPN}/${BPN}-${PV}.tar.gz \
"
-SRC_URI[md5sum] = "0371a9678cb42f37b9bf9b86e8aa7903"
-SRC_URI[sha256sum] =
"eab470c7c928132441541aa49b1352c0fc699c30f762dfaeb3bf88e6f0fd701b"
+SRC_URI[md5sum] = "1ee44fa71447a845f6eef5b3f38d2781"
+SRC_URI[sha256sum] =
"ce5b6d2b9fc4442d7a07c93ab128d2dff2ce09a1d4f2d055b95cf28dd0dc9a9a"
UPSTREAM_CHECK_URI = "http://www.greenwoodsoftware.com/less/download.html";
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142628):
https://lists.openembedded.org/g/openembedded-core/message/142628
Mute This Topic: https://lists.openembedded.org/mt/76901383/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] enchant2:upgrade 2.2.9 -> 2.2.11
Signed-off-by: Zang Ruochen
---
.../enchant/{enchant2_2.2.9.bb => enchant2_2.2.11.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-support/enchant/{enchant2_2.2.9.bb => enchant2_2.2.11.bb}
(90%)
diff --git a/meta/recipes-support/enchant/enchant2_2.2.9.bb
b/meta/recipes-support/enchant/enchant2_2.2.11.bb
similarity index 90%
rename from meta/recipes-support/enchant/enchant2_2.2.9.bb
rename to meta/recipes-support/enchant/enchant2_2.2.11.bb
index 784fd14ee1..fac8bca0b1 100644
--- a/meta/recipes-support/enchant/enchant2_2.2.9.bb
+++ b/meta/recipes-support/enchant/enchant2_2.2.11.bb
@@ -9,7 +9,7 @@ DEPENDS = "glib-2.0"
inherit autotools pkgconfig
SRC_URI =
"https://github.com/AbiWord/enchant/releases/download/v${PV}/enchant-${PV}.tar.gz";
-SRC_URI[sha256sum] =
"b29a3d2273f5edcbdbbb565e94bfd8ea3f9526886fcb6327b4b0f72f0d722f3c"
+SRC_URI[sha256sum] =
"a29c5777c4e45fcac2595c15c49d6d2aa434fa5e7c993dff3f9f367b65fe472a"
UPSTREAM_CHECK_URI = "https://github.com/AbiWord/enchant/releases";
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142627):
https://lists.openembedded.org/g/openembedded-core/message/142627
Mute This Topic: https://lists.openembedded.org/mt/76901313/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] ncurses: Create alternative symlinks for st and st-256color
Adjust for other st implementations
Signed-off-by: Khem Raj
---
meta/recipes-core/ncurses/ncurses.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/ncurses/ncurses.inc
b/meta/recipes-core/ncurses/ncurses.inc
index 1627fb91d3..4b61889668 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -273,6 +273,11 @@ inherit update-alternatives
ALTERNATIVE_PRIORITY = "100"
ALTERNATIVE_ncurses-tools_class-target = "clear reset"
+ALTERNATIVE_ncurses-terminfo_class-target = "st st-256color"
+
+ALTERNATIVE_LINK_NAME[st] = "${datadir}/terminfo/s/st"
+
+ALTERNATIVE_LINK_NAME[st-256color] = "${datadir}/terminfo/s/st-256color"
BBCLASSEXTEND = "native nativesdk"
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142626):
https://lists.openembedded.org/g/openembedded-core/message/142626
Mute This Topic: https://lists.openembedded.org/mt/76900472/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] fix memcheck vgtests remove fullpath-after flags
From: Stacy Gaikovaia
Previously in:
f75792b28e valgrind: make a few more ptests pass
the vagrind test runner was adjusted to suppress part
of a path that only exists when run in the yocto ptest
environment. Unfortunately this change includes the
valgrind version and when valgrind was last updated,
the patch was not changed. Rather than continually updating
the patch or even generating the version dynamically,
we can simply change the expected output for two tests.
The reason the option: --fullpath-after=foo was
introduced into the effected valgrind ptests was to
deal with builds where ccache is used. Compiling with
ccache enabled sometimes causes the source file absolute
name to be found in a full path that is not the same as $PWD.
See commit c80f32e662dfa2a4f046960a25d5b8b7a8821bea in
valgrind for more information about changes to the
arguments that test badfree3 and varinfo5 run with.
There is also a minor fix to add the missing overloading.pm
perl package and put the dependencies in alphabetic order.
Upstream-Status: Inappropriate [embedded specific]
Signed-off-by: Stacy Gaikovaia
---
...vgtests-remove-fullpath-after-flags.patch} | 30 ++-
.../valgrind/valgrind_3.16.1.bb | 16 --
2 files changed, 30 insertions(+), 16 deletions(-)
rename
meta/recipes-devtools/valgrind/valgrind/{0001-adjust-path-filter-for-2-memcheck-tests.patch
=> 0001-memcheck-vgtests-remove-fullpath-after-flags.patch} (52%)
diff --git
a/meta/recipes-devtools/valgrind/valgrind/0001-adjust-path-filter-for-2-memcheck-tests.patch
b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-vgtests-remove-fullpath-after-flags.patch
similarity index 52%
rename from
meta/recipes-devtools/valgrind/valgrind/0001-adjust-path-filter-for-2-memcheck-tests.patch
rename to
meta/recipes-devtools/valgrind/valgrind/0001-memcheck-vgtests-remove-fullpath-after-flags.patch
index 4bc4bb086c..dce8b52ba3 100644
---
a/meta/recipes-devtools/valgrind/valgrind/0001-adjust-path-filter-for-2-memcheck-tests.patch
+++
b/meta/recipes-devtools/valgrind/valgrind/0001-memcheck-vgtests-remove-fullpath-after-flags.patch
@@ -1,40 +1,42 @@
-From bf63e35c3036e6040c8cfecabc7160b1f36b0591 Mon Sep 17 00:00:00 2001
-From: Randy MacLeod
-Date: Wed, 28 Aug 2019 12:31:15 -0400
-Subject: [PATCH] adjust path filter for 2 memcheck tests
+From 3ff82dcb844f98dbf67c69f11f6516bc234725a9 Mon Sep 17 00:00:00 2001
+From: Stacy Gaikovaia
+Date: Wed, 16 Sep 2020 13:45:07 -0400
+Subject: [PATCH] memcheck vgtests remove fullpath-after flags
Test executables produced when cross-compiling can contain
-relative paths such as:
- coregrind/tests/../../../valgrind-3.15.0/coregrind/
-Use the --fullpath-after option to match and therefore
-suppress more of the prefix to enable test to pass.
+relative paths containing version number, such as:
+coregrind/tests/../../../valgrind-3.16.1/coregrind
+
+Remove the --fullpath-after option so yocto project doesn't
+have to upgrade patch every valgrind uprev. Upgrade test stderr
+paths in corresponding tests .bb script.
Upstream-Status: Inappropriate [embedded specific]
-Signed-off-by: Randy MacLeod
+Signed-off-by: Stacy Gaikovaia
---
memcheck/tests/badfree3.vgtest | 2 +-
memcheck/tests/varinfo5.vgtest | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/memcheck/tests/badfree3.vgtest b/memcheck/tests/badfree3.vgtest
-index 3dfc5fd8a..57eec21f3 100644
+index 3dfc5fd8a..4ee03f00a 100644
--- a/memcheck/tests/badfree3.vgtest
+++ b/memcheck/tests/badfree3.vgtest
@@ -1,3 +1,3 @@
prog: badfree
-vgopts: -q --fullpath-after=memcheck/ --fullpath-after=coregrind/
-+vgopts: -q --fullpath-after=/valgrind-3.15.0/memcheck/
--fullpath-after=/valgrind-3.15.0/coregrind/
++vgopts: -q
stderr_filter_args: badfree.c
diff --git a/memcheck/tests/varinfo5.vgtest b/memcheck/tests/varinfo5.vgtest
-index 063d00dce..6907bb2f6 100644
+index 063d00dce..79c4a72a4 100644
--- a/memcheck/tests/varinfo5.vgtest
+++ b/memcheck/tests/varinfo5.vgtest
@@ -1,3 +1,3 @@
prog: varinfo5
-vgopts: --fullpath-after=memcheck/ --fullpath-after=coregrind/
--read-var-info=yes --read-inline-info=yes -q
-+vgopts: --fullpath-after=/valgrind-3.15.0/memcheck/
--fullpath-after=/valgrind-3.15.0/coregrind/ --read-var-info=yes
--read-inline-info=yes -q
++vgopts: --read-var-info=yes --read-inline-info=yes -q
stderr_filter: filter_varinfo3
--
-2.22.0
+2.25.1
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
b/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
index 484a229a1a..d4ca1a7752 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
@@ -36,7 +36,7 @@ SRC_URI =
"https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
file://0001-Make-local-functions-static-to-avoid-assembler-error.patch \
file://0001-Return-a-valid-exit_code-from-vg_regtest.patch \
file://0001-valgrind-filte
Re: [OE-core] [PATCH] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF
In my configurations, we refernce the multiconfig directories inside of our many layers. I definitely don't want the copied into the conf/* directory structure, since I don't want users modifying the prebuilt ones. --Mark On 9/16/20 12:08 PM, gr embeter wrote: >> Why copy this from TEMPLATECONF when they can be supplied by any layer in >> your BBLAYERS? > > At the stage of creating build directory I think it is logically to > use TEMPLATECONF both for "local.conf" and "multiconfig" > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142624): https://lists.openembedded.org/g/openembedded-core/message/142624 Mute This Topic: https://lists.openembedded.org/mt/76889431/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] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF
> Why copy this from TEMPLATECONF when they can be supplied by any layer in > your BBLAYERS? At the stage of creating build directory I think it is logically to use TEMPLATECONF both for "local.conf" and "multiconfig" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142623): https://lists.openembedded.org/g/openembedded-core/message/142623 Mute This Topic: https://lists.openembedded.org/mt/76889431/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][dunfell] xinput-calibrator: change SRC_URI to branch with libinput support
Since "conf: Use xf86-input-libinput by default" [1] there are reports [2] of xinput-calibrator failing because it expects xf86-input-evdev and with the above patch xf86-input-libinput takes precedence. Fix this issue by using a branch of xinput calibrator which supports xf86-input-libinput. [1] https://git.openembedded.org/openembedded-core/commit/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc?id=2d005faff6341a81a2afae28860101ba9db51ae8 [2] https://www.yoctoproject.org/pipermail/yocto/2018-December/043487.html Signed-off-by: Steve Sakoman --- .../xinput-calibrator/xinput-calibrator_git.bb| 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb index 4f831932e7..d2a16643fe 100644 --- a/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb +++ b/meta/recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb @@ -11,8 +11,8 @@ inherit autotools pkgconfig features_check # depends on virtual/libx11 REQUIRED_DISTRO_FEATURES = "x11" -SRCREV = "03dadf55109bd43d3380f040debe9f82f66f2f35" -SRC_URI = "git://github.com/tias/xinput_calibrator.git \ +SRCREV = "18ec53f1cada39f905614ebfaffed5c7754ecf46" +SRC_URI = "git://github.com/kreijack/xinput_calibrator.git;branch=libinput \ file://30xinput_calibrate.sh \ file://Allow-xinput_calibrator_pointercal.sh-to-be-run-as-n.patch \ file://0001-calibrator.hh-Include-string-to-get-std-string.patch \ -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142622): https://lists.openembedded.org/g/openembedded-core/message/142622 Mute This Topic: https://lists.openembedded.org/mt/76891107/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] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF
Why copy this from TEMPLATECONF when they can be supplied by any layer in your BBLAYERS? On Wed, Sep 16, 2020 at 8:10 AM gr embeter wrote: > Retrieve multiconfig automatically from meta-layer if it exists, > so that it is possible to use it "out-of-the-box". > > Signed-off-by: Grygorii Tertychnyi < > grygorii.tertych...@leica-geosystems.com> > --- > scripts/oe-setup-builddir | 4 > 1 file changed, 4 insertions(+) > > diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir > index 30eaa8efbe1f..0077c13110b9 100755 > --- a/scripts/oe-setup-builddir > +++ b/scripts/oe-setup-builddir > @@ -65,6 +65,7 @@ if [ -n "$TEMPLATECONF" ]; then > OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample" > OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" > OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" > +OECOREMULTICONF="$TEMPLATECONF/multiconfig" > fi > > unset SHOWYPDOC > @@ -80,6 +81,9 @@ for more information as common configuration options > are commented. > > EOM > cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf" > +if [ -d "$OECOREMULTICONF" ]; then > +cp -af -t "$BUILDDIR/conf" "$OECOREMULTICONF" > +fi > SHOWYPDOC=yes > fi > > -- > 2.25.1 > > > > -- Christopher Larson kergoth at gmail dot com Founder - BitBake, OpenEmbedded, OpenZaurus Senior Software Engineer, Mentor Graphics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142621): https://lists.openembedded.org/g/openembedded-core/message/142621 Mute This Topic: https://lists.openembedded.org/mt/76889431/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] bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE
This is something I was sitting on for long time, because last time it was
too late to get it merged in 3.1 and then I forgot to send it when master
got open for 3.2 changes :/. And now I'm again a bit late for 3.2..
Here are some more details from #yocto IRC channel log from 2020-03-09
22:02 < JaMa> RP: memory check for you, it's about commit from 2011/2009 :)
do you know why we have 2 different CACHE settings in default setup?
22:02 < JaMa> meta/conf/bitbake.conf:CACHE = "${TMPDIR}/cache${@['', '/' +
str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d,
1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d,
1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}"
22:02 < JaMa> meta/conf/distro/defaultsetup.conf:CACHE =
"${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(bb.data.getVar('MACHINE', d, 1))][bool(bb.data.getVar('MACHINE', d,
1))]}${@['', '/' + str(bb.data.getVar('SDKMACHINE', d,
1))][bool(bb.data.getVar('SDKMACHINE', d, 1))]}"
22:03 < JaMa> 2nd was introduced in 2011 with
http://git.openembedded.org/openembedded-core/commit/?id=c0a148077ae27a1ef57c55ac22953c68d001af57
22:03 < JaMa> any objection to update the 1st one and drop 2nd?
22:04 < JaMa> 2009 was last "functional" change in the 1st one (other than
getVar API change updates later twice)
http://git.openembedded.org/openembedded-core/commit/?id=1d4f93e8f63395220da652bae055acde11544577
22:04 < RP> JaMa: presumably its because TCMODE and TCLIBC are nodistro
specific
22:05 < RP> JaMa: we've had wider adoption of that convention since
22:05 < RP> JaMa: if someone had a summy nodistro conf file, it would break
with TCMODE/TCLIBC not in bitbake.conf
22:06 < RP> JaMa: no object to simplifying this though
22:06 < RP> s/summy/dummy/
22:06 < JaMa> ok, will do that in 3.2
22:07 < JaMa> TCLIBC is used in quite a few places now, TCMODE only in
meta/conf/local.conf.sample.extended + defaultsetup.conf
22:07 < RP> JaMa: right, TCLIBC is pretty much required now
On Wed, Sep 16, 2020 at 3:30 PM Martin Jansa via lists.openembedded.org
wrote:
> * move TCMODE and TCLIBC from defaultsetup.conf to bitbake.conf
> * set CACHE as it was in defaultsetup.conf and drop it from
> defaultsetup.conf
> * most if not all DISTROs are now including defaultsetup.conf and
> TCLIBC is pretty much expected to be always set correctly, e.g.:
> meta/recipes-core/systemd/systemd_243.2.bb:if d.getVar('TCLIBC') ==
> "musl":
> meta/recipes-devtools/gcc/gcc-runtime.inc:if [ "${TCLIBC}" !=
> "glibc" ]; then
> meta/recipes-devtools/gcc/libgcc.inc: if [ "${TCLIBC}" != "glibc" ];
> then
> meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-toolchain_0.1.bb:
> ENV_NAME="${DISTRO}-${TCLIBC}-${SDK_ARCH}-@TARGET_PREFIX
> @${DISTRO_VERSION}.tar.gz"
> meta/recipes-devtools/valgrind/valgrind_3.15.0.bb:RRECOMMENDS_${PN} +=
> "${TCLIBC}-dbg"
> meta/recipes-kernel/linux/kernel-devsrc.bb:RDEPENDS_${PN} = "bc python3
> flex bison ${TCLIBC}-utils"
>
> meta/classes/buildhistory.bbclass:BUILDHISTORY_DIR_IMAGE =
> "${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
> meta/classes/cross-canadian.bbclass:if d.getVar("TCLIBC") in [
> 'baremetal', 'newlib' ]:
> meta/classes/kernel.bbclass:tclibc = d.getVar('TCLIBC')
> meta/classes/toaster.bbclass:BUILDHISTORY_DIR_IMAGE_BASE =
> e.data.expand("%s/images/${MACHINE_ARCH}/${TCLIBC}/"% BUILDHISTORY_DIR)
>
> Signed-off-by: Martin Jansa
> ---
> meta/conf/bitbake.conf | 5 -
> meta/conf/distro/defaultsetup.conf | 5 -
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 5d994f067d..a318d1ca58 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -357,8 +357,11 @@ FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt'
> if oe.types.boolean(d.getVar
> # General work and output directories for the build system.
> ##
>
> +TCMODE ?= "default"
> +TCLIBC ?= "glibc"
> TMPDIR ?= "${TOPDIR}/tmp"
> -CACHE = "${TMPDIR}/cache${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
> str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
> +
> +CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
> str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
> str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
> # The persistent cache should be shared by all builds
> PERSISTENT_DIR = "${TOPDIR}/cache"
> LOG_DIR = "${TMPDIR}/log"
> diff --git a/meta/conf/distro/defaultsetup.conf
> b/meta/conf/distro/defaultsetup.conf
> index 66fd246526..b36a4e 100644
> --- a/meta/conf/distro/defaultsetup.conf
> +++ b/meta/conf/distro/defaultsetup.conf
> @@ -3,10 +3,7 @@ include conf/distro/include/default-versions.inc
> include conf/distro/include/default-distrovars.inc
> include conf/distro/include/maintainers.inc
>
> -TCMODE ?= "default"
> require conf/distro/include/tcmod
Re: [OE-core][dunfell 23/25] kernel.bbclass: run do_symlink_kernsrc before do_patch
Since there is an upcoming dunfell release and we don't have a fix for
this issue I am going to revert this patch.
When it is fixed in master I will reconsider taking this patch and the
fix for dunfell.
Steve
On Sat, Sep 12, 2020 at 9:10 AM Steve Sakoman via
lists.openembedded.org
wrote:
>
> Looping in Rasmus, the patch author.
>
> Would you like to submit a patch to fix this issue? Otherwise I
> should probably revert this patch in dunfell.
>
> Thanks!
>
> Steve
>
>
> On Fri, Sep 11, 2020 at 3:40 PM Chanho Park wrote:
> >
> > Hi,
> >
> > This patch makes STAGING_KERNEL_DIR symlink broken if externalsrc is used.
> > I filed a bug for this.
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=14044
> >
> > Best Regards,
> > Chanho Park
> >
> > On Mon, Aug 31, 2020 at 3:19 AM Steve Sakoman wrote:
> > >
> > > From: Rasmus Villemoes
> > >
> > > There's a race between do_symlink_kernsrc and do_populate_lic, since
> > > the latter is ordered "after do_patch"; so the two may run in
> > > parallel. In some cases, that actually causes do_populate_lic to fail
> > > if it happens to look for a license file somewhere under ${S} in the
> > > short window after shutil.move and before the symlink has been
> > > created.
> > >
> > > Fix that by simply ordering symlink_kernsrc before do_patch. Any task
> > > that pokes around in ${S} looking for files should be ordered after
> > > do_patch, so this should also fix similar latent races with other ad
> > > hoc tasks.
> > >
> > > Signed-off-by: Rasmus Villemoes
> > > Signed-off-by: Richard Purdie
> > > (cherry picked from commit c5dfc2586b4135cc86e91bb04fed837daf505676)
> > > Signed-off-by: Steve Sakoman
> > > ---
> > > meta/classes/kernel.bbclass | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > > index 9e3c34ad48..9eb9bd2844 100644
> > > --- a/meta/classes/kernel.bbclass
> > > +++ b/meta/classes/kernel.bbclass
> > > @@ -152,7 +152,7 @@ python do_symlink_kernsrc () {
> > > shutil.move(s, kernsrc)
> > > os.symlink(kernsrc, s)
> > > }
> > > -addtask symlink_kernsrc before do_configure after do_unpack
> > > +addtask symlink_kernsrc before do_patch after do_unpack
> > >
> > > inherit kernel-arch deploy
> > >
> > > --
> > > 2.17.1
> > >
> > >
> >
> >
> >
> > --
> > Best Regards,
> > Chanho Park
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142619):
https://lists.openembedded.org/g/openembedded-core/message/142619
Mute This Topic: https://lists.openembedded.org/mt/76518932/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] oe-setup-builddir: create conf/multiconfig/ from TEMPLATECONF
Retrieve multiconfig automatically from meta-layer if it exists, so that it is possible to use it "out-of-the-box". Signed-off-by: Grygorii Tertychnyi --- scripts/oe-setup-builddir | 4 1 file changed, 4 insertions(+) diff --git a/scripts/oe-setup-builddir b/scripts/oe-setup-builddir index 30eaa8efbe1f..0077c13110b9 100755 --- a/scripts/oe-setup-builddir +++ b/scripts/oe-setup-builddir @@ -65,6 +65,7 @@ if [ -n "$TEMPLATECONF" ]; then OECORELAYERCONF="$TEMPLATECONF/bblayers.conf.sample" OECORELOCALCONF="$TEMPLATECONF/local.conf.sample" OECORENOTESCONF="$TEMPLATECONF/conf-notes.txt" +OECOREMULTICONF="$TEMPLATECONF/multiconfig" fi unset SHOWYPDOC @@ -80,6 +81,9 @@ for more information as common configuration options are commented. EOM cp -f $OECORELOCALCONF "$BUILDDIR/conf/local.conf" +if [ -d "$OECOREMULTICONF" ]; then +cp -af -t "$BUILDDIR/conf" "$OECOREMULTICONF" +fi SHOWYPDOC=yes fi -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142618): https://lists.openembedded.org/g/openembedded-core/message/142618 Mute This Topic: https://lists.openembedded.org/mt/76889431/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Wed, 2020-09-16 at 10:25 -0400, Jon Mason wrote: > On Wed, Sep 16, 2020 at 9:49 AM Richard Purdie > wrote: > > On Wed, 2020-09-16 at 09:45 -0400, Jon Mason wrote: > > > On Wed, Sep 16, 2020 at 9:26 AM Richard Purdie > > > wrote: > > > > On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > > > > > There is a large number of Arm Tune files located in > > > > > meta/conf/machine/include/, and to support the current and > > > > > upcoming Arm > > > > > cores, more are needed. Adding more files is simply going to > > > > > make it > > > > > harder to find the relevant ones for an OE/YP > > > > > developer/user. Also, > > > > > there are problems with stale and erroneous configs (see my > > > > > previous > > > > > series), which will only be exacerbated by having more files. > > > > > > > > > > I am proposing a reorganization of the existing tune files by > > > > > including > > > > > them in the generic family include file. For example, the > > > > > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > > > > > tune-cortexa57.inc would be moved into arch-armv8a.inc. This > > > > > reduces > > > > > the number of files from 12 to 2 for ARMv8a, and that is > > > > > excluding the > > > > > 13 I am adding in this series that would otherwise be unique > > > > > files. > > > > > > > > > > To use, simply add > > > > > ... > > > > > DEFAULTTUNE ?= "neoversen1" > > > > > require conf/machine/include/arm/arch-armv8-2a.inc > > > > > ... > > > > > > > > > > Which is arguably what should be done anyway (instead of > > > > > taking > > > > > the > > > > > default of the tune include file). > > > > > See the qemuarm64 patch in the series for a working example. > > > > > > > > > > Of course, by removing the existing tune files, current users > > > > > are > > > > > going > > > > > to break. A simple script can be written to use sed (or > > > > > similar) > > > > > to > > > > > replace the relevant parts for those users that would be > > > > > affected > > > > > (at > > > > > least for those that are in the layer index and update > > > > > regularly). > > > > > > > > I've just looked at this in a bit more details and I'm worried. > > > > > > > > The intent is the BSP includes the processor/core tune file > > > > that > > > > its > > > > based upon. The BSP should usually know which one is present. > > > > > > > > That tune then presents the possible options which the BSPs > > > > selects > > > > from but the end user or distro can override. > > > > > > > > With this change, you get all tunes and you don't know which > > > > are > > > > compatible with a given core/processor. I'm not sure that is an > > > > improvement. > > > > > > Before you were selecting an A75 inc file (for example), now you > > > are > > > specifying an ARMv8.2 inc file and saying it is an A75 from the > > > available list. Either way, you needed to know which core you > > > were > > > running. > > > > > > In addition to this, you have the ability to run the generic > > > default > > > for the family, which will work for all of them. And for ARMv8, > > > even > > > the more generic armv8 will work for all of them. So, there > > > isn't an > > > incompatibility problem. > > > > You should have the ability to access the generic tune with either > > approach? > > > > > > I appreciate not wanting "lots of files" but we need to > > > > consider > > > > the > > > > usability too. > > > > > > > > As others have mentioned, the errors are fairly obvious with > > > > diff > > > > between the files (or a GUI like meld). > > > > > > > > What are the advantages this brings other than fewer files? Am > > > > I > > > > missing something? > > > > > > This is the main benefit of it, TBH. If I add 25 more arm tunes, > > > it's going to get ugly. And if Arm keeps adding cores at this > > > same > > > pace every year, it's going to get even uglier. However, I'm > > > fine to > > > send out those patches if it only bothers me to have so many > > > files. > > > > My worry is that the current system: > > > > a) tells BSP developers to select their processor, not an arch > > b) only shows them tunes that work on that processor > > > > So we're changing the model, but only for armv8XXX. This is going > > to be > > confusing. I do like only showing people things they can use too. > > > > How about we split the difference and add the new tune files into > > subdirs by architecture? > > So it would look something like > meta/conf/machine/arm/armv8.0/tune-cortexa57.inc > meta/conf/machine/arm/armv8.2/tune-cortexa75.inc Yes. With an open question on whether we move any existing files. Maybe just the armv8.0+ ones? > And inside of those, it would reference > meta/conf/machine/include/arm/arch-armv8.inc or > meta/conf/machine/include/arm/arch-armv8-2a.inc (just as it does > now). Correct? Yes. > Assuming so, does it make sense to try and match this with all the > other CPU architectures (e.g., x86, ppc, mips, armv7, etc)? I'd say not w
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Wed, Sep 16, 2020 at 10:25:49AM -0400, Jon Mason wrote: > On Wed, Sep 16, 2020 at 9:49 AM Richard Purdie > wrote: > > > > On Wed, 2020-09-16 at 09:45 -0400, Jon Mason wrote: > > > On Wed, Sep 16, 2020 at 9:26 AM Richard Purdie > > > wrote: > > > > On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > > > > > There is a large number of Arm Tune files located in > > > > > meta/conf/machine/include/, and to support the current and > > > > > upcoming Arm > > > > > cores, more are needed. Adding more files is simply going to > > > > > make it > > > > > harder to find the relevant ones for an OE/YP > > > > > developer/user. Also, > > > > > there are problems with stale and erroneous configs (see my > > > > > previous > > > > > series), which will only be exacerbated by having more files. > > > > > > > > > > I am proposing a reorganization of the existing tune files by > > > > > including > > > > > them in the generic family include file. For example, the > > > > > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > > > > > tune-cortexa57.inc would be moved into arch-armv8a.inc. This > > > > > reduces > > > > > the number of files from 12 to 2 for ARMv8a, and that is > > > > > excluding the > > > > > 13 I am adding in this series that would otherwise be unique > > > > > files. > > > > > > > > > > To use, simply add > > > > > ... > > > > > DEFAULTTUNE ?= "neoversen1" > > > > > require conf/machine/include/arm/arch-armv8-2a.inc > > > > > ... > > > > > > > > > > Which is arguably what should be done anyway (instead of taking > > > > > the > > > > > default of the tune include file). > > > > > See the qemuarm64 patch in the series for a working example. > > > > > > > > > > Of course, by removing the existing tune files, current users are > > > > > going > > > > > to break. A simple script can be written to use sed (or similar) > > > > > to > > > > > replace the relevant parts for those users that would be affected > > > > > (at > > > > > least for those that are in the layer index and update > > > > > regularly). > > > > > > > > I've just looked at this in a bit more details and I'm worried. > > > > > > > > The intent is the BSP includes the processor/core tune file that > > > > its > > > > based upon. The BSP should usually know which one is present. > > > > > > > > That tune then presents the possible options which the BSPs selects > > > > from but the end user or distro can override. > > > > > > > > With this change, you get all tunes and you don't know which are > > > > compatible with a given core/processor. I'm not sure that is an > > > > improvement. > > > > > > Before you were selecting an A75 inc file (for example), now you are > > > specifying an ARMv8.2 inc file and saying it is an A75 from the > > > available list. Either way, you needed to know which core you were > > > running. > > > > > > In addition to this, you have the ability to run the generic default > > > for the family, which will work for all of them. And for ARMv8, even > > > the more generic armv8 will work for all of them. So, there isn't an > > > incompatibility problem. > > > > You should have the ability to access the generic tune with either > > approach? > > > > > > I appreciate not wanting "lots of files" but we need to consider > > > > the > > > > usability too. > > > > > > > > As others have mentioned, the errors are fairly obvious with diff > > > > between the files (or a GUI like meld). > > > > > > > > What are the advantages this brings other than fewer files? Am I > > > > missing something? > > > > > > This is the main benefit of it, TBH. If I add 25 more arm tunes, > > > it's going to get ugly. And if Arm keeps adding cores at this same > > > pace every year, it's going to get even uglier. However, I'm fine to > > > send out those patches if it only bothers me to have so many files. > > > > My worry is that the current system: > > > > a) tells BSP developers to select their processor, not an arch > > b) only shows them tunes that work on that processor > > > > So we're changing the model, but only for armv8XXX. This is going to be > > confusing. I do like only showing people things they can use too. > > > > How about we split the difference and add the new tune files into > > subdirs by architecture? > > So it would look something like > meta/conf/machine/arm/armv8.0/tune-cortexa57.inc > meta/conf/machine/arm/armv8.2/tune-cortexa75.inc This additional level will still force all BSPs to update the include/require line in MACHINE configs. > And inside of those, it would reference > meta/conf/machine/include/arm/arch-armv8.inc or > meta/conf/machine/include/arm/arch-armv8-2a.inc (just as it does now). > Correct? Isn't this enough to see which tune-coretex* file belongs to which family? (e.g. git grep arch-armv8-2a.inc to see all available tune files from armv8.2a family instead of armv8.2 subdirectory) > Assuming so, does it make sense to try and match this with all the > other CPU architectures (e
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Wed, Sep 16, 2020 at 9:49 AM Richard Purdie wrote: > > On Wed, 2020-09-16 at 09:45 -0400, Jon Mason wrote: > > On Wed, Sep 16, 2020 at 9:26 AM Richard Purdie > > wrote: > > > On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > > > > There is a large number of Arm Tune files located in > > > > meta/conf/machine/include/, and to support the current and > > > > upcoming Arm > > > > cores, more are needed. Adding more files is simply going to > > > > make it > > > > harder to find the relevant ones for an OE/YP > > > > developer/user. Also, > > > > there are problems with stale and erroneous configs (see my > > > > previous > > > > series), which will only be exacerbated by having more files. > > > > > > > > I am proposing a reorganization of the existing tune files by > > > > including > > > > them in the generic family include file. For example, the > > > > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > > > > tune-cortexa57.inc would be moved into arch-armv8a.inc. This > > > > reduces > > > > the number of files from 12 to 2 for ARMv8a, and that is > > > > excluding the > > > > 13 I am adding in this series that would otherwise be unique > > > > files. > > > > > > > > To use, simply add > > > > ... > > > > DEFAULTTUNE ?= "neoversen1" > > > > require conf/machine/include/arm/arch-armv8-2a.inc > > > > ... > > > > > > > > Which is arguably what should be done anyway (instead of taking > > > > the > > > > default of the tune include file). > > > > See the qemuarm64 patch in the series for a working example. > > > > > > > > Of course, by removing the existing tune files, current users are > > > > going > > > > to break. A simple script can be written to use sed (or similar) > > > > to > > > > replace the relevant parts for those users that would be affected > > > > (at > > > > least for those that are in the layer index and update > > > > regularly). > > > > > > I've just looked at this in a bit more details and I'm worried. > > > > > > The intent is the BSP includes the processor/core tune file that > > > its > > > based upon. The BSP should usually know which one is present. > > > > > > That tune then presents the possible options which the BSPs selects > > > from but the end user or distro can override. > > > > > > With this change, you get all tunes and you don't know which are > > > compatible with a given core/processor. I'm not sure that is an > > > improvement. > > > > Before you were selecting an A75 inc file (for example), now you are > > specifying an ARMv8.2 inc file and saying it is an A75 from the > > available list. Either way, you needed to know which core you were > > running. > > > > In addition to this, you have the ability to run the generic default > > for the family, which will work for all of them. And for ARMv8, even > > the more generic armv8 will work for all of them. So, there isn't an > > incompatibility problem. > > You should have the ability to access the generic tune with either > approach? > > > > I appreciate not wanting "lots of files" but we need to consider > > > the > > > usability too. > > > > > > As others have mentioned, the errors are fairly obvious with diff > > > between the files (or a GUI like meld). > > > > > > What are the advantages this brings other than fewer files? Am I > > > missing something? > > > > This is the main benefit of it, TBH. If I add 25 more arm tunes, > > it's going to get ugly. And if Arm keeps adding cores at this same > > pace every year, it's going to get even uglier. However, I'm fine to > > send out those patches if it only bothers me to have so many files. > > My worry is that the current system: > > a) tells BSP developers to select their processor, not an arch > b) only shows them tunes that work on that processor > > So we're changing the model, but only for armv8XXX. This is going to be > confusing. I do like only showing people things they can use too. > > How about we split the difference and add the new tune files into > subdirs by architecture? So it would look something like meta/conf/machine/arm/armv8.0/tune-cortexa57.inc meta/conf/machine/arm/armv8.2/tune-cortexa75.inc And inside of those, it would reference meta/conf/machine/include/arm/arch-armv8.inc or meta/conf/machine/include/arm/arch-armv8-2a.inc (just as it does now). Correct? Assuming so, does it make sense to try and match this with all the other CPU architectures (e.g., x86, ppc, mips, armv7, etc)? Thanks, Jon > Cheers, > > Richard > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142615): https://lists.openembedded.org/g/openembedded-core/message/142615 Mute This Topic: https://lists.openembedded.org/mt/76844469/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Wed, 2020-09-16 at 09:45 -0400, Jon Mason wrote: > On Wed, Sep 16, 2020 at 9:26 AM Richard Purdie > wrote: > > On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > > > There is a large number of Arm Tune files located in > > > meta/conf/machine/include/, and to support the current and > > > upcoming Arm > > > cores, more are needed. Adding more files is simply going to > > > make it > > > harder to find the relevant ones for an OE/YP > > > developer/user. Also, > > > there are problems with stale and erroneous configs (see my > > > previous > > > series), which will only be exacerbated by having more files. > > > > > > I am proposing a reorganization of the existing tune files by > > > including > > > them in the generic family include file. For example, the > > > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > > > tune-cortexa57.inc would be moved into arch-armv8a.inc. This > > > reduces > > > the number of files from 12 to 2 for ARMv8a, and that is > > > excluding the > > > 13 I am adding in this series that would otherwise be unique > > > files. > > > > > > To use, simply add > > > ... > > > DEFAULTTUNE ?= "neoversen1" > > > require conf/machine/include/arm/arch-armv8-2a.inc > > > ... > > > > > > Which is arguably what should be done anyway (instead of taking > > > the > > > default of the tune include file). > > > See the qemuarm64 patch in the series for a working example. > > > > > > Of course, by removing the existing tune files, current users are > > > going > > > to break. A simple script can be written to use sed (or similar) > > > to > > > replace the relevant parts for those users that would be affected > > > (at > > > least for those that are in the layer index and update > > > regularly). > > > > I've just looked at this in a bit more details and I'm worried. > > > > The intent is the BSP includes the processor/core tune file that > > its > > based upon. The BSP should usually know which one is present. > > > > That tune then presents the possible options which the BSPs selects > > from but the end user or distro can override. > > > > With this change, you get all tunes and you don't know which are > > compatible with a given core/processor. I'm not sure that is an > > improvement. > > Before you were selecting an A75 inc file (for example), now you are > specifying an ARMv8.2 inc file and saying it is an A75 from the > available list. Either way, you needed to know which core you were > running. > > In addition to this, you have the ability to run the generic default > for the family, which will work for all of them. And for ARMv8, even > the more generic armv8 will work for all of them. So, there isn't an > incompatibility problem. You should have the ability to access the generic tune with either approach? > > I appreciate not wanting "lots of files" but we need to consider > > the > > usability too. > > > > As others have mentioned, the errors are fairly obvious with diff > > between the files (or a GUI like meld). > > > > What are the advantages this brings other than fewer files? Am I > > missing something? > > This is the main benefit of it, TBH. If I add 25 more arm tunes, > it's going to get ugly. And if Arm keeps adding cores at this same > pace every year, it's going to get even uglier. However, I'm fine to > send out those patches if it only bothers me to have so many files. My worry is that the current system: a) tells BSP developers to select their processor, not an arch b) only shows them tunes that work on that processor So we're changing the model, but only for armv8XXX. This is going to be confusing. I do like only showing people things they can use too. How about we split the difference and add the new tune files into subdirs by architecture? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142614): https://lists.openembedded.org/g/openembedded-core/message/142614 Mute This Topic: https://lists.openembedded.org/mt/76844469/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Wed, Sep 16, 2020 at 9:26 AM Richard Purdie wrote: > > On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > > There is a large number of Arm Tune files located in > > meta/conf/machine/include/, and to support the current and upcoming Arm > > cores, more are needed. Adding more files is simply going to make it > > harder to find the relevant ones for an OE/YP developer/user. Also, > > there are problems with stale and erroneous configs (see my previous > > series), which will only be exacerbated by having more files. > > > > I am proposing a reorganization of the existing tune files by including > > them in the generic family include file. For example, the > > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > > tune-cortexa57.inc would be moved into arch-armv8a.inc. This reduces > > the number of files from 12 to 2 for ARMv8a, and that is excluding the > > 13 I am adding in this series that would otherwise be unique files. > > > > To use, simply add > > ... > > DEFAULTTUNE ?= "neoversen1" > > require conf/machine/include/arm/arch-armv8-2a.inc > > ... > > > > Which is arguably what should be done anyway (instead of taking the > > default of the tune include file). > > See the qemuarm64 patch in the series for a working example. > > > > Of course, by removing the existing tune files, current users are going > > to break. A simple script can be written to use sed (or similar) to > > replace the relevant parts for those users that would be affected (at > > least for those that are in the layer index and update regularly). > > I've just looked at this in a bit more details and I'm worried. > > The intent is the BSP includes the processor/core tune file that its > based upon. The BSP should usually know which one is present. > > That tune then presents the possible options which the BSPs selects > from but the end user or distro can override. > > With this change, you get all tunes and you don't know which are > compatible with a given core/processor. I'm not sure that is an > improvement. Before you were selecting an A75 inc file (for example), now you are specifying an ARMv8.2 inc file and saying it is an A75 from the available list. Either way, you needed to know which core you were running. In addition to this, you have the ability to run the generic default for the family, which will work for all of them. And for ARMv8, even the more generic armv8 will work for all of them. So, there isn't an incompatibility problem. > I appreciate not wanting "lots of files" but we need to consider the > usability too. > > As others have mentioned, the errors are fairly obvious with diff > between the files (or a GUI like meld). > > What are the advantages this brings other than fewer files? Am I > missing something? This is the main benefit of it, TBH. If I add 25 more arm tunes, it's going to get ugly. And if Arm keeps adding cores at this same pace every year, it's going to get even uglier. However, I'm fine to send out those patches if it only bothers me to have so many files. Thanks, Jon > > Cheers, > > Richard > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142613): https://lists.openembedded.org/g/openembedded-core/message/142613 Mute This Topic: https://lists.openembedded.org/mt/76844469/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Tue, Sep 15, 2020 at 3:09 AM Robert Berger wrote: > > Hi Jon, > > That's not really a comment on the reorganization of compiler tunes, but > more like "Do they actually do something meaningful?" > > I posted here[1] some benchmarks and at least with the benchmarks I > tried on the chips I tried there is no obvious impact. > > i.mx6q: > > TUNE_FEATURES= "arm armv7a vfp thumb callconvention-hard" > TARGET_FPU = "hard" > > vs. > > TUNE_FEATURES= "arm vfp cortexa9 neon thumb callconvention-hard" > TARGET_FPU = "hard" > > > i.m8mm: > > TUNE_FEATURES= "aarch64 cortexa53 crc crypto" > TARGET_FPU = "" > > vs. > > TUNE_FEATURES= "aarch64 armv8a crc crypto" > TARGET_FPU = "" > > > [1] > https://yoctoproject.blogspot.com/2020/09/compiler-tunes-benchmarks-with-yocto.html > > Should we expect so see differences? There are more things at play here than simply performance. But speaking of performance, there might not be much of a benefit between a generic ARMv8.0 and a ARMv8 based core (like A53), but I do expect to see a performance bump for a ARMv8.2 based core (like A76). The delta between the former is much smaller than the latter. The differences are not only performance. Tuning for A76 versus a more generic armv8a allows for security features like branch-protection to be enabled (as it isn't supported in older versions). You get these kind of things "by default" when tuning for the specific model. Thanks, Jon > If so can you suggest benchmarks which show those differences? > > > Regards, > > Robert -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142612): https://lists.openembedded.org/g/openembedded-core/message/142612 Mute This Topic: https://lists.openembedded.org/mt/76844469/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] bitbake.conf: use ${TCMODE}-${TCLIBC} directory for CACHE
* move TCMODE and TCLIBC from defaultsetup.conf to bitbake.conf
* set CACHE as it was in defaultsetup.conf and drop it from defaultsetup.conf
* most if not all DISTROs are now including defaultsetup.conf and
TCLIBC is pretty much expected to be always set correctly, e.g.:
meta/recipes-core/systemd/systemd_243.2.bb:if d.getVar('TCLIBC') ==
"musl":
meta/recipes-devtools/gcc/gcc-runtime.inc:if [ "${TCLIBC}" != "glibc"
]; then
meta/recipes-devtools/gcc/libgcc.inc: if [ "${TCLIBC}" != "glibc" ]; then
meta/recipes-devtools/icecc-toolchain/nativesdk-icecc-toolchain_0.1.bb:ENV_NAME="${DISTRO}-${TCLIBC}-${SDK_ARCH}-@TARGET_PREFIX@${DISTRO_VERSION}.tar.gz"
meta/recipes-devtools/valgrind/valgrind_3.15.0.bb:RRECOMMENDS_${PN} +=
"${TCLIBC}-dbg"
meta/recipes-kernel/linux/kernel-devsrc.bb:RDEPENDS_${PN} = "bc python3 flex
bison ${TCLIBC}-utils"
meta/classes/buildhistory.bbclass:BUILDHISTORY_DIR_IMAGE =
"${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
meta/classes/cross-canadian.bbclass:if d.getVar("TCLIBC") in [
'baremetal', 'newlib' ]:
meta/classes/kernel.bbclass:tclibc = d.getVar('TCLIBC')
meta/classes/toaster.bbclass:BUILDHISTORY_DIR_IMAGE_BASE =
e.data.expand("%s/images/${MACHINE_ARCH}/${TCLIBC}/"% BUILDHISTORY_DIR)
Signed-off-by: Martin Jansa
---
meta/conf/bitbake.conf | 5 -
meta/conf/distro/defaultsetup.conf | 5 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 5d994f067d..a318d1ca58 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -357,8 +357,11 @@ FILESYSTEM_PERMS_TABLES ?= "${@'files/fs-perms.txt' if
oe.types.boolean(d.getVar
# General work and output directories for the build system.
##
+TCMODE ?= "default"
+TCLIBC ?= "glibc"
TMPDIR ?= "${TOPDIR}/tmp"
-CACHE = "${TMPDIR}/cache${@['', '/' +
str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
+
+CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
# The persistent cache should be shared by all builds
PERSISTENT_DIR = "${TOPDIR}/cache"
LOG_DIR = "${TMPDIR}/log"
diff --git a/meta/conf/distro/defaultsetup.conf
b/meta/conf/distro/defaultsetup.conf
index 66fd246526..b36a4e 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -3,10 +3,7 @@ include conf/distro/include/default-versions.inc
include conf/distro/include/default-distrovars.inc
include conf/distro/include/maintainers.inc
-TCMODE ?= "default"
require conf/distro/include/tcmode-${TCMODE}.inc
-
-TCLIBC ?= "glibc"
require conf/distro/include/tclibc-${TCLIBC}.inc
require conf/distro/include/uninative-flags.inc
@@ -15,8 +12,6 @@ require conf/distro/include/uninative-flags.inc
TCLIBCAPPEND ?= "-${TCLIBC}"
TMPDIR .= "${TCLIBCAPPEND}"
-CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' +
str(d.getVar('MACHINE'))][bool(d.getVar('MACHINE'))]}${@['', '/' +
str(d.getVar('SDKMACHINE'))][bool(d.getVar('SDKMACHINE'))]}"
-
USER_CLASSES ?= ""
PACKAGE_CLASSES ?= "package_ipk"
INHERIT_BLACKLIST = "blacklist"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142611):
https://lists.openembedded.org/g/openembedded-core/message/142611
Mute This Topic: https://lists.openembedded.org/mt/76887263/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [meta-oe][PATCH 0/5] ARMv8 Tune reorg
On Mon, 2020-09-14 at 11:13 -0400, Jon Mason wrote: > There is a large number of Arm Tune files located in > meta/conf/machine/include/, and to support the current and upcoming Arm > cores, more are needed. Adding more files is simply going to make it > harder to find the relevant ones for an OE/YP developer/user. Also, > there are problems with stale and erroneous configs (see my previous > series), which will only be exacerbated by having more files. > > I am proposing a reorganization of the existing tune files by including > them in the generic family include file. For example, the > tune-cortexa55.inc would be moved into arch-armv8-2a.inc, and > tune-cortexa57.inc would be moved into arch-armv8a.inc. This reduces > the number of files from 12 to 2 for ARMv8a, and that is excluding the > 13 I am adding in this series that would otherwise be unique files. > > To use, simply add > ... > DEFAULTTUNE ?= "neoversen1" > require conf/machine/include/arm/arch-armv8-2a.inc > ... > > Which is arguably what should be done anyway (instead of taking the > default of the tune include file). > See the qemuarm64 patch in the series for a working example. > > Of course, by removing the existing tune files, current users are going > to break. A simple script can be written to use sed (or similar) to > replace the relevant parts for those users that would be affected (at > least for those that are in the layer index and update regularly). I've just looked at this in a bit more details and I'm worried. The intent is the BSP includes the processor/core tune file that its based upon. The BSP should usually know which one is present. That tune then presents the possible options which the BSPs selects from but the end user or distro can override. With this change, you get all tunes and you don't know which are compatible with a given core/processor. I'm not sure that is an improvement. I appreciate not wanting "lots of files" but we need to consider the usability too. As others have mentioned, the errors are fairly obvious with diff between the files (or a GUI like meld). What are the advantages this brings other than fewer files? Am I missing something? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142610): https://lists.openembedded.org/g/openembedded-core/message/142610 Mute This Topic: https://lists.openembedded.org/mt/76844469/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/5] image-artifact-names: introduce new bbclass and move some variables into it
* similar to kernel-artifact-names for other recipes/bbclasses which
need to use some deployed artifacts
* bitbake.conf: move IMAGE_BASENAME, IMAGE_VERSION_SUFFIX, IMAGE_NAME,
IMAGE_LINK_NAME variables
* image_types.bbclass: move IMAGE_NAME_SUFFIX variable
* currently IMAGE_NAME_SUFFIX is used only by image.bbclass,
image_types.bbclass and
meta/recipes-core/images/build-appliance-image_15.0.0.bb
but if it's needed by some recipe which isn't itself an image, then
it's useful in bitbake.conf, e.g. we have a recipe for creating
VirtualBox appliances which combines .wic.vmdk with .ovf file to
create .zip with appliance, but for that we need the filename of
.wic.vmdk which now contains IMAGE_NAME_SUFFIX
https://github.com/webOS-ports/meta-webos-ports/blob/4980ce52a43ac6897657602810313af359f0b839/meta-luneos/recipes-core/images/luneos-emulator-appliance.inc#L24
* we were hardcoding .rootfs suffix where needed, but for quite long
time it's configurable with IMAGE_NAME_SUFFIX since:
commit 380ee36811939d947024bf78de907e3c071b834f
Author: Patrick Ohly
Date: Mon Mar 7 18:07:52 2016 +0100
image creation: allow overriding .rootfs suffix
and might not match with hardcoded .rootfs, so make it easier to
use IMAGE_NAME_SUFFIX where needed even without inheritting whole
image_types.bbclass
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/buildhistory.bbclass | 2 ++
meta/classes/image-artifact-names.bbclass | 15 +++
meta/classes/image-live.bbclass| 2 +-
meta/classes/image_types.bbclass | 9 ++---
meta/classes/kernel-artifact-names.bbclass | 8
meta/classes/qemuboot.bbclass | 2 ++
meta/classes/rootfs-postcommands.bbclass | 2 ++
meta/classes/testimage.bbclass | 2 ++
meta/conf/bitbake.conf | 5 -
9 files changed, 34 insertions(+), 13 deletions(-)
create mode 100644 meta/classes/image-artifact-names.bbclass
diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass
index fbdb1d3161..0f26c3c07b 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -7,6 +7,8 @@
# Copyright (C) 2007-2011 Koen Kooi
#
+inherit image-artifact-names
+
BUILDHISTORY_FEATURES ?= "image package sdk"
BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory"
BUILDHISTORY_DIR_IMAGE =
"${BUILDHISTORY_DIR}/images/${MACHINE_ARCH}/${TCLIBC}/${IMAGE_BASENAME}"
diff --git a/meta/classes/image-artifact-names.bbclass
b/meta/classes/image-artifact-names.bbclass
new file mode 100644
index 00..5ab8f1b7aa
--- /dev/null
+++ b/meta/classes/image-artifact-names.bbclass
@@ -0,0 +1,15 @@
+##
+# Specific image creation and rootfs population info.
+##
+
+IMAGE_BASENAME = "${PN}"
+IMAGE_VERSION_SUFFIX = "-${DATETIME}"
+IMAGE_VERSION_SUFFIX[vardepsexclude] += "DATETIME"
+IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}"
+
+# IMAGE_NAME is the base name for everything produced when building images.
+# The actual image that contains the rootfs has an additional suffix (.rootfs
+# by default) followed by additional suffices which describe the format (.ext4,
+# .ext4.xz, etc.).
+IMAGE_NAME_SUFFIX ??= ".rootfs"
diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index 54058b350d..9ea5ddc312 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -22,7 +22,7 @@
# ${HDDIMG_ID} - FAT image volume-id
# ${ROOTFS} - indicates a filesystem image to include as the root filesystem
(optional)
-inherit live-vm-common
+inherit live-vm-common image-artifact-names
do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \
mtools-native:do_populate_sysroot \
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index ab05cc90ff..66884af8e0 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -1,9 +1,3 @@
-# IMAGE_NAME is the base name for everything produced when building images.
-# The actual image that contains the rootfs has an additional suffix (.rootfs
-# by default) followed by additional suffices which describe the format (.ext4,
-# .ext4.xz, etc.).
-IMAGE_NAME_SUFFIX ??= ".rootfs"
-
# The default aligment of the size of the rootfs is set to 1KiB. In case
# you're using the SD card emulation of a QEMU system simulator you may
# set this value to 2048 (2MiB alignment).
@@ -231,7 +225,8 @@ IMAGE_CMD_f2fs () {
EXTRA_IMAGECMD = ""
-inherit siteinfo kernel-arch
+inherit siteinfo kernel-arch image-artifact-names
+
JFFS2_ENDIANNESS ?= "${@oe.utils.conditional('SITEINFO_ENDIANNESS', 'le',
'-l', '-b', d)}"
JFFS2_ERASEBLOCK ?= "0x4"
EXTRA_IMAGECMD_jffs2 ?= "--pad ${JFFS2_ENDIANNESS}
--eraseb
[OE-core] [PATCH 4/5] kernel.bbclass: use camelCase notation for bash variables in do_deploy
* to match other variables there like deployDir imageType
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fbd2959341..48135b3d41 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -716,10 +716,10 @@ kernel_do_deploy() {
fi
for imageType in ${KERNEL_IMAGETYPES} ; do
- base_name=$imageType-${KERNEL_IMAGE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
$deployDir/$base_name.bin
- ln -sf $base_name.bin
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
- ln -sf $base_name.bin $deployDir/$imageType
+ baseName=$imageType-${KERNEL_IMAGE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
$deployDir/$baseName.bin
+ ln -sf $baseName.bin
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
+ ln -sf $baseName.bin $deployDir/$imageType
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
'^CONFIG_MODULES=y$' .config); then
@@ -740,9 +740,9 @@ kernel_do_deploy() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
- initramfs_base_name=$imageType-${INITRAMFS_NAME}
- install -m 0644
${KERNEL_OUTPUT_DIR}/$imageType.initramfs $deployDir/$initramfs_base_name.bin
- ln -sf $initramfs_base_name.bin
$deployDir/$imageType-${INITRAMFS_LINK_NAME}.bin
+ initramfsBaseName=$imageType-${INITRAMFS_NAME}
+ install -m 0644
${KERNEL_OUTPUT_DIR}/$imageType.initramfs $deployDir/$initramfsBaseName.bin
+ ln -sf $initramfsBaseName.bin
$deployDir/$imageType-${INITRAMFS_LINK_NAME}.bin
done
fi
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142608):
https://lists.openembedded.org/g/openembedded-core/message/142608
Mute This Topic: https://lists.openembedded.org/mt/76886620/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/5] kernel.bbclass: use bash variables like imageType, base_name without {}
* just to make sure it looks like bash variable not bitbake variable in
run.do_* scripts
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 14c22da306..10e734a19e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -407,7 +407,7 @@ kernel_do_install() {
install -d ${D}/${KERNEL_IMAGEDEST}
install -d ${D}/boot
for imageType in ${KERNEL_IMAGETYPES} ; do
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
done
install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION}
install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION}
@@ -716,11 +716,11 @@ kernel_do_deploy() {
fi
for imageType in ${KERNEL_IMAGETYPES} ; do
- base_name=${imageType}-${KERNEL_IMAGE_NAME}
- install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType}
$deployDir/${base_name}.bin
- symlink_name=${imageType}-${KERNEL_IMAGE_LINK_NAME}
- ln -sf ${base_name}.bin $deployDir/${symlink_name}.bin
- ln -sf ${base_name}.bin $deployDir/${imageType}
+ base_name=$imageType-${KERNEL_IMAGE_NAME}
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
$deployDir/$base_name.bin
+ symlink_name=$imageType-${KERNEL_IMAGE_LINK_NAME}
+ ln -sf $base_name.bin $deployDir/$symlink_name.bin
+ ln -sf $base_name.bin $deployDir/$imageType
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e
'^CONFIG_MODULES=y$' .config); then
@@ -741,10 +741,10 @@ kernel_do_deploy() {
if [ "$imageType" = "fitImage" ] ; then
continue
fi
- initramfs_base_name=${imageType}-${INITRAMFS_NAME}
-
initramfs_symlink_name=${imageType}-${INITRAMFS_LINK_NAME}
- install -m 0644
${KERNEL_OUTPUT_DIR}/${imageType}.initramfs
$deployDir/${initramfs_base_name}.bin
- ln -sf ${initramfs_base_name}.bin
$deployDir/${initramfs_symlink_name}.bin
+ initramfs_base_name=$imageType-${INITRAMFS_NAME}
+ initramfs_symlink_name=$imageType-${INITRAMFS_LINK_NAME}
+ install -m 0644
${KERNEL_OUTPUT_DIR}/$imageType.initramfs $deployDir/$initramfs_base_name.bin
+ ln -sf $initramfs_base_name.bin
$deployDir/$initramfs_symlink_name.bin
done
fi
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142606):
https://lists.openembedded.org/g/openembedded-core/message/142606
Mute This Topic: https://lists.openembedded.org/mt/76886618/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/5] kernel.bbclass: eliminate (initramfs_)symlink_name variables
* they are used only once, we can use the value directly
* notice that .bin extension isn't part of the variable values
[YOCTO #12937]
Signed-off-by: Martin Jansa
---
meta/classes/kernel.bbclass | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 10e734a19e..fbd2959341 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -718,8 +718,7 @@ kernel_do_deploy() {
for imageType in ${KERNEL_IMAGETYPES} ; do
base_name=$imageType-${KERNEL_IMAGE_NAME}
install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
$deployDir/$base_name.bin
- symlink_name=$imageType-${KERNEL_IMAGE_LINK_NAME}
- ln -sf $base_name.bin $deployDir/$symlink_name.bin
+ ln -sf $base_name.bin
$deployDir/$imageType-${KERNEL_IMAGE_LINK_NAME}.bin
ln -sf $base_name.bin $deployDir/$imageType
done
@@ -742,9 +741,8 @@ kernel_do_deploy() {
continue
fi
initramfs_base_name=$imageType-${INITRAMFS_NAME}
- initramfs_symlink_name=$imageType-${INITRAMFS_LINK_NAME}
install -m 0644
${KERNEL_OUTPUT_DIR}/$imageType.initramfs $deployDir/$initramfs_base_name.bin
- ln -sf $initramfs_base_name.bin
$deployDir/$initramfs_symlink_name.bin
+ ln -sf $initramfs_base_name.bin
$deployDir/$imageType-${INITRAMFS_LINK_NAME}.bin
done
fi
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142607):
https://lists.openembedded.org/g/openembedded-core/message/142607
Mute This Topic: https://lists.openembedded.org/mt/76886619/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 5/5] *-initramfs: don't use .rootfs IMAGE_NAME_SUFFIX
* fixes the issue when image-live.bbclass expects the image
ending with just INITRAMFS_FSTYPES:
image-live.bbclass:INITRD_LIVE ?=
"${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE_LIVE}-${MACHINE}.${INITRAMFS_FSTYPES}"
while by default it now was with .rootfs suffix:
-rw-r--r-- 2 bitbake bitbake 1.5K Oct 25 16:12
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs.env
-rw-r--r-- 4 bitbake bitbake 11M Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.cpio.gz
-rw-r--r-- 4 bitbake bitbake 1.2K Oct 25 16:11
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.manifest
-rw-r--r-- 4 bitbake bitbake 1.3K Oct 25 16:12
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.qemuboot.conf
-rw-r--r-- 4 bitbake bitbake 196K Oct 25 16:11
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.testdata.json
-rw-r--r-- 4 bitbake bitbake 118M Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.wic
-rw-r--r-- 4 bitbake bitbake 3.1K Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64-1.0-r0-20191025154349.wic.bmap
-rw-r--r-- 4 bitbake bitbake 1.3K Oct 25 16:12
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.qemuboot.conf
-rw-r--r-- 4 bitbake bitbake 11M Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.rootfs.cpio.gz
-rw-r--r-- 4 bitbake bitbake 1.2K Oct 25 16:11
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.rootfs.manifest
-rw-r--r-- 4 bitbake bitbake 118M Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.rootfs.wic
-rw-r--r-- 4 bitbake bitbake 3.1K Oct 25 16:13
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.rootfs.wic.bmap
-rw-r--r-- 4 bitbake bitbake 196K Oct 25 16:11
/OE/build/oe-core/tmp/deploy/images/genericx86-64/core-image-minimal-initramfs-genericx86-64.testdata.json
initramfs images aren't normally used for rootfs, so just set
the suffix to empty, people using different artifact names might
still need to set INITRD_LIVE (e.g. when their images don't end
with "-${MACHINE}" as well)
Signed-off-by: Martin Jansa
---
meta/recipes-core/images/core-image-minimal-initramfs.bb| 1 +
meta/recipes-core/images/core-image-tiny-initramfs.bb | 1 +
meta/recipes-extended/images/core-image-testmaster-initramfs.bb | 1 +
3 files changed, 3 insertions(+)
diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 83d0eaa8df..664fe7310e 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -17,6 +17,7 @@ PACKAGE_INSTALL = "${INITRAMFS_SCRIPTS}
${VIRTUAL-RUNTIME_base-utils} udev base-
IMAGE_FEATURES = ""
export IMAGE_BASENAME = "${MLPREFIX}core-image-minimal-initramfs"
+IMAGE_NAME_SUFFIX ?= ""
IMAGE_LINGUAS = ""
LICENSE = "MIT"
diff --git a/meta/recipes-core/images/core-image-tiny-initramfs.bb
b/meta/recipes-core/images/core-image-tiny-initramfs.bb
index 0eca6d9944..5849900742 100644
--- a/meta/recipes-core/images/core-image-tiny-initramfs.bb
+++ b/meta/recipes-core/images/core-image-tiny-initramfs.bb
@@ -13,6 +13,7 @@ PACKAGE_INSTALL = "initramfs-live-boot-tiny
packagegroup-core-boot dropbear ${VI
IMAGE_FEATURES = ""
export IMAGE_BASENAME = "core-image-tiny-initramfs"
+IMAGE_NAME_SUFFIX ?= ""
IMAGE_LINGUAS = ""
LICENSE = "MIT"
diff --git a/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
b/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
index 09a6d16042..1a2e0af27b 100644
--- a/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
+++ b/meta/recipes-extended/images/core-image-testmaster-initramfs.bb
@@ -8,6 +8,7 @@ PACKAGE_INSTALL = "initramfs-live-boot
initramfs-live-install-testfs initramfs-l
IMAGE_FEATURES = ""
export IMAGE_BASENAME = "core-image-testmaster-initramfs"
+IMAGE_NAME_SUFFIX ?= ""
IMAGE_LINGUAS = ""
LICENSE = "MIT"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142609):
https://lists.openembedded.org/g/openembedded-core/message/142609
Mute This Topic: https://lists.openembedded.org/mt/76886623/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][zeus][PATCH] populate_sdk_base.bbclass: fix warning: name not matched
Hi,
As I understand it, the original zip format support was done so that there
wouldn't be any symlinks in the sdk package.
https://git.openembedded.org/openembedded-core/commit/?id=57a33048a89a422cfdc986d3489c67b2d297e1e7
With this change the symlinks are now back again which leads to broken SDK
when extracted with 7Zip.
Both commits were contributed from windriver, are you now using something
else to extract the zip?
-samuli
On Fri, 8 May 2020 at 07:34, wenlin.k...@windriver.com <
wenlin.k...@windriver.com> wrote:
> On 2020/5/8 上午11:04, Mittal, Anuj wrote:
>
> Hi,
>
> On Wed, 2020-05-06 at 01:46 -0700, wenlin.k...@windriver.com wrote:
>
> Fix below warning:
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/udev/rules.d/80-net-setup-link.rules
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/tmpfiles.d/etc.conf
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/tmpfiles.d/home.conf
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/systemd/network/80-wired.network
> zip warning: name not matched: sysroots/aarch64-wrs-
> linux/etc/resolv.conf
> zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/mtab
> zip warning: name not matched: sysroots/aarch64-wrs-linux/etc/resolv-
> conf.systemd
> zip warning: name not matched: sysroots/aarch64-wrs-linux/var/lock
>
>
> Is this specific to zeus? I don't see this change in master/dunfell.
> It'd be great if you could include more details in commit message
> explaining what is happening.
>
>
> No, this issue can be seen in master too, but this patch is only to zeus,
> for master, I have sent patch too.
>
> Steps:
>
> 1. Setup poky[zeus] project
>
> 2. In local.conf, add:
> SDK_ARCHIVE_TYPE = "zip"
>
> 3. bitbake core-image-minimal -c populate_sdk
>
> 4. check log file log.do_populate_sdk
>
>
> Thanks,
>
> Anuj
>
>
> Signed-off-by: Wenlin Kang
>
> ---
> meta/classes/populate_sdk_base.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/populate_sdk_base.bbclass
> b/meta/classes/populate_sdk_base.bbclass
> index d03465b6fc..b5c004d832 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -55,7 +55,7 @@ python () {
> d.setVar('SDK_ARCHIVE_DEPENDS', 'zip-native')
> # SDK_ARCHIVE_CMD used to generate archived sdk
> ${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} from input dir
> ${SDK_OUTPUT}/${SDKPATH} to output dir ${SDKDEPLOYDIR}
> # recommand to cd into input dir first to avoid archive with
> buildpath
> - d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
> -r ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
> + d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip
> -r -y ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
> else:
> d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
> d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar
> ${SDKTAROPTS} -cf - . | xz -T 0 -9 >
> ${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
>
>
>
> --
> Thanks,
> Wenlin Kang
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142604):
https://lists.openembedded.org/g/openembedded-core/message/142604
Mute This Topic: https://lists.openembedded.org/mt/74024894/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] python2: fix segmentation fault in ptest test_bigrepeat
Hi Richard, The patch is for zeus branch. Thanks, Heng On 9/4/20 9:59 AM, heng guo wrote: On 9/3/20 7:12 PM, Richard Purdie wrote: On Thu, 2020-09-03 at 17:24 +0800, Heng Guo wrote: Segmentation fault at case test_bigrepeat of python ptest. a similar bug can be found at https://bugs.python.org/issue33153. tuplerepeat() in Objects/tupleobject.c uses a questionable check that relies on signed integer overflow. A singed integer overflow is triggered by ptest case: test_bigrepeat. Python2 is out of maintainus, so backport the related patch from python3 commit: https://github.com/python/cpython/commit/c04ddff290fc203d05b75c8569b748525fb76b5b Signed-off-by: Heng Guo --- ...segmentation-fault-in-test_bigrepeat.patch | 33 +++ meta/recipes-devtools/python/python_2.7.18.bb | 1 + 2 files changed, 34 insertions(+) create mode 100644 meta/recipes-devtools/python/python/0001-python2- fix-segmentation-fault-in-test_bigrepeat.patch diff --git a/meta/recipes-devtools/python/python/0001-python2-fix- segmentation-fault-in-test_bigrepeat.patch b/meta/recipes- devtools/python/python/0001-python2-fix-segmentation-fault-in- test_bigrepeat.patch new file mode 100644 index 00..45087bfb8d --- /dev/null +++ b/meta/recipes-devtools/python/python/0001-python2-fix- segmentation-fault-in-test_bigrepeat.patch @@ -0,0 +1,33 @@ +From 031d06e1e670d40b6500cce4134ab35ec8858a8b Mon Sep 17 00:00:00 2001 +From: Heng Guo +Date: Wed, 15 Jul 2020 15:42:13 +0800 +Subject: [PATCH] python2: fix segmentation fault in test_bigrepeat + +Port from: + https://github.com/python/cpython/commit/c04ddff290fc203d05b75c8569b748525fb76b5b +Only merge codes related to tuplerepeat() in tupleobject.c. + +Signed-off-by: Heng Guo Missing Upstream-Status tag, also which branch is this against? The recipe no longer exists in OE-Core. [Heng]: https://bugs.python.org/issue33153 the same bug is reported to python2 over 2 years and on hold over 1 year. For python branch: remotes/origin/2.7. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142603): https://lists.openembedded.org/g/openembedded-core/message/142603 Mute This Topic: https://lists.openembedded.org/mt/76603050/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] qemu: override DEBUG_BUILD
From: Mingli Yu
Override DEBUG_BUILD for qemu as the qemu upstream states it
doesn't work without optimization [1] to fix below build failure
when debug build enabled.
|
/usr/lib/gcc/x86_64-wrs-linux/10.1.0/../../../../x86_64-wrs-linux/bin/ld.bfd:
/mnt/build/tmp/work/x86_64-linux/qemu-system-native/5.1.0-r0/qemu-5.1.0/fsdev/qemu-fsdev-throttle.c:25:
undefined reference to `unknown_lock_type'
|
/usr/lib/gcc/x86_64-wrs-linux/10.1.0/../../../../x86_64-wrs-linux/bin/ld.bfd:
../fsdev/qemu-fsdev-throttle.o: in function `fsdev_co_throttle_request':
|
/mnt/build/tmp/work/x86_64-linux/qemu-system-native/5.1.0-r0/qemu-5.1.0/fsdev/qemu-fsdev-throttle.c:103:
undefined reference to `unknown_lock_type'
|
/usr/lib/gcc/x86_64-wrs-linux/10.1.0/../../../../x86_64-wrs-linux/bin/ld.bfd:
../fsdev/qemu-fsdev-throttle.o:/mnt/build/tmp/work/x86_64-linux/qemu-system-native/5.1.0-r0/qemu-5.1.0/fsdev/qemu-fsdev-throttle.c:103:
more undefined references to `unknown_lock_type' follow
| collect2: error: ld returned 1 exit status
[1]: https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03873.html
Signed-off-by: Mingli Yu
---
meta/recipes-devtools/qemu/qemu.inc | 4
meta/recipes-devtools/qemu/qemu_5.1.0.bb | 5 -
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 9091115caf..bbb9038961 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -39,6 +39,10 @@ SRC_URI[sha256sum] =
"c9174eb5933d9eb5e61f541cd6d1184cd3118dfe4c5c4955bc1bdc4d39
COMPATIBLE_HOST_mipsarchn32 = "null"
COMPATIBLE_HOST_mipsarchn64 = "null"
+# Per https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03873.html
+# upstream states qemu doesn't work without optimization
+DEBUG_BUILD = "0"
+
do_install_append() {
# Prevent QA warnings about installed ${localstatedir}/run
if [ -d ${D}${localstatedir}/run ]; then rmdir ${D}${localstatedir}/run; fi
diff --git a/meta/recipes-devtools/qemu/qemu_5.1.0.bb
b/meta/recipes-devtools/qemu/qemu_5.1.0.bb
index 9b09490269..a4018cc448 100644
--- a/meta/recipes-devtools/qemu/qemu_5.1.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_5.1.0.bb
@@ -10,11 +10,6 @@ DEPENDS = "glib-2.0 zlib pixman bison-native"
RDEPENDS_${PN}_class-target += "bash"
-# Does not compile for -Og because that level does not clean up dead-code.
-# See lockable.h.
-#
-DEBUG_BUILD = "0"
-
EXTRA_OECONF_append_class-target = " --target-list=${@get_qemu_target_list(d)}"
EXTRA_OECONF_append_class-target_mipsarcho32 =
"${@bb.utils.contains('BBEXTENDCURR', 'multilib', ' --disable-capstone', '',
d)}"
EXTRA_OECONF_append_class-nativesdk = "
--target-list=${@get_qemu_target_list(d)}"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142602):
https://lists.openembedded.org/g/openembedded-core/message/142602
Mute This Topic: https://lists.openembedded.org/mt/76883112/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] qemu: always define unknown_lock_type
On 9/15/20 6:26 PM, Ross Burton wrote: On Mon, 14 Sep 2020 at 16:23, Khem Raj wrote: perhaps you are not using one of -O option ? -Og passed to the compiler as DEBUG_BUILD = "1" defined in local.conf. Does qemu work when built with -Og This is the pertinent question. If qemu doesn't run after un-upstreamable patches when built with -Og, what's the point? Debuggable code that you can't execute serves no purpose. If qemu *needs* to be optimised to actually execute then override DEBUG_BUILD to optimise at the lowest usable level. Thanks! Will sent a patch to override DEBUG_BUILD for qemu. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142601): https://lists.openembedded.org/g/openembedded-core/message/142601 Mute This Topic: https://lists.openembedded.org/mt/76748224/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
