* [PATCH 0/2] Rework deployment of image artifacts
@ 2026-04-10 13:22 'Felix Moessbauer' via isar-users
2026-04-10 13:22 ` [PATCH 1/2] Revert "meta: Deploy image build artifacts into distro- and image-specific subdirs" 'Felix Moessbauer' via isar-users
` (3 more replies)
0 siblings, 4 replies; 18+ messages in thread
From: 'Felix Moessbauer' via isar-users @ 2026-04-10 13:22 UTC (permalink / raw)
To: isar-users; +Cc: wzh, jan.kiszka, quirin.gylstorff, Felix Moessbauer
As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally
incompatible with custom initrd recipes, this patch was reverted,
re-introducing the do_copy_boot_files error on DTBs that are named
equally but belong to different mc targets.
This series mitigate the issue by keeping the layout of DEPLOY_DIR_IMAGE,
but prefixing the DTB_FILES with PN and DISTRO. These prefixes are
then stripped again during imaging.
Note, that the series has been CI tested against the "dtbdeploy" and "dev"
tags.
Best regards,
Felix Moessbauer
Siemens AG
Felix Moessbauer (2):
Revert "meta: Deploy image build artifacts into distro- and
image-specific subdirs"
prefix DTB files with PN in deploy dir
RECIPE-API-CHANGELOG.md | 84 +++----------------
.../installer-add-rootfs.bbclass | 9 +-
meta/classes-recipe/image.bbclass | 17 ++--
.../imagetypes_container.bbclass | 2 +-
meta/classes-recipe/imagetypes_wic.bbclass | 2 +-
meta/conf/bitbake.conf | 3 +-
.../wic/plugins/source/bootimg-efi-isar.py | 3 +-
.../plugins/source/isoimage-isohybrid-isar.py | 2 +-
testsuite/cibase.py | 2 +-
testsuite/citest.py | 7 +-
testsuite/start_vm.py | 2 +-
11 files changed, 36 insertions(+), 97 deletions(-)
--
2.53.0
--
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260410132250.3320171-1-felix.moessbauer%40siemens.com.
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 1/2] Revert "meta: Deploy image build artifacts into distro- and image-specific subdirs" 2026-04-10 13:22 [PATCH 0/2] Rework deployment of image artifacts 'Felix Moessbauer' via isar-users @ 2026-04-10 13:22 ` 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 2/2] prefix DTB files with PN in deploy dir 'Felix Moessbauer' via isar-users ` (2 subsequent siblings) 3 siblings, 0 replies; 18+ messages in thread From: 'Felix Moessbauer' via isar-users @ 2026-04-10 13:22 UTC (permalink / raw) To: isar-users; +Cc: wzh, jan.kiszka, quirin.gylstorff, Felix Moessbauer This reverts commit 13cb77dd04614b655499bbb6d2b88b96718634cd. As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally incompatible with custom initrd recipes, this patch was reverted, re-introducing the do_copy_boot_files error on DTBs that are named equally but belong to different mc targets. Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> --- RECIPE-API-CHANGELOG.md | 80 ------------------- .../installer-add-rootfs.bbclass | 9 +-- meta/classes-recipe/image.bbclass | 11 ++- .../imagetypes_container.bbclass | 2 +- meta/conf/bitbake.conf | 3 +- .../plugins/source/isoimage-isohybrid-isar.py | 2 +- testsuite/cibase.py | 2 +- testsuite/citest.py | 7 +- testsuite/start_vm.py | 2 +- 9 files changed, 17 insertions(+), 101 deletions(-) diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md index c5962969..0e6a3172 100644 --- a/RECIPE-API-CHANGELOG.md +++ b/RECIPE-API-CHANGELOG.md @@ -981,83 +981,3 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as part of a repository, a tarball, or some other directory structure, just specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. - -### Change DEPLOY_DIR_IMAGE path and artifacts naming - -Change DEPLOY_DIR_IMAGE from ${DEPLOY_DIR}/images/${MACHINE} to -${DEPLOY_DIR}/images/${MACHINE}/${DISTRO}-${IMAGE_PN}. - -When building different distros with the same machine the following -error occurs: - -do_copy_boot_files: The recipe isar-image-base is trying to install -files into a shared area when those files already exists. It happens -when some files have the same names (e.g., dtb files) for different -distros. - -To prevent such collisions, image artifacts are now deployed into a -distro- and image-specific subdirectory. - -Additionally, artifact filenames have been shortened by removing the -${DISTRO} and ${IMAGE_PN} prefix, since this information is now -encoded in the directory path. - -Example 1: Build isar-image-base (phyboard-mira, debian-bookworm) -Under "build/tmp/deploy/images/": -Before: -phyboard-mira/imx6q-phytec-mira-rdk-nand.dtb -phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-initrd.img -phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira-vmlinuz -phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira.dpkg_status -phyboard-mira/isar-image-base-debian-bookworm-phyboard-mira.ubi - -After: -phyboard-mira/debian-bookworm-isar-image-base/imx6q-phytec-mira-rdk-nand.dtb -phyboard-mira/debian-bookworm-isar-image-base/initrd.img -phyboard-mira/debian-bookworm-isar-image-base/vmlinuz -phyboard-mira/debian-bookworm-isar-image-base/phyboard-mira.dpkg_status -phyboard-mira/debian-bookworm-isar-image-base/phyboard-mira.ubi - -Example 2: Build isar-image-ci (qemuamd64, debian-bookworm) -Under "build/tmp/deploy/images/": -Before: -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64-initrd.img -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64-vmlinuz -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64.dpkg_status -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64.manifest -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64.wic -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64.wic.bmap -qemuamd64/isar-image-ci-debian-bookworm-qemuamd64.wic.manifest - -After: -qemuamd64/debian-bookworm-isar-image-ci/initrd.img -qemuamd64/debian-bookworm-isar-image-ci/vmlinuz -qemuamd64/debian-bookworm-isar-image-ci/qemuamd64.dpkg_status -qemuamd64/debian-bookworm-isar-image-ci/qemuamd64.manifest -qemuamd64/debian-bookworm-isar-image-ci/qemuamd64.wic -qemuamd64/debian-bookworm-isar-image-ci/qemuamd64.wic.bmap -qemuamd64/debian-bookworm-isar-image-ci/qemuamd64.wic.manifest - -Artifacts that do not belong to a full image (e.g. isar-image-base, -isar-image-ci) remain unchanged. For example, a customized initramfs -built independently is not affected. - -This change affects the location and naming of build artifacts and must -be taken into account by downstream users. - -Note that this approach differs from OpenEmbedded. - -OpenEmbedded typically avoids artifact collisions in multiconfig builds -by using separate TMPDIRs per configuration, resulting in multiple -build directories such as tmp-qemuarm64 and tmp-qemuarm64customized. In -this model, artifacts with identical names but different contents do -not cause conflicts because they reside in their own isolated build -directories. - -If multiple configurations are intentionally configured to share the -same TMPDIR in OpenEmbedded, conflicts may occur and are not handled by -OE. Artifacts with the same name overwrite each other, leading to -incorrect build results. - -Changes in next ---------------- diff --git a/meta-isar/classes-recipe/installer-add-rootfs.bbclass b/meta-isar/classes-recipe/installer-add-rootfs.bbclass index 62301c34..69d87be8 100644 --- a/meta-isar/classes-recipe/installer-add-rootfs.bbclass +++ b/meta-isar/classes-recipe/installer-add-rootfs.bbclass @@ -13,10 +13,9 @@ INSTALLER_TARGET_IMAGES ??= "${INSTALLER_TARGET_IMAGE}" INSTALLER_TARGET_MC ??= "installer-target" INSTALLER_TARGET_DISTRO ??= "${DISTRO}" INSTALLER_TARGET_MACHINE ??= "${MACHINE}" -INSTALLER_TARGET_IMAGE ??= "${IMAGE_PN}" -INSTALLER_TARGET_DEPLOY_DIR_IMAGE ??= "${DEPLOY_DIR}/images/${INSTALLER_TARGET_MACHINE}/${INSTALLER_TARGET_DISTRO}-${INSTALLER_TARGET_IMAGE}" +INSTALLER_TARGET_DEPLOY_DIR_IMAGE ??= "${DEPLOY_DIR}/images/${INSTALLER_TARGET_MACHINE}" -IMAGE_DATA_FILE ??= "${INSTALLER_TARGET_MACHINE}" +IMAGE_DATA_FILE ??= "${INSTALLER_TARGET_IMAGE}-${INSTALLER_TARGET_DISTRO}-${INSTALLER_TARGET_MACHINE}" IMAGE_DATA_POSTFIX ??= "wic.zst" IMAGE_DATA_POSTFIX:buster ??= "wic.xz" IMAGE_DATA_POSTFIX:bullseye ??= "wic.xz" @@ -30,7 +29,7 @@ def get_installer_sources(d, suffix): target_machine = d.getVar('INSTALLER_TARGET_MACHINE') sources = [] for image in installer_target_images: - image_data = f"{target_machine}" + image_data = f"{image}-{target_distro}-{target_machine}" sources.append(f"{target_deploy_dir}/{image_data}.{suffix}") return sources @@ -42,7 +41,7 @@ def get_installer_destinations(d, suffix): target_machine = d.getVar('INSTALLER_TARGET_MACHINE') dests = [] for image in installer_target_images: - image_data = f"{target_machine}" + image_data = f"{image}-{target_distro}-{target_machine}" dests.append(f"/install/{image_data}.{suffix}") return dests diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass index 866df68a..26a4ec06 100644 --- a/meta/classes-recipe/image.bbclass +++ b/meta/classes-recipe/image.bbclass @@ -18,9 +18,8 @@ IMAGE_ROOTFS ?= "${WORKDIR}/rootfs" KERNEL_IMAGE_PKG ??= "${@ ("linux-image-" + d.getVar("KERNEL_NAME")) if d.getVar("KERNEL_NAME") else ""}" IMAGE_INSTALL += "${KERNEL_IMAGE_PKG}" -# Name the image as the machine name only, since the path includes distro name now -IMAGE_FULLNAME = "${MACHINE}" -IMAGE_PN = "${PN}" +# Name of the image including distro&machine names +IMAGE_FULLNAME = "${PN}-${DISTRO}-${MACHINE}" # Deprecated; this would be set to e.g. "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}-initrd.img" INITRD_IMAGE ?= "" @@ -30,7 +29,7 @@ INITRD_IMAGE ?= "" IMAGE_INITRD ?= "" # Name of the deployed initrd image -INITRD_DEPLOY_FILE = "initrd.img" +INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }-${DISTRO}-${MACHINE}-initrd.img" # Make sure dependent initramfs recipe is built do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }" @@ -53,7 +52,7 @@ python() { ROOTFS_FEATURES += "${@ 'generate-initrd' if (d.getVar('INITRD_IMAGE') == '' and d.getVar('IMAGE_INITRD') == '') else ''}" # This variable is used by wic and start_vm -KERNEL_IMAGE ?= "${KERNEL_FILE}" +KERNEL_IMAGE ?= "${IMAGE_FULLNAME}-${KERNEL_FILE}" # This defines the deployed dtbs for reuse by imagers DTB_FILES ?= "" @@ -109,7 +108,7 @@ ROOTFS_PACKAGES += "${IMAGE_PREINSTALL} ${@isar_multiarch_packages('IMAGE_INSTAL ROOTFS_VARDEPS += "IMAGE_INSTALL" ROOTFS_MANIFEST_DEPLOY_DIR ?= "${DEPLOY_DIR_IMAGE}" ROOTFS_DPKGSTATUS_DEPLOY_DIR ?= "${DEPLOY_DIR_IMAGE}" -ROOTFS_PACKAGE_SUFFIX ?= "${MACHINE}" +ROOTFS_PACKAGE_SUFFIX ?= "${PN}-${DISTRO}-${MACHINE}" CACHE_DEB_SRC = "${@bb.utils.contains('BASE_REPO_FEATURES', 'cache-deb-src', '1', '0', d)}" python () { diff --git a/meta/classes-recipe/imagetypes_container.bbclass b/meta/classes-recipe/imagetypes_container.bbclass index fba15503..e07ce8e6 100644 --- a/meta/classes-recipe/imagetypes_container.bbclass +++ b/meta/classes-recipe/imagetypes_container.bbclass @@ -9,7 +9,7 @@ CONTAINER_TYPES = "oci-archive docker-archive docker-daemon containers-storage" USING_CONTAINER = "${@bb.utils.contains_any('IMAGE_BASETYPES', d.getVar('CONTAINER_TYPES').split(), '1', '0', d)}" -CONTAINER_IMAGE_NAME ?= "container-${DISTRO_ARCH}" +CONTAINER_IMAGE_NAME ?= "${PN}-${DISTRO}-${DISTRO_ARCH}" CONTAINER_IMAGE_TAG ?= "${PV}-${PR}" CONTAINER_IMAGE_CMD ?= "/bin/dash" CONTAINER_IMAGE_ENTRYPOINT ?= "" diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf index 5f339d40..5c71078d 100644 --- a/meta/conf/bitbake.conf +++ b/meta/conf/bitbake.conf @@ -57,8 +57,7 @@ WORKDIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}/${PN}/${PV}-${PR}" GIT_DL_LINK_DIR = "${TMPDIR}/work/${DISTRO}-${DISTRO_ARCH}" DEPLOY_DIR_BOOTSTRAP = "${DEPLOY_DIR}/bootstrap" DEPLOY_DIR_SDKCHROOT = "${DEPLOY_DIR}/sdkchroot" -IMAGE_PN ?= "" -DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}${@('/%s-%s' % (d.getVar('DISTRO'), d.getVar('IMAGE_PN'))) if d.getVar('IMAGE_PN') != '' else ''}" +DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}" DL_DIR ?= "${TOPDIR}/downloads" SSTATE_DIR ?= "${TOPDIR}/sstate-cache" SSTATE_MANIFESTS = "${TMPDIR}/sstate-control/${DISTRO}-${DISTRO_ARCH}" diff --git a/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py b/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py index eaef9c79..0ed61fff 100644 --- a/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py +++ b/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py @@ -196,7 +196,7 @@ class IsoImagePlugin(SourcePlugin): raise WicError("Couldn't find MACHINE, exiting.") pattern = '%s/%s*%s.%s' % (initrd_dir, image_name, machine, image_type) - pattern = '%s/initrd.%s' % (initrd_dir, image_type) + pattern = '%s/%s-%s-initrd.%s' % (initrd_dir, image_name, machine, image_type) files = glob.glob(pattern) if files: initrd = files[0] diff --git a/testsuite/cibase.py b/testsuite/cibase.py index 060607f7..4a6308d0 100755 --- a/testsuite/cibase.py +++ b/testsuite/cibase.py @@ -44,7 +44,7 @@ class CIBaseTest(CIBuilder): self.configure(wic_deploy_parts=wic_deploy_parts, **kwargs) self.bitbake(targets, **kwargs) - wic_path = f"{self.build_dir}/tmp/deploy/images/*/*/*.wic.p1" + wic_path = f"{self.build_dir}/tmp/deploy/images/*/*.wic.p1" partition_files = set(glob.glob(wic_path)) if wic_deploy_parts and len(partition_files) == 0: self.fail("Found raw wic partitions in DEPLOY_DIR") diff --git a/testsuite/citest.py b/testsuite/citest.py index a1b362c4..3eea07e5 100755 --- a/testsuite/citest.py +++ b/testsuite/citest.py @@ -498,9 +498,8 @@ class InitRdBaseTest(CIBaseTest): super().init() self.deploy_dir = os.path.join(self.build_dir, 'tmp', 'deploy') - def deploy_dir_image(self, mc, image): - multiconfig = f"{mc}:{image}" - return CIUtils.getVars('DEPLOY_DIR_IMAGE', target=multiconfig) + def deploy_dir_image(self, machine): + return os.path.join(self.deploy_dir, 'images', machine) def dracut_in_image(self, targets): machine = 'qemuamd64' @@ -529,7 +528,7 @@ class InitRdBaseTest(CIBaseTest): bb_should_fail=False): mc = f'mc:{machine}-{distro.removeprefix("debian-")}' initrd_image = f'{initrd}-{distro}-{machine}-initrd.img' - initrd_path = os.path.join(self.deploy_dir_image(mc, initrd), initrd_image) + initrd_path = os.path.join(self.deploy_dir_image(machine), initrd_image) # cleansstate if the initrd image was already built/deployed to verify # that a new build does result in the image being deployed diff --git a/testsuite/start_vm.py b/testsuite/start_vm.py index 958ab00a..8e28f11b 100755 --- a/testsuite/start_vm.py +++ b/testsuite/start_vm.py @@ -50,7 +50,7 @@ def format_qemu_cmdline( image_type = image_fstypes.split()[0] base = 'ubuntu' if distro in ['jammy', 'focal', 'noble'] else 'debian' - rootfs_image = f"qemu{arch}.{image_type}" + rootfs_image = f"{image}-{base}-{distro}-qemu{arch}.{image_type}" if image_type == 'ext4': kernel_image = deploy_dir_image + '/' + kernel_image -- 2.53.0 -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260410132250.3320171-2-felix.moessbauer%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-10 13:22 [PATCH 0/2] Rework deployment of image artifacts 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 1/2] Revert "meta: Deploy image build artifacts into distro- and image-specific subdirs" 'Felix Moessbauer' via isar-users @ 2026-04-10 13:22 ` 'Felix Moessbauer' via isar-users 2026-04-10 13:38 ` 'Jan Kiszka' via isar-users 2026-04-16 13:54 ` Zhihang Wei 2026-04-10 14:21 ` [PATCH 0/2] Rework deployment of image artifacts Zhihang Wei 2026-04-16 15:42 ` Zhihang Wei 3 siblings, 2 replies; 18+ messages in thread From: 'Felix Moessbauer' via isar-users @ 2026-04-10 13:22 UTC (permalink / raw) To: isar-users; +Cc: wzh, jan.kiszka, quirin.gylstorff, Felix Moessbauer As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally incompatible with custom initrd recipes, this patch was reverted, re-introducing the do_copy_boot_files error on DTBs that are named equally but belong to different mc targets. To mitigate this limitation without breaking custom initrds, we prefix all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. On imaging, these prefixes are stripped again by the imager scripts. Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> --- RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ meta/classes-recipe/image.bbclass | 6 ++++-- meta/classes-recipe/imagetypes_wic.bbclass | 2 +- .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- 4 files changed, 27 insertions(+), 4 deletions(-) diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md index 0e6a3172..856da5de 100644 --- a/RECIPE-API-CHANGELOG.md +++ b/RECIPE-API-CHANGELOG.md @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as part of a repository, a tarball, or some other directory structure, just specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. + +Changes in next +--------------- + +### Prefix DTB file names when deploying + +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not +affected by this change). Custom imaging plugins need to be adapted to this +change by removing the prefix from the filename. For that, the variable +DTB_PREFIX is exported as bitbake var into wic environment. + +This fixes errors when building different distros with the same machine, +whereby previously the following error occured: + +do_copy_boot_files: The recipe isar-image-base is trying to install +files into a shared area when those files already exists. It happens +when some files have the same names (e.g., dtb files) for different +distros. diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass index 26a4ec06..9b5dd23e 100644 --- a/meta/classes-recipe/image.bbclass +++ b/meta/classes-recipe/image.bbclass @@ -379,7 +379,8 @@ EOF KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" # only one dtb file supported, pick the first -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" +DTB_PREFIX = "${PN}-${DISTRO}." +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" @@ -402,7 +403,8 @@ do_copy_boot_files() { die "${file} not found" fi - cp -f "$dtb" "${DEPLOYDIR}/" + dtb_name=$(basename "$dtb") + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" done } addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass index dd6c501d..c0813223 100644 --- a/meta/classes-recipe/imagetypes_wic.bbclass +++ b/meta/classes-recipe/imagetypes_wic.bbclass @@ -107,7 +107,7 @@ WICVARS += "\ ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" # Isar specific vars used in our plugins -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" python do_rootfs_wicenv () { wicvars = d.getVar('WICVARS') diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py index 6bc78d42..32b220fa 100644 --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): if dtb: if ';' in dtb: raise WicError("Only one DTB supported, exiting") - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) exec_cmd(cp_cmd, True) @classmethod -- 2.53.0 -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260410132250.3320171-3-felix.moessbauer%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-10 13:22 ` [PATCH 2/2] prefix DTB files with PN in deploy dir 'Felix Moessbauer' via isar-users @ 2026-04-10 13:38 ` 'Jan Kiszka' via isar-users 2026-04-10 14:12 ` 'MOESSBAUER, Felix' via isar-users 2026-04-16 13:54 ` Zhihang Wei 1 sibling, 1 reply; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-10 13:38 UTC (permalink / raw) To: Felix Moessbauer, isar-users; +Cc: wzh, quirin.gylstorff On 10.04.26 15:22, Felix Moessbauer wrote: > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > incompatible with custom initrd recipes, this patch was reverted, > re-introducing the do_copy_boot_files error on DTBs that are named > equally but belong to different mc targets. > > To mitigate this limitation without breaking custom initrds, we prefix > all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. > On imaging, these prefixes are stripped again by the imager scripts. > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> > --- > RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ > meta/classes-recipe/image.bbclass | 6 ++++-- > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- > 4 files changed, 27 insertions(+), 4 deletions(-) > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > index 0e6a3172..856da5de 100644 > --- a/RECIPE-API-CHANGELOG.md > +++ b/RECIPE-API-CHANGELOG.md > @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to > `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as > part of a repository, a tarball, or some other directory structure, just > specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. > + > +Changes in next > +--------------- > + > +### Prefix DTB file names when deploying > + > +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of > +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes > +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not > +affected by this change). Custom imaging plugins need to be adapted to this > +change by removing the prefix from the filename. For that, the variable > +DTB_PREFIX is exported as bitbake var into wic environment. > + > +This fixes errors when building different distros with the same machine, > +whereby previously the following error occured: > + > +do_copy_boot_files: The recipe isar-image-base is trying to install > +files into a shared area when those files already exists. It happens > +when some files have the same names (e.g., dtb files) for different > +distros. > diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass > index 26a4ec06..9b5dd23e 100644 > --- a/meta/classes-recipe/image.bbclass > +++ b/meta/classes-recipe/image.bbclass > @@ -379,7 +379,8 @@ EOF > KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" > INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" > # only one dtb file supported, pick the first > -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" > +DTB_PREFIX = "${PN}-${DISTRO}." > +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" > > do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" > do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" > @@ -402,7 +403,8 @@ do_copy_boot_files() { > die "${file} not found" > fi > > - cp -f "$dtb" "${DEPLOYDIR}/" > + dtb_name=$(basename "$dtb") > + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" Let's but the DTBs in prefix-subdirs - will also make referring to them cleaner. > done > } > addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install > diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass > index dd6c501d..c0813223 100644 > --- a/meta/classes-recipe/imagetypes_wic.bbclass > +++ b/meta/classes-recipe/imagetypes_wic.bbclass > @@ -107,7 +107,7 @@ WICVARS += "\ > ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" > > # Isar specific vars used in our plugins > -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" > +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" > > python do_rootfs_wicenv () { > wicvars = d.getVar('WICVARS') > diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > index 6bc78d42..32b220fa 100644 > --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): > if dtb: > if ';' in dtb: > raise WicError("Only one DTB supported, exiting") > - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) > + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) > + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) > exec_cmd(cp_cmd, True) > > @classmethod DTBs are the most prominent conflicts with multiconfigs or partial rebuilds. We may mitigate this one, so it's fine, but the fundamental risk will remain. One of the reason why I asked to study OE carefully and try to learn from it first. Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/72ac920d-1af2-4997-beb4-0f5a4064574b%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-10 13:38 ` 'Jan Kiszka' via isar-users @ 2026-04-10 14:12 ` 'MOESSBAUER, Felix' via isar-users 2026-04-10 16:32 ` 'Jan Kiszka' via isar-users 0 siblings, 1 reply; 18+ messages in thread From: 'MOESSBAUER, Felix' via isar-users @ 2026-04-10 14:12 UTC (permalink / raw) To: Kiszka, Jan, isar-users; +Cc: wzh, Gylstorff, Quirin On Fri, 2026-04-10 at 15:38 +0200, Jan Kiszka wrote: > On 10.04.26 15:22, Felix Moessbauer wrote: > > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > > incompatible with custom initrd recipes, this patch was reverted, > > re-introducing the do_copy_boot_files error on DTBs that are named > > equally but belong to different mc targets. > > > > To mitigate this limitation without breaking custom initrds, we prefix > > all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. > > On imaging, these prefixes are stripped again by the imager scripts. > > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> > > --- > > RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ > > meta/classes-recipe/image.bbclass | 6 ++++-- > > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > > .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- > > 4 files changed, 27 insertions(+), 4 deletions(-) > > > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > > index 0e6a3172..856da5de 100644 > > --- a/RECIPE-API-CHANGELOG.md > > +++ b/RECIPE-API-CHANGELOG.md > > @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to > > `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as > > part of a repository, a tarball, or some other directory structure, just > > specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. > > + > > +Changes in next > > +--------------- > > + > > +### Prefix DTB file names when deploying > > + > > +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of > > +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes > > +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not > > +affected by this change). Custom imaging plugins need to be adapted to this > > +change by removing the prefix from the filename. For that, the variable > > +DTB_PREFIX is exported as bitbake var into wic environment. > > + > > +This fixes errors when building different distros with the same machine, > > +whereby previously the following error occured: > > + > > +do_copy_boot_files: The recipe isar-image-base is trying to install > > +files into a shared area when those files already exists. It happens > > +when some files have the same names (e.g., dtb files) for different > > +distros. > > diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass > > index 26a4ec06..9b5dd23e 100644 > > --- a/meta/classes-recipe/image.bbclass > > +++ b/meta/classes-recipe/image.bbclass > > @@ -379,7 +379,8 @@ EOF > > KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" > > INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" > > # only one dtb file supported, pick the first > > -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" > > +DTB_PREFIX = "${PN}-${DISTRO}." > > +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" > > > > do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" > > do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" > > @@ -402,7 +403,8 @@ do_copy_boot_files() { > > die "${file} not found" > > fi > > > > - cp -f "$dtb" "${DEPLOYDIR}/" > > + dtb_name=$(basename "$dtb") > > + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" > > Let's but the DTBs in prefix-subdirs - will also make referring to them > cleaner. I explicitly decided against putting them in subdirs to not diverge from the names of the other artifacts. However, OE deploys the DTBs via the devicetree class to ${IMAGE_DEPLOY_DIR}/devicetree/ , which does not help much as we still would get a clash. In addition, it deploys to sysroot where other recipes should consume it from [1]. But we could do that cleanup while we are at it. Another reason for not putting them in a directory are file globs commonly used in CI to copy out all files in the deploy dir. [1] https://docs.yoctoproject.org/dev/ref-manual/classes.html#devicetree Apart from that, OE anyways discourages direct deploy to DEPLOY_DIR_IMAGE. Instead the deploy.bbclass class should be used to deploy through the sstate cache. > > > done > > } > > addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install > > diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass > > index dd6c501d..c0813223 100644 > > --- a/meta/classes-recipe/imagetypes_wic.bbclass > > +++ b/meta/classes-recipe/imagetypes_wic.bbclass > > @@ -107,7 +107,7 @@ WICVARS += "\ > > ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" > > > > # Isar specific vars used in our plugins > > -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" > > +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" > > > > python do_rootfs_wicenv () { > > wicvars = d.getVar('WICVARS') > > diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > index 6bc78d42..32b220fa 100644 > > --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): > > if dtb: > > if ';' in dtb: > > raise WicError("Only one DTB supported, exiting") > > - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) > > + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) > > + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) > > exec_cmd(cp_cmd, True) > > > > @classmethod > > DTBs are the most prominent conflicts with multiconfigs or partial > rebuilds. We may mitigate this one, so it's fine, but the fundamental > risk will remain. One of the reason why I asked to study OE carefully > and try to learn from it first. In OE these problems are also not solved. Even the split of the TMPDIR is done in downstream layers, not OE-core (at least I found nothing in OE core). Felix > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/42a2d5b328b95347a27c18af16ce812f5d568fa2.camel%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-10 14:12 ` 'MOESSBAUER, Felix' via isar-users @ 2026-04-10 16:32 ` 'Jan Kiszka' via isar-users 0 siblings, 0 replies; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-10 16:32 UTC (permalink / raw) To: Moessbauer, Felix (FT RPD CED OES-DE), isar-users Cc: wzh, Gylstorff, Quirin (FT RPD CED OES-DE) On 10.04.26 16:12, Moessbauer, Felix (FT RPD CED OES-DE) wrote: > On Fri, 2026-04-10 at 15:38 +0200, Jan Kiszka wrote: >> On 10.04.26 15:22, Felix Moessbauer wrote: >>> As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally >>> incompatible with custom initrd recipes, this patch was reverted, >>> re-introducing the do_copy_boot_files error on DTBs that are named >>> equally but belong to different mc targets. >>> >>> To mitigate this limitation without breaking custom initrds, we prefix >>> all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. >>> On imaging, these prefixes are stripped again by the imager scripts. >>> >>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> >>> --- >>> RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ >>> meta/classes-recipe/image.bbclass | 6 ++++-- >>> meta/classes-recipe/imagetypes_wic.bbclass | 2 +- >>> .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- >>> 4 files changed, 27 insertions(+), 4 deletions(-) >>> >>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md >>> index 0e6a3172..856da5de 100644 >>> --- a/RECIPE-API-CHANGELOG.md >>> +++ b/RECIPE-API-CHANGELOG.md >>> @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to >>> `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as >>> part of a repository, a tarball, or some other directory structure, just >>> specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. >>> + >>> +Changes in next >>> +--------------- >>> + >>> +### Prefix DTB file names when deploying >>> + >>> +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of >>> +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes >>> +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not >>> +affected by this change). Custom imaging plugins need to be adapted to this >>> +change by removing the prefix from the filename. For that, the variable >>> +DTB_PREFIX is exported as bitbake var into wic environment. Downstream pick-up scripts like https://gitlab.com/Xenomai/xenomai-images/-/blob/master/scripts/deploy_to_aws.sh?ref_type=heads will need adjustments as well. >>> + >>> +This fixes errors when building different distros with the same machine, >>> +whereby previously the following error occured: >>> + >>> +do_copy_boot_files: The recipe isar-image-base is trying to install >>> +files into a shared area when those files already exists. It happens >>> +when some files have the same names (e.g., dtb files) for different >>> +distros. >>> diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass >>> index 26a4ec06..9b5dd23e 100644 >>> --- a/meta/classes-recipe/image.bbclass >>> +++ b/meta/classes-recipe/image.bbclass >>> @@ -379,7 +379,8 @@ EOF >>> KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" >>> INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" >>> # only one dtb file supported, pick the first >>> -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" >>> +DTB_PREFIX = "${PN}-${DISTRO}." >>> +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" >>> >>> do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" >>> do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" >>> @@ -402,7 +403,8 @@ do_copy_boot_files() { >>> die "${file} not found" >>> fi >>> >>> - cp -f "$dtb" "${DEPLOYDIR}/" >>> + dtb_name=$(basename "$dtb") >>> + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" >> >> Let's but the DTBs in prefix-subdirs - will also make referring to them >> cleaner. > > I explicitly decided against putting them in subdirs to not diverge > from the names of the other artifacts. However, OE deploys the DTBs via > the devicetree class to ${IMAGE_DEPLOY_DIR}/devicetree/ , which does > not help much as we still would get a clash. In addition, it deploys to > sysroot where other recipes should consume it from [1]. But we could do > that cleanup while we are at it. Which of the cleanups? There is no sysroot in Isar. Rather, we would have to add a package to the chroot of the imager and pick it up from there. > > Another reason for not putting them in a directory are file globs > commonly used in CI to copy out all files in the deploy dir. See above, those will have to be adjusted because you often cannot pick up the mangled DTB file names. That is why I suggested a directory. > > [1] > https://docs.yoctoproject.org/dev/ref-manual/classes.html#devicetree > > Apart from that, OE anyways discourages direct deploy to > DEPLOY_DIR_IMAGE. Instead the deploy.bbclass class should be used to > deploy through the sstate cache. > Then let's try that and see if it helps better. >> >>> done >>> } >>> addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install >>> diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass >>> index dd6c501d..c0813223 100644 >>> --- a/meta/classes-recipe/imagetypes_wic.bbclass >>> +++ b/meta/classes-recipe/imagetypes_wic.bbclass >>> @@ -107,7 +107,7 @@ WICVARS += "\ >>> ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" >>> >>> # Isar specific vars used in our plugins >>> -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" >>> +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" >>> >>> python do_rootfs_wicenv () { >>> wicvars = d.getVar('WICVARS') >>> diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> index 6bc78d42..32b220fa 100644 >>> --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): >>> if dtb: >>> if ';' in dtb: >>> raise WicError("Only one DTB supported, exiting") >>> - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) >>> + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) >>> + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) >>> exec_cmd(cp_cmd, True) >>> >>> @classmethod >> >> DTBs are the most prominent conflicts with multiconfigs or partial >> rebuilds. We may mitigate this one, so it's fine, but the fundamental >> risk will remain. One of the reason why I asked to study OE carefully >> and try to learn from it first. > > In OE these problems are also not solved. Even the split of the TMPDIR > is done in downstream layers, not OE-core (at least I found nothing in > OE core). Then we are either overusing multiconfig here or are still missing some other detail, such as indirect deployment. As the DTB deployment conflict is existing in Isar for many years, only affecting in practice its own setup, I would suggest to take the revert quickly into the tree and possibly postpone a real solution after further research. I'm also concerned that the pattern applied here will not easily scale to similar problems around other artifacts we deploy in various downstream layers. We are producing the same error around its firmware.bin when rebuilding isar-cip-core for different distros e.g. Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/cf057977-bbee-4da6-914e-a7eb287505b1%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-10 13:22 ` [PATCH 2/2] prefix DTB files with PN in deploy dir 'Felix Moessbauer' via isar-users 2026-04-10 13:38 ` 'Jan Kiszka' via isar-users @ 2026-04-16 13:54 ` Zhihang Wei 2026-04-16 14:39 ` 'MOESSBAUER, Felix' via isar-users 1 sibling, 1 reply; 18+ messages in thread From: Zhihang Wei @ 2026-04-16 13:54 UTC (permalink / raw) To: Felix Moessbauer, isar-users; +Cc: jan.kiszka, quirin.gylstorff On 4/10/26 15:22, Felix Moessbauer wrote: > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > incompatible with custom initrd recipes, this patch was reverted, > re-introducing the do_copy_boot_files error on DTBs that are named > equally but belong to different mc targets. > > To mitigate this limitation without breaking custom initrds, we prefix > all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. > On imaging, these prefixes are stripped again by the imager scripts. > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> > --- > RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ > meta/classes-recipe/image.bbclass | 6 ++++-- > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- > 4 files changed, 27 insertions(+), 4 deletions(-) > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > index 0e6a3172..856da5de 100644 > --- a/RECIPE-API-CHANGELOG.md > +++ b/RECIPE-API-CHANGELOG.md > @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to > `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as > part of a repository, a tarball, or some other directory structure, just > specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. > + > +Changes in next > +--------------- > + The last three lines should be kept. Also, the 2nd patch to add prefix to DTBs needs an entry in the API-CHANGELOG. Apart from these, we'll apply this series. Zhihang > +### Prefix DTB file names when deploying > + > +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of > +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes > +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not > +affected by this change). Custom imaging plugins need to be adapted to this > +change by removing the prefix from the filename. For that, the variable > +DTB_PREFIX is exported as bitbake var into wic environment. > + > +This fixes errors when building different distros with the same machine, > +whereby previously the following error occured: > + > +do_copy_boot_files: The recipe isar-image-base is trying to install > +files into a shared area when those files already exists. It happens > +when some files have the same names (e.g., dtb files) for different > +distros. > diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass > index 26a4ec06..9b5dd23e 100644 > --- a/meta/classes-recipe/image.bbclass > +++ b/meta/classes-recipe/image.bbclass > @@ -379,7 +379,8 @@ EOF > KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" > INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" > # only one dtb file supported, pick the first > -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" > +DTB_PREFIX = "${PN}-${DISTRO}." > +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" > > do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" > do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" > @@ -402,7 +403,8 @@ do_copy_boot_files() { > die "${file} not found" > fi > > - cp -f "$dtb" "${DEPLOYDIR}/" > + dtb_name=$(basename "$dtb") > + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" > done > } > addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install > diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass > index dd6c501d..c0813223 100644 > --- a/meta/classes-recipe/imagetypes_wic.bbclass > +++ b/meta/classes-recipe/imagetypes_wic.bbclass > @@ -107,7 +107,7 @@ WICVARS += "\ > ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" > > # Isar specific vars used in our plugins > -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" > +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" > > python do_rootfs_wicenv () { > wicvars = d.getVar('WICVARS') > diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > index 6bc78d42..32b220fa 100644 > --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): > if dtb: > if ';' in dtb: > raise WicError("Only one DTB supported, exiting") > - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) > + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) > + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) > exec_cmd(cp_cmd, True) > > @classmethod -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/ac9602f9-2271-4438-b490-686caa514ce7%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-16 13:54 ` Zhihang Wei @ 2026-04-16 14:39 ` 'MOESSBAUER, Felix' via isar-users 2026-04-16 15:41 ` Zhihang Wei 0 siblings, 1 reply; 18+ messages in thread From: 'MOESSBAUER, Felix' via isar-users @ 2026-04-16 14:39 UTC (permalink / raw) To: Zhihang Wei, isar-users; +Cc: Kiszka, Jan, Gylstorff, Quirin On Thu, 2026-04-16 at 15:54 +0200, Zhihang Wei wrote: > On 4/10/26 15:22, Felix Moessbauer wrote: > > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > > incompatible with custom initrd recipes, this patch was reverted, > > re-introducing the do_copy_boot_files error on DTBs that are named > > equally but belong to different mc targets. > > > > To mitigate this limitation without breaking custom initrds, we prefix > > all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. > > On imaging, these prefixes are stripped again by the imager scripts. > > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> > > --- > > RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ > > meta/classes-recipe/image.bbclass | 6 ++++-- > > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > > .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- > > 4 files changed, 27 insertions(+), 4 deletions(-) > > > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > > index 0e6a3172..856da5de 100644 > > --- a/RECIPE-API-CHANGELOG.md > > +++ b/RECIPE-API-CHANGELOG.md > > @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to > > `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as > > part of a repository, a tarball, or some other directory structure, just > > specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. > > + > > +Changes in next > > +--------------- > > + > The last three lines should be kept. > Also, the 2nd patch to add prefix to DTBs needs an entry in the > API-CHANGELOG. Apart from these, we'll apply this series. Zhihang Hi, which lines are you referring to? The "Changes in next" line is in there and the added prefix is documented (see below). But feel free to just adjust as you like. We still need a decision if the "meta: Deploy image build artifacts into distro- and image-specific subdirs" is JUST reverted (including the then broken test), or if we switch to the API proposed here, given that there might be another breaking change in case other artifacts (like firmware) also need to be split. Anyways, I really like to move forward - this way or another, as the ISAR 1.0 release is currently not usable for us. Best regards, Felix > > +### Prefix DTB file names when deploying > > + > > +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of > > +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes > > +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not > > +affected by this change). Custom imaging plugins need to be adapted to this > > +change by removing the prefix from the filename. For that, the variable > > +DTB_PREFIX is exported as bitbake var into wic environment. > > + > > +This fixes errors when building different distros with the same machine, > > +whereby previously the following error occured: > > + > > +do_copy_boot_files: The recipe isar-image-base is trying to install > > +files into a shared area when those files already exists. It happens > > +when some files have the same names (e.g., dtb files) for different > > +distros. > > diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass > > index 26a4ec06..9b5dd23e 100644 > > --- a/meta/classes-recipe/image.bbclass > > +++ b/meta/classes-recipe/image.bbclass > > @@ -379,7 +379,8 @@ EOF > > KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" > > INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" > > # only one dtb file supported, pick the first > > -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" > > +DTB_PREFIX = "${PN}-${DISTRO}." > > +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" > > > > do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" > > do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" > > @@ -402,7 +403,8 @@ do_copy_boot_files() { > > die "${file} not found" > > fi > > > > - cp -f "$dtb" "${DEPLOYDIR}/" > > + dtb_name=$(basename "$dtb") > > + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" > > done > > } > > addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install > > diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass > > index dd6c501d..c0813223 100644 > > --- a/meta/classes-recipe/imagetypes_wic.bbclass > > +++ b/meta/classes-recipe/imagetypes_wic.bbclass > > @@ -107,7 +107,7 @@ WICVARS += "\ > > ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" > > > > # Isar specific vars used in our plugins > > -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" > > +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" > > > > python do_rootfs_wicenv () { > > wicvars = d.getVar('WICVARS') > > diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > index 6bc78d42..32b220fa 100644 > > --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py > > @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): > > if dtb: > > if ';' in dtb: > > raise WicError("Only one DTB supported, exiting") > > - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) > > + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) > > + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) > > exec_cmd(cp_cmd, True) > > > > @classmethod -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/4f80204b325f81dd49350c9e03fdc610e0cb188a.camel%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 2/2] prefix DTB files with PN in deploy dir 2026-04-16 14:39 ` 'MOESSBAUER, Felix' via isar-users @ 2026-04-16 15:41 ` Zhihang Wei 0 siblings, 0 replies; 18+ messages in thread From: Zhihang Wei @ 2026-04-16 15:41 UTC (permalink / raw) To: MOESSBAUER, Felix, isar-users; +Cc: Kiszka, Jan, Gylstorff, Quirin On 4/16/26 16:39, MOESSBAUER, Felix wrote: > On Thu, 2026-04-16 at 15:54 +0200, Zhihang Wei wrote: >> On 4/10/26 15:22, Felix Moessbauer wrote: >>> As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally >>> incompatible with custom initrd recipes, this patch was reverted, >>> re-introducing the do_copy_boot_files error on DTBs that are named >>> equally but belong to different mc targets. >>> >>> To mitigate this limitation without breaking custom initrds, we prefix >>> all DTB files with ${PN}-${DISTRO} when deploying to DEPLOY_IMAGE_DIR. >>> On imaging, these prefixes are stripped again by the imager scripts. >>> >>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> >>> --- >>> RECIPE-API-CHANGELOG.md | 20 +++++++++++++++++++ >>> meta/classes-recipe/image.bbclass | 6 ++++-- >>> meta/classes-recipe/imagetypes_wic.bbclass | 2 +- >>> .../wic/plugins/source/bootimg-efi-isar.py | 3 ++- >>> 4 files changed, 27 insertions(+), 4 deletions(-) >>> >>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md >>> index 0e6a3172..856da5de 100644 >>> --- a/RECIPE-API-CHANGELOG.md >>> +++ b/RECIPE-API-CHANGELOG.md >>> @@ -981,3 +981,23 @@ fragment, this can be specified via adding `${S}/path/to/fragment.cfg` to >>> `KERNEL_CONFIG_FRAGMENTS`. If a fragment was checked out into ${WORKDIR} as >>> part of a repository, a tarball, or some other directory structure, just >>> specify it relative to ${WORKDIR} in `KERNEL_CONFIG_FRAGMENTS`. >>> + >>> +Changes in next >>> +--------------- >>> + >> The last three lines should be kept. >> Also, the 2nd patch to add prefix to DTBs needs an entry in the >> API-CHANGELOG. Apart from these, we'll apply this series. Zhihang > Hi, > > which lines are you referring to? The "Changes in next" line is in > there and the added prefix is documented (see below). But feel free to > just adjust as you like. Sorry, overlooked this part. Please ignore. > We still need a decision if the "meta: Deploy image build artifacts > into distro- and image-specific subdirs" is JUST reverted (including > the then broken test), or if we switch to the API proposed here, given > that there might be another breaking change in case other artifacts > (like firmware) also need to be split. We agree to switch to prefixed DTBs. That would be at least a workaround to support the Trixie targets. Zhihang > Anyways, I really like to move forward - this way or another, as the > ISAR 1.0 release is currently not usable for us. > > Best regards, > Felix > >>> +### Prefix DTB file names when deploying >>> + >>> +DTB files are now placed in the ${DEPLOY_DIR_IMAGE} with a prefix of >>> +${PN}-${DISTRO}. During wic imaging, the prefix is removed again, so no changes >>> +to downstream wks files are needed (i.e. `dtb=my-device-tree.dtb` is not >>> +affected by this change). Custom imaging plugins need to be adapted to this >>> +change by removing the prefix from the filename. For that, the variable >>> +DTB_PREFIX is exported as bitbake var into wic environment. >>> + >>> +This fixes errors when building different distros with the same machine, >>> +whereby previously the following error occured: >>> + >>> +do_copy_boot_files: The recipe isar-image-base is trying to install >>> +files into a shared area when those files already exists. It happens >>> +when some files have the same names (e.g., dtb files) for different >>> +distros. >>> diff --git a/meta/classes-recipe/image.bbclass b/meta/classes-recipe/image.bbclass >>> index 26a4ec06..9b5dd23e 100644 >>> --- a/meta/classes-recipe/image.bbclass >>> +++ b/meta/classes-recipe/image.bbclass >>> @@ -379,7 +379,8 @@ EOF >>> KERNEL_IMG = "${PP_DEPLOY}/${KERNEL_IMAGE}" >>> INITRD_IMG = "${PP_DEPLOY}/${INITRD_DEPLOY_FILE}" >>> # only one dtb file supported, pick the first >>> -DTB_IMG = "${PP_DEPLOY}/${@(d.getVar('DTB_FILES').split() or [''])[0]}" >>> +DTB_PREFIX = "${PN}-${DISTRO}." >>> +DTB_IMG = "${PP_DEPLOY}/${DTB_PREFIX}${@os.path.basename((d.getVar('DTB_FILES').split() or [''])[0])}" >>> >>> do_copy_boot_files[cleandirs] += "${DEPLOYDIR}" >>> do_copy_boot_files[sstate-inputdirs] = "${DEPLOYDIR}" >>> @@ -402,7 +403,8 @@ do_copy_boot_files() { >>> die "${file} not found" >>> fi >>> >>> - cp -f "$dtb" "${DEPLOYDIR}/" >>> + dtb_name=$(basename "$dtb") >>> + cp -f "$dtb" "${DEPLOYDIR}/${DTB_PREFIX}$dtb_name" >>> done >>> } >>> addtask copy_boot_files before do_rootfs_postprocess after do_rootfs_install >>> diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass >>> index dd6c501d..c0813223 100644 >>> --- a/meta/classes-recipe/imagetypes_wic.bbclass >>> +++ b/meta/classes-recipe/imagetypes_wic.bbclass >>> @@ -107,7 +107,7 @@ WICVARS += "\ >>> ROOTFS_SIZE STAGING_DATADIR STAGING_DIR STAGING_LIBDIR TARGET_SYS TRANSLATED_TARGET_ARCH" >>> >>> # Isar specific vars used in our plugins >>> -WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE" >>> +WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE DTB_PREFIX" >>> >>> python do_rootfs_wicenv () { >>> wicvars = d.getVar('WICVARS') >>> diff --git a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> index 6bc78d42..32b220fa 100644 >>> --- a/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> +++ b/meta/scripts/lib/wic/plugins/source/bootimg-efi-isar.py >>> @@ -57,7 +57,8 @@ class BootimgEFIPlugin(SourcePlugin): >>> if dtb: >>> if ';' in dtb: >>> raise WicError("Only one DTB supported, exiting") >>> - cp_cmd = "cp %s/%s %s" % (bootimg_dir, dtb, hdddir) >>> + dtb_file = "%s%s" % (get_bitbake_var("DTB_PREFIX"), dtb) >>> + cp_cmd = "cp %s/%s %s/%s" % (bootimg_dir, dtb_file, hdddir, dtb) >>> exec_cmd(cp_cmd, True) >>> >>> @classmethod -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/cefad8b1-5ff3-4465-9545-0d0846bfa1c5%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-10 13:22 [PATCH 0/2] Rework deployment of image artifacts 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 1/2] Revert "meta: Deploy image build artifacts into distro- and image-specific subdirs" 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 2/2] prefix DTB files with PN in deploy dir 'Felix Moessbauer' via isar-users @ 2026-04-10 14:21 ` Zhihang Wei 2026-04-16 15:42 ` Zhihang Wei 3 siblings, 0 replies; 18+ messages in thread From: Zhihang Wei @ 2026-04-10 14:21 UTC (permalink / raw) To: Felix Moessbauer, isar-users; +Cc: jan.kiszka, quirin.gylstorff On 4/10/26 15:22, Felix Moessbauer wrote: > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > incompatible with custom initrd recipes, this patch was reverted, > re-introducing the do_copy_boot_files error on DTBs that are named > equally but belong to different mc targets. > > This series mitigate the issue by keeping the layout of DEPLOY_DIR_IMAGE, > but prefixing the DTB_FILES with PN and DISTRO. These prefixes are > then stripped again during imaging. > > Note, that the series has been CI tested against the "dtbdeploy" and "dev" > tags. > > Best regards, > Felix Moessbauer > Siemens AG > > Felix Moessbauer (2): > Revert "meta: Deploy image build artifacts into distro- and > image-specific subdirs" > prefix DTB files with PN in deploy dir > > RECIPE-API-CHANGELOG.md | 84 +++---------------- > .../installer-add-rootfs.bbclass | 9 +- > meta/classes-recipe/image.bbclass | 17 ++-- > .../imagetypes_container.bbclass | 2 +- > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > meta/conf/bitbake.conf | 3 +- > .../wic/plugins/source/bootimg-efi-isar.py | 3 +- > .../plugins/source/isoimage-isohybrid-isar.py | 2 +- > testsuite/cibase.py | 2 +- > testsuite/citest.py | 7 +- > testsuite/start_vm.py | 2 +- > 11 files changed, 36 insertions(+), 97 deletions(-) > This has passed the newly added 2 DTB deploy test cases. I'll put it on full CI and get back to this next week. Zhihang -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/7e386332-f57d-4e29-8480-a06569b3802c%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-10 13:22 [PATCH 0/2] Rework deployment of image artifacts 'Felix Moessbauer' via isar-users ` (2 preceding siblings ...) 2026-04-10 14:21 ` [PATCH 0/2] Rework deployment of image artifacts Zhihang Wei @ 2026-04-16 15:42 ` Zhihang Wei 2026-04-16 15:51 ` 'Jan Kiszka' via isar-users 3 siblings, 1 reply; 18+ messages in thread From: Zhihang Wei @ 2026-04-16 15:42 UTC (permalink / raw) To: Felix Moessbauer, isar-users; +Cc: jan.kiszka, quirin.gylstorff Applied to next, thanks. Zhihang On 4/10/26 15:22, Felix Moessbauer wrote: > As the changing of the DEPLOY_DIR_IMAGE has proven to be fundamentally > incompatible with custom initrd recipes, this patch was reverted, > re-introducing the do_copy_boot_files error on DTBs that are named > equally but belong to different mc targets. > > This series mitigate the issue by keeping the layout of DEPLOY_DIR_IMAGE, > but prefixing the DTB_FILES with PN and DISTRO. These prefixes are > then stripped again during imaging. > > Note, that the series has been CI tested against the "dtbdeploy" and "dev" > tags. > > Best regards, > Felix Moessbauer > Siemens AG > > Felix Moessbauer (2): > Revert "meta: Deploy image build artifacts into distro- and > image-specific subdirs" > prefix DTB files with PN in deploy dir > > RECIPE-API-CHANGELOG.md | 84 +++---------------- > .../installer-add-rootfs.bbclass | 9 +- > meta/classes-recipe/image.bbclass | 17 ++-- > .../imagetypes_container.bbclass | 2 +- > meta/classes-recipe/imagetypes_wic.bbclass | 2 +- > meta/conf/bitbake.conf | 3 +- > .../wic/plugins/source/bootimg-efi-isar.py | 3 +- > .../plugins/source/isoimage-isohybrid-isar.py | 2 +- > testsuite/cibase.py | 2 +- > testsuite/citest.py | 7 +- > testsuite/start_vm.py | 2 +- > 11 files changed, 36 insertions(+), 97 deletions(-) > -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/9da6af9d-c17c-4d75-9085-a77c5f970e0a%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-16 15:42 ` Zhihang Wei @ 2026-04-16 15:51 ` 'Jan Kiszka' via isar-users 2026-04-16 16:01 ` 'Jan Kiszka' via isar-users 0 siblings, 1 reply; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-16 15:51 UTC (permalink / raw) To: Zhihang Wei, Felix Moessbauer, isar-users; +Cc: quirin.gylstorff On 16.04.26 17:42, Zhihang Wei wrote: > Applied to next, thanks. > I am repeating myself: We broken the deployment API in v1.0. This series is breaking it once more, just differently (and rather unhandy for many downstream users). Are we truly sure now that this is the FINAL solution, or do we plan for n more API breakages? Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/a4f2b187-15f8-4ffa-9f1a-a2b86c36b458%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-16 15:51 ` 'Jan Kiszka' via isar-users @ 2026-04-16 16:01 ` 'Jan Kiszka' via isar-users 2026-04-17 14:15 ` Zhihang Wei 0 siblings, 1 reply; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-16 16:01 UTC (permalink / raw) To: Zhihang Wei, Felix Moessbauer, isar-users, Baurzhan Ismagulov Cc: quirin.gylstorff On 16.04.26 17:51, Jan Kiszka wrote: > On 16.04.26 17:42, Zhihang Wei wrote: >> Applied to next, thanks. >> > > I am repeating myself: We broken the deployment API in v1.0. This series > is breaking it once more, just differently (and rather unhandy for many > downstream users). > > Are we truly sure now that this is the FINAL solution, or do we plan for > n more API breakages? > But let's a assume we keep it like this: What is the plan for a v1.0.1 hotfix release? I'm seeing other patches being merged. Some would qualify to be part as well, another one is harmless but not a hotfix. So I'm asking before things possibly move on further. At least some users here are waiting to adopt v1.0.x. Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/59c17c07-b886-47d5-b022-bb996f3606c2%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-16 16:01 ` 'Jan Kiszka' via isar-users @ 2026-04-17 14:15 ` Zhihang Wei 2026-04-17 14:39 ` 'Jan Kiszka' via isar-users 0 siblings, 1 reply; 18+ messages in thread From: Zhihang Wei @ 2026-04-17 14:15 UTC (permalink / raw) To: Jan Kiszka, Felix Moessbauer, isar-users, Baurzhan Ismagulov Cc: quirin.gylstorff On 4/16/26 18:01, Jan Kiszka wrote: > On 16.04.26 17:51, Jan Kiszka wrote: >> On 16.04.26 17:42, Zhihang Wei wrote: >>> Applied to next, thanks. >>> >> I am repeating myself: We broken the deployment API in v1.0. This series >> is breaking it once more, just differently (and rather unhandy for many >> downstream users). >> >> Are we truly sure now that this is the FINAL solution, or do we plan for >> n more API breakages? >> > But let's a assume we keep it like this: > > What is the plan for a v1.0.1 hotfix release? I'm seeing other patches > being merged. Some would qualify to be part as well, another one is > harmless but not a hotfix. So I'm asking before things possibly move on > further. At least some users here are waiting to adopt v1.0.x. > > Jan > We have tested the prefixed DTB approach on our downstreams and it works without major issues. Regarding splitting TMPDIRs: this would break at least one of our downstreams. We have a setup with two multiconfigs — one for rescue (with its own rootfs, kernel, etc.) and another regular one which depends on the rescue one and needs to consume its deployed artifacts. Splitting TMPDIRs is not viable in this case. As for the release plan: we would like to target v1.1 rather than a v1.0.1 hotfix, with the API expected to remain stable for some period. I propose that if a final solution can be found quickly, we hold v1.1 until it is merged. Otherwise, v1.1 should be based on the prefixed DTB patch. We do have a new proposal for the "final solution". Let me send it under v6 DTB discussion. Zhihang -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/86216acd-0b35-4f11-803a-c5ac439de993%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-17 14:15 ` Zhihang Wei @ 2026-04-17 14:39 ` 'Jan Kiszka' via isar-users 2026-04-17 15:05 ` 'Jan Kiszka' via isar-users 0 siblings, 1 reply; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-17 14:39 UTC (permalink / raw) To: Zhihang Wei, Felix Moessbauer, isar-users, Baurzhan Ismagulov Cc: quirin.gylstorff On 17.04.26 16:15, Zhihang Wei wrote: > > > On 4/16/26 18:01, Jan Kiszka wrote: >> On 16.04.26 17:51, Jan Kiszka wrote: >>> On 16.04.26 17:42, Zhihang Wei wrote: >>>> Applied to next, thanks. >>>> >>> I am repeating myself: We broken the deployment API in v1.0. This series >>> is breaking it once more, just differently (and rather unhandy for many >>> downstream users). >>> >>> Are we truly sure now that this is the FINAL solution, or do we plan for >>> n more API breakages? >>> >> But let's a assume we keep it like this: >> >> What is the plan for a v1.0.1 hotfix release? I'm seeing other patches >> being merged. Some would qualify to be part as well, another one is >> harmless but not a hotfix. So I'm asking before things possibly move on >> further. At least some users here are waiting to adopt v1.0.x. >> >> Jan >> > We have tested the prefixed DTB approach on our downstreams and it > works without major issues. You likely have nothing like the deployment scripts for LAVA (isar-cip-core, xenomai-images). It breaks them, and we need extra logic because of the mangled names and paths. > > Regarding splitting TMPDIRs: this would break at least one of our > downstreams. We have a setup with two multiconfigs — one for rescue > (with its own rootfs, kernel, etc.) and another regular one which > depends on the rescue one and needs to consume its deployed artifacts. > Splitting TMPDIRs is not viable in this case. > This has already been identified as problem, yes. OE does not use it either, only few downstreams. We are apparently overusing mc: or the deployment folder here. > > As for the release plan: we would like to target v1.1 rather than a > v1.0.1 hotfix, with the API expected to remain stable for some period. We must fix this soon or 1.0 will remain a no-go version. It will then happen the opposite of what "1.0" was aiming at: to signal maturity. > I propose that if a final solution can be found quickly, we hold v1.1 > until it is merged. Otherwise, v1.1 should be based on the prefixed DTB > patch. > > We do have a new proposal for the "final solution". Let me send it > under v6 DTB discussion. > I'm looking into it. Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/cfbbdaac-88ac-4dc5-8b9d-2549a67f0459%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-17 14:39 ` 'Jan Kiszka' via isar-users @ 2026-04-17 15:05 ` 'Jan Kiszka' via isar-users 2026-04-20 6:25 ` 'Quirin Gylstorff' via isar-users 2026-04-20 16:00 ` Zhihang Wei 0 siblings, 2 replies; 18+ messages in thread From: 'Jan Kiszka' via isar-users @ 2026-04-17 15:05 UTC (permalink / raw) To: Zhihang Wei, Felix Moessbauer, isar-users, Baurzhan Ismagulov Cc: quirin.gylstorff On 17.04.26 16:39, 'Jan Kiszka' via isar-users wrote: > On 17.04.26 16:15, Zhihang Wei wrote: >> >> >> On 4/16/26 18:01, Jan Kiszka wrote: >>> On 16.04.26 17:51, Jan Kiszka wrote: >>>> On 16.04.26 17:42, Zhihang Wei wrote: >>>>> Applied to next, thanks. >>>>> >>>> I am repeating myself: We broken the deployment API in v1.0. This series >>>> is breaking it once more, just differently (and rather unhandy for many >>>> downstream users). >>>> >>>> Are we truly sure now that this is the FINAL solution, or do we plan for >>>> n more API breakages? >>>> >>> But let's a assume we keep it like this: >>> >>> What is the plan for a v1.0.1 hotfix release? I'm seeing other patches >>> being merged. Some would qualify to be part as well, another one is >>> harmless but not a hotfix. So I'm asking before things possibly move on >>> further. At least some users here are waiting to adopt v1.0.x. >>> >>> Jan >>> >> We have tested the prefixed DTB approach on our downstreams and it >> works without major issues. > > You likely have nothing like the deployment scripts for LAVA > (isar-cip-core, xenomai-images). It breaks them, and we need extra logic > because of the mangled names and paths. > >> >> Regarding splitting TMPDIRs: this would break at least one of our >> downstreams. We have a setup with two multiconfigs — one for rescue >> (with its own rootfs, kernel, etc.) and another regular one which >> depends on the rescue one and needs to consume its deployed artifacts. >> Splitting TMPDIRs is not viable in this case. >> > > This has already been identified as problem, yes. OE does not use it > either, only few downstreams. We are apparently overusing mc: or the > deployment folder here. > >> >> As for the release plan: we would like to target v1.1 rather than a >> v1.0.1 hotfix, with the API expected to remain stable for some period. > > We must fix this soon or 1.0 will remain a no-go version. It will then > happen the opposite of what "1.0" was aiming at: to signal maturity. > >> I propose that if a final solution can be found quickly, we hold v1.1 >> until it is merged. Otherwise, v1.1 should be based on the prefixed DTB >> patch. >> >> We do have a new proposal for the "final solution". Let me send it >> under v6 DTB discussion. >> > > I'm looking into it. > > Jan > Just to make it clear (again), this is how OE deploys DTBs to images: build/tmp/deploy/images/qemusdc2/devicetree/*.dtb Didn't check yet, but there might even unfold the new subdirectory structure (by vendor, mostly) under that folder. So this renaming here is not getting us better aligned (to be fair: we were not aligned before). Jan -- Siemens AG, Foundational Technologies Linux Expert Center -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/09a97392-a6f3-4329-a5d3-af39a45d6c87%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-17 15:05 ` 'Jan Kiszka' via isar-users @ 2026-04-20 6:25 ` 'Quirin Gylstorff' via isar-users 2026-04-20 16:00 ` Zhihang Wei 1 sibling, 0 replies; 18+ messages in thread From: 'Quirin Gylstorff' via isar-users @ 2026-04-20 6:25 UTC (permalink / raw) To: Jan Kiszka, Zhihang Wei, Felix Moessbauer, isar-users, Baurzhan Ismagulov On 4/17/26 5:05 PM, Jan Kiszka wrote: > On 17.04.26 16:39, 'Jan Kiszka' via isar-users wrote: >> On 17.04.26 16:15, Zhihang Wei wrote: >>> >>> >>> On 4/16/26 18:01, Jan Kiszka wrote: >>>> On 16.04.26 17:51, Jan Kiszka wrote: >>>>> On 16.04.26 17:42, Zhihang Wei wrote: >>>>>> Applied to next, thanks. >>>>>> >>>>> I am repeating myself: We broken the deployment API in v1.0. This series >>>>> is breaking it once more, just differently (and rather unhandy for many >>>>> downstream users). >>>>> >>>>> Are we truly sure now that this is the FINAL solution, or do we plan for >>>>> n more API breakages? >>>>> >>>> But let's a assume we keep it like this: >>>> >>>> What is the plan for a v1.0.1 hotfix release? I'm seeing other patches >>>> being merged. Some would qualify to be part as well, another one is >>>> harmless but not a hotfix. So I'm asking before things possibly move on >>>> further. At least some users here are waiting to adopt v1.0.x. >>>> >>>> Jan >>>> >>> We have tested the prefixed DTB approach on our downstreams and it >>> works without major issues. >> >> You likely have nothing like the deployment scripts for LAVA >> (isar-cip-core, xenomai-images). It breaks them, and we need extra logic >> because of the mangled names and paths. >> >>> >>> Regarding splitting TMPDIRs: this would break at least one of our >>> downstreams. We have a setup with two multiconfigs — one for rescue >>> (with its own rootfs, kernel, etc.) and another regular one which >>> depends on the rescue one and needs to consume its deployed artifacts. >>> Splitting TMPDIRs is not viable in this case. >>> >> >> This has already been identified as problem, yes. OE does not use it >> either, only few downstreams. We are apparently overusing mc: or the >> deployment folder here. >> >>> >>> As for the release plan: we would like to target v1.1 rather than a >>> v1.0.1 hotfix, with the API expected to remain stable for some period. >> >> We must fix this soon or 1.0 will remain a no-go version. It will then >> happen the opposite of what "1.0" was aiming at: to signal maturity. >> >>> I propose that if a final solution can be found quickly, we hold v1.1 >>> until it is merged. Otherwise, v1.1 should be based on the prefixed DTB >>> patch. >>> >>> We do have a new proposal for the "final solution". Let me send it >>> under v6 DTB discussion. >>> >> >> I'm looking into it. >> >> Jan >> > > Just to make it clear (again), this is how OE deploys DTBs to images: > > build/tmp/deploy/images/qemusdc2/devicetree/*.dtb > > Didn't check yet, but there might even unfold the new subdirectory > structure (by vendor, mostly) under that folder. So this renaming here > is not getting us better aligned (to be fair: we were not aligned before). From the history of https://git.openembedded.org/openembedded-core/log/meta/classes-recipe/kernel-devicetree.bbclass the kernel recipe name was added to the devicetree file. it looks like the devicetree folder is created by https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/devicetree.bbclass to avoid a clash with the device tree deployed by the kernel. Quirin > > Jan > -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/a1e72665-6763-4190-a9e6-be2b98e67161%40siemens.com. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH 0/2] Rework deployment of image artifacts 2026-04-17 15:05 ` 'Jan Kiszka' via isar-users 2026-04-20 6:25 ` 'Quirin Gylstorff' via isar-users @ 2026-04-20 16:00 ` Zhihang Wei 1 sibling, 0 replies; 18+ messages in thread From: Zhihang Wei @ 2026-04-20 16:00 UTC (permalink / raw) To: Jan Kiszka, Felix Moessbauer, isar-users, Baurzhan Ismagulov Cc: quirin.gylstorff On 4/17/26 17:05, Jan Kiszka wrote: > On 17.04.26 16:39, 'Jan Kiszka' via isar-users wrote: >> On 17.04.26 16:15, Zhihang Wei wrote: >>> >>> On 4/16/26 18:01, Jan Kiszka wrote: >>>> On 16.04.26 17:51, Jan Kiszka wrote: >>>>> On 16.04.26 17:42, Zhihang Wei wrote: >>>>>> Applied to next, thanks. >>>>>> >>>>> I am repeating myself: We broken the deployment API in v1.0. This series >>>>> is breaking it once more, just differently (and rather unhandy for many >>>>> downstream users). >>>>> >>>>> Are we truly sure now that this is the FINAL solution, or do we plan for >>>>> n more API breakages? >>>>> >>>> But let's a assume we keep it like this: >>>> >>>> What is the plan for a v1.0.1 hotfix release? I'm seeing other patches >>>> being merged. Some would qualify to be part as well, another one is >>>> harmless but not a hotfix. So I'm asking before things possibly move on >>>> further. At least some users here are waiting to adopt v1.0.x. >>>> >>>> Jan >>>> >>> We have tested the prefixed DTB approach on our downstreams and it >>> works without major issues. >> You likely have nothing like the deployment scripts for LAVA >> (isar-cip-core, xenomai-images). It breaks them, and we need extra logic >> because of the mangled names and paths. >> Could you provide some steps to recreate the issue? >>> Regarding splitting TMPDIRs: this would break at least one of our >>> downstreams. We have a setup with two multiconfigs — one for rescue >>> (with its own rootfs, kernel, etc.) and another regular one which >>> depends on the rescue one and needs to consume its deployed artifacts. >>> Splitting TMPDIRs is not viable in this case. >>> >> This has already been identified as problem, yes. OE does not use it >> either, only few downstreams. We are apparently overusing mc: or the >> deployment folder here. >> >>> As for the release plan: we would like to target v1.1 rather than a >>> v1.0.1 hotfix, with the API expected to remain stable for some period. >> We must fix this soon or 1.0 will remain a no-go version. It will then >> happen the opposite of what "1.0" was aiming at: to signal maturity. I propose tagging v1.1 on 8c34bb25, with the revert and prefixing DTBs. >>> I propose that if a final solution can be found quickly, we hold v1.1 >>> until it is merged. Otherwise, v1.1 should be based on the prefixed DTB >>> patch. >>> >>> We do have a new proposal for the "final solution". Let me send it >>> under v6 DTB discussion. >>> >> I'm looking into it. >> >> Jan >> > Just to make it clear (again), this is how OE deploys DTBs to images: > > build/tmp/deploy/images/qemusdc2/devicetree/*.dtb > > Didn't check yet, but there might even unfold the new subdirectory > structure (by vendor, mostly) under that folder. So this renaming here > is not getting us better aligned (to be fair: we were not aligned before). > > Jan > In my case, DTB is deployed flat under the images directory: build/tmp-arm64/deploy/images/qemuarm64/foundation-v8--5.15.199+git0+78eca082b6_33aae9ebda-r0-qemuarm64-20260323124115.dtb Then OE has multiple deploy path patterns for DTB. Zhihang -- You received this message because you are subscribed to the Google Groups "isar-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/isar-users/7d035d84-87e4-437c-be05-5537b8b2d955%40ilbers.de. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2026-04-20 16:00 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2026-04-10 13:22 [PATCH 0/2] Rework deployment of image artifacts 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 1/2] Revert "meta: Deploy image build artifacts into distro- and image-specific subdirs" 'Felix Moessbauer' via isar-users 2026-04-10 13:22 ` [PATCH 2/2] prefix DTB files with PN in deploy dir 'Felix Moessbauer' via isar-users 2026-04-10 13:38 ` 'Jan Kiszka' via isar-users 2026-04-10 14:12 ` 'MOESSBAUER, Felix' via isar-users 2026-04-10 16:32 ` 'Jan Kiszka' via isar-users 2026-04-16 13:54 ` Zhihang Wei 2026-04-16 14:39 ` 'MOESSBAUER, Felix' via isar-users 2026-04-16 15:41 ` Zhihang Wei 2026-04-10 14:21 ` [PATCH 0/2] Rework deployment of image artifacts Zhihang Wei 2026-04-16 15:42 ` Zhihang Wei 2026-04-16 15:51 ` 'Jan Kiszka' via isar-users 2026-04-16 16:01 ` 'Jan Kiszka' via isar-users 2026-04-17 14:15 ` Zhihang Wei 2026-04-17 14:39 ` 'Jan Kiszka' via isar-users 2026-04-17 15:05 ` 'Jan Kiszka' via isar-users 2026-04-20 6:25 ` 'Quirin Gylstorff' via isar-users 2026-04-20 16:00 ` Zhihang Wei
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox