Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.4.3.rc1)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.4.3.rc3. We are planning to execute following tests for this cycle: Please note that this is the rc3 build for 3.4.3, the rc number was marked to rc1 by mistake. OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowTurbot 32-bit 2. Coffee Lake 3. NUC 7 4. NUC 6 5. Edgerouter 6. Beaglebone ETA for completion next Monday, March 28. Thanks, Jay > -Original Message- > From: yo...@lists.yoctoproject.org On Behalf > Of Pokybuild User > Sent: Thursday, 24 March, 2022 11:35 PM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [yocto] QA notification for completed autobuilder build (yocto- > 3.4.3.rc1) > > > A build flagged for QA (yocto-3.4.3.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.4.3.rc1 > > > Build hash information: > > bitbake: 43dcb2b2a2b95a5c959be57bca94fb7190ea6257 > meta-agl: dd8e34ef5383d95d941a3afc9a03d3fcbba699dd > meta-arm: 33bbdc67f2ed7189398292ff58a7fee42a85a166 > meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069 > meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400 > meta-intel: fb9e0633614dbf956da185d291333bcc1b137e5a > meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8 > meta-openembedded: 061b7fc74f887454251307ef119b808a90654d3f > oecore: ebca8f3ac9372b7ebb3d39e8f7f930b63b481448 > poky: ee68ae307fd951b9de6b31dc6713ea29186b7749 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163625): https://lists.openembedded.org/g/openembedded-core/message/163625 Mute This Topic: https://lists.openembedded.org/mt/90014712/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OpenEmbedded Happy Hour March 30 5pm/1700 UTC
All, You are cordially invited to the next OpenEmbedded Happy Hour on March 30 for Europe/Americas timezones @ 1700/5pm UTC (1pm ET / 10am PT): https://www.openembedded.org/wiki/Calendar https://www.openembedded.org/wiki/Happy_Hours https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+March+30=20220330T17 -- Regards, Denys Dmytriyenko PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163624): https://lists.openembedded.org/g/openembedded-core/message/163624 Mute This Topic: https://lists.openembedded.org/mt/90011134/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 v1 1/2] gpg-sign: Add parameters to gpg signature function
On Thu, 2022-03-24 at 23:11 +0100, Ferry Toth wrote: > Op 24-03-2022 om 16:36 schreef Ferry Toth: > > Op 24-03-2022 om 13:03 schreef Richard Purdie: > > > On Thu, 2022-03-24 at 12:23 +0100, Ferry Toth wrote: > > > > > On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: > > > > > > I forgot to add a cover letter, sorry for that. The 2 patches > > > > > > together > > > > > > implement DEB repository signing. > > > > > > > > > > > > This is necessary since Gatesgarth |apt| (1.8.2) has become more > > > > > > strict > > > > > > and doesn’t allow unsigned repositories by default. > > > > > > > > > > > > It is possible to override this behavior |but||| is more work then > > > > > > to > > > > > > enable signed DEB repositories. These patches makes DEB a first > > > > > > class > > > > > > citizen as IPK and RPM. > > > > > > > > > > > > Patches have been in use in meta-intel-edison since Gatesgarth, see > > > > > > https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb- > > > > > > repository.html\ > > > > > What puzzles me is that we can build root filesystems using apt, we > > > > > test > > > > > this on > > > > > the autobuilder. Saying repositories are broken since gatesgarth > > > > > therefore > > > > > seems > > > > > confusing in the commit message. > > The Development Task manual in 3.22.4.3.3 names it a repository, as I > believe is common for a distributions server holding pre-built packages. > But I could change the name to package feed if that would be better. > > What I meant to say is that apt requires signed package feeds since > 1.8.2 and disabling that is a workaround. I mean to distinguish between the use of repositories at rootfs creation time compared to repositories used later to update an image. Since I know repositories are used to build the rootfs, the commit message did confuse me at first since rootfs construction works. > > > > > Good question. When I (meta-intel-edison) build the rootfs using DEB's > > > > it just > > > > works. > > > > Could it be that during rootfs build dpkg is used and not apt? I think > > > > I have > > > > seen that in the logs. > > > It definitely uses apt. > Checking logs I see you are correct. > > > > Of course apt uses dpkg to install a package as well, but it refuses to > > > > download the package from a repo when it's not signed. > > > Perhaps the difference is the packages are local and not remote? > > No, for generating the rootfs it appears the sources list file has: > > deb [trusted=yes] file:/path.../oe-rootfs-repo/edison/ ./ > > So apparently has been taken care by disabling the signing requirement. > [trusted=yes] is part of that workaround. That does give another way to work around this then... > > > > > > I guess we must configure apt to override that during the rootfs > > > > > process and > > > > > likely an end user with a remote feed could do the same, possibly > > > > > with a > > > > > warning > > > > > from apt? > Yes. But it is a pain to google to find how to do that. > > > > I believe there is no issue during rootfs generation. > > > > > > > > > I'm also worried that there isn't any automated testing of this > > > > > change. The > > > > > reason I worry is that since we don't show any testing failures right > > > > > now, > > > > > there > > > > > is clearly a hole in our automated testing coverage and there is no > > > > > guarantee > > > > > that this feature will keep working. It is these smaller corner case > > > > > issues > > > > > which tend to make or break the project's experience as if a feature > > > > > is > > > > > present, > > > > > people expect it to work. Can we improve the testing situation? > > > > It doesn't seem to be a particularly volatile area in the code. I > > > > refreshed > > > > Xavier's patches for Gatesgarth, and am actively using unchanged patch > > > > on > > > > Honisiter. > > > > I don't know how the automated testing is working but I guess for RPM a > > > > repo > > > > is generated using a small layer? And then tested on a qemu running the > > > > rootfs? > > > > Should be almost same for deb/apt, maybe could be modified from rpm > > > > test? > > > I think the rpm test is test_testimage_dnf in > > > meta/lib/oeqa/selftest/cases/runtime_test.py. You'd run it with: > > > > > > oe-selftest -r runtime_test.TestImage.test_testimage_dnf > > I'll have a look. > > Pfff. These tests are O(1) more then the signing code they test. I'm > trying this original test (on rpm) now to see if I can get that to run > and understand how it works. What you're asking to work is a complex scenario so the test isn't going to be simple. FWIW there is also oeqa/runtime/cases/apt.py. That test checks if a package can be installed from a remote package feed (no signing). It is doing: echo deb [ allow-insecure=yes ] %s ./ > sources.list to work around the signing issue. > Am I right that meta/lib/oeqa/selftest/cases/signing.py tests the actual > package feed
Re: [OE-core] [PATCH v1 1/2] gpg-sign: Add parameters to gpg signature function
Hi Op 24-03-2022 om 16:36 schreef Ferry Toth: Hi Op 24-03-2022 om 13:03 schreef Richard Purdie: On Thu, 2022-03-24 at 12:23 +0100, Ferry Toth wrote: On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: I forgot to add a cover letter, sorry for that. The 2 patches together implement DEB repository signing. This is necessary since Gatesgarth |apt| (1.8.2) has become more strict and doesn’t allow unsigned repositories by default. It is possible to override this behavior |but||| is more work then to enable signed DEB repositories. These patches makes DEB a first class citizen as IPK and RPM. Patches have been in use in meta-intel-edison since Gatesgarth, see https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb- repository.html\ What puzzles me is that we can build root filesystems using apt, we test this on the autobuilder. Saying repositories are broken since gatesgarth therefore seems confusing in the commit message. The Development Task manual in 3.22.4.3.3 names it a repository, as I believe is common for a distributions server holding pre-built packages. But I could change the name to package feed if that would be better. What I meant to say is that apt requires signed package feeds since 1.8.2 and disabling that is a workaround. Good question. When I (meta-intel-edison) build the rootfs using DEB's it just works. Could it be that during rootfs build dpkg is used and not apt? I think I have seen that in the logs. It definitely uses apt. Checking logs I see you are correct. Of course apt uses dpkg to install a package as well, but it refuses to download the package from a repo when it's not signed. Perhaps the difference is the packages are local and not remote? No, for generating the rootfs it appears the sources list file has: deb [trusted=yes] file:/path.../oe-rootfs-repo/edison/ ./ So apparently has been taken care by disabling the signing requirement. [trusted=yes] is part of that workaround. I guess we must configure apt to override that during the rootfs process and likely an end user with a remote feed could do the same, possibly with a warning from apt? Yes. But it is a pain to google to find how to do that. I believe there is no issue during rootfs generation. I'm also worried that there isn't any automated testing of this change. The reason I worry is that since we don't show any testing failures right now, there is clearly a hole in our automated testing coverage and there is no guarantee that this feature will keep working. It is these smaller corner case issues which tend to make or break the project's experience as if a feature is present, people expect it to work. Can we improve the testing situation? It doesn't seem to be a particularly volatile area in the code. I refreshed Xavier's patches for Gatesgarth, and am actively using unchanged patch on Honisiter. I don't know how the automated testing is working but I guess for RPM a repo is generated using a small layer? And then tested on a qemu running the rootfs? Should be almost same for deb/apt, maybe could be modified from rpm test? I think the rpm test is test_testimage_dnf in meta/lib/oeqa/selftest/cases/runtime_test.py. You'd run it with: oe-selftest -r runtime_test.TestImage.test_testimage_dnf I'll have a look. Pfff. These tests are O(1) more then the signing code they test. I'm trying this original test (on rpm) now to see if I can get that to run and understand how it works. Am I right that meta/lib/oeqa/selftest/cases/signing.py tests the actual package feed signing? Point is: currently deb is documented as a feasible package format to generate a repo. But it really is not without these signing patches. So we could either deprecate deb's (no, no please don't) or fix it. These patches fix it. With or without automated testing, it is already better then the current situation. I'm not sure it is. The project gains yet another set of config options which we don't have tests for and the maintainer stress levels in trying to keep it all working just get worse. We have a huge number of ways people can configure the builds. The only way the project manages to keep all of this working is through automated testing, there is simply no other way to do it. I appreciate adding tests is a pain and nobody likes doing it. It does however let the project stay functional for everyone's diverse use cases. There are all kinds of patches I could take because the improve some corner case. In most cases we don't know what else they might break or whether that code continues to be used or stays working. I therefore do really want tests for new configurations. It's not an improvement but a fix for an existing config. Even if it would break in the future it can't be worse then it is now. Who should write those tests? If you don't/can't as some actively using the feature, it means someone else has to, but who? I do understand. I've not decided what to do with the patches to be
[oe-core][PATCH 1/1] libxml2: fix CVE-2022-23308 regression
The fix for the CVE in 2.9.13 caused a regression which
was addressed after 2.9.13. We import that patch here.
Signed-off-by: Joe Slater
---
.../CVE-2022-23308-fix-regression.patch | 99 +++
meta/recipes-core/libxml/libxml2_2.9.13.bb| 3 +
2 files changed, 102 insertions(+)
create mode 100644
meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
diff --git
a/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
b/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
new file mode 100644
index 00..e188914613
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
@@ -0,0 +1,99 @@
+From 646fe48d1c8a74310c409ddf81fe7df6700052af Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Tue, 22 Feb 2022 11:51:08 +0100
+Subject: [PATCH] Fix --without-valid build
+
+Regressed in commit 652dd12a.
+---
+ valid.c | 58 -
+ 1 file changed, 29 insertions(+), 29 deletions(-)
+---
+
+From https://github.com/GNOME/libxml2.git
+ commit 646fe48d1c8a74310c409ddf81fe7df6700052af
+
+CVE: CVE-2022-23308
+Upstream-Status: Backport
+
+Signed-off-by: Joe Slater
+
+
+diff --git a/valid.c b/valid.c
+index 8e596f1d..9684683a 100644
+--- a/valid.c
b/valid.c
+@@ -479,35 +479,6 @@ nodeVPop(xmlValidCtxtPtr ctxt)
+ return (ret);
+ }
+
+-/**
+- * xmlValidNormalizeString:
+- * @str: a string
+- *
+- * Normalize a string in-place.
+- */
+-static void
+-xmlValidNormalizeString(xmlChar *str) {
+-xmlChar *dst;
+-const xmlChar *src;
+-
+-if (str == NULL)
+-return;
+-src = str;
+-dst = str;
+-
+-while (*src == 0x20) src++;
+-while (*src != 0) {
+- if (*src == 0x20) {
+- while (*src == 0x20) src++;
+- if (*src != 0)
+- *dst++ = 0x20;
+- } else {
+- *dst++ = *src++;
+- }
+-}
+-*dst = 0;
+-}
+-
+ #ifdef DEBUG_VALID_ALGO
+ static void
+ xmlValidPrintNode(xmlNodePtr cur) {
+@@ -2636,6 +2607,35 @@ xmlDumpNotationTable(xmlBufferPtr buf,
xmlNotationTablePtr table) {
+ (xmlDictOwns(dict, (const xmlChar *)(str)) == 0))) \
+ xmlFree((char *)(str));
+
++/**
++ * xmlValidNormalizeString:
++ * @str: a string
++ *
++ * Normalize a string in-place.
++ */
++static void
++xmlValidNormalizeString(xmlChar *str) {
++xmlChar *dst;
++const xmlChar *src;
++
++if (str == NULL)
++return;
++src = str;
++dst = str;
++
++while (*src == 0x20) src++;
++while (*src != 0) {
++ if (*src == 0x20) {
++ while (*src == 0x20) src++;
++ if (*src != 0)
++ *dst++ = 0x20;
++ } else {
++ *dst++ = *src++;
++ }
++}
++*dst = 0;
++}
++
+ static int
+ xmlIsStreaming(xmlValidCtxtPtr ctxt) {
+ xmlParserCtxtPtr pctxt;
+--
+2.35.1
+
diff --git a/meta/recipes-core/libxml/libxml2_2.9.13.bb
b/meta/recipes-core/libxml/libxml2_2.9.13.bb
index be59aba84b..e361b53bfd 100644
--- a/meta/recipes-core/libxml/libxml2_2.9.13.bb
+++ b/meta/recipes-core/libxml/libxml2_2.9.13.bb
@@ -23,6 +23,9 @@ SRC_URI +=
"http://www.w3.org/XML/Test/xmlts20080827.tar.gz;subdir=${BP};name=te
file://remove-fuzz-from-ptests.patch \
file://libxml-m4-use-pkgconfig.patch \
"
+# will be in v2.9.14
+#
+SRC_URI += "file://CVE-2022-23308-fix-regression.patch"
SRC_URI[archive.sha256sum] =
"276130602d12fe484ecc03447ee5e759d0465558fbc9d6bd144e3745306ebf0e"
SRC_URI[testtar.sha256sum] =
"96151685cec997e1f9f3387e3626d61e6284d4d6e66e0e440c209286c03e9cc7"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163621):
https://lists.openembedded.org/g/openembedded-core/message/163621
Mute This Topic: https://lists.openembedded.org/mt/90007157/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/tinfoil: Fix intermittent event loss issue in test
We've been seeing occasional test failures on the autobuilder where
we don't see the expected events. It turns out this is due to
run_command being helpful and eating them if the server is fast and
the client slow. Adding a sleep into the run_command code makes the
failure consistent.
Use a new "handle_events" argument to allow us to handle all the
events which is what this test requires.
[YOCTO #14585]
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/tinfoil.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/tinfoil.py
b/meta/lib/oeqa/selftest/cases/tinfoil.py
index 63ceddf118a..6f26af23d54 100644
--- a/meta/lib/oeqa/selftest/cases/tinfoil.py
+++ b/meta/lib/oeqa/selftest/cases/tinfoil.py
@@ -94,7 +94,7 @@ class TinfoilTests(OESelftestTestCase):
pass
pattern = 'conf'
-res = tinfoil.run_command('testCookerCommandEvent', pattern)
+res = tinfoil.run_command('testCookerCommandEvent', pattern,
handle_events=False)
self.assertTrue(res)
eventreceived = False
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163620):
https://lists.openembedded.org/g/openembedded-core/message/163620
Mute This Topic: https://lists.openembedded.org/mt/90004953/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] kernel.bbclass: avoid config changes based on the availability of pahole
From: Michael Olbrich
CONFIG_PAHOLE_HAS_SPLIT_BTF shows up in the config only when pahole is
installed on the host system. As a result, the config changes depending on
whether pahole is installed or not.
Set PAHOLE=false to ensure that it is never found.
If this is actually needed in the future, then we can add an option for
it and create a host package for pahole.
Signed-off-by: Michael Olbrich
[afa: ported from PTXdist 0c0cec2288 to OE-core]
Signed-off-by: Ahmad Fatoum
---
meta/classes/kernel.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4f304eb9c7ae..b3bbd3b27684 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -234,7 +234,7 @@ UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
KERNEL_EXTRA_ARGS ?= ""
EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCFLAGS="${BUILD_CFLAGS}"
HOSTLDFLAGS="${BUILD_LDFLAGS}" HOSTCPP="${BUILD_CPP}""
-EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}""
+EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX}" HOSTCXXFLAGS="${BUILD_CXXFLAGS}"
PAHOLE=false"
KERNEL_ALT_IMAGETYPE ??= ""
@@ -639,7 +639,7 @@ addtask savedefconfig after do_configure
inherit cml1
-KCONFIG_CONFIG_COMMAND:append = " LD='${KERNEL_LD}'
HOSTLDFLAGS='${BUILD_LDFLAGS}'"
+KCONFIG_CONFIG_COMMAND:append = " PAHOLE=false LD='${KERNEL_LD}'
HOSTLDFLAGS='${BUILD_LDFLAGS}'"
EXPORT_FUNCTIONS do_compile do_transform_kernel do_transform_bundled_initramfs
do_install do_configure
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163619):
https://lists.openembedded.org/g/openembedded-core/message/163619
Mute This Topic: https://lists.openembedded.org/mt/90003329/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 v4] qemu: Depend on libepoxy instead of virtual/libgl
- This abstracts on GL/GLES implementations
- Rename packageconfig to epoxy to match what code it doing underneath
Signed-off-by: Khem Raj
---
v2: Rename packageconfig to epoxy as it matches code
v3: Depend on libepoxy instead of virtual/egl
v4: Fix qemu-system-native recipe to adjust for renamed packageconfig
meta/recipes-devtools/qemu/qemu-system-native_6.2.0.bb | 2 +-
meta/recipes-devtools/qemu/qemu.inc| 6 +++---
meta/recipes-devtools/qemu/qemu_6.2.0.bb | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-devtools/qemu/qemu-system-native_6.2.0.bb
b/meta/recipes-devtools/qemu/qemu-system-native_6.2.0.bb
index b544ab4e817..bc5384d472e 100644
--- a/meta/recipes-devtools/qemu/qemu-system-native_6.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu-system-native_6.2.0.bb
@@ -12,7 +12,7 @@ DEPENDS = "glib-2.0-native zlib-native pixman-native
qemu-native bison-native me
EXTRA_OECONF:append = " --target-list=${@get_qemu_system_target_list(d)}"
PACKAGECONFIG ??= "fdt alsa kvm pie \
-${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '',
d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer epoxy',
'', d)} \
"
# Handle distros such as CentOS 5 32-bit that do not have kvm support
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 78aea71cc05..e9d2dae0405 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -142,8 +142,8 @@ do_install:append() {
# END of qemu-mips workaround
# Disable kvm/virgl/mesa on targets that do not support it
-PACKAGECONFIG:remove:darwin = "kvm virglrenderer glx gtk+"
-PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer glx gtk+"
+PACKAGECONFIG:remove:darwin = "kvm virglrenderer epoxy gtk+"
+PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer epoxy gtk+"
PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,libsdl2"
PACKAGECONFIG[virtfs] = "--enable-virtfs --enable-attr
--enable-cap-ng,--disable-virtfs,libcap-ng attr,"
@@ -165,7 +165,7 @@ PACKAGECONFIG[nettle] =
"--enable-nettle,--disable-nettle,nettle"
PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
PACKAGECONFIG[alsa] = "--audio-drv-list=default,,alsa-lib"
-PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
+PACKAGECONFIG[epoxy] = "--enable-opengl,--disable-opengl,libepoxy"
PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
diff --git a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
index c7eef0a9d5e..92857adf9c3 100644
--- a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
+++ b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
@@ -17,9 +17,9 @@ EXTRA_OECONF:append:class-nativesdk = "
--target-list=${@get_qemu_target_list(d)
PACKAGECONFIG ??= " \
fdt sdl kvm pie \
${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \
-${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '',
d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer epoxy',
'', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'seccomp', d)} \
"
PACKAGECONFIG:class-nativesdk ??= "fdt sdl kvm pie \
-${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx', '',
d)} \
+${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer epoxy',
'', d)} \
"
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163618):
https://lists.openembedded.org/g/openembedded-core/message/163618
Mute This Topic: https://lists.openembedded.org/mt/90003047/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 v1 1/2] gpg-sign: Add parameters to gpg signature function
Hi Op 24-03-2022 om 13:03 schreef Richard Purdie: On Thu, 2022-03-24 at 12:23 +0100, Ferry Toth wrote: On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: I forgot to add a cover letter, sorry for that. The 2 patches together implement DEB repository signing. This is necessary since Gatesgarth |apt| (1.8.2) has become more strict and doesn’t allow unsigned repositories by default. It is possible to override this behavior |but||| is more work then to enable signed DEB repositories. These patches makes DEB a first class citizen as IPK and RPM. Patches have been in use in meta-intel-edison since Gatesgarth, see https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb- repository.html\ What puzzles me is that we can build root filesystems using apt, we test this on the autobuilder. Saying repositories are broken since gatesgarth therefore seems confusing in the commit message. Good question. When I (meta-intel-edison) build the rootfs using DEB's it just works. Could it be that during rootfs build dpkg is used and not apt? I think I have seen that in the logs. It definitely uses apt. Of course apt uses dpkg to install a package as well, but it refuses to download the package from a repo when it's not signed. Perhaps the difference is the packages are local and not remote? I guess we must configure apt to override that during the rootfs process and likely an end user with a remote feed could do the same, possibly with a warning from apt? I believe there is no issue during rootfs generation. I'm also worried that there isn't any automated testing of this change. The reason I worry is that since we don't show any testing failures right now, there is clearly a hole in our automated testing coverage and there is no guarantee that this feature will keep working. It is these smaller corner case issues which tend to make or break the project's experience as if a feature is present, people expect it to work. Can we improve the testing situation? It doesn't seem to be a particularly volatile area in the code. I refreshed Xavier's patches for Gatesgarth, and am actively using unchanged patch on Honisiter. I don't know how the automated testing is working but I guess for RPM a repo is generated using a small layer? And then tested on a qemu running the rootfs? Should be almost same for deb/apt, maybe could be modified from rpm test? I think the rpm test is test_testimage_dnf in meta/lib/oeqa/selftest/cases/runtime_test.py. You'd run it with: oe-selftest -r runtime_test.TestImage.test_testimage_dnf I'll have a look. Point is: currently deb is documented as a feasible package format to generate a repo. But it really is not without these signing patches. So we could either deprecate deb's (no, no please don't) or fix it. These patches fix it. With or without automated testing, it is already better then the current situation. I'm not sure it is. The project gains yet another set of config options which we don't have tests for and the maintainer stress levels in trying to keep it all working just get worse. We have a huge number of ways people can configure the builds. The only way the project manages to keep all of this working is through automated testing, there is simply no other way to do it. I appreciate adding tests is a pain and nobody likes doing it. It does however let the project stay functional for everyone's diverse use cases. There are all kinds of patches I could take because the improve some corner case. In most cases we don't know what else they might break or whether that code continues to be used or stays working. I therefore do really want tests for new configurations. It's not an improvement but a fix for an existing config. Even if it would break in the future it can't be worse then it is now. Who should write those tests? If you don't/can't as some actively using the feature, it means someone else has to, but who? I do understand. I've not decided what to do with the patches to be honest but the merge and not bother with tests argument doesn't sit well with me. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163617): https://lists.openembedded.org/g/openembedded-core/message/163617 Mute This Topic: https://lists.openembedded.org/mt/89962631/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[oe-core][hardknott][PATCH 1/1] libxml2: Fix CVE-2022-23308
The first patch is the fix in version 2.9.13. The second
patch was added later and fixes a regression introduced
by the first.
Signed-off-by: Joe Slater
---
.../CVE-2022-23308-fix-regression.patch | 99 +
.../libxml/libxml2/CVE-2022-23308.patch | 209 ++
meta/recipes-core/libxml/libxml2_2.9.10.bb| 2 +
3 files changed, 310 insertions(+)
create mode 100644
meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
create mode 100644 meta/recipes-core/libxml/libxml2/CVE-2022-23308.patch
diff --git
a/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
b/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
new file mode 100644
index 00..eefecb9adb
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2022-23308-fix-regression.patch
@@ -0,0 +1,99 @@
+From 646fe48d1c8a74310c409ddf81fe7df6700052af Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Tue, 22 Feb 2022 11:51:08 +0100
+Subject: [PATCH] Fix --without-valid build
+
+Regressed in commit 652dd12a.
+---
+ valid.c | 58 -
+ 1 file changed, 29 insertions(+), 29 deletions(-)
+---
+
+From https://github.com/GNOME/libxml2.git
+ commit 646fe48d1c8a74310c409ddf81fe7df6700052af
+
+CVE: CVE-2022-23308
+Upstream-status: Backport
+
+Signed-off-by: Joe Slater
+
+
+diff --git a/valid.c b/valid.c
+index 8e596f1d..9684683a 100644
+--- a/valid.c
b/valid.c
+@@ -479,35 +479,6 @@ nodeVPop(xmlValidCtxtPtr ctxt)
+ return (ret);
+ }
+
+-/**
+- * xmlValidNormalizeString:
+- * @str: a string
+- *
+- * Normalize a string in-place.
+- */
+-static void
+-xmlValidNormalizeString(xmlChar *str) {
+-xmlChar *dst;
+-const xmlChar *src;
+-
+-if (str == NULL)
+-return;
+-src = str;
+-dst = str;
+-
+-while (*src == 0x20) src++;
+-while (*src != 0) {
+- if (*src == 0x20) {
+- while (*src == 0x20) src++;
+- if (*src != 0)
+- *dst++ = 0x20;
+- } else {
+- *dst++ = *src++;
+- }
+-}
+-*dst = 0;
+-}
+-
+ #ifdef DEBUG_VALID_ALGO
+ static void
+ xmlValidPrintNode(xmlNodePtr cur) {
+@@ -2636,6 +2607,35 @@ xmlDumpNotationTable(xmlBufferPtr buf,
xmlNotationTablePtr table) {
+ (xmlDictOwns(dict, (const xmlChar *)(str)) == 0))) \
+ xmlFree((char *)(str));
+
++/**
++ * xmlValidNormalizeString:
++ * @str: a string
++ *
++ * Normalize a string in-place.
++ */
++static void
++xmlValidNormalizeString(xmlChar *str) {
++xmlChar *dst;
++const xmlChar *src;
++
++if (str == NULL)
++return;
++src = str;
++dst = str;
++
++while (*src == 0x20) src++;
++while (*src != 0) {
++ if (*src == 0x20) {
++ while (*src == 0x20) src++;
++ if (*src != 0)
++ *dst++ = 0x20;
++ } else {
++ *dst++ = *src++;
++ }
++}
++*dst = 0;
++}
++
+ static int
+ xmlIsStreaming(xmlValidCtxtPtr ctxt) {
+ xmlParserCtxtPtr pctxt;
+--
+2.35.1
+
diff --git a/meta/recipes-core/libxml/libxml2/CVE-2022-23308.patch
b/meta/recipes-core/libxml/libxml2/CVE-2022-23308.patch
new file mode 100644
index 00..708a98b45a
--- /dev/null
+++ b/meta/recipes-core/libxml/libxml2/CVE-2022-23308.patch
@@ -0,0 +1,209 @@
+From 652dd12a858989b14eed4e84e453059cd3ba340e Mon Sep 17 00:00:00 2001
+From: Nick Wellnhofer
+Date: Tue, 8 Feb 2022 03:29:24 +0100
+Subject: [PATCH] [CVE-2022-23308] Use-after-free of ID and IDREF attributes
+
+If a document is parsed with XML_PARSE_DTDVALID and without
+XML_PARSE_NOENT, the value of ID attributes has to be normalized after
+potentially expanding entities in xmlRemoveID. Otherwise, later calls
+to xmlGetID can return a pointer to previously freed memory.
+
+ID attributes which are empty or contain only whitespace after
+entity expansion are affected in a similar way. This is fixed by
+not storing such attributes in the ID table.
+
+The test to detect streaming mode when validating against a DTD was
+broken. In connection with the defects above, this could result in a
+use-after-free when using the xmlReader interface with validation.
+Fix detection of streaming mode to avoid similar issues. (This changes
+the expected result of a test case. But as far as I can tell, using the
+XML reader with XIncludes referencing the root document never worked
+properly, anyway.)
+
+All of these issues can result in denial of service. Using xmlReader
+with validation could result in disclosure of memory via the error
+channel, typically stderr. The security impact of xmlGetID returning
+a pointer to freed memory depends on the application. The typical use
+case of calling xmlGetID on an unmodified document is not affected.
+---
+ result/XInclude/ns1.xml.rdr | 2 +-
+ valid.c | 88 +++--
+ 2 files changed, 56 insertions(+), 34 deletions(-)
+ ---
+
+From https://github.com/GNOME/libxml2.git
+ commit
[oe-core][dunfell][PATCH] apt: backport patch fix for CVE-2020-3810
Upstream commit:
https://salsa.debian.org/apt-team/apt/-/blob/dceb1e49e4b8e4dadaf056be34088b415939cda6/apt-pkg/contrib/arfile.cc
CVE: CVE-2020-3810
Signed-off-by: Davide Gardenal
---
meta/recipes-devtools/apt/apt.inc | 1 +
.../apt/apt/CVE-2020-3810.patch | 174 ++
2 files changed, 175 insertions(+)
create mode 100644 meta/recipes-devtools/apt/apt/CVE-2020-3810.patch
diff --git a/meta/recipes-devtools/apt/apt.inc
b/meta/recipes-devtools/apt/apt.inc
index 3c4fc6df07..ba827848a7 100644
--- a/meta/recipes-devtools/apt/apt.inc
+++ b/meta/recipes-devtools/apt/apt.inc
@@ -18,6 +18,7 @@ SRC_URI =
"https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/${BPN}/${P
file://0001-environment.mak-musl-based-systems-can-generate-shar.patch \
file://0001-apt-1.2.12-Fix-musl-build.patch \
file://0001-Include-array.h-for-std-array.patch \
+ file://CVE-2020-3810.patch \
"
SRC_URI[md5sum] = "d30eed9304e82ea8238c854b5c5a34d9"
SRC_URI[sha256sum] =
"03ded4f5e9b8d43ecec083704b2dcabf20c182ed382db9ac7251da0b0b038059"
diff --git a/meta/recipes-devtools/apt/apt/CVE-2020-3810.patch
b/meta/recipes-devtools/apt/apt/CVE-2020-3810.patch
new file mode 100644
index 00..cf1206a3fa
--- /dev/null
+++ b/meta/recipes-devtools/apt/apt/CVE-2020-3810.patch
@@ -0,0 +1,174 @@
+From dceb1e49e4b8e4dadaf056be34088b415939cda6 Mon Sep 17 00:00:00 2001
+From: Julian Andres Klode
+Date: Tue, 12 May 2020 11:49:09 +0200
+Subject: [PATCH] SECURITY UPDATE: Fix out of bounds read in .ar and .tar
+ implementation (CVE-2020-3810)
+
+When normalizing ar member names by removing trailing whitespace
+and slashes, an out-out-bound read can be caused if the ar member
+name consists only of such characters, because the code did not
+stop at 0, but would wrap around and continue reading from the
+stack, without any limit.
+
+Add a check to abort if we reached the first character in the
+name, effectively rejecting the use of names consisting just
+of slashes and spaces.
+
+Furthermore, certain error cases in arfile.cc and extracttar.cc have
+included member names in the output that were not checked at all and
+might hence not be nul terminated, leading to further out of bound reads.
+
+Fixes Debian/apt#111
+LP: #1878177
+
+CVE: CVE-2020-3810
+
+Upstream-Status: Backport:
+https://salsa.debian.org/apt-team/apt/-/commit/dceb1e49e4b8e4dadaf056be34088b415939cda6
+
+Signed-off-by: Davide Gardenal
+---
+apt-inst/contrib/arfile.cc | 11 ++-
+apt-inst/contrib/extracttar.cc | 2 +-
+.../test-github-111-invalid-armember | 88 +++
+ 3 files changed, 98 insertions(+), 3 deletions(-)
+ create mode 100755 test/integration/test-github-111-invalid-armember
+
+diff --git a/apt-inst/contrib/arfile.cc b/st/contrib/arfile.cc
+index 3fc3afedb..5cb43c690 100644
+--- a/apt-inst/contrib/arfile.cc
b/apt-inst/contrib/arfile.cc
+@@ -92,7 +92,7 @@ bool ARArchive::LoadHeaders()
+ StrToNum(Head.Size,Memb->Size,sizeof(Head.Size)) == false)
+ {
+delete Memb;
+- return _error->Error(_("Invalid archive member header %s"), Head.Name);
++ return _error->Error(_("Invalid archive member header"));
+ }
+
+ // Check for an extra long name string
+@@ -119,7 +119,14 @@ bool ARArchive::LoadHeaders()
+ else
+ {
+unsigned int I = sizeof(Head.Name) - 1;
+- for (; Head.Name[I] == ' ' || Head.Name[I] == '/'; I--);
++ for (; Head.Name[I] == ' ' || Head.Name[I] == '/'; I--)
++ {
++ if (I == 0)
++ {
++ delete Memb;
++ return _error->Error(_("Invalid archive member header"));
++ }
++ }
+Memb->Name = std::string(Head.Name,I+1);
+ }
+
+diff --git a/apt-inst/contrib/extracttar.cc b/apt-inst/contrib/extracttar.cc
+index 9bb0a55c0..b22f59dbc 100644
+--- a/apt-inst/contrib/extracttar.cc
b/apt-inst/contrib/extracttar.cc
+@@ -254,7 +254,7 @@ bool ExtractTar::Go(pkgDirStream )
+
+default:
+BadRecord = true;
+- _error->Warning(_("Unknown TAR header type %u, member
%s"),(unsigned)Tar->LinkFlag,Tar->Name);
++ _error->Warning(_("Unknown TAR header type %u"),
(unsigned)Tar->LinkFlag);
+break;
+ }
+
+diff --git a/test/integration/test-github-111-invalid-armember
b/test/integration/test-github-111-invalid-armember
+new file mode 100755
+index 0..ec2163bf6
+--- /dev/null
b/test/integration/test-github-111-invalid-armember
+@@ -0,0 +1,88 @@
++#!/bin/sh
++set -e
++
++TESTDIR="$(readlink -f "$(dirname "$0")")"
++. "$TESTDIR/framework"
++setupenvironment
++configarchitecture "amd64"
++setupaptarchive
++
++# this used to crash, but it should treat it as an invalid member header
++touch ' '
++ar -q test.deb ' '
++testsuccessequal "E: Invalid archive member header"
${BUILDDIRECTORY}/../test/interactive-helper/testdeb
Re: [OE-core] [dunfell][PATCH v2] qemu: backport patch fix for CVE-2020-13791
Understood, sorry I'm not yet very familiar, still learning. Thanks for the feedback! -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163614): https://lists.openembedded.org/g/openembedded-core/message/163614 Mute This Topic: https://lists.openembedded.org/mt/89996991/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 v2] qemu: backport patch fix for CVE-2020-13791
On Thu, Mar 24, 2022 at 1:32 AM Davide Gardenal
wrote:
>
> Upstream patch:
> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00979.html
>
> CVE: CVE-2020-13791
>
> Update v2: rebase with patch for CVE-2020-13253 and
> add Upstream-Status in patch description
Thanks for sending v2
In the future if you put the above version change note after the three
dashes below it will make life just a little bit easier for me.
When it is prior to the dashes I have to hand edit the patch to remove
the version notes, otherwise they will end up in the commit message.
No big deal either way, I appreciate the help with CVEs!
>
> Signed-off-by: Davide Gardenal
> ---
i.e. put version notes here!
> meta/recipes-devtools/qemu/qemu.inc | 1 +
> .../qemu/qemu/CVE-2020-13791.patch| 44 +++
> 2 files changed, 45 insertions(+)
> create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index 0bdc917783..25c2cdef3a 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -97,6 +97,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> file://CVE-2020-13253_3.patch \
> file://CVE-2020-13253_4.patch \
> file://CVE-2020-13253_5.patch \
> + file://CVE-2020-13791.patch \
> "
> UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>
> diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
> b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
> new file mode 100644
> index 00..1e8278f7b7
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
> @@ -0,0 +1,44 @@
> +Date: Thu, 4 Jun 2020 16:25:24 +0530
> +From: Prasad J Pandit
> +Subject: [PATCH v3] ati-vga: check address before reading
> configuration bytes (CVE-2020-13791)
> +
> +While reading PCI configuration bytes, a guest may send an
> +address towards the end of the configuration space. It may lead
> +to an OOB access issue. Add check to ensure 'address + size' is
> +within PCI configuration space.
> +
> +CVE: CVE-2020-13791
> +
> +Upstream-Status: Submitted
> +https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00979.html
> +
> +Reported-by: Ren Ding
> +Reported-by: Hanqing Zhao
> +Reported-by: Yi Ren
> +Suggested-by: BALATON Zoltan
> +Signed-off-by: Prasad J Pandit
> +Signed-off-by: Davide Gardenal
> +---
> + hw/display/ati.c | 4 +++-
> + 1 file changed, 3 insertions(+), 1 deletion(-)
> +
> +Update v3: avoid modifying 'addr' variable
> + -> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00834.html
> +
> +diff --git a/hw/display/ati.c b/hw/display/ati.c
> +index 67604e68de..b4d0fd88b7 100644
> +--- a/hw/display/ati.c
> b/hw/display/ati.c
> +@@ -387,7 +387,9 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
> unsigned int size)
> + val = s->regs.crtc_pitch;
> + break;
> + case 0xf00 ... 0xfff:
> +-val = pci_default_read_config(>dev, addr - 0xf00, size);
> ++if ((addr - 0xf00) + size <= pci_config_size(>dev)) {
> ++val = pci_default_read_config(>dev, addr - 0xf00, size);
> ++}
> + break;
> + case CUR_OFFSET:
> + val = s->regs.cur_offset;
> +--
> +2.26.2
> --
> 2.32.0
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163613):
https://lists.openembedded.org/g/openembedded-core/message/163613
Mute This Topic: https://lists.openembedded.org/mt/89996991/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] mobile-broadband-provider-info: update branch name
On Wed, Mar 23, 2022 at 11:45 PM Enguerrand de Ribaucourt
wrote:
>
> - Original Message -
> > From: "Alexandre Belloni"
> > To: "Enguerrand de Ribaucourt"
> >
> > Cc: openembedded-core@lists.openembedded.org
> > Sent: Wednesday, March 23, 2022 4:35:32 PM
> > Subject: Re: [OE-core][PATCH] mobile-broadband-provider-info: update branch
> > name
>
> > Hello Enguerrand,
>
> > This was already fixed in master in:
> > https://git.openembedded.org/openembedded-core/commit/?id=ed02ee8f20094f598448d58875cb7be8a24a019f
>
> > Is this for another branch?
>
> Hello Alexandre,
>
> Yes, this patch is for honister. The issue is also yet unfixed in the dunfell
> branch.
Also fixed in dunfell:
https://git.yoctoproject.org/poky/commit/?h=dunfell=08b8cd174d823eeccb1a505ac68e753f5eb4a43e
Steve
>
> Thank you for your time.
>
> > On 23/03/2022 09:50:10+0100, Enguerrand de Ribaucourt wrote:
> > > The master branch was renamed main, resulting in do_fetch failure.
> > > This patch updates SRC_URI with the new branch name.
>
> >> Signed-off-by: Enguerrand de Ribaucourt
> > >
> > > ---
> > > .../mobile-broadband-provider-info_git.bb | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> >> diff --git
> >> a/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > > b/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > > index 4246f4dcbd..3b170f4fdd 100644
> >> ---
> > > a/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> >> +++
> > > b/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > > @@ -8,7 +8,7 @@ SRCREV = "11f2247eccd3c161b8fd9b41143862e9fb81193c"
> > > PV = "20210805"
> > > PE = "1"
>
> >> -SRC_URI =
> > > "git://gitlab.gnome.org/GNOME/mobile-broadband-provider-info.git;protocol=https;branch=master"
> >> +SRC_URI =
> > > "git://gitlab.gnome.org/GNOME/mobile-broadband-provider-info.git;protocol=https;branch=main"
> > > S = "${WORKDIR}/git"
>
> > > inherit autotools
> > > --
> > > 2.25.1
>
>
>
> > >
>
>
> > --
> > 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 (#163612):
https://lists.openembedded.org/g/openembedded-core/message/163612
Mute This Topic: https://lists.openembedded.org/mt/89971498/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] perl: Add missing RDEPENDS
This allows quilt-ptest to work in an otherwise bare image. Without
this there are broken modules.
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/perl/files/perl-rdepends.txt | 4
meta/recipes-devtools/perl/perl_5.34.1.bb | 4
2 files changed, 8 insertions(+)
diff --git a/meta/recipes-devtools/perl/files/perl-rdepends.txt
b/meta/recipes-devtools/perl/files/perl-rdepends.txt
index 3415f32ab1f..74c24c3bb50 100644
--- a/meta/recipes-devtools/perl/files/perl-rdepends.txt
+++ b/meta/recipes-devtools/perl/files/perl-rdepends.txt
@@ -1,7 +1,11 @@
# Some additional dependencies that the above doesn't manage to figure out
RDEPENDS:perl-module-file-spec += "perl-module-file-spec-unix"
+RDEPENDS:perl-module-scalar-util += "perl-module-list-util"
+RDEPENDS:perl-module-file-temp += "perl-module-scalar-util"
+RDEPENDS:perl-module-file-temp += "perl-module-file-spec"
RDEPENDS:perl-module-io-file += "perl-module-symbol"
+RDEPENDS:perl-module-io-file += "perl-module-carp"
RDEPENDS:perl-module-math-bigint += "perl-module-math-bigint-calc"
RDEPENDS:perl-module-test-builder += "perl-module-list-util"
RDEPENDS:perl-module-test-builder += "perl-module-scalar-util"
diff --git a/meta/recipes-devtools/perl/perl_5.34.1.bb
b/meta/recipes-devtools/perl/perl_5.34.1.bb
index 608a42189bc..0e9d0c032eb 100644
--- a/meta/recipes-devtools/perl/perl_5.34.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.1.bb
@@ -355,7 +355,11 @@ do_create_rdepends_inc() {
# Some additional dependencies that the above doesn't manage to figure out
RDEPENDS:${PN}-module-file-spec += "${PN}-module-file-spec-unix"
+RDEPENDS:${PN}-module-scalar-util += "${PN}-module-list-util"
+RDEPENDS:${PN}-module-file-temp += "${PN}-module-scalar-util"
+RDEPENDS:${PN}-module-file-temp += "${PN}-module-file-spec"
RDEPENDS:${PN}-module-io-file += "${PN}-module-symbol"
+RDEPENDS:${PN}-module-io-file += "${PN}-module-carp"
RDEPENDS:${PN}-module-math-bigint += "${PN}-module-math-bigint-calc"
RDEPENDS:${PN}-module-test-builder += "${PN}-module-list-util"
RDEPENDS:${PN}-module-test-builder += "${PN}-module-scalar-util"
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163611):
https://lists.openembedded.org/g/openembedded-core/message/163611
Mute This Topic: https://lists.openembedded.org/mt/8336/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] qemu: Depend on libepoxy instead of virtual/libgl
On Thu, 2022-03-24 at 14:26 +0100, Alexandre Belloni via lists.openembedded.org
wrote:
> Hi Khem,
>
> On 23/03/2022 19:11:41-0700, Khem Raj wrote:
> > - This abstracts on GL/GLES implementations
> > - Rename packageconfig to epoxy to match what code it doing underneath
>
> This is not working either and I guess we will need to go and fix all
> the layers using the glx packageconfig:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3413
>
> >
> > Signed-off-by: Khem Raj
> > ---
> > v2: Rename packageconfig to epoxy as it matches code
> > v3: Depend on libepoxy instead of virtual/egl
> >
> > meta/recipes-devtools/qemu/qemu.inc | 6 +++---
> > meta/recipes-devtools/qemu/qemu_6.2.0.bb | 4 ++--
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc
> > b/meta/recipes-devtools/qemu/qemu.inc
> > index 78aea71cc05..e9d2dae0405 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -142,8 +142,8 @@ do_install:append() {
> > # END of qemu-mips workaround
> >
> > # Disable kvm/virgl/mesa on targets that do not support it
> > -PACKAGECONFIG:remove:darwin = "kvm virglrenderer glx gtk+"
> > -PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer glx gtk+"
> > +PACKAGECONFIG:remove:darwin = "kvm virglrenderer epoxy gtk+"
> > +PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer epoxy gtk+"
> >
> > PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,libsdl2"
> > PACKAGECONFIG[virtfs] = "--enable-virtfs --enable-attr
> > --enable-cap-ng,--disable-virtfs,libcap-ng attr,"
> > @@ -165,7 +165,7 @@ PACKAGECONFIG[nettle] =
> > "--enable-nettle,--disable-nettle,nettle"
> > PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
> > PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
> > PACKAGECONFIG[alsa] = "--audio-drv-list=default,,alsa-lib"
> > -PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
> > +PACKAGECONFIG[epoxy] = "--enable-opengl,--disable-opengl,libepoxy"
> > PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
> > PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
> > PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
> > diff --git a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> > b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> > index c7eef0a9d5e..92857adf9c3 100644
> > --- a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> > +++ b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> > @@ -17,9 +17,9 @@ EXTRA_OECONF:append:class-nativesdk = "
> > --target-list=${@get_qemu_target_list(d)
> > PACKAGECONFIG ??= " \
> > fdt sdl kvm pie \
> > ${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \
> > -${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx',
> > '', d)} \
> > +${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer
> > epoxy', '', d)} \
> > ${@bb.utils.filter('DISTRO_FEATURES', 'seccomp', d)} \
> > "
> > PACKAGECONFIG:class-nativesdk ??= "fdt sdl kvm pie \
> > -${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx',
> > '', d)} \
> > +${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer
> > epoxy', '', d)} \
> > "
> > --
> > 2.35.1
> >
I think there is a reference missed here:
qemu-system-native_6.0.0.bb:${@bb.utils.contains('DISTRO_FEATURES',
'opengl', 'virglrenderer glx', '', d)} \
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163610):
https://lists.openembedded.org/g/openembedded-core/message/163610
Mute This Topic: https://lists.openembedded.org/mt/89991450/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] qemu: Depend on libepoxy instead of virtual/libgl
Hi Khem,
On 23/03/2022 19:11:41-0700, Khem Raj wrote:
> - This abstracts on GL/GLES implementations
> - Rename packageconfig to epoxy to match what code it doing underneath
This is not working either and I guess we will need to go and fix all
the layers using the glx packageconfig:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/3413
>
> Signed-off-by: Khem Raj
> ---
> v2: Rename packageconfig to epoxy as it matches code
> v3: Depend on libepoxy instead of virtual/egl
>
> meta/recipes-devtools/qemu/qemu.inc | 6 +++---
> meta/recipes-devtools/qemu/qemu_6.2.0.bb | 4 ++--
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index 78aea71cc05..e9d2dae0405 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -142,8 +142,8 @@ do_install:append() {
> # END of qemu-mips workaround
>
> # Disable kvm/virgl/mesa on targets that do not support it
> -PACKAGECONFIG:remove:darwin = "kvm virglrenderer glx gtk+"
> -PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer glx gtk+"
> +PACKAGECONFIG:remove:darwin = "kvm virglrenderer epoxy gtk+"
> +PACKAGECONFIG:remove:mingw32 = "kvm virglrenderer epoxy gtk+"
>
> PACKAGECONFIG[sdl] = "--enable-sdl,--disable-sdl,libsdl2"
> PACKAGECONFIG[virtfs] = "--enable-virtfs --enable-attr
> --enable-cap-ng,--disable-virtfs,libcap-ng attr,"
> @@ -165,7 +165,7 @@ PACKAGECONFIG[nettle] =
> "--enable-nettle,--disable-nettle,nettle"
> PACKAGECONFIG[libusb] = "--enable-libusb,--disable-libusb,libusb1"
> PACKAGECONFIG[fdt] = "--enable-fdt,--disable-fdt,dtc"
> PACKAGECONFIG[alsa] = "--audio-drv-list=default,,alsa-lib"
> -PACKAGECONFIG[glx] = "--enable-opengl,--disable-opengl,virtual/libgl"
> +PACKAGECONFIG[epoxy] = "--enable-opengl,--disable-opengl,libepoxy"
> PACKAGECONFIG[lzo] = "--enable-lzo,--disable-lzo,lzo"
> PACKAGECONFIG[numa] = "--enable-numa,--disable-numa,numactl"
> PACKAGECONFIG[gnutls] = "--enable-gnutls,--disable-gnutls,gnutls"
> diff --git a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> index c7eef0a9d5e..92857adf9c3 100644
> --- a/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> +++ b/meta/recipes-devtools/qemu/qemu_6.2.0.bb
> @@ -17,9 +17,9 @@ EXTRA_OECONF:append:class-nativesdk = "
> --target-list=${@get_qemu_target_list(d)
> PACKAGECONFIG ??= " \
> fdt sdl kvm pie \
> ${@bb.utils.filter('DISTRO_FEATURES', 'alsa xen', d)} \
> -${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx',
> '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer epoxy',
> '', d)} \
> ${@bb.utils.filter('DISTRO_FEATURES', 'seccomp', d)} \
> "
> PACKAGECONFIG:class-nativesdk ??= "fdt sdl kvm pie \
> -${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer glx',
> '', d)} \
> +${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virglrenderer epoxy',
> '', d)} \
> "
> --
> 2.35.1
>
>
>
>
--
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 (#163609):
https://lists.openembedded.org/g/openembedded-core/message/163609
Mute This Topic: https://lists.openembedded.org/mt/89991450/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] packagegroup: Properly track the enabling of complementary packages
On Thu, 2022-03-24 at 12:41 +0100, Alban Bedel via lists.openembedded.org wrote:
> The set of packages included in a packagegroup depend on the
> PACKAGEGROUP_DISABLE_COMPLEMENTARY variable and, if that variable is
> not set to '1', on DISTRO_FEATURES. As this magic happen in a python
> function it can't be detected by the dependency system. We have to add
> these variables to the PACKAGEVARS list to have them added to the
> do_package vardeps list.
>
> Signed-off-by: Alban Bedel
> ---
> meta/classes/packagegroup.bbclass | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/classes/packagegroup.bbclass
> b/meta/classes/packagegroup.bbclass
> index 557b1b6382ba..cffdaadbde0e 100644
> --- a/meta/classes/packagegroup.bbclass
> +++ b/meta/classes/packagegroup.bbclass
> @@ -31,9 +31,11 @@ python () {
> packages = [pkg + suffix for pkg in packages
> for suffix in types]
> d.setVar('PACKAGES', ' '.join(packages))
> +d.appendVar('PACKAGEVARS', ' DISTRO_FEATURES')
> for pkg in packages:
> d.setVar('ALLOW_EMPTY:%s' % pkg, '1')
> }
> +PACKAGEVARS += 'PACKAGEGROUP_DISABLE_COMPLEMENTARY'
>
That is a hugely heavy hammer to apply to the problem. We go to quite some
lengths to try and ensure changing DISTRO_FEATURES doesn't cause things to
rebuild unless they need to (e.g. by using contains()).
PACKAGEVARS is also the wrong thing for use here as it is for variables which
have per package versions (like ALLOW_EMPTY). Put another way,
PACKAGEGROUP_DISABLE_COMPLEMENTARY:${PN}-dbg makes no sense.
PACKAGES[vardeps] += "PACKAGEGROUP_DISABLE_COMPLEMENTARY"
would be the correct way to handle the first part of this. For the distro
features piece, something like this:
PACKAGES += "${@bb.utils.contains('DISTRO_FEATURES', 'ptest', '', '', d)}"
might cause the dependencies to work correctly.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163608):
https://lists.openembedded.org/g/openembedded-core/message/163608
Mute This Topic: https://lists.openembedded.org/mt/89997103/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 v1 1/2] gpg-sign: Add parameters to gpg signature function
On Thu, 2022-03-24 at 12:23 +0100, Ferry Toth wrote: > > On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: > > > > > > I forgot to add a cover letter, sorry for that. The 2 patches together > > > implement DEB repository signing. > > > > > > This is necessary since Gatesgarth |apt| (1.8.2) has become more strict > > > and doesn’t allow unsigned repositories by default. > > > > > > It is possible to override this behavior |but||| is more work then to > > > enable signed DEB repositories. These patches makes DEB a first class > > > citizen as IPK and RPM. > > > > > > Patches have been in use in meta-intel-edison since Gatesgarth, see > > > https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb- > > > repository.html\ > > What puzzles me is that we can build root filesystems using apt, we test > > this on > > the autobuilder. Saying repositories are broken since gatesgarth therefore > > seems > > confusing in the commit message. > Good question. When I (meta-intel-edison) build the rootfs using DEB's it just > works. > Could it be that during rootfs build dpkg is used and not apt? I think I have > seen that in the logs. It definitely uses apt. > Of course apt uses dpkg to install a package as well, but it refuses to > download the package from a repo when it's not signed. Perhaps the difference is the packages are local and not remote? > > I guess we must configure apt to override that during the rootfs process and > > likely an end user with a remote feed could do the same, possibly with a > > warning > > from apt? > I believe there is no issue during rootfs generation. > > > I'm also worried that there isn't any automated testing of this change. The > > reason I worry is that since we don't show any testing failures right now, > > there > > is clearly a hole in our automated testing coverage and there is no > > guarantee > > that this feature will keep working. It is these smaller corner case issues > > which tend to make or break the project's experience as if a feature is > > present, > > people expect it to work. Can we improve the testing situation? > It doesn't seem to be a particularly volatile area in the code. I refreshed > Xavier's patches for Gatesgarth, and am actively using unchanged patch on > Honisiter. > I don't know how the automated testing is working but I guess for RPM a repo > is generated using a small layer? And then tested on a qemu running the > rootfs? > Should be almost same for deb/apt, maybe could be modified from rpm test? I think the rpm test is test_testimage_dnf in meta/lib/oeqa/selftest/cases/runtime_test.py. You'd run it with: oe-selftest -r runtime_test.TestImage.test_testimage_dnf > Point is: currently deb is documented as a feasible package format to generate > a repo. But it really is not without these signing patches. So we could either > deprecate deb's (no, no please don't) or fix it. > These patches fix it. With or without automated testing, it is already better > then the current situation. I'm not sure it is. The project gains yet another set of config options which we don't have tests for and the maintainer stress levels in trying to keep it all working just get worse. We have a huge number of ways people can configure the builds. The only way the project manages to keep all of this working is through automated testing, there is simply no other way to do it. I appreciate adding tests is a pain and nobody likes doing it. It does however let the project stay functional for everyone's diverse use cases. There are all kinds of patches I could take because the improve some corner case. In most cases we don't know what else they might break or whether that code continues to be used or stays working. I therefore do really want tests for new configurations. Who should write those tests? If you don't/can't as some actively using the feature, it means someone else has to, but who? I've not decided what to do with the patches to be honest but the merge and not bother with tests argument doesn't sit well with me. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163607): https://lists.openembedded.org/g/openembedded-core/message/163607 Mute This Topic: https://lists.openembedded.org/mt/89962631/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] packagegroup: Properly track the enabling of complementary packages
The set of packages included in a packagegroup depend on the
PACKAGEGROUP_DISABLE_COMPLEMENTARY variable and, if that variable is
not set to '1', on DISTRO_FEATURES. As this magic happen in a python
function it can't be detected by the dependency system. We have to add
these variables to the PACKAGEVARS list to have them added to the
do_package vardeps list.
Signed-off-by: Alban Bedel
---
meta/classes/packagegroup.bbclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/classes/packagegroup.bbclass
b/meta/classes/packagegroup.bbclass
index 557b1b6382ba..cffdaadbde0e 100644
--- a/meta/classes/packagegroup.bbclass
+++ b/meta/classes/packagegroup.bbclass
@@ -31,9 +31,11 @@ python () {
packages = [pkg + suffix for pkg in packages
for suffix in types]
d.setVar('PACKAGES', ' '.join(packages))
+d.appendVar('PACKAGEVARS', ' DISTRO_FEATURES')
for pkg in packages:
d.setVar('ALLOW_EMPTY:%s' % pkg, '1')
}
+PACKAGEVARS += 'PACKAGEGROUP_DISABLE_COMPLEMENTARY'
# We don't want to look at shared library dependencies for the
# dbg packages
--
2.32.0
smime.p7s
Description: S/MIME cryptographic signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163606):
https://lists.openembedded.org/g/openembedded-core/message/163606
Mute This Topic: https://lists.openembedded.org/mt/89997103/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][dunfell][PATCH v2] qemu: backport patch fix for CVE-2020-13791
Upstream patch:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00979.html
CVE: CVE-2020-13791
Update v2: rebase with patch for CVE-2020-13253 and
add Upstream-Status in patch description
Signed-off-by: Davide Gardenal
---
meta/recipes-devtools/qemu/qemu.inc | 1 +
.../qemu/qemu/CVE-2020-13791.patch| 44 +++
2 files changed, 45 insertions(+)
create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index 0bdc917783..25c2cdef3a 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -97,6 +97,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2020-13253_3.patch \
file://CVE-2020-13253_4.patch \
file://CVE-2020-13253_5.patch \
+ file://CVE-2020-13791.patch \
"
UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
new file mode 100644
index 00..1e8278f7b7
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2020-13791.patch
@@ -0,0 +1,44 @@
+Date: Thu, 4 Jun 2020 16:25:24 +0530
+From: Prasad J Pandit
+Subject: [PATCH v3] ati-vga: check address before reading configuration
bytes (CVE-2020-13791)
+
+While reading PCI configuration bytes, a guest may send an
+address towards the end of the configuration space. It may lead
+to an OOB access issue. Add check to ensure 'address + size' is
+within PCI configuration space.
+
+CVE: CVE-2020-13791
+
+Upstream-Status: Submitted
+https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00979.html
+
+Reported-by: Ren Ding
+Reported-by: Hanqing Zhao
+Reported-by: Yi Ren
+Suggested-by: BALATON Zoltan
+Signed-off-by: Prasad J Pandit
+Signed-off-by: Davide Gardenal
+---
+ hw/display/ati.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+Update v3: avoid modifying 'addr' variable
+ -> https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg00834.html
+
+diff --git a/hw/display/ati.c b/hw/display/ati.c
+index 67604e68de..b4d0fd88b7 100644
+--- a/hw/display/ati.c
b/hw/display/ati.c
+@@ -387,7 +387,9 @@ static uint64_t ati_mm_read(void *opaque, hwaddr addr,
unsigned int size)
+ val = s->regs.crtc_pitch;
+ break;
+ case 0xf00 ... 0xfff:
+-val = pci_default_read_config(>dev, addr - 0xf00, size);
++if ((addr - 0xf00) + size <= pci_config_size(>dev)) {
++val = pci_default_read_config(>dev, addr - 0xf00, size);
++}
+ break;
+ case CUR_OFFSET:
+ val = s->regs.cur_offset;
+--
+2.26.2
--
2.32.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163605):
https://lists.openembedded.org/g/openembedded-core/message/163605
Mute This Topic: https://lists.openembedded.org/mt/89996991/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 v1 1/2] gpg-sign: Add parameters to gpg signature function
Hi, Op 24-03-2022 om 09:12 schreef Richard Purdie: On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: Hi Richard, I forgot to add a cover letter, sorry for that. The 2 patches together implement DEB repository signing. This is necessary since Gatesgarth |apt| (1.8.2) has become more strict and doesn’t allow unsigned repositories by default. It is possible to override this behavior |but||| is more work then to enable signed DEB repositories. These patches makes DEB a first class citizen as IPK and RPM. Patches have been in use in meta-intel-edison since Gatesgarth, see https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb-repository.html\ What puzzles me is that we can build root filesystems using apt, we test this on the autobuilder. Saying repositories are broken since gatesgarth therefore seems confusing in the commit message. Good question. When I (meta-intel-edison) build the rootfs using DEB's it just works. Could it be that during rootfs build dpkg is used and not apt? I think I have seen that in the logs. Of course apt uses dpkg to install a package as well, but it refuses to download the package from a repo when it's not signed. I guess we must configure apt to override that during the rootfs process and likely an end user with a remote feed could do the same, possibly with a warning from apt? I believe there is no issue during rootfs generation. I'm also worried that there isn't any automated testing of this change. The reason I worry is that since we don't show any testing failures right now, there is clearly a hole in our automated testing coverage and there is no guarantee that this feature will keep working. It is these smaller corner case issues which tend to make or break the project's experience as if a feature is present, people expect it to work. Can we improve the testing situation? It doesn't seem to be a particularly volatile area in the code. I refreshed Xavier's patches for Gatesgarth, and am actively using unchanged patch on Honisiter. I don't know how the automated testing is working but I guess for RPM a repo is generated using a small layer? And then tested on a qemu running the rootfs? Should be almost same for deb/apt, maybe could be modified from rpm test? Point is: currently deb is documented as a feasible package format to generate a repo. But it really is not without these signing patches. So we could either deprecate deb's (no, no please don't) or fix it. These patches fix it. With or without automated testing, it is already better then the current situation. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163604): https://lists.openembedded.org/g/openembedded-core/message/163604 Mute This Topic: https://lists.openembedded.org/mt/89962631/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [honister][PATCH] crate-fetch: fix setscene failures
From: Richard Purdie
In sstate.bbclass, when fetching an sstate object we have:
pstaging_fetch(sstatefetch, d):
[...]
localdata.setVar('SRCPV', d.getVar('SRCPV'))
i.e. some code which expands SRCPV before it changes SRC_URI for the sstate
tarball fetching. In crate-fetch.bbclass we have:
def import_crate(d):
import crate
if not getattr(crate, 'imported', False):
bb.fetch2.methods.append(crate.Crate())
crate.imported = True
def crate_get_srcrev(d):
import_crate(d)
return bb.fetch2.get_srcrev(d)
SRCPV = "${@crate_get_srcrev(d)}"
and so an "import crate" occurs when pstating_fetch() is called. That succeeds
and all is well but the bb.fetch2.get_srcrev(d) call fails since there is no url
in SRC_URI which supports srcrev() resulting in:
| WARNING: rust-cross-core2-32-musl-1.54.0-r0
do_deploy_source_date_epoch_setscene: ExpansionError('SRCPV',
'${@crate_get_srcrev(d)}', FetchError('SRCREV was used yet no valid SCM was
found in SRC_URI', None))
| WARNING: Logfile for failed setscene task is
/home/pokybuild/yocto-worker/musl-qemux86/build/build/tmp/work/x86_64-linux/rust-cross-core2-32-musl/1.54.0-r0/temp/log.do_deploy_source_date_epoch_setscene.3133099
| WARNING: Setscene task
(/home/pokybuild/yocto-worker/musl-qemux86/build/meta/recipes-devtools/rust/rust-cross_1.54.0.bb:do_deploy_source_date_epoch_setscene)
failed with exit code '1' - real task will be run instead
Signed-off-by: Anuj Mittal
---
meta/classes/crate-fetch.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/crate-fetch.bbclass b/meta/classes/crate-fetch.bbclass
index a7fa22b2a0..04d76c0de8 100644
--- a/meta/classes/crate-fetch.bbclass
+++ b/meta/classes/crate-fetch.bbclass
@@ -22,6 +22,9 @@ crate_import_handler[eventmask] = "bb.event.RecipePreFinalise"
def crate_get_srcrev(d):
import_crate(d)
+srcuri = d.getVar("SRC_URI")
+if "crate://" not in srcuri and "git://" not in srcuri:
+return "Invalid"
return bb.fetch2.get_srcrev(d)
# Override SRCPV to make sure it imports the fetcher first
--
2.35.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#163603):
https://lists.openembedded.org/g/openembedded-core/message/163603
Mute This Topic: https://lists.openembedded.org/mt/89996581/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] mobile-broadband-provider-info: update branch name
- Original Message -
> From: "Alexandre Belloni"
> To: "Enguerrand de Ribaucourt"
> Cc: openembedded-core@lists.openembedded.org
> Sent: Wednesday, March 23, 2022 4:35:32 PM
> Subject: Re: [OE-core][PATCH] mobile-broadband-provider-info: update branch
> name
> Hello Enguerrand,
> This was already fixed in master in:
> https://git.openembedded.org/openembedded-core/commit/?id=ed02ee8f20094f598448d58875cb7be8a24a019f
> Is this for another branch?
Hello Alexandre,
Yes, this patch is for honister. The issue is also yet unfixed in the dunfell
branch.
Thank you for your time.
> On 23/03/2022 09:50:10+0100, Enguerrand de Ribaucourt wrote:
> > The master branch was renamed main, resulting in do_fetch failure.
> > This patch updates SRC_URI with the new branch name.
>> Signed-off-by: Enguerrand de Ribaucourt
> >
> > ---
> > .../mobile-broadband-provider-info_git.bb | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> diff --git
>> a/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > b/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > index 4246f4dcbd..3b170f4fdd 100644
>> ---
> > a/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
>> +++
> > b/meta/recipes-connectivity/mobile-broadband-provider-info/mobile-broadband-provider-info_git.bb
> > @@ -8,7 +8,7 @@ SRCREV = "11f2247eccd3c161b8fd9b41143862e9fb81193c"
> > PV = "20210805"
> > PE = "1"
>> -SRC_URI =
> > "git://gitlab.gnome.org/GNOME/mobile-broadband-provider-info.git;protocol=https;branch=master"
>> +SRC_URI =
> > "git://gitlab.gnome.org/GNOME/mobile-broadband-provider-info.git;protocol=https;branch=main"
> > S = "${WORKDIR}/git"
> > inherit autotools
> > --
> > 2.25.1
> >
> --
> 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 (#163602):
https://lists.openembedded.org/g/openembedded-core/message/163602
Mute This Topic: https://lists.openembedded.org/mt/89971498/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 v1 1/2] gpg-sign: Add parameters to gpg signature function
On Wed, 2022-03-23 at 19:34 +0100, Ferry Toth wrote: > Hi Richard, > > I forgot to add a cover letter, sorry for that. The 2 patches together > implement DEB repository signing. > > This is necessary since Gatesgarth |apt| (1.8.2) has become more strict > and doesn’t allow unsigned repositories by default. > > It is possible to override this behavior |but||| is more work then to > enable signed DEB repositories. These patches makes DEB a first class > citizen as IPK and RPM. > > Patches have been in use in meta-intel-edison since Gatesgarth, see > https://edison-fw.github.io/meta-intel-edison/5.0-Creating-a-deb-repository.html\ What puzzles me is that we can build root filesystems using apt, we test this on the autobuilder. Saying repositories are broken since gatesgarth therefore seems confusing in the commit message. I guess we must configure apt to override that during the rootfs process and likely an end user with a remote feed could do the same, possibly with a warning from apt? I'm also worried that there isn't any automated testing of this change. The reason I worry is that since we don't show any testing failures right now, there is clearly a hole in our automated testing coverage and there is no guarantee that this feature will keep working. It is these smaller corner case issues which tend to make or break the project's experience as if a feature is present, people expect it to work. Can we improve the testing situation? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#163601): https://lists.openembedded.org/g/openembedded-core/message/163601 Mute This Topic: https://lists.openembedded.org/mt/89962631/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
