[OE-core] [PATCH] ffmpeg: fix build failure when vulkan is enabled
The patch fixes the following errors observed when building ffmpeg in
vulkan-enabled distros:
| src/libavutil/hwcontext_vulkan.c:363:7: error:
'VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME' undeclared here (not in a function);
did you mean 'VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME'?
| 363 | { VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
| | ^~~
| | VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME
| src/libavutil/hwcontext_vulkan.c:364:7: error:
'VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME' undeclared here (not in a function);
did you mean 'VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME'?
| 364 | { VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
| | ^~~
| | VK_EXT_VIDEO_ENCODE_H265_EXTENSION_NAME
Signed-off-by: Dmitry Baryshkov
---
.../ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch | 34 +++
.../recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb | 1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
b/meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
new file mode 100644
index ..95bd608a2773
--- /dev/null
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
@@ -0,0 +1,34 @@
+From: Lynne
+Date: Sun, 25 Dec 2022 00:03:30 + (+0100)
+Subject: hwcontext_vulkan: remove optional encode/decode extensions from the
list
+X-Git-Url:
http://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff_plain/eb0455d64690
+
+hwcontext_vulkan: remove optional encode/decode extensions from the list
+
+They're not currently used, so they don't need to be there.
+Vulkan stabilized the decode extensions less than a week ago, and their
+name prefixes were changed from EXT to KHR. It's a bit too soon to be
+depending on it, so rather than bumping, just remove these for now.
+
+Upstream-Status: Backport
[https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff_plain/eb0455d64690]
+---
+
+diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
+index f1db1c7291..2a9b5f4aac 100644
+--- a/libavutil/hwcontext_vulkan.c
b/libavutil/hwcontext_vulkan.c
+@@ -358,14 +358,6 @@ static const VulkanOptExtension optional_device_exts[] = {
+ { VK_KHR_EXTERNAL_MEMORY_WIN32_EXTENSION_NAME,
FF_VK_EXT_EXTERNAL_WIN32_MEMORY },
+ { VK_KHR_EXTERNAL_SEMAPHORE_WIN32_EXTENSION_NAME,
FF_VK_EXT_EXTERNAL_WIN32_SEM },
+ #endif
+-
+-/* Video encoding/decoding */
+-{ VK_KHR_VIDEO_QUEUE_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+-{ VK_KHR_VIDEO_DECODE_QUEUE_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+-{ VK_KHR_VIDEO_ENCODE_QUEUE_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+-{ VK_EXT_VIDEO_ENCODE_H264_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+-{ VK_EXT_VIDEO_DECODE_H264_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+-{ VK_EXT_VIDEO_DECODE_H265_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+ };
+
+ /* Converts return values to strings */
diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
index 63abc5d437a8..cccd9f65abf5 100644
--- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
+++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.1.2.bb
@@ -25,6 +25,7 @@ LIC_FILES_CHKSUM =
"file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
file://0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch \
file://0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
\
+ file://ffmpeg-fix-vulkan.patch \
"
SRC_URI[sha256sum] =
"619e706d662c8420859832ddc259cd4d4096a48a2ce1eefd052db9e440eef3dc"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177714):
https://lists.openembedded.org/g/openembedded-core/message/177714
Mute This Topic: https://lists.openembedded.org/mt/97218258/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] create-spdx: Add check for variable contents along with quotes
On Fri, Feb 24, 2023 at 1:25 PM Saul Wold wrote:
>
> This adds a check to ensure we that if a variable is
> empty it gets an empty string, this also adds quotes
> to indicate the variable contents.
>
> "comment": "CUSTOM_SPECIAL="
> or
> "comment": "CUSTOM_SPECIAL=variable contents"
>
> Signed-off-by: Saul Wold
> ---
> meta/classes/create-spdx-2.2.bbclass | 5 ++-
> .../selftest/cases/spdx_custom_annotations.py | 42 +++
> 2 files changed, 46 insertions(+), 1 deletion(-)
> create mode 100644 meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
>
> diff --git a/meta/classes/create-spdx-2.2.bbclass
> b/meta/classes/create-spdx-2.2.bbclass
> index 454dd7a7a07..da90bf8033a 100644
> --- a/meta/classes/create-spdx-2.2.bbclass
> +++ b/meta/classes/create-spdx-2.2.bbclass
> @@ -524,7 +524,10 @@ python do_create_spdx() {
>
> if d.getVar("SPDX_CUSTOM_ANNOTATION_VARS"):
> for var in d.getVar('SPDX_CUSTOM_ANNOTATION_VARS').split():
> -recipe.annotations.append(create_annotation(d, var + "=" +
> d.getVar(var)))
> +if d.getVar(var):
> +recipe.annotations.append(create_annotation(d, var + "=" +
> d.getVar(var).replace('"', '\\"')))
Manually trying to escape quotes can be really hard; Is there a
particular reason it's necessary? If you're trying to read this back
programmatically, I'd expect:
name, value = annotation.split(=, 1)
to work
> +else:
> +recipe.annotations.append(create_annotation(d, var + "="))
>
> # Some CVEs may be patched during the build process without incrementing
> the version number,
> # so querying for CVEs based on the CPE id can lead to false positives.
> To account for this,
> diff --git a/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
> b/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
> new file mode 100644
> index 000..a2bef998988
> --- /dev/null
> +++ b/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
> @@ -0,0 +1,42 @@
> +#
> +# Copyright OpenEmbedded Contributors
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +from oeqa.selftest.case import OESelftestTestCase
> +from oeqa.utils.commands import bitbake
> +import json
> +
> +class SPDXCustomAnnotations(OESelftestTestCase):
> +
> +# Build test recipes with custom-annotation
> +def test_spdx_custom_annotations(self):
> +self.write_config("INHERIT:append = ' create_spdx'")
> +
> +result = bitbake('%s custom-annotation')
> +print(f"Bitbake Result: {result}")
> +try:
> +mdir = self.get_dir_from_bb_var('DEPLOY_DIR_SPDX',
> self.buildtarget)
> +with open(f"{mdir}/recpes/recipe-{pn}.spdx.json") as json_file:
> +spdx_json = json.load(json_file)
> +
> print(f'{spdx_json["packages"]["annotations"][0]["comment"]}')
> +
> self.assertEqual(spdx_json["packages"]["annotations"][0]["comment"],
> "ANNOTE1=This is the first custom annotation")
> +
> self.assertEqual(spdx_json["packages"]["annotations"][1]["comment"],
> "ANNOTE2=This is another custom annotation")
> +except:
> +print("json load failed")
> +
> +#class SPDXCustomeAnnotationTests(OESelftestTestCase):
> +#def default_config(self):
> +#return """
> +#INHERIT:append = " create-spdx"
> +#SPDX_CUSTOM_ANNOTATION_VARS:pn-core-image-minimal = "TEST_VAR"
> +#TEST_VAR:pn-core-image-minimal = "This is a test annotation"
> +#"""
> +#
> +#def test_image_annotation(self):
> +#self.write_config(self.default_config())
> +#
> +#result = bitbake('core-image-minimal', ignore_status=True)
> +
> +
> +
> --
> 2.25.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177713):
https://lists.openembedded.org/g/openembedded-core/message/177713
Mute This Topic: https://lists.openembedded.org/mt/97213264/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH] openssl: upgrade 1.1.1s to 1.1.1t
Also a corruption issue with this patch:
Applying: openssl: upgrade 1.1.1s to 1.1.1t
error: corrupt patch at line 19
error: could not build fake ancestor
Patch failed at 0001 openssl: upgrade 1.1.1s to 1.1.1t
Steve
On Tue, Feb 21, 2023 at 6:24 AM Hugo Simeliere via
lists.openembedded.org
wrote:
>
> Major changes between OpenSSL 1.1.1s and OpenSSL 1.1.1t [7 Feb 2023]
>
> * Fixed X.400 address type confusion in X.509 GeneralName (CVE-2023-0286)
>
> * Fixed Use-after-free following BIO_new_NDEF (CVE-2023-0215)
>
> * Fixed Double free after calling PEM_read_bio_ex (CVE-2022-4450)
>
> * Fixed Timing Oracle in RSA Decryption (CVE-2022-4304)
>
>
>
> Signed-off-by: Hugo SIMELIERE
>
> ---
>
> .../openssl/{openssl_1.1.1s.bb => openssl_1.1.1t.bb}| 2 +-
>
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> rename meta/recipes-connectivity/openssl/{openssl_1.1.1s.bb =>
> openssl_1.1.1t.bb} (98%)
>
>
>
> diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1s.bb
> b/meta/recipes-connectivity/openssl/openssl_1.1.1t.bb
>
> similarity index 98%
>
> rename from meta/recipes-connectivity/openssl/openssl_1.1.1s.bb
>
> rename to meta/recipes-connectivity/openssl/openssl_1.1.1t.bb
>
> index 6c8f285996..a1956ad8c2 100644
>
> --- a/meta/recipes-connectivity/openssl/openssl_1.1.1s.bb
>
> +++ b/meta/recipes-connectivity/openssl/openssl_1.1.1t.bb
>
> @@ -24,7 +24,7 @@ SRC_URI_append_class-nativesdk = " \
>
> file://environment.d-openssl.sh \
>
> "
>
> -SRC_URI[sha256sum] =
> "c5ac01e760ee6ff0dab61d6b2bbd30146724d063eb322180c6f18a6f74e4b6aa"
>
> +SRC_URI[sha256sum] =
> "8dee9b24bdb1dcbf0c3d1e9b02fb8f6bf22165e807f45adeb7c9677536859d3b"
>
> inherit lib_package multilib_header multilib_script ptest
>
> MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"
>
> --
>
> 2.25.1
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177712):
https://lists.openembedded.org/g/openembedded-core/message/177712
Mute This Topic: https://lists.openembedded.org/mt/97112482/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][dunfell][PATCH] bluez5: Exclude CVE-2022-39177 from cve-check
On Tue, Feb 21, 2023 at 6:58 AM Hugo Simeliere via lists.openembedded.org wrote: > > CVE already fixed in CVE-2022-39176.patch > > > > Signed-off-by: Hugo SIMELIERE > > --- > > meta/recipes-connectivity/bluez5/bluez5_5.55.bb | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/meta/recipes-connectivity/bluez5/bluez5_5.55.bb > b/meta/recipes-connectivity/bluez5/bluez5_5.55.bb > > index e5353bd815..be74a35e0a 100644 > > --- a/meta/recipes-connectivity/bluez5/bluez5_5.55.bb > > +++ b/meta/recipes-connectivity/bluez5/bluez5_5.55.bb > > @@ -6,6 +6,13 @@ SRC_URI[sha256sum] = > "8863717113c4897e2ad3271fc808ea245319e6fd95eed2e934fae8e089 > Your mailer seems to be corrupting the patch: Applying: bluez5: Exclude CVE-2022-39177 from cve-check error: corrupt patch at line 10 error: could not build fake ancestor Patch failed at 0001 bluez5: Exclude CVE-2022-39177 from cve-check Please correct and send a V2. Thanks! Steve > # These issues have kernel fixes rather than bluez fixes so exclude here > > CVE_CHECK_WHITELIST += "CVE-2020-12352 CVE-2020-24490" > > +# Commit 7a80d2096f1b7125085e21448112aa02f49f5e9a, > e2b0f0d8d63e1223bb714a9efb37e2257818268b > > +# and 0388794dc5fdb73a4ea88bcf148de0a12b4364d4 to fix CVE-2022-39177 > > +# already backport in CVE-2022-39176.patch > > +# https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1977968 > > + > > +CVE_CHECK_WHITELIST += "CVE-2022-39177" > > + > > # noinst programs in Makefile.tools that are conditional on READLINE > > # support > > NOINST_TOOLS_READLINE ?= " \ > > -- > > 2.25.1 > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177711): https://lists.openembedded.org/g/openembedded-core/message/177711 Mute This Topic: https://lists.openembedded.org/mt/97113394/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] systemd: add user for systemd-oomd if enabled
From: Luca Boccassi
systemd-oomd.service has:
User=systemd-oom
So we need to create a static user for it, if its packageconfig
is enabled.
Signed-off-by: Luca Boccassi
---
meta/recipes-core/systemd/systemd_252.5.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/systemd/systemd_252.5.bb
b/meta/recipes-core/systemd/systemd_252.5.bb
index 64a3efa1d4..4eca622352 100644
--- a/meta/recipes-core/systemd/systemd_252.5.bb
+++ b/meta/recipes-core/systemd/systemd_252.5.bb
@@ -417,6 +417,7 @@ USERADD_PARAM:${PN} +=
"${@bb.utils.contains('PACKAGECONFIG', 'networkd', '--sys
USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'polkit',
'--system --no-create-home --user-group --home-dir ${sysconfdir}/polkit-1
polkitd;', '', d)}"
USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'resolved',
'--system -d / -M --shell /sbin/nologin systemd-resolve;', '', d)}"
USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'timesyncd',
'--system -d / -M --shell /sbin/nologin systemd-timesync;', '', d)}"
+USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'oomd',
'--system -d / -M --shell /sbin/nologin systemd-oom;', '', d)}"
USERADD_PARAM:${PN}-extra-utils = "--system -d / -M --shell /sbin/nologin
systemd-bus-proxy"
USERADD_PARAM:${PN}-journal-gatewayd = "--system -d / -M --shell /sbin/nologin
systemd-journal-gateway"
USERADD_PARAM:${PN}-journal-remote = "--system -d / -M --shell /sbin/nologin
systemd-journal-remote"
--
2.39.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177710):
https://lists.openembedded.org/g/openembedded-core/message/177710
Mute This Topic: https://lists.openembedded.org/mt/97213395/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] create-spdx: Add check for variable contents along with quotes
This adds a check to ensure we that if a variable is
empty it gets an empty string, this also adds quotes
to indicate the variable contents.
"comment": "CUSTOM_SPECIAL="
or
"comment": "CUSTOM_SPECIAL=variable contents"
Signed-off-by: Saul Wold
---
meta/classes/create-spdx-2.2.bbclass | 5 ++-
.../selftest/cases/spdx_custom_annotations.py | 42 +++
2 files changed, 46 insertions(+), 1 deletion(-)
create mode 100644 meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
diff --git a/meta/classes/create-spdx-2.2.bbclass
b/meta/classes/create-spdx-2.2.bbclass
index 454dd7a7a07..da90bf8033a 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -524,7 +524,10 @@ python do_create_spdx() {
if d.getVar("SPDX_CUSTOM_ANNOTATION_VARS"):
for var in d.getVar('SPDX_CUSTOM_ANNOTATION_VARS').split():
-recipe.annotations.append(create_annotation(d, var + "=" +
d.getVar(var)))
+if d.getVar(var):
+recipe.annotations.append(create_annotation(d, var + "=" +
d.getVar(var).replace('"', '\\"')))
+else:
+recipe.annotations.append(create_annotation(d, var + "="))
# Some CVEs may be patched during the build process without incrementing
the version number,
# so querying for CVEs based on the CPE id can lead to false positives. To
account for this,
diff --git a/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
b/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
new file mode 100644
index 000..a2bef998988
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/spdx_custom_annotations.py
@@ -0,0 +1,42 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake
+import json
+
+class SPDXCustomAnnotations(OESelftestTestCase):
+
+# Build test recipes with custom-annotation
+def test_spdx_custom_annotations(self):
+self.write_config("INHERIT:append = ' create_spdx'")
+
+result = bitbake('%s custom-annotation')
+print(f"Bitbake Result: {result}")
+try:
+mdir = self.get_dir_from_bb_var('DEPLOY_DIR_SPDX',
self.buildtarget)
+with open(f"{mdir}/recpes/recipe-{pn}.spdx.json") as json_file:
+spdx_json = json.load(json_file)
+print(f'{spdx_json["packages"]["annotations"][0]["comment"]}')
+
self.assertEqual(spdx_json["packages"]["annotations"][0]["comment"],
"ANNOTE1=This is the first custom annotation")
+
self.assertEqual(spdx_json["packages"]["annotations"][1]["comment"],
"ANNOTE2=This is another custom annotation")
+except:
+print("json load failed")
+
+#class SPDXCustomeAnnotationTests(OESelftestTestCase):
+#def default_config(self):
+#return """
+#INHERIT:append = " create-spdx"
+#SPDX_CUSTOM_ANNOTATION_VARS:pn-core-image-minimal = "TEST_VAR"
+#TEST_VAR:pn-core-image-minimal = "This is a test annotation"
+#"""
+#
+#def test_image_annotation(self):
+#self.write_config(self.default_config())
+#
+#result = bitbake('core-image-minimal', ignore_status=True)
+
+
+
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177709):
https://lists.openembedded.org/g/openembedded-core/message/177709
Mute This Topic: https://lists.openembedded.org/mt/97213264/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 v3 0/6] scripts/resulttool/regression: add metadata filtering
Hi Alexis, Firstly, this looks very much improved, thanks. It is great to start to see some meaningful data from this. On Fri, 2023-02-24 at 17:45 +0100, Alexis Lothoré via lists.openembedded.org wrote: > From: Alexis Lothoré > > Hello, > this new series is the follow-up of [1] to make regression reports more > meaningful, by reducing noise and false positives. > > Change since v2: > - add filtering on MACHINE field from test results configuration: the MACHINE > should always match > - add "metadata guessing" mechanism based on Richard proposal ([2]). Up to the > point where this series will be merged, tests results stored in git are not > enriched with OESELFTEST_METADATA. To allow proper test comparison even with > those tests, try to guess what oeselftest command line has been used to run > the corresponding tests, and generate OESELFTEST_METADATA accordingly > - add new tool to ease test results usage: yocto_testresults_query. For now > the > tool only manages regression report and is a thin layer between > send-qa-email > (in yocto-autobuilder-helper) and resulttool. Its main role is to translate > regression reports arguments (which are tags or branches) to fixed revisions > and to call resulttool accordingly. Most of its code is a transfer from > send-qa-email (another series for the autobuilder will follow this one to > make > send-qa-email use this new helper, but this current series works > independently) > Example: "yocto_testresults_query.py regression-report 4.2_M1 4.2_M2" will > replay the regression report generated when the 4.2_M2 has been generated. > > Change since v1: > - properly configure "From" field in series > > With those improvements, the regression report is significantly reduced and > some > useful data start to emerge from the removed noise: > - with the MACHINE filtering, the 4.2_M2 report goes from 5.5GB to 627MB > - with the OESELFTEST_METADATA enrichment + metadata guessing for older tests, > the report goes from 627MB to 1.5MB That is just a bit more readable! > > After manual inspection on some entries, the remaining oeselftest regression > raised in the report seems valid. There are still some issues to tackle: > - it seems that now one major remaining source of noise is on the "runtime" > tests (comparison to tests not run on "target" results) > - when a ptest managed by oe-selftest fails, I guess the remaining tests are > not > run, so when 1 failure is logged, we have many "PASSED->None" transitions in > regression report, we should probably silence it. > - some transitions appear as regression while those are in fact improvements > (e.g: "UNRESOLVED->PASSED") I had quick play. Firstly, if I try "yocto_testresults_query.py regression-report 4.2_M1 4.2_M2" in an openembedded-core repository instead of poky, it breaks. That isn't surprising but we should either make it work or show a sensible error. I also took a look the report and wondered why the matching isn't quite right and why we have these "regressions". If we could remove that noise, I think we'd get down to the real issues. I ended up doing: resulttool report --commit 4d19594b8bdacde6d809d3f2a25cff7c5a42295e . > /tmp/repa resulttool report --commit 5e249ec855517765f4b99e8039cb888ffa09c211 . > /tmp/repb meld /tmp/rep* which was interesting as gave lots of warnings like: "Warning duplicate ptest result 'acl.test/cp.test' for qemuarm64" so it looks like we had a couple of different test runs for qemuarm64 ptests which is confusing your new code. I suspect this happened due to some autobuilder glitch during the release build which restarted some of the build pieces. Not sure how to handle that yet, I'll give it some further thought but I wanted to share what I think is the source of some of the issues. Basically we need to get the regression report looking more like that meld output! Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177708): https://lists.openembedded.org/g/openembedded-core/message/177708 Mute This Topic: https://lists.openembedded.org/mt/97209732/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] musl: Update to tip of trunk
This brings in following changes
* 7d756e1c (upstream/master, origin/master) dns: prefer monotonic clock for
timeouts
* 07616721 fix return value of wcs{,n}cmp for extreme wchar_t values
* 35fdfe62 math: fix undefined shift in logf
* 7e13e5ae inet_pton: fix uninitialized memory use for IPv4-mapped IPv6
addresses
* 7e6da7ac hsearch: fix null pointer arithmetic UB
* f79b973d increase sendmsg internal buffer to support SCM_MAX_FD
* 0ab97350 mq_notify: block all (application) signals in the worker thread
* 711673ee mq_notify: join worker thread before returning in error path
* 8c0c9c69 mq_notify: rework to fix use-after-close/double-close bugs
* fde6891e mq_notify: use semaphore instead of barrier to sync args consumption
* c3cd04fa fix pthread_detach inadvertently acting as cancellation point in
race case
* 115149c0 powerpc-sf longjmp clobbering of val argument
* 5763f003 riscv64: add vfork
* 269d1938 fix wrong sigaction syscall ABI on mips*, or1k, microblaze, riscv64
* ea3b40a3 fix integer overflow in WIFSTOPPED macro
* f897461d fix debugger tracking of shared libraries on mips with PIE main
program
* a4b0a665 expose memmem under baseline POSIX feature profile
* 9532ae13 use libc-internal malloc for pthread_atfork
* 7d358599 prevent invalid reads of nl_arg in printf_core
* c5f4b2df elf.h: add ELFCOMPRESS_ZSTD
* 159d1f6c semaphores: fix missed wakes from ABA bug in waiter count logic
Signed-off-by: Khem Raj
---
meta/recipes-core/musl/musl_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/musl/musl_git.bb
b/meta/recipes-core/musl/musl_git.bb
index 7749495ec6..39f6dd8219 100644
--- a/meta/recipes-core/musl/musl_git.bb
+++ b/meta/recipes-core/musl/musl_git.bb
@@ -4,7 +4,7 @@
require musl.inc
inherit linuxloader
-SRCREV = "f47a8cdd250d9163fcfb39bf4e9d813957c0b187"
+SRCREV = "7d756e1c04de6eb3f2b3d3e1141a218bb329fcfb"
BASEVER = "1.2.3"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177707):
https://lists.openembedded.org/g/openembedded-core/message/177707
Mute This Topic: https://lists.openembedded.org/mt/97211365/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 03/11] build-appliance-image: add support for qemu
On Fri, 2023-02-24 at 16:05 +, Richard Purdie via lists.openembedded.org wrote: > On Tue, 2023-02-21 at 15:44 -0500, Trevor Woerner wrote: > > Add ext4 explicitly to the list of IMAGE_FSTYPES so the build appliance can > > be > > run with runqemu. > > > > Signed-off-by: Trevor Woerner > > --- > > meta/recipes-core/images/build-appliance-image_15.0.0.bb | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb > > b/meta/recipes-core/images/build-appliance-image_15.0.0.bb > > index 064e7a1ed82f..e28096758b9b 100644 > > --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb > > +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb > > @@ -1,5 +1,5 @@ > > SUMMARY = "An image containing the build system itself" > > -DESCRIPTION = "An image containing the build system that you can boot and > > run using either VirtualBox, VMware Player or VMware Workstation." > > +DESCRIPTION = "An image containing the build system that you can boot and > > run using any of qemu, VirtualBox, VMware Player or VMware Workstation." > > HOMEPAGE = "http://www.yoctoproject.org/documentation/build-appliance"; > > > > LICENSE = "MIT" > > @@ -20,7 +20,7 @@ IMAGE_ROOTFS_EXTRA_SPACE = "41943040" > > APPEND += "rootfstype=ext4 quiet" > > > > DEPENDS = "zip-native python3-pip-native" > > -IMAGE_FSTYPES = "wic.vmdk wic.vhd wic.vhdx" > > +IMAGE_FSTYPES = "ext4 wic.vmdk wic.vhd wic.vhdx" > > > > inherit core-image setuptools3 > > > > I've held off this one since whilst it isn't wrong as such, the ext > images aren't exactly optimal. I think our hope was that we could use > the vmdk or vhdx images with qemu instead and then directly test the > ones we publicly share. Do you know if that could work? It may then > mean people don't need to handle multiple files too? I quickly tried: qemu-system-x86_64 tmp/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk -enable-kvm and it nearly works (splash screen displayed but then went blank) so I suspect runqemu could likely learn to run these relatively easily. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177706): https://lists.openembedded.org/g/openembedded-core/message/177706 Mute This Topic: https://lists.openembedded.org/mt/97118441/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] icecc.bbclass: enable the network only when ICECC_DISABLED is not set
On Fri, 2023-02-24 at 17:38 +0100, Martin Jansa wrote:
> On Fri, Feb 24, 2023 at 5:27 PM Richard Purdie
> wrote:
> > On Fri, 2023-02-17 at 09:58 +, Jose Quaresma wrote:
> > > Enabling the network uncondictional is not need for some use
> > > cases.
> > >
> > > Such use case is usefull to reuse the sstate-cache of the build
> > > and it requires the icecc inherit in all of the builds.
> > > The real control control of the icecc is in the variable
> > > ICECC_DISABLED
> > > so this patch change the logic to enable the network when the
> > > icecc is in use.
> > >
> > > Signed-off-by: Jose Quaresma
> > > ---
> > > meta/classes/icecc.bbclass | 10 ++
> > > 1 file changed, 6 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/meta/classes/icecc.bbclass
> > > b/meta/classes/icecc.bbclass
> > > index 312e0f17b5..159cae20f8 100644
> > > --- a/meta/classes/icecc.bbclass
> > > +++ b/meta/classes/icecc.bbclass
> > > @@ -428,22 +428,18 @@ set_icecc_env() {
> > > bbnote "Using icecc tarball: $ICECC_VERSION"
> > > }
> > >
> > > -do_configure[network] = "1"
> > > do_configure:prepend() {
> > > set_icecc_env
> > > }
> > >
> > > -do_compile[network] = "1"
> > > do_compile:prepend() {
> > > set_icecc_env
> > > }
> > >
> > > -do_compile_kernelmodules[network] = "1"
> > > do_compile_kernelmodules:prepend() {
> > > set_icecc_env
> > > }
> > >
> > > -do_install[network] = "1"
> > > do_install:prepend() {
> > > set_icecc_env
> > > }
> > > @@ -457,3 +453,9 @@ ICECC_SDK_HOST_TASK:pn-uninative-tarball = ""
> > >
> > > # Add the toolchain scripts to the SDK
> > > TOOLCHAIN_HOST_TASK:append = " ${ICECC_SDK_HOST_TASK}"
> > > +
> > > +python () {
> > > + if d.getVar('ICECC_DISABLED') != "1":
> > > + for task in ['do_configure', 'do_compile',
> > > 'do_compile_kernelmodules', 'do_install']:
> > > + d.setVarFlag(task, 'network', '1')
> > > +}
> >
> > I did want to talk a little about the overhead this has. Basically
> > you've turned a simple flag setting into some anonymous python so
> > the
> > parsing overhead increases with it since there is now code parsing
> > and
> > execution to add in.
> >
> > For a single recipe this isn't so bad but when it is being added to
> > every recipe it adds up.
> >
> > I'm not against the change as such, I just see a continual flood of
> > patches adding conditions everywhere for various reasons and each
> > one
> > degrades parsing speed a little bit more (as well as complicates
> > the
> > test matrix).
> >
> > I personally don't use this class so I don't have a stake in this
> > one
> > but I thought it worth highlighting since I think the overhead of
> > this
> > was mentioned elsewhere and I think the overhead isn't widely
> > understood.
> >
>
>
> As the network evaluation patch was merged in bitbake:
> https://git.openembedded.org/bitbake/commit/?id=3d96c07f9fd4ba1a84826811d14bb4e98ad58846
>
> I can send my inline version:
> https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=1b143f065ab5408f5543951a8c73fa01ce3ee0c1
>
> This works for master, for langdale and kirkstone we would need to
> backport this bitbake commit as well as "utils: Allow to_boolean to
> support int values", I have all 3 in my branches for kirkstone and
> langdale and can send them as soon as there is agreement to do that
> (e.g. top 5 changes from
> https://git.openembedded.org/bitbake-contrib/log/?h=jansa/2.0)
Just to explain things for the purposes of the archives, that inline
patch, whilst quite neat looking, will perform worse than the anonymous
python.
The reason is relatively simple. The anonymous python will run once,
the inline will cause 4 different python fragments to run at best when
the variable is expanded. Bitbake will have to expand it to compute the
recipes basehashes. In reality, the expansion cache is often
invalidated by datastore write operations so it can be expanded
multiple times.
I'm also reluctant to backport a performance regression and change in
behaviour back to stable branches so Jose's patch may be the better
option.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177705):
https://lists.openembedded.org/g/openembedded-core/message/177705
Mute This Topic: https://lists.openembedded.org/mt/97025329/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3 6/6] oeqa/selftest: add test for yocto_testresults_query.py
From: Alexis Lothoré
Add some tests for new yocto_testresults_query.py helper. First test is taken
from yocto-autobuilder-helper feature which has moved in yocto_testresults_query
Signed-off-by: Alexis Lothoré
---
.../cases/yoctotestresultsquerytests.py | 39 +++
1 file changed, 39 insertions(+)
create mode 100644 meta/lib/oeqa/selftest/cases/yoctotestresultsquerytests.py
diff --git a/meta/lib/oeqa/selftest/cases/yoctotestresultsquerytests.py
b/meta/lib/oeqa/selftest/cases/yoctotestresultsquerytests.py
new file mode 100644
index 000..312edb64319
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/yoctotestresultsquerytests.py
@@ -0,0 +1,39 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import os
+import sys
+import subprocess
+import shutil
+from oeqa.selftest.case import OESelftestTestCase
+from yocto_testresults_query import get_sha1, create_workdir
+basepath = os.path.abspath(os.path.dirname(__file__) + '/../../../../../')
+lib_path = basepath + '/scripts/lib'
+sys.path = sys.path + [lib_path]
+
+
+class TestResultsQueryTests(OESelftestTestCase):
+def test_get_sha1(self):
+test_data_get_sha1 = [
+{"input": "yocto-4.0", "expected":
"00cfdde791a0176c134f31e5a09eff725e75b905"},
+{"input": "4.1_M1", "expected":
"95066dde6861ee08fdb505ab3e0422156cc24fae"},
+]
+for data in test_data_get_sha1:
+test_name = data["input"]
+with self.subTest(f"Test SHA1 from {test_name}"):
+self.assertEqual(
+get_sha1(basepath, data["input"]), data["expected"])
+
+def test_create_workdir(self):
+workdir = create_workdir()
+try:
+url = subprocess.check_output(
+["git", "-C", workdir, "remote", "get-url",
"origin"]).strip().decode("utf-8")
+except:
+shutil.rmtree(workdir, ignore_errors=True)
+self.fail(f"Can not execute git commands in {workdir}")
+shutil.rmtree(workdir)
+self.assertEqual(url, "git://git.yoctoproject.org/yocto-testresults")
--
2.39.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177704):
https://lists.openembedded.org/g/openembedded-core/message/177704
Mute This Topic: https://lists.openembedded.org/mt/97209738/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3 4/6] oeqa/selftest/resulttool: add test for metadata filtering on regression
From: Alexis Lothoré
Introduce new tests for the metadata-based filtering added for oeselftest
results
Signed-off-by: Alexis Lothoré
---
.../oeqa/selftest/cases/resulttooltests.py| 137 ++
1 file changed, 137 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/resulttooltests.py
b/meta/lib/oeqa/selftest/cases/resulttooltests.py
index efdfd98af3c..75d406c122d 100644
--- a/meta/lib/oeqa/selftest/cases/resulttooltests.py
+++ b/meta/lib/oeqa/selftest/cases/resulttooltests.py
@@ -98,3 +98,140 @@ class ResultToolTests(OESelftestTestCase):
resultutils.append_resultsdata(results,
ResultToolTests.target_results_data, configmap=resultutils.flatten_map)
self.assertEqual(len(results[''].keys()), 5, msg="Flattened results
not correct %s" % str(results))
+def test_results_without_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+ "TESTSERIES": "series1",
+ "IMAGE_BASENAME": "image",
+ "IMAGE_PKGTYPE": "ipk",
+ "DISTRO": "mydistro",
+ "MACHINE": "qemux86"}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertTrue(regression.can_be_compared(base_configuration,
target_configuration),
+msg="incorrect metadata filtering, tests without
metadata should be compared")
+
+def test_target_result_with_missing_metadata_can_not_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+ "TESTSERIES": "series1",
+ "IMAGE_BASENAME": "image",
+ "IMAGE_PKGTYPE": "ipk",
+ "DISTRO": "mydistro",
+ "MACHINE": "qemux86",
+ "OESELFTEST_METADATA": {"run_all_tests": True,
+ "run_tests": None,
+ "skips": None,
+ "machine": None,
+ "select_tags":
["toolchain-user", "toolchain-system"],
+ "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertFalse(regression.can_be_compared(base_configuration,
target_configuration),
+ msg="incorrect metadata filtering, tests should not
be compared")
+
+def test_results_with_matching_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+ "TESTSERIES": "series1",
+ "IMAGE_BASENAME": "image",
+ "IMAGE_PKGTYPE": "ipk",
+ "DISTRO": "mydistro",
+ "MACHINE": "qemux86",
+ "OESELFTEST_METADATA": {"run_all_tests": True,
+ "run_tests": None,
+ "skips": None,
+ "machine": None,
+ "select_tags":
["toolchain-user", "toolchain-system"],
+ "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86",
+"OESELFTEST_METADATA": {"run_all_tests": True,
+"run_tests": None,
+"skips": None,
+"machine": None,
+"select_tags":
["toolchain-user", "toolchain-system"],
+"exclude_tags": None}}
+self.assertTrue(regression.can_be_compared(base_configuration,
target_configuration),
+
[OE-core] [PATCH v3 5/6] scripts: add new helper for regression report generation
From: Alexis Lothoré
Add yocto-testresults-query script. This is a thin wrapper over resulttool which
is able to translate tags or branch name to specific revisions, and then to work
with those "guessed" revisions with resulttool
Signed-off-by: Alexis Lothoré
---
scripts/yocto_testresults_query.py | 106 +
1 file changed, 106 insertions(+)
create mode 100755 scripts/yocto_testresults_query.py
diff --git a/scripts/yocto_testresults_query.py
b/scripts/yocto_testresults_query.py
new file mode 100755
index 000..fee3855c6d8
--- /dev/null
+++ b/scripts/yocto_testresults_query.py
@@ -0,0 +1,106 @@
+#!/usr/bin/env python3
+
+# Yocto Project test results management tool
+# This script is an thin layer over resulttool to manage tes results and
regression reports.
+# Its main feature is to translate tags or branch names to revisions SHA1, and
then to run resulttool
+# with those computed revisions
+#
+# Copyright (C) 2023 OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import sys
+import os
+import argparse
+import subprocess
+import tempfile
+import lib.scriptutils as scriptutils
+
+script_path = os.path.dirname(os.path.realpath(__file__))
+poky_path = os.path.abspath(os.path.join(script_path, ".."))
+resulttool = os.path.abspath(os.path.join(script_path, "resulttool"))
+logger = scriptutils.logger_create(sys.argv[0])
+testresults_default_url="git://git.yoctoproject.org/yocto-testresults"
+
+def create_workdir():
+workdir = tempfile.mkdtemp(prefix='yocto-testresults-query.')
+logger.info(f"Shallow-cloning testresults in {workdir}")
+subprocess.check_call(["git", "clone", testresults_default_url, workdir,
"--depth", "1"])
+return workdir
+
+def get_sha1(pokydir, revision):
+rev = subprocess.check_output(["git", "rev-list", "-n", "1", revision],
cwd=pokydir).decode('utf-8').strip()
+logger.info(f"SHA-1 revision for {revision} in {pokydir} is {rev}")
+return rev
+
+def fetch_testresults(workdir, sha1):
+logger.info(f"Fetching test results for {sha1} in {workdir}")
+rawtags = subprocess.check_output(["git", "ls-remote", "--refs", "--tags",
"origin", f"*{sha1}*"], cwd=workdir).decode('utf-8').strip()
+if not rawtags:
+raise Exception(f"No reference found for commit {sha1} in {workdir}")
+for rev in [rawtag.split()[1] for rawtag in rawtags.splitlines()]:
+logger.info(f"Fetching matching revisions: {rev}")
+subprocess.check_call(["git", "fetch", "--depth", "1", "origin",
f"{rev}:{rev}"], cwd=workdir)
+
+def compute_regression_report(workdir, baserevision, targetrevision):
+logger.info(f"Running resulttool regression between SHA1 {baserevision}
and {targetrevision}")
+report = subprocess.check_output([resulttool, "regression-git",
"--commit", baserevision, "--commit2", targetrevision, workdir]).decode("utf-8")
+return report
+
+def print_report_with_header(report, baseversion, baserevision, targetversion,
targetrevision):
+print("== Regression report
==")
+print(f'{"=> Target:": <16}{targetversion: <16}({targetrevision})')
+print(f'{"=> Base:": <16}{baseversion: <16}({baserevision})')
+
print("===\n")
+print(report, end='')
+
+def regression(args):
+logger.info(f"Compute regression report between {args.base} and
{args.target}")
+if args.testresultsdir:
+workdir = args.testresultsdir
+else:
+workdir = create_workdir()
+
+try:
+baserevision = get_sha1(poky_path, args.base)
+targetrevision = get_sha1(poky_path, args.target)
+fetch_testresults(workdir, baserevision)
+fetch_testresults(workdir, targetrevision)
+report = compute_regression_report(workdir, baserevision,
targetrevision)
+print_report_with_header(report, args.base, baserevision, args.target,
targetrevision)
+finally:
+if not args.testresultsdir:
+subprocess.check_call(["rm", "-rf", workdir])
+
+def main():
+parser = argparse.ArgumentParser(description="Yocto Project test results
helper")
+subparsers = parser.add_subparsers(
+help="Supported commands for test results helper",
+required=True)
+parser_regression_report = subparsers.add_parser(
+"regression-report",
+help="Generate regression report between two fixed revisions.
Revisions can be branch name or tag")
+parser_regression_report.add_argument(
+'base',
+help="Revision or tag against which to compare results (i.e: the
older)")
+parser_regression_report.add_argument(
+'target',
+help="Revision or tag to compare against the base (i.e: the newer)")
+parser_regression_report.add_argument(
+'-t',
+'--testresultsdir',
+help=f"An existing test results directory. {sys.argv[0]} will
automatically clone it an
[OE-core] [PATCH v3 1/6] scripts/oe-selftest: append metadata to tests results
From: Alexis Lothoré
Many stored results TEST_TYPE are set to "oeselftest", however all those
tests are not run with the same sets of parameters, so those tests results may
not be comparable.
Attach relevant parameters as tests metadata to allow identifying tests
configuration so we can compare tests only when they are run with the same
parameters.
Signed-off-by: Alexis Lothoré
---
meta/lib/oeqa/selftest/context.py | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/context.py
b/meta/lib/oeqa/selftest/context.py
index c7dd03ce378..8cc46283ed0 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -22,6 +22,17 @@ from oeqa.core.exception import OEQAPreRun, OEQATestNotFound
from oeqa.utils.commands import runCmd, get_bb_vars, get_test_layer
+OESELFTEST_METADATA=["run_all_tests", "run_tests", "skips", "machine",
"select_tags", "exclude_tags"]
+
+def get_oeselftest_metadata(args):
+result = {}
+raw_args = vars(args)
+for metadata in OESELFTEST_METADATA:
+if metadata in raw_args:
+result[metadata] = raw_args[metadata]
+
+return result
+
class NonConcurrentTestSuite(unittest.TestSuite):
def __init__(self, suite, processes, setupfunc, removefunc):
super().__init__([suite])
@@ -334,12 +345,14 @@ class
OESelftestTestContextExecutor(OETestContextExecutor):
import platform
from oeqa.utils.metadata import metadata_from_bb
metadata = metadata_from_bb()
+oeselftest_metadata = get_oeselftest_metadata(args)
configuration = {'TEST_TYPE': 'oeselftest',
'STARTTIME': args.test_start_time,
'MACHINE': self.tc.td["MACHINE"],
'HOST_DISTRO': oe.lsb.distro_identifier().replace(' ',
'-'),
'HOST_NAME': metadata['hostname'],
-'LAYERS': metadata['layers']}
+'LAYERS': metadata['layers'],
+'OESELFTEST_METADATA':oeselftest_metadata}
return configuration
def get_result_id(self, configuration):
--
2.39.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177699):
https://lists.openembedded.org/g/openembedded-core/message/177699
Mute This Topic: https://lists.openembedded.org/mt/97209733/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3 3/6] scripts/resulttool/regression: add metadata filtering for oeselftest
From: Alexis Lothoré
When generating regression reports, many false positive can be observed since
some tests results are compared while the corresponding tests sets are not the
same, as it can be seen for example for oeselftest tests (oeselftest is run
multiple time but with different parameters, resulting in different tests sets)
Add a filtering mechanism in resulttool regression module to enable a better
matching between tests. The METADATA_MATCH_TABLE defines that when the TEST_TYPE
is "oeselftest", then resulttool should filter pairs based on
OESELFTEST_METADATA appended to test configuration. If metadata is absent from
test results, in order to keep compatibility with older results, add a
"guessing" mechanism to generate the missing OESELFTEST_METADATA. The guessed
data is tightly coupled to the autobuilder configuration, where all oe-selftest
executions are described
Signed-off-by: Alexis Lothoré
---
scripts/lib/resulttool/regression.py | 162 +++
1 file changed, 162 insertions(+)
diff --git a/scripts/lib/resulttool/regression.py
b/scripts/lib/resulttool/regression.py
index d0b0c318051..1b0c8335a39 100644
--- a/scripts/lib/resulttool/regression.py
+++ b/scripts/lib/resulttool/regression.py
@@ -11,6 +11,164 @@ import resulttool.resultutils as resultutils
from oeqa.utils.git import GitRepo
import oeqa.utils.gitarchive as gitarchive
+METADATA_MATCH_TABLE = {
+"oeselftest": "OESELFTEST_METADATA"
+}
+
+OESELFTEST_METADATA_GUESS_TABLE={
+"trigger-build-posttrigger": {
+"run_all_tests": False,
+"run_tests":["buildoptions.SourceMirroring.test_yocto_source_mirror"],
+"skips": None,
+"machine": None,
+"select_tags":None,
+"exclude_tags": None
+},
+"reproducible": {
+"run_all_tests": False,
+"run_tests":["reproducible"],
+"skips": None,
+"machine": None,
+"select_tags":None,
+"exclude_tags": None
+},
+"arch-qemu-quick": {
+"run_all_tests": True,
+"run_tests":None,
+"skips": None,
+"machine": None,
+"select_tags":["machine"],
+"exclude_tags": None
+},
+"arch-qemu-full-x86-or-x86_64": {
+"run_all_tests": True,
+"run_tests":None,
+"skips": None,
+"machine": None,
+"select_tags":["machine", "toolchain-system"],
+"exclude_tags": None
+},
+"arch-qemu-full-others": {
+"run_all_tests": True,
+"run_tests":None,
+"skips": None,
+"machine": None,
+"select_tags":["machine", "toolchain-user"],
+"exclude_tags": None
+},
+"selftest": {
+"run_all_tests": True,
+"run_tests":None,
+"skips": ["distrodata.Distrodata.test_checkpkg",
"buildoptions.SourceMirroring.test_yocto_source_mirror", "reproducible"],
+"machine": None,
+"select_tags":None,
+"exclude_tags": ["machine", "toolchain-system", "toolchain-user"]
+},
+"bringup": {
+"run_all_tests": True,
+"run_tests":None,
+"skips": ["distrodata.Distrodata.test_checkpkg",
"buildoptions.SourceMirroring.test_yocto_source_mirror"],
+"machine": None,
+"select_tags":None,
+"exclude_tags": ["machine", "toolchain-system", "toolchain-user"]
+}
+}
+
+def test_has_at_least_one_matching_tag(test, tag_list):
+return "oetags" in test and any(oetag in tag_list for oetag in
test["oetags"])
+
+def all_tests_have_at_least_one_matching_tag(results, tag_list):
+return all(test_has_at_least_one_matching_tag(test_result, tag_list) or
test_name.startswith("ptestresult") for (test_name, test_result) in
results.items())
+
+def any_test_have_any_matching_tag(results, tag_list):
+return any(test_has_at_least_one_matching_tag(test, tag_list) for test in
results.values())
+
+def have_skipped_test(result, test_prefix):
+return all( result[test]['status'] == "SKIPPED" for test in result if
test.startswith(test_prefix))
+
+def have_all_tests_skipped(result, test_prefixes_list):
+return all(have_skipped_test(result, test_prefix) for test_prefix in
test_prefixes_list)
+
+def guess_oeselftest_metadata(results):
+"""
+When an oeselftest test result is lacking OESELFTEST_METADATA, we can try
to guess it based on results content.
+Check results for specific values (absence/presence of oetags, number and
name of executed tests...),
+and if it matches one of known configuration from autobuilder
configuration, apply guessed OSELFTEST_METADATA
+to it to allow proper test filtering.
+This guessing process is tightly coupled to config.json in autobuilder. It
should trigger less and less,
+as new tests will have OESELFTEST_METADATA properly appended at test
reporting time
+"""
+
+if len(results) == 1 and
"buildoptions.SourceMirroring.test_yocto_source_mirror" in results:
+return OESELFTEST_METADATA_GUESS_TABLE['trigger-build-po
[OE-core] [PATCH v3 2/6] scripts/resulttool/regression: remove unused import
From: Alexis Lothoré Signed-off-by: Alexis Lothoré --- scripts/lib/resulttool/regression.py | 1 - 1 file changed, 1 deletion(-) diff --git a/scripts/lib/resulttool/regression.py b/scripts/lib/resulttool/regression.py index 9f952951b3f..d0b0c318051 100644 --- a/scripts/lib/resulttool/regression.py +++ b/scripts/lib/resulttool/regression.py @@ -7,7 +7,6 @@ # import resulttool.resultutils as resultutils -import json from oeqa.utils.git import GitRepo import oeqa.utils.gitarchive as gitarchive -- 2.39.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177701): https://lists.openembedded.org/g/openembedded-core/message/177701 Mute This Topic: https://lists.openembedded.org/mt/97209735/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v3 0/6] scripts/resulttool/regression: add metadata filtering
From: Alexis Lothoré Hello, this new series is the follow-up of [1] to make regression reports more meaningful, by reducing noise and false positives. Change since v2: - add filtering on MACHINE field from test results configuration: the MACHINE should always match - add "metadata guessing" mechanism based on Richard proposal ([2]). Up to the point where this series will be merged, tests results stored in git are not enriched with OESELFTEST_METADATA. To allow proper test comparison even with those tests, try to guess what oeselftest command line has been used to run the corresponding tests, and generate OESELFTEST_METADATA accordingly - add new tool to ease test results usage: yocto_testresults_query. For now the tool only manages regression report and is a thin layer between send-qa-email (in yocto-autobuilder-helper) and resulttool. Its main role is to translate regression reports arguments (which are tags or branches) to fixed revisions and to call resulttool accordingly. Most of its code is a transfer from send-qa-email (another series for the autobuilder will follow this one to make send-qa-email use this new helper, but this current series works independently) Example: "yocto_testresults_query.py regression-report 4.2_M1 4.2_M2" will replay the regression report generated when the 4.2_M2 has been generated. Change since v1: - properly configure "From" field in series With those improvements, the regression report is significantly reduced and some useful data start to emerge from the removed noise: - with the MACHINE filtering, the 4.2_M2 report goes from 5.5GB to 627MB - with the OESELFTEST_METADATA enrichment + metadata guessing for older tests, the report goes from 627MB to 1.5MB After manual inspection on some entries, the remaining oeselftest regression raised in the report seems valid. There are still some issues to tackle: - it seems that now one major remaining source of noise is on the "runtime" tests (comparison to tests not run on "target" results) - when a ptest managed by oe-selftest fails, I guess the remaining tests are not run, so when 1 failure is logged, we have many "PASSED->None" transitions in regression report, we should probably silence it. - some transitions appear as regression while those are in fact improvements (e.g: "UNRESOLVED->PASSED") [1] https://lore.kernel.org/openembedded-core/20230214165309.63527-1-alexis.loth...@bootlin.com/ [2] https://lore.kernel.org/openembedded-core/124b9c9667b038b8502f6457ba7d894fc4ef3c58.ca...@linuxfoundation.org/ Alexis Lothoré (6): scripts/oe-selftest: append metadata to tests results scripts/resulttool/regression: remove unused import scripts/resulttool/regression: add metadata filtering for oeselftest oeqa/selftest/resulttool: add test for metadata filtering on regression scripts: add new helper for regression report generation oeqa/selftest: add test for yocto_testresults_query.py .../oeqa/selftest/cases/resulttooltests.py| 137 +++ .../cases/yoctotestresultsquerytests.py | 39 + meta/lib/oeqa/selftest/context.py | 15 +- scripts/lib/resulttool/regression.py | 163 +- scripts/yocto_testresults_query.py| 106 5 files changed, 458 insertions(+), 2 deletions(-) create mode 100644 meta/lib/oeqa/selftest/cases/yoctotestresultsquerytests.py create mode 100755 scripts/yocto_testresults_query.py -- 2.39.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177698): https://lists.openembedded.org/g/openembedded-core/message/177698 Mute This Topic: https://lists.openembedded.org/mt/97209732/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/4] bindgen-cli: Add new recipe
2023. 02. 24. 14:32 keltezéssel, Alex Kiernan írta:
I need to go and ask our resident rustacean, but when we pulled this
crate into a build here, I had to bring in meta-clang in order to
satisfy the runtime deps. May well be that I got something wrong at
the time, or something's changed, but we definitely needed that.
I am also using meta-clang.
Then I will probably have to post it to meta-clang or
make this recipe conditional on the presence of meta-clang.
On Fri, Feb 24, 2023 at 9:39 AM Zoltan Boszormenyi wrote:
The recipe is automatically generated by cargo-bitbake, with the
manual change to add BBCLASSEXTEND = "native" in the include file.
It is used by Mesa 23.0.0 to build Rusticl.
Signed-off-by: Zoltán Böszörményi
---
meta/recipes-devtools/bindgen/bindgen-cli.inc | 1 +
.../bindgen/bindgen-cli_0.64.0.bb | 132 ++
2 files changed, 133 insertions(+)
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli.inc
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli.inc
b/meta/recipes-devtools/bindgen/bindgen-cli.inc
new file mode 100644
index 00..d3267ac413
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli.inc
@@ -0,0 +1 @@
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
new file mode 100644
index 00..da3d692717
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
@@ -0,0 +1,132 @@
+# Auto-Generated by cargo-bitbake 0.3.16-alpha.0
+#
+inherit cargo
+
+# If this is git based prefer versioned ones if they exist
+# DEFAULT_PREFERENCE = "-1"
+
+# how to get bindgen-cli could be as easy as but default to a git checkout:
+# SRC_URI += "crate://crates.io/bindgen-cli/0.64.0"
+SRC_URI +=
"git://github.com/rust-lang/rust-bindgen.git;protocol=https;nobranch=1;branch=v0.64.0"
+SRCREV = "ae6817256ac557981906e93a1f866349db85053e"
+S = "${WORKDIR}/git"
+CARGO_SRC_DIR = "bindgen-cli"
+
+
+# please note if you have entries that do not begin with crate://
+# you must change them to how that package can be fetched
+SRC_URI += " \
+crate://crates.io/aho-corasick/0.5.3 \
+crate://crates.io/aho-corasick/0.7.20 \
+crate://crates.io/ansi_term/0.12.1 \
+crate://crates.io/atty/0.2.14 \
+crate://crates.io/bitflags/1.3.2 \
+crate://crates.io/block/0.1.6 \
+crate://crates.io/cc/1.0.78 \
+crate://crates.io/cexpr/0.6.0 \
+crate://crates.io/cfg-if/1.0.0 \
+crate://crates.io/clang-sys/1.4.0 \
+crate://crates.io/clap/2.34.0 \
+crate://crates.io/clap/4.1.4 \
+crate://crates.io/clap_derive/4.1.0 \
+crate://crates.io/clap_lex/0.3.1 \
+crate://crates.io/diff/0.1.13 \
+crate://crates.io/either/1.8.1 \
+crate://crates.io/env_logger/0.3.5 \
+crate://crates.io/env_logger/0.9.3 \
+crate://crates.io/errno-dragonfly/0.1.2 \
+crate://crates.io/errno/0.2.8 \
+crate://crates.io/fastrand/1.8.0 \
+crate://crates.io/fuchsia-cprng/0.1.1 \
+crate://crates.io/glob/0.3.1 \
+crate://crates.io/heck/0.4.0 \
+crate://crates.io/hermit-abi/0.1.19 \
+crate://crates.io/hermit-abi/0.2.6 \
+crate://crates.io/humantime/2.1.0 \
+crate://crates.io/instant/0.1.12 \
+crate://crates.io/io-lifetimes/1.0.4 \
+crate://crates.io/is-terminal/0.4.2 \
+crate://crates.io/kernel32-sys/0.2.2 \
+crate://crates.io/lazy_static/1.4.0 \
+crate://crates.io/lazycell/1.3.0 \
+crate://crates.io/libc/0.2.139 \
+crate://crates.io/libloading/0.6.7 \
+crate://crates.io/libloading/0.7.4 \
+crate://crates.io/linux-raw-sys/0.1.4 \
+crate://crates.io/log/0.3.9 \
+crate://crates.io/log/0.4.17 \
+crate://crates.io/malloc_buf/0.0.6 \
+crate://crates.io/memchr/0.1.11 \
+crate://crates.io/memchr/2.5.0 \
+crate://crates.io/minimal-lexical/0.2.1 \
+crate://crates.io/nom/7.1.3 \
+crate://crates.io/objc/0.2.7 \
+crate://crates.io/once_cell/1.17.0 \
+crate://crates.io/os_str_bytes/6.4.1 \
+crate://crates.io/peeking_take_while/0.1.2 \
+crate://crates.io/proc-macro-error-attr/1.0.4 \
+crate://crates.io/proc-macro-error/1.0.4 \
+crate://crates.io/proc-macro2/1.0.50 \
+crate://crates.io/quickcheck/0.4.1 \
+crate://crates.io/quote/1.0.23 \
+crate://crates.io/rand/0.3.23 \
+crate://crates.io/rand/0.4.6 \
+crate://crates.io/rand_core/0.3.1 \
+crate://crates.io/rand_core/0.4.2 \
+crate://crates.io/rdrand/0.4.0 \
+crate://crates.io/redox_syscall/0.2.16 \
+crate://crates.io/regex-syntax/0.3.9 \
+crate://crates.io/regex-syntax/0.6.28 \
+crate://crates.io/regex/0.1.80 \
+crate://crates.io/regex/1.7.1 \
+crate://crates.io/remove_dir_all/0.5.3 \
+crate://crates.io/rustc-hash/1.1.0 \
+crate://crates.io/rustix/0.36.7 \
+crate://crates.io/shlex/1.1.0 \
+crate://crates.io/strsim/0.10.0 \
+
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
2023. 02. 24. 12:12 keltezéssel, Alexander Kanavin írta:
On Fri, 24 Feb 2023 at 11:52, Alexander Kanavin via
lists.openembedded.org
wrote:
It also succeeds when there is no inherit rust at all, in the current
master branch recipe.
If inherit rust is conditional, and condition is false, then there is
some other change that triggers the failure, and that change should be
conditional as well.
Or is it the other way around - fails when condition should be true?
How did you write it?
Copied from a different recipe and modified for this use case:
inherit ${@bb.utils.contains('PACKAGECONFIG', 'rusticl', 'rust', '', d)}
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177696):
https://lists.openembedded.org/g/openembedded-core/message/177696
Mute This Topic: https://lists.openembedded.org/mt/97202946/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] icecc.bbclass: enable the network only when ICECC_DISABLED is not set
On Fri, Feb 24, 2023 at 5:27 PM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Fri, 2023-02-17 at 09:58 +, Jose Quaresma wrote:
> > Enabling the network uncondictional is not need for some use cases.
> >
> > Such use case is usefull to reuse the sstate-cache of the build
> > and it requires the icecc inherit in all of the builds.
> > The real control control of the icecc is in the variable ICECC_DISABLED
> > so this patch change the logic to enable the network when the icecc is
> in use.
> >
> > Signed-off-by: Jose Quaresma
> > ---
> > meta/classes/icecc.bbclass | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
> > index 312e0f17b5..159cae20f8 100644
> > --- a/meta/classes/icecc.bbclass
> > +++ b/meta/classes/icecc.bbclass
> > @@ -428,22 +428,18 @@ set_icecc_env() {
> > bbnote "Using icecc tarball: $ICECC_VERSION"
> > }
> >
> > -do_configure[network] = "1"
> > do_configure:prepend() {
> > set_icecc_env
> > }
> >
> > -do_compile[network] = "1"
> > do_compile:prepend() {
> > set_icecc_env
> > }
> >
> > -do_compile_kernelmodules[network] = "1"
> > do_compile_kernelmodules:prepend() {
> > set_icecc_env
> > }
> >
> > -do_install[network] = "1"
> > do_install:prepend() {
> > set_icecc_env
> > }
> > @@ -457,3 +453,9 @@ ICECC_SDK_HOST_TASK:pn-uninative-tarball = ""
> >
> > # Add the toolchain scripts to the SDK
> > TOOLCHAIN_HOST_TASK:append = " ${ICECC_SDK_HOST_TASK}"
> > +
> > +python () {
> > +if d.getVar('ICECC_DISABLED') != "1":
> > +for task in ['do_configure', 'do_compile',
> 'do_compile_kernelmodules', 'do_install']:
> > +d.setVarFlag(task, 'network', '1')
> > +}
>
> I did want to talk a little about the overhead this has. Basically
> you've turned a simple flag setting into some anonymous python so the
> parsing overhead increases with it since there is now code parsing and
> execution to add in.
>
> For a single recipe this isn't so bad but when it is being added to
> every recipe it adds up.
>
> I'm not against the change as such, I just see a continual flood of
> patches adding conditions everywhere for various reasons and each one
> degrades parsing speed a little bit more (as well as complicates the
> test matrix).
>
> I personally don't use this class so I don't have a stake in this one
> but I thought it worth highlighting since I think the overhead of this
> was mentioned elsewhere and I think the overhead isn't widely
> understood.
>
As the network evaluation patch was merged in bitbake:
https://git.openembedded.org/bitbake/commit/?id=3d96c07f9fd4ba1a84826811d14bb4e98ad58846
I can send my inline version:
https://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=1b143f065ab5408f5543951a8c73fa01ce3ee0c1
This works for master, for langdale and kirkstone we would need to backport
this bitbake commit as well as "utils: Allow to_boolean to support int
values", I have all 3 in my branches for kirkstone and langdale and can
send them as soon as there is agreement to do that (e.g. top 5 changes from
https://git.openembedded.org/bitbake-contrib/log/?h=jansa/2.0)
Regards,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177695):
https://lists.openembedded.org/g/openembedded-core/message/177695
Mute This Topic: https://lists.openembedded.org/mt/97025329/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] icecc.bbclass: enable the network only when ICECC_DISABLED is not set
On Fri, 2023-02-17 at 09:58 +, Jose Quaresma wrote:
> Enabling the network uncondictional is not need for some use cases.
>
> Such use case is usefull to reuse the sstate-cache of the build
> and it requires the icecc inherit in all of the builds.
> The real control control of the icecc is in the variable ICECC_DISABLED
> so this patch change the logic to enable the network when the icecc is in use.
>
> Signed-off-by: Jose Quaresma
> ---
> meta/classes/icecc.bbclass | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/meta/classes/icecc.bbclass b/meta/classes/icecc.bbclass
> index 312e0f17b5..159cae20f8 100644
> --- a/meta/classes/icecc.bbclass
> +++ b/meta/classes/icecc.bbclass
> @@ -428,22 +428,18 @@ set_icecc_env() {
> bbnote "Using icecc tarball: $ICECC_VERSION"
> }
>
> -do_configure[network] = "1"
> do_configure:prepend() {
> set_icecc_env
> }
>
> -do_compile[network] = "1"
> do_compile:prepend() {
> set_icecc_env
> }
>
> -do_compile_kernelmodules[network] = "1"
> do_compile_kernelmodules:prepend() {
> set_icecc_env
> }
>
> -do_install[network] = "1"
> do_install:prepend() {
> set_icecc_env
> }
> @@ -457,3 +453,9 @@ ICECC_SDK_HOST_TASK:pn-uninative-tarball = ""
>
> # Add the toolchain scripts to the SDK
> TOOLCHAIN_HOST_TASK:append = " ${ICECC_SDK_HOST_TASK}"
> +
> +python () {
> +if d.getVar('ICECC_DISABLED') != "1":
> +for task in ['do_configure', 'do_compile',
> 'do_compile_kernelmodules', 'do_install']:
> +d.setVarFlag(task, 'network', '1')
> +}
I did want to talk a little about the overhead this has. Basically
you've turned a simple flag setting into some anonymous python so the
parsing overhead increases with it since there is now code parsing and
execution to add in.
For a single recipe this isn't so bad but when it is being added to
every recipe it adds up.
I'm not against the change as such, I just see a continual flood of
patches adding conditions everywhere for various reasons and each one
degrades parsing speed a little bit more (as well as complicates the
test matrix).
I personally don't use this class so I don't have a stake in this one
but I thought it worth highlighting since I think the overhead of this
was mentioned elsewhere and I think the overhead isn't widely
understood.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177694):
https://lists.openembedded.org/g/openembedded-core/message/177694
Mute This Topic: https://lists.openembedded.org/mt/97025329/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC]] cve-update-nvd2-native: new CVE database fetcher
On Fri, Feb 24, 2023 at 5:16 PM Marta Rybczynska wrote: > Add new fetcher for the NVD database using the 2.0 API [1]. > The implementation changes as little as possible, keeping the current > database format (but using a different database file for the transition > period), with a notable exception of not using the META table. > > Minor changes that could be visible: > - the database starts in 1999 instead of 2002 > - the complete fetch is longer (30 minutes typically) > > Tests VERY MUCH welcome, I have found some bugs today still. Docs (with a mandatory note according to the terms of use) will come with v2. For the swap between v1 and v2 I'm not sure what will be the best solution: - a configuration option allows to migrate when the user decides to do so - ... but does not protect the day they disconnect the feed What do you think? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177693): https://lists.openembedded.org/g/openembedded-core/message/177693 Mute This Topic: https://lists.openembedded.org/mt/97209064/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]] cve-update-nvd2-native: new CVE database fetcher
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
Signed-off-by: Marta Rybczynska
---
meta/classes/cve-check.bbclass| 4 +-
.../meta/cve-update-nvd2-native.bb| 300 ++
2 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/meta/cve-update-nvd2-native.bb
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 41fdf8363f..1f16683c32 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -32,7 +32,7 @@ CVE_PRODUCT ??= "${BPN}"
CVE_VERSION ??= "${PV}"
CVE_CHECK_DB_DIR ?= "${DL_DIR}/CVE_CHECK"
-CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_1.1.db"
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
CVE_CHECK_DB_FILE_LOCK ?= "${CVE_CHECK_DB_FILE}.lock"
CVE_CHECK_LOG ?= "${T}/cve.log"
@@ -161,7 +161,7 @@ python do_cve_check () {
}
addtask cve_check before do_build
-do_cve_check[depends] = "cve-update-db-native:do_fetch"
+do_cve_check[depends] = "cve-update-nvd2-native:do_fetch"
do_cve_check[nostamp] = "1"
python cve_check_cleanup () {
diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb
b/meta/recipes-core/meta/cve-update-nvd2-native.bb
new file mode 100644
index 00..5f2e962dc7
--- /dev/null
+++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb
@@ -0,0 +1,300 @@
+SUMMARY = "Updates the NVD CVE database"
+LICENSE = "MIT"
+
+# Important note:
+# This product uses the NVD API but is not endorsed or certified by the NVD.
+
+INHIBIT_DEFAULT_DEPS = "1"
+
+inherit native
+
+deltask do_unpack
+deltask do_patch
+deltask do_configure
+deltask do_compile
+deltask do_install
+deltask do_populate_sysroot
+
+NVDCVE_URL ?= "https://services.nvd.nist.gov/rest/json/cves/2.0";
+
+# CVE database update interval, in seconds. By default: once a day (24*60*60).
+# Use 0 to force the update
+# Use a negative value to skip the update
+CVE_DB_UPDATE_INTERVAL ?= "86400"
+
+# Timeout for blocking socket operations, such as the connection attempt.
+CVE_SOCKET_TIMEOUT ?= "60"
+
+CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_2.db"
+
+CVE_CHECK_DB_FILE ?= "${CVE_CHECK_DB_DIR}/nvdcve_2.db"
+
+python () {
+if not bb.data.inherits_class("cve-check", d):
+raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not
loaded.")
+}
+
+python do_fetch() {
+"""
+Update NVD database with API 2.0
+"""
+import bb.utils
+import bb.progress
+import shutil
+
+bb.utils.export_proxies(d)
+
+db_file = d.getVar("CVE_CHECK_DB_FILE")
+db_dir = os.path.dirname(db_file)
+db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
+
+cleanup_db_download(db_file, db_tmp_file)
+# By default let's update the whole database (since time 0)
+database_time = 0
+
+# The NVD database changes once a day, so no need to update more frequently
+# Allow the user to force-update
+try:
+import time
+update_interval = int(d.getVar("CVE_DB_UPDATE_INTERVAL"))
+if update_interval < 0:
+bb.note("CVE database update skipped")
+return
+if time.time() - os.path.getmtime(db_file) < update_interval:
+bb.note("CVE database recently updated, skipping")
+return
+database_time = os.path.getmtime(db_file)
+
+except OSError:
+pass
+
+bb.utils.mkdirhier(db_dir)
+if os.path.exists(db_file):
+shutil.copy2(db_file, db_tmp_file)
+
+if update_db_file(db_tmp_file, d, database_time) == True:
+# Update downloaded correctly, can swap files
+shutil.move(db_tmp_file, db_file)
+else:
+# Update failed, do not modify the database
+bb.note("CVE database update failed")
+os.remove(db_tmp_file)
+}
+
+do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
+do_fetch[file-checksums] = ""
+do_fetch[vardeps] = ""
+
+def cleanup_db_download(db_file, db_tmp_file):
+"""
+Cleanup the download space from possible failed downloads
+"""
+
+# Clean up the updates done on the main file
+# Remove it only if a journal file exists - it means a complete re-download
+if os.path.exists("{0}-journal".format(db_file)):
+# If a journal is present the last update might have been interrupted.
In that case,
+# just wipe any leftovers and force the DB to be recreated.
+os.remove("{0}-journal".format(db_file))
+
+if os.path.exists(db_file):
+os.remove(db_file)
+
+# Clean-up the temporary file downloads, we can remove both journal
+# and the temporary database
+
Re: [OE-core] [PATCH] meta/recipes-core/images/core-image-minimal: add mtools to IMAGE_INSTALL
"Kareem Zarka" writes:
> The wic.py selftest cases test_skip_kernel_install and
> test_kernel_install for OpenEmbedded were failing on autobuilders due
> to a missing dependency on the mtools package, which provides a set of
> tools for working with MS-DOS file systems, including mcopy.
probably you want to add mtools-native dependency to the test itself
instead of installing into the image.
maybe even simple bitbake("mtools-native") will help?
> To address this issue, we added mtools to the IMAGE_INSTALL variable in
> the core-image-minimal.bb recipe. This ensures that the package is
> included in the core-image-minimal image, which enables the
> test_skip_kernel_install and test_kernel_install selftest cases
> to run correctly on autobuilders.
>
> Signed-off-by: Kareem Zarka
> ---
> meta/recipes-core/images/core-image-minimal.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/images/core-image-minimal.bb
> b/meta/recipes-core/images/core-image-minimal.bb
> index 84343adcd8..5d626898f0 100644
> --- a/meta/recipes-core/images/core-image-minimal.bb
> +++ b/meta/recipes-core/images/core-image-minimal.bb
> @@ -1,6 +1,6 @@
> SUMMARY = "A small image just capable of allowing a device to boot."
>
> -IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
> +IMAGE_INSTALL = "mtools packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
>
> IMAGE_LINGUAS = " "
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177691):
https://lists.openembedded.org/g/openembedded-core/message/177691
Mute This Topic: https://lists.openembedded.org/mt/97206738/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 03/11] build-appliance-image: add support for qemu
On Tue, 2023-02-21 at 15:44 -0500, Trevor Woerner wrote: > Add ext4 explicitly to the list of IMAGE_FSTYPES so the build appliance can be > run with runqemu. > > Signed-off-by: Trevor Woerner > --- > meta/recipes-core/images/build-appliance-image_15.0.0.bb | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/meta/recipes-core/images/build-appliance-image_15.0.0.bb > b/meta/recipes-core/images/build-appliance-image_15.0.0.bb > index 064e7a1ed82f..e28096758b9b 100644 > --- a/meta/recipes-core/images/build-appliance-image_15.0.0.bb > +++ b/meta/recipes-core/images/build-appliance-image_15.0.0.bb > @@ -1,5 +1,5 @@ > SUMMARY = "An image containing the build system itself" > -DESCRIPTION = "An image containing the build system that you can boot and > run using either VirtualBox, VMware Player or VMware Workstation." > +DESCRIPTION = "An image containing the build system that you can boot and > run using any of qemu, VirtualBox, VMware Player or VMware Workstation." > HOMEPAGE = "http://www.yoctoproject.org/documentation/build-appliance"; > > LICENSE = "MIT" > @@ -20,7 +20,7 @@ IMAGE_ROOTFS_EXTRA_SPACE = "41943040" > APPEND += "rootfstype=ext4 quiet" > > DEPENDS = "zip-native python3-pip-native" > -IMAGE_FSTYPES = "wic.vmdk wic.vhd wic.vhdx" > +IMAGE_FSTYPES = "ext4 wic.vmdk wic.vhd wic.vhdx" > > inherit core-image setuptools3 > I've held off this one since whilst it isn't wrong as such, the ext images aren't exactly optimal. I think our hope was that we could use the vmdk or vhdx images with qemu instead and then directly test the ones we publicly share. Do you know if that could work? It may then mean people don't need to handle multiple files too? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177690): https://lists.openembedded.org/g/openembedded-core/message/177690 Mute This Topic: https://lists.openembedded.org/mt/97118441/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] meta/recipes-core/images/core-image-minimal: add mtools to IMAGE_INSTALL
On Fri, Feb 24, 2023 at 9:37 AM Kareem Zarka wrote:
>
> The wic.py selftest cases test_skip_kernel_install and
> test_kernel_install for OpenEmbedded were failing on autobuilders due
> to a missing dependency on the mtools package, which provides a set of
> tools for working with MS-DOS file systems, including mcopy.
> To address this issue, we added mtools to the IMAGE_INSTALL variable in
> the core-image-minimal.bb recipe. This ensures that the package is
> included in the core-image-minimal image, which enables the
> test_skip_kernel_install and test_kernel_install selftest cases
> to run correctly on autobuilders.
>
I can't immediately say where the right place to add this dependency
is, since I don't run the selftest images myself, but I can say that
adding mtools to everyone's minimal image is not something I'd like to
see.
At a minimum, can't the CORE_IMAGE_EXTRA_INSTALL variable be leveraged
for this ? It's there to be used for cases like this.
Bruce
> Signed-off-by: Kareem Zarka
> ---
> meta/recipes-core/images/core-image-minimal.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/images/core-image-minimal.bb
> b/meta/recipes-core/images/core-image-minimal.bb
> index 84343adcd8..5d626898f0 100644
> --- a/meta/recipes-core/images/core-image-minimal.bb
> +++ b/meta/recipes-core/images/core-image-minimal.bb
> @@ -1,6 +1,6 @@
> SUMMARY = "A small image just capable of allowing a device to boot."
>
> -IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
> +IMAGE_INSTALL = "mtools packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
>
> IMAGE_LINGUAS = " "
>
> --
> 2.25.1
>
>
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177689):
https://lists.openembedded.org/g/openembedded-core/message/177689
Mute This Topic: https://lists.openembedded.org/mt/97206738/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] meta/recipes-core/images/core-image-minimal: add mtools to IMAGE_INSTALL
The wic.py selftest cases test_skip_kernel_install and
test_kernel_install for OpenEmbedded were failing on autobuilders due
to a missing dependency on the mtools package, which provides a set of
tools for working with MS-DOS file systems, including mcopy.
To address this issue, we added mtools to the IMAGE_INSTALL variable in
the core-image-minimal.bb recipe. This ensures that the package is
included in the core-image-minimal image, which enables the
test_skip_kernel_install and test_kernel_install selftest cases
to run correctly on autobuilders.
Signed-off-by: Kareem Zarka
---
meta/recipes-core/images/core-image-minimal.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/images/core-image-minimal.bb
b/meta/recipes-core/images/core-image-minimal.bb
index 84343adcd8..5d626898f0 100644
--- a/meta/recipes-core/images/core-image-minimal.bb
+++ b/meta/recipes-core/images/core-image-minimal.bb
@@ -1,6 +1,6 @@
SUMMARY = "A small image just capable of allowing a device to boot."
-IMAGE_INSTALL = "packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
+IMAGE_INSTALL = "mtools packagegroup-core-boot ${CORE_IMAGE_EXTRA_INSTALL}"
IMAGE_LINGUAS = " "
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177688):
https://lists.openembedded.org/g/openembedded-core/message/177688
Mute This Topic: https://lists.openembedded.org/mt/97206738/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] meta/lib/oeqa/selftest/cases/wic: Add tests for configuring kernel image install into boot partition.
- test_skip_kernel_install: This test verifies that the kernel is not
installed in the boot partition when the 'install-kernel-into-boot-dir'
parameter is set to false.
- test_kernel_install: This test verifies that the kernel is installed
in the boot partition when the 'install-kernel-into-boot-dir' parameter
is set to true .
Both tests use a WKS (Kickstart) file to specify the desired
configuration, build a disk image using WIC, and extract the disk image
to a temporary directory to verify the results.
Signed-off-by: Kareem Zarka
---
meta/lib/oeqa/selftest/cases/wic.py | 66 +
1 file changed, 66 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/wic.py
b/meta/lib/oeqa/selftest/cases/wic.py
index ca1abb970a..b46dccc144 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -16,6 +16,7 @@ import hashlib
from glob import glob
from shutil import rmtree, copy
from tempfile import NamedTemporaryFile
+from tempfile import TemporaryDirectory
from oeqa.selftest.case import OESelftestTestCase
from oeqa.core.decorator import OETestTag
@@ -146,6 +147,71 @@ class CLITests(OESelftestTestCase):
self.assertEqual(1, runCmd('wic', ignore_status=True).status)
class Wic(WicTestCase):
+def test_skip_kernel_install(self):
+"""Test the functionality of not installing the kernel in the boot
directory using the wic plugin"""
+# create a temporary file for the WKS content
+with NamedTemporaryFile("w", suffix=".wks") as wks:
+wks.write(
+'part --source bootimg-efi '
+
'--sourceparams="loader=grub-efi,install-kernel-into-boot-dir=false" '
+'--label boot --active\n'
+)
+wks.flush()
+# create a temporary directory to extract the disk image to
+with TemporaryDirectory() as tmpdir:
+img = 'core-image-minimal'
+# build the image using the WKS file
+cmd = "wic create %s -e %s -o %s" % (
+wks.name, img, self.resultdir)
+runCmd(cmd)
+wksname = os.path.splitext(os.path.basename(wks.name))[0]
+out = glob(os.path.join(
+self.resultdir, "%s-*.direct" % wksname))
+self.assertEqual(1, len(out))
+# extract the content of the disk image to the temporary
directory
+cmd = "wic cp %s:1 %s" % (out[0], tmpdir)
+runCmd(cmd)
+# check if the kernel is installed or not
+kimgtype = get_bb_var('KERNEL_IMAGETYPE', img)
+for file in os.listdir(tmpdir):
+if file == kimgtype:
+raise AssertionError(
+"The kernel image '{}' was found in the
partition".format(kimgtype)
+)
+
+def test_kernel_install(self):
+"""Test the installation of the kernel to the boot directory in the
wic plugin"""
+# create a temporary file for the WKS content
+with NamedTemporaryFile("w", suffix=".wks") as wks:
+wks.write(
+'part --source bootimg-efi '
+
'--sourceparams="loader=grub-efi,install-kernel-into-boot-dir=true" '
+'--label boot --active\n'
+)
+wks.flush()
+# create a temporary directory to extract the disk image to
+with TemporaryDirectory() as tmpdir:
+img = 'core-image-minimal'
+# build the image using the WKS file
+cmd = "wic create %s -e %s -o %s" % (wks.name, img,
self.resultdir)
+runCmd(cmd)
+wksname = os.path.splitext(os.path.basename(wks.name))[0]
+out = glob(os.path.join(self.resultdir, "%s-*.direct" %
wksname))
+self.assertEqual(1, len(out))
+# extract the content of the disk image to the temporary
directory
+cmd = "wic cp %s:1 %s" % (out[0], tmpdir)
+runCmd(cmd)
+# check if the kernel is installed or not
+kimgtype = get_bb_var('KERNEL_IMAGETYPE', img)
+found = False
+for file in os.listdir(tmpdir):
+if file == kimgtype:
+found = True
+break
+self.assertTrue(
+found, "The kernel image '{}' was not found in the boot
partition".format(kimgtype)
+)
+
def test_build_image_name(self):
"""Test wic create wictestdisk --image-name=core-image-minimal"""
cmd = "wic create wictestdisk --image-name=core-image-minimal -o %s" %
self.resultdir
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177687):
https://lists.openembedded.org/g/openembedded-core/message/1
[OE-core] [PATCH] wic/plugins/source/bootimg-efi: Configure installation of kernel image into boot partition.
The issue with installing the kernel image to both rootfs
and boot partition is that some systems rely on the kernel image in
rootfs and not in the boot partition.
This leads to duplication of the kernel image, which can cause
unnecessary storage usage.
This patch provides a solution to the problem by adding a new parameter
"install-kernel-into-boot-dir" to the wic kickstart file.
If this parameter is set to 'true', the plugin will install the
kernel image to the boot partition. If the parameter is set to 'false',
the plugin will skip installing the kernel image, avoiding duplication.
Tests for this functionality will be added in the next patch.
Signed-off-by: Kareem Zarka
---
scripts/lib/wic/plugins/source/bootimg-efi.py | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py
b/scripts/lib/wic/plugins/source/bootimg-efi.py
index 4b00913a70..4e99d37f26 100644
--- a/scripts/lib/wic/plugins/source/bootimg-efi.py
+++ b/scripts/lib/wic/plugins/source/bootimg-efi.py
@@ -363,9 +363,10 @@ class BootimgEFIPlugin(SourcePlugin):
objcopy_cmd += " %s %s/EFI/Linux/linux.efi" % (efi_stub,
hdddir)
exec_native_cmd(objcopy_cmd, native_sysroot)
else:
-install_cmd = "install -m 0644 %s/%s %s/%s" % \
-(staging_kernel_dir, kernel, hdddir, kernel)
-exec_cmd(install_cmd)
+if source_params.get('install-kernel-into-boot-dir') != 'false':
+install_cmd = "install -m 0644 %s/%s %s/%s" % \
+(staging_kernel_dir, kernel, hdddir, kernel)
+exec_cmd(install_cmd)
if get_bitbake_var("IMAGE_EFI_BOOT_FILES"):
for src_path, dst_path in cls.install_task:
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177686):
https://lists.openembedded.org/g/openembedded-core/message/177686
Mute This Topic: https://lists.openembedded.org/mt/97206734/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 3/4] mesa: Rename PACKAGECONFIG "opencl" to "clover"
On Fri, 24 Feb 2023 at 13:29, Alexandre Belloni via
lists.openembedded.org
wrote:
> > -PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> > ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> > spirv-tools"
> > +PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> > ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> > spirv-tools"
>
> Are we allowed to do that? It will break anyone using "opencl" in there
> PACKAGECONFIG
It's a part of the implicit agreement that bumping master revision to
a newer master revision can and does break stuff.
In this case 'opencl' is ambigous about what opencl implementation you
get. Curl's 'ssl' option was recently renamed to 'openssl' for the
same reason, and broke builds similarly.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177685):
https://lists.openembedded.org/g/openembedded-core/message/177685
Mute This Topic: https://lists.openembedded.org/mt/97202945/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] systemd: add group sgx to udev package
>From NEWS for v250:
* Device nodes for the Software Guard eXtension enclaves (sgx_vepc) are
now also owned by the system group "sgx".
>From NEWS for v248:
* Intel SGX enclave device nodes (which expose a security feature of
newer Intel CPUs) will now be owned by a new system group "sgx".
Fixes following journal error entry during startup:
/lib/udev/rules.d/50-udev-default.rules:43 Unknown group 'sgx', ignoring
This is seen already on kirkstone.
Signed-off-by: Peter Marko
---
meta-selftest/files/static-group | 1 +
meta/recipes-core/systemd/systemd_252.5.bb | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta-selftest/files/static-group b/meta-selftest/files/static-group
index b13dde3218..cbec6f1377 100644
--- a/meta-selftest/files/static-group
+++ b/meta-selftest/files/static-group
@@ -24,3 +24,4 @@ weston-launch:x:524:
weston:x:525:
wayland:x:526:
render:x:527:
+sgx:x:528:
diff --git a/meta/recipes-core/systemd/systemd_252.5.bb
b/meta/recipes-core/systemd/systemd_252.5.bb
index 64a3efa1d4..f67351d207 100644
--- a/meta/recipes-core/systemd/systemd_252.5.bb
+++ b/meta/recipes-core/systemd/systemd_252.5.bb
@@ -410,7 +410,7 @@ USERADD_PACKAGES = "${PN} ${PN}-extra-utils \
${@bb.utils.contains('PACKAGECONFIG', 'journal-upload',
'${PN}-journal-upload', '', d)} \
"
GROUPADD_PARAM:${PN} = "-r systemd-journal;"
-GROUPADD_PARAM:udev = "-r render"
+GROUPADD_PARAM:udev = "-r render;-r sgx;"
GROUPADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'polkit_hostnamed_fallback', '-r systemd-hostname;', '', d)}"
USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'coredump',
'--system -d / -M --shell /sbin/nologin systemd-coredump;', '', d)}"
USERADD_PARAM:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 'networkd',
'--system -d / -M --shell /sbin/nologin systemd-network;', '', d)}"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177684):
https://lists.openembedded.org/g/openembedded-core/message/177684
Mute This Topic: https://lists.openembedded.org/mt/97205870/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/4] bindgen-cli: Add new recipe
I need to go and ask our resident rustacean, but when we pulled this
crate into a build here, I had to bring in meta-clang in order to
satisfy the runtime deps. May well be that I got something wrong at
the time, or something's changed, but we definitely needed that.
On Fri, Feb 24, 2023 at 9:39 AM Zoltan Boszormenyi wrote:
>
> The recipe is automatically generated by cargo-bitbake, with the
> manual change to add BBCLASSEXTEND = "native" in the include file.
>
> It is used by Mesa 23.0.0 to build Rusticl.
>
> Signed-off-by: Zoltán Böszörményi
> ---
> meta/recipes-devtools/bindgen/bindgen-cli.inc | 1 +
> .../bindgen/bindgen-cli_0.64.0.bb | 132 ++
> 2 files changed, 133 insertions(+)
> create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli.inc
> create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
>
> diff --git a/meta/recipes-devtools/bindgen/bindgen-cli.inc
> b/meta/recipes-devtools/bindgen/bindgen-cli.inc
> new file mode 100644
> index 00..d3267ac413
> --- /dev/null
> +++ b/meta/recipes-devtools/bindgen/bindgen-cli.inc
> @@ -0,0 +1 @@
> +BBCLASSEXTEND = "native"
> diff --git a/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> new file mode 100644
> index 00..da3d692717
> --- /dev/null
> +++ b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> @@ -0,0 +1,132 @@
> +# Auto-Generated by cargo-bitbake 0.3.16-alpha.0
> +#
> +inherit cargo
> +
> +# If this is git based prefer versioned ones if they exist
> +# DEFAULT_PREFERENCE = "-1"
> +
> +# how to get bindgen-cli could be as easy as but default to a git checkout:
> +# SRC_URI += "crate://crates.io/bindgen-cli/0.64.0"
> +SRC_URI +=
> "git://github.com/rust-lang/rust-bindgen.git;protocol=https;nobranch=1;branch=v0.64.0"
> +SRCREV = "ae6817256ac557981906e93a1f866349db85053e"
> +S = "${WORKDIR}/git"
> +CARGO_SRC_DIR = "bindgen-cli"
> +
> +
> +# please note if you have entries that do not begin with crate://
> +# you must change them to how that package can be fetched
> +SRC_URI += " \
> +crate://crates.io/aho-corasick/0.5.3 \
> +crate://crates.io/aho-corasick/0.7.20 \
> +crate://crates.io/ansi_term/0.12.1 \
> +crate://crates.io/atty/0.2.14 \
> +crate://crates.io/bitflags/1.3.2 \
> +crate://crates.io/block/0.1.6 \
> +crate://crates.io/cc/1.0.78 \
> +crate://crates.io/cexpr/0.6.0 \
> +crate://crates.io/cfg-if/1.0.0 \
> +crate://crates.io/clang-sys/1.4.0 \
> +crate://crates.io/clap/2.34.0 \
> +crate://crates.io/clap/4.1.4 \
> +crate://crates.io/clap_derive/4.1.0 \
> +crate://crates.io/clap_lex/0.3.1 \
> +crate://crates.io/diff/0.1.13 \
> +crate://crates.io/either/1.8.1 \
> +crate://crates.io/env_logger/0.3.5 \
> +crate://crates.io/env_logger/0.9.3 \
> +crate://crates.io/errno-dragonfly/0.1.2 \
> +crate://crates.io/errno/0.2.8 \
> +crate://crates.io/fastrand/1.8.0 \
> +crate://crates.io/fuchsia-cprng/0.1.1 \
> +crate://crates.io/glob/0.3.1 \
> +crate://crates.io/heck/0.4.0 \
> +crate://crates.io/hermit-abi/0.1.19 \
> +crate://crates.io/hermit-abi/0.2.6 \
> +crate://crates.io/humantime/2.1.0 \
> +crate://crates.io/instant/0.1.12 \
> +crate://crates.io/io-lifetimes/1.0.4 \
> +crate://crates.io/is-terminal/0.4.2 \
> +crate://crates.io/kernel32-sys/0.2.2 \
> +crate://crates.io/lazy_static/1.4.0 \
> +crate://crates.io/lazycell/1.3.0 \
> +crate://crates.io/libc/0.2.139 \
> +crate://crates.io/libloading/0.6.7 \
> +crate://crates.io/libloading/0.7.4 \
> +crate://crates.io/linux-raw-sys/0.1.4 \
> +crate://crates.io/log/0.3.9 \
> +crate://crates.io/log/0.4.17 \
> +crate://crates.io/malloc_buf/0.0.6 \
> +crate://crates.io/memchr/0.1.11 \
> +crate://crates.io/memchr/2.5.0 \
> +crate://crates.io/minimal-lexical/0.2.1 \
> +crate://crates.io/nom/7.1.3 \
> +crate://crates.io/objc/0.2.7 \
> +crate://crates.io/once_cell/1.17.0 \
> +crate://crates.io/os_str_bytes/6.4.1 \
> +crate://crates.io/peeking_take_while/0.1.2 \
> +crate://crates.io/proc-macro-error-attr/1.0.4 \
> +crate://crates.io/proc-macro-error/1.0.4 \
> +crate://crates.io/proc-macro2/1.0.50 \
> +crate://crates.io/quickcheck/0.4.1 \
> +crate://crates.io/quote/1.0.23 \
> +crate://crates.io/rand/0.3.23 \
> +crate://crates.io/rand/0.4.6 \
> +crate://crates.io/rand_core/0.3.1 \
> +crate://crates.io/rand_core/0.4.2 \
> +crate://crates.io/rdrand/0.4.0 \
> +crate://crates.io/redox_syscall/0.2.16 \
> +crate://crates.io/regex-syntax/0.3.9 \
> +crate://crates.io/regex-syntax/0.6.28 \
> +crate://crates.io/regex/0.1.80 \
> +crate://crates.io/regex/1.7.1 \
> +crate://crates.io/remove_dir_all/0.5.3 \
> +crate://crates.io/rustc-hash/1.1.0 \
> +crate://crates.io/rustix/0.36.7 \
> +crate://crates.io/shlex/1.1.0 \
> +crate://crates.i
Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support
Hi,
Am Freitag, dem 03.02.2023 um 22:07 +0100 schrieb Alexandre Belloni:
> This breaks oe-selftest:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/4760/steps/15/logs/stdio
thanks for having this thrown on the autobuilder!
> 2023-02-03 17:55:08,025 - oe-selftest - INFO -
> fitimage.FitImageTests.test_sign_cascaded_uboot_fit_image
> (subunit.RemotedTestCase)
> 2023-02-03 17:55:08,026 - oe-selftest - INFO - ... FAIL
> Stderr:
> 2023-02-03 14:32:52,619 - oe-selftest - INFO - Adding: "include selftest.inc"
> in
> /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-35279/conf/local.conf
> 2023-02-03 14:32:52,620 - oe-selftest - INFO - Adding: "include bblayers.inc"
> in bblayers.conf
> 2023-02-03 17:55:08,026 - oe-selftest - INFO - 13: 4/22 399/509 (54.05s) (0
> failed)
> (fitimage.FitImageTests.test_sign_cascaded_uboot_fit_image)
> 2023-02-03 17:55:08,026 - oe-selftest - INFO -
> testtools.testresult.real._StringException:
> Traceback (most recent call last):
> File "/home/pokybuild/yocto-worker/oe-selftest-
> centos/build/meta/lib/oeqa/selftest/cases/fitimage.py", line 612, in
> test_sign_cascaded_uboot_fit_image
> bitbake("virtual/bootloader")
> File
> "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/utils/commands.py",
> line 236, in bitbake
> return runCmd(cmd, ignore_status, timeout, output_log=output_log,
> **options)
> File
> "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/utils/commands.py",
> line 214, in runCmd
> raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s"
> % (command,
> result.status, exc_output))
> AssertionError: Command 'bitbake virtual/bootloader' returned non-zero exit
> status 1:
>
> ERROR: barebox-2023.01.0-r0 do_configure: No defconfig given. Either add file
> 'file://defconfig' to SRC_URI or set BAREBOX_CONFIG
This fails since BAREBOX_CONFIG is not set to any default, yet.
This is similar to what the uboot recipes expect to be set from the MACHINE as
UBOOT_MACHINE.
To limit the impact of barebox to oe-core, I would set BAREBOX_CONFIG overrides
for the default
machines contained in oe-core in the barebox recipe. Then they don't have to be
set in the
machine.conf files.
> ERROR: barebox-2023.01.0-r0 do_configure:
> ExecutionError('/home/pokybuild/yocto-worker/oe-
> selftest-centos/build/build-st-35279/tmp/work/qemuarm-poky-linux-gnueabi/barebox/2023.01.0-
> r0/temp/run.do_configure.3098535', 1, None, None)
> ERROR: Logfile of failure stored in:
> /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-
> st-35279/tmp/work/qemuarm-poky-linux-gnueabi/barebox/2023.01.0-r0/temp/log.do_configure.3098535
> NOTE: recipe barebox-2023.01.0-r0: task do_configure: Failed
> ERROR: Task
> (/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/recipes-
> bsp/barebox/barebox_2023.01.0.bb:do_configure) failed with exit code '1'
>
> And as already reported by Richard:
>
> AssertionError:
> The following recipes do not have a maintainer assigned to them. Please add
> an entry to
> meta/conf/distro/include/maintainers.inc file.
> barebox-tools
> (/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/recipes-
> bsp/barebox/barebox-tools_2023.01.0.bb)
> barebox (/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/recipes-
> bsp/barebox/barebox_2023.01.0.bb)
Yes. At least for now, that's the easier part and was already fixed in my local
patch set by
assigning me. ;)
Regards, Enrico
> On 03/02/2023 14:50:10+0100, Marco Felsch wrote:
> > This adds the support for the barebox bootloader to oe-core. The recipe
> > is based on the recipe found in meta-ptx [1] with a few minor adaptions.
> >
> > This basic support includes the bootloader and the target tools to
> > interact with the bootloader. The host tools support is not part of
> > this commit. This will be added later on as separate recipe.
> >
> > [1] https://github.com/pengutronix/meta-ptx/tree/master/recipes-bsp/barebox
> >
> > Signed-off-by: Marco Felsch
> > ---
> > meta/conf/documentation.conf | 7 +
> > meta/recipes-bsp/barebox/barebox.inc | 123 ++
> > meta/recipes-bsp/barebox/barebox_2023.01.0.bb | 5 +
> > ...IMAGE_COMPRESSION-per-default-to-lz4.patch | 40 ++
> > 4 files changed, 175 insertions(+)
> > create mode 100644 meta/recipes-bsp/barebox/barebox.inc
> > create mode 100644 meta/recipes-bsp/barebox/barebox_2023.01.0.bb
> > create mode 100644
> > meta/recipes-bsp/barebox/files/0001-pbl-set-IMAGE_COMPRESSION-per-default-
> > to-lz4.patch
> >
> > diff --git a/meta/conf/documentation.conf b/meta/conf/documentation.conf
> > index a27d7a53c3..99e8f8e730 100644
> > --- a/meta/conf/documentation.conf
> > +++ b/meta/conf/documentation.conf
> > @@ -77,6 +77,13 @@ AUTOREV[doc] = "When SRCREV is set to the value of this
> > variable, it
> > specifies t
> >
> > B[doc] = "The Build Directory. The OpenEmbedded build system p
Re: [OE-core] [PATCH 3/4] mesa: Rename PACKAGECONFIG "opencl" to "clover"
On 24/02/2023 10:38:49+0100, Zoltan Boszormenyi wrote:
> There is another OpenCL frontend called "rusticl" now.
>
> Signed-off-by: Zoltán Böszörményi
> ---
> meta/recipes-graphics/mesa/mesa.inc | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/meta/recipes-graphics/mesa/mesa.inc
> b/meta/recipes-graphics/mesa/mesa.inc
> index 70f9b6fc17..9ec10c49ca 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -115,9 +115,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled,
> -Dgles1=disabled -Dgles2
> # "egl" requires "opengl"
> PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
>
> -# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
> +# "clover" requires libclc from meta-clang and spirv-tools from OE-Core
> OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno',
> '-Dopencl-native=true', '', d)}"
> -PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> spirv-tools"
> +PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
> ${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
> spirv-tools"
Are we allowed to do that? It will break anyone using "opencl" in there
PACKAGECONFIG
>
> PACKAGECONFIG[broadcom] = ""
> PACKAGECONFIG[etnaviv] = ""
> @@ -196,7 +196,7 @@ DEV_PKG_DEPENDENCY = ""
> # development package of libgles3.
> RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
>
> -RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
> 'libclc spirv-tools', '', d)}"
> +RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover',
> 'libclc spirv-tools', '', d)}"
>
> PACKAGES =+ "libegl-mesa libegl-mesa-dev \
> libosmesa libosmesa-dev \
> @@ -242,7 +242,7 @@ python __anonymous() {
>("gles", "libgles1", "libglesv1-cm1"),
>("gles", "libgles2", "libglesv2-2"),
>("gles", "libgles3",),
> - ("opencl", "libopencl",)):
> + ("clover", "libopencl",)):
> if not p[0] in pkgconfig:
> continue
> mlprefix = d.getVar("MLPREFIX")
> --
> 2.39.2
>
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177681):
https://lists.openembedded.org/g/openembedded-core/message/177681
Mute This Topic: https://lists.openembedded.org/mt/97202945/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
On Fri, 24 Feb 2023 at 11:52, Alexander Kanavin via lists.openembedded.org wrote: > It also succeeds when there is no inherit rust at all, in the current > master branch recipe. > > If inherit rust is conditional, and condition is false, then there is > some other change that triggers the failure, and that change should be > conditional as well. Or is it the other way around - fails when condition should be true? How did you write it? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177680): https://lists.openembedded.org/g/openembedded-core/message/177680 Mute This Topic: https://lists.openembedded.org/mt/97202946/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [RFC PATCH 0/2] Handling of ${PN}-dev RRECOMMENDS non-existent ${PN}
Hi,
On 2/24/23 04:05, ChenQi wrote:
> I have some concerns about this series of patches.
> 1. The QA check is not checking for RRECOMMENDS on non-existentent packages,
> it's only checking for non-existent in-recipe packages. That is, it's not
> checking packages from other recipes.
Yes, you're right. Our (non-written) reasoning was :
* a out-of-recipe RRECOMMENDS link to a package that won't be built seems
totally legitimate (AFAIK, if A RRECOMMENDS B, A has no way to know if B will
be built)
* but, for a in-recipe RRECOMMENDS. It shows that the recipe is not internally
consistent. So the QA_WARN is legitimate, I guess?
> 2. If patch 2 is sent, then the patch for 'a general way to fix the case'
> should also be sent, otherwise, we'll be in a situation that a bunch of
> warnings are there but there's no suggested fix and current workarounds have
> been explicitly removed.
Yes, I guess some context was missing here as well : these 2 patches are the
first step to fix Yocto#6839 & Yocto#8222.
The way to properly fix these is not obvious right now and to help Richard, we
pushed these to make the problem appear more clearly.
These are not ready to be merge as-is (hence the RFC tag on the cover letter...
which, I now notice, lacks in the patches... sorry)
> 3. There are some typos. s/existant/existent.
Will fix those. Thanks!
> Looking at the original two issues, Yocto#6839 & Yocto#8222, I agree that the
> appropriate approach is to first create a QA check. However, I think this QA
> check should either:
> 1. only check for non-existent main package for the dev package (as the
> default value of -dev package is the main package)
> or
> 2. thoroughly check for non-existent packages across recipes (maybe by using
> pkgdata)
This is exactly the kind of discussion we need to have. Thanks!
I'm leaning towards "1." but still, I think, it should be generalized to any
in-recipe RRECOMMENDS links.
Regards,
> Regards,
> Qi
>
>
>
> On 2/24/23 07:29, Yoann Congal via lists.openembedded.org wrote:
>> This series is a work in progress on 2 related bugs :
>> * [YOCTO #6839] Handle dev package with no main package more gracefully
>> * [YOCTO #8222] Elide dependency from -dev package on main package if
>> there are no shared libraries in it
>>
>> An empty package ${PN} is not generated by default. This has been a
>> problem most frequently seen because ${PN}-dev depends on it. This case
>> has been handled by :
>> * Using ALLOW_EMPTY:${PN} = "1" : forcing ${PN} to be created even
>> empty.
>> * DEV_PKG_DEPENDENCY = "" : Implicitly removing the dependency on ${PN}
>> * And finally and globally making the ${PN}-dev -> ${PN} relation a
>> RRECOMMENDS.
>>
>> 2 patches :
>> * insane: Add QA check for RRECOMMENDS on non-existent packages
>> * meta/recipes: Remove empty ${PN}/DEV_PKG_DEPENDENCY workaround
>>
>> First one create a QA check to try to detect the problematic situation.
>> The second removes workarounds setup to hide to problematic case.
>>
>> Together they will prominently show where the problematic cases are.
>> Next step will be to find a generic way to fix the case.
>>
>> Fawzi KHABER (2):
>> insane: Add QA check for RRECOMMENDS on non-existent packages
>> meta/recipes: Remove empty ${PN}/DEV_PKG_DEPENDENCY workarounds
>>
>> meta/classes-global/insane.bbclass | 11 +++
>> meta/recipes-connectivity/bind/bind_9.18.11.bb | 1 -
>> meta/recipes-core/musl/bsd-headers.bb | 1 -
>> meta/recipes-core/musl/libssp-nonshared.bb | 1 -
>> meta/recipes-core/newlib/newlib_git.bb | 3 ---
>> meta/recipes-devtools/gcc/libgcc-common.inc | 4
>> meta/recipes-devtools/python/python3_3.11.2.bb | 1 -
>> meta/recipes-graphics/mesa/libglu_9.0.2.bb | 3 ---
>> meta/recipes-graphics/mesa/mesa.inc | 3 ---
>> .../recipes-graphics/xorg-lib/libpthread-stubs_0.4.bb | 1 -
>> meta/recipes-graphics/xorg-lib/xtrans_1.4.0.bb | 1 -
>> meta/recipes-graphics/xorg-proto/xcb-proto_1.15.2.bb | 1 -
>> meta/recipes-graphics/xorg-proto/xorgproto_2022.2.bb | 3 +--
>> meta/recipes-graphics/xorg-util/util-macros_1.20.0.bb | 3 +--
>> .../linux-libc-headers/linux-libc-headers.inc | 1 -
>> .../make-mod-scripts/make-mod-scripts_1.0.bb | 1 -
>> .../argp-standalone/argp-standalone_1.4.1.bb | 1 -
>> 17 files changed, 13 insertions(+), 27 deletions(-)
>>
>>
>>
>>
>
--
Yoann Congal
Smile ECS - Tech Expert
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177679):
https://lists.openembedded.org/g/openembedded-core/message/177679
Mute This Topic: https://lists.openembedded.org/mt/97195657/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
On Fri, 24 Feb 2023 at 11:34, Zoltan Boszormenyi wrote: > Problem is, now the configure stage fails with: > > | ../mesa-23.0.0/meson.build:964: WARNING: add_languages is missing native:, > assuming > languages are wanted for both host and build. > | Compiler for language rust for the build machine not found. > | > | ../mesa-23.0.0/meson.build:964:2: ERROR: Rust compiler rustc -C > linker=x86_64-oe-linux-gcc -C link-arg=-m64 -C link-arg=-march=nehalem -C > link-arg=-mtune=generic -C link-arg=-mfpmath=sse -C link-arg=-msse4.2 -C > link-arg=-fstack-protector-strong -C link-arg=-O2 -C > link-arg=-D_FORTIFY_SOURCE=2 -C > link-arg=-Wformat -C link-arg=-Wformat-security -C > link-arg=-Werror=format-security -C > link-arg=--sysroot=/data2/dtd-yocto-4.0/tmp-sicom-glibc/work/corei7-64-oe-linux/mesa/2_23.0.0-r0/recipe-sysroot > can not compile programs. > | > | error: Error loading target specification: Could not find specification for > target > "x86_64-linux". Run `rustc --print target-list` for a list of built-in targets > > I also tried it with moving the conditionally set rust > between or before the already inherited classes. > > It succeeds when inherit rust is not conditional. It also succeeds when there is no inherit rust at all, in the current master branch recipe. If inherit rust is conditional, and condition is false, then there is some other change that triggers the failure, and that change should be conditional as well. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177678): https://lists.openembedded.org/g/openembedded-core/message/177678 Mute This Topic: https://lists.openembedded.org/mt/97202946/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] oeqa/selftest/prservice: Improve debug output for failure
We keep seeing this failure on the autobuilder but the output amounts
to "False is not True". Improve the debug message on the chance it may
make the issue clearer.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/prservice.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/prservice.py
b/meta/lib/oeqa/selftest/cases/prservice.py
index cb95503c2cb..6e3d23b7b3c 100644
--- a/meta/lib/oeqa/selftest/cases/prservice.py
+++ b/meta/lib/oeqa/selftest/cases/prservice.py
@@ -77,7 +77,7 @@ class BitbakePrTests(OESelftestTestCase):
exported_db_path = os.path.join(self.builddir, 'export.inc')
export_result = runCmd("bitbake-prserv-tool export %s" %
exported_db_path, ignore_status=True)
self.assertEqual(export_result.status, 0, msg="PR Service database
export failed: %s" % export_result.output)
-self.assertTrue(os.path.exists(exported_db_path))
+self.assertTrue(os.path.exists(exported_db_path), msg="%s didn't
exist, tool output %s" % (exported_db_path, export_result.output)))
if replace_current_db:
current_db_path = os.path.join(get_bb_var('PERSISTENT_DIR'),
'prserv.sqlite3')
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177677):
https://lists.openembedded.org/g/openembedded-core/message/177677
Mute This Topic: https://lists.openembedded.org/mt/97203502/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/4] bindgen-cli: Add new recipe
2023. 02. 24. 11:13 keltezéssel, Alexander Kanavin írta: On Fri, 24 Feb 2023 at 10:59, Böszörményi Zoltán wrote: 2023. 02. 24. 10:44 keltezéssel, Alexander Kanavin írta: As this is needed only for rusticl, and that is switched off by default, there is no need for the recipe to be in core. I'd say meta-oe is a better location. Why? Rust itself is in OE-core for a while now and bindgen is practically an integral part of Rust if it's to be interfaced with C/C++. That is not enough for inclusion into core. It either needs to be useful in a typical, common embedded use case, or be a hard depenency of such an item. So it has only one consumer, rusticl, and even that is not enabled by default or broadly useful. Understood. I will move the bindgen recipe to meta-oe. Keep in mind that maintainer capacity is not infinite, we're all volunteers except RP. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177676): https://lists.openembedded.org/g/openembedded-core/message/177676 Mute This Topic: https://lists.openembedded.org/mt/97202942/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
2023. 02. 24. 11:05 keltezéssel, Zoltan Boszormenyi via lists.openembedded.org írta: 2023. 02. 24. 10:45 keltezéssel, Ross Burton írta: On 24 Feb 2023, at 09:38, Zoltan Boszormenyi via lists.openembedded.org wrote: -inherit meson pkgconfig python3native gettext features_check +inherit meson pkgconfig python3native gettext features_check rust This forces a dependency on rust-native, even if rusticl is disabled. Is it actually needed? If so, make the inherit conditional. I will do that, thanks. Problem is, now the configure stage fails with: | ../mesa-23.0.0/meson.build:964: WARNING: add_languages is missing native:, assuming languages are wanted for both host and build. | Compiler for language rust for the build machine not found. | | ../mesa-23.0.0/meson.build:964:2: ERROR: Rust compiler rustc -C linker=x86_64-oe-linux-gcc -C link-arg=-m64 -C link-arg=-march=nehalem -C link-arg=-mtune=generic -C link-arg=-mfpmath=sse -C link-arg=-msse4.2 -C link-arg=-fstack-protector-strong -C link-arg=-O2 -C link-arg=-D_FORTIFY_SOURCE=2 -C link-arg=-Wformat -C link-arg=-Wformat-security -C link-arg=-Werror=format-security -C link-arg=--sysroot=/data2/dtd-yocto-4.0/tmp-sicom-glibc/work/corei7-64-oe-linux/mesa/2_23.0.0-r0/recipe-sysroot can not compile programs. | | error: Error loading target specification: Could not find specification for target "x86_64-linux". Run `rustc --print target-list` for a list of built-in targets I also tried it with moving the conditionally set rust between or before the already inherited classes. It succeeds when inherit rust is not conditional. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177675): https://lists.openembedded.org/g/openembedded-core/message/177675 Mute This Topic: https://lists.openembedded.org/mt/97202946/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 2/4] vala: Fix install conflict when enable multilib.
On Fri, 2023-02-24 at 10:44 +0800, wangmy wrote:
> From: Wang Mingyu
>
> Error: Transaction test error:
> file /usr/bin/vala-gen-introspect-0.56 conflicts between attempted installs
> of lib32-vala-0.56.3-r0.armv7ahf_neon and vala-0.56.3-r0.aarch64
> file /usr/bin/vapigen-wrapper conflicts between attempted installs of
> lib32-vala-0.56.3-r0.armv7ahf_neon and vala-0.56.3-r0.aarch64
>
> Signed-off-by: Wang Mingyu
> ---
> meta/recipes-devtools/vala/vala.inc | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/meta/recipes-devtools/vala/vala.inc
> b/meta/recipes-devtools/vala/vala.inc
> index d3daee37dc..90689662cb 100644
> --- a/meta/recipes-devtools/vala/vala.inc
> +++ b/meta/recipes-devtools/vala/vala.inc
> @@ -66,3 +66,6 @@ PACKAGE_PREPROCESS_FUNCS += "vala_package_preprocess"
> vala_package_preprocess () {
> sed -i -e 's:${RECIPE_SYSROOT}::g;'
> ${PKGD}${bindir_crossscripts}/vapigen-wrapper
> }
> +
> +inherit multilib_script
> +MULTILIB_SCRIPTS = "${PN}:${bindir}/crossscripts/vapigen-wrapper
> ${PN}:${bindir}/vala-gen-introspect-0.56"
This looks a bit odd since crossscripts wouldn't be installed on the
target?
Also, when posting these kinds of changes, can you show a diff of the
two files please?
Sometimes we can tweak the files so that they can become the same but
it is hard to know without context.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177674):
https://lists.openembedded.org/g/openembedded-core/message/177674
Mute This Topic: https://lists.openembedded.org/mt/97198850/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/4] bindgen-cli: Add new recipe
On Fri, 24 Feb 2023 at 10:59, Böszörményi Zoltán wrote: > > 2023. 02. 24. 10:44 keltezéssel, Alexander Kanavin írta: > > As this is needed only for rusticl, and that is switched off by > > default, there is no need for the recipe to be in core. I'd say > > meta-oe is a better location. > > Why? > > Rust itself is in OE-core for a while now and > bindgen is practically an integral part of Rust > if it's to be interfaced with C/C++. That is not enough for inclusion into core. It either needs to be useful in a typical, common embedded use case, or be a hard depenency of such an item. So it has only one consumer, rusticl, and even that is not enabled by default or broadly useful. Keep in mind that maintainer capacity is not infinite, we're all volunteers except RP. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177673): https://lists.openembedded.org/g/openembedded-core/message/177673 Mute This Topic: https://lists.openembedded.org/mt/97202942/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
2023. 02. 24. 10:45 keltezéssel, Ross Burton írta: On 24 Feb 2023, at 09:38, Zoltan Boszormenyi via lists.openembedded.org wrote: -inherit meson pkgconfig python3native gettext features_check +inherit meson pkgconfig python3native gettext features_check rust This forces a dependency on rust-native, even if rusticl is disabled. Is it actually needed? If so, make the inherit conditional. I will do that, thanks. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177672): https://lists.openembedded.org/g/openembedded-core/message/177672 Mute This Topic: https://lists.openembedded.org/mt/97202946/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/4] bindgen-cli: Add new recipe
2023. 02. 24. 10:44 keltezéssel, Alexander Kanavin írta:
As this is needed only for rusticl, and that is switched off by
default, there is no need for the recipe to be in core. I'd say
meta-oe is a better location.
Why?
Rust itself is in OE-core for a while now and
bindgen is practically an integral part of Rust
if it's to be interfaced with C/C++.
Also, the list of crates should be generated by
cargo-update-recipe-crates class, not by cargo bitbake.
I will look into it, thanks.
Alex
On Fri, 24 Feb 2023 at 10:39, Zoltan Boszormenyi wrote:
The recipe is automatically generated by cargo-bitbake, with the
manual change to add BBCLASSEXTEND = "native" in the include file.
It is used by Mesa 23.0.0 to build Rusticl.
Signed-off-by: Zoltán Böszörményi
---
meta/recipes-devtools/bindgen/bindgen-cli.inc | 1 +
.../bindgen/bindgen-cli_0.64.0.bb | 132 ++
2 files changed, 133 insertions(+)
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli.inc
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli.inc
b/meta/recipes-devtools/bindgen/bindgen-cli.inc
new file mode 100644
index 00..d3267ac413
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli.inc
@@ -0,0 +1 @@
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
new file mode 100644
index 00..da3d692717
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
@@ -0,0 +1,132 @@
+# Auto-Generated by cargo-bitbake 0.3.16-alpha.0
+#
+inherit cargo
+
+# If this is git based prefer versioned ones if they exist
+# DEFAULT_PREFERENCE = "-1"
+
+# how to get bindgen-cli could be as easy as but default to a git checkout:
+# SRC_URI += "crate://crates.io/bindgen-cli/0.64.0"
+SRC_URI +=
"git://github.com/rust-lang/rust-bindgen.git;protocol=https;nobranch=1;branch=v0.64.0"
+SRCREV = "ae6817256ac557981906e93a1f866349db85053e"
+S = "${WORKDIR}/git"
+CARGO_SRC_DIR = "bindgen-cli"
+
+
+# please note if you have entries that do not begin with crate://
+# you must change them to how that package can be fetched
+SRC_URI += " \
+crate://crates.io/aho-corasick/0.5.3 \
+crate://crates.io/aho-corasick/0.7.20 \
+crate://crates.io/ansi_term/0.12.1 \
+crate://crates.io/atty/0.2.14 \
+crate://crates.io/bitflags/1.3.2 \
+crate://crates.io/block/0.1.6 \
+crate://crates.io/cc/1.0.78 \
+crate://crates.io/cexpr/0.6.0 \
+crate://crates.io/cfg-if/1.0.0 \
+crate://crates.io/clang-sys/1.4.0 \
+crate://crates.io/clap/2.34.0 \
+crate://crates.io/clap/4.1.4 \
+crate://crates.io/clap_derive/4.1.0 \
+crate://crates.io/clap_lex/0.3.1 \
+crate://crates.io/diff/0.1.13 \
+crate://crates.io/either/1.8.1 \
+crate://crates.io/env_logger/0.3.5 \
+crate://crates.io/env_logger/0.9.3 \
+crate://crates.io/errno-dragonfly/0.1.2 \
+crate://crates.io/errno/0.2.8 \
+crate://crates.io/fastrand/1.8.0 \
+crate://crates.io/fuchsia-cprng/0.1.1 \
+crate://crates.io/glob/0.3.1 \
+crate://crates.io/heck/0.4.0 \
+crate://crates.io/hermit-abi/0.1.19 \
+crate://crates.io/hermit-abi/0.2.6 \
+crate://crates.io/humantime/2.1.0 \
+crate://crates.io/instant/0.1.12 \
+crate://crates.io/io-lifetimes/1.0.4 \
+crate://crates.io/is-terminal/0.4.2 \
+crate://crates.io/kernel32-sys/0.2.2 \
+crate://crates.io/lazy_static/1.4.0 \
+crate://crates.io/lazycell/1.3.0 \
+crate://crates.io/libc/0.2.139 \
+crate://crates.io/libloading/0.6.7 \
+crate://crates.io/libloading/0.7.4 \
+crate://crates.io/linux-raw-sys/0.1.4 \
+crate://crates.io/log/0.3.9 \
+crate://crates.io/log/0.4.17 \
+crate://crates.io/malloc_buf/0.0.6 \
+crate://crates.io/memchr/0.1.11 \
+crate://crates.io/memchr/2.5.0 \
+crate://crates.io/minimal-lexical/0.2.1 \
+crate://crates.io/nom/7.1.3 \
+crate://crates.io/objc/0.2.7 \
+crate://crates.io/once_cell/1.17.0 \
+crate://crates.io/os_str_bytes/6.4.1 \
+crate://crates.io/peeking_take_while/0.1.2 \
+crate://crates.io/proc-macro-error-attr/1.0.4 \
+crate://crates.io/proc-macro-error/1.0.4 \
+crate://crates.io/proc-macro2/1.0.50 \
+crate://crates.io/quickcheck/0.4.1 \
+crate://crates.io/quote/1.0.23 \
+crate://crates.io/rand/0.3.23 \
+crate://crates.io/rand/0.4.6 \
+crate://crates.io/rand_core/0.3.1 \
+crate://crates.io/rand_core/0.4.2 \
+crate://crates.io/rdrand/0.4.0 \
+crate://crates.io/redox_syscall/0.2.16 \
+crate://crates.io/regex-syntax/0.3.9 \
+crate://crates.io/regex-syntax/0.6.28 \
+crate://crates.io/regex/0.1.80 \
+crate://crates.io/regex/1.7.1 \
+crate://crates.io/remove_dir_all/0.5.3 \
+crate://crates.io/rustc-hash/1.1.0 \
+crate://crates.io/rustix/0.36.7 \
+crate://crates.io/shlex/1.1.0 \
+crate://
Re: [OE-core] [PATCH 4/4] mesa: Add PACKAGECONFIG "rusticl"
> On 24 Feb 2023, at 09:38, Zoltan Boszormenyi via lists.openembedded.org > wrote: > -inherit meson pkgconfig python3native gettext features_check > +inherit meson pkgconfig python3native gettext features_check rust This forces a dependency on rust-native, even if rusticl is disabled. Is it actually needed? If so, make the inherit conditional. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#177670): https://lists.openembedded.org/g/openembedded-core/message/177670 Mute This Topic: https://lists.openembedded.org/mt/97202946/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/4] bindgen-cli: Add new recipe
As this is needed only for rusticl, and that is switched off by
default, there is no need for the recipe to be in core. I'd say
meta-oe is a better location.
Also, the list of crates should be generated by
cargo-update-recipe-crates class, not by cargo bitbake.
Alex
On Fri, 24 Feb 2023 at 10:39, Zoltan Boszormenyi wrote:
>
> The recipe is automatically generated by cargo-bitbake, with the
> manual change to add BBCLASSEXTEND = "native" in the include file.
>
> It is used by Mesa 23.0.0 to build Rusticl.
>
> Signed-off-by: Zoltán Böszörményi
> ---
> meta/recipes-devtools/bindgen/bindgen-cli.inc | 1 +
> .../bindgen/bindgen-cli_0.64.0.bb | 132 ++
> 2 files changed, 133 insertions(+)
> create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli.inc
> create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
>
> diff --git a/meta/recipes-devtools/bindgen/bindgen-cli.inc
> b/meta/recipes-devtools/bindgen/bindgen-cli.inc
> new file mode 100644
> index 00..d3267ac413
> --- /dev/null
> +++ b/meta/recipes-devtools/bindgen/bindgen-cli.inc
> @@ -0,0 +1 @@
> +BBCLASSEXTEND = "native"
> diff --git a/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> new file mode 100644
> index 00..da3d692717
> --- /dev/null
> +++ b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
> @@ -0,0 +1,132 @@
> +# Auto-Generated by cargo-bitbake 0.3.16-alpha.0
> +#
> +inherit cargo
> +
> +# If this is git based prefer versioned ones if they exist
> +# DEFAULT_PREFERENCE = "-1"
> +
> +# how to get bindgen-cli could be as easy as but default to a git checkout:
> +# SRC_URI += "crate://crates.io/bindgen-cli/0.64.0"
> +SRC_URI +=
> "git://github.com/rust-lang/rust-bindgen.git;protocol=https;nobranch=1;branch=v0.64.0"
> +SRCREV = "ae6817256ac557981906e93a1f866349db85053e"
> +S = "${WORKDIR}/git"
> +CARGO_SRC_DIR = "bindgen-cli"
> +
> +
> +# please note if you have entries that do not begin with crate://
> +# you must change them to how that package can be fetched
> +SRC_URI += " \
> +crate://crates.io/aho-corasick/0.5.3 \
> +crate://crates.io/aho-corasick/0.7.20 \
> +crate://crates.io/ansi_term/0.12.1 \
> +crate://crates.io/atty/0.2.14 \
> +crate://crates.io/bitflags/1.3.2 \
> +crate://crates.io/block/0.1.6 \
> +crate://crates.io/cc/1.0.78 \
> +crate://crates.io/cexpr/0.6.0 \
> +crate://crates.io/cfg-if/1.0.0 \
> +crate://crates.io/clang-sys/1.4.0 \
> +crate://crates.io/clap/2.34.0 \
> +crate://crates.io/clap/4.1.4 \
> +crate://crates.io/clap_derive/4.1.0 \
> +crate://crates.io/clap_lex/0.3.1 \
> +crate://crates.io/diff/0.1.13 \
> +crate://crates.io/either/1.8.1 \
> +crate://crates.io/env_logger/0.3.5 \
> +crate://crates.io/env_logger/0.9.3 \
> +crate://crates.io/errno-dragonfly/0.1.2 \
> +crate://crates.io/errno/0.2.8 \
> +crate://crates.io/fastrand/1.8.0 \
> +crate://crates.io/fuchsia-cprng/0.1.1 \
> +crate://crates.io/glob/0.3.1 \
> +crate://crates.io/heck/0.4.0 \
> +crate://crates.io/hermit-abi/0.1.19 \
> +crate://crates.io/hermit-abi/0.2.6 \
> +crate://crates.io/humantime/2.1.0 \
> +crate://crates.io/instant/0.1.12 \
> +crate://crates.io/io-lifetimes/1.0.4 \
> +crate://crates.io/is-terminal/0.4.2 \
> +crate://crates.io/kernel32-sys/0.2.2 \
> +crate://crates.io/lazy_static/1.4.0 \
> +crate://crates.io/lazycell/1.3.0 \
> +crate://crates.io/libc/0.2.139 \
> +crate://crates.io/libloading/0.6.7 \
> +crate://crates.io/libloading/0.7.4 \
> +crate://crates.io/linux-raw-sys/0.1.4 \
> +crate://crates.io/log/0.3.9 \
> +crate://crates.io/log/0.4.17 \
> +crate://crates.io/malloc_buf/0.0.6 \
> +crate://crates.io/memchr/0.1.11 \
> +crate://crates.io/memchr/2.5.0 \
> +crate://crates.io/minimal-lexical/0.2.1 \
> +crate://crates.io/nom/7.1.3 \
> +crate://crates.io/objc/0.2.7 \
> +crate://crates.io/once_cell/1.17.0 \
> +crate://crates.io/os_str_bytes/6.4.1 \
> +crate://crates.io/peeking_take_while/0.1.2 \
> +crate://crates.io/proc-macro-error-attr/1.0.4 \
> +crate://crates.io/proc-macro-error/1.0.4 \
> +crate://crates.io/proc-macro2/1.0.50 \
> +crate://crates.io/quickcheck/0.4.1 \
> +crate://crates.io/quote/1.0.23 \
> +crate://crates.io/rand/0.3.23 \
> +crate://crates.io/rand/0.4.6 \
> +crate://crates.io/rand_core/0.3.1 \
> +crate://crates.io/rand_core/0.4.2 \
> +crate://crates.io/rdrand/0.4.0 \
> +crate://crates.io/redox_syscall/0.2.16 \
> +crate://crates.io/regex-syntax/0.3.9 \
> +crate://crates.io/regex-syntax/0.6.28 \
> +crate://crates.io/regex/0.1.80 \
> +crate://crates.io/regex/1.7.1 \
> +crate://crates.io/remove_dir_all/0.5.3 \
> +crate://crates.io/rustc-hash/1.1.0 \
> +crate://crates.io/rustix/0.36.7 \
> +crate://crates.io/shlex/1.1.0 \
> +crate://crates.io
[OE-core] [PATCH] gcr: correctly configure vala against introspection data
GI_DATA_ENABLED is the right source for making that decision
as it additionally factors in presence of qemu-usermode in
MACHINE_FEATURES.
Signed-off-by: Alexander Kanavin
---
meta/recipes-gnome/gcr/gcr_4.0.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gcr/gcr_4.0.0.bb
b/meta/recipes-gnome/gcr/gcr_4.0.0.bb
index b137968943..7821e31b52 100644
--- a/meta/recipes-gnome/gcr/gcr_4.0.0.bb
+++ b/meta/recipes-gnome/gcr/gcr_4.0.0.bb
@@ -29,7 +29,7 @@ PACKAGECONFIG ??= " \
${@bb.utils.filter('DISTRO_FEATURES', 'systemd', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'gtk', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'gtk', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 'gobject-introspection-data',
'vapi', '', d)} \
+ ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'vapi', '', d)} \
"
PACKAGECONFIG[gtk] = "-Dgtk4=true,-Dgtk4=false,gtk4"
PACKAGECONFIG[ssh_agent] =
"-Dssh_agent=true,-Dssh_agent=false,libsecret,openssh"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177668):
https://lists.openembedded.org/g/openembedded-core/message/177668
Mute This Topic: https://lists.openembedded.org/mt/97202956/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/4] mesa: Rename PACKAGECONFIG "opencl" to "clover"
There is another OpenCL frontend called "rusticl" now.
Signed-off-by: Zoltán Böszörményi
---
meta/recipes-graphics/mesa/mesa.inc | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 70f9b6fc17..9ec10c49ca 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -115,9 +115,9 @@ PACKAGECONFIG[gles] = "-Dgles1=enabled -Dgles2=enabled,
-Dgles1=disabled -Dgles2
# "egl" requires "opengl"
PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
-# "opencl" requires libclc from meta-clang and spirv-tools from OE-Core
+# "clover" requires libclc from meta-clang and spirv-tools from OE-Core
OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno',
'-Dopencl-native=true', '', d)}"
-PACKAGECONFIG[opencl] = "-Dgallium-opencl=icd -Dopencl-spirv=true
${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools"
+PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools"
PACKAGECONFIG[broadcom] = ""
PACKAGECONFIG[etnaviv] = ""
@@ -196,7 +196,7 @@ DEV_PKG_DEPENDENCY = ""
# development package of libgles3.
RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
-RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'opencl',
'libclc spirv-tools', '', d)}"
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover',
'libclc spirv-tools', '', d)}"
PACKAGES =+ "libegl-mesa libegl-mesa-dev \
libosmesa libosmesa-dev \
@@ -242,7 +242,7 @@ python __anonymous() {
("gles", "libgles1", "libglesv1-cm1"),
("gles", "libgles2", "libglesv2-2"),
("gles", "libgles3",),
- ("opencl", "libopencl",)):
+ ("clover", "libopencl",)):
if not p[0] in pkgconfig:
continue
mlprefix = d.getVar("MLPREFIX")
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177666):
https://lists.openembedded.org/g/openembedded-core/message/177666
Mute This Topic: https://lists.openembedded.org/mt/97202945/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 4/4] mesa: Add PACKAGECONFIG "rusticl"
Signed-off-by: Zoltán Böszörményi
---
meta/recipes-graphics/mesa/mesa.inc | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index 9ec10c49ca..e70cf9a42a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -45,7 +45,7 @@ PROVIDES = " \
virtual/mesa \
"
-inherit meson pkgconfig python3native gettext features_check
+inherit meson pkgconfig python3native gettext features_check rust
BBCLASSEXTEND = "native nativesdk"
@@ -119,6 +119,13 @@ PACKAGECONFIG[egl] = "-Degl=enabled, -Degl=disabled"
OPENCL_NATIVE = "${@bb.utils.contains('PACKAGECONFIG', 'freedreno',
'-Dopencl-native=true', '', d)}"
PACKAGECONFIG[clover] = "-Dgallium-opencl=icd -Dopencl-spirv=true
${OPENCL_NATIVE},-Dgallium-opencl=disabled -Dopencl-spirv=false,libclc
spirv-tools"
+# "rusticl" requires libclc and spirv-llvm-translator from meta-clang and
spirv-tools from OE-Core
+PACKAGECONFIG[rusticl] = "-Dgallium-rusticl=true
-Drust_std=2021,-Dgallium-rusticl=false,bindgen-cli-native libclc spirv-tools
spirv-llvm-translator,libclc spirv-tools spirv-llvm-translator"
+
+# "rusticl" runs bindgen.
+# This setting is needed by bindgen to dlopen the correct libclang.
+export LIBCLANG_PATH = "${STAGING_LIBDIR_NATIVE}"
+
PACKAGECONFIG[broadcom] = ""
PACKAGECONFIG[etnaviv] = ""
PACKAGECONFIG[freedreno] = ""
@@ -197,6 +204,7 @@ DEV_PKG_DEPENDENCY = ""
RDEPENDS:libgles3-mesa-dev += "libgles2-mesa-dev"
RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'clover',
'libclc spirv-tools', '', d)}"
+RDEPENDS:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG', 'rusticl',
'libclc spirv-tools spirv-llvm-translator', '', d)}"
PACKAGES =+ "libegl-mesa libegl-mesa-dev \
libosmesa libosmesa-dev \
@@ -242,7 +250,8 @@ python __anonymous() {
("gles", "libgles1", "libglesv1-cm1"),
("gles", "libgles2", "libglesv2-2"),
("gles", "libgles3",),
- ("clover", "libopencl",)):
+ ("clover", "libopencl",),
+ ("rusticl", "libopencl",)):
if not p[0] in pkgconfig:
continue
mlprefix = d.getVar("MLPREFIX")
@@ -303,7 +312,8 @@ FILES:libgles1-mesa = "${libdir}/libGLESv1*.so.*"
FILES:libgles2-mesa = "${libdir}/libGLESv2.so.*"
FILES:libgl-mesa = "${libdir}/libGL.so.*"
FILES:libglx-mesa = "${libdir}/libGLX*.so.*"
-FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.*
${libdir}/gallium-pipe/*.so ${sysconfdir}/OpenCL/vendors/mesa.icd"
+FILES:libopencl-mesa = "${libdir}/libMesaOpenCL.so.*
${libdir}/libRusticlOpenCL.so ${libdir}/gallium-pipe/*.so
${sysconfdir}/OpenCL/vendors/mesa.icd ${sysconfdir}/OpenCL/vendors/rusticl.icd"
+INSANE_SKIP:libopencl-mesa += "${@bb.utils.contains('PACKAGECONFIG',
'rusticl', 'dev-so', '', d)}"
FILES:libglapi = "${libdir}/libglapi.so.*"
FILES:libosmesa = "${libdir}/libOSMesa.so.*"
FILES:libxatracker = "${libdir}/libxatracker.so.*"
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177667):
https://lists.openembedded.org/g/openembedded-core/message/177667
Mute This Topic: https://lists.openembedded.org/mt/97202946/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/4] mesa, mesa-gl: 23.0.0
Signed-off-by: Zoltán Böszörményi
---
...-backend-fix-gbm-compile-without-dri.patch | 65 ---
...ormat-Check-for-NEON-before-using-it.patch | 16 ++---
.../{mesa-gl_22.3.5.bb => mesa-gl_23.0.0.bb} | 0
meta/recipes-graphics/mesa/mesa.inc | 3 +-
.../mesa/{mesa_22.3.5.bb => mesa_23.0.0.bb} | 0
5 files changed, 9 insertions(+), 75 deletions(-)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch
rename meta/recipes-graphics/mesa/{mesa-gl_22.3.5.bb => mesa-gl_23.0.0.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_22.3.5.bb => mesa_23.0.0.bb} (100%)
diff --git
a/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch
b/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch
deleted file mode 100644
index 6541671b7a..00
---
a/meta/recipes-graphics/mesa/files/0001-gbm-backend-fix-gbm-compile-without-dri.patch
+++ /dev/null
@@ -1,65 +0,0 @@
-From 25946100e21cf2095bea334e8d7096798561d0b7 Mon Sep 17 00:00:00 2001
-From: Vincent Davis Jr
-Date: Wed, 28 Dec 2022 16:28:01 -0600
-Subject: [PATCH] gbm/backend: fix gbm compile without dri
-
-Upstream-Status: Backport
-
-https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20447
-https://gitlab.freedesktop.org/mesa/mesa/-/commit/842ca284650f066e58706741a7d22d67b5088e60
-
-At mesa version 22.2.3 patch wasn't introduced until after.
-
-Commit introduces a fix that allows for gbm to be built with an empty
-backend. There are situation especially in a Yocto/OE cross compilation
-environment where you want to build with an empty backend. The particular
-situation is as such:
-
-The mesa-gl recipe is the preferred provider for virtual/libgbm, virtual/libgl,
-virtual/mesa, etc... But the x11 DISTRO_FEATURE in't included this leads to
build
-errors such as:
-
-| /../../../ld: src/gbm/libgbm.so.1.0.0.p/main_backend.c.o: in function
`find_backend':
-| backend.c:(.text.find_backend+0xa4): undefined reference to `gbm_dri_backend'
-| /../../../ld:
src/gbm/libgbm.so.1.0.0.p/main_backend.c.o:(.data.rel.ro.builtin_backends+0x4):
-undefined reference to `gbm_dri_backend'
-| collect2: error: ld returned 1 exit status
-
-Issue should be replicable by setting -Ddri3=disabled and -Dgbm=enabled
-
-Add fix to bypasses compilation issue by excluding gbm dri backend. If
-HAVE_DRI || HAVE_DRIX not specified.
-
-Acked-by: David Heidelberg
-Signed-off-by: Vincent Davis Jr
- src/gbm/main/backend.c | 4
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/gbm/main/backend.c b/src/gbm/main/backend.c
-index 974d0a76a4e..feee0703495 100644
a/src/gbm/main/backend.c
-+++ b/src/gbm/main/backend.c
-@@ -42,7 +42,9 @@
- #define ARRAY_SIZE(a) (sizeof(a)/sizeof((a)[0]))
- #define VER_MIN(a, b) ((a) < (b) ? (a) : (b))
-
-+#if defined(HAVE_DRI) || defined(HAVE_DRI2) || defined(HAVE_DRI3)
- extern const struct gbm_backend gbm_dri_backend;
-+#endif
-
- struct gbm_backend_desc {
-const char *name;
-@@ -51,7 +53,9 @@ struct gbm_backend_desc {
- };
-
- static const struct gbm_backend_desc builtin_backends[] = {
-+#if defined(HAVE_DRI) || defined(HAVE_DRI2) || defined(HAVE_DRI3)
-{ "dri", &gbm_dri_backend },
-+#endif
- };
-
- #define BACKEND_LIB_SUFFIX "_gbm"
---
-2.34.1
-
diff --git
a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
index d22ff3c8a8..0bbd518047 100644
---
a/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
+++
b/meta/recipes-graphics/mesa/files/0001-util-format-Check-for-NEON-before-using-it.patch
@@ -23,12 +23,12 @@ diff --git a/src/util/format/u_format.c
b/src/util/format/u_format.c
index c071250..0880984 100644
--- a/src/util/format/u_format.c
+++ b/src/util/format/u_format.c
-@@ -1184,7 +1184,7 @@ static void
+@@ -1187,7 +1187,7 @@
util_format_unpack_table_init(void)
{
for (enum pipe_format format = PIPE_FORMAT_NONE; format <
PIPE_FORMAT_COUNT; format++) {
--#if (defined(PIPE_ARCH_AARCH64) || defined(PIPE_ARCH_ARM)) &&
!defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
-+#if (defined(PIPE_ARCH_AARCH64) || (defined(__ARM_NEON) &&
defined(PIPE_ARCH_ARM))) && !defined(NO_FORMAT_ASM)
+-#if (DETECT_ARCH_AARCH64 || DETECT_ARCH_ARM) && !defined(NO_FORMAT_ASM) &&
!defined(__SOFTFP__)
++#if (DETECT_ARCH_AARCH64 || (DETECT_ARCH_ARM && defined(__ARM_NEON))) &&
!defined(NO_FORMAT_ASM) && !defined(__SOFTFP__)
const struct util_format_unpack_description *unpack =
util_format_unpack_description_neon(format);
if (unpack) {
util_format_unpack_table[format] = unpack;
@@ -36,12 +36,12 @@ diff --git a/src/util/format/u_format_unpack_neon.c
b/src/util/format/u_format_u
index a4a5cb1..1e4f794 100644
--- a/src/util/format/u_format_unpack_neon.c
+++ b/src/util/format/u_format_unpack_neon.c
-@@ -23
[OE-core] [PATCH 1/4] bindgen-cli: Add new recipe
The recipe is automatically generated by cargo-bitbake, with the
manual change to add BBCLASSEXTEND = "native" in the include file.
It is used by Mesa 23.0.0 to build Rusticl.
Signed-off-by: Zoltán Böszörményi
---
meta/recipes-devtools/bindgen/bindgen-cli.inc | 1 +
.../bindgen/bindgen-cli_0.64.0.bb | 132 ++
2 files changed, 133 insertions(+)
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli.inc
create mode 100644 meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli.inc
b/meta/recipes-devtools/bindgen/bindgen-cli.inc
new file mode 100644
index 00..d3267ac413
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli.inc
@@ -0,0 +1 @@
+BBCLASSEXTEND = "native"
diff --git a/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
new file mode 100644
index 00..da3d692717
--- /dev/null
+++ b/meta/recipes-devtools/bindgen/bindgen-cli_0.64.0.bb
@@ -0,0 +1,132 @@
+# Auto-Generated by cargo-bitbake 0.3.16-alpha.0
+#
+inherit cargo
+
+# If this is git based prefer versioned ones if they exist
+# DEFAULT_PREFERENCE = "-1"
+
+# how to get bindgen-cli could be as easy as but default to a git checkout:
+# SRC_URI += "crate://crates.io/bindgen-cli/0.64.0"
+SRC_URI +=
"git://github.com/rust-lang/rust-bindgen.git;protocol=https;nobranch=1;branch=v0.64.0"
+SRCREV = "ae6817256ac557981906e93a1f866349db85053e"
+S = "${WORKDIR}/git"
+CARGO_SRC_DIR = "bindgen-cli"
+
+
+# please note if you have entries that do not begin with crate://
+# you must change them to how that package can be fetched
+SRC_URI += " \
+crate://crates.io/aho-corasick/0.5.3 \
+crate://crates.io/aho-corasick/0.7.20 \
+crate://crates.io/ansi_term/0.12.1 \
+crate://crates.io/atty/0.2.14 \
+crate://crates.io/bitflags/1.3.2 \
+crate://crates.io/block/0.1.6 \
+crate://crates.io/cc/1.0.78 \
+crate://crates.io/cexpr/0.6.0 \
+crate://crates.io/cfg-if/1.0.0 \
+crate://crates.io/clang-sys/1.4.0 \
+crate://crates.io/clap/2.34.0 \
+crate://crates.io/clap/4.1.4 \
+crate://crates.io/clap_derive/4.1.0 \
+crate://crates.io/clap_lex/0.3.1 \
+crate://crates.io/diff/0.1.13 \
+crate://crates.io/either/1.8.1 \
+crate://crates.io/env_logger/0.3.5 \
+crate://crates.io/env_logger/0.9.3 \
+crate://crates.io/errno-dragonfly/0.1.2 \
+crate://crates.io/errno/0.2.8 \
+crate://crates.io/fastrand/1.8.0 \
+crate://crates.io/fuchsia-cprng/0.1.1 \
+crate://crates.io/glob/0.3.1 \
+crate://crates.io/heck/0.4.0 \
+crate://crates.io/hermit-abi/0.1.19 \
+crate://crates.io/hermit-abi/0.2.6 \
+crate://crates.io/humantime/2.1.0 \
+crate://crates.io/instant/0.1.12 \
+crate://crates.io/io-lifetimes/1.0.4 \
+crate://crates.io/is-terminal/0.4.2 \
+crate://crates.io/kernel32-sys/0.2.2 \
+crate://crates.io/lazy_static/1.4.0 \
+crate://crates.io/lazycell/1.3.0 \
+crate://crates.io/libc/0.2.139 \
+crate://crates.io/libloading/0.6.7 \
+crate://crates.io/libloading/0.7.4 \
+crate://crates.io/linux-raw-sys/0.1.4 \
+crate://crates.io/log/0.3.9 \
+crate://crates.io/log/0.4.17 \
+crate://crates.io/malloc_buf/0.0.6 \
+crate://crates.io/memchr/0.1.11 \
+crate://crates.io/memchr/2.5.0 \
+crate://crates.io/minimal-lexical/0.2.1 \
+crate://crates.io/nom/7.1.3 \
+crate://crates.io/objc/0.2.7 \
+crate://crates.io/once_cell/1.17.0 \
+crate://crates.io/os_str_bytes/6.4.1 \
+crate://crates.io/peeking_take_while/0.1.2 \
+crate://crates.io/proc-macro-error-attr/1.0.4 \
+crate://crates.io/proc-macro-error/1.0.4 \
+crate://crates.io/proc-macro2/1.0.50 \
+crate://crates.io/quickcheck/0.4.1 \
+crate://crates.io/quote/1.0.23 \
+crate://crates.io/rand/0.3.23 \
+crate://crates.io/rand/0.4.6 \
+crate://crates.io/rand_core/0.3.1 \
+crate://crates.io/rand_core/0.4.2 \
+crate://crates.io/rdrand/0.4.0 \
+crate://crates.io/redox_syscall/0.2.16 \
+crate://crates.io/regex-syntax/0.3.9 \
+crate://crates.io/regex-syntax/0.6.28 \
+crate://crates.io/regex/0.1.80 \
+crate://crates.io/regex/1.7.1 \
+crate://crates.io/remove_dir_all/0.5.3 \
+crate://crates.io/rustc-hash/1.1.0 \
+crate://crates.io/rustix/0.36.7 \
+crate://crates.io/shlex/1.1.0 \
+crate://crates.io/strsim/0.10.0 \
+crate://crates.io/strsim/0.8.0 \
+crate://crates.io/syn/1.0.107 \
+crate://crates.io/tempdir/0.3.7 \
+crate://crates.io/tempfile/3.3.0 \
+crate://crates.io/termcolor/1.2.0 \
+crate://crates.io/textwrap/0.11.0 \
+crate://crates.io/thread-id/2.0.0 \
+crate://crates.io/thread_local/0.2.7 \
+crate://crates.io/unicode-ident/1.0.6 \
+crate://crates.io/unicode-width/0.1.10 \
+crate://crates.io/utf8-ranges/0.1.3 \
+crate://crates.io/vec_map/0.8.2 \
+crate://crates.io/version_check/0.9.4 \
Re: [OE-core][kirkstone][PATCH] bind: Upgrade bind-9.18.11 -> bind-9.19.9
9.19 is a development branch. You need to update to the latest version
in 9.18 series. Also, the patch needs to be submitted for master
first.
Alex
On Fri, 24 Feb 2023 at 09:53, vkumbhar wrote:
>
> Fix below security CVEs:
> CVE-2022-3094
> CVE-2022-3736
> CVE-2022-3924
>
> Fix serve-stale crash when recursive clients soft quota
> is reached. (CVE-2022-3924) [GL #3619]
>
> Handle RRSIG lookups when serve-stale is active.
> (CVE-2022-3736) [GL #3622]
>
> An UPDATE message flood could cause named to exhaust all
> available memory. This flaw was addressed by adding a
> new "update-quota" statement that controls the number of
> simultaneous UPDATE messages that can be processed or
> forwarded. The default is 100. A stats counter has been
> added to record events when the update quota is
> exceeded, and the XML and JSON statistics version
> numbers have been updated. (CVE-2022-3094) [GL #3523]
>
> Signed-off-by: Vivek Kumbhar
> ---
> .../0001-avoid-start-failure-with-bind-user.patch | 0
> .../0001-named-lwresd-V-and-start-log-hide-build-options.patch | 0
> .../bind-ensure-searching-for-json-headers-searches-sysr.patch | 0
> .../bind/{bind-9.18.11 => bind-9.19.9}/bind9| 0
> .../bind/{bind-9.18.11 => bind-9.19.9}/conf.patch | 0
> .../bind/{bind-9.18.11 => bind-9.19.9}/generate-rndc-key.sh | 0
> .../init.d-add-support-for-read-only-rootfs.patch | 0
> .../make-etc-initd-bind-stop-work.patch | 0
> .../bind/{bind-9.18.11 => bind-9.19.9}/named.service| 0
> .../bind/{bind_9.18.11.bb => bind_9.19.9.bb}| 2 +-
> 10 files changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/0001-avoid-start-failure-with-bind-user.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/0001-named-lwresd-V-and-start-log-hide-build-options.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/bind-ensure-searching-for-json-headers-searches-sysr.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 => bind-9.19.9}/bind9
> (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/conf.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/generate-rndc-key.sh (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/init.d-add-support-for-read-only-rootfs.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/make-etc-initd-bind-stop-work.patch (100%)
> rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
> bind-9.19.9}/named.service (100%)
> rename meta/recipes-connectivity/bind/{bind_9.18.11.bb => bind_9.19.9.bb}
> (97%)
>
> diff --git
> a/meta/recipes-connectivity/bind/bind-9.18.11/0001-avoid-start-failure-with-bind-user.patch
>
> b/meta/recipes-connectivity/bind/bind-9.19.9/0001-avoid-start-failure-with-bind-user.patch
> similarity index 100%
> rename from
> meta/recipes-connectivity/bind/bind-9.18.11/0001-avoid-start-failure-with-bind-user.patch
> rename to
> meta/recipes-connectivity/bind/bind-9.19.9/0001-avoid-start-failure-with-bind-user.patch
> diff --git
> a/meta/recipes-connectivity/bind/bind-9.18.11/0001-named-lwresd-V-and-start-log-hide-build-options.patch
>
> b/meta/recipes-connectivity/bind/bind-9.19.9/0001-named-lwresd-V-and-start-log-hide-build-options.patch
> similarity index 100%
> rename from
> meta/recipes-connectivity/bind/bind-9.18.11/0001-named-lwresd-V-and-start-log-hide-build-options.patch
> rename to
> meta/recipes-connectivity/bind/bind-9.19.9/0001-named-lwresd-V-and-start-log-hide-build-options.patch
> diff --git
> a/meta/recipes-connectivity/bind/bind-9.18.11/bind-ensure-searching-for-json-headers-searches-sysr.patch
>
> b/meta/recipes-connectivity/bind/bind-9.19.9/bind-ensure-searching-for-json-headers-searches-sysr.patch
> similarity index 100%
> rename from
> meta/recipes-connectivity/bind/bind-9.18.11/bind-ensure-searching-for-json-headers-searches-sysr.patch
> rename to
> meta/recipes-connectivity/bind/bind-9.19.9/bind-ensure-searching-for-json-headers-searches-sysr.patch
> diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/bind9
> b/meta/recipes-connectivity/bind/bind-9.19.9/bind9
> similarity index 100%
> rename from meta/recipes-connectivity/bind/bind-9.18.11/bind9
> rename to meta/recipes-connectivity/bind/bind-9.19.9/bind9
> diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/conf.patch
> b/meta/recipes-connectivity/bind/bind-9.19.9/conf.patch
> similarity index 100%
> rename from meta/recipes-connectivity/bind/bind-9.18.11/conf.patch
> rename to meta/recipes-connectivity/bind/bind-9.19.9/conf.patch
> diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/generate-rndc-key.sh
> b/meta/recipes-connectivity/bind/bind-9.19.9/generate-rndc-key.sh
> similarity index 100%
> rename from meta/rec
[OE-core][kirkstone][PATCH] bind: Upgrade bind-9.18.11 -> bind-9.19.9
Fix below security CVEs:
CVE-2022-3094
CVE-2022-3736
CVE-2022-3924
Fix serve-stale crash when recursive clients soft quota
is reached. (CVE-2022-3924) [GL #3619]
Handle RRSIG lookups when serve-stale is active.
(CVE-2022-3736) [GL #3622]
An UPDATE message flood could cause named to exhaust all
available memory. This flaw was addressed by adding a
new "update-quota" statement that controls the number of
simultaneous UPDATE messages that can be processed or
forwarded. The default is 100. A stats counter has been
added to record events when the update quota is
exceeded, and the XML and JSON statistics version
numbers have been updated. (CVE-2022-3094) [GL #3523]
Signed-off-by: Vivek Kumbhar
---
.../0001-avoid-start-failure-with-bind-user.patch | 0
.../0001-named-lwresd-V-and-start-log-hide-build-options.patch | 0
.../bind-ensure-searching-for-json-headers-searches-sysr.patch | 0
.../bind/{bind-9.18.11 => bind-9.19.9}/bind9| 0
.../bind/{bind-9.18.11 => bind-9.19.9}/conf.patch | 0
.../bind/{bind-9.18.11 => bind-9.19.9}/generate-rndc-key.sh | 0
.../init.d-add-support-for-read-only-rootfs.patch | 0
.../make-etc-initd-bind-stop-work.patch | 0
.../bind/{bind-9.18.11 => bind-9.19.9}/named.service| 0
.../bind/{bind_9.18.11.bb => bind_9.19.9.bb}| 2 +-
10 files changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/0001-avoid-start-failure-with-bind-user.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/0001-named-lwresd-V-and-start-log-hide-build-options.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/bind-ensure-searching-for-json-headers-searches-sysr.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 => bind-9.19.9}/bind9
(100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 => bind-9.19.9}/conf.patch
(100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/generate-rndc-key.sh (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/init.d-add-support-for-read-only-rootfs.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/make-etc-initd-bind-stop-work.patch (100%)
rename meta/recipes-connectivity/bind/{bind-9.18.11 =>
bind-9.19.9}/named.service (100%)
rename meta/recipes-connectivity/bind/{bind_9.18.11.bb => bind_9.19.9.bb} (97%)
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.11/0001-avoid-start-failure-with-bind-user.patch
b/meta/recipes-connectivity/bind/bind-9.19.9/0001-avoid-start-failure-with-bind-user.patch
similarity index 100%
rename from
meta/recipes-connectivity/bind/bind-9.18.11/0001-avoid-start-failure-with-bind-user.patch
rename to
meta/recipes-connectivity/bind/bind-9.19.9/0001-avoid-start-failure-with-bind-user.patch
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.11/0001-named-lwresd-V-and-start-log-hide-build-options.patch
b/meta/recipes-connectivity/bind/bind-9.19.9/0001-named-lwresd-V-and-start-log-hide-build-options.patch
similarity index 100%
rename from
meta/recipes-connectivity/bind/bind-9.18.11/0001-named-lwresd-V-and-start-log-hide-build-options.patch
rename to
meta/recipes-connectivity/bind/bind-9.19.9/0001-named-lwresd-V-and-start-log-hide-build-options.patch
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.11/bind-ensure-searching-for-json-headers-searches-sysr.patch
b/meta/recipes-connectivity/bind/bind-9.19.9/bind-ensure-searching-for-json-headers-searches-sysr.patch
similarity index 100%
rename from
meta/recipes-connectivity/bind/bind-9.18.11/bind-ensure-searching-for-json-headers-searches-sysr.patch
rename to
meta/recipes-connectivity/bind/bind-9.19.9/bind-ensure-searching-for-json-headers-searches-sysr.patch
diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/bind9
b/meta/recipes-connectivity/bind/bind-9.19.9/bind9
similarity index 100%
rename from meta/recipes-connectivity/bind/bind-9.18.11/bind9
rename to meta/recipes-connectivity/bind/bind-9.19.9/bind9
diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/conf.patch
b/meta/recipes-connectivity/bind/bind-9.19.9/conf.patch
similarity index 100%
rename from meta/recipes-connectivity/bind/bind-9.18.11/conf.patch
rename to meta/recipes-connectivity/bind/bind-9.19.9/conf.patch
diff --git a/meta/recipes-connectivity/bind/bind-9.18.11/generate-rndc-key.sh
b/meta/recipes-connectivity/bind/bind-9.19.9/generate-rndc-key.sh
similarity index 100%
rename from meta/recipes-connectivity/bind/bind-9.18.11/generate-rndc-key.sh
rename to meta/recipes-connectivity/bind/bind-9.19.9/generate-rndc-key.sh
diff --git
a/meta/recipes-connectivity/bind/bind-9.18.11/init.d-add-support-for-read-only-rootfs.patch
b/meta/recipes-connectivity/bind/bind-9.19.9/init.d-add-support-for-read-only-rootfs.patch
similarity index 100%
rename from
meta/recipes-connectiv
Re: [OE-core] [PATCH v12] Rust Oe-Selftest implementation
On Thu, 2023-02-23 at 22:50 +, Richard Purdie via
lists.openembedded.org wrote:
> On Thu, 2023-02-23 at 21:04 +, Richard Purdie via
> lists.openembedded.org wrote:
> > On Thu, 2023-02-23 at 13:55 -0500, Randy MacLeod wrote:
> > > Thanks Naveen,
> > >
> > > With a large patch like this it would be good if you could provide a
> > > cover letter that summarized what is different in v12, compared to
> > > v11.
> > >
> > > I've looked at the diff and my summary is below. There are some
> > > changes
> > > which I see but would benefit from an explanation.
> > >
> > > Finally, please change your SOB line to @windriver.com.
> > >
> >
> > Changelogs definitely help, thanks Randy!
> >
> > Thanks for putting this patch together Naveen, we are getting there. I
> > ran this through the autobuilder and the good news is we only saw one
> > failure related to the patch, in oe-selftest on an ARM host:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1004
> > (from
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/4962
> > )
> >
> > We could disable the rust tests on arm host systems to get this to
> > merge however ideally it would be fixed to run there properly as well.
> > I'm not even sure this should actually be running there at all now I
> > look at things. The other toolchain/machine specific tests are tagged
> > as "machine", e.g. meta_ide.py has:
> >
> > @OETestTag("machine")
> > class MetaIDE(OESelftestTestCase):
> >
> > or they're marked as @OETestTag("toolchain-user") or
> > @OETestTag("toolchain-system") in the case of the glibc/gcc tests. The
> > difference is how the tests are run so "toolchain-system" would be most
> > appropriate for rust. This means that the tests are run per MACHINE
> > target instead of once overall.
> >
> > The second issue I noticed is that the test results are not appearing
> > in the test report. For the build above, this is here:
> >
> > https://autobuilder.yocto.io/pub/non-release/20230223-9/testresults/testresult-report.txt
> >
> >
> > and I can't see the rust tests at all. This will need to be fixed
> > before the patches can merge. It may be changing to be
> > machine/toolchain might fix that, I don't remember the details.
>
> I found some time to check into this a little further. We definitely
> need to mark the test as a toolchain-system test so it is run in the
> right places.
>
> Aside from that, there is also no individual test result reporting in
> place for it, either the test suite passes or it does not.
>
> With the gcc tests, you'll see there is the self.ptest_result() call
> which logs the individual test pass/fail/skip value. We'll need to do
> something similar with rust so we don't just have one overall
> pass/fail.
I reran this with the OTTestTag set. With that set, the tests run in
the correct places and we then see failures for x86, mips and ppc:
https://autobuilder.yoctoproject.org/typhoon/#/builders/59/builds/6663
https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/6682
https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/6672
AssertionError: Command '['scp', '-o', 'UserKnownHostsFile=/dev/null', '-o',
'StrictHostKeyChecking=no', '-o', 'LogLevel=ERROR',
'/home/pokybuild/yocto-worker/qemux86/build/build-st-2169186/tmp/work/core2-32-poky-linux/rust/1.67.1-r0/rustc-1.67.1-src/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server',
'root@192.168.7.8:~/']' returned non-zero exit status 1:
b'scp: dest open(""): No such file or directory\r\nscp: failed to upload file
/home/pokybuild/yocto-worker/qemux86/build/build-st-2169186/tmp/work/core2-32-poky-linux/rust/1.67.1-r0/rustc-1.67.1-src/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server
to'
which might be because it is trying to copy a file from /x86_64-
unknown-linux-gnu/ when it is a 32 bit target?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177661):
https://lists.openembedded.org/g/openembedded-core/message/177661
Mute This Topic: https://lists.openembedded.org/mt/97178295/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
