[OE-core] [RFC PATCH 2/2] baremetal-image: change comment to qemuboot.json
Signed-off-by: Guillaume Champagne --- meta/classes/baremetal-image.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/classes/baremetal-image.bbclass b/meta/classes/baremetal-image.bbclass index 90d58f2615..ecda456c39 100644 --- a/meta/classes/baremetal-image.bbclass +++ b/meta/classes/baremetal-image.bbclass @@ -77,7 +77,7 @@ QB_DTB ?= "" QB_OPT_APPEND = "-nographic" # This next part is necessary to trick the build system into thinking -# its building an image recipe so it generates the qemuboot.conf +# its building an image recipe so it generates the qemuboot.json addtask do_rootfs before do_image after do_install addtask do_image after do_rootfs before do_image_complete addtask do_image_complete after do_image before do_build -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147980): https://lists.openembedded.org/g/openembedded-core/message/147980 Mute This Topic: https://lists.openembedded.org/mt/80577034/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 1/2] runqemu: replace qemuboot.conf by qemuboot.json
Fixes [YOCTO #12503]
Switch to json format since it is more common than INI style
configuration files within oe-core.
Every key stored can now be a top level item and case on keys no longer
has to be enforced.
Signed-off-by: Guillaume Champagne
---
meta/classes/qemuboot.bbclass | 18 +--
meta/lib/oeqa/selftest/cases/runqemu.py | 6 ++--
scripts/runqemu | 40 -
3 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 4b7532b304..5437e2a499 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -92,7 +92,7 @@ QB_DRIVE_TYPE ?= "/dev/sd"
inherit image-artifact-names
-# Create qemuboot.conf
+# Create qemuboot.json
addtask do_write_qemuboot_conf after do_rootfs before do_image
def qemuboot_vars(d):
@@ -105,14 +105,13 @@ def qemuboot_vars(d):
do_write_qemuboot_conf[vardeps] += "${@' '.join(qemuboot_vars(d))}"
do_write_qemuboot_conf[vardepsexclude] += "TOPDIR"
python do_write_qemuboot_conf() {
-import configparser
+import json
-qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'),
d.getVar('IMAGE_NAME'))
-qemuboot_link = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'),
d.getVar('IMAGE_LINK_NAME'))
+qemuboot = "%s/%s.qemuboot.json" % (d.getVar('IMGDEPLOYDIR'),
d.getVar('IMAGE_NAME'))
+qemuboot_link = "%s/%s.qemuboot.json" % (d.getVar('IMGDEPLOYDIR'),
d.getVar('IMAGE_LINK_NAME'))
finalpath = d.getVar("DEPLOY_DIR_IMAGE")
topdir = d.getVar('TOPDIR')
-cf = configparser.ConfigParser()
-cf.add_section('config_bsp')
+cf = {}
for k in sorted(qemuboot_vars(d)):
# qemu-helper-native sysroot is not removed by rm_work and
# contains all tools required by runqemu
@@ -125,7 +124,8 @@ python do_write_qemuboot_conf() {
# and still run them
if val.startswith(topdir):
val = os.path.relpath(val, finalpath)
-cf.set('config_bsp', k, '%s' % val)
+
+cf[k] = val
# QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a symlink
# to the kernel file, which hinders relocatability of the qb conf.
@@ -135,11 +135,11 @@ python do_write_qemuboot_conf() {
# we only want to write out relative paths so that we can relocate images
# and still run them
kernel = os.path.relpath(kernel, finalpath)
-cf.set('config_bsp', 'QB_DEFAULT_KERNEL', kernel)
+cf['QB_DEFAULT_KERNEL'] = kernel
bb.utils.mkdirhier(os.path.dirname(qemuboot))
with open(qemuboot, 'w') as f:
-cf.write(f)
+f.write(json.dumps(cf, indent=4))
if qemuboot_link != qemuboot:
if os.path.lexists(qemuboot_link):
diff --git a/meta/lib/oeqa/selftest/cases/runqemu.py
b/meta/lib/oeqa/selftest/cases/runqemu.py
index 7e676bcb41..a20c388d91 100644
--- a/meta/lib/oeqa/selftest/cases/runqemu.py
+++ b/meta/lib/oeqa/selftest/cases/runqemu.py
@@ -117,8 +117,8 @@ SYSLINUX_TIMEOUT = "10"
self.assertIn('format=qcow2', f.read(), "Failed: %s" % cmd)
def test_boot_qemu_boot(self):
-"""Test runqemu /path/to/image.qemuboot.conf"""
-qemuboot_conf = "%s-%s.qemuboot.conf" % (self.recipe, self.machine)
+"""Test runqemu /path/to/image.qemuboot.json"""
+qemuboot_conf = "%s-%s.qemuboot.json" % (self.recipe, self.machine)
qemuboot_conf = os.path.join(self.deploy_dir_image, qemuboot_conf)
if not os.path.exists(qemuboot_conf):
self.skipTest("%s not found" % qemuboot_conf)
@@ -158,7 +158,7 @@ class QemuTest(OESelftestTestCase):
cls.machine = get_bb_var('MACHINE')
cls.deploy_dir_image = get_bb_var('DEPLOY_DIR_IMAGE')
cls.cmd_common = "runqemu nographic"
-cls.qemuboot_conf = "%s-%s.qemuboot.conf" % (cls.recipe, cls.machine)
+cls.qemuboot_conf = "%s-%s.qemuboot.json" % (cls.recipe, cls.machine)
cls.qemuboot_conf = os.path.join(cls.deploy_dir_image,
cls.qemuboot_conf)
bitbake(cls.recipe)
diff --git a/scripts/runqemu b/scripts/runqemu
index dd92a64553..d87e0ae99c 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -16,7 +16,7 @@ import re
import fcntl
import shutil
import glob
-import configparser
+import json
import signal
class RunQemuError(Exception):
@@ -29,8 +29,8 @@ class OEPathError(RunQemuError):
super().__init__("In order for this script to dynamically infer
paths\n \
kernels or filesystem images, you either need bitbake in your PATH\n \
or to source oe-init-build-env before running this script.\n\n \
-Dynamic path inference can be avoided by passing a *.qemuboot.conf to\n \
-runqemu, i.e. `runqemu /path/to/my-image-name.qemuboot.conf`\n\n %s" % message)
+Dynamic path inference can be avoided by passing a *.qemuboot.json to\n \
+runqemu, i.e. `runqemu /path/to/my-image-name.qemuboot.json`\n\n %s" % message)
def create_logger():
@@ -90,7 +90,7 @@
[OE-core] [RFC PATCH 0/2] replace qemuboot.conf by qemuboot.json
This fixes bug #12503. Sending this as an RFC since I'm not sure what to do with autobuilder-worker-prereq-tests. It fetches a qemuboot.conf from yoctoproject.org, but this cannot be changed yet to qemuboot.json since it doesn't exist on there. A patch is also sent to the docs mailing list to update references to qemuboot.conf in the documentation. Guillaume Champagne (2): runqemu: replace qemuboot.conf by qemuboot.json baremetal-image: change comment to qemuboot.json meta/classes/baremetal-image.bbclass| 2 +- meta/classes/qemuboot.bbclass | 18 +-- meta/lib/oeqa/selftest/cases/runqemu.py | 6 ++-- scripts/runqemu | 40 - 4 files changed, 33 insertions(+), 33 deletions(-) -- 2.20.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147978): https://lists.openembedded.org/g/openembedded-core/message/147978 Mute This Topic: https://lists.openembedded.org/mt/80577032/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][dunfell] sudo: 1.8.31 -> 1.8.32
On Thu, Feb 11, 2021 at 3:21 AM Lee Chee Yang wrote:
>
> From: Lee Chee Yang
>
> release notes:
> https://www.sudo.ws/legacy.html#1.8.32
>
> updates include fixes for
> CVE-2021-23239
> CVE-2021-23240
I'm getting do_compile errors with musl builds:
https://errors.yoctoproject.org/Errors/Details/570494/
In file included from ../../../sudo-1.8.32/lib/util/progname.c:36:
../../../sudo-1.8.32/include/sudo_compat.h:318: warning:
"WIFCONTINUED" redefined
318 | # define WIFCONTINUED(x) 0
Steve
> Signed-off-by: Lee Chee Yang
> ---
> meta/recipes-extended/sudo/sudo.inc | 2 +-
> meta/recipes-extended/sudo/{sudo_1.8.31.bb => sudo_1.8.32.bb} | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
> rename meta/recipes-extended/sudo/{sudo_1.8.31.bb => sudo_1.8.32.bb} (92%)
>
> diff --git a/meta/recipes-extended/sudo/sudo.inc
> b/meta/recipes-extended/sudo/sudo.inc
> index 5d27d46928..aeedfc1a23 100644
> --- a/meta/recipes-extended/sudo/sudo.inc
> +++ b/meta/recipes-extended/sudo/sudo.inc
> @@ -4,7 +4,7 @@ HOMEPAGE = "http://www.sudo.ws;
> BUGTRACKER = "http://www.sudo.ws/bugs/;
> SECTION = "admin"
> LICENSE = "ISC & BSD & Zlib"
> -LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=4d1b44b1576eea036d78b8cc961aa93d \
> +LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=07966675feaddba70cc812895b248230 \
>
> file://plugins/sudoers/redblack.c;beginline=1;endline=46;md5=03e35317699ba00b496251e0dfe9f109
> \
>
> file://lib/util/reallocarray.c;beginline=3;endline=15;md5=397dd45c7683e90b9f8bf24638cf03bf
> \
>
> file://lib/util/fnmatch.c;beginline=3;endline=27;md5=004d7d2866ba1f5b41174906849d2e0f
> \
> diff --git a/meta/recipes-extended/sudo/sudo_1.8.31.bb
> b/meta/recipes-extended/sudo/sudo_1.8.32.bb
> similarity index 92%
> rename from meta/recipes-extended/sudo/sudo_1.8.31.bb
> rename to meta/recipes-extended/sudo/sudo_1.8.32.bb
> index 39d8817c32..af875f5b4c 100644
> --- a/meta/recipes-extended/sudo/sudo_1.8.31.bb
> +++ b/meta/recipes-extended/sudo/sudo_1.8.32.bb
> @@ -7,8 +7,8 @@ SRC_URI = "https://www.sudo.ws/dist/sudo-${PV}.tar.gz \
>
> PAM_SRC_URI = "file://sudo.pam"
>
> -SRC_URI[md5sum] = "ce17ff6e72a70f8d5dabba8abf3cd2de"
> -SRC_URI[sha256sum] =
> "7ea8d97a3cee4c844e0887ea7a1bd80eb54cc98fd77966776cb1a80653ad454f"
> +SRC_URI[md5sum] = "a7318202ba391079a0e32933f0fb8bd6"
> +SRC_URI[sha256sum] =
> "5ce3c18c5efbecd5437a0945f314f1822423eaf9a2d7eb7ecf80857bc32246c5"
>
> DEPENDS += " virtual/crypt ${@bb.utils.contains('DISTRO_FEATURES', 'pam',
> 'libpam', '', d)}"
> RDEPENDS_${PN} += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam',
> 'pam-plugin-limits pam-plugin-keyinit', '', d)}"
> --
> 2.17.1
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147977):
https://lists.openembedded.org/g/openembedded-core/message/147977
Mute This Topic: https://lists.openembedded.org/mt/80556958/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][gatesgarth]Mongodb segfault on gatesgarth
Hello all, Im seeing a segfault running mongod, tested on pure upstream poky and openembedded layers (gatesgarth branch) Any known issues here on mongod in gatesgarth? Not a perfect test by any means but also tried mongodb version from zeus release where it was working and same issue. hoping to maybe get some pointers in the right direction to pinpoint issue, also having some trouble setting up debug environment correctly, Keep getting either ‘no debug symbols found’ or, ‘the debug info found in /usr/bin/.debug/mongod.debug does not match /usr/bin/mongod (CRC mismatch)’ With what I think are all the correct flags setup to debug.. INHIBIT_PACKAGE_STRIP = "1" INHIBIT_PACKAGE_DEBUG_STRIP = "1" INHIBIT_SYSROOT_STRIP = "1" DEBUG_BUILD = "1" PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory' Adding mongodb-dbg, adding tools-debug Any pointers would be much appreciated! Thanks, Jaewon -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147976): https://lists.openembedded.org/g/openembedded-core/message/147976 Mute This Topic: https://lists.openembedded.org/mt/80574786/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] linux-firmware: update to 20210208
Signed-off-by: Oleksandr Kravchuk
---
.../{linux-firmware_20201218.bb => linux-firmware_20210208.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20201218.bb =>
linux-firmware_20210208.bb} (99%)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
index 700a79b118..4a2e30119d 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20201218.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20210208.bb
@@ -201,7 +201,7 @@ PE = "1"
SRC_URI = "${KERNELORG_MIRROR}/linux/kernel/firmware/${BPN}-${PV}.tar.xz"
-SRC_URI[sha256sum] =
"a1cc1ff72c739f312b095df589e9fd639fc81c3f8f7966377ea35222dc94c04b"
+SRC_URI[sha256sum] =
"1bcb1a3944c361507754a7d26ccff40ffc28d1fb93bce711d67da26b33e785b7"
inherit allarch
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147975):
https://lists.openembedded.org/g/openembedded-core/message/147975
Mute This Topic: https://lists.openembedded.org/mt/80574292/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] cryptodev: upgrade to 1.12
Signed-off-by: Oleksandr Kravchuk
---
.../{cryptodev-linux_1.11.bb => cryptodev-linux_1.12.bb}| 0
.../{cryptodev-module_1.11.bb => cryptodev-module_1.12.bb} | 0
.../{cryptodev-tests_1.11.bb => cryptodev-tests_1.12.bb}| 0
meta/recipes-kernel/cryptodev/cryptodev.inc | 2 +-
4 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/cryptodev/{cryptodev-linux_1.11.bb =>
cryptodev-linux_1.12.bb} (100%)
rename meta/recipes-kernel/cryptodev/{cryptodev-module_1.11.bb =>
cryptodev-module_1.12.bb} (100%)
rename meta/recipes-kernel/cryptodev/{cryptodev-tests_1.11.bb =>
cryptodev-tests_1.12.bb} (100%)
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-linux_1.11.bb
b/meta/recipes-kernel/cryptodev/cryptodev-linux_1.12.bb
similarity index 100%
rename from meta/recipes-kernel/cryptodev/cryptodev-linux_1.11.bb
rename to meta/recipes-kernel/cryptodev/cryptodev-linux_1.12.bb
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.11.bb
b/meta/recipes-kernel/cryptodev/cryptodev-module_1.12.bb
similarity index 100%
rename from meta/recipes-kernel/cryptodev/cryptodev-module_1.11.bb
rename to meta/recipes-kernel/cryptodev/cryptodev-module_1.12.bb
diff --git a/meta/recipes-kernel/cryptodev/cryptodev-tests_1.11.bb
b/meta/recipes-kernel/cryptodev/cryptodev-tests_1.12.bb
similarity index 100%
rename from meta/recipes-kernel/cryptodev/cryptodev-tests_1.11.bb
rename to meta/recipes-kernel/cryptodev/cryptodev-tests_1.12.bb
diff --git a/meta/recipes-kernel/cryptodev/cryptodev.inc
b/meta/recipes-kernel/cryptodev/cryptodev.inc
index c050eda49e..fbbba2dcf4 100644
--- a/meta/recipes-kernel/cryptodev/cryptodev.inc
+++ b/meta/recipes-kernel/cryptodev/cryptodev.inc
@@ -5,7 +5,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
SRC_URI = "git://github.com/cryptodev-linux/cryptodev-linux \
"
-SRCREV = "fabe5989a3dc9fba0cd0a40b612247cdde351c01"
+SRCREV = "e0c25e289d6baf1d83c2b9cb523d3bc237d0c0c9"
S = "${WORKDIR}/git"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147974):
https://lists.openembedded.org/g/openembedded-core/message/147974
Mute This Topic: https://lists.openembedded.org/mt/80574291/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] [gatesgarth][PATCH 00/35] pull request (cover letter only)
On Thu, 2021-02-11 at 23:46 +0800, Anuj Mittal wrote: > Please merge these changes in gatesgarth. > > Thanks, > > Anuj > > The following changes since commit c63feb7e062750ef9d1fcfd6ee16f1d220f8a369: > > strace: increase ptest timeout duration 120->240s (2021-02-05 23:34:49 > +) > > are available in the Git repository at: > > git://push.openembedded.org/openembedded-core-contrib stable/gatesgarth-next > > Alexander Kanavin (5): > python3: split python target configuration into own class > python3-pycairo: use python3targetconfig > distutils3-base.bbclass: use python3targetconfig > meta: drop _PYTHON_SYSCONFIGDATA_NAME hacks > gpgme: use python3targetconfig > > Anuj Mittal (2): > sudo: fix CVE-2021-23240 > sudo: fix CVE-2021-3156 > > Awais Belal (1): > kernel.bbclass: fix deployment for initramfs images > > Bruce Ashfield (3): > linux-yocto/5.4: update to v5.4.90 > linux-yocto-rt/5.4: fix 5.4-stable caused build breakage > linux-yocto/5.4: update to v5.4.94 > > Chen Qi (1): > systemd: change /bin/nologin to /sbin/nologin > > Dorinda (1): > sanity.bbclass: Check if PSEUDO_IGNORE_PATHS and paths under pseudo > control overlap > > Kamel Bouhara (2): > npm.bbclass: make shrinkwrap file optional > recipetool: create: only add npmsw url if required > > Khem Raj (1): > python3targetconfig.bbclass: Make py3 dep and tasks only for target > recipes > > Lee Chee Yang (2): > openssl: set CVE_VERSION_SUFFIX > wic/selftest: test_permissions also test bitbake image > > Martin Jansa (1): > image_types.bbclass: tar: use posix format instead of gnu > > Michael Halstead (2): > uninative: Upgrade to 2.10 > yocto-uninative.inc: version 2.11 updates glibc to 2.33 2.11 isn't safe yet, its causing failures so I'd suggest sticking to 2.10 until we have 2.12. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147973): https://lists.openembedded.org/g/openembedded-core/message/147973 Mute This Topic: https://lists.openembedded.org/mt/80560283/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] ports/access.c: Use EACCES, not EPERM
The man page for access() does not allow for a return value of EPERM,
should be EACCES. Fix.
Signed-off-by: Richard Purdie
---
ports/unix/guts/access.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ports/unix/guts/access.c b/ports/unix/guts/access.c
index 1cc8d58..4725f49 100644
--- a/ports/unix/guts/access.c
+++ b/ports/unix/guts/access.c
@@ -21,7 +21,7 @@
if (buf.st_mode & 0111) {
return 0;
} else {
- errno = EPERM;
+ errno = EACCES;
return -1;
}
} else {
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147970):
https://lists.openembedded.org/g/openembedded-core/message/147970
Mute This Topic: https://lists.openembedded.org/mt/80563053/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] ports/rename/renameat: Avoid race when renaming files
We're seeing failures where a file is renamed under pseudo but an
access appears to be made to the old filename before the OP_RENAME has
hit the database but after the real_rename has applied in the kernel.
This is effectively the MAY_UNLINK problem for the original filename. There
were protections for the newpath but not the oldpath.
To try and avoid these aborts(), mark the original path as MAY_UNLINK however
we need to be careful not to trigger the DID_UNLINK but instead update
the deleting entry in the database as the rename completes. To do this,
we no clear the deleting flag during the database rename operation in SQL.
Also, we have to stop removing the by_ino matches where by_ino.deleting is
set, else we may lose the renamed file's attributes that way.
Signed-off-by: Richard Purdie
---
ports/unix/guts/rename.c | 35 ++-
ports/unix/guts/renameat.c | 34 +-
pseudo.c | 11 +--
pseudo_db.c| 4 ++--
4 files changed, 50 insertions(+), 34 deletions(-)
diff --git a/ports/unix/guts/rename.c b/ports/unix/guts/rename.c
index 7e4a499..80bbf41 100644
--- a/ports/unix/guts/rename.c
+++ b/ports/unix/guts/rename.c
@@ -13,7 +13,8 @@
int oldrc, newrc;
int save_errno;
int old_db_entry = 0;
- int may_unlinked = 0;
+ int may_unlink_new = 0;
+ int may_unlink_old = 0;
pseudo_debug(PDBGF_OP, "rename: %s->%s\n",
oldpath ? oldpath : "",
@@ -43,28 +44,36 @@
/* as with unlink, we have to mark that the file may get deleted */
msg = pseudo_client_op(OP_MAY_UNLINK, 0, -1, -1, newpath, newrc ? NULL
: );
if (msg && msg->result == RESULT_SUCCEED)
- may_unlinked = 1;
+ may_unlink_new = 1;
+/* oldpath is also likely to disappear. Something could call stat()
after
+ real_rename so we need to mark as MAY_UNLINK too */
+ msg = pseudo_client_op(OP_MAY_UNLINK, 0, -1, -1, oldpath, oldrc ? NULL
: );
+ if (msg && msg->result == RESULT_SUCCEED)
+ may_unlink_old = 1;
+
msg = pseudo_client_op(OP_STAT, 0, -1, -1, oldpath, oldrc ? NULL :
);
if (msg && msg->result == RESULT_SUCCEED)
old_db_entry = 1;
rc = real_rename(oldpath, newpath);
save_errno = errno;
- if (may_unlinked) {
- if (rc == -1) {
- /* since we failed, that wasn't really unlinked -- put
-* it back.
-*/
- pseudo_client_op(OP_CANCEL_UNLINK, 0, -1, -1, newpath,
);
- } else {
- /* confirm that the file was removed */
- pseudo_client_op(OP_DID_UNLINK, 0, -1, -1, newpath,
);
- }
- }
+
if (rc == -1) {
+ /* since we failed, that wasn't really unlinked -- put
+* it back.
+*/
+ if (may_unlink_new)
+ pseudo_client_op(OP_CANCEL_UNLINK, 0, -1, -1, newpath,
);
+ if (may_unlink_old)
+ pseudo_client_op(OP_CANCEL_UNLINK, 0, -1, -1, oldpath,
);
/* and we're done. */
errno = save_errno;
return rc;
}
+
+ /* confirm that the file was removed */
+ if (may_unlink_new)
+ pseudo_client_op(OP_DID_UNLINK, 0, -1, -1, newpath, );
+ /* OP_DID_UNLINK for oldpath is handled by the server */
save_errno = errno;
/* rename(3) is not mv(1). rename(file, dir) fails; you must provide
diff --git a/ports/unix/guts/renameat.c b/ports/unix/guts/renameat.c
index 8064818..5ac63f9 100644
--- a/ports/unix/guts/renameat.c
+++ b/ports/unix/guts/renameat.c
@@ -13,7 +13,8 @@
int oldrc, newrc;
int save_errno;
int old_db_entry = 0;
- int may_unlinked = 0;
+ int may_unlink_new = 0;
+ int may_unlink_old = 0;
pseudo_debug(PDBGF_FILE, "renameat: %d,%s->%d,%s\n",
olddirfd, oldpath ? oldpath : "",
@@ -55,29 +56,36 @@
/* as with unlink, we have to mark that the file may get deleted */
msg = pseudo_client_op(OP_MAY_UNLINK, 0, -1, newdirfd, newpath, newrc ?
NULL : );
if (msg && msg->result == RESULT_SUCCEED)
- may_unlinked = 1;
+ may_unlink_new = 1;
+/* oldpath is also likely to disappear. Something could call stat()
after
+ real_rename so we need to mark as MAY_UNLINK too */
+ msg = pseudo_client_op(OP_MAY_UNLINK, 0, -1, olddirfd, oldpath, oldrc ?
NULL : );
+ if (msg && msg->result == RESULT_SUCCEED)
+ may_unlink_old = 1;
+
msg = pseudo_client_op(OP_STAT, 0, -1, olddirfd, oldpath, oldrc ? NULL
: );
if (msg && msg->result == RESULT_SUCCEED)
old_db_entry = 1;
rc = real_renameat(olddirfd,
[OE-core] [PATCH 2/3] ports/unix: Add faccessat and faccessat2
Add wrappers for the faccessat and faccessat2 glibc functions matching
the way access.c works. faccessat2 was added in glibc 2.33.
Signed-off-by: Richard Purdie
---
ports/unix/guts/faccessat.c | 15
ports/unix/guts/faccessat2.c | 46
ports/unix/wrapfuncs.in | 2 ++
3 files changed, 63 insertions(+)
create mode 100644 ports/unix/guts/faccessat.c
create mode 100644 ports/unix/guts/faccessat2.c
diff --git a/ports/unix/guts/faccessat.c b/ports/unix/guts/faccessat.c
new file mode 100644
index 000..02515ee
--- /dev/null
+++ b/ports/unix/guts/faccessat.c
@@ -0,0 +1,15 @@
+/*
+ * Copyright (c) 2021, Linux Foundation; see
+ * guts/COPYRIGHT for information.
+ *
+ * SPDX-License-Identifier: LGPL-2.1-only
+ *
+ * static int
+ * wrap_fsaccessat(int dirfd, const char *path, int mode, int flags) {
+ * int rc = -1;
+ */
+ rc = wrap_faccessat2(dirfd, path, mode, flags);
+
+/* return rc;
+ * }
+ */
diff --git a/ports/unix/guts/faccessat2.c b/ports/unix/guts/faccessat2.c
new file mode 100644
index 000..1283cc6
--- /dev/null
+++ b/ports/unix/guts/faccessat2.c
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2021, Linux Foundation; see
+ * guts/COPYRIGHT for information.
+ *
+ * SPDX-License-Identifier: LGPL-2.1-only
+ *
+ * static int
+ * wrap_fsaccessat2(int dirfd, const char *path, int mode, int flags) {
+ * int rc = -1;
+ */
+ PSEUDO_STATBUF buf;
+
+#ifdef PSEUDO_NO_REAL_AT_FUNCTIONS
+ if (dirfd != AT_FDCWD) {
+ errno = ENOSYS;
+ return -1;
+ }
+ if (flags & AT_SYMLINK_NOFOLLOW) {
+ rc = base_lstat(path, );
+ } else {
+ rc = base_stat(path, );
+ }
+#else
+ rc = base_fstatat(dirfd, path, , flags & AT_SYMLINK_NOFOLLOW);
+#endif
+ if (rc == -1)
+ return rc;
+
+ /* note: no attempt to handle the case where user isn't
+* root.
+*/
+
+ if (mode & X_OK) {
+ if (buf.st_mode & 0111) {
+ return 0;
+ } else {
+ errno = EACCES;
+ return -1;
+ }
+ } else {
+ return 0;
+ }
+
+/* return rc;
+ * }
+ */
diff --git a/ports/unix/wrapfuncs.in b/ports/unix/wrapfuncs.in
index bd2706f..7724fc7 100644
--- a/ports/unix/wrapfuncs.in
+++ b/ports/unix/wrapfuncs.in
@@ -10,6 +10,8 @@ int dup(int fd); /* noignore_path=1 */
int chdir(const char *path); /* noignore_path=1 */
int fchdir(int dirfd); /* noignore_path=1 */
int access(const char *path, int mode);
+int faccessat(int dirfd, const char *path, int mode, int flags);
+int faccessat2(int dirfd, const char *path, int mode, int flags);
FTS *fts_open(char * const *path_argv, int options, int (*compar)(const FTSENT
**, const FTSENT **)); /* inode64=1 */
int ftw(const char *path, int (*fn)(const char *, const struct stat *, int),
int nopenfd);
int nftw(const char *path, int (*fn)(const char *, const struct stat *, int,
struct FTW *), int nopenfd, int flag);
--
2.27.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147971):
https://lists.openembedded.org/g/openembedded-core/message/147971
Mute This Topic: https://lists.openembedded.org/mt/80563054/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] openssl: Enable building for RISC-V 32-bit
Hello Alistair,
On Thu, Feb 11, 2021 at 5:52 PM Alistair Francis
wrote:
>
> Signed-off-by: Alistair Francis
> ---
> ...ort-for-io_pgetevents_time64-syscall.patch | 58 +++
> .../openssl/openssl_1.1.1i.bb | 4 ++
> 2 files changed, 62 insertions(+)
> create mode 100644
> meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
>
> diff --git
> a/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
>
> b/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
> new file mode 100644
> index 00..591354fbb9
> --- /dev/null
> +++
> b/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
> @@ -0,0 +1,58 @@
> +From d1a1b797d961301fd58513e50ac5de9ad5b8bc08 Mon Sep 17 00:00:00 2001
> +From: Alistair Francis
> +Date: Thu, 29 Aug 2019 13:56:21 -0700
> +Subject: [PATCH] Add support for io_pgetevents_time64 syscall
> +
> +32-bit architectures that are y2038 safe don't include syscalls that use
> +32-bit time_t. Instead these architectures have suffixed syscalls that
> +always use a 64-bit time_t. In the case of the io_getevents syscall the
> +syscall has been replaced with the io_pgetevents_time64 syscall instead.
> +
> +This patch changes the io_getevents() function to use the correct
> +syscall based on the avaliable syscalls and the time_t size. We will
> +only use the new 64-bit time_t syscall if the architecture is using a
> +64-bit time_t. This is to avoid having to deal with 32/64-bit
> +conversions and relying on a 64-bit timespec struct on 32-bit time_t
> +platforms. As of Linux 5.3 there are no 32-bit time_t architectures
> +without __NR_io_getevents. In the future if a 32-bit time_t architecture
> +wants to use the 64-bit syscalls we can handle the conversion.
> +
> +This fixes build failures on 32-bit RISC-V.
> +
> +Signed-off-by: Alistair Francis
> +Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/9819]
This PR and related commit has not been integrated in 1.1.1-stable
branch, and according to Arnd [1] - it might be wrong.
I do not know if this can be taken like that, but just want to point
out that upstream did not fully take the change you're providing here.
> +---
> + engines/e_afalg.c | 16
> + 1 file changed, 16 insertions(+)
> +
> +diff --git a/engines/e_afalg.c b/engines/e_afalg.c
> +index dacbe358cb..99516cb1bb 100644
> +--- a/engines/e_afalg.c
> b/engines/e_afalg.c
> +@@ -125,7 +125,23 @@ static ossl_inline int io_getevents(aio_context_t ctx,
> long min, long max,
> +struct io_event *events,
> +struct timespec *timeout)
> + {
> ++#if defined(__NR_io_getevents)
> + return syscall(__NR_io_getevents, ctx, min, max, events, timeout);
> ++#elif defined(__NR_io_pgetevents_time64)
> ++/* Let's only support the 64 suffix syscalls for 64-bit time_t.
> ++ * This simplifies the code for us as we don't need to use a 64-bit
> ++ * version of timespec with a 32-bit time_t and handle converting
> ++ * between 64-bit and 32-bit times and check for overflows.
> ++ */
> ++if (sizeof(timeout->tv_sec) == 8)
> ++return syscall(__NR_io_pgetevents_time64, ctx, min, max, events,
> timeout, NULL);
> ++else {
> ++errno = ENOSYS;
> ++return -1;
> ++}
> ++#else
> ++# error "We require either the io_getevents syscall or
> __NR_io_pgetevents_time64."
> ++#endif
> + }
> +
> + static void afalg_waitfd_cleanup(ASYNC_WAIT_CTX *ctx, const void *key,
> +--
> +2.23.0
> +
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> index 86950f7544..599d78abea 100644
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
> @@ -23,6 +23,10 @@ SRC_URI_append_class-nativesdk = " \
> file://environment.d-openssl.sh \
> "
>
> +SRC_URI_append_riscv32 = " \
> + file://0003-Add-support-for-io_pgetevents_time64-syscall.patch \
> + "
> +
> SRC_URI[sha256sum] =
> "e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242"
>
> inherit lib_package multilib_header multilib_script ptest
> --
> 2.30.0
>
>
>
>
Link: [1]:
https://github.com/openssl/openssl/commit/5b5e2985f355c8e99c196d9ce5d02c15bebadfbc#comments
--
Regards,
Andrey.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147969):
https://lists.openembedded.org/g/openembedded-core/message/147969
Mute This Topic: https://lists.openembedded.org/mt/80562146/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] openssl: Enable building for RISC-V 32-bit
Signed-off-by: Alistair Francis
---
...ort-for-io_pgetevents_time64-syscall.patch | 58 +++
.../openssl/openssl_1.1.1i.bb | 4 ++
2 files changed, 62 insertions(+)
create mode 100644
meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
diff --git
a/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
b/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
new file mode 100644
index 00..591354fbb9
--- /dev/null
+++
b/meta/recipes-connectivity/openssl/openssl/0003-Add-support-for-io_pgetevents_time64-syscall.patch
@@ -0,0 +1,58 @@
+From d1a1b797d961301fd58513e50ac5de9ad5b8bc08 Mon Sep 17 00:00:00 2001
+From: Alistair Francis
+Date: Thu, 29 Aug 2019 13:56:21 -0700
+Subject: [PATCH] Add support for io_pgetevents_time64 syscall
+
+32-bit architectures that are y2038 safe don't include syscalls that use
+32-bit time_t. Instead these architectures have suffixed syscalls that
+always use a 64-bit time_t. In the case of the io_getevents syscall the
+syscall has been replaced with the io_pgetevents_time64 syscall instead.
+
+This patch changes the io_getevents() function to use the correct
+syscall based on the avaliable syscalls and the time_t size. We will
+only use the new 64-bit time_t syscall if the architecture is using a
+64-bit time_t. This is to avoid having to deal with 32/64-bit
+conversions and relying on a 64-bit timespec struct on 32-bit time_t
+platforms. As of Linux 5.3 there are no 32-bit time_t architectures
+without __NR_io_getevents. In the future if a 32-bit time_t architecture
+wants to use the 64-bit syscalls we can handle the conversion.
+
+This fixes build failures on 32-bit RISC-V.
+
+Signed-off-by: Alistair Francis
+Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/9819]
+---
+ engines/e_afalg.c | 16
+ 1 file changed, 16 insertions(+)
+
+diff --git a/engines/e_afalg.c b/engines/e_afalg.c
+index dacbe358cb..99516cb1bb 100644
+--- a/engines/e_afalg.c
b/engines/e_afalg.c
+@@ -125,7 +125,23 @@ static ossl_inline int io_getevents(aio_context_t ctx,
long min, long max,
+struct io_event *events,
+struct timespec *timeout)
+ {
++#if defined(__NR_io_getevents)
+ return syscall(__NR_io_getevents, ctx, min, max, events, timeout);
++#elif defined(__NR_io_pgetevents_time64)
++/* Let's only support the 64 suffix syscalls for 64-bit time_t.
++ * This simplifies the code for us as we don't need to use a 64-bit
++ * version of timespec with a 32-bit time_t and handle converting
++ * between 64-bit and 32-bit times and check for overflows.
++ */
++if (sizeof(timeout->tv_sec) == 8)
++return syscall(__NR_io_pgetevents_time64, ctx, min, max, events,
timeout, NULL);
++else {
++errno = ENOSYS;
++return -1;
++}
++#else
++# error "We require either the io_getevents syscall or
__NR_io_pgetevents_time64."
++#endif
+ }
+
+ static void afalg_waitfd_cleanup(ASYNC_WAIT_CTX *ctx, const void *key,
+--
+2.23.0
+
diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
index 86950f7544..599d78abea 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1i.bb
@@ -23,6 +23,10 @@ SRC_URI_append_class-nativesdk = " \
file://environment.d-openssl.sh \
"
+SRC_URI_append_riscv32 = " \
+ file://0003-Add-support-for-io_pgetevents_time64-syscall.patch \
+ "
+
SRC_URI[sha256sum] =
"e8be6a35fe41d10603c3cc635e93289ed00bf34b79671a3a4de64fcee00d5242"
inherit lib_package multilib_header multilib_script ptest
--
2.30.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147968):
https://lists.openembedded.org/g/openembedded-core/message/147968
Mute This Topic: https://lists.openembedded.org/mt/80562146/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 dunfell v2] gcc-9.3.inc: Fix potential runtime crash
GCCv9 tree vectorization code is faulty and can cause random crashes at
runtime (when using -O3). Add the backported patch to address this
issue.
Signed-off-by: Jon Mason
---
meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
...-PR-tree-optimization-97236-fix-bad-.patch | 119 ++
2 files changed, 120 insertions(+)
create mode 100644
meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
b/meta/recipes-devtools/gcc/gcc-9.3.inc
index 4c54ba250aba..1c8e3df51d91 100644
--- a/meta/recipes-devtools/gcc/gcc-9.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
@@ -72,6 +72,7 @@ SRC_URI = "\
file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
+
file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
SRC_URI[sha256sum] =
"71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
diff --git
a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
new file mode 100644
index ..dc1039dcc8b1
--- /dev/null
+++
b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
@@ -0,0 +1,119 @@
+Upstream-Status: Backport
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=97b668f9a8c6ec565c278a60e7d1492a6932e409]
+Signed-off-by: Jon Mason
+
+From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
+From: Matthias Klose
+Date: Tue, 6 Oct 2020 13:41:37 +0200
+Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad use of
+ VMAT_CONTIGUOUS
+
+This avoids using VMAT_CONTIGUOUS with single-element interleaving
+when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
+continue to avoid load-lanes and gathers.
+
+2020-10-01 Richard Biener
+
+ PR tree-optimization/97236
+ * tree-vect-stmts.c (get_group_load_store_type): Keep
+ VMAT_ELEMENTWISE for single-element vectors.
+
+ * gcc.dg/vect/pr97236.c: New testcase.
+
+(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
+---
+ gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
+ gcc/tree-vect-stmts.c | 20 ++
+ 2 files changed, 52 insertions(+), 11 deletions(-)
+ create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
+
+diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
b/gcc/testsuite/gcc.dg/vect/pr97236.c
+new file mode 100644
+index ..9d3dc20d953d
+--- /dev/null
b/gcc/testsuite/gcc.dg/vect/pr97236.c
+@@ -0,0 +1,43 @@
++typedef unsigned char __uint8_t;
++typedef __uint8_t uint8_t;
++typedef struct plane_t {
++ uint8_t *p_pixels;
++ int i_lines;
++ int i_pitch;
++} plane_t;
++
++typedef struct {
++ plane_t p[5];
++} picture_t;
++
++#define N 4
++
++void __attribute__((noipa))
++picture_Clone(picture_t *picture, picture_t *res)
++{
++ for (int i = 0; i < N; i++) {
++res->p[i].p_pixels = picture->p[i].p_pixels;
++res->p[i].i_lines = picture->p[i].i_lines;
++res->p[i].i_pitch = picture->p[i].i_pitch;
++ }
++}
++
++int
++main()
++{
++ picture_t aaa, bbb;
++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
++
++ for (unsigned i = 0; i < N; i++)
++aaa.p[i].p_pixels = pixels;
++
++ picture_Clone (, );
++
++ uint8_t c = 0;
++ for (unsigned i = 0; i < N; i++)
++c += bbb.p[i].p_pixels[0];
++
++ if (c != N)
++__builtin_abort ();
++ return 0;
++}
+diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
+index 507f81b0a0e8..ffbba3441de2 100644
+--- a/gcc/tree-vect-stmts.c
b/gcc/tree-vect-stmts.c
+@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info stmt_info,
tree vectype, bool slp,
+ /* First cope with the degenerate case of a single-element
+vector. */
+ if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
+- *memory_access_type = VMAT_CONTIGUOUS;
++ ;
+
+ /* Otherwise try using LOAD/STORE_LANES. */
+-if (*memory_access_type == VMAT_ELEMENTWISE
+-&& (vls_type == VLS_LOAD
+-? vect_load_lanes_supported (vectype, group_size, masked_p)
+-: vect_store_lanes_supported (vectype, group_size,
+- masked_p)))
++else if (vls_type == VLS_LOAD
++ ? vect_load_lanes_supported (vectype, group_size, masked_p)
++ : vect_store_lanes_supported (vectype, group_size,
++ masked_p))
+ {
+ *memory_access_type = VMAT_LOAD_STORE_LANES;
+ overrun_p = would_overrun_p;
+
Re: [OE-core] [meta-oe][PATCH dunfell] gcc-9.3.inc: Fix potential runtime crash
On Thu, Feb 11, 2021 at 6:30 AM Steve Sakoman wrote:
>
> On Thu, Feb 11, 2021 at 6:09 AM Jon Mason wrote:
> >
> > Sorry, the subject should have "dunfell" in it
>
> No worries, I got it!
But as Ross pointed out you'll need to add the missing patch header
info before I can merge it ...
Steve
> > On Thu, Feb 11, 2021 at 10:57 AM Jon Mason via lists.openembedded.org
> > wrote:
> > >
> > > GCCv9 tree vectorization code is faulty and can cause random crashes at
> > > runtime (when using -O3). Add the backported patch to address this
> > > issue.
> > >
> > > Signed-off-by: Jon Mason
> > > ---
> > > meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
> > > ...-PR-tree-optimization-97236-fix-bad-.patch | 116 ++
> > > 2 files changed, 117 insertions(+)
> > > create mode 100644
> > > meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > >
> > > diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
> > > b/meta/recipes-devtools/gcc/gcc-9.3.inc
> > > index 4c54ba250aba..1c8e3df51d91 100644
> > > --- a/meta/recipes-devtools/gcc/gcc-9.3.inc
> > > +++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
> > > @@ -72,6 +72,7 @@ SRC_URI = "\
> > >
> > > file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
> > >
> > > file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
> > > file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
> > > +
> > > file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
> > > "
> > > S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
> > > SRC_URI[sha256sum] =
> > > "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
> > > diff --git
> > > a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > >
> > > b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > > new file mode 100644
> > > index ..9020aa6c3a1e
> > > --- /dev/null
> > > +++
> > > b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > > @@ -0,0 +1,116 @@
> > > +From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
> > > +From: Matthias Klose
> > > +Date: Tue, 6 Oct 2020 13:41:37 +0200
> > > +Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad
> > > use of
> > > + VMAT_CONTIGUOUS
> > > +
> > > +This avoids using VMAT_CONTIGUOUS with single-element interleaving
> > > +when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
> > > +continue to avoid load-lanes and gathers.
> > > +
> > > +2020-10-01 Richard Biener
> > > +
> > > + PR tree-optimization/97236
> > > + * tree-vect-stmts.c (get_group_load_store_type): Keep
> > > + VMAT_ELEMENTWISE for single-element vectors.
> > > +
> > > + * gcc.dg/vect/pr97236.c: New testcase.
> > > +
> > > +(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
> > > +---
> > > + gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
> > > + gcc/tree-vect-stmts.c | 20 ++
> > > + 2 files changed, 52 insertions(+), 11 deletions(-)
> > > + create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
> > > +
> > > +diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
> > > b/gcc/testsuite/gcc.dg/vect/pr97236.c
> > > +new file mode 100644
> > > +index ..9d3dc20d953d
> > > +--- /dev/null
> > > b/gcc/testsuite/gcc.dg/vect/pr97236.c
> > > +@@ -0,0 +1,43 @@
> > > ++typedef unsigned char __uint8_t;
> > > ++typedef __uint8_t uint8_t;
> > > ++typedef struct plane_t {
> > > ++ uint8_t *p_pixels;
> > > ++ int i_lines;
> > > ++ int i_pitch;
> > > ++} plane_t;
> > > ++
> > > ++typedef struct {
> > > ++ plane_t p[5];
> > > ++} picture_t;
> > > ++
> > > ++#define N 4
> > > ++
> > > ++void __attribute__((noipa))
> > > ++picture_Clone(picture_t *picture, picture_t *res)
> > > ++{
> > > ++ for (int i = 0; i < N; i++) {
> > > ++res->p[i].p_pixels = picture->p[i].p_pixels;
> > > ++res->p[i].i_lines = picture->p[i].i_lines;
> > > ++res->p[i].i_pitch = picture->p[i].i_pitch;
> > > ++ }
> > > ++}
> > > ++
> > > ++int
> > > ++main()
> > > ++{
> > > ++ picture_t aaa, bbb;
> > > ++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
> > > ++
> > > ++ for (unsigned i = 0; i < N; i++)
> > > ++aaa.p[i].p_pixels = pixels;
> > > ++
> > > ++ picture_Clone (, );
> > > ++
> > > ++ uint8_t c = 0;
> > > ++ for (unsigned i = 0; i < N; i++)
> > > ++c += bbb.p[i].p_pixels[0];
> > > ++
> > > ++ if (c != N)
> > > ++__builtin_abort ();
> > > ++ return 0;
> > > ++}
> > > +diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> > > +index 507f81b0a0e8..ffbba3441de2 100644
> > > +--- a/gcc/tree-vect-stmts.c
> > > b/gcc/tree-vect-stmts.c
> > > +@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info
> > > stmt_info,
[OE-core] [PATCH 2/2] qemurunner: Add support for qmp commands
This adds support for the Qemu Machine Protocol [0] extending
the current dump process for Host and Target. The commands are
added in the testimage.bbclass.
Currently, we setup qemu to stall until qmp gets connected and
sends the initialization and continue commands, this works
correctly.
With this version, the monitor_dumper is created in OEQemuTarget
but then set in OESSHTarget as that's where we get the SSH failure
happens. Python's @property is used to create a setter/getter type
of setup in OESSHTarget to get overridden by OEQemuTarget.
By default the data is currently dumped to files for each command in
TMPDIR/log/runtime-hostdump/_qmp/unknown__qemu_monitor as
this is the naming convenstion in the dump.py code.
We use the qmp.py from qemu, which needs to get installed in the
recipe-sysroot-native of the target image.
[0] https://github.com/qemu/qemu/blob/master/docs/interop/qmp-spec.txt
Signed-off-by: Saul Wold
---
v3: added warning messages into qemurunner
fixed extraneous warning from dumping host info
meta/classes/testimage.bbclass| 6
meta/lib/oeqa/core/target/qemu.py | 6
meta/lib/oeqa/core/target/ssh.py | 17 +-
meta/lib/oeqa/targetcontrol.py| 3 ++
meta/lib/oeqa/utils/dump.py | 31 +++--
meta/lib/oeqa/utils/qemurunner.py | 56 +--
6 files changed, 113 insertions(+), 6 deletions(-)
diff --git a/meta/classes/testimage.bbclass b/meta/classes/testimage.bbclass
index 78da4b09bdf..5db384d342f 100644
--- a/meta/classes/testimage.bbclass
+++ b/meta/classes/testimage.bbclass
@@ -127,6 +127,11 @@ testimage_dump_host () {
netstat -an
}
+testimage_dump_monitor () {
+query-status
+query-block
+}
+
python do_testimage() {
testimage_main(d)
}
@@ -319,6 +324,7 @@ def testimage_main(d):
target_kwargs['powercontrol_extra_args'] =
d.getVar("TEST_POWERCONTROL_EXTRA_ARGS") or ""
target_kwargs['serialcontrol_cmd'] = d.getVar("TEST_SERIALCONTROL_CMD") or
None
target_kwargs['serialcontrol_extra_args'] =
d.getVar("TEST_SERIALCONTROL_EXTRA_ARGS") or ""
+target_kwargs['testimage_dump_monitor'] =
d.getVar("testimage_dump_monitor") or ""
target_kwargs['testimage_dump_target'] = d.getVar("testimage_dump_target")
or ""
def export_ssh_agent(d):
diff --git a/meta/lib/oeqa/core/target/qemu.py
b/meta/lib/oeqa/core/target/qemu.py
index 0f29414df54..a73d82d9aff 100644
--- a/meta/lib/oeqa/core/target/qemu.py
+++ b/meta/lib/oeqa/core/target/qemu.py
@@ -12,6 +12,7 @@ from collections import defaultdict
from .ssh import OESSHTarget
from oeqa.utils.qemurunner import QemuRunner
+from oeqa.utils.dump import MonitorDumper
from oeqa.utils.dump import TargetDumper
supported_fstypes = ['ext3', 'ext4', 'cpio.gz', 'wic']
@@ -43,6 +44,11 @@ class OEQemuTarget(OESSHTarget):
dump_host_cmds=dump_host_cmds, logger=logger,
serial_ports=serial_ports, boot_patterns =
boot_patterns,
use_ovmf=ovmf)
+dump_monitor_cmds = kwargs.get("testimage_dump_monitor")
+self.monitor_dumper = MonitorDumper(dump_monitor_cmds, dump_dir,
self.runner)
+if self.monitor_dumper:
+self.monitor_dumper.create_dir("qmp")
+
dump_target_cmds = kwargs.get("testimage_dump_target")
self.target_dumper = TargetDumper(dump_target_cmds, dump_dir,
self.runner)
self.target_dumper.create_dir("qemu")
diff --git a/meta/lib/oeqa/core/target/ssh.py b/meta/lib/oeqa/core/target/ssh.py
index 461448dbc56..923a223b25b 100644
--- a/meta/lib/oeqa/core/target/ssh.py
+++ b/meta/lib/oeqa/core/target/ssh.py
@@ -43,6 +43,7 @@ class OESSHTarget(OETarget):
if port:
self.ssh = self.ssh + [ '-p', port ]
self.scp = self.scp + [ '-P', port ]
+self._monitor_dumper = None
def start(self, **kwargs):
pass
@@ -50,6 +51,15 @@ class OESSHTarget(OETarget):
def stop(self, **kwargs):
pass
+@property
+def monitor_dumper(self):
+return self._monitor_dumper
+
+@monitor_dumper.setter
+def monitor_dumper(self, dumper):
+self._monitor_dumper = dumper
+self.monitor_dumper.dump_monitor()
+
def _run(self, command, timeout=None, ignore_status=True):
"""
Runs command in target using SSHProcess.
@@ -87,9 +97,14 @@ class OESSHTarget(OETarget):
processTimeout = self.timeout
status, output = self._run(sshCmd, processTimeout, True)
-self.logger.debug('Command: %s\nOutput: %s\n' % (command, output))
+self.logger.debug('Command: %s\nStatus: %d Output: %s\n' % (command,
status, output))
if (status == 255) and (('No route to host') in output):
+if self.monitor_dumper:
+self.monitor_dumper.dump_monitor()
+if status == 255:
self.target_dumper.dump_target()
+if
[OE-core] [PATCH 1/2] qemu-system-native: install qmp python module
The qmp python module supports the Qemu Machine Protocol [0].
This module needs to be installed in a known location so the
qemurunner python script can find the qmp module.
This change causes it to be installed in the recipe-sysroot-native
of the target image and that directory can be added to the python
sys.path that needs to use the qmp.py module.
[0] https://github.com/qemu/qemu/blob/master/docs/interop/qmp-spec.txt
Signed-off-by: Saul Wold
---
v3: moved inherit above require per RP's comments
meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb
b/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb
index 222b55cbc6e..390dadea48a 100644
--- a/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-system-native_5.2.0.bb
@@ -1,5 +1,7 @@
BPN = "qemu"
+inherit python3-dir
+
require qemu-native.inc
# As some of the files installed by qemu-native and qemu-system-native
@@ -23,4 +25,7 @@ do_install_append() {
rm -f ${D}${datadir}/qemu/trace-events-all
rm -rf ${D}${datadir}/qemu/keymaps
rm -rf ${D}${datadir}/icons/
+
+# Install qmp.py to be used with testimage
+install -D ${S}/python/qemu/qmp.py ${D}${PYTHON_SITEPACKAGES_DIR}/qmp.py
}
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147964):
https://lists.openembedded.org/g/openembedded-core/message/147964
Mute This Topic: https://lists.openembedded.org/mt/80561663/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [RFC PATCH 0/2] Enable QMP Dumping for testimage
This is the third pass at enabling getting debug information from QEMU via the Qemu Machine Protocol interface. The Qemu source provides a qmp.py module which I current install in tmp/hosttools as a known location. I am sure there are various possible locations. The initial commands that I issue to qmp with a failure is detected is: query-status and query-block. The output goes into formated json files as follows: tmp/log/runtime-hostdump/202101061054_qmp ├── qmp_00_query-block ├── qmp_00_query-status ├── qmp_01_query-block └── qmp_01_query-status Comments welcome, I tested this by calling the monitor_dump code directly in the target/ssh.py code instead of waiting for a given failure. This version has some additional warning out out in qemurunner to try and find issues with the CentOS-8 virtgl selftest failure. I there is some timing failure with the qemu process exiting. Sau! Saul Wold (2): qemu-system-native: install qmp python module qemurunner: Add support for qmp commands meta/classes/testimage.bbclass| 6 meta/lib/oeqa/core/target/qemu.py | 6 meta/lib/oeqa/core/target/ssh.py | 17 +- meta/lib/oeqa/targetcontrol.py| 3 ++ meta/lib/oeqa/utils/dump.py | 31 +-- meta/lib/oeqa/utils/qemurunner.py | 29 - .../qemu/qemu-system-native_5.1.0.bb | 4 +++ 7 files changed, 91 insertions(+), 5 deletions(-) -- 2.25.1 Saul Wold (2): qemu-system-native: install qmp python module qemurunner: Add support for qmp commands meta/classes/testimage.bbclass| 6 ++ meta/lib/oeqa/core/target/qemu.py | 6 ++ meta/lib/oeqa/core/target/ssh.py | 17 +- meta/lib/oeqa/targetcontrol.py| 3 + meta/lib/oeqa/utils/dump.py | 31 +- meta/lib/oeqa/utils/qemurunner.py | 56 ++- .../qemu/qemu-system-native_5.2.0.bb | 5 ++ 7 files changed, 118 insertions(+), 6 deletions(-) -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147963): https://lists.openembedded.org/g/openembedded-core/message/147963 Mute This Topic: https://lists.openembedded.org/mt/80561662/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 dunfell] gcc-9.3.inc: Fix potential runtime crash
On Thu, Feb 11, 2021 at 6:09 AM Jon Mason wrote:
>
> Sorry, the subject should have "dunfell" in it
No worries, I got it!
Steve
> On Thu, Feb 11, 2021 at 10:57 AM Jon Mason via lists.openembedded.org
> wrote:
> >
> > GCCv9 tree vectorization code is faulty and can cause random crashes at
> > runtime (when using -O3). Add the backported patch to address this
> > issue.
> >
> > Signed-off-by: Jon Mason
> > ---
> > meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
> > ...-PR-tree-optimization-97236-fix-bad-.patch | 116 ++
> > 2 files changed, 117 insertions(+)
> > create mode 100644
> > meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
> > b/meta/recipes-devtools/gcc/gcc-9.3.inc
> > index 4c54ba250aba..1c8e3df51d91 100644
> > --- a/meta/recipes-devtools/gcc/gcc-9.3.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
> > @@ -72,6 +72,7 @@ SRC_URI = "\
> >
> > file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
> >
> > file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
> > file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
> > +
> > file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
> > "
> > S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
> > SRC_URI[sha256sum] =
> > "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
> > diff --git
> > a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> >
> > b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > new file mode 100644
> > index ..9020aa6c3a1e
> > --- /dev/null
> > +++
> > b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> > @@ -0,0 +1,116 @@
> > +From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
> > +From: Matthias Klose
> > +Date: Tue, 6 Oct 2020 13:41:37 +0200
> > +Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad use
> > of
> > + VMAT_CONTIGUOUS
> > +
> > +This avoids using VMAT_CONTIGUOUS with single-element interleaving
> > +when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
> > +continue to avoid load-lanes and gathers.
> > +
> > +2020-10-01 Richard Biener
> > +
> > + PR tree-optimization/97236
> > + * tree-vect-stmts.c (get_group_load_store_type): Keep
> > + VMAT_ELEMENTWISE for single-element vectors.
> > +
> > + * gcc.dg/vect/pr97236.c: New testcase.
> > +
> > +(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
> > +---
> > + gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
> > + gcc/tree-vect-stmts.c | 20 ++
> > + 2 files changed, 52 insertions(+), 11 deletions(-)
> > + create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
> > +
> > +diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
> > b/gcc/testsuite/gcc.dg/vect/pr97236.c
> > +new file mode 100644
> > +index ..9d3dc20d953d
> > +--- /dev/null
> > b/gcc/testsuite/gcc.dg/vect/pr97236.c
> > +@@ -0,0 +1,43 @@
> > ++typedef unsigned char __uint8_t;
> > ++typedef __uint8_t uint8_t;
> > ++typedef struct plane_t {
> > ++ uint8_t *p_pixels;
> > ++ int i_lines;
> > ++ int i_pitch;
> > ++} plane_t;
> > ++
> > ++typedef struct {
> > ++ plane_t p[5];
> > ++} picture_t;
> > ++
> > ++#define N 4
> > ++
> > ++void __attribute__((noipa))
> > ++picture_Clone(picture_t *picture, picture_t *res)
> > ++{
> > ++ for (int i = 0; i < N; i++) {
> > ++res->p[i].p_pixels = picture->p[i].p_pixels;
> > ++res->p[i].i_lines = picture->p[i].i_lines;
> > ++res->p[i].i_pitch = picture->p[i].i_pitch;
> > ++ }
> > ++}
> > ++
> > ++int
> > ++main()
> > ++{
> > ++ picture_t aaa, bbb;
> > ++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
> > ++
> > ++ for (unsigned i = 0; i < N; i++)
> > ++aaa.p[i].p_pixels = pixels;
> > ++
> > ++ picture_Clone (, );
> > ++
> > ++ uint8_t c = 0;
> > ++ for (unsigned i = 0; i < N; i++)
> > ++c += bbb.p[i].p_pixels[0];
> > ++
> > ++ if (c != N)
> > ++__builtin_abort ();
> > ++ return 0;
> > ++}
> > +diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> > +index 507f81b0a0e8..ffbba3441de2 100644
> > +--- a/gcc/tree-vect-stmts.c
> > b/gcc/tree-vect-stmts.c
> > +@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info
> > stmt_info, tree vectype, bool slp,
> > + /* First cope with the degenerate case of a single-element
> > +vector. */
> > + if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
> > +- *memory_access_type = VMAT_CONTIGUOUS;
> > ++ ;
> > +
> > + /* Otherwise try using LOAD/STORE_LANES. */
> > +-if (*memory_access_type == VMAT_ELEMENTWISE
> > +-&&
Re: [OE-core] [meta-oe][PATCH] gcc-9.3.inc: Fix potential runtime crash
Missing patch headers.
On Thu, 11 Feb 2021 at 15:57, Jon Mason wrote:
>
> GCCv9 tree vectorization code is faulty and can cause random crashes at
> runtime (when using -O3). Add the backported patch to address this
> issue.
>
> Signed-off-by: Jon Mason
> ---
> meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
> ...-PR-tree-optimization-97236-fix-bad-.patch | 116 ++
> 2 files changed, 117 insertions(+)
> create mode 100644
> meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
> b/meta/recipes-devtools/gcc/gcc-9.3.inc
> index 4c54ba250aba..1c8e3df51d91 100644
> --- a/meta/recipes-devtools/gcc/gcc-9.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
> @@ -72,6 +72,7 @@ SRC_URI = "\
>
> file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
>
> file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
> file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
> +
> file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
> "
> S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
> SRC_URI[sha256sum] =
> "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
> diff --git
> a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
>
> b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> new file mode 100644
> index ..9020aa6c3a1e
> --- /dev/null
> +++
> b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> @@ -0,0 +1,116 @@
> +From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
> +From: Matthias Klose
> +Date: Tue, 6 Oct 2020 13:41:37 +0200
> +Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad use of
> + VMAT_CONTIGUOUS
> +
> +This avoids using VMAT_CONTIGUOUS with single-element interleaving
> +when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
> +continue to avoid load-lanes and gathers.
> +
> +2020-10-01 Richard Biener
> +
> + PR tree-optimization/97236
> + * tree-vect-stmts.c (get_group_load_store_type): Keep
> + VMAT_ELEMENTWISE for single-element vectors.
> +
> + * gcc.dg/vect/pr97236.c: New testcase.
> +
> +(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
> +---
> + gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
> + gcc/tree-vect-stmts.c | 20 ++
> + 2 files changed, 52 insertions(+), 11 deletions(-)
> + create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
> +
> +diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
> b/gcc/testsuite/gcc.dg/vect/pr97236.c
> +new file mode 100644
> +index ..9d3dc20d953d
> +--- /dev/null
> b/gcc/testsuite/gcc.dg/vect/pr97236.c
> +@@ -0,0 +1,43 @@
> ++typedef unsigned char __uint8_t;
> ++typedef __uint8_t uint8_t;
> ++typedef struct plane_t {
> ++ uint8_t *p_pixels;
> ++ int i_lines;
> ++ int i_pitch;
> ++} plane_t;
> ++
> ++typedef struct {
> ++ plane_t p[5];
> ++} picture_t;
> ++
> ++#define N 4
> ++
> ++void __attribute__((noipa))
> ++picture_Clone(picture_t *picture, picture_t *res)
> ++{
> ++ for (int i = 0; i < N; i++) {
> ++res->p[i].p_pixels = picture->p[i].p_pixels;
> ++res->p[i].i_lines = picture->p[i].i_lines;
> ++res->p[i].i_pitch = picture->p[i].i_pitch;
> ++ }
> ++}
> ++
> ++int
> ++main()
> ++{
> ++ picture_t aaa, bbb;
> ++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
> ++
> ++ for (unsigned i = 0; i < N; i++)
> ++aaa.p[i].p_pixels = pixels;
> ++
> ++ picture_Clone (, );
> ++
> ++ uint8_t c = 0;
> ++ for (unsigned i = 0; i < N; i++)
> ++c += bbb.p[i].p_pixels[0];
> ++
> ++ if (c != N)
> ++__builtin_abort ();
> ++ return 0;
> ++}
> +diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> +index 507f81b0a0e8..ffbba3441de2 100644
> +--- a/gcc/tree-vect-stmts.c
> b/gcc/tree-vect-stmts.c
> +@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info stmt_info,
> tree vectype, bool slp,
> + /* First cope with the degenerate case of a single-element
> +vector. */
> + if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
> +- *memory_access_type = VMAT_CONTIGUOUS;
> ++ ;
> +
> + /* Otherwise try using LOAD/STORE_LANES. */
> +-if (*memory_access_type == VMAT_ELEMENTWISE
> +-&& (vls_type == VLS_LOAD
> +-? vect_load_lanes_supported (vectype, group_size, masked_p)
> +-: vect_store_lanes_supported (vectype, group_size,
> +- masked_p)))
> ++else if (vls_type == VLS_LOAD
> ++ ? vect_load_lanes_supported (vectype, group_size, masked_p)
> ++ : vect_store_lanes_supported
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Wed, 10 Feb 2021 at 11:12, Ray Smith wrote: > This has a desirable side-effect of enabling a build of mesa that > supports only OpenGL ES and EGL, without having the rest of the > distribution think that full OpenGL is available. The 'opengl' DISTRO_FEATURE is deliberately vague and doesn't have any implications regarding OpenGL vs OpenGL ES. If Mesa won't build with just GLES without GL, then that's a regression with OpenGL and should be taken up with them. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147960): https://lists.openembedded.org/g/openembedded-core/message/147960 Mute This Topic: https://lists.openembedded.org/mt/80529198/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 dunfell] gcc-9.3.inc: Fix potential runtime crash
Sorry, the subject should have "dunfell" in it
On Thu, Feb 11, 2021 at 10:57 AM Jon Mason via lists.openembedded.org
wrote:
>
> GCCv9 tree vectorization code is faulty and can cause random crashes at
> runtime (when using -O3). Add the backported patch to address this
> issue.
>
> Signed-off-by: Jon Mason
> ---
> meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
> ...-PR-tree-optimization-97236-fix-bad-.patch | 116 ++
> 2 files changed, 117 insertions(+)
> create mode 100644
> meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
> b/meta/recipes-devtools/gcc/gcc-9.3.inc
> index 4c54ba250aba..1c8e3df51d91 100644
> --- a/meta/recipes-devtools/gcc/gcc-9.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
> @@ -72,6 +72,7 @@ SRC_URI = "\
>
> file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
>
> file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
> file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
> +
> file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
> "
> S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
> SRC_URI[sha256sum] =
> "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
> diff --git
> a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
>
> b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> new file mode 100644
> index ..9020aa6c3a1e
> --- /dev/null
> +++
> b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
> @@ -0,0 +1,116 @@
> +From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
> +From: Matthias Klose
> +Date: Tue, 6 Oct 2020 13:41:37 +0200
> +Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad use of
> + VMAT_CONTIGUOUS
> +
> +This avoids using VMAT_CONTIGUOUS with single-element interleaving
> +when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
> +continue to avoid load-lanes and gathers.
> +
> +2020-10-01 Richard Biener
> +
> + PR tree-optimization/97236
> + * tree-vect-stmts.c (get_group_load_store_type): Keep
> + VMAT_ELEMENTWISE for single-element vectors.
> +
> + * gcc.dg/vect/pr97236.c: New testcase.
> +
> +(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
> +---
> + gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
> + gcc/tree-vect-stmts.c | 20 ++
> + 2 files changed, 52 insertions(+), 11 deletions(-)
> + create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
> +
> +diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
> b/gcc/testsuite/gcc.dg/vect/pr97236.c
> +new file mode 100644
> +index ..9d3dc20d953d
> +--- /dev/null
> b/gcc/testsuite/gcc.dg/vect/pr97236.c
> +@@ -0,0 +1,43 @@
> ++typedef unsigned char __uint8_t;
> ++typedef __uint8_t uint8_t;
> ++typedef struct plane_t {
> ++ uint8_t *p_pixels;
> ++ int i_lines;
> ++ int i_pitch;
> ++} plane_t;
> ++
> ++typedef struct {
> ++ plane_t p[5];
> ++} picture_t;
> ++
> ++#define N 4
> ++
> ++void __attribute__((noipa))
> ++picture_Clone(picture_t *picture, picture_t *res)
> ++{
> ++ for (int i = 0; i < N; i++) {
> ++res->p[i].p_pixels = picture->p[i].p_pixels;
> ++res->p[i].i_lines = picture->p[i].i_lines;
> ++res->p[i].i_pitch = picture->p[i].i_pitch;
> ++ }
> ++}
> ++
> ++int
> ++main()
> ++{
> ++ picture_t aaa, bbb;
> ++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
> ++
> ++ for (unsigned i = 0; i < N; i++)
> ++aaa.p[i].p_pixels = pixels;
> ++
> ++ picture_Clone (, );
> ++
> ++ uint8_t c = 0;
> ++ for (unsigned i = 0; i < N; i++)
> ++c += bbb.p[i].p_pixels[0];
> ++
> ++ if (c != N)
> ++__builtin_abort ();
> ++ return 0;
> ++}
> +diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
> +index 507f81b0a0e8..ffbba3441de2 100644
> +--- a/gcc/tree-vect-stmts.c
> b/gcc/tree-vect-stmts.c
> +@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info stmt_info,
> tree vectype, bool slp,
> + /* First cope with the degenerate case of a single-element
> +vector. */
> + if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
> +- *memory_access_type = VMAT_CONTIGUOUS;
> ++ ;
> +
> + /* Otherwise try using LOAD/STORE_LANES. */
> +-if (*memory_access_type == VMAT_ELEMENTWISE
> +-&& (vls_type == VLS_LOAD
> +-? vect_load_lanes_supported (vectype, group_size, masked_p)
> +-: vect_store_lanes_supported (vectype, group_size,
> +- masked_p)))
> ++else if (vls_type == VLS_LOAD
> ++ ? vect_load_lanes_supported (vectype, group_size, masked_p)
>
[OE-core] [meta-oe][PATCH] gcc-9.3.inc: Fix potential runtime crash
GCCv9 tree vectorization code is faulty and can cause random crashes at
runtime (when using -O3). Add the backported patch to address this
issue.
Signed-off-by: Jon Mason
---
meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
...-PR-tree-optimization-97236-fix-bad-.patch | 116 ++
2 files changed, 117 insertions(+)
create mode 100644
meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc
b/meta/recipes-devtools/gcc/gcc-9.3.inc
index 4c54ba250aba..1c8e3df51d91 100644
--- a/meta/recipes-devtools/gcc/gcc-9.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
@@ -72,6 +72,7 @@ SRC_URI = "\
file://0001-aarch64-New-Straight-Line-Speculation-SLS-mitigation.patch \
file://0002-aarch64-Introduce-SLS-mitigation-for-RET-and-BR-inst.patch \
file://0003-aarch64-Mitigate-SLS-for-BLR-instruction.patch \
+
file://0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch \
"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
SRC_URI[sha256sum] =
"71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
diff --git
a/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
new file mode 100644
index ..9020aa6c3a1e
--- /dev/null
+++
b/meta/recipes-devtools/gcc/gcc-9.3/0001-Backport-fix-for-PR-tree-optimization-97236-fix-bad-.patch
@@ -0,0 +1,116 @@
+From 97b668f9a8c6ec565c278a60e7d1492a6932e409 Mon Sep 17 00:00:00 2001
+From: Matthias Klose
+Date: Tue, 6 Oct 2020 13:41:37 +0200
+Subject: [PATCH] Backport fix for PR/tree-optimization/97236 - fix bad use of
+ VMAT_CONTIGUOUS
+
+This avoids using VMAT_CONTIGUOUS with single-element interleaving
+when using V1mode vectors. Instead keep VMAT_ELEMENTWISE but
+continue to avoid load-lanes and gathers.
+
+2020-10-01 Richard Biener
+
+ PR tree-optimization/97236
+ * tree-vect-stmts.c (get_group_load_store_type): Keep
+ VMAT_ELEMENTWISE for single-element vectors.
+
+ * gcc.dg/vect/pr97236.c: New testcase.
+
+(cherry picked from commit 1ab88985631dd2c5a5e3b5c0dce47cf8b6ed2f82)
+---
+ gcc/testsuite/gcc.dg/vect/pr97236.c | 43 +
+ gcc/tree-vect-stmts.c | 20 ++
+ 2 files changed, 52 insertions(+), 11 deletions(-)
+ create mode 100644 gcc/testsuite/gcc.dg/vect/pr97236.c
+
+diff --git a/gcc/testsuite/gcc.dg/vect/pr97236.c
b/gcc/testsuite/gcc.dg/vect/pr97236.c
+new file mode 100644
+index ..9d3dc20d953d
+--- /dev/null
b/gcc/testsuite/gcc.dg/vect/pr97236.c
+@@ -0,0 +1,43 @@
++typedef unsigned char __uint8_t;
++typedef __uint8_t uint8_t;
++typedef struct plane_t {
++ uint8_t *p_pixels;
++ int i_lines;
++ int i_pitch;
++} plane_t;
++
++typedef struct {
++ plane_t p[5];
++} picture_t;
++
++#define N 4
++
++void __attribute__((noipa))
++picture_Clone(picture_t *picture, picture_t *res)
++{
++ for (int i = 0; i < N; i++) {
++res->p[i].p_pixels = picture->p[i].p_pixels;
++res->p[i].i_lines = picture->p[i].i_lines;
++res->p[i].i_pitch = picture->p[i].i_pitch;
++ }
++}
++
++int
++main()
++{
++ picture_t aaa, bbb;
++ uint8_t pixels[10] = {1, 1, 1, 1, 1, 1, 1, 1};
++
++ for (unsigned i = 0; i < N; i++)
++aaa.p[i].p_pixels = pixels;
++
++ picture_Clone (, );
++
++ uint8_t c = 0;
++ for (unsigned i = 0; i < N; i++)
++c += bbb.p[i].p_pixels[0];
++
++ if (c != N)
++__builtin_abort ();
++ return 0;
++}
+diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
+index 507f81b0a0e8..ffbba3441de2 100644
+--- a/gcc/tree-vect-stmts.c
b/gcc/tree-vect-stmts.c
+@@ -2355,25 +2355,23 @@ get_group_load_store_type (stmt_vec_info stmt_info,
tree vectype, bool slp,
+ /* First cope with the degenerate case of a single-element
+vector. */
+ if (known_eq (TYPE_VECTOR_SUBPARTS (vectype), 1U))
+- *memory_access_type = VMAT_CONTIGUOUS;
++ ;
+
+ /* Otherwise try using LOAD/STORE_LANES. */
+-if (*memory_access_type == VMAT_ELEMENTWISE
+-&& (vls_type == VLS_LOAD
+-? vect_load_lanes_supported (vectype, group_size, masked_p)
+-: vect_store_lanes_supported (vectype, group_size,
+- masked_p)))
++else if (vls_type == VLS_LOAD
++ ? vect_load_lanes_supported (vectype, group_size, masked_p)
++ : vect_store_lanes_supported (vectype, group_size,
++ masked_p))
+ {
+ *memory_access_type = VMAT_LOAD_STORE_LANES;
+ overrun_p = would_overrun_p;
+ }
+
+ /* If that fails, try using permuting loads. */
+-if (*memory_access_type == VMAT_ELEMENTWISE
+-&&
[OE-core] [gatesgarth][PATCH 00/35] pull request (cover letter only)
Please merge these changes in gatesgarth. Thanks, Anuj The following changes since commit c63feb7e062750ef9d1fcfd6ee16f1d220f8a369: strace: increase ptest timeout duration 120->240s (2021-02-05 23:34:49 +) are available in the Git repository at: git://push.openembedded.org/openembedded-core-contrib stable/gatesgarth-next Alexander Kanavin (5): python3: split python target configuration into own class python3-pycairo: use python3targetconfig distutils3-base.bbclass: use python3targetconfig meta: drop _PYTHON_SYSCONFIGDATA_NAME hacks gpgme: use python3targetconfig Anuj Mittal (2): sudo: fix CVE-2021-23240 sudo: fix CVE-2021-3156 Awais Belal (1): kernel.bbclass: fix deployment for initramfs images Bruce Ashfield (3): linux-yocto/5.4: update to v5.4.90 linux-yocto-rt/5.4: fix 5.4-stable caused build breakage linux-yocto/5.4: update to v5.4.94 Chen Qi (1): systemd: change /bin/nologin to /sbin/nologin Dorinda (1): sanity.bbclass: Check if PSEUDO_IGNORE_PATHS and paths under pseudo control overlap Kamel Bouhara (2): npm.bbclass: make shrinkwrap file optional recipetool: create: only add npmsw url if required Khem Raj (1): python3targetconfig.bbclass: Make py3 dep and tasks only for target recipes Lee Chee Yang (2): openssl: set CVE_VERSION_SUFFIX wic/selftest: test_permissions also test bitbake image Martin Jansa (1): image_types.bbclass: tar: use posix format instead of gnu Michael Halstead (2): uninative: Upgrade to 2.10 yocto-uninative.inc: version 2.11 updates glibc to 2.33 Mike Looijmans (1): license_image.bbclass: Don't attempt to symlink to the same file Richard Purdie (8): image_types: Ensure tar archives are reproducible ncurses: Don't put terminfo into the sysroot python3: Avoid installing test data into recipe-sysroot staging: Clean up files installed into the sysroot package: Ensure do_packagedata is cleaned correctly qemu.inc: Should depend on qemu-system-native, not qemu-native openssh: Backport a fix to fix with glibc 2.33 on some platforms pseudo: Update to work with glibc 2.33 Steve Sakoman (1): glibc: update to latest release/2.32/master branch Tomasz Dziendzielski (1): sstatesig: Add descriptive error message to getpwuid/getgrgid "uid/gid not found" KeyError Vyacheslav Yurkov (1): npm.bbclass: use python3 for npm config saloni (2): libgcrypt: Whitelisted CVEs libcroco: Added CVE meta/classes/distutils3-base.bbclass | 2 +- meta/classes/image_types.bbclass | 2 +- meta/classes/kernel.bbclass | 2 +- meta/classes/license_image.bbclass| 3 +- meta/classes/npm.bbclass | 37 +- meta/classes/package.bbclass | 1 + meta/classes/python3native.bbclass| 2 - meta/classes/python3targetconfig.bbclass | 17 + meta/classes/sanity.bbclass | 10 + meta/classes/scons.bbclass| 3 - meta/classes/staging.bbclass | 4 + meta/conf/distro/include/yocto-uninative.inc | 10 +- meta/conf/machine/include/qemu.inc| 2 +- meta/lib/oe/prservice.py | 4 - meta/lib/oe/sstatesig.py | 6 +- meta/lib/oeqa/selftest/cases/wic.py | 16 + ...440ca70abab947acbd77795e9f130967956c.patch | 28 ++ .../openssh/openssh_8.3p1.bb | 1 + .../openssl/openssl_1.1.1i.bb | 2 + meta/recipes-core/glib-2.0/glib.inc | 4 - meta/recipes-core/glibc/glibc-version.inc | 2 +- .../glibc/glibc/CVE-2019-25013.patch | 137 -- meta/recipes-core/glibc/glibc_2.32.bb | 4 +- meta/recipes-core/ncurses/ncurses.inc | 5 + meta/recipes-core/systemd/systemd_246.9.bb| 16 +- meta/recipes-devtools/pseudo/pseudo_git.bb| 2 +- .../python/python3-pycairo_1.19.1.bb | 2 +- meta/recipes-devtools/python/python3_3.8.5.bb | 6 + .../sudo/files/CVE-2021-23240.patch | 419 ++ .../sudo/files/CVE-2021-3156-1.patch | 100 + .../sudo/files/CVE-2021-3156-2.patch | 53 +++ .../sudo/files/CVE-2021-3156-3.patch | 73 +++ .../sudo/files/CVE-2021-3156-4.patch | 29 ++ .../sudo/files/CVE-2021-3156-5.patch | 41 ++ meta/recipes-extended/sudo/sudo_1.9.3.bb | 6 + meta/recipes-graphics/mesa/mesa.inc | 5 - .../linux/linux-yocto-rt_5.4.bb | 6 +- .../linux/linux-yocto-tiny_5.4.bb | 8 +- meta/recipes-kernel/linux/linux-yocto_5.4.bb | 22 +- meta/recipes-support/gpgme/gpgme_1.14.0.bb| 2 +- .../libcroco/files/CVE-2020-12825.patch | 192 .../libcroco/libcroco_0.6.13.bb | 3 + .../libgcrypt/libgcrypt_1.8.6.bb | 3 + scripts/lib/recipetool/create_npm.py | 6 +- 44 files changed, 1085 insertions(+), 213 deletions(-) create mode
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On 11.02.21 15:59, Richard Purdie wrote: On Thu, 2021-02-11 at 15:47 +0100, Konrad Weihmann wrote: On 11.02.21 14:04, Richard Purdie wrote: On Thu, 2021-02-11 at 13:10 +0100, Konrad Weihmann wrote: On 11.02.21 12:43, Richard Purdie wrote: On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: After this patch got merged I notice some "noise" in my builds. I can guarantee that making any such option available will just have people reach for it and use it. You clearly want to here when the changes needed to avoid it are probably not that difficult. If that's not what the project wants, I'm also fine with it, but then it would be really helpful to point to the bbappend as a culprit and not the base recipe I understand why you'd want it, I'm just not sure if would encourage the right behaviour :(. Fair enough - guess I will go with the educating ppl (including myself) path then One thing to remember is that you can change ERROR_QA and WARN_QA on a per recipe basis, so in theory you can disable this per recipe, or reduce it to a warning... Its not neat code to do it, but it isn't really meant to be! Yeah, unfortunately all the CI tooling I use, will even reflect that back to the user - nvm I will figure out something Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147956): https://lists.openembedded.org/g/openembedded-core/message/147956 Mute This Topic: https://lists.openembedded.org/mt/80075083/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [v2][PATCH] connman: update to 1.39
[Yocto #14231]
Bug fix only and includes two security fixes:
CVE-2021-26675
CVE-2021-26676
Signed-off-by: Armin Kuster
---
.../connman/{connman_1.38.bb => connman_1.39.bb} | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
rename meta/recipes-connectivity/connman/{connman_1.38.bb => connman_1.39.bb}
(78%)
diff --git a/meta/recipes-connectivity/connman/connman_1.38.bb
b/meta/recipes-connectivity/connman/connman_1.39.bb
similarity index 78%
rename from meta/recipes-connectivity/connman/connman_1.38.bb
rename to meta/recipes-connectivity/connman/connman_1.39.bb
index 027c41e9afa..df42e9ffb8a 100644
--- a/meta/recipes-connectivity/connman/connman_1.38.bb
+++ b/meta/recipes-connectivity/connman/connman_1.39.bb
@@ -9,8 +9,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/network/${BPN}/${BP}.tar.xz \
SRC_URI_append_libc-musl = "
file://0002-resolve-musl-does-not-implement-res_ninit.patch"
-SRC_URI[md5sum] = "1ed8745354c7254bdfd4def54833ee94"
-SRC_URI[sha256sum] =
"cb30aca97c2f79ccaed8802aa2909ac5100a3969de74c0af8a9d73b85fc4932b"
+SRC_URI[sha256sum] =
"9f62a7169b7491c670a1ff2e335b0d966308fb2f62e285c781105eb90f181af3"
RRECOMMENDS_${PN} = "connman-conf"
RCONFLICTS_${PN} = "networkmanager"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147955):
https://lists.openembedded.org/g/openembedded-core/message/147955
Mute This Topic: https://lists.openembedded.org/mt/80559329/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On Thu, 2021-02-11 at 15:47 +0100, Konrad Weihmann wrote: > > On 11.02.21 14:04, Richard Purdie wrote: > > On Thu, 2021-02-11 at 13:10 +0100, Konrad Weihmann wrote: > > > > > > On 11.02.21 12:43, Richard Purdie wrote: > > > > On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: > > > > > After this patch got merged I notice some "noise" in my builds. > > > > I can guarantee that making any such option available will just have > > people reach for it and use it. You clearly want to here when the > > changes needed to avoid it are probably not that difficult. > > > > > If that's not what the project wants, I'm also fine with it, but then it > > > would be really helpful to point to the bbappend as a culprit and not > > > the base recipe > > > > I understand why you'd want it, I'm just not sure if would encourage > > the right behaviour :(. > > Fair enough - guess I will go with the educating ppl (including myself) > path then One thing to remember is that you can change ERROR_QA and WARN_QA on a per recipe basis, so in theory you can disable this per recipe, or reduce it to a warning... Its not neat code to do it, but it isn't really meant to be! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147954): https://lists.openembedded.org/g/openembedded-core/message/147954 Mute This Topic: https://lists.openembedded.org/mt/80075083/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On 11.02.21 14:04, Richard Purdie wrote: On Thu, 2021-02-11 at 13:10 +0100, Konrad Weihmann wrote: On 11.02.21 12:43, Richard Purdie wrote: On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: After this patch got merged I notice some "noise" in my builds. For bbappends which inherit unrelated classes I get a lot of warning like Issue: nativesdk-openssh: native/nativesdk class is not inherited last, this can result in unexpected behaviour. Classes inherited after native/nativesdk: my-custom-class.bbclass [native-last] First it doesn't give any hint that this is caused by the bbappend and secondly I have no idea how to fix that (if that is even possible). So I would like to have at least an option to ignore these warnings for classes I'm sure don't cause any conflict - something more granular then just to deactivate this pretty useful check. Thoughts? This shouldn't be too common as most recently use BBCLASSEXTEND which would ensure they're last. Which recipes are you running into this with? Sure, it does only affect recipes which are manually inheriting native (I got a bunch of them, that's why I noticed). Any reason they don't/can't use BBCLASSEXTEND? A (unfortunately) common pattern I face is that ppl share variables between recipes using bbclasses - which to my understanding shouldn't cause any issues when being inherited after native. And the same pattern is applied to recipes only being appended. You could use conf files for variables. That is something I'd like to try and encourage more of, I've been meaning to look at that for the core too. You really don't want your class coming after native/nativesdk, if you understand what that code is doing you'll realise it is rather risky :( Totally, that why I'm absolutely in favor of this patch. You could turn off that warning for a set of recipes if you really don't care but I'd prefer not to make that too easy. But that would turn off the whole feature, which is bad IMO. What I see (once that will be used by a wider audience in the wild) is that this will lead to questions (consuming my time as an integrator) or to the fact that this check will be turned off completely. Either way not the best choice if you'd ask me. I'm hoping that people might fix the underlying issues. That's why I asked for a more granular configuration, so that a person who's able to understand the implications of a bbclass in relation to native could turn it off on a distro/site config level. And just to be clear I wouldn't want that to be used widely, or even being promoted. I can guarantee that making any such option available will just have people reach for it and use it. You clearly want to here when the changes needed to avoid it are probably not that difficult. If that's not what the project wants, I'm also fine with it, but then it would be really helpful to point to the bbappend as a culprit and not the base recipe I understand why you'd want it, I'm just not sure if would encourage the right behaviour :(. Fair enough - guess I will go with the educating ppl (including myself) path then Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147953): https://lists.openembedded.org/g/openembedded-core/message/147953 Mute This Topic: https://lists.openembedded.org/mt/80075083/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: add workaround for faccessat2 being blocked by seccomp filters
Older seccomp-based filters used in container frameworks will block faccessat2
calls as it's a relatively new syscall. This isn't a big problem with
glibc <2.33 but 2.33 will call faccessat2 itself, get EPERM, and thenn be
confused
about what to do as EPERM isn't an expected error code.
Signed-off-by: Ross Burton
---
.../glibc/glibc/faccessat2-perm.patch | 31 +++
meta/recipes-core/glibc/glibc_2.33.bb | 1 +
2 files changed, 32 insertions(+)
create mode 100644 meta/recipes-core/glibc/glibc/faccessat2-perm.patch
diff --git a/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
b/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
new file mode 100644
index 00..2ee7110ca1
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/faccessat2-perm.patch
@@ -0,0 +1,31 @@
+Older seccomp-based filters used in container frameworks will block faccessat2
+calls as it's a relatively new syscall. This isn't a big problem with
+glibc <2.33 but 2.33 will call faccessat2 itself, get EPERM, and thenn be
confused
+about what to do as EPERM isn't an expected error code.
+
+This manifests itself as mysterious errors, for example a kernel failing to
link.
+
+The root cause of bad seccomp filters is mostly fixed (systemd 247, Docker
20.10.0)
+but we can't expect everyone to upgrade, so add a workaound (originally from
+Red Hat) to handle EPERM like ENOSYS and fallback to faccessat().
+
+Upstream-Status: Inappropriate
+Signed-off-by: Ross Burton
+
+diff --git a/sysdeps/unix/sysv/linux/faccessat.c
b/sysdeps/unix/sysv/linux/faccessat.c
+index 56cb6dcc8b4d58d3..5de75032bbc93a2c 100644
+--- a/sysdeps/unix/sysv/linux/faccessat.c
b/sysdeps/unix/sysv/linux/faccessat.c
+@@ -34,7 +34,11 @@ faccessat (int fd, const char *file, int mode, int flag)
+ #if __ASSUME_FACCESSAT2
+ return ret;
+ #else
+- if (ret == 0 || errno != ENOSYS)
++ /* Fedora-specific workaround:
++ As a workround for a broken systemd-nspawn that returns
++ EPERM when a syscall is not allowed instead of ENOSYS
++ we must check for EPERM here and fall back to faccessat. */
++ if (ret == 0 || !(errno == ENOSYS || errno == EPERM))
+ return ret;
+
+ if (flag & ~(AT_SYMLINK_NOFOLLOW | AT_EACCESS))
diff --git a/meta/recipes-core/glibc/glibc_2.33.bb
b/meta/recipes-core/glibc/glibc_2.33.bb
index 4085c779eb..e0002e6046 100644
--- a/meta/recipes-core/glibc/glibc_2.33.bb
+++ b/meta/recipes-core/glibc/glibc_2.33.bb
@@ -12,6 +12,7 @@ NATIVESDKFIXES_class-nativesdk = "\
file://0005-nativesdk-glibc-Raise-the-size-of-arrays-containing-.patch \
file://0006-nativesdk-glibc-Allow-64-bit-atomics-for-x86.patch \
file://0007-nativesdk-glibc-Make-relocatable-install-for-locales.patch \
+ file://faccessat2-perm.patch \
"
SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147952):
https://lists.openembedded.org/g/openembedded-core/message/147952
Mute This Topic: https://lists.openembedded.org/mt/80558829/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Thu, Feb 11, 2021 at 01:05:20PM +0100, Martin Jansa wrote: > Or you can read it as that it makes sense to build mesa recipe only when > DISTRO supports opengl or vulkan or opengles, It's never been the intent of DISTRO_FEATURES to determine which recipes it "makes sense" to build, above and beyond those that are actually impossible to compile in a given configuration. If there were certain recipes that are fundamentally and completely incompatible with a particular DISTRO_FEATURE to the extent that you simply couldn't build them at all then it might make sense to exclude them in this way, but I can't honestly think of even a single case where that would be true. Even at a fundamental level, there's no reason that a musl-based DISTRO couldn't also build glibc for example. Conversely, if a recipe simply needs some aspect of a given DISTRO_FEATURE to work then, in general, the solution to that is just to declare it as a dependency. Recipes that necessarily and unavoidably need OpenGL should just have virtual/libgl in their DEPENDS and there is no need for them to be checking DISTRO_FEATURES to see whether OpenGL is "available" in some abstract sense. If a particular DISTRO wants to actively prohibit mesa or any other recipe from being built (because it wants to ensure that certain code never leaks into the build artifacts due to a dependency error) then there are other mechanisms for that. The intent of the "opengl" DISTRO_FEATURE is that it gives you a single central place to control the configuration of packages that either have an optional dependency on OpenGL, or are selectable between OpenGL and Vulkan at configure time. Even this is a tiny bit half-baked because it doesn't really distinguish between the myriad variants of OpenGL(ES) but in general that distinction is a matter of platform capability rather than DISTRO choice (i.e. if your graphics stack only supports OpenGL ES 1.x, no amount of oe-core configuration is going to make it support OpenGL 4.) And the DISTRO_FEATURE does at least let you assert at the whole-distribution level that you have a preference for Vulkan over OpenGL, or vice versa. If you add opengl to DISTRO_FEATURES then you will start getting OpenGL support enabled in recipes like cairo. With the way the Mesa recipe is currently constituted, anybody who wants to build Mesa for some ancillary purpose but doesn't want everything else to start using OpenGL needs to add opengl to DISTRO_FEATURES and then engage in a game of whack-a-mole to go round turning it back off again in all the individual PACKAGECONFIGs. I don't think that's a rational state of affairs. p. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147951): https://lists.openembedded.org/g/openembedded-core/message/147951 Mute This Topic: https://lists.openembedded.org/mt/80529198/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][dunfell] sudo: 1.8.31 -> 1.8.32
From: Lee Chee Yang
release notes:
https://www.sudo.ws/legacy.html#1.8.32
updates include fixes for
CVE-2021-23239
CVE-2021-23240
Signed-off-by: Lee Chee Yang
---
meta/recipes-extended/sudo/sudo.inc | 2 +-
meta/recipes-extended/sudo/{sudo_1.8.31.bb => sudo_1.8.32.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-extended/sudo/{sudo_1.8.31.bb => sudo_1.8.32.bb} (92%)
diff --git a/meta/recipes-extended/sudo/sudo.inc
b/meta/recipes-extended/sudo/sudo.inc
index 5d27d46928..aeedfc1a23 100644
--- a/meta/recipes-extended/sudo/sudo.inc
+++ b/meta/recipes-extended/sudo/sudo.inc
@@ -4,7 +4,7 @@ HOMEPAGE = "http://www.sudo.ws;
BUGTRACKER = "http://www.sudo.ws/bugs/;
SECTION = "admin"
LICENSE = "ISC & BSD & Zlib"
-LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=4d1b44b1576eea036d78b8cc961aa93d \
+LIC_FILES_CHKSUM = "file://doc/LICENSE;md5=07966675feaddba70cc812895b248230 \
file://plugins/sudoers/redblack.c;beginline=1;endline=46;md5=03e35317699ba00b496251e0dfe9f109
\
file://lib/util/reallocarray.c;beginline=3;endline=15;md5=397dd45c7683e90b9f8bf24638cf03bf
\
file://lib/util/fnmatch.c;beginline=3;endline=27;md5=004d7d2866ba1f5b41174906849d2e0f
\
diff --git a/meta/recipes-extended/sudo/sudo_1.8.31.bb
b/meta/recipes-extended/sudo/sudo_1.8.32.bb
similarity index 92%
rename from meta/recipes-extended/sudo/sudo_1.8.31.bb
rename to meta/recipes-extended/sudo/sudo_1.8.32.bb
index 39d8817c32..af875f5b4c 100644
--- a/meta/recipes-extended/sudo/sudo_1.8.31.bb
+++ b/meta/recipes-extended/sudo/sudo_1.8.32.bb
@@ -7,8 +7,8 @@ SRC_URI = "https://www.sudo.ws/dist/sudo-${PV}.tar.gz \
PAM_SRC_URI = "file://sudo.pam"
-SRC_URI[md5sum] = "ce17ff6e72a70f8d5dabba8abf3cd2de"
-SRC_URI[sha256sum] =
"7ea8d97a3cee4c844e0887ea7a1bd80eb54cc98fd77966776cb1a80653ad454f"
+SRC_URI[md5sum] = "a7318202ba391079a0e32933f0fb8bd6"
+SRC_URI[sha256sum] =
"5ce3c18c5efbecd5437a0945f314f1822423eaf9a2d7eb7ecf80857bc32246c5"
DEPENDS += " virtual/crypt ${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'libpam', '', d)}"
RDEPENDS_${PN} += " ${@bb.utils.contains('DISTRO_FEATURES', 'pam',
'pam-plugin-limits pam-plugin-keyinit', '', d)}"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147950):
https://lists.openembedded.org/g/openembedded-core/message/147950
Mute This Topic: https://lists.openembedded.org/mt/80556958/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On Thu, 2021-02-11 at 13:10 +0100, Konrad Weihmann wrote: > > On 11.02.21 12:43, Richard Purdie wrote: > > On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: > > > After this patch got merged I notice some "noise" in my builds. > > > > > > For bbappends which inherit unrelated classes I get a lot of warning like > > > > > > Issue: nativesdk-openssh: native/nativesdk class is not inherited last, > > > this can result in unexpected behaviour. Classes inherited after > > > native/nativesdk: my-custom-class.bbclass [native-last] > > > > > > First it doesn't give any hint that this is caused by the bbappend and > > > secondly I have no idea how to fix that (if that is even possible). > > > > > > So I would like to have at least an option to ignore these warnings for > > > classes I'm sure don't cause any conflict - something more granular then > > > just to deactivate this pretty useful check. > > > > > > Thoughts? > > > > This shouldn't be too common as most recently use BBCLASSEXTEND which > > would ensure they're last. Which recipes are you running into this > > with? > > Sure, it does only affect recipes which are manually inheriting native > (I got a bunch of them, that's why I noticed). Any reason they don't/can't use BBCLASSEXTEND? > A (unfortunately) common pattern I face is that ppl share variables > between recipes using bbclasses - which to my understanding shouldn't > cause any issues when being inherited after native. > And the same pattern is applied to recipes only being appended. You could use conf files for variables. That is something I'd like to try and encourage more of, I've been meaning to look at that for the core too. > > You really don't want your class coming after native/nativesdk, if you > > understand what that code is doing you'll realise it is rather risky :( > > Totally, that why I'm absolutely in favor of this patch. > > > > > You could turn off that warning for a set of recipes if you really > > don't care but I'd prefer not to make that too easy. > > But that would turn off the whole feature, which is bad IMO. > What I see (once that will be used by a wider audience in the wild) is > that this will lead to questions (consuming my time as an integrator) or > to the fact that this check will be turned off completely. > Either way not the best choice if you'd ask me. I'm hoping that people might fix the underlying issues. > That's why I asked for a more granular configuration, so that a person > who's able to understand the implications of a bbclass in relation to > native could turn it off on a distro/site config level. > > And just to be clear I wouldn't want that to be used widely, or even > being promoted. I can guarantee that making any such option available will just have people reach for it and use it. You clearly want to here when the changes needed to avoid it are probably not that difficult. > If that's not what the project wants, I'm also fine with it, but then it > would be really helpful to point to the bbappend as a culprit and not > the base recipe I understand why you'd want it, I'm just not sure if would encourage the right behaviour :(. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147949): https://lists.openembedded.org/g/openembedded-core/message/147949 Mute This Topic: https://lists.openembedded.org/mt/80075083/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] sanity.bbclass: improve the network connectivity check message
On Wed, 2021-02-10 at 10:46 +0800, Yu, Mingli wrote:
> From: Mingli Yu
>
> The network connectivity check via checking www.example.com by default
> and also can customized by CONNECTIVITY_CHECK_URIS if desired.
>
> Improve the check message to let the user know if the network is actually
> unaccessible or the checked URIs is wrongly set.
>
> [YOCTO #12708]
>
> Signed-off-by: Mingli Yu
> ---
> meta/classes/sanity.bbclass | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
> index 485173ab48..ebf0a559a2 100644
> --- a/meta/classes/sanity.bbclass
> +++ b/meta/classes/sanity.bbclass
> @@ -389,13 +389,17 @@ def check_connectivity(d):
> except Exception as err:
> # Allow the message to be configured so that users can be
> # pointed to a support mechanism.
> +urlmsg = "Check network connectivity via the below tested URIs\n"
> +urlmsg += "please make sure the below tested URIs
> accessible\n"
> +for test_uri in test_uris:
> +urlmsg = "%s\n" % test_uri.strip()
> msg = data.getVar('CONNECTIVITY_CHECK_MSG') or ""
> if len(msg) == 0:
> msg = "%s.\n" % err
> msg += "Please ensure your host's network is configured
> correctly,\n"
> msg += "or set BB_NO_NETWORK = \"1\" to disable network
> access if\n"
> msg += "all required sources are on local disk.\n"
> -retval = msg
> +retval = urlmsg + msg
>
>
The idea was to allow things like toaster as a UI to override the
message entirely so this should probably just add to the len(msg) == 0
case. Probably something like:
if not msg:
msg = "%s.\n" % err
msg += "Please ensure your host's network is configured correctly,\n"
msg += "or set BB_NO_NETWORK = \"1\" to disable network access if\n"
msg += "all required sources are on local disk.\n"
msg += "The urls tested were:
for test_uri in test_uris:
msg += "%s\n" % test_uri.strip()
len(msg) == 0 is a horrible test so I tweaked that too :)
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147948):
https://lists.openembedded.org/g/openembedded-core/message/147948
Mute This Topic: https://lists.openembedded.org/mt/80523455/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On 11.02.21 12:43, Richard Purdie wrote: On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: After this patch got merged I notice some "noise" in my builds. For bbappends which inherit unrelated classes I get a lot of warning like Issue: nativesdk-openssh: native/nativesdk class is not inherited last, this can result in unexpected behaviour. Classes inherited after native/nativesdk: my-custom-class.bbclass [native-last] First it doesn't give any hint that this is caused by the bbappend and secondly I have no idea how to fix that (if that is even possible). So I would like to have at least an option to ignore these warnings for classes I'm sure don't cause any conflict - something more granular then just to deactivate this pretty useful check. Thoughts? This shouldn't be too common as most recently use BBCLASSEXTEND which would ensure they're last. Which recipes are you running into this with? Sure, it does only affect recipes which are manually inheriting native (I got a bunch of them, that's why I noticed). A (unfortunately) common pattern I face is that ppl share variables between recipes using bbclasses - which to my understanding shouldn't cause any issues when being inherited after native. And the same pattern is applied to recipes only being appended. You really don't want your class coming after native/nativesdk, if you understand what that code is doing you'll realise it is rather risky :( Totally, that why I'm absolutely in favor of this patch. You could turn off that warning for a set of recipes if you really don't care but I'd prefer not to make that too easy. But that would turn off the whole feature, which is bad IMO. What I see (once that will be used by a wider audience in the wild) is that this will lead to questions (consuming my time as an integrator) or to the fact that this check will be turned off completely. Either way not the best choice if you'd ask me. That's why I asked for a more granular configuration, so that a person who's able to understand the implications of a bbclass in relation to native could turn it off on a distro/site config level. And just to be clear I wouldn't want that to be used widely, or even being promoted. If that's not what the project wants, I'm also fine with it, but then it would be really helpful to point to the bbappend as a culprit and not the base recipe Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147947): https://lists.openembedded.org/g/openembedded-core/message/147947 Mute This Topic: https://lists.openembedded.org/mt/80075083/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Thu, Feb 11, 2021 at 11:59:43AM +, Ray Smith wrote: > On Wed, Feb 10, 2021 at 9:36 PM Otavio Salvador < > otavio.salva...@ossystems.com.br> wrote: > > > Em qua., 10 de fev. de 2021 às 17:21, Andrey Zhizhikin > > escreveu: > > > >> > >> Should this be clarified with Mesa folks upfront? If you believe that > >> this limitation is rather "artificial", then there has to be a proper > >> explanation from Mesa developers why OGL is provided when OGLES-only > >> is built. > >> > > > > Agreed ... I'd rather not drop the check until we hear from upstream the > > reasoning behind it. > > > > This patch is really about the first line: > > > Mesa doesn't _require_ either of these features of the distribution, > > it (conditionally) _provides_ them. > > Even if we had an opengles distro feature that solved the GLES vs OpenGL > issues, having a 'ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan > opengles"' line instead still wouldn't make sense (although it would solve > my problem), because mesa doesn't require any of those features. This line > is effectively saying it depends on the things it provides. Or you can read it as that it makes sense to build mesa recipe only when DISTRO supports opengl or vulkan or opengles, which IMHO still makes sense. Similarly when DISTO_FEATURES are used to set PACKAGECONFIG values, it doesn't say what it requires, but what DISTRO wants to support. signature.asc Description: PGP signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147946): https://lists.openembedded.org/g/openembedded-core/message/147946 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] mesa: Remove dependency on opengl or vulkan DISTRO_FEATURES
On Wed, Feb 10, 2021 at 9:36 PM Otavio Salvador < otavio.salva...@ossystems.com.br> wrote: > Em qua., 10 de fev. de 2021 às 17:21, Andrey Zhizhikin > escreveu: > >> >> Should this be clarified with Mesa folks upfront? If you believe that >> this limitation is rather "artificial", then there has to be a proper >> explanation from Mesa developers why OGL is provided when OGLES-only >> is built. >> > > Agreed ... I'd rather not drop the check until we hear from upstream the > reasoning behind it. > This patch is really about the first line: > Mesa doesn't _require_ either of these features of the distribution, > it (conditionally) _provides_ them. Even if we had an opengles distro feature that solved the GLES vs OpenGL issues, having a 'ANY_OF_DISTRO_FEATURES_class-target = "opengl vulkan opengles"' line instead still wouldn't make sense (although it would solve my problem), because mesa doesn't require any of those features. This line is effectively saying it depends on the things it provides. I will raise the build issue with mesa, but I think it's not related to the core issue here. There are no responses yet, but I see https://gitlab.freedesktop.org/mesa/mesa/-/issues/4176 was raised a couple of weeks ago with a very similar issue. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147945): https://lists.openembedded.org/g/openembedded-core/message/147945 Mute This Topic: https://lists.openembedded.org/mt/80529198/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
On Thu, 2021-02-11 at 08:21 +0100, Konrad Weihmann wrote: > After this patch got merged I notice some "noise" in my builds. > > For bbappends which inherit unrelated classes I get a lot of warning like > > Issue: nativesdk-openssh: native/nativesdk class is not inherited last, > this can result in unexpected behaviour. Classes inherited after > native/nativesdk: my-custom-class.bbclass [native-last] > > First it doesn't give any hint that this is caused by the bbappend and > secondly I have no idea how to fix that (if that is even possible). > > So I would like to have at least an option to ignore these warnings for > classes I'm sure don't cause any conflict - something more granular then > just to deactivate this pretty useful check. > > Thoughts? This shouldn't be too common as most recently use BBCLASSEXTEND which would ensure they're last. Which recipes are you running into this with? You really don't want your class coming after native/nativesdk, if you understand what that code is doing you'll realise it is rather risky :( You could turn off that warning for a set of recipes if you really don't care but I'd prefer not to make that too easy. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#147944): https://lists.openembedded.org/g/openembedded-core/message/147944 Mute This Topic: https://lists.openembedded.org/mt/80075083/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] insane: Add test for native/nativesdk inherit order
>After this patch got merged I notice some "noise" in my builds.
>
>For bbappends which inherit unrelated classes I get a lot of warning like
>
>Issue: nativesdk-openssh: native/nativesdk class is not inherited last,
>this can result in unexpected behaviour. Classes inherited after
>native/nativesdk: my-custom-class.bbclass [native-last]
>
>First it doesn't give any hint that this is caused by the bbappend and
>secondly I have no idea how to fix that (if that is even possible).
>
>So I would like to have at least an option to ignore these warnings for
>classes I'm sure don't cause any conflict - something more granular then
>just to deactivate this pretty useful check.
>
>Thoughts?
I think it's a good idea to just ignore specific classes. The diff below
should be enough, with some additional note in the warning message. I'll
check if it works correctly later today.
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 53230fc667..2f53a9be09 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1381,6 +1381,10 @@ python () {
# native also inherits nopackages and relocatable
bbclasses
skip_classes.extend(['nopackages', 'relocatable'])
+extra_skip_classes =
(d.getVar('NATIVE_LAST_IGNORE_CLASSES') or '').split()
+if extra_skip_classes:
+skip_classes.extend(extra_skip_classes)
+
broken_order = []
for class_item in reversed(inherited_classes):
if needle not in class_item:
Best regards,
Tomasz Dziendzielski
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147943):
https://lists.openembedded.org/g/openembedded-core/message/147943
Mute This Topic: https://lists.openembedded.org/mt/80075083/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
