[PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Zhihang Wei]

Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
binaries to the deploy directory.

When different images for the same target (e.g., "-base" and "-debug")
are built in parallel, DTB deployment may fail because DTBs do not
contain image-specific components in their filenames, unlike the kernel
and initrd. As a result, artifacts from different builds may be written
to the same location.

Here we deploy the DTBs and other image artifacts to subdirectories,
with names of distro image encoded to the path.

Note that this results in separate copies of the same artifacts being
deployed for each image build.

Related topics on the mailing list:
https://lists.isar-build.org/isar-users/20250403170701.807745-1-badrikesh.prusty@siemens.com/T/#u
https://lists.isar-build.org/isar-users/20240705071856.904-1-cedric.hombourger@siemens.com/T/#u
https://lists.isar-build.org/isar-users/c426ad86-5cc5-42e6-8223-e7a7e5b3424en@googlegroups.com/T/#u
https://lists.isar-build.org/isar-users/20240416100746.5681-1-nicusor_huhulea@mentor.com/T/#u
https://lists.isar-build.org/isar-users/DB3PR10MB690820CF3DD2DCA71D822AF1E63B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
https://lists.isar-build.org/isar-users/DB3PR10MB690861E70EB246FEF845E253E64B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
https://lists.isar-build.org/isar-users/20240131144459.2386220-1-iskochilov@ilbers.de/T/#u

Changes since v8:
- Rebase on next.
- Document how this approach differs from OpenEmbedded.

Changes since v7:
- Fix SOB.

Changes since v6:
- Deploy DTBs and other image artifacts into distro- and
  image-specific subdirs.
- Shorten image artifact filenames.

Changes since v5:
- Fix isoimage-isohybrid-isar WIC plugin.
- Split testcases.
- Update wording.

Changes since v4:
- Rebase on next.
- Squash latest patch to first one.
- Fix deploy paths in initrd tests.

Changes since v3:
- Rebase on next.
- Fix target deploy dir path for installer.

Changes since v2:
- Patch 1: Consider also kernel suffix.
- Patch 2: Use separate testcase for possible dtb clashes.
- Minor cosmetic fixes.

Changes since v1:
- Separate `dtb-files` recipe used instead of linux one.
- Included older "[PATCH] Fix do_copy_boot_files error" into the
  series.

Anton Mikanovich (2):
  wic: Obtain real machine name in isoimage source plugin
  testsuite: Add testcases to check dtb deployment

Zhihang Wei (1):
  meta: Deploy image build artifacts into distro- and image-specific
    subdirs

 RECIPE-API-CHANGELOG.md                       | 77 +++++++++++++++++++
 .../installer-add-rootfs.bbclass              |  9 ++-
 meta/classes-recipe/image.bbclass             | 11 +--
 .../imagetypes_container.bbclass              |  2 +-
 meta/classes-recipe/imagetypes_wic.bbclass    |  2 +-
 meta/conf/bitbake.conf                        |  3 +-
 .../plugins/source/isoimage-isohybrid-isar.py |  6 +-
 testsuite/cibase.py                           |  2 +-
 testsuite/citest.py                           | 40 +++++++++-
 testsuite/start_vm.py                         |  2 +-
 10 files changed, 135 insertions(+), 19 deletions(-)

-- 
2.39.5

-- 
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/20260401104907.3365696-1-wzh%40ilbers.de.

[PATCH v9 1/3] wic: Obtain real machine name in isoimage source plugin

[Zhihang Wei]

From: Anton Mikanovich <amikan@ilbers.de>

The current implementation tries to obtain machine name from the deploy
directory name, which relies on hardcoded path format. Add MACHINE to
the WIC environment and read it in isoimage-isohybrid-isar.py to fix
that.

Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
---
 meta/classes-recipe/imagetypes_wic.bbclass                    | 2 +-
 .../scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/imagetypes_wic.bbclass b/meta/classes-recipe/imagetypes_wic.bbclass
index f31ea61f..a2687ef0 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"
+WICVARS += "DISTRO DISTRO_ARCH KERNEL_FILE MACHINE"
 
 python do_rootfs_wicenv () {
     wicvars = d.getVar('WICVARS')
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 fb6c6b39..0ed61fff 100644
--- a/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py
+++ b/meta/scripts/lib/wic/plugins/source/isoimage-isohybrid-isar.py
@@ -191,7 +191,9 @@ class IsoImagePlugin(SourcePlugin):
             if not image_type:
                 raise WicError("Couldn't find INITRAMFS_FSTYPES, exiting.")
 
-            machine = os.path.basename(initrd_dir)
+            machine = get_bitbake_var("MACHINE")
+            if not machine:
+                raise WicError("Couldn't find MACHINE, exiting.")
 
             pattern = '%s/%s*%s.%s' % (initrd_dir, image_name, machine, image_type)
             pattern = '%s/%s-%s-initrd.%s' % (initrd_dir, image_name, machine, image_type)
-- 
2.39.5

-- 
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/20260401104907.3365696-2-wzh%40ilbers.de.

[PATCH v9 2/3] testsuite: Add testcases to check dtb deployment

[Zhihang Wei]

From: Anton Mikanovich <amikan@ilbers.de>

Build several images with dtbs deployed to the same path.

 - test_dtb_deploy_distros

   Same machine, different distros, same image, same kernel, same dtb
   name and contents.

 - test_dtb_deploy_images

   Same machine, same distro, different images, same kernel, same dtb
   name and contents.

Both fail with:

ERROR: mc:phyboard-mira-bookworm:isar-image-base-1.0-r0 do_copy_boot_files: The recipe isar-image-base is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
NOTE: recipe isar-image-base-1.0-r0: task do_copy_boot_files: Failed
  build/tmp/deploy/images/phyboard-mira/imx6q-phytec-mira-rdk-nand.dtb
    (not matched to any task)
Please verify which recipe should provide the above files.

Signed-off-by: Anton Mikanovich <amikan@ilbers.de>
---
 testsuite/citest.py | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/testsuite/citest.py b/testsuite/citest.py
index ab28b68e..ca701422 100755
--- a/testsuite/citest.py
+++ b/testsuite/citest.py
@@ -677,6 +677,39 @@ class WicTest(CIBaseTest):
         )
 
 
