Re: [OE-core] linux-yocto: Set CONFIG_ATA_PIIX=y by default
On 10/17/21 15:32, Bruce Ashfield wrote: On Sun, Oct 17, 2021 at 4:26 AM Jacob Kroon wrote: Hi Bruce and Saul, On 10/16/21 09:18, Jacob Kroon via lists.openembedded.org wrote: Hi Bruce, My Yocto images (which uses the linux-yocto kernel) stopped booting in QEMU some time ago, and after some debugging it turns out this was because the upstream Linux kernel removed the legacy IDE driver. Instead one should use the libata driver. However, I don't think the linux-yocto kernel has builtin support for the HW that is emulated by QEMU by default (PIIX), instead it is built as a module, CONFIG_ATA_PIIX=m. If I set CONFIG_ATA_PIIX=y, my images boot again. I did a "make ARCH=i386 defconfig" in Torvalds master linux tree, and the .config has CONFIG_ATA_PIIX=y. Do you think it would make sense to have the support builtin in linux-yocto aswell ? I'm using KMACHINE = "common-pc". CC:ing Saul Wold, since I see that commit 0d4f5ed5dca41a48423ce738131e52f7863d8ca6 in yocto-kernel-cache did: diff --git a/bsp/common-pc/common-pc-drivers.cfg b/bsp/common-pc/common-pc-drivers.cfg index 71608433..0b821903 100644 --- a/bsp/common-pc/common-pc-drivers.cfg +++ b/bsp/common-pc/common-pc-drivers.cfg @@ -5,7 +5,8 @@ CONFIG_PCI_MSI=y CONFIG_ATA=y CONFIG_ATA_ACPI=y CONFIG_ATA_SFF=y -CONFIG_ATA_PIIX=y +CONFIG_ATA_BMDMA=y +CONFIG_ATA_PIIX=m CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y which changed ATA_PIIX from a builtin to a module. Maybe this wasn't intentional ? It was definitely intentional. > We try and keep the configuration space of the targets as small as possible. In particular, this is exactly why qemux86* was created, so we wouldn't have to enable options in either the h/w targets or the emulated targets that are specific to a use case on one (and vice versa). That being said, they still actually do share the same machine definitions in the kernel-cache, since nothing significant has forced me to use that namespace split. qemux86 doesn't need PIIX out of the box to boot, and the Kconfig indicates "set it to N unless ...", and we do know the built-ins we want, so it is set to 'm' as a middle ground. When I start qemu-system-x86_64/qemu-system-i386 and type "info qtree" in the QEMU monitor (both version 5.2.0 and 6.1.0) I see "piix3-ide" for the IDE controller. Given that for older Yocto kernels the legacy IDE driver was builtin (CONFIG_BLK_DEV_PIIX=y), but is now removed in the kernel present on master, I'd figure ATA_PIIX=y would be required nowadays in order to get the kernels to boot in QEMU (since libata is replacing the old legacy IDE driver nowadays). That being said, it isn't out of the question to enable it (slippery slope to giant defconfig like beasts with everything and the kitchen sink enabled notwithstanding .. not that this is much of a step down that slope!) .. just let me ask a few more things first. Yeah, the only reason I'm asking is because I think I'm using default QEMU emulated hardware, and I'm sure we want a Yocto kernel to boot in default QEMU hardware. You say you are using KMACHINE='common-pc', that's good. But what else is at play ? What OE MACHINE are you building ? What image FStypes, etc ? It is a custom machine for https://www.compulab.com/products/computer-on-modules/cm-itc/ machine/cm-itc.conf: --- IMAGE_FSTYPES ?= "ext4" require conf/machine/include/x86/tune-i686.inc require conf/machine/include/x86/x86-base.inc PREFERRED_PROVIDER_virtual/bootloader = "grub-efi" --- I won't be able to do some build testing until Monday, but do you happen to have the qemu command lines (via runqemu) and machine definitions for qemux88 and your machine? I'd like to look at them and confirm exactly what image, and boot parameters are in play, since one boots and the other doesn't. I don't use the "runqemu"-script, I boot the images using Fedora 34 QEMU installation (QEMU version 5.2.0). Commandline is: qemu-system-x86_64 -m 1G -enable-kvm -nic user,hostfwd=tcp::10022-:22 -cpu n270 -bios /usr/share/edk2/ovmf-ia32/OVMF_CODE.fd -drive format=raw,file= I have the following bbappended in my yocto kernel recipe: KMACHINE:cm-itc ?= "common-pc" COMPATIBLE_MACHINE:cm-itc = "cm-itc" together with some custom kernel configuration. Regards Jacob -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157049): https://lists.openembedded.org/g/openembedded-core/message/157049 Mute This Topic: https://lists.openembedded.org/mt/86367293/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.4.rc1)
Hi All, This is the full report for yocto-3.4.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Jay > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Richard Purdie > Sent: Tuesday, 12 October, 2021 1:25 AM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notification > Subject: [qa-build-notification] QA notification for completed autobuilder > build > (yocto-3.4.rc1) > > A build flagged for QA (yocto-3.4.rc1) was completed on the autobuilder and is > available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.4.rc1 > > > Build hash information: > > bitbake: c78ebac71ec976fdf27ea24767057882870f5c60 > meta-agl: 228ecc1dec390138c44299d1c244acda9ad75ce1 > meta-arm: 98193f3b6167e07cbb794e96b80d78ca1779ea4f > meta-aws: 27bca81c4d3f0138fda583f9ea98df6152332333 > meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400 > meta-intel: 90170cf85fe35b4e8dc00eee50053c0205276b63 > meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8 > meta-openembedded: f2152d79043601eacb70da1a3ab36f5ac56f3e28 > oecore: bb1dea6806f084364b6017db2567f438e805aef0 > poky: f6d1126fff213460dc6954a5d5fc168606d76b66 > > > > 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 (#157048): https://lists.openembedded.org/g/openembedded-core/message/157048 Mute This Topic: https://lists.openembedded.org/mt/86280098/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 14/14] layer.conf: Extend recipes not to install without explict dependencies
On Fri, Oct 1, 2021 at 4:17 PM Martin Jansa wrote: > > FWIW: I've fixed some bigger layers where pkgconfig was causing quite a few > build failures, > Had an off-oe time due to heavy work load. Think this one is the reason for the pkgconfig patch flood. You are aware that there are packages not failing at build time for missing pkgconfig but build output is different and bugs will pop up at runtime. To avoid responsible maintainers have to go through EVERY recipe (and combination of PACKAGECONFIGs) and check if builds are still as expected - Can't believe it! Andreas -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157047): https://lists.openembedded.org/g/openembedded-core/message/157047 Mute This Topic: https://lists.openembedded.org/mt/85739636/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] bitbake: cooker: check if upstream hash equivalence server is available
Joshua Watt escreveu no dia sábado, 16/10/2021 à(s)
20:15:
>
>
> On Fri, Oct 15, 2021, 6:47 PM Jose Quaresma
> wrote:
>
>> When the user specify an upstream hash equivalence server in
>> BB_HASHSERVE_UPSTREAM abort if we can't connect otherwise the
>> user will never be notified about the problem.
>>
>> Signed-off-by: Jose Quaresma
>> ---
>> bitbake/lib/bb/cooker.py | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
>> index af794b4c42..34603c5ea2 100644
>> --- a/bitbake/lib/bb/cooker.py
>> +++ b/bitbake/lib/bb/cooker.py
>> @@ -388,12 +388,22 @@ class BBCooker:
>> # Create a new hash server bound to a unix domain socket
>> if not self.hashserv:
>> dbfile = (self.data.getVar("PERSISTENT_DIR") or
>> self.data.getVar("CACHE")) + "/hashserv.db"
>> +upstream = self.data.getVar("BB_HASHSERVE_UPSTREAM") or
>> None
>> +if upstream:
>> +import socket
>> +try:
>> +sock =
>> socket.create_connection(upstream.split(":"), 5)
>> +sock.close()
>> +except socket.error as e:
>> +bb.fatal("BB_HASHSERVE_UPSTREAM is not valid,
>> unable to connect hash equivalence server at '%s': %s"
>> + % (upstream, repr(e)))
>> +
>>
>
> Perhaps this should just be a warning? The upstream missing should not be
> fatal for a given server, if it is we probably need to fix that
>
In my opinion this needs to be fatal or fixed with a different approach.
If we launch bitbake in a clean build without build/cache with an invalid
server it will deadlock printing the follow message after several minutes:
WARNING: Error contacting Hash Equivalence Server
unix:///build/hashserve.sock: Connection closed
The build/bitbake-cookerdaemon.log have all the connections errors as well
as exceptions.
This cooker log is a bit ugly imho and I will try to improved it in a
follow up patch.
> self.hashservaddr = "unix://%s/hashserve.sock" %
>> self.data.getVar("TOPDIR")
>> self.hashserv = hashserv.create_server(
>> self.hashservaddr,
>> dbfile,
>> sync=False,
>> -upstream=self.data.getVar("BB_HASHSERVE_UPSTREAM")
>> or None,
>> +upstream=upstream,
>> )
>> self.hashserv.serve_as_process()
>> self.data.setVar("BB_HASHSERVE", self.hashservaddr)
>> --
>> 2.33.1
>>
>>
>>
>>
>>
--
Best regards,
José Quaresma
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157046):
https://lists.openembedded.org/g/openembedded-core/message/157046
Mute This Topic: https://lists.openembedded.org/mt/86362510/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] python3-packaging: BBCLASSEXTEND nativesdk
python3-setuptools-scm RDEPENDS on it for nativesdk
Fixes:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2766/steps/13/logs/warnings
Signed-off-by: Tim Orling
---
meta/recipes-devtools/python/python3-packaging_21.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/python/python3-packaging_21.0.bb
b/meta/recipes-devtools/python/python3-packaging_21.0.bb
index aef3ccae9a..f20f8886a4 100644
--- a/meta/recipes-devtools/python/python3-packaging_21.0.bb
+++ b/meta/recipes-devtools/python/python3-packaging_21.0.bb
@@ -7,7 +7,7 @@ SRC_URI[sha256sum] =
"7dc96269f53a4ccec5c0670940a4281106dd0bb343f47b7471f779df49
inherit pypi setuptools3
-BBCLASSEXTEND = "native"
+BBCLASSEXTEND = "native nativesdk"
DEPENDS += "${PYTHON_PN}-setuptools-native"
RDEPENDS:${PN} += "${PYTHON_PN}-pyparsing"
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157045):
https://lists.openembedded.org/g/openembedded-core/message/157045
Mute This Topic: https://lists.openembedded.org/mt/86399635/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OE-core CVE metrics for hardknott on Sun 17 Oct 2021 05:00:01 AM HST
Branch: hardknott New this week: 0 CVEs Removed this week: 0 CVEs Full list: Found 32 unpatched CVEs CVE-2013-0340: expat:expat-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0340 * CVE-2016-20012: openssh https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-20012 * CVE-2019-12067: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-12067 * CVE-2020-18974: nasm:nasm-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-18974 * CVE-2020-29623: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29623 * CVE-2020-35503: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 * CVE-2021-1765: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1765 * CVE-2021-1789: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1789 * CVE-2021-1799: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1799 * CVE-2021-1801: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1801 * CVE-2021-1870: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1870 * CVE-2021-20196: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20196 * CVE-2021-20255: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255 * CVE-2021-22922: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22922 * CVE-2021-22923: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22923 * CVE-2021-22945: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22945 * CVE-2021-22946: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22946 * CVE-2021-22947: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22947 * CVE-2021-31879: wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879 * CVE-2021-33833: connman https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33833 * CVE-2021-33928: libsolv https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33928 * CVE-2021-33929: libsolv https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33929 * CVE-2021-33930: libsolv https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33930 * CVE-2021-33938: libsolv https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-33938 * CVE-2021-3445: libdnf https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3445 * CVE-2021-3507: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3507 * CVE-2021-36976: libarchive https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-36976 * CVE-2021-3713: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3713 * CVE-2021-39537: ncurses:ncurses-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-39537 * CVE-2021-40491: inetutils https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-40491 * CVE-2021-40528: libgcrypt:libgcrypt-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-40528 * CVE-2021-41617: openssh https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-41617 * -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157044): https://lists.openembedded.org/g/openembedded-core/message/157044 Mute This Topic: https://lists.openembedded.org/mt/86392239/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] python3-smmap: update to 5.0.0
Signed-off-by: Oleksandr Kravchuk
---
meta/recipes-devtools/python/python3-smmap_4.0.0.bb | 3 ---
.../python/{python-smmap.inc => python3-smmap_5.0.0.bb} | 4 ++--
2 files changed, 2 insertions(+), 5 deletions(-)
delete mode 100644 meta/recipes-devtools/python/python3-smmap_4.0.0.bb
rename meta/recipes-devtools/python/{python-smmap.inc =>
python3-smmap_5.0.0.bb} (84%)
diff --git a/meta/recipes-devtools/python/python3-smmap_4.0.0.bb
b/meta/recipes-devtools/python/python3-smmap_4.0.0.bb
deleted file mode 100644
index 5f0f341d6a..00
--- a/meta/recipes-devtools/python/python3-smmap_4.0.0.bb
+++ /dev/null
@@ -1,3 +0,0 @@
-inherit setuptools3
-require python-smmap.inc
-
diff --git a/meta/recipes-devtools/python/python-smmap.inc
b/meta/recipes-devtools/python/python3-smmap_5.0.0.bb
similarity index 84%
rename from meta/recipes-devtools/python/python-smmap.inc
rename to meta/recipes-devtools/python/python3-smmap_5.0.0.bb
index 7d0cff5fa6..ea131ef793 100644
--- a/meta/recipes-devtools/python/python-smmap.inc
+++ b/meta/recipes-devtools/python/python3-smmap_5.0.0.bb
@@ -7,11 +7,11 @@ SECTION = "devel/python"
LICENSE = "BSD-3-Clause"
LIC_FILES_CHKSUM =
"file://PKG-INFO;beginline=8;endline=8;md5=e910b35b0ef4e1f665b9a75d6afb7709"
-inherit pypi
+inherit pypi setuptools3
PYPI_PACKAGE = "smmap"
-SRC_URI[sha256sum] =
"7e65386bd122d45405ddf795637b7f7d2b532e7e401d46bbe3fb49b9986d5182"
+SRC_URI[sha256sum] =
"c840e62059cd3be204b0c9c9f74be2c09d5648eddd4580d9314c3ecde0b30936"
RDEPENDS:${PN} += "${PYTHON_PN}-codecs \
${PYTHON_PN}-mmap \
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157043):
https://lists.openembedded.org/g/openembedded-core/message/157043
Mute This Topic: https://lists.openembedded.org/mt/86392142/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OE-core CVE metrics for dunfell on Sun 17 Oct 2021 04:30:01 AM HST
Branch: dunfell New this week: 0 CVEs Removed this week: 1 CVEs CVE-2020-21913: icu:icu-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-21913 * Full list: Found 74 unpatched CVEs CVE-2016-20012: openssh https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-20012 * CVE-2018-21232: re2c:re2c-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-21232 * CVE-2019-12067: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-12067 * CVE-2020-13253: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-13253 * CVE-2020-13754: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-13754 * CVE-2020-13791: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-13791 * CVE-2020-14372: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-14372 * CVE-2020-15469: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15469 * CVE-2020-15705: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15705 * CVE-2020-15859: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15859 * CVE-2020-15900: ghostscript-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-15900 * CVE-2020-16590: binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-16590 * CVE-2020-16591: binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-16591 * CVE-2020-16599: binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-16599 * CVE-2020-17380: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-17380 * CVE-2020-18974: nasm:nasm-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-18974 * CVE-2020-25632: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25632 * CVE-2020-25647: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25647 * CVE-2020-25742: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25742 * CVE-2020-25743: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-25743 * CVE-2020-27661: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27661 * CVE-2020-27749: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27749 * CVE-2020-27779: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27779 * CVE-2020-27821: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-27821 * CVE-2020-29510: go:go-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29510 * CVE-2020-29623: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29623 * CVE-2020-35503: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 * CVE-2020-35504: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35504 * CVE-2020-35505: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35505 * CVE-2020-35506: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35506 * CVE-2020-36254: dropbear https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-36254 * CVE-2020-3810: apt https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-3810 * CVE-2021-0129: bluez5 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-0129 * CVE-2021-1765: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1765 * CVE-2021-1789: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1789 * CVE-2021-1799: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1799 * CVE-2021-1801: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1801 * CVE-2021-1870: webkitgtk https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-1870 * CVE-2021-20225: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20225 * CVE-2021-20233: grub:grub-efi:grub-efi-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20233 * CVE-2021-20255: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255 * CVE-2021-20294: binutils:binutils-cross-testsuite:binutils-cross-x86_64:binutils-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20294 * CVE-2021-22897: curl:curl-native https://web.nvd.nist.gov/view/
Re: [OE-core] just want to confirm my understanding of how systemd services get symlinks
Hi Robert,
On Mon, Oct 4, 2021 at 8:02 PM Robert P. J. Day wrote:
>
>
> just had a discussion with a colleague about the proper design of a
> systemd-based service, and my (admittedly sophomore) understanding is
> that, in the service file, there is an [Install] section, which
> contains a "WantedBy" line like:
>
> fubar.service:WantedBy=sysinit.target
>
> upon installation in the image, from systemd.bbclass. the routine
> systemd_postinst() is invoked which (among other things), does this:
>
> if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> for service in ${SYSTEMD_SERVICE_ESCAPED}; do
> systemctl ${OPTS} enable "$service"
> done
> fi
>
> and my understanding is that it is that call to "systemctl" that
> creates the appropriate symlink so that that service now exists under
> the directory "sysinit.target.wants".
>
> my need for confirmation is based on muh collegaue's pointing at
> some existing systemd-based recipes in some legacy code, which
> manually do the following in do_install_append():
>
> ln -s ${sysconfdir}/systemd/system/fubar.service \
> ${D}/${sysconfdir}/systemd/system/sysinit.target.wants/
>
> i'm pretty sure that that "ln" command is unnecessary as long as the
> service file is defined properly, but now i just want to get that
> confirmed.
>
> rday
>
> p.s. hmm ... i wonder if the original recipe designer was unaware
> of systemd.bbclass and thought he had to do it all manually.
Correct, use an install section and systemd.bbclass and you do not
need to manually link into e.g. sysinit.target.wants. Do not forget to
set SYSTEMD_SERVICE, though.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-systemd
I think using the systemd.bbclass is more robust than the manual link.
Additionally, users of your recipe can use SYSTEMD_AUTO_ENABLE to
disable automatic start of the service during boot.
Cheers,
Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157041):
https://lists.openembedded.org/g/openembedded-core/message/157041
Mute This Topic: https://lists.openembedded.org/mt/86073990/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] OE-core CVE metrics for master on Sun 17 Oct 2021 04:00:01 AM HST
Branch: master New this week: 2 CVEs CVE-2021-3527: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3527 * CVE-2021-3682: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3682 * Removed this week: 6 CVEs CVE-2020-35503: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-35503 * CVE-2021-22945: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22945 * CVE-2021-22946: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22946 * CVE-2021-22947: curl:curl-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-22947 * CVE-2021-31879: wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879 * CVE-2021-3507: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3507 * Full list: Found 11 unpatched CVEs CVE-2016-20012: openssh https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-20012 * CVE-2019-12067: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-12067 * CVE-2020-18974: nasm:nasm-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-18974 * CVE-2021-20255: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255 * CVE-2021-3527: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3527 * CVE-2021-3682: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3682 * CVE-2021-36976: libarchive:libarchive-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-36976 * CVE-2021-3713: qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3713 * CVE-2021-3796: vim https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-3796 * CVE-2021-39537: ncurses:ncurses-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-39537 * CVE-2021-41617: openssh https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-41617 * -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157040): https://lists.openembedded.org/g/openembedded-core/message/157040 Mute This Topic: https://lists.openembedded.org/mt/86391255/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] linux-yocto: Set CONFIG_ATA_PIIX=y by default
On Sun, Oct 17, 2021 at 4:26 AM Jacob Kroon wrote: > > Hi Bruce and Saul, > > On 10/16/21 09:18, Jacob Kroon via lists.openembedded.org wrote: > > Hi Bruce, > > > > My Yocto images (which uses the linux-yocto kernel) stopped booting in > > QEMU some time ago, and after some debugging it turns out this was > > because the upstream Linux kernel removed the legacy IDE driver. Instead > > one should use the libata driver. However, I don't think the linux-yocto > > kernel has builtin support for the HW that is emulated by QEMU by > > default (PIIX), instead it is built as a module, CONFIG_ATA_PIIX=m. If I > > set CONFIG_ATA_PIIX=y, my images boot again. > > > > I did a "make ARCH=i386 defconfig" in Torvalds master linux tree, and > > the .config has CONFIG_ATA_PIIX=y. > > > > Do you think it would make sense to have the support builtin in > > linux-yocto aswell ? > > > > I'm using KMACHINE = "common-pc". CC:ing Saul Wold, since I see that > commit 0d4f5ed5dca41a48423ce738131e52f7863d8ca6 in yocto-kernel-cache did: > > > diff --git a/bsp/common-pc/common-pc-drivers.cfg > > b/bsp/common-pc/common-pc-drivers.cfg > > index 71608433..0b821903 100644 > > --- a/bsp/common-pc/common-pc-drivers.cfg > > +++ b/bsp/common-pc/common-pc-drivers.cfg > > @@ -5,7 +5,8 @@ CONFIG_PCI_MSI=y > > CONFIG_ATA=y > > CONFIG_ATA_ACPI=y > > CONFIG_ATA_SFF=y > > -CONFIG_ATA_PIIX=y > > +CONFIG_ATA_BMDMA=y > > +CONFIG_ATA_PIIX=m > > > > CONFIG_INPUT=y > > CONFIG_INPUT_MOUSEDEV=y > > which changed ATA_PIIX from a builtin to a module. Maybe this wasn't > intentional ? It was definitely intentional. We try and keep the configuration space of the targets as small as possible. In particular, this is exactly why qemux86* was created, so we wouldn't have to enable options in either the h/w targets or the emulated targets that are specific to a use case on one (and vice versa). That being said, they still actually do share the same machine definitions in the kernel-cache, since nothing significant has forced me to use that namespace split. qemux86 doesn't need PIIX out of the box to boot, and the Kconfig indicates "set it to N unless ...", and we do know the built-ins we want, so it is set to 'm' as a middle ground. That being said, it isn't out of the question to enable it (slippery slope to giant defconfig like beasts with everything and the kitchen sink enabled notwithstanding .. not that this is much of a step down that slope!) .. just let me ask a few more things first. You say you are using KMACHINE='common-pc', that's good. But what else is at play ? What OE MACHINE are you building ? What image FStypes, etc ? I won't be able to do some build testing until Monday, but do you happen to have the qemu command lines (via runqemu) and machine definitions for qemux88 and your machine? I'd like to look at them and confirm exactly what image, and boot parameters are in play, since one boots and the other doesn't. Cheers, Bruce > > Regards Jacob -- - 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 (#157039): https://lists.openembedded.org/g/openembedded-core/message/157039 Mute This Topic: https://lists.openembedded.org/mt/86367293/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] webkitgtk: add gperf-native to DEPENDS to fix build
On Sun, Oct 17, 2021 at 2:03 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Sun, 2021-10-17 at 13:57 +0200, Andreas Müller wrote: > > > Could NOT find Gperf (missing: GPERF_EXECUTABLE) (Required is at > least > > > version "3.0.1") > > > > Signed-off-by: Andreas Müller > > --- > > meta/recipes-sato/webkit/webkitgtk_2.34.0.bb | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > b/meta/recipes- > > sato/webkit/webkitgtk_2.34.0.bb > > index 25e1d422cc..a8e067147c 100644 > > --- a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > > +++ b/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > > @@ -32,6 +32,7 @@ CVE_PRODUCT = "webkitgtk webkitgtk\+" > > > > DEPENDS = " \ > >ruby-native \ > > + gperf-native \ > >cairo \ > >harfbuzz \ > >jpeg \ > > Out of interest, why are you seeing that and the automated testing isn't? > FWIW: I'm also seeing webkitgtk failures since last upgrade, but for me it isn't because of gperf, but: | CMake Error at Source/cmake/OptionsGTK.cmake:353 (message): | Either GLX or EGL is needed. | Call Stack (most recent call first): | Source/cmake/WebKitCommon.cmake:220 (include) | CMakeLists.txt:20 (include) possibly because the default setup in oe-core doesn't have opengl in DISTRO_FEATUES while all builds on autobuilder have opengl enabled with poky? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157038): https://lists.openembedded.org/g/openembedded-core/message/157038 Mute This Topic: https://lists.openembedded.org/mt/86389188/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] webkitgtk: add gperf-native to DEPENDS to fix build
On Sun, Oct 17, 2021 at 2:03 PM Richard Purdie wrote: > > On Sun, 2021-10-17 at 13:57 +0200, Andreas Müller wrote: > > > Could NOT find Gperf (missing: GPERF_EXECUTABLE) (Required is at least > > > version "3.0.1") > > > > Signed-off-by: Andreas Müller > > --- > > meta/recipes-sato/webkit/webkitgtk_2.34.0.bb | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb b/meta/recipes- > > sato/webkit/webkitgtk_2.34.0.bb > > index 25e1d422cc..a8e067147c 100644 > > --- a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > > +++ b/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > > @@ -32,6 +32,7 @@ CVE_PRODUCT = "webkitgtk webkitgtk\+" > > > > DEPENDS = " \ > >ruby-native \ > > + gperf-native \ > >cairo \ > >harfbuzz \ > >jpeg \ > > Out of interest, why are you seeing that and the automated testing isn't? > Asked myself same but did not find an answer. My build should use default PACKAGECONFIGs. Was off for a while so now pulled master (meta-openembedded master-next for mozjs upgrade) and started a build. Not helpful exactly - sorry... Andreas -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157037): https://lists.openembedded.org/g/openembedded-core/message/157037 Mute This Topic: https://lists.openembedded.org/mt/86389188/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] webkitgtk: add gperf-native to DEPENDS to fix build
On Sun, 2021-10-17 at 13:57 +0200, Andreas Müller wrote: > > Could NOT find Gperf (missing: GPERF_EXECUTABLE) (Required is at least > > version "3.0.1") > > Signed-off-by: Andreas Müller > --- > meta/recipes-sato/webkit/webkitgtk_2.34.0.bb | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb b/meta/recipes- > sato/webkit/webkitgtk_2.34.0.bb > index 25e1d422cc..a8e067147c 100644 > --- a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > +++ b/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb > @@ -32,6 +32,7 @@ CVE_PRODUCT = "webkitgtk webkitgtk\+" > > DEPENDS = " \ > ruby-native \ > + gperf-native \ > cairo \ > harfbuzz \ > jpeg \ Out of interest, why are you seeing that and the automated testing isn't? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157036): https://lists.openembedded.org/g/openembedded-core/message/157036 Mute This Topic: https://lists.openembedded.org/mt/86389188/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] webkitgtk: add gperf-native to DEPENDS to fix build
| Could NOT find Gperf (missing: GPERF_EXECUTABLE) (Required is at least | version "3.0.1") Signed-off-by: Andreas Müller --- meta/recipes-sato/webkit/webkitgtk_2.34.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb b/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb index 25e1d422cc..a8e067147c 100644 --- a/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb +++ b/meta/recipes-sato/webkit/webkitgtk_2.34.0.bb @@ -32,6 +32,7 @@ CVE_PRODUCT = "webkitgtk webkitgtk\+" DEPENDS = " \ ruby-native \ + gperf-native \ cairo \ harfbuzz \ jpeg \ -- 2.31.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157035): https://lists.openembedded.org/g/openembedded-core/message/157035 Mute This Topic: https://lists.openembedded.org/mt/86389188/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/3] python3-setuptools-scm: upgrade 6.0.1 -> 6.3.2
On Sun, 2021-10-17 at 01:41 +, Tim Orling wrote:
> RDEPENDS on python3-tomli instead of python3-toml
>
> Cleanup RDEPENDS (common vs. class-target)
>
> For changes, see:
> https://github.com/pypa/setuptools_scm/blob/main/CHANGELOG.rst#632
>
> Signed-off-by: Tim Orling
> ---
> ..._6.0.1.bb => python3-setuptools-scm_6.3.2.bb} | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
> rename meta/recipes-devtools/python/{python3-setuptools-scm_6.0.1.bb =>
> python3-setuptools-scm_6.3.2.bb} (73%)
>
> diff --git a/meta/recipes-devtools/python/python3-setuptools-scm_6.0.1.bb
> b/meta/recipes-devtools/python/python3-setuptools-scm_6.3.2.bb
> similarity index 73%
> rename from meta/recipes-devtools/python/python3-setuptools-scm_6.0.1.bb
> rename to meta/recipes-devtools/python/python3-setuptools-scm_6.3.2.bb
> index afbed17a2d..bc594d9620 100644
> --- a/meta/recipes-devtools/python/python3-setuptools-scm_6.0.1.bb
> +++ b/meta/recipes-devtools/python/python3-setuptools-scm_6.3.2.bb
> @@ -4,7 +4,7 @@ DESCRIPTION = "setuptools_scm handles managing your Python
> package versions in S
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://PKG-INFO;beginline=8;endline=8;md5=8227180126797a0148f94f483f3e1489"
>
> -SRC_URI[sha256sum] =
> "d1925a69cb07e9b29416a275b9fadb009a23c148ace905b2fb220649a6c18e92"
> +SRC_URI[sha256sum] =
> "a49aa8081eeb3514eb9728fa5040f2eaa962d6c6f4ec9c32f6c1fba88f88a0f2"
>
> PYPI_PACKAGE = "setuptools_scm"
> inherit pypi setuptools3
> @@ -12,15 +12,15 @@ inherit pypi setuptools3
> UPSTREAM_CHECK_REGEX = "setuptools_scm-(?P.*)\.tar"
>
> RDEPENDS:${PN} = "\
> -${PYTHON_PN}-debugger \
> -${PYTHON_PN}-json \
> -${PYTHON_PN}-py \
> +${PYTHON_PN}-packaging \
> +${PYTHON_PN}-pyparsing \
> ${PYTHON_PN}-setuptools \
> -${PYTHON_PN}-toml \
> +${PYTHON_PN}-tomli \
> "
> -RDEPENDS:${PN}:class-native = "\
> -${PYTHON_PN}-setuptools-native \
> -${PYTHON_PN}-toml-native \
> +
> +RDEPENDS:${PN}:append:class-target = " \
> +${PYTHON_PN}-debugger \
> +${PYTHON_PN}-json \
> "
>
> BBCLASSEXTEND = "native nativesdk"
I think python3-packaging needs a nativesdk BBCLASSEXTEND for this to work:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/2766/steps/13/logs/warnings
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157034):
https://lists.openembedded.org/g/openembedded-core/message/157034
Mute This Topic: https://lists.openembedded.org/mt/86383919/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] populate_sdk_base: add support for zstd compression (and default to it)
On Sat, 16 Oct 2021 at 21:21, Joshua Watt wrote: > > Is this the maximum compression level for zstd? Also, are any of these > using parallel compression? > Yes, they all run with the same standard cpu cores setting from bitbake.conf. xz additionally has a RAM cap. zstd has further compression levels, but I didn't try them - you're weclome to: --ultra : enable levels beyond 19, up to 22 (requires more memory) Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157033): https://lists.openembedded.org/g/openembedded-core/message/157033 Mute This Topic: https://lists.openembedded.org/mt/86353954/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 v5 1/2] lib/oe/qa,insane: Move extra error handling functions to library
On Fri, 2021-10-15 at 15:39 +0100, Mike Crowe via lists.openembedded.org wrote: > Extract package_qa_write_error, package_qa_handle_error and > package_qa_add_message functions from insane.bbclass to lib/oe/qa.py and > drop the package_qa_ prefixes. > > Update various bbclasses to use the new functions. No import is required > since base.bbclass puts oe.qa in OE_IMPORTS. > > Stop requiring callers to manually track whether a fatal error has been > encountered via a "sane" flag. Instead replace the QA_SANE variable with > QA_ERRORS_FOUND and call oe.qa.exit_if_errors or > oe.qa.exit_with_message_if_errors at the end of each task. > > Inspired by discussion resulting from > https://lists.openembedded.org/g/openembedded-core/message/156793 and > https://lists.openembedded.org/g/openembedded-core/message/156900 > > Signed-off-by: Mike Crowe > --- > meta/classes/buildhistory.bbclass | 3 +- > meta/classes/insane.bbclass | 180 -- > meta/classes/multilib.bbclass | 3 +- > meta/classes/package.bbclass | 26 ++--- > meta/classes/ptest.bbclass| 2 +- > meta/lib/oe/qa.py | 34 ++ > 6 files changed, 120 insertions(+), 128 deletions(-) There was an indentation issue with multilib.bbclass but I fixed that and now have merged this, thanks. I think you are right about there being legacy reasons for collecting up the messages and the "sane" variable tracking so if you are feeling keen (or anyone else is) further cleanup of this code is very welcome. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157032): https://lists.openembedded.org/g/openembedded-core/message/157032 Mute This Topic: https://lists.openembedded.org/mt/86340591/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] linux-yocto: Set CONFIG_ATA_PIIX=y by default
Hi Bruce and Saul, On 10/16/21 09:18, Jacob Kroon via lists.openembedded.org wrote: Hi Bruce, My Yocto images (which uses the linux-yocto kernel) stopped booting in QEMU some time ago, and after some debugging it turns out this was because the upstream Linux kernel removed the legacy IDE driver. Instead one should use the libata driver. However, I don't think the linux-yocto kernel has builtin support for the HW that is emulated by QEMU by default (PIIX), instead it is built as a module, CONFIG_ATA_PIIX=m. If I set CONFIG_ATA_PIIX=y, my images boot again. I did a "make ARCH=i386 defconfig" in Torvalds master linux tree, and the .config has CONFIG_ATA_PIIX=y. Do you think it would make sense to have the support builtin in linux-yocto aswell ? I'm using KMACHINE = "common-pc". CC:ing Saul Wold, since I see that commit 0d4f5ed5dca41a48423ce738131e52f7863d8ca6 in yocto-kernel-cache did: diff --git a/bsp/common-pc/common-pc-drivers.cfg b/bsp/common-pc/common-pc-drivers.cfg index 71608433..0b821903 100644 --- a/bsp/common-pc/common-pc-drivers.cfg +++ b/bsp/common-pc/common-pc-drivers.cfg @@ -5,7 +5,8 @@ CONFIG_PCI_MSI=y CONFIG_ATA=y CONFIG_ATA_ACPI=y CONFIG_ATA_SFF=y -CONFIG_ATA_PIIX=y +CONFIG_ATA_BMDMA=y +CONFIG_ATA_PIIX=m CONFIG_INPUT=y CONFIG_INPUT_MOUSEDEV=y which changed ATA_PIIX from a builtin to a module. Maybe this wasn't intentional ? Regards Jacob -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#157031): https://lists.openembedded.org/g/openembedded-core/message/157031 Mute This Topic: https://lists.openembedded.org/mt/86367293/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 5/5] overlayfs: add debug information
Signed-off-by: Vyacheslav Yurkov
---
meta/classes/overlayfs.bbclass | 6 ++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass
index 9397ab44f9..3c0f4dc882 100644
--- a/meta/classes/overlayfs.bbclass
+++ b/meta/classes/overlayfs.bbclass
@@ -92,9 +92,11 @@ WantedBy=local-fs.target
'LOWERDIR': lower,
}
+bb.debug(1, "Generate systemd unit %s" % mountUnitName(lower))
with open(os.path.join(d.getVar('WORKDIR'), mountUnitName(lower)),
'w') as f:
f.write(MountUnitTemplate.format(**args))
+bb.debug(1, "Generate helper systemd unit %s" % helperUnitName(lower))
with open(os.path.join(d.getVar('WORKDIR'), helperUnitName(lower)),
'w') as f:
f.write(CreateDirsUnitTemplate.format(**args))
@@ -105,13 +107,17 @@ WantedBy=local-fs.target
'PN': d.getVar('PN')
}
+bb.debug(1, "Generate systemd unit with all overlays %s" %
allOverlaysUnitName(d))
with open(os.path.join(d.getVar('WORKDIR'), allOverlaysUnitName(d)),
'w') as f:
f.write(AllOverlaysTemplate.format(**args))
mountUnitList = []
overlayMountPoints = d.getVarFlags("OVERLAYFS_MOUNT_POINT")
for mountPoint in overlayMountPoints:
+bb.debug(1, "Process variable flag %s" % mountPoint)
for lower in d.getVarFlag('OVERLAYFS_WRITABLE_PATHS',
mountPoint).split():
+bb.debug(1, "Prepare mount unit for %s with data mount point %s" %
+ (lower, d.getVarFlag('OVERLAYFS_MOUNT_POINT',
mountPoint)))
prepareUnits(d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint),
lower)
mountUnitList.append(mountUnitName(lower))
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157030):
https://lists.openembedded.org/g/openembedded-core/message/157030
Mute This Topic: https://lists.openembedded.org/mt/86386910/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/5] oeqa/selftest: extend overlayfs test
Test that overlayfs.bbclass generates one systemd unit, that
applications can set dependencies on, and that this unit mounts all
required overlays
Signed-off-by: Vyacheslav Yurkov
---
meta/lib/oeqa/selftest/cases/overlayfs.py | 42 +++
1 file changed, 42 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index f0c9860b48..84242a1605 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -149,15 +149,54 @@ WantedBy=multi-user.target
EOT
}
+"""
+
+overlayfs_recipe_append = """
+OVERLAYFS_WRITABLE_PATHS[mnt-overlay] += "/usr/share/another-overlay-mount"
+
+SYSTEMD_SERVICE:${PN} += " \
+my-application.service \
+"
+
+do_install:append() {
+install -d ${D}${systemd_system_unitdir}
+cat < ${D}${systemd_system_unitdir}/my-application.service
+[Unit]
+Description=Sample application start-up unit
+After=overlayfs-user-overlays.service
+Requires=overlayfs-user-overlays.service
+
+[Service]
+Type=oneshot
+ExecStart=/bin/true
+RemainAfterExit=true
+
+[Install]
+WantedBy=multi-user.target
+EOT
+}
"""
self.write_config(config)
self.add_overlay_conf_to_machine()
self.write_recipeinc('systemd-machine-units',
systemd_machine_unit_append)
+self.write_recipeinc('overlayfs-user', overlayfs_recipe_append)
bitbake('core-image-minimal')
with runqemu('core-image-minimal') as qemu:
+# Check that application service started
+status, output = qemu.run_serial("systemctl status my-application")
+self.assertTrue("active (exited)" in output, msg=output)
+
+# Check that overlay mounts are dependencies of our application
unit
+status, output = qemu.run_serial("systemctl list-dependencies
my-application")
+self.assertTrue("overlayfs-user-overlays.service" in output,
msg=output)
+
+status, output = qemu.run_serial("systemctl list-dependencies
overlayfs-user-overlays")
+self.assertTrue("usr-share-another\\x2doverlay\\x2dmount.mount" in
output, msg=output)
+self.assertTrue("usr-share-my\\x2dapplication.mount" in output,
msg=output)
+
# Check that we have /mnt/overlay fs mounted as tmpfs and
# /usr/share/my-application as an overlay (see overlayfs-user
recipe)
status, output = qemu.run_serial("/bin/mount -t tmpfs,overlay")
@@ -167,3 +206,6 @@ EOT
line = self.getline_qemu(output,
"upperdir=/mnt/overlay/upper/usr/share/my-application")
self.assertTrue(line and line.startswith("overlay"), msg=output)
+
+line = self.getline_qemu(output,
"upperdir=/mnt/overlay/upper/usr/share/another-overlay-mount")
+self.assertTrue(line and line.startswith("overlay"), msg=output)
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157029):
https://lists.openembedded.org/g/openembedded-core/message/157029
Mute This Topic: https://lists.openembedded.org/mt/86386909/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 3/5] overlayfs: meta-selftest recipe fix
Avoid strict assignment in the recipe to allow overrides in .inc file
Signed-off-by: Vyacheslav Yurkov
---
meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb
b/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb
index 60405067de..913a4d1fdb 100644
--- a/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb
+++ b/meta-selftest/recipes-test/overlayfs-user/overlayfs-user.bb
@@ -8,7 +8,7 @@ EXCLUDE_FROM_WORLD = "1"
inherit ${@bb.utils.contains("DISTRO_FEATURES", "overlayfs", "overlayfs", "",
d)}
include test_recipe.inc
-OVERLAYFS_WRITABLE_PATHS[mnt-overlay] = "/usr/share/my-application"
+OVERLAYFS_WRITABLE_PATHS[mnt-overlay] += "/usr/share/my-application"
do_install() {
install -d ${D}/usr/share/my-application
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157028):
https://lists.openembedded.org/g/openembedded-core/message/157028
Mute This Topic: https://lists.openembedded.org/mt/86386908/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/5] overlayfs: all overlays unit
Application can depend on several overlayfs mount points. Provide a
systemd unit application can depend on to make sure all overlays are
mounted before it is started to avoid any race conditions
Signed-off-by: Bruno Knittel
Signed-off-by: Vyacheslav Yurkov
---
meta/classes/overlayfs.bbclass | 36 --
meta/lib/oe/overlayfs.py | 5 +
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/meta/classes/overlayfs.bbclass b/meta/classes/overlayfs.bbclass
index 8d9b59c9bf..9397ab44f9 100644
--- a/meta/classes/overlayfs.bbclass
+++ b/meta/classes/overlayfs.bbclass
@@ -37,6 +37,8 @@ REQUIRED_DISTRO_FEATURES += "systemd overlayfs"
inherit systemd features_check
python do_create_overlayfs_units() {
+from oe.overlayfs import mountUnitName
+
CreateDirsUnitTemplate = """[Unit]
Description=Overlayfs directories setup
Requires={DATA_MOUNT_UNIT}
@@ -65,10 +67,23 @@
Options=lowerdir={LOWERDIR},upperdir={DATA_MOUNT_POINT}/upper{LOWERDIR},workdir=
[Install]
WantedBy=multi-user.target
+"""
+AllOverlaysTemplate = """[Unit]
+Description=Groups all overlays required by {PN} in one unit
+After={ALL_OVERLAYFS_UNITS}
+Requires={ALL_OVERLAYFS_UNITS}
+
+[Service]
+Type=oneshot
+ExecStart=/bin/true
+RemainAfterExit=true
+
+[Install]
+WantedBy=local-fs.target
"""
def prepareUnits(data, lower):
-from oe.overlayfs import mountUnitName, helperUnitName
+from oe.overlayfs import helperUnitName
args = {
'DATA_MOUNT_POINT': data,
@@ -83,10 +98,27 @@ WantedBy=multi-user.target
with open(os.path.join(d.getVar('WORKDIR'), helperUnitName(lower)),
'w') as f:
f.write(CreateDirsUnitTemplate.format(**args))
+def prepareGlobalUnit(dependentUnits):
+from oe.overlayfs import allOverlaysUnitName
+args = {
+'ALL_OVERLAYFS_UNITS': " ".join(dependentUnits),
+'PN': d.getVar('PN')
+}
+
+with open(os.path.join(d.getVar('WORKDIR'), allOverlaysUnitName(d)),
'w') as f:
+f.write(AllOverlaysTemplate.format(**args))
+
+mountUnitList = []
overlayMountPoints = d.getVarFlags("OVERLAYFS_MOUNT_POINT")
for mountPoint in overlayMountPoints:
for lower in d.getVarFlag('OVERLAYFS_WRITABLE_PATHS',
mountPoint).split():
prepareUnits(d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint),
lower)
+mountUnitList.append(mountUnitName(lower))
+
+# set up one unit, which depends on all mount units, so users can set
+# only one dependency in their units to make sure software starts
+# when all overlays are mounted
+prepareGlobalUnit(mountUnitList)
}
# we need to generate file names early during parsing stage
@@ -95,7 +127,7 @@ python () {
unitList = unitFileList(d)
for unit in unitList:
-d.appendVar('SYSTEMD_SERVICE:' + d.getVar('PN'), ' ' + unit);
+d.appendVar('SYSTEMD_SERVICE:' + d.getVar('PN'), ' ' + unit)
d.appendVar('FILES:' + d.getVar('PN'), ' ' + strForBash(unit))
d.setVar('OVERLAYFS_UNIT_LIST', ' '.join([strForBash(s) for s in
unitList]))
diff --git a/meta/lib/oe/overlayfs.py b/meta/lib/oe/overlayfs.py
index 21ef710509..b5d5e88e80 100644
--- a/meta/lib/oe/overlayfs.py
+++ b/meta/lib/oe/overlayfs.py
@@ -15,6 +15,9 @@ def escapeSystemdUnitName(path):
def strForBash(s):
return s.replace('\\', '')
+def allOverlaysUnitName(d):
+return d.getVar('PN') + '-overlays.service'
+
def mountUnitName(unit):
return escapeSystemdUnitName(unit) + '.mount'
@@ -39,5 +42,7 @@ def unitFileList(d):
fileList.append(mountUnitName(path))
fileList.append(helperUnitName(path))
+fileList.append(allOverlaysUnitName(d))
+
return fileList
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157026):
https://lists.openembedded.org/g/openembedded-core/message/157026
Mute This Topic: https://lists.openembedded.org/mt/86386906/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/5] oeqa/selftest: refactor common functions
Signed-off-by: Vyacheslav Yurkov
---
meta/lib/oeqa/selftest/cases/overlayfs.py | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index 0184d52494..f0c9860b48 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -8,11 +8,14 @@ from oeqa.utils.commands import runCmd, bitbake, get_bb_var,
runqemu
class OverlayFSTests(OESelftestTestCase):
"""Overlayfs class usage tests"""
-def getline(self, res, line):
-for l in res.output.split('\n'):
+def getline_qemu(self, out, line):
+for l in out.split('\n'):
if line in l:
return l
+def getline(self, res, line):
+return self.getline_qemu(res.output, line)
+
def add_overlay_conf_to_machine(self):
machine_inc = """
OVERLAYFS_MOUNT_POINT[mnt-overlay] = "/mnt/overlay"
@@ -154,18 +157,13 @@ EOT
bitbake('core-image-minimal')
-def getline_qemu(out, line):
-for l in out.split('\n'):
-if line in l:
-return l
-
with runqemu('core-image-minimal') as qemu:
# Check that we have /mnt/overlay fs mounted as tmpfs and
# /usr/share/my-application as an overlay (see overlayfs-user
recipe)
status, output = qemu.run_serial("/bin/mount -t tmpfs,overlay")
-line = getline_qemu(output, "on /mnt/overlay")
+line = self.getline_qemu(output, "on /mnt/overlay")
self.assertTrue(line and line.startswith("tmpfs"), msg=output)
-line = getline_qemu(output,
"upperdir=/mnt/overlay/upper/usr/share/my-application")
+line = self.getline_qemu(output,
"upperdir=/mnt/overlay/upper/usr/share/my-application")
self.assertTrue(line and line.startswith("overlay"), msg=output)
--
2.28.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157027):
https://lists.openembedded.org/g/openembedded-core/message/157027
Mute This Topic: https://lists.openembedded.org/mt/86386907/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
