Re: [m-c-s][PATCH] glusterfs: switch from distutils3 to setuptools3
Bruce Ashfield
merged.
toggle quoted messageShow quoted text
Bruce In message: [meta-virtualization][m-c-s][PATCH] glusterfs: switch from distutils3 to setuptools3 on 28/02/2022 Jeremy Puhlman wrote:
---
|
|
Re: [PATCH] xen-*image-minimal: Install *xen-acpi-processor package only for x86* machines
Bruce Ashfield
Looks fine to me, so we have some ARM servers that have the ACPI feature that
toggle quoted messageShow quoted text
are broken. I've queued it to master-next, and will wait a bit to hear frmo Christopher. Bruce In message: [meta-virtualization][PATCH] xen-*image-minimal: Install *xen-acpi-processor package only for x86* machines on 02/03/2022 Kamil Dziezyk wrote:
Kernel module xen_acpi_processor is built only for x86* architectures,
|
|
Re: [PATCH] python3-dtc: fix missing files in sysroot
Bruce Ashfield
queued to master-next along side of Tim's fixes.
toggle quoted messageShow quoted text
Bruce In message: [meta-virtualization] [PATCH] python3-dtc: fix missing files in sysroot on 01/03/2022 Ross Burton wrote:
There is a bug in SWIG/setuptools where 'pip install' doesn't build
|
|
Re: [PATCH 1/2] python3-dtc: fix wheel build
Bruce Ashfield
queued to master-next. I'm still seeing some issues on a couple of builders,
toggle quoted messageShow quoted text
but will take are of sorting that out. I'll push the changes when I've figured it out. Bruce In message: [meta-virtualization] [PATCH 1/2] python3-dtc: fix wheel build on 27/02/2022 Tim Orling wrote:
The wheel that is built is ${S}/dist/libfdt-1.6.2.dev39+g4048aed.d20220103-cp310-cp310-linux_x86_64.whl
|
|
[PATCH] xen-*image-minimal: Install *xen-acpi-processor package only for x86* machines
Kamil Dziezyk
Kernel module xen_acpi_processor is built only for x86* architectures,
therefore 'kernel-module-xen-acpi-processor' package is compatible only with x86* machines. Issue-Id: SCM-3892 Signed-off-by: Kamil Dziezyk <kamil.dziezyk@...> Change-Id: I8dde00e3c78a1f9eea50b19fbc1981f5e26df133 --- recipes-extended/images/xen-guest-image-minimal.bb | 6 +++++- recipes-extended/images/xen-image-minimal.bb | 5 ++++- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/recipes-extended/images/xen-guest-image-minimal.bb b/recipes-extended/images/xen-guest-image-minimal.bb index ca111b4..fced763 100644 --- a/recipes-extended/images/xen-guest-image-minimal.bb +++ b/recipes-extended/images/xen-guest-image-minimal.bb @@ -4,9 +4,13 @@ inherit core-image features_check IMAGE_INSTALL += " \ packagegroup-core-boot \ - ${@bb.utils.contains('MACHINE_FEATURES', 'acpi', 'kernel-module-xen-acpi-processor', '', d)} \ + ${@bb.utils.contains('MACHINE_FEATURES', 'acpi', '${XEN_ACPI_PROCESSOR_MODULE}', '', d)} \ " +XEN_ACPI_PROCESSOR_MODULE = "" +XEN_ACPI_PROCESSOR_MODULE:x86 = "kernel-module-xen-acpi-processor" +XEN_ACPI_PROCESSOR_MODULE:x86-64 = "kernel-module-xen-acpi-processor" + IMAGE_INSTALL += "${@bb.utils.contains('IMAGE_FEATURES', 'x11', ' xf86-video-fbdev', '', d)}" # Install xf86-video-vesa on x86 platforms. diff --git a/recipes-extended/images/xen-image-minimal.bb b/recipes-extended/images/xen-image-minimal.bb index ea596ce..f6fa5ed 100644 --- a/recipes-extended/images/xen-image-minimal.bb +++ b/recipes-extended/images/xen-image-minimal.bb @@ -5,7 +5,7 @@ INITRD_IMAGE = "core-image-minimal-initramfs" XEN_KERNEL_MODULES ?= "kernel-module-xen-blkback kernel-module-xen-gntalloc \ kernel-module-xen-gntdev kernel-module-xen-netback kernel-module-xen-wdt \ ${@bb.utils.contains('MACHINE_FEATURES', 'pci', "${XEN_PCIBACK_MODULE}", '', d)} \ - ${@bb.utils.contains('MACHINE_FEATURES', 'acpi', 'kernel-module-xen-acpi-processor', '', d)} \ + ${@bb.utils.contains('MACHINE_FEATURES', 'acpi', '${XEN_ACPI_PROCESSOR_MODULE}', '', d)} \ " IMAGE_INSTALL += " \ @@ -28,6 +28,9 @@ IMAGE_INSTALL:append:x86-64 = "kernel-module-tun" XEN_PCIBACK_MODULE = "" XEN_PCIBACK_MODULE:x86 = "kernel-module-xen-pciback" XEN_PCIBACK_MODULE:x86-64 = "kernel-module-xen-pciback" +XEN_ACPI_PROCESSOR_MODULE = "" +XEN_ACPI_PROCESSOR_MODULE:x86 = "kernel-module-xen-acpi-processor" +XEN_ACPI_PROCESSOR_MODULE:x86-64 = "kernel-module-xen-acpi-processor" LICENSE = "MIT" -- 2.17.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
[PATCH] python3-dtc: fix missing files in sysroot
Ross Burton <ross@...>
There is a bug in SWIG/setuptools where 'pip install' doesn't build
libfdt.py unless the build tree is already dirty, which makes using the library impossible. Bump the SRCREV to incorporate the upstream workaround for this issue. Signed-off-by: Ross Burton <ross.burton@...> --- recipes-kernel/dtc/python3-dtc_1.6.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-kernel/dtc/python3-dtc_1.6.1.bb b/recipes-kernel/dtc= /python3-dtc_1.6.1.bb index 671d280..a868bd0 100644 --- a/recipes-kernel/dtc/python3-dtc_1.6.1.bb +++ b/recipes-kernel/dtc/python3-dtc_1.6.1.bb @@ -14,7 +14,7 @@ UPSTREAM_CHECK_GITTAGREGEX =3D "v(?P<pver>\d+(\.\d+)+)" =20 LIC_FILES_CHKSUM =3D "file://pylibfdt/libfdt.i;beginline=3D1;endline=3D6= ;md5=3Dafda088c974174a29108c8d80b5dce90" =20 -SRCREV =3D "4048aed12b81c5a0154b9af438edc99ec7d2b6a1" +SRCREV =3D "c001fc01a43e7a06447c06ea3d50bd60641322b8" =20 PV =3D "1.6.1+git${SRCPV}" S =3D "${WORKDIR}/git" --=20 2.25.1
|
|
[m-c-s][PATCH] glusterfs: switch from distutils3 to setuptools3
---
recipes-extended/glusterfs/glusterfs.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-extended/glusterfs/glusterfs.inc b/recipes-extended/glusterfs/glusterfs.inc index 646b521f..5c960bca 100644 --- a/recipes-extended/glusterfs/glusterfs.inc +++ b/recipes-extended/glusterfs/glusterfs.inc @@ -27,7 +27,7 @@ LIC_FILES_CHKSUM = "file://COPYING-GPLV2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \ file://COPYING-LGPLV3;md5=e6a600fd5e1d9cbde2d983680233ad02 \ file://contrib/fuse-util/COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" -inherit autotools pkgconfig distutils3-base update-rc.d systemd +inherit autotools pkgconfig setuptools3-base update-rc.d systemd inherit python3-dir DEPENDS += "bison-native flex-native python3-native fuse libaio libtirpc libxml2 ncurses \ -- 2.24.1
|
|
[PATCH 2/2] lopper: fix wheel build
Tim Orling
The wheel that is built is:
lopper-1.0-py3-none-any.whl Set BASEVERSION to 1.0 and use this to set PV and the value for PYPA_WHEEL (the path to the wheel filename). Signed-off-by: Tim Orling <tim.orling@...> --- recipes-kernel/lopper/lopper_git.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/recipes-kernel/lopper/lopper_git.bb b/recipes-kernel/lopper/lopper_git.bb index 606dab6..e96bac7 100644 --- a/recipes-kernel/lopper/lopper_git.bb +++ b/recipes-kernel/lopper/lopper_git.bb @@ -7,7 +7,10 @@ SRC_URI = "git://github.com/devicetree-org/lopper.git;branch=master;protocol=htt SRCREV = "3c81fcce08eeb64cbbde1535abd83572985a8689" S = "${WORKDIR}/git" -PV="v1.0+git${SRCPV}" +BASEVERSION = "1.0" +PV="v${BASEVERSION}+git${SRCPV}" + +PYPA_WHEEL = "${PIP_INSTALL_DIST_PATH}/${BPN}-${BASEVERSION}-*.whl" LIC_FILES_CHKSUM = "file://LICENSE.md;md5=8e5f5f691f01c9fdfa7a7f2d535be619" -- 2.30.2
|
|
[PATCH 1/2] python3-dtc: fix wheel build
Tim Orling
The wheel that is built is ${S}/dist/libfdt-1.6.2.dev39+g4048aed.d20220103-cp310-cp310-linux_x86_64.whl
Set PYPA_WHEEL to match this. Signed-off-by: Tim Orling <tim.orling@...> --- recipes-kernel/dtc/python3-dtc_1.6.1.bb | 2 ++ 1 file changed, 2 insertions(+) diff --git a/recipes-kernel/dtc/python3-dtc_1.6.1.bb b/recipes-kernel/dtc/python3-dtc_1.6.1.bb index 449d071..671d280 100644 --- a/recipes-kernel/dtc/python3-dtc_1.6.1.bb +++ b/recipes-kernel/dtc/python3-dtc_1.6.1.bb @@ -19,6 +19,8 @@ SRCREV = "4048aed12b81c5a0154b9af438edc99ec7d2b6a1" PV = "1.6.1+git${SRCPV}" S = "${WORKDIR}/git" +PYPA_WHEEL = "${S}/dist/libfdt-1.6.2*.whl" + inherit setuptools3 pkgconfig BBCLASSEXTEND = "native nativesdk" -- 2.30.2
|
|
Re: [PATCH] xvisor: Remove bb.error when builing for non-supported arch
Bruce Ashfield
merged!
toggle quoted messageShow quoted text
Bruce In message: [meta-virtualization] [PATCH] xvisor: Remove bb.error when builing for non-supported arch on 15/02/2022 Kasper wrote:
From: Kasper Revsbech <kasper.revsbech.ext@...>
|
|
Re: [m-c-s][PATCH 1/2] librdmacm: update LICENSE variant
Bruce Ashfield
merged.
toggle quoted messageShow quoted text
Bruce In message: [meta-virtualization][m-c-s][PATCH 1/2] librdmacm: update LICENSE variant on 18/02/2022 Changqing Li wrote:
From: Changqing Li <changqing.li@...>
|
|
[m-c-s][PATCH 1/2] librdmacm: update LICENSE variant
Changqing Li
From: Changqing Li <changqing.li@...>
Fix warning: WARNING: QA Issue: librdmacm: No generic license file exists for: BSD in any provider [license-exists] Signed-off-by: Changqing Li <changqing.li@...> --- recipes-extended/librdmacm/librdmacm_1.1.0.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-extended/librdmacm/librdmacm_1.1.0.bb b/recipes-extended/librdmacm/librdmacm_1.1.0.bb index 2e18b0a9..a3271dfd 100644 --- a/recipes-extended/librdmacm/librdmacm_1.1.0.bb +++ b/recipes-extended/librdmacm/librdmacm_1.1.0.bb @@ -9,7 +9,7 @@ Also includes ACM (communication management assistant) service." HOMEPAGE = "http://www.openfabrics.org/downloads/rdmacm/" SECTION = "libs/devel" -LICENSE = "BSD" +LICENSE = "BSD-2-Clause | GPLv2" LIC_FILES_CHKSUM = "file://COPYING;md5=39cc3044d68741f9005da73e9b92db95" DEPENDS = "virtual/libibverbs" -- 2.25.1
|
|
[m-c-s][PATCH 2/2] celt051: update LICENSE variant
Changqing Li
From: Changqing Li <changqing.li@...>
fix warning: WARNING: QA Issue: celt051: No generic license file exists for: BSD in any provider [license-exists] Signed-off-by: Changqing Li <changqing.li@...> --- recipes-support/celt051/celt051_git.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-support/celt051/celt051_git.bb b/recipes-support/celt051/celt051_git.bb index 6eab5669..52c7cf38 100644 --- a/recipes-support/celt051/celt051_git.bb +++ b/recipes-support/celt051/celt051_git.bb @@ -9,7 +9,7 @@ with high quality. Unlike these formats CELT imposes very little delay \ on the signal, even less than is typical for speech centric formats \ like Speex, GSM, or G.729." -LICENSE = "BSD" +LICENSE = "BSD-2-Clause" LIC_FILES_CHKSUM = "file://COPYING;md5=375f60ab360d17f0172737036ff155b2" PV = "0.5.1.3" -- 2.25.1
|
|
Re: [PATCH] xvisor: Remove bb.error when builing for non-supported arch
Alistair Francis
On Wed, Feb 16, 2022 at 12:31 AM Kasper <kasper@...> wrote:
Reviewed-by: Alistair Francis <alistair.francis@...> Alistair ---
|
|
[PATCH] xvisor: Remove bb.error when builing for non-supported arch
Kasper
From: Kasper Revsbech <kasper.revsbech.ext@...>
Change bb.error to bb.note when getting config and arch of target/host as it is not an error if arch is not supported that should flag when parsing the recipe. It is an error if trying to include in image and that is already handled in COMPATIBLE_HOST Signed-off-by: Kasper Revsbech <kasper.revsbech.ext@...> --- recipes-extended/xvisor/xvisor-configs.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/recipes-extended/xvisor/xvisor-configs.inc b/recipes-extended/xvisor/xvisor-configs.inc index f53bba2..cd873cb 100644 --- a/recipes-extended/xvisor/xvisor-configs.inc +++ b/recipes-extended/xvisor/xvisor-configs.inc @@ -9,7 +9,7 @@ def get_oemake_config(a, d): elif re.match('riscv32(eb|)$', a): return 'generic-32b-defconfig' elif re.match('riscv64(eb|)$', a): return 'generic-64b-defconfig' else: - bb.error("cannot map '%s' to a Xvisor defconfig" % a) + bb.note("cannot map '%s' to a Xvisor defconfig" % a) def map_xvisor_arch(a, d): import re @@ -22,4 +22,4 @@ def map_xvisor_arch(a, d): elif re.match('aarch64_be_ilp32$', a): return 'arm' elif re.match('riscv(32|64|)(eb|)$', a): return 'riscv' else: - bb.error("cannot map '%s' to a Xvisor architecture" % a) + bb.note("cannot map '%s' to a Xvisor architecture" % a) -- 2.32.0
|
|
Re: [PATCH honister] k3s: uprev from v1.21.5+k3s1 to v1.21.9+k3s1
Bruce Ashfield
On Thu, Feb 10, 2022 at 3:05 AM Diego Sueiro <Diego.Sueiro@...> wrote:
It isn't appropriate for any branch, not just honister. It is covered in detail on both the OE core and OE architecture mailing list over the past year, to year and a half (with the latest being just recently). The summary is that we can't allow go to do the fetching in the compile phase, everything must be done in the fetch phase. And on top of that, there is a list of requirements around the fetching for it to be correct, and support all the OE features (offline building, licensing, reproducibility, etc). It is probably best summarized by this recent thread: https://lists.openembedded.org/g/openembedded-architecture/topic/88417908#1409 I'm working on a solution, and when something workable is ready, it can be used on honister, as well as master. Bruce I have no knowledge in Go both in aspects of the programming language as well -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
Re: [PATCH honister] k3s: uprev from v1.21.5+k3s1 to v1.21.9+k3s1
Diego Sueiro
Hi Bruce,
Can you please elaborate a bit better what the problem is and why this solution---"git://github.com/rancher/k3s.git;branch=release-1.21;name=k3s;protoco is not appropriate for the honister branch? I have no knowledge in Go both in aspects of the programming language as well as building. -- Diego Sueiro The solution isn't simple, since it is something that has to be generic, as it
|
|
Re: OCI images in yocto image
Bruce Ashfield
On Wed, Feb 9, 2022 at 1:29 PM Peter Bergin <peter@...> wrote:
There's no viable way to do this on the build side, and then have it appear in the image. I've experimented several times with this, and haven't found a decent solution. Running docker on the build host is a non-starter, which rules out many options. There's more options if you use podman versus docker for the container runtime, but I also haven't had time to finish anything there yet. To get the OCI images into docker, I bounce them through a registry and use docker pull. You can see the logs of that process in several of my yocto summit presentations. Nope, there's no drawbacks. The tar is just a convenience for moving the bundles around. It isn't an official OCI image format, just the unbundled directory format (it is just a bit odd compared to other image formats, which tend to be single files, so I created the tar step to be similar to them). You can definitely copy the OCI image directory onto the image, and have it be immediately runnable via runc. There's no common/defacto service to start the images on boot, but that's a fairly trivial thing to do with your init system of choice. (having a service to start those images on boot is on my TODO list, but I'm still tangled up with package uprev and golang, so I haven't gotten to it yet). Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
OCI images in yocto image
Peter Bergin
Hi,
I'm exploring the world of containers combined with Yocto. I can build a container image and bundle that one with my rootfs image. The container image is stored in the rootfs as a tar-file of a OCI image spec with the content blobs, index.json and oci-layout. As per the description in classes/image-oci.bbclass the way to run the container is to unpack the file and the create the OCI runtime bundle and start it with runc. I have played around with docker and tried to import OCI image directly in to docker store but have not succeeded. Anyone that knows if it is possible? 'docker image import <oci-image>.tar does not give any errors and the image shows up in 'docker images' but does not import the correct rootfs. When creating the OCI image in image-oci.bbclass the process starts with a bundle that is packaged as an image and compressed to a tar-file. Given the above the whole process needs to be reverted on target to start a container from that image. It should then be possible to just install the bundle directly on target rootfs that directly can be started with runc. Are there any drawbacks with this? I can see that a tar-file is easier to distribute and install afterwards but my question related to directly integrating an OCI-image to a Yocto rootfs-image. Best regards, /Peter
|
|
Re: [PATCH honister] k3s: uprev from v1.21.5+k3s1 to v1.21.9+k3s1
Bruce Ashfield
On Wed, Feb 9, 2022 at 10:32 AM Diego Sueiro <diego.sueiro@...> wrote:
Unfortunately .. no, we can't take this change. I'm working on a full update to k3s in master, and it is running into similar challenges due to the removal of vendor upstream. The solution isn't simple, since it is something that has to be generic, as it applies to many different recipes in meta-virtualization. Bruce ${GO} build -tags "$TAGS" -ldflags "${GO_BUILD_LDFLAGS} -w -s" -o ./dist/artifacts/k3s ./cmd/server/main.go -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|