+class DtbDeployTest(CIBaseTest):
+
+    """
+    Build some targets potentially causing DTB deploy issues.
+
+    :avocado: tags=dtbdeploy,full
+    """
+
+    def test_dtb_deploy_distros(self):
+        """
+        Cover case: Same machine, different distros
+        """
+        targets = [
+            'mc:phyboard-mira-bullseye:isar-image-base',
+            'mc:phyboard-mira-bookworm:isar-image-base',
+        ]
+
+        self.init()
+        self.perform_build_test(targets)
+
+    def test_dtb_deploy_images(self):
+        """
+        Cover case: Same machine/distro, different images
+        """
+        targets = [
+            'mc:phyboard-mira-bookworm:isar-image-base',
+            'mc:phyboard-mira-bookworm:isar-image-ci',
+        ]
+
+        self.init()
+        self.perform_build_test(targets)
+
+
 class NoCrossTest(CIBaseTest):
 
     """
-- 
2.39.5

-- 
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/20260401104907.3365696-3-wzh%40ilbers.de.

[PATCH v9 3/3] meta: Deploy image build artifacts into distro- and image-specific subdirs

[Zhihang Wei]

When building different distros or images for the same machine (e.g.
phyboard-mira-bullseye and phyboard-mira-bookworm, or isar-image-ci
and isar-image-base), artifacts with identical names (e.g. DTB files)
may be deployed to the same location, resulting file conflicts and
build failures.

Deploy image build artifacts into a subdirectory named
${DISTRO}-${IMAGE_PN} to avoid such collisions.

Since the directory now encodes the distro and image name, remove the
${DISTRO} and ${IMAGE_PN} prefixes from artifact filenames to
keep the names short and clear.

Fixes test_dtb_deploy_distros testcase:

ERROR: mc:phyboard-mira-bookworm:isar-image-base-1.0-r0 do_copy_boot_files: The recipe isar-image-base is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
NOTE: recipe isar-image-base-1.0-r0: task do_copy_boot_files: Failed
  build/tmp/deploy/images/phyboard-mira/imx6q-phytec-mira-rdk-nand.dtb
    (not matched to any task)
Please verify which recipe should provide the above files.

Signed-off-by: Zhihang Wei <wzh@ilbers.de>
---
 RECIPE-API-CHANGELOG.md                       | 77 +++++++++++++++++++
 .../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, 98 insertions(+), 17 deletions(-)

diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index e44b4b9d..a0badb74 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -972,3 +972,80 @@ we introduce the variables ``MMAPTOPT_NOEXPKEYSIGN`` and ``DISTRO_MM_OPTS``.
 While the former provides an argument to disable the key expiry checking, the
 latter allows users to inject custom options into ``mmdebstrap``. For details,
 see ``man mmdebstrap``. Use with care!
+
+### 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.
diff --git a/meta-isar/classes-recipe/installer-add-rootfs.bbclass b/meta-isar/classes-recipe/installer-add-rootfs.bbclass
index 2fa551bd..edf93016 100644
--- a/meta-isar/classes-recipe/installer-add-rootfs.bbclass
+++ b/meta-isar/classes-recipe/installer-add-rootfs.bbclass
@@ -13,9 +13,10 @@ INSTALLER_TARGET_IMAGES ??= "${INSTALLER_TARGET_IMAGE}"
 INSTALLER_TARGET_MC ??= "installer-target"
 INSTALLER_TARGET_DISTRO ??= "${DISTRO}"
 INSTALLER_TARGET_MACHINE ??= "${MACHINE}"
-INSTALLER_TARGET_DEPLOY_DIR_IMAGE ??= "${DEPLOY_DIR}/images/${INSTALLER_TARGET_MACHINE}"
+INSTALLER_TARGET_IMAGE ??= "${IMAGE_PN}"
+INSTALLER_TARGET_DEPLOY_DIR_IMAGE ??= "${DEPLOY_DIR}/images/${INSTALLER_TARGET_MACHINE}/${INSTALLER_TARGET_DISTRO}-${INSTALLER_TARGET_IMAGE}"
 
-IMAGE_DATA_FILE ??= "${INSTALLER_TARGET_IMAGE}-${INSTALLER_TARGET_DISTRO}-${INSTALLER_TARGET_MACHINE}"
+IMAGE_DATA_FILE ??= "${INSTALLER_TARGET_MACHINE}"
 IMAGE_DATA_POSTFIX ??= "wic.zst"
 IMAGE_DATA_POSTFIX:buster ??= "wic.xz"
 IMAGE_DATA_POSTFIX:bullseye ??= "wic.xz"
@@ -29,7 +30,7 @@ def get_installer_sources(d, suffix):
     target_machine = d.getVar('INSTALLER_TARGET_MACHINE')
     sources = []
     for image in installer_target_images:
-        image_data = f"{image}-{target_distro}-{target_machine}"
+        image_data = f"{target_machine}"
         sources.append(f"{target_deploy_dir}/{image_data}.{suffix}")
     return sources
 
@@ -41,7 +42,7 @@ def get_installer_destinations(d, suffix):
     target_machine = d.getVar('INSTALLER_TARGET_MACHINE')
     dests = []
     for image in installer_target_images:
-        image_data = f"{image}-{target_distro}-{target_machine}"
+        image_data = f"{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 afe6906e..d4f9e2c0 100644
--- a/meta/classes-recipe/image.bbclass
+++ b/meta/classes-recipe/image.bbclass
@@ -18,8 +18,9 @@ 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 of the image including distro&machine names
-IMAGE_FULLNAME = "${PN}-${DISTRO}-${MACHINE}"
+# Name the image as the machine name only, since the path includes distro name now
+IMAGE_FULLNAME = "${MACHINE}"
+IMAGE_PN = "${PN}"
 
 # Deprecated; this would be set to e.g. "${INITRAMFS_RECIPE}-${DISTRO}-${MACHINE}-initrd.img"
 INITRD_IMAGE ?= ""
@@ -29,7 +30,7 @@ INITRD_IMAGE ?= ""
 IMAGE_INITRD ?= ""
 
 # Name of the deployed initrd image
-INITRD_DEPLOY_FILE = "${@ d.getVar('IMAGE_INITRD') or '${PN}' }-${DISTRO}-${MACHINE}-initrd.img"
+INITRD_DEPLOY_FILE = "initrd.img"
 
 # Make sure dependent initramfs recipe is built
 do_image[depends] += "${@ '${IMAGE_INITRD}:do_build' if '${IMAGE_INITRD}' else '' }"
@@ -52,7 +53,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 ?= "${IMAGE_FULLNAME}-${KERNEL_FILE}"
+KERNEL_IMAGE ?= "${KERNEL_FILE}"
 
 # This defines the deployed dtbs for reuse by imagers
 DTB_FILES ?= ""
@@ -108,7 +109,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 ?= "${PN}-${DISTRO}-${MACHINE}"
+ROOTFS_PACKAGE_SUFFIX ?= "${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 ea15decf..1c5386a8 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 ?= "${PN}-${DISTRO}-${DISTRO_ARCH}"
+CONTAINER_IMAGE_NAME ?= "container-${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 0f84e715..7c544e5d 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -57,7 +57,8 @@ 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"
-DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}"
+IMAGE_PN ?= ""
+DEPLOY_DIR_IMAGE = "${DEPLOY_DIR}/images/${MACHINE}${@('/%s-%s' % (d.getVar('DISTRO'), d.getVar('IMAGE_PN'))) if d.getVar('IMAGE_PN') != '' else ''}"
 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 0ed61fff..eaef9c79 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/%s-%s-initrd.%s' % (initrd_dir, image_name, machine, image_type)
+            pattern = '%s/initrd.%s' % (initrd_dir, image_type)
             files = glob.glob(pattern)
             if files:
                 initrd = files[0]
diff --git a/testsuite/cibase.py b/testsuite/cibase.py
index fd6a3df9..fac2ab75 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 ca701422..f36da786 100755
--- a/testsuite/citest.py
+++ b/testsuite/citest.py
@@ -496,8 +496,9 @@ class InitRdBaseTest(CIBaseTest):
         super().init()
         self.deploy_dir = os.path.join(self.build_dir, 'tmp', 'deploy')
 
-    def deploy_dir_image(self, machine):
-        return os.path.join(self.deploy_dir, 'images', machine)
+    def deploy_dir_image(self, mc, image):
+        multiconfig = f"{mc}:{image}"
+        return CIUtils.getVars('DEPLOY_DIR_IMAGE', target=multiconfig)
 
     def dracut_in_image(self, targets):
         machine = 'qemuamd64'
@@ -526,7 +527,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(machine), initrd_image)
+        initrd_path = os.path.join(self.deploy_dir_image(mc, initrd), 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 57d169df..a37ffe82 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"{image}-{base}-{distro}-qemu{arch}.{image_type}"
+    rootfs_image = f"qemu{arch}.{image_type}"
 
     if image_type == 'ext4':
         kernel_image = deploy_dir_image + '/' + kernel_image
-- 
2.39.5

-- 
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/20260401104907.3365696-4-wzh%40ilbers.de.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Zhihang Wei]

Applied to next.

Zhihang

On 4/1/26 12:49, Zhihang Wei wrote:
> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
> binaries to the deploy directory.
>
> When different images for the same target (e.g., "-base" and "-debug")
> are built in parallel, DTB deployment may fail because DTBs do not
> contain image-specific components in their filenames, unlike the kernel
> and initrd. As a result, artifacts from different builds may be written
> to the same location.
>
> Here we deploy the DTBs and other image artifacts to subdirectories,
> with names of distro image encoded to the path.
>
> Note that this results in separate copies of the same artifacts being
> deployed for each image build.
>
> Related topics on the mailing list:
> https://lists.isar-build.org/isar-users/20250403170701.807745-1-badrikesh.prusty@siemens.com/T/#u
> https://lists.isar-build.org/isar-users/20240705071856.904-1-cedric.hombourger@siemens.com/T/#u
> https://lists.isar-build.org/isar-users/c426ad86-5cc5-42e6-8223-e7a7e5b3424en@googlegroups.com/T/#u
> https://lists.isar-build.org/isar-users/20240416100746.5681-1-nicusor_huhulea@mentor.com/T/#u
> https://lists.isar-build.org/isar-users/DB3PR10MB690820CF3DD2DCA71D822AF1E63B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
> https://lists.isar-build.org/isar-users/DB3PR10MB690861E70EB246FEF845E253E64B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
> https://lists.isar-build.org/isar-users/20240131144459.2386220-1-iskochilov@ilbers.de/T/#u
>
> Changes since v8:
> - Rebase on next.
> - Document how this approach differs from OpenEmbedded.
>
> Changes since v7:
> - Fix SOB.
>
> Changes since v6:
> - Deploy DTBs and other image artifacts into distro- and
>    image-specific subdirs.
> - Shorten image artifact filenames.
>
> Changes since v5:
> - Fix isoimage-isohybrid-isar WIC plugin.
> - Split testcases.
> - Update wording.
>
> Changes since v4:
> - Rebase on next.
> - Squash latest patch to first one.
> - Fix deploy paths in initrd tests.
>
> Changes since v3:
> - Rebase on next.
> - Fix target deploy dir path for installer.
>
> Changes since v2:
> - Patch 1: Consider also kernel suffix.
> - Patch 2: Use separate testcase for possible dtb clashes.
> - Minor cosmetic fixes.
>
> Changes since v1:
> - Separate `dtb-files` recipe used instead of linux one.
> - Included older "[PATCH] Fix do_copy_boot_files error" into the
>    series.
>
> Anton Mikanovich (2):
>    wic: Obtain real machine name in isoimage source plugin
>    testsuite: Add testcases to check dtb deployment
>
> Zhihang Wei (1):
>    meta: Deploy image build artifacts into distro- and image-specific
>      subdirs
>
>   RECIPE-API-CHANGELOG.md                       | 77 +++++++++++++++++++
>   .../installer-add-rootfs.bbclass              |  9 ++-
>   meta/classes-recipe/image.bbclass             | 11 +--
>   .../imagetypes_container.bbclass              |  2 +-
>   meta/classes-recipe/imagetypes_wic.bbclass    |  2 +-
>   meta/conf/bitbake.conf                        |  3 +-
>   .../plugins/source/isoimage-isohybrid-isar.py |  6 +-
>   testsuite/cibase.py                           |  2 +-
>   testsuite/citest.py                           | 40 +++++++++-
>   testsuite/start_vm.py                         |  2 +-
>   10 files changed, 135 insertions(+), 19 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/49cf7518-36ac-40f9-8c76-e82c096c91c0%40ilbers.de.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Quirin Gylstorff' via isar-users]

Hi,

On 4/1/26 12:49 PM, Zhihang Wei wrote:
> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
> binaries to the deploy directory.
> 
> When different images for the same target (e.g., "-base" and "-debug")
> are built in parallel, DTB deployment may fail because DTBs do not
> contain image-specific components in their filenames, unlike the kernel
> and initrd. As a result, artifacts from different builds may be written
> to the same location.
> 
> Here we deploy the DTBs and other image artifacts to subdirectories,
> with names of distro image encoded to the path.
> 
> Note that this results in separate copies of the same artifacts being
> deployed for each image build.
> 

This breaks isar-cip-core with release 1.0 with the unified kernel build 
as a custom initrd is no longer part of the same directory structure as 
the rest of the image. As the custom initramfs is a separate package it 
cannot aquire the PN of the rootfs. See 
https://github.com/ilbers/isar/blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/imagetypes_wic.bbclass#L215.

Also merge_wic_sbom does no longer work with a custom initrd.

Quirin


> Related topics on the mailing list:
> https://lists.isar-build.org/isar-users/20250403170701.807745-1-badrikesh.prusty@siemens.com/T/#u
> https://lists.isar-build.org/isar-users/20240705071856.904-1-cedric.hombourger@siemens.com/T/#u
> https://lists.isar-build.org/isar-users/c426ad86-5cc5-42e6-8223-e7a7e5b3424en@googlegroups.com/T/#u
> https://lists.isar-build.org/isar-users/20240416100746.5681-1-nicusor_huhulea@mentor.com/T/#u
> https://lists.isar-build.org/isar-users/DB3PR10MB690820CF3DD2DCA71D822AF1E63B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
> https://lists.isar-build.org/isar-users/DB3PR10MB690861E70EB246FEF845E253E64B2@DB3PR10MB6908.EURPRD10.PROD.OUTLOOK.COM/T/#u
> https://lists.isar-build.org/isar-users/20240131144459.2386220-1-iskochilov@ilbers.de/T/#u
> 
> Changes since v8:
> - Rebase on next.
> - Document how this approach differs from OpenEmbedded.
> 
> Changes since v7:
> - Fix SOB.
> 
> Changes since v6:
> - Deploy DTBs and other image artifacts into distro- and
>    image-specific subdirs.
> - Shorten image artifact filenames.
> 
> Changes since v5:
> - Fix isoimage-isohybrid-isar WIC plugin.
> - Split testcases.
> - Update wording.
> 
> Changes since v4:
> - Rebase on next.
> - Squash latest patch to first one.
> - Fix deploy paths in initrd tests.
> 
> Changes since v3:
> - Rebase on next.
> - Fix target deploy dir path for installer.
> 
> Changes since v2:
> - Patch 1: Consider also kernel suffix.
> - Patch 2: Use separate testcase for possible dtb clashes.
> - Minor cosmetic fixes.
> 
> Changes since v1:
> - Separate `dtb-files` recipe used instead of linux one.
> - Included older "[PATCH] Fix do_copy_boot_files error" into the
>    series.
> 
> Anton Mikanovich (2):
>    wic: Obtain real machine name in isoimage source plugin
>    testsuite: Add testcases to check dtb deployment
> 
> Zhihang Wei (1):
>    meta: Deploy image build artifacts into distro- and image-specific
>      subdirs
> 
>   RECIPE-API-CHANGELOG.md                       | 77 +++++++++++++++++++
>   .../installer-add-rootfs.bbclass              |  9 ++-
>   meta/classes-recipe/image.bbclass             | 11 +--
>   .../imagetypes_container.bbclass              |  2 +-
>   meta/classes-recipe/imagetypes_wic.bbclass    |  2 +-
>   meta/conf/bitbake.conf                        |  3 +-
>   .../plugins/source/isoimage-isohybrid-isar.py |  6 +-
>   testsuite/cibase.py                           |  2 +-
>   testsuite/citest.py                           | 40 +++++++++-
>   testsuite/start_vm.py                         |  2 +-
>   10 files changed, 135 insertions(+), 19 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/5d8d99b5-1f15-4faf-a86b-d7e77af8fc9b%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Jan Kiszka' via isar-users]

On 07.04.26 16:29, Quirin Gylstorff wrote:
> Hi,
> 
> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>> binaries to the deploy directory.
>>
>> When different images for the same target (e.g., "-base" and "-debug")
>> are built in parallel, DTB deployment may fail because DTBs do not
>> contain image-specific components in their filenames, unlike the kernel
>> and initrd. As a result, artifacts from different builds may be written
>> to the same location.
>>
>> Here we deploy the DTBs and other image artifacts to subdirectories,
>> with names of distro image encoded to the path.
>>
>> Note that this results in separate copies of the same artifacts being
>> deployed for each image build.
>>
> 
> This breaks isar-cip-core with release 1.0 with the unified kernel build
> as a custom initrd is no longer part of the same directory structure as
> the rest of the image. As the custom initramfs is a separate package it
> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
> imagetypes_wic.bbclass#L215.
> 
> Also merge_wic_sbom does no longer work with a custom initrd.
> 

The RECIPE-API-CHANGLOG says:

> 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.

And this is the problem: Customized initramfs logically belonged to full
images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
but there also with the traditional image file naming, flat.

Quirin tried some isar-cip-core conversion, and this is the new
deployment reality:

build/tmp/deploy/images/qemu-amd64/
├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
└── cip-core-trixie-cip-core-image
    ├── bootx64.efi
    ├── linux.efi
    ├── OVMF
    │   ├── OVMF_CODE_4M.fd
    │   ├── OVMF_CODE_4M.ms.fd
    │   ├── OVMF_CODE_4M.secboot.fd
    │   ├── OVMF_CODE_4M.secboot.strictnx.fd
    │   ├── OVMF_CODE_4M.snakeoil.fd
    │   ├── OVMF_VARS_4M.fd
    │   ├── OVMF_VARS_4M.ms.fd
    │   └── OVMF_VARS_4M.snakeoil.fd
    ├── qemu-amd64.cdx.json
    ├── qemu-amd64.dpkg_status
    ├── qemu-amd64-ebg.swu
    ├── qemu-amd64.manifest
    ├── qemu-amd64.spdx.json
    ├── qemu-amd64.squashfs
    ├── qemu-amd64.swu
    ├── qemu-amd64.uuid.env
    ├── qemu-amd64.wic
    ├── qemu-amd64.wic.bmap
    ├── qemu-amd64.wic.cdx.json
    ├── qemu-amd64.wic.manifest
    ├── qemu-amd64.wic.spdx.json
    └── vmlinuz

Already visually, this screams for improvements. But I'm afraid there
are more concrete issues hidden in even more complex layers.

And this is exactly why I strongly recommended to NOT merge these
changes in a hurry before the release anymore. We already needed 9
versions, and we were still not fully confident about the stability of
the new solution.

Looks like we now need a 1.0.1, either with a really consistent approach
or a revert. I would not recommend any downstreams affected by the
deploy dir changes to jump on 1.0 until we sorted out all details.

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/78d27f6a-bdec-49fb-a600-7a877c151084%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Quirin Gylstorff' via isar-users]

On 4/8/26 3:10 PM, Jan Kiszka wrote:
> On 07.04.26 16:29, Quirin Gylstorff wrote:
>> Hi,
>>
>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>> binaries to the deploy directory.
>>>
>>> When different images for the same target (e.g., "-base" and "-debug")
>>> are built in parallel, DTB deployment may fail because DTBs do not
>>> contain image-specific components in their filenames, unlike the kernel
>>> and initrd. As a result, artifacts from different builds may be written
>>> to the same location.
>>>
>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>> with names of distro image encoded to the path.
>>>
>>> Note that this results in separate copies of the same artifacts being
>>> deployed for each image build.
>>>
>>
>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>> as a custom initrd is no longer part of the same directory structure as
>> the rest of the image. As the custom initramfs is a separate package it
>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>> imagetypes_wic.bbclass#L215.
>>
>> Also merge_wic_sbom does no longer work with a custom initrd.
>>
> 
> The RECIPE-API-CHANGLOG says:
> 
>> 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.
> 
> And this is the problem: Customized initramfs logically belonged to full
> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
> but there also with the traditional image file naming, flat.
> 
> Quirin tried some isar-cip-core conversion, and this is the new
> deployment reality:
> 
> build/tmp/deploy/images/qemu-amd64/
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
> └── cip-core-trixie-cip-core-image
>      ├── bootx64.efi
>      ├── linux.efi
>      ├── OVMF
>      │   ├── OVMF_CODE_4M.fd
>      │   ├── OVMF_CODE_4M.ms.fd
>      │   ├── OVMF_CODE_4M.secboot.fd
>      │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>      │   ├── OVMF_CODE_4M.snakeoil.fd
>      │   ├── OVMF_VARS_4M.fd
>      │   ├── OVMF_VARS_4M.ms.fd
>      │   └── OVMF_VARS_4M.snakeoil.fd
>      ├── qemu-amd64.cdx.json
>      ├── qemu-amd64.dpkg_status
>      ├── qemu-amd64-ebg.swu
>      ├── qemu-amd64.manifest
>      ├── qemu-amd64.spdx.json
>      ├── qemu-amd64.squashfs
>      ├── qemu-amd64.swu
>      ├── qemu-amd64.uuid.env
>      ├── qemu-amd64.wic
>      ├── qemu-amd64.wic.bmap
>      ├── qemu-amd64.wic.cdx.json
>      ├── qemu-amd64.wic.manifest
>      ├── qemu-amd64.wic.spdx.json
>      └── vmlinuz
> 
> Already visually, this screams for improvements. But I'm afraid there
> are more concrete issues hidden in even more complex layers.
> 
> And this is exactly why I strongly recommended to NOT merge these
> changes in a hurry before the release anymore. We already needed 9
> versions, and we were still not fully confident about the stability of
> the new solution.
> 
> Looks like we now need a 1.0.1, either with a really consistent approach
> or a revert. I would not recommend any downstreams affected by the
> deploy dir changes to jump on 1.0 until we sorted out all details.

Why are we using now ${MACHINE}.* as identifier and not ${IMAGE_PN}. In 
a ci/cd script i prefer the IMAGE_PN as it shows me what I need to collect.

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/f9b6e995-6ca6-4abd-8f92-b35d62602ab0%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Jan Kiszka' via isar-users]

On 08.04.26 15:20, Quirin Gylstorff wrote:
> 
> 
> On 4/8/26 3:10 PM, Jan Kiszka wrote:
>> On 07.04.26 16:29, Quirin Gylstorff wrote:
>>> Hi,
>>>
>>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>>> binaries to the deploy directory.
>>>>
>>>> When different images for the same target (e.g., "-base" and "-debug")
>>>> are built in parallel, DTB deployment may fail because DTBs do not
>>>> contain image-specific components in their filenames, unlike the kernel
>>>> and initrd. As a result, artifacts from different builds may be written
>>>> to the same location.
>>>>
>>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>>> with names of distro image encoded to the path.
>>>>
>>>> Note that this results in separate copies of the same artifacts being
>>>> deployed for each image build.
>>>>
>>>
>>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>>> as a custom initrd is no longer part of the same directory structure as
>>> the rest of the image. As the custom initramfs is a separate package it
>>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>>> imagetypes_wic.bbclass#L215.
>>>
>>> Also merge_wic_sbom does no longer work with a custom initrd.
>>>
>>
>> The RECIPE-API-CHANGLOG says:
>>
>>> 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.
>>
>> And this is the problem: Customized initramfs logically belonged to full
>> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
>> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
>> but there also with the traditional image file naming, flat.
>>
>> Quirin tried some isar-cip-core conversion, and this is the new
>> deployment reality:
>>
>> build/tmp/deploy/images/qemu-amd64/
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
>> └── cip-core-trixie-cip-core-image
>>      ├── bootx64.efi
>>      ├── linux.efi
>>      ├── OVMF
>>      │   ├── OVMF_CODE_4M.fd
>>      │   ├── OVMF_CODE_4M.ms.fd
>>      │   ├── OVMF_CODE_4M.secboot.fd
>>      │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>>      │   ├── OVMF_CODE_4M.snakeoil.fd
>>      │   ├── OVMF_VARS_4M.fd
>>      │   ├── OVMF_VARS_4M.ms.fd
>>      │   └── OVMF_VARS_4M.snakeoil.fd
>>      ├── qemu-amd64.cdx.json
>>      ├── qemu-amd64.dpkg_status
>>      ├── qemu-amd64-ebg.swu
>>      ├── qemu-amd64.manifest
>>      ├── qemu-amd64.spdx.json
>>      ├── qemu-amd64.squashfs
>>      ├── qemu-amd64.swu
>>      ├── qemu-amd64.uuid.env
>>      ├── qemu-amd64.wic
>>      ├── qemu-amd64.wic.bmap
>>      ├── qemu-amd64.wic.cdx.json
>>      ├── qemu-amd64.wic.manifest
>>      ├── qemu-amd64.wic.spdx.json
>>      └── vmlinuz
>>
>> Already visually, this screams for improvements. But I'm afraid there
>> are more concrete issues hidden in even more complex layers.
>>
>> And this is exactly why I strongly recommended to NOT merge these
>> changes in a hurry before the release anymore. We already needed 9
>> versions, and we were still not fully confident about the stability of
>> the new solution.
>>
>> Looks like we now need a 1.0.1, either with a really consistent approach
>> or a revert. I would not recommend any downstreams affected by the
>> deploy dir changes to jump on 1.0 until we sorted out all details.
> 
> Why are we using now ${MACHINE}.* as identifier and not ${IMAGE_PN}. In
> a ci/cd script i prefer the IMAGE_PN as it shows me what I need to collect.
> 

You mean

cip-core-image.wic

rather than

qemu-amd64.wic

above, right?

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/a5f19b99-70e1-4ccb-af6e-bdd7fb072970%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Quirin Gylstorff' via isar-users]

On 4/8/26 3:27 PM, Jan Kiszka wrote:
> On 08.04.26 15:20, Quirin Gylstorff wrote:
>>
>>
>> On 4/8/26 3:10 PM, Jan Kiszka wrote:
>>> On 07.04.26 16:29, Quirin Gylstorff wrote:
>>>> Hi,
>>>>
>>>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>>>> binaries to the deploy directory.
>>>>>
>>>>> When different images for the same target (e.g., "-base" and "-debug")
>>>>> are built in parallel, DTB deployment may fail because DTBs do not
>>>>> contain image-specific components in their filenames, unlike the kernel
>>>>> and initrd. As a result, artifacts from different builds may be written
>>>>> to the same location.
>>>>>
>>>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>>>> with names of distro image encoded to the path.
>>>>>
>>>>> Note that this results in separate copies of the same artifacts being
>>>>> deployed for each image build.
>>>>>
>>>>
>>>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>>>> as a custom initrd is no longer part of the same directory structure as
>>>> the rest of the image. As the custom initramfs is a separate package it
>>>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>>>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>>>> imagetypes_wic.bbclass#L215.
>>>>
>>>> Also merge_wic_sbom does no longer work with a custom initrd.
>>>>
>>>
>>> The RECIPE-API-CHANGLOG says:
>>>
>>>> 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.
>>>
>>> And this is the problem: Customized initramfs logically belonged to full
>>> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
>>> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
>>> but there also with the traditional image file naming, flat.
>>>
>>> Quirin tried some isar-cip-core conversion, and this is the new
>>> deployment reality:
>>>
>>> build/tmp/deploy/images/qemu-amd64/
>>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
>>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
>>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
>>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
>>> └── cip-core-trixie-cip-core-image
>>>       ├── bootx64.efi
>>>       ├── linux.efi
>>>       ├── OVMF
>>>       │   ├── OVMF_CODE_4M.fd
>>>       │   ├── OVMF_CODE_4M.ms.fd
>>>       │   ├── OVMF_CODE_4M.secboot.fd
>>>       │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>>>       │   ├── OVMF_CODE_4M.snakeoil.fd
>>>       │   ├── OVMF_VARS_4M.fd
>>>       │   ├── OVMF_VARS_4M.ms.fd
>>>       │   └── OVMF_VARS_4M.snakeoil.fd
>>>       ├── qemu-amd64.cdx.json
>>>       ├── qemu-amd64.dpkg_status
>>>       ├── qemu-amd64-ebg.swu
>>>       ├── qemu-amd64.manifest
>>>       ├── qemu-amd64.spdx.json
>>>       ├── qemu-amd64.squashfs
>>>       ├── qemu-amd64.swu
>>>       ├── qemu-amd64.uuid.env
>>>       ├── qemu-amd64.wic
>>>       ├── qemu-amd64.wic.bmap
>>>       ├── qemu-amd64.wic.cdx.json
>>>       ├── qemu-amd64.wic.manifest
>>>       ├── qemu-amd64.wic.spdx.json
>>>       └── vmlinuz
>>>
>>> Already visually, this screams for improvements. But I'm afraid there
>>> are more concrete issues hidden in even more complex layers.
>>>
>>> And this is exactly why I strongly recommended to NOT merge these
>>> changes in a hurry before the release anymore. We already needed 9
>>> versions, and we were still not fully confident about the stability of
>>> the new solution.
>>>
>>> Looks like we now need a 1.0.1, either with a really consistent approach
>>> or a revert. I would not recommend any downstreams affected by the
>>> deploy dir changes to jump on 1.0 until we sorted out all details.
>>
>> Why are we using now ${MACHINE}.* as identifier and not ${IMAGE_PN}. In
>> a ci/cd script i prefer the IMAGE_PN as it shows me what I need to collect.
>>
> 
> You mean
> 
> cip-core-image.wic
> 
> rather than
> 
> qemu-amd64.wic
> 
> above, right?

Yes.

Also here is the current state in isar-cip-core 
https://gitlab.com/cip-project/cip-core/isar-cip-core/-/commits/qg/isar/update-to-1.0.

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/9a2851d9-7fc9-4951-bdff-e22a86ec3ed1%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Zhihang Wei]

On 4/8/26 15:10, Jan Kiszka wrote:
> On 07.04.26 16:29, Quirin Gylstorff wrote:
>> Hi,
>>
>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>> binaries to the deploy directory.
>>>
>>> When different images for the same target (e.g., "-base" and "-debug")
>>> are built in parallel, DTB deployment may fail because DTBs do not
>>> contain image-specific components in their filenames, unlike the kernel
>>> and initrd. As a result, artifacts from different builds may be written
>>> to the same location.
>>>
>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>> with names of distro image encoded to the path.
>>>
>>> Note that this results in separate copies of the same artifacts being
>>> deployed for each image build.
>>>
>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>> as a custom initrd is no longer part of the same directory structure as
>> the rest of the image. As the custom initramfs is a separate package it
>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>> imagetypes_wic.bbclass#L215.
>>
>> Also merge_wic_sbom does no longer work with a custom initrd.
>>
> The RECIPE-API-CHANGLOG says:
>
>> 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.
> And this is the problem: Customized initramfs logically belonged to full
> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
> but there also with the traditional image file naming, flat.
"remain unchanged" here means the customized initramfs keep the same
filenames and paths as before.

Customized initramfs are built by their own recipes. While building a
full image may trigger the build of a customized initramfs, they can
also be built separately. In contrast, the default initramfs is not a
standalone recipe but a task within the image build process. So
technically, customized initramfs are independent artifacts.

If CIP core associates a specific customized initramfs with an image
via DEPLOY_DIR_IMAGE, this assumption is affected by the new layout and
needs to be adapted accordingly.
> Quirin tried some isar-cip-core conversion, and this is the new
> deployment reality:
>
> build/tmp/deploy/images/qemu-amd64/
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
> └── cip-core-trixie-cip-core-image
>      ├── bootx64.efi
>      ├── linux.efi
>      ├── OVMF
>      │   ├── OVMF_CODE_4M.fd
>      │   ├── OVMF_CODE_4M.ms.fd
>      │   ├── OVMF_CODE_4M.secboot.fd
>      │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>      │   ├── OVMF_CODE_4M.snakeoil.fd
>      │   ├── OVMF_VARS_4M.fd
>      │   ├── OVMF_VARS_4M.ms.fd
>      │   └── OVMF_VARS_4M.snakeoil.fd
>      ├── qemu-amd64.cdx.json
>      ├── qemu-amd64.dpkg_status
>      ├── qemu-amd64-ebg.swu
>      ├── qemu-amd64.manifest
>      ├── qemu-amd64.spdx.json
>      ├── qemu-amd64.squashfs
>      ├── qemu-amd64.swu
>      ├── qemu-amd64.uuid.env
>      ├── qemu-amd64.wic
>      ├── qemu-amd64.wic.bmap
>      ├── qemu-amd64.wic.cdx.json
>      ├── qemu-amd64.wic.manifest
>      ├── qemu-amd64.wic.spdx.json
>      └── vmlinuz
>
> Already visually, this screams for improvements. But I'm afraid there
> are more concrete issues hidden in even more complex layers.
>
> And this is exactly why I strongly recommended to NOT merge these
> changes in a hurry before the release anymore. We already needed 9
> versions, and we were still not fully confident about the stability of
> the new solution.
If this kind of issue should be detected before merging, a CIP core
test case needs to be added to CI.

Zhihang
>
> Looks like we now need a 1.0.1, either with a really consistent approach
> or a revert. I would not recommend any downstreams affected by the
> deploy dir changes to jump on 1.0 until we sorted out all details.
>
> 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/6a128eca-1346-4774-a1c0-139cae457956%40ilbers.de.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['Jan Kiszka' via isar-users]

On 09.04.26 17:35, Zhihang Wei wrote:
> 
> On 4/8/26 15:10, Jan Kiszka wrote:
>> On 07.04.26 16:29, Quirin Gylstorff wrote:
>>> Hi,
>>>
>>> On 4/1/26 12:49 PM, Zhihang Wei wrote:
>>>> Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
>>>> binaries to the deploy directory.
>>>>
>>>> When different images for the same target (e.g., "-base" and "-debug")
>>>> are built in parallel, DTB deployment may fail because DTBs do not
>>>> contain image-specific components in their filenames, unlike the kernel
>>>> and initrd. As a result, artifacts from different builds may be written
>>>> to the same location.
>>>>
>>>> Here we deploy the DTBs and other image artifacts to subdirectories,
>>>> with names of distro image encoded to the path.
>>>>
>>>> Note that this results in separate copies of the same artifacts being
>>>> deployed for each image build.
>>>>
>>> This breaks isar-cip-core with release 1.0 with the unified kernel build
>>> as a custom initrd is no longer part of the same directory structure as
>>> the rest of the image. As the custom initramfs is a separate package it
>>> cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
>>> blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
>>> imagetypes_wic.bbclass#L215.
>>>
>>> Also merge_wic_sbom does no longer work with a custom initrd.
>>>
>> The RECIPE-API-CHANGLOG says:
>>
>>> 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.
>> And this is the problem: Customized initramfs logically belonged to full
>> images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
>> they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
>> but there also with the traditional image file naming, flat.
> "remain unchanged" here means the customized initramfs keep the same
> filenames and paths as before.
> 
> Customized initramfs are built by their own recipes. While building a
> full image may trigger the build of a customized initramfs, they can
> also be built separately. In contrast, the default initramfs is not a
> standalone recipe but a task within the image build process. So
> technically, customized initramfs are independent artifacts.
> 
> If CIP core associates a specific customized initramfs with an image
> via DEPLOY_DIR_IMAGE, this assumption is affected by the new layout and
> needs to be adapted accordingly.

The problem is that Isar upstream lacks a realistic use case for
customized initramfs. One would be to embed it into a rootfs, as
replacement of the default one. Quirin had the idea of packaging it for
that. Another would be feeding it into the UKI generation of
bootimg-efi-isar but that has unfortunately not yet been enabled for Isar.

>> Quirin tried some isar-cip-core conversion, and this is the new
>> deployment reality:
>>
>> build/tmp/deploy/images/qemu-amd64/
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.cdx.json
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64-initrd.img
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.manifest
>> ├── cip-core-initramfs-cip-core-trixie-qemu-amd64.spdx.json
>> └── cip-core-trixie-cip-core-image
>>      ├── bootx64.efi
>>      ├── linux.efi
>>      ├── OVMF
>>      │   ├── OVMF_CODE_4M.fd
>>      │   ├── OVMF_CODE_4M.ms.fd
>>      │   ├── OVMF_CODE_4M.secboot.fd
>>      │   ├── OVMF_CODE_4M.secboot.strictnx.fd
>>      │   ├── OVMF_CODE_4M.snakeoil.fd
>>      │   ├── OVMF_VARS_4M.fd
>>      │   ├── OVMF_VARS_4M.ms.fd
>>      │   └── OVMF_VARS_4M.snakeoil.fd
>>      ├── qemu-amd64.cdx.json
>>      ├── qemu-amd64.dpkg_status
>>      ├── qemu-amd64-ebg.swu
>>      ├── qemu-amd64.manifest
>>      ├── qemu-amd64.spdx.json
>>      ├── qemu-amd64.squashfs
>>      ├── qemu-amd64.swu
>>      ├── qemu-amd64.uuid.env
>>      ├── qemu-amd64.wic
>>      ├── qemu-amd64.wic.bmap
>>      ├── qemu-amd64.wic.cdx.json
>>      ├── qemu-amd64.wic.manifest
>>      ├── qemu-amd64.wic.spdx.json
>>      └── vmlinuz
>>
>> Already visually, this screams for improvements. But I'm afraid there
>> are more concrete issues hidden in even more complex layers.
>>
>> And this is exactly why I strongly recommended to NOT merge these
>> changes in a hurry before the release anymore. We already needed 9
>> versions, and we were still not fully confident about the stability of
>> the new solution.
> If this kind of issue should be detected before merging, a CIP core
> test case needs to be added to CI.

Unfortunately, this will need a process, not just a pipeline step
because breaking changes will need at least temporary patches to that layer.

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/f5026115-5c19-4535-8832-5dbc7f5b1a65%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Roberto A. Foglietta]

On Thu, 9 Apr 2026 at 18:38, 'Jan Kiszka' via isar-users
<isar-users@googlegroups.com> wrote:
>

[...]

> The problem is that Isar upstream lacks a realistic use case for
> customized initramfs. One would be to embed it into a rootfs, as
> replacement of the default one.

It lacks as far as you know. However, I am moving towards the rootfs
paradigm but the custom initramfs will not get out the scene anyway

+ 6ce8d8c - 2026-04-06 - Makefile: revisiting internal logic, p.8 (fix)
+ cfa451a - 2026-04-06 - Makefile: revisiting internal logic, p.8
+ 4878752 - 2026-04-06 - Makefile: revisiting internal logic, p.7
+ e20935f - 2026-04-06 - Makefile: revisiting internal logic, p.6
+ 6bc2f9a - 2026-04-06 - Makefile: revisiting internal logic, p.5
+ 289fe7e - 2026-04-06 - Makefile: revisiting internal logic, p.4
+ 59a9435 - 2026-04-06 - Makefile: revisiting internal logic, p.3
+ 4421faa - 2026-04-06 - Makefile: revisiting internal logic, p.2
+ e30267a - 2026-04-06 - Makefile: revisiting internal logic

If you wonder why, here we are: Europe talks about what other countries do.

https://github.com/robang74/uchaosys/blob/main/docs/uchaos-sponsorship-presentation.md#trust-sovereignty-for-security-strategy

Best regards, R-

-- 
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/CAJGKYO7anVNdqX2QzZLgeXQFNEDT2Wto89S0YLdLG-ESMXD2tw%40mail.gmail.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

['MOESSBAUER, Felix' via isar-users]

On Thu, 2026-04-09 at 17:35 +0200, Zhihang Wei wrote:
> On 4/8/26 15:10, Jan Kiszka wrote:
> > On 07.04.26 16:29, Quirin Gylstorff wrote:
> > > Hi,
> > > 
> > > On 4/1/26 12:49 PM, Zhihang Wei wrote:
> > > > Image task "do_copy_boot_files" deploys kernel, initrd, and device tree
> > > > binaries to the deploy directory.
> > > > 
> > > > When different images for the same target (e.g., "-base" and "-debug")
> > > > are built in parallel, DTB deployment may fail because DTBs do not
> > > > contain image-specific components in their filenames, unlike the kernel
> > > > and initrd. As a result, artifacts from different builds may be written
> > > > to the same location.
> > > > 
> > > > Here we deploy the DTBs and other image artifacts to subdirectories,
> > > > with names of distro image encoded to the path.
> > > > 
> > > > Note that this results in separate copies of the same artifacts being
> > > > deployed for each image build.
> > > > 
> > > This breaks isar-cip-core with release 1.0 with the unified kernel build
> > > as a custom initrd is no longer part of the same directory structure as
> > > the rest of the image. As the custom initramfs is a separate package it
> > > cannot aquire the PN of the rootfs. See https://github.com/ilbers/isar/
> > > blob/6504321e85b5fdc3bb5a83f042b77cb39cd11a6f/meta/classes-recipe/
> > > imagetypes_wic.bbclass#L215.
> > > 
> > > Also merge_wic_sbom does no longer work with a custom initrd.
> > > 
> > The RECIPE-API-CHANGLOG says:
> > 
> > > 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.
> > And this is the problem: Customized initramfs logically belonged to full
> > images, and so it was possible to address them DEPLOY_DIR_IMAGE. Now
> > they are "somewhere" - namely under the OE-standard DEPLOY_DIR_IMAGE,
> > but there also with the traditional image file naming, flat.
> "remain unchanged" here means the customized initramfs keep the same
> filenames and paths as before.
> 
> Customized initramfs are built by their own recipes. While building a
> full image may trigger the build of a customized initramfs, they can
> also be built separately. In contrast, the default initramfs is not a
> standalone recipe but a task within the image build process. So
> technically, customized initramfs are independent artifacts.
> 
> If CIP core associates a specific customized initramfs with an image
> via DEPLOY_DIR_IMAGE, this assumption is affected by the new layout and
> needs to be adapted accordingly.

> 
Hi, as I already wrote in [1], the root cause of the bug is that there
is currently no way to couple the path of the deployed initrd and the
imaging step. We previously relied on well-known path coincidence by
basically guessing how the initrd is named and checking if there is one
at the guessed path.

If the path is no longer predictable (with the Deploy DTBs patchset),
we cannot find the initrd.

What we actually need is a way to pass down a variable to both the
image and the initrd. This variable could be defined in local conf or
machine conf. Semantically, it belongs to the machine conf as there
also the kernel is selected. I can try to come up with a PoC for that,
but as of now, ISAR v1.0 is simply broken!

[1] 
https://github.com/ilbers/isar/commit/8986f02c27d0e94fb4945690b572d9e5a8cebc2f

Best regards,
Felix

-- 
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/767da583999ea8b35916395d040d46052d60e1cb.camel%40siemens.com.

Re: [PATCH v9 0/3] Deploy DTBs and other image artifacts into subdirs to avoid conflicts

[Roberto A. Foglietta]

On Thu, 9 Apr 2026 at 19:09, Roberto A. Foglietta
<roberto.foglietta@gmail.com> wrote:
>
> On Thu, 9 Apr 2026 at 18:38, 'Jan Kiszka' via isar-users
> <isar-users@googlegroups.com> wrote:
> >
>
> [...]
>
> > The problem is that Isar upstream lacks a realistic use case for
> > customized initramfs. One would be to embed it into a rootfs, as
> > replacement of the default one.
>
> It lacks as far as you know. However, I am moving towards the rootfs
> paradigm but the custom initramfs will not get out the scene anyway
>
> + 6ce8d8c - 2026-04-06 - Makefile: revisiting internal logic, p.8 (fix)
> + cfa451a - 2026-04-06 - Makefile: revisiting internal logic, p.8
> + 4878752 - 2026-04-06 - Makefile: revisiting internal logic, p.7
> + e20935f - 2026-04-06 - Makefile: revisiting internal logic, p.6
> + 6bc2f9a - 2026-04-06 - Makefile: revisiting internal logic, p.5
> + 289fe7e - 2026-04-06 - Makefile: revisiting internal logic, p.4
> + 59a9435 - 2026-04-06 - Makefile: revisiting internal logic, p.3
> + 4421faa - 2026-04-06 - Makefile: revisiting internal logic, p.2
> + e30267a - 2026-04-06 - Makefile: revisiting internal logic
>
> If you wonder why, here we are: Europe talks about what other countries do.
>
> https://github.com/robang74/uchaosys/blob/main/docs/uchaos-sponsorship-presentation.md#trust-sovereignty-for-security-strategy
>

Seriously?

+:git-shell:v067:uchaosys> sw ee84a56
commit ee84a561842e3608da0a914b33a05bf322979acd (HEAD -> v067,
origin/v067, origin/HEAD)
Author: Roberto A. Foglietta <roberto.foglietta@gmail.com>
Date:   Sat Apr 11 10:41:13 2026 +0200

    musl,cfng: lib.net download wget reression fix

    Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>

diff --git a/cnfg/Makefile.musl b/cnfg/Makefile.musl
index e6295b5..cdd7b8a 100644
--- a/cnfg/Makefile.musl
+++ b/cnfg/Makefile.musl
@@ -27,7 +27,7 @@ MPFR_SITE = $(GNU_SITE)/mpfr
 ISL_SITE = https://downloads.sourceforge.net/project/libisl/

 PCRE2_SITE = https://github.com/PCRE2Project/pcre2/releases/download/pcre2-$(PCRE2_VER)
-ZLIB_SITE = https://zlib.net/
+ZLIB_SITE = https://zlib.net

 MUSL_SITE = https://musl.libc.org/releases
 MUSL_REPO = https://git.musl-libc.org/git/musl
diff --git a/cnfg/musl-125x.config.mak b/cnfg/musl-125x.config.mak
index d92422e..273589a 100644
--- a/cnfg/musl-125x.config.mak
+++ b/cnfg/musl-125x.config.mak
@@ -49,7 +49,7 @@ LINUX_VER = 5.15.202

 # By default source archives are downloaded with wget. curl is also an option.

-DL_CMD = wget -c -O
+DL_CMD = wget -U "Mozilla/5.0" -c -O
 # DL_CMD = curl -C - -L -o

 # Check sha-1 hashes of downloaded source archives. On gnu systems this is
________________________________________________________________________
files in commited:
cnfg/Makefile.musl




-- 
Roberto A. Foglietta
+49.176.274.75.661
+39.349.33.30.697

-- 
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/CAJGKYO4XZmYCEKC87Q4mGyyQ889AYe2rx-QU%3DWnhTNtN%3DjthrQ%40mail.gmail.com.