[PATCH 0/2] handle DPKG_ARCH=all case for transitive deps

[PATCH 0/2] handle DPKG_ARCH=all case for transitive deps

['Felix Moessbauer' via isar-users]

This series fixes an issue with DPKG_ARCH=all packages that have
dependencies to other DPKG_ARCH=all packages. Hereby, the transitive
packages were built for the wrong architecture. The issue became
apparent when testing the SBOM series by Christoph, which builds
packages to be used during the ISAR build (not for the final target).

While fixing this, another issue surfaced where files are missing in
dpkg-raw packages.

Best regards,
Felix

Felix Moessbauer (2):
  dpkg-raw: add files to source package
  handle DPKG_ARCH=all case for transitive deps

 meta/classes/dpkg-raw.bbclass  |  4 ++--
 meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
 2 files changed, 19 insertions(+), 3 deletions(-)

-- 
2.50.1

-- 
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/20250820124140.281190-1-felix.moessbauer%40siemens.com.

[PATCH 1/2] dpkg-raw: add files to source package

['Felix Moessbauer' via isar-users]

In dpkg-raw, the user can place files in ${D} which are then installed
into the resulting binary package. Hereby, ${D} is a directory outside
of ${S} (since b19cd25) to not interfere with other data added to ${S}.
However, by that the files are not added to the source package. This
remained unnoticed, as the directory dh_install installs from is set
to absolute path, hence the installed files actually came from the
absolute path and not from the extracted source package. In case of
${PN} == ${BPN}, this path was always there as it has been created by
previous tasks. However, with the switch in 2ca3a7e5 to only build the
source package once, the path is not always there.

We fix this by adding the files to the source package (under image) and
install from a relative base. We further use a sub-path (image) in ${S}
as a temporary location to not run into the issue solved in b19cd25.

Fixes: 2ca3a7e5 ("dpkg-source: Build source package only once")
Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes/dpkg-raw.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
index a7bf204a..d4cb7d8a 100644
--- a/meta/classes/dpkg-raw.bbclass
+++ b/meta/classes/dpkg-raw.bbclass
@@ -5,7 +5,7 @@
 
 inherit dpkg
 
-D = "${WORKDIR}/image"
+D = "${S}/image"
 
 # Default to creating a binary-indep package
 DPKG_ARCH ??= "all"
@@ -30,6 +30,6 @@ do_prepare_build() {
 	cat <<EOF >> ${S}/debian/rules
 
 override_dh_install:
-	dh_install --sourcedir=${PP}/image
+	dh_install --sourcedir=image
 EOF
 }
-- 
2.50.1

-- 
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/20250820124140.281190-2-felix.moessbauer%40siemens.com.

[PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['Felix Moessbauer' via isar-users]

Arch=all packages might build depend on other arch=all packages, hence we
need to correctly model the dependency chain. Otherwise the transitive
dependencies are built for the distro arch instead of the native arch.

We implement this by dispatching the non-native variant of DPKG_ARCH=all
packages to the -native variant by adding a dependency. We further
replace the non-native do_deploy_dep task with a noop to preserve the
dependency chain.

Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
index babdfbd4..c2bba21f 100644
--- a/meta/classes/multiarch.bbclass
+++ b/meta/classes/multiarch.bbclass
@@ -29,7 +29,11 @@ python() {
             d.appendVar('BBCLASSEXTEND', ' compat')
 
     # build native separately only when it differs from the target variant
-    if not archIsAll and archDiffers:
+    # We must not short-circuit for DPKG_ARCH=all packages, as they might
+    # have transitive dependencies which need to be built for -native.
+    # This special handling for DPKG_ARCH=all packages is left to the
+    # multiarch_virtclass_handler
+    if archDiffers:
         d.appendVar('BBCLASSEXTEND', ' native')
     else:
         extend_provides(pn, 'native', d)
@@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
             d.setVar(var, ' '.join(multiarch_var))
 
     pn = e.data.getVar('PN')
+    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
+    archIsAll = d.getVar('DPKG_ARCH') == 'all'
     if pn.endswith('-compat'):
         e.data.setVar('BPN', pn[:-len('-compat')])
         e.data.appendVar('OVERRIDES', ':class-compat')
@@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
         e.data.appendVar('OVERRIDES', ':class-native')
         fixup_pn_in_vars(e.data)
         fixup_depends('-native', e.data)
+    elif archIsAll and archDiffers:
+        # Arch=all packages might build depend on other arch=all packages,
+        # hence we need to correctly model the dependency chain.
+        # We implement this by dispatching the non-native variant to the -native
+        # variant by adding a dependency. We further replace the non-native
+        # do_deploy_dep task with a noop to preserve the dependency chain.
+        e.data.setVar('do_deploy_deb', '')
+        bb.build.deltask('deploy_deb', e.data)
+        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
+        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
 }
 addhandler multiarch_virtclass_handler
 multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
-- 
2.50.1

-- 
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/20250820124140.281190-3-felix.moessbauer%40siemens.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

[Andreas Naumann]

Hi Felix, all,

Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> Arch=all packages might build depend on other arch=all packages, hence we
> need to correctly model the dependency chain. Otherwise the transitive
> dependencies are built for the distro arch instead of the native arch.
>
> We implement this by dispatching the non-native variant of DPKG_ARCH=all
> packages to the -native variant by adding a dependency. We further
> replace the non-native do_deploy_dep task with a noop to preserve the
> dependency chain.
>
> Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>   meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>   1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> index babdfbd4..c2bba21f 100644
> --- a/meta/classes/multiarch.bbclass
> +++ b/meta/classes/multiarch.bbclass
> @@ -29,7 +29,11 @@ python() {
>               d.appendVar('BBCLASSEXTEND', ' compat')
>   
>       # build native separately only when it differs from the target variant
> -    if not archIsAll and archDiffers:
> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> +    # have transitive dependencies which need to be built for -native.

Funny enough i suspected to have the same problem yesterday, but it 
turned out to
be different: When a package is single architecture only, e.g. arm64, it 
should not be
extended as native if HOST_ARCH is amd64.

So I added a check to BBCLASSEXTEND only if DPKG_ARCH != HOST_ARCH.

> +    # This special handling for DPKG_ARCH=all packages is left to the
> +    # multiarch_virtclass_handler
> +    if archDiffers:
>           d.appendVar('BBCLASSEXTEND', ' native')
Now, seeing your patch to remove the not-"all" case also, I wonder if 
that could be used
as the sole check before BBCLASSEXTEND. Like e.g.
archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
if isNative:
    d.appendVar('BBCLASSEXTEND', ' native')
>       else:
>           extend_provides(pn, 'native', d)

but now I wonder what the extend_provides is needed for. If HOST_ARCH == 
DISTRO_ARCH, what's
the use of providing a native variant?

But back to your Patch: Is it possible that -compat "all" packages also have
dependencies on other "all" packages, which in turn have dependencies on
architecture specific packages?

regards,
Andreas


> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>               d.setVar(var, ' '.join(multiarch_var))
>   
>       pn = e.data.getVar('PN')
> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>       if pn.endswith('-compat'):
>           e.data.setVar('BPN', pn[:-len('-compat')])
>           e.data.appendVar('OVERRIDES', ':class-compat')
> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>           e.data.appendVar('OVERRIDES', ':class-native')
>           fixup_pn_in_vars(e.data)
>           fixup_depends('-native', e.data)
> +    elif archIsAll and archDiffers:
> +        # Arch=all packages might build depend on other arch=all packages,
> +        # hence we need to correctly model the dependency chain.
> +        # We implement this by dispatching the non-native variant to the -native
> +        # variant by adding a dependency. We further replace the non-native
> +        # do_deploy_dep task with a noop to preserve the dependency chain.
> +        e.data.setVar('do_deploy_deb', '')
> +        bb.build.deltask('deploy_deb', e.data)
> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
>   }
>   addhandler multiarch_virtclass_handler
>   multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

-- 
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

-- 
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/24e7baaa-c347-4327-b06d-25c9a074a494%40emlix.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['MOESSBAUER, Felix' via isar-users]

On Wed, 2025-09-10 at 13:00 +0200, Andreas Naumann wrote:
> Hi Felix, all,
> 
> Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> > Arch=all packages might build depend on other arch=all packages, hence we
> > need to correctly model the dependency chain. Otherwise the transitive
> > dependencies are built for the distro arch instead of the native arch.
> > 
> > We implement this by dispatching the non-native variant of DPKG_ARCH=all
> > packages to the -native variant by adding a dependency. We further
> > replace the non-native do_deploy_dep task with a noop to preserve the
> > dependency chain.
> > 
> > Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---
> >   meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
> >   1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> > index babdfbd4..c2bba21f 100644
> > --- a/meta/classes/multiarch.bbclass
> > +++ b/meta/classes/multiarch.bbclass
> > @@ -29,7 +29,11 @@ python() {
> >               d.appendVar('BBCLASSEXTEND', ' compat')
> >   
> >       # build native separately only when it differs from the target variant
> > -    if not archIsAll and archDiffers:
> > +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> > +    # have transitive dependencies which need to be built for -native.
> 
> Funny enough i suspected to have the same problem yesterday, but it 
> turned out to
> be different: When a package is single architecture only, e.g. arm64, it 
> should not be
> extended as native if HOST_ARCH is amd64.
> 
> So I added a check to BBCLASSEXTEND only if DPKG_ARCH != HOST_ARCH.

Good catch. This case is currently not handled. But I would like to
have it in a separate patch, as it tackles another issue.

> 
> > +    # This special handling for DPKG_ARCH=all packages is left to the
> > +    # multiarch_virtclass_handler
> > +    if archDiffers:
> >           d.appendVar('BBCLASSEXTEND', ' native')
> Now, seeing your patch to remove the not-"all" case also, I wonder if 
> that could be used
> as the sole check before BBCLASSEXTEND. Like e.g.
> archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
> if isNative:
>     d.appendVar('BBCLASSEXTEND', ' native')
> >       else:
> >           extend_provides(pn, 'native', d)
> 
> but now I wonder what the extend_provides is needed for. If HOST_ARCH == 
> DISTRO_ARCH, what's
> the use of providing a native variant?

If we are building for the native arch, we can just add the -native
variants to the PROVIDES, so dependencies of packages depending
explicitly on <foo>-native can be resolved (without the need for extra
recipe variants).

> 
> But back to your Patch: Is it possible that -compat "all" packages also have
> dependencies on other "all" packages, which in turn have dependencies on
> architecture specific packages?

Good question. In general, package dependencies are resolved for the
native architecture (or the requested one). AFAIK this selection is
propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
should always resolve C as either :all or i386 (except if there is a
explicit cross-arch dependency specifier like :any, which we don't
model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
already be resolved correctly with this patch.

Tested by's are welcome :)

Felix

> 
> regards,
> Andreas
> 
> 
> > @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
> >               d.setVar(var, ' '.join(multiarch_var))
> >   
> >       pn = e.data.getVar('PN')
> > +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> > +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
> >       if pn.endswith('-compat'):
> >           e.data.setVar('BPN', pn[:-len('-compat')])
> >           e.data.appendVar('OVERRIDES', ':class-compat')
> > @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
> >           e.data.appendVar('OVERRIDES', ':class-native')
> >           fixup_pn_in_vars(e.data)
> >           fixup_depends('-native', e.data)
> > +    elif archIsAll and archDiffers:
> > +        # Arch=all packages might build depend on other arch=all packages,
> > +        # hence we need to correctly model the dependency chain.
> > +        # We implement this by dispatching the non-native variant to the -native
> > +        # variant by adding a dependency. We further replace the non-native
> > +        # do_deploy_dep task with a noop to preserve the dependency chain.
> > +        e.data.setVar('do_deploy_deb', '')
> > +        bb.build.deltask('deploy_deb', e.data)
> > +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> > +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
> >   }
> >   addhandler multiarch_virtclass_handler
> >   multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
> 
> -- 
> Andreas Naumann
> 
> emlix GmbH
> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
> Phone +49 (0)551 30664-0, e-mail info@emlix.com
> District Court of Goettingen, Registry Number HR B 3160
> Managing Directors: Heike Jordan, Dr. Uwe Kracke
> VAT ID No. DE 205 198 055
> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> http://www.emlix.com

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

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

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

[Andreas Naumann]

Am 11.09.25 um 12:20 schrieb MOESSBAUER, Felix:
> On Wed, 2025-09-10 at 13:00 +0200, Andreas Naumann wrote:
>> Hi Felix, all,
>>
>> Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
>>> Arch=all packages might build depend on other arch=all packages, hence we
>>> need to correctly model the dependency chain. Otherwise the transitive
>>> dependencies are built for the distro arch instead of the native arch.
>>>
>>> We implement this by dispatching the non-native variant of DPKG_ARCH=all
>>> packages to the -native variant by adding a dependency. We further
>>> replace the non-native do_deploy_dep task with a noop to preserve the
>>> dependency chain.
>>>
>>> Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>> ---
>>>    meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>>>    1 file changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
>>> index babdfbd4..c2bba21f 100644
>>> --- a/meta/classes/multiarch.bbclass
>>> +++ b/meta/classes/multiarch.bbclass
>>> @@ -29,7 +29,11 @@ python() {
>>>                d.appendVar('BBCLASSEXTEND', ' compat')
>>>    
>>>        # build native separately only when it differs from the target variant
>>> -    if not archIsAll and archDiffers:
>>> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
>>> +    # have transitive dependencies which need to be built for -native.
>> Funny enough i suspected to have the same problem yesterday, but it
>> turned out to
>> be different: When a package is single architecture only, e.g. arm64, it
>> should not be
>> extended as native if HOST_ARCH is amd64.
>>
>> So I added a check to BBCLASSEXTEND only if DPKG_ARCH != HOST_ARCH.
> Good catch. This case is currently not handled. But I would like to
> have it in a separate patch, as it tackles another issue.

I thought it's possible to make the nesting of if-clauses easier that
way, but after some more thought and fiddling... unfortunately it's the
opposite. So yes, separate patch.

>
>>> +    # This special handling for DPKG_ARCH=all packages is left to the
>>> +    # multiarch_virtclass_handler
>>> +    if archDiffers:
>>>            d.appendVar('BBCLASSEXTEND', ' native')
>> Now, seeing your patch to remove the not-"all" case also, I wonder if
>> that could be used
>> as the sole check before BBCLASSEXTEND. Like e.g.
>> archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
>> if isNative:
>>      d.appendVar('BBCLASSEXTEND', ' native')
>>>        else:
>>>            extend_provides(pn, 'native', d)
>> but now I wonder what the extend_provides is needed for. If HOST_ARCH ==
>> DISTRO_ARCH, what's
>> the use of providing a native variant?
> If we are building for the native arch, we can just add the -native
> variants to the PROVIDES, so dependencies of packages depending
> explicitly on <foo>-native can be resolved (without the need for extra
> recipe variants).

I understand that its a simpler solution in that case. But, maybe I'm not
seeing the obvious, what would require a -native package then? If 
target-arch
is host-arch, why would anything else than the base package be in any
dependency chain?

>
>> But back to your Patch: Is it possible that -compat "all" packages also have
>> dependencies on other "all" packages, which in turn have dependencies on
>> architecture specific packages?
> Good question. In general, package dependencies are resolved for the
> native architecture (or the requested one). AFAIK this selection is
> propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
> should always resolve C as either :all or i386 (except if there is a
> explicit cross-arch dependency specifier like :any, which we don't
> model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
> already be resolved correctly with this patch.
The patch doesnt change that -compat is "short-circuited" when 
archIsAll, doesnt it?
Or maybe I dont fully understand how the code works yet.
>
> Tested by's are welcome :)

I'm working with it and keep an eye on it.

regards,
Andreas

>
> Felix
>
>> regards,
>> Andreas
>>
>>
>>> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>>>                d.setVar(var, ' '.join(multiarch_var))
>>>    
>>>        pn = e.data.getVar('PN')
>>> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
>>> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>>>        if pn.endswith('-compat'):
>>>            e.data.setVar('BPN', pn[:-len('-compat')])
>>>            e.data.appendVar('OVERRIDES', ':class-compat')
>>> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>>>            e.data.appendVar('OVERRIDES', ':class-native')
>>>            fixup_pn_in_vars(e.data)
>>>            fixup_depends('-native', e.data)
>>> +    elif archIsAll and archDiffers:
>>> +        # Arch=all packages might build depend on other arch=all packages,
>>> +        # hence we need to correctly model the dependency chain.
>>> +        # We implement this by dispatching the non-native variant to the -native
>>> +        # variant by adding a dependency. We further replace the non-native
>>> +        # do_deploy_dep task with a noop to preserve the dependency chain.
>>> +        e.data.setVar('do_deploy_deb', '')
>>> +        bb.build.deltask('deploy_deb', e.data)
>>> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
>>> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
>>>    }
>>>    addhandler multiarch_virtclass_handler
>>>    multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>> -- 
>> Andreas Naumann
>>
>> emlix GmbH
>> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
>> Phone +49 (0)551 30664-0, e-mail info@emlix.com
>> District Court of Goettingen, Registry Number HR B 3160
>> Managing Directors: Heike Jordan, Dr. Uwe Kracke
>> VAT ID No. DE 205 198 055
>> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
>> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
>> http://www.emlix.com

-- 
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

-- 
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/f7ac34b9-c96b-4939-aec4-c72bcd471db9%40emlix.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['MOESSBAUER, Felix' via isar-users]

On Fri, 2025-09-12 at 17:50 +0200, Andreas Naumann wrote:
> Am 11.09.25 um 12:20 schrieb MOESSBAUER, Felix:
> > On Wed, 2025-09-10 at 13:00 +0200, Andreas Naumann wrote:
> > > Hi Felix, all,
> > > 
> > > Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> > > > Arch=all packages might build depend on other arch=all packages, hence we
> > > > need to correctly model the dependency chain. Otherwise the transitive
> > > > dependencies are built for the distro arch instead of the native arch.
> > > > 
> > > > We implement this by dispatching the non-native variant of DPKG_ARCH=all
> > > > packages to the -native variant by adding a dependency. We further
> > > > replace the non-native do_deploy_dep task with a noop to preserve the
> > > > dependency chain.
> > > > 
> > > > Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > > ---
> > > >    meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
> > > >    1 file changed, 17 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> > > > index babdfbd4..c2bba21f 100644
> > > > --- a/meta/classes/multiarch.bbclass
> > > > +++ b/meta/classes/multiarch.bbclass
> > > > @@ -29,7 +29,11 @@ python() {
> > > >                d.appendVar('BBCLASSEXTEND', ' compat')
> > > >    
> > > >        # build native separately only when it differs from the target variant
> > > > -    if not archIsAll and archDiffers:
> > > > +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> > > > +    # have transitive dependencies which need to be built for -native.
> > > Funny enough i suspected to have the same problem yesterday, but it
> > > turned out to
> > > be different: When a package is single architecture only, e.g. arm64, it
> > > should not be
> > > extended as native if HOST_ARCH is amd64.
> > > 
> > > So I added a check to BBCLASSEXTEND only if DPKG_ARCH != HOST_ARCH.
> > Good catch. This case is currently not handled. But I would like to
> > have it in a separate patch, as it tackles another issue.
> 
> I thought it's possible to make the nesting of if-clauses easier that
> way, but after some more thought and fiddling... unfortunately it's the
> opposite. So yes, separate patch.
> 
> > 
> > > > +    # This special handling for DPKG_ARCH=all packages is left to the
> > > > +    # multiarch_virtclass_handler
> > > > +    if archDiffers:
> > > >            d.appendVar('BBCLASSEXTEND', ' native')
> > > Now, seeing your patch to remove the not-"all" case also, I wonder if
> > > that could be used
> > > as the sole check before BBCLASSEXTEND. Like e.g.
> > > archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
> > > if isNative:
> > >      d.appendVar('BBCLASSEXTEND', ' native')
> > > >        else:
> > > >            extend_provides(pn, 'native', d)
> > > but now I wonder what the extend_provides is needed for. If HOST_ARCH ==
> > > DISTRO_ARCH, what's
> > > the use of providing a native variant?
> > If we are building for the native arch, we can just add the -native
> > variants to the PROVIDES, so dependencies of packages depending
> > explicitly on <foo>-native can be resolved (without the need for extra
> > recipe variants).
> 
> I understand that its a simpler solution in that case. But, maybe I'm not
> seeing the obvious, what would require a -native package then? If 
> target-arch
> is host-arch, why would anything else than the base package be in any
> dependency chain?

Consider the case where you have a documentation generator in your
dependency chain. This should always run in the native arch. In Debian,
this build dependency would be annotated with <foo>:any. In ISAR, you
need to annotate it with -native, to ensure that always the native
version is built, no matter what is DISTRO_ARCH.

> 
> > 
> > > But back to your Patch: Is it possible that -compat "all" packages also have
> > > dependencies on other "all" packages, which in turn have dependencies on
> > > architecture specific packages?
> > Good question. In general, package dependencies are resolved for the
> > native architecture (or the requested one). AFAIK this selection is
> > propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
> > should always resolve C as either :all or i386 (except if there is a
> > explicit cross-arch dependency specifier like :any, which we don't
> > model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
> > already be resolved correctly with this patch.
> The patch doesnt change that -compat is "short-circuited" when 
> archIsAll, doesnt it?
> Or maybe I dont fully understand how the code works yet.
> > 
> > Tested by's are welcome :)
> 
> I'm working with it and keep an eye on it.

Thanks!

If there are no other comments, this patchset is ready to be merged.

Felix


-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
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/96bbe4d4fa98a89ca8ee07dd8100b1a936b394d5.camel%40siemens.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

[Andreas Naumann]

Hi Felix,

Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> Arch=all packages might build depend on other arch=all packages, hence we
> need to correctly model the dependency chain. Otherwise the transitive
> dependencies are built for the distro arch instead of the native arch.
>
> We implement this by dispatching the non-native variant of DPKG_ARCH=all
> packages to the -native variant by adding a dependency. We further
> replace the non-native do_deploy_dep task with a noop to preserve the
> dependency chain.
>
> Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>   meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>   1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> index babdfbd4..c2bba21f 100644
> --- a/meta/classes/multiarch.bbclass
> +++ b/meta/classes/multiarch.bbclass
> @@ -29,7 +29,11 @@ python() {
>               d.appendVar('BBCLASSEXTEND', ' compat')
>   
>       # build native separately only when it differs from the target variant
> -    if not archIsAll and archDiffers:
> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> +    # have transitive dependencies which need to be built for -native.
> +    # This special handling for DPKG_ARCH=all packages is left to the
> +    # multiarch_virtclass_handler
> +    if archDiffers:
>           d.appendVar('BBCLASSEXTEND', ' native')
>       else:
>           extend_provides(pn, 'native', d)
> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>               d.setVar(var, ' '.join(multiarch_var))
>   
>       pn = e.data.getVar('PN')
> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>       if pn.endswith('-compat'):
>           e.data.setVar('BPN', pn[:-len('-compat')])
>           e.data.appendVar('OVERRIDES', ':class-compat')
> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>           e.data.appendVar('OVERRIDES', ':class-native')
>           fixup_pn_in_vars(e.data)
>           fixup_depends('-native', e.data)
> +    elif archIsAll and archDiffers:
> +        # Arch=all packages might build depend on other arch=all packages,
> +        # hence we need to correctly model the dependency chain.
> +        # We implement this by dispatching the non-native variant to the -native
> +        # variant by adding a dependency. We further replace the non-native
> +        # do_deploy_dep task with a noop to preserve the dependency chain.
> +        e.data.setVar('do_deploy_deb', '')
> +        bb.build.deltask('deploy_deb', e.data)
> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')

I have now done some more testing and unfortunately find that this 
causes failures when building the -native variant of some dpkg-raw 
packages we have. We use them for certain config files and they are 
intended for the target. I dont know why exactly they fail and I'm sure 
this could be fixed, but actually there is no need to build those 
packages in the native environment. So I'm somewhat surprised to see 
that and could image that this causes confusion for others that dont 
know about the "all" intricacies as well.

Another observation that I see is that dpkg-prebuilt "any" packages, 
which are probably in the dependency chain of an "all" package, now are 
always also built as -native, even though they are needed for the target 
only.

best,
Andras

>   }
>   addhandler multiarch_virtclass_handler
>   multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

-- 
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

-- 
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/05c06d5d-5248-4d56-b470-a096411b2844%40emlix.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['MOESSBAUER, Felix' via isar-users]

On Mon, 2025-09-15 at 19:49 +0200, Andreas Naumann wrote:
> Hi Felix,
> 
> Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> > Arch=all packages might build depend on other arch=all packages, hence we
> > need to correctly model the dependency chain. Otherwise the transitive
> > dependencies are built for the distro arch instead of the native arch.
> > 
> > We implement this by dispatching the non-native variant of DPKG_ARCH=all
> > packages to the -native variant by adding a dependency. We further
> > replace the non-native do_deploy_dep task with a noop to preserve the
> > dependency chain.
> > 
> > Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > ---
> >   meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
> >   1 file changed, 17 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> > index babdfbd4..c2bba21f 100644
> > --- a/meta/classes/multiarch.bbclass
> > +++ b/meta/classes/multiarch.bbclass
> > @@ -29,7 +29,11 @@ python() {
> >               d.appendVar('BBCLASSEXTEND', ' compat')
> >   
> >       # build native separately only when it differs from the target variant
> > -    if not archIsAll and archDiffers:
> > +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> > +    # have transitive dependencies which need to be built for -native.
> > +    # This special handling for DPKG_ARCH=all packages is left to the
> > +    # multiarch_virtclass_handler
> > +    if archDiffers:
> >           d.appendVar('BBCLASSEXTEND', ' native')
> >       else:
> >           extend_provides(pn, 'native', d)
> > @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
> >               d.setVar(var, ' '.join(multiarch_var))
> >   
> >       pn = e.data.getVar('PN')
> > +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> > +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
> >       if pn.endswith('-compat'):
> >           e.data.setVar('BPN', pn[:-len('-compat')])
> >           e.data.appendVar('OVERRIDES', ':class-compat')
> > @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
> >           e.data.appendVar('OVERRIDES', ':class-native')
> >           fixup_pn_in_vars(e.data)
> >           fixup_depends('-native', e.data)
> > +    elif archIsAll and archDiffers:
> > +        # Arch=all packages might build depend on other arch=all packages,
> > +        # hence we need to correctly model the dependency chain.
> > +        # We implement this by dispatching the non-native variant to the -native
> > +        # variant by adding a dependency. We further replace the non-native
> > +        # do_deploy_dep task with a noop to preserve the dependency chain.
> > +        e.data.setVar('do_deploy_deb', '')
> > +        bb.build.deltask('deploy_deb', e.data)
> > +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> > +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
> 
> I have now done some more testing and unfortunately find that this 
> causes failures when building the -native variant of some dpkg-raw 
> packages we have.
> 

Hi, do you have an example for such a package? Just to be clear: There
is no "native" variant of a dpkg-raw package. The dpkg-raw packages are
always build on the host architecture (in bitbake terms) and of Debian
arch=all.

> We use them for certain config files and they are 
> intended for the target.
> 

Do these configs contain data that is not the same on all
architectures? If so, DPKG_ARCH="all" is wrong.

> I dont know why exactly they fail and I'm sure 
> this could be fixed, but actually there is no need to build those 
> packages in the native environment.
> 

There is need to do so, as otherwise we emulate the build process which
is super slow.

> So I'm somewhat surprised to see 
> that and could image that this causes confusion for others that dont 
> know about the "all" intricacies as well.

Probably, but in the end we are building a debian system and by that
the users should be aware of the debian architecture specifiers.

> 
> Another observation that I see is that dpkg-prebuilt "any" packages, 
> which are probably in the dependency chain of an "all" package, now are 
> always also built as -native, even though they are needed for the target 
> only.

Same here, even if bitbake tells you that they are build as "-native",
there is no difference in the output, as the binary is simply copied.

Best regards,
Felix

> 
> best,
> Andras
> 
> >   }
> >   addhandler multiarch_virtclass_handler
> >   multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
> 
> -- 
> Andreas Naumann
> 
> emlix GmbH
> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
> Phone +49 (0)551 30664-0, e-mail info@emlix.com
> District Court of Goettingen, Registry Number HR B 3160
> Managing Directors: Heike Jordan, Dr. Uwe Kracke
> VAT ID No. DE 205 198 055
> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> http://www.emlix.com

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
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/9af00c922ab12ee5961d377babb3a87f49efac6c.camel%40siemens.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

[Andreas Naumann]

Hi Felix, all

Am 16.09.25 um 09:16 schrieb MOESSBAUER, Felix:
> On Mon, 2025-09-15 at 19:49 +0200, Andreas Naumann wrote:
>> Hi Felix,
>>
>> Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
>>> Arch=all packages might build depend on other arch=all packages, hence we
>>> need to correctly model the dependency chain. Otherwise the transitive
>>> dependencies are built for the distro arch instead of the native arch.
>>>
>>> We implement this by dispatching the non-native variant of DPKG_ARCH=all
>>> packages to the -native variant by adding a dependency. We further
>>> replace the non-native do_deploy_dep task with a noop to preserve the
>>> dependency chain.
>>>
>>> Co-developed-by: Adriaan Schmidt<adriaan.schmidt@siemens.com>
>>> Signed-off-by: Felix Moessbauer<felix.moessbauer@siemens.com>
>>> ---
>>>    meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>>>    1 file changed, 17 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
>>> index babdfbd4..c2bba21f 100644
>>> --- a/meta/classes/multiarch.bbclass
>>> +++ b/meta/classes/multiarch.bbclass
>>> @@ -29,7 +29,11 @@ python() {
>>>                d.appendVar('BBCLASSEXTEND', ' compat')
>>>    
>>>        # build native separately only when it differs from the target variant
>>> -    if not archIsAll and archDiffers:
>>> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
>>> +    # have transitive dependencies which need to be built for -native.
>>> +    # This special handling for DPKG_ARCH=all packages is left to the
>>> +    # multiarch_virtclass_handler
>>> +    if archDiffers:
>>>            d.appendVar('BBCLASSEXTEND', ' native')
>>>        else:
>>>            extend_provides(pn, 'native', d)
>>> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>>>                d.setVar(var, ' '.join(multiarch_var))
>>>    
>>>        pn = e.data.getVar('PN')
>>> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
>>> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>>>        if pn.endswith('-compat'):
>>>            e.data.setVar('BPN', pn[:-len('-compat')])
>>>            e.data.appendVar('OVERRIDES', ':class-compat')
>>> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>>>            e.data.appendVar('OVERRIDES', ':class-native')
>>>            fixup_pn_in_vars(e.data)
>>>            fixup_depends('-native', e.data)
>>> +    elif archIsAll and archDiffers:
>>> +        # Arch=all packages might build depend on other arch=all packages,
>>> +        # hence we need to correctly model the dependency chain.
>>> +        # We implement this by dispatching the non-native variant to the -native
>>> +        # variant by adding a dependency. We further replace the non-native
>>> +        # do_deploy_dep task with a noop to preserve the dependency chain.
>>> +        e.data.setVar('do_deploy_deb', '')
>>> +        bb.build.deltask('deploy_deb', e.data)
>>> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
>>> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
>> I have now done some more testing and unfortunately find that this
>> causes failures when building the -native variant of some dpkg-raw
>> packages we have.
>>
> Hi, do you have an example for such a package? Just to be clear: There
> is no "native" variant of a dpkg-raw package. The dpkg-raw packages are
> always build on the host architecture (in bitbake terms) and of Debian
> arch=all.
>
>> We use them for certain config files and they are
>> intended for the target.
>>
> Do these configs contain data that is not the same on all
> architectures? If so, DPKG_ARCH="all" is wrong.

After some debugging, it seems to be a combination of your patch and 
"2ca3a7e dpkg-source: Build source package only once". There is no 
problem building our dpkg-raw packages explicitly in the non-native 
form, e.g. in the host environment for the target arch.
But through your patch, the package also runs as -native, which then 
triggers a problem with 2ca3a7e.

... I only now discover that the other part of your patchset "dpkg-raw: 
add files to source package" fixes this. Ok.

However, because of this I went digging on why you introduced the patch. 
And I wonder why sbom-chroot doesn't just depend on 
python3-debsbom-native directly? (Which still breaks as long as 2ca3a7e 
sets the dependency on a function of the non-native package).


>> I dont know why exactly they fail and I'm sure
>> this could be fixed, but actually there is no need to build those
>> packages in the native environment.
>>
> There is need to do so, as otherwise we emulate the build process which
> is super slow.
Yes you're right. I meant there is no need to build them *for* the 
native architecture.
>> So I'm somewhat surprised to see
>> that and could image that this causes confusion for others that dont
>> know about the "all" intricacies as well.
> Probably, but in the end we are building a debian system and by that
> the users should be aware of the debian architecture specifiers.
Yes sure, they were new to me, but no problem, they are not that 
complicated.

But when I deliberately build -native packages (which I assume to be a 
valid use case according to the doc), and somehow the buildsystem goes 
back and forth running functions from the native and the base package, 
it's difficult to follow why that would be necessary. It doesnt make for 
ease of debugging when working on new packages either.

For the use cases I have in sight right now it would be fine if a 
package build breaks because it cannot be done cross-architecture. I'd 
hope to being able to fix this by either improving the package or making 
sure to call it -native only. But if that's not what the expectation is 
for Debian Crossbuilding I'm eager to learn.

best regards,
Andreas

>> Another observation that I see is that dpkg-prebuilt "any" packages,
>> which are probably in the dependency chain of an "all" package, now are
>> always also built as -native, even though they are needed for the target
>> only.
> Same here, even if bitbake tells you that they are build as "-native",
> there is no difference in the output, as the binary is simply copied.
>
> Best regards,
> Felix
>
>> best,
>> Andras
>>
>>>    }
>>>    addhandler multiarch_virtclass_handler
>>>    multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>> -- 
>> Andreas Naumann
>>
>> emlix GmbH
>> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
>> Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
>> District Court of Goettingen, Registry Number HR B 3160
>> Managing Directors: Heike Jordan, Dr. Uwe Kracke
>> VAT ID No. DE 205 198 055
>> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
>> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
>> http://www.emlix.com

-- 
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

-- 
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/45ecefef-bbc3-4506-b9b3-c945d0d77e65%40emlix.com.

Re: [PATCH 1/2] dpkg-raw: add files to source package

[Anton Mikanovich]

20/08/2025 15:41, 'Felix Moessbauer' via isar-users wrote:
> In dpkg-raw, the user can place files in ${D} which are then installed
> into the resulting binary package. Hereby, ${D} is a directory outside
> of ${S} (since b19cd25) to not interfere with other data added to ${S}.
> However, by that the files are not added to the source package. This
> remained unnoticed, as the directory dh_install installs from is set
> to absolute path, hence the installed files actually came from the
> absolute path and not from the extracted source package. In case of
> ${PN} == ${BPN}, this path was always there as it has been created by
> previous tasks. However, with the switch in 2ca3a7e5 to only build the
> source package once, the path is not always there.
>
> We fix this by adding the files to the source package (under image) and
> install from a relative base. We further use a sub-path (image) in ${S}
> as a temporary location to not run into the issue solved in b19cd25.
>
> Fixes: 2ca3a7e5 ("dpkg-source: Build source package only once")
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
p1 was applied to next, thanks.

-- 
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/5da617f1-ea5a-4838-91ff-da5b18c7e14a%40ilbers.de.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['MOESSBAUER, Felix' via isar-users]

On Fri, 2025-09-19 at 09:15 +0200, Andreas Naumann wrote:
> Hi Felix, all
> 
> Am 16.09.25 um 09:16 schrieb MOESSBAUER, Felix:
> > On Mon, 2025-09-15 at 19:49 +0200, Andreas Naumann wrote:
> > > Hi Felix,
> > > 
> > > Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
> > > > Arch=all packages might build depend on other arch=all packages, hence we
> > > > need to correctly model the dependency chain. Otherwise the transitive
> > > > dependencies are built for the distro arch instead of the native arch.
> > > > 
> > > > We implement this by dispatching the non-native variant of DPKG_ARCH=all
> > > > packages to the -native variant by adding a dependency. We further
> > > > replace the non-native do_deploy_dep task with a noop to preserve the
> > > > dependency chain.
> > > > 
> > > > Co-developed-by: Adriaan Schmidt<adriaan.schmidt@siemens.com>
> > > > Signed-off-by: Felix Moessbauer<felix.moessbauer@siemens.com>
> > > > ---
> > > >    meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
> > > >    1 file changed, 17 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> > > > index babdfbd4..c2bba21f 100644
> > > > --- a/meta/classes/multiarch.bbclass
> > > > +++ b/meta/classes/multiarch.bbclass
> > > > @@ -29,7 +29,11 @@ python() {
> > > >                d.appendVar('BBCLASSEXTEND', ' compat')
> > > >    
> > > >        # build native separately only when it differs from the target variant
> > > > -    if not archIsAll and archDiffers:
> > > > +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> > > > +    # have transitive dependencies which need to be built for -native.
> > > > +    # This special handling for DPKG_ARCH=all packages is left to the
> > > > +    # multiarch_virtclass_handler
> > > > +    if archDiffers:
> > > >            d.appendVar('BBCLASSEXTEND', ' native')
> > > >        else:
> > > >            extend_provides(pn, 'native', d)
> > > > @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
> > > >                d.setVar(var, ' '.join(multiarch_var))
> > > >    
> > > >        pn = e.data.getVar('PN')
> > > > +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> > > > +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
> > > >        if pn.endswith('-compat'):
> > > >            e.data.setVar('BPN', pn[:-len('-compat')])
> > > >            e.data.appendVar('OVERRIDES', ':class-compat')
> > > > @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
> > > >            e.data.appendVar('OVERRIDES', ':class-native')
> > > >            fixup_pn_in_vars(e.data)
> > > >            fixup_depends('-native', e.data)
> > > > +    elif archIsAll and archDiffers:
> > > > +        # Arch=all packages might build depend on other arch=all packages,
> > > > +        # hence we need to correctly model the dependency chain.
> > > > +        # We implement this by dispatching the non-native variant to the -native
> > > > +        # variant by adding a dependency. We further replace the non-native
> > > > +        # do_deploy_dep task with a noop to preserve the dependency chain.
> > > > +        e.data.setVar('do_deploy_deb', '')
> > > > +        bb.build.deltask('deploy_deb', e.data)
> > > > +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> > > > +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
> > > I have now done some more testing and unfortunately find that this
> > > causes failures when building the -native variant of some dpkg-raw
> > > packages we have.
> > > 
> > Hi, do you have an example for such a package? Just to be clear: There
> > is no "native" variant of a dpkg-raw package. The dpkg-raw packages are
> > always build on the host architecture (in bitbake terms) and of Debian
> > arch=all.
> > 
> > > We use them for certain config files and they are
> > > intended for the target.
> > > 
> > Do these configs contain data that is not the same on all
> > architectures? If so, DPKG_ARCH="all" is wrong.
> 
> After some debugging, it seems to be a combination of your patch and 
> "2ca3a7e dpkg-source: Build source package only once". There is no 
> problem building our dpkg-raw packages explicitly in the non-native 
> form, e.g. in the host environment for the target arch.
> But through your patch, the package also runs as -native, which then 
> triggers a problem with 2ca3a7e.
> 
> ... I only now discover that the other part of your patchset "dpkg-raw: 
> add files to source package" fixes this. Ok.

Ok, so in general this series is fine.

> 
> However, because of this I went digging on why you introduced the patch. 
> And I wonder why sbom-chroot doesn't just depend on 
> python3-debsbom-native directly? (Which still breaks as long as 2ca3a7e 
> sets the dependency on a function of the non-native package).

This is a more general thing: The chroot is architecture specific. By
that, the architecture of the packages (DEPENDS) is selected based on
that without the need for having -native. The internal logic then takes
care of building the packages in the correct variant (e.g. -compat,
-native or without any suffix, which refers to the target arch).

The 2ca3a7e ("dpkg-source: Build source package only once") just
ensures that we only create a single source package, no matter for
which (and how many) architectures we build it.

> 
> 
> > > I dont know why exactly they fail and I'm sure
> > > this could be fixed, but actually there is no need to build those
> > > packages in the native environment.
> > > 
> > There is need to do so, as otherwise we emulate the build process which
> > is super slow.
> Yes you're right. I meant there is no need to build them *for* the 
> native architecture.
> > > So I'm somewhat surprised to see
> > > that and could image that this causes confusion for others that dont
> > > know about the "all" intricacies as well.
> > Probably, but in the end we are building a debian system and by that
> > the users should be aware of the debian architecture specifiers.
> Yes sure, they were new to me, but no problem, they are not that 
> complicated.
> 
> But when I deliberately build -native packages (which I assume to be a 
> valid use case according to the doc), and somehow the buildsystem goes 
> back and forth running functions from the native and the base package, 
> it's difficult to follow why that would be necessary. It doesnt make for 
> ease of debugging when working on new packages either.
> 
> For the use cases I have in sight right now it would be fine if a 
> package build breaks because it cannot be done cross-architecture. I'd 
> hope to being able to fix this by either improving the package or making 
> sure to call it -native only. But if that's not what the expectation is 
> for Debian Crossbuilding I'm eager to learn.

If there are no further issues with this patchset, I would like to move
forward and see it merged. It is a pre-condition for the SBOM patches
for non target!=host arch.

Best regards,
Felix

> 
> best regards,
> Andreas
> 
> > > Another observation that I see is that dpkg-prebuilt "any" packages,
> > > which are probably in the dependency chain of an "all" package, now are
> > > always also built as -native, even though they are needed for the target
> > > only.
> > Same here, even if bitbake tells you that they are build as "-native",
> > there is no difference in the output, as the binary is simply copied.
> > 
> > Best regards,
> > Felix
> > 
> > > best,
> > > Andras
> > > 
> > > >    }
> > > >    addhandler multiarch_virtclass_handler
> > > >    multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
> > > -- 
> > > Andreas Naumann
> > > 
> > > emlix GmbH
> > > Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
> > > Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
> > > District Court of Goettingen, Registry Number HR B 3160
> > > Managing Directors: Heike Jordan, Dr. Uwe Kracke
> > > VAT ID No. DE 205 198 055
> > > Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> > > Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> > > http://www.emlix.com
> 
> -- 
> Andreas Naumann
> 
> emlix GmbH
> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
> Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
> District Court of Goettingen, Registry Number HR B 3160
> Managing Directors: Heike Jordan, Dr. Uwe Kracke
> VAT ID No. DE 205 198 055
> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> http://www.emlix.com

-- 
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

-- 
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/56507dd43d6b0f0e309563ebbe2d48327353cdc5.camel%40siemens.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

['Andreas Naumann' via isar-users]

Hi Felix, all

Am 06.10.25 um 16:05 schrieb MOESSBAUER, Felix:
> On Fri, 2025-09-19 at 09:15 +0200, Andreas Naumann wrote:
>> Hi Felix, all
>>
>> Am 16.09.25 um 09:16 schrieb MOESSBAUER, Felix:
>>> On Mon, 2025-09-15 at 19:49 +0200, Andreas Naumann wrote:
>>>> Hi Felix,
>>>>
>>>> Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:
>>>>> Arch=all packages might build depend on other arch=all packages, hence we
>>>>> need to correctly model the dependency chain. Otherwise the transitive
>>>>> dependencies are built for the distro arch instead of the native arch.
>>>>>
>>>>> We implement this by dispatching the non-native variant of DPKG_ARCH=all
>>>>> packages to the -native variant by adding a dependency. We further
>>>>> replace the non-native do_deploy_dep task with a noop to preserve the
>>>>> dependency chain.
>>>>>
>>>>> Co-developed-by: Adriaan Schmidt<adriaan.schmidt@siemens.com>
>>>>> Signed-off-by: Felix Moessbauer<felix.moessbauer@siemens.com>
>>>>> ---
>>>>>     meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>>>>>     1 file changed, 17 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
>>>>> index babdfbd4..c2bba21f 100644
>>>>> --- a/meta/classes/multiarch.bbclass
>>>>> +++ b/meta/classes/multiarch.bbclass
>>>>> @@ -29,7 +29,11 @@ python() {
>>>>>                 d.appendVar('BBCLASSEXTEND', ' compat')
>>>>>     
>>>>>         # build native separately only when it differs from the target variant
>>>>> -    if not archIsAll and archDiffers:
>>>>> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
>>>>> +    # have transitive dependencies which need to be built for -native.
>>>>> +    # This special handling for DPKG_ARCH=all packages is left to the
>>>>> +    # multiarch_virtclass_handler
>>>>> +    if archDiffers:
>>>>>             d.appendVar('BBCLASSEXTEND', ' native')
>>>>>         else:
>>>>>             extend_provides(pn, 'native', d)
>>>>> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>>>>>                 d.setVar(var, ' '.join(multiarch_var))
>>>>>     
>>>>>         pn = e.data.getVar('PN')
>>>>> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
>>>>> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>>>>>         if pn.endswith('-compat'):
>>>>>             e.data.setVar('BPN', pn[:-len('-compat')])
>>>>>             e.data.appendVar('OVERRIDES', ':class-compat')
>>>>> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>>>>>             e.data.appendVar('OVERRIDES', ':class-native')
>>>>>             fixup_pn_in_vars(e.data)
>>>>>             fixup_depends('-native', e.data)
>>>>> +    elif archIsAll and archDiffers:
>>>>> +        # Arch=all packages might build depend on other arch=all packages,
>>>>> +        # hence we need to correctly model the dependency chain.
>>>>> +        # We implement this by dispatching the non-native variant to the -native
>>>>> +        # variant by adding a dependency. We further replace the non-native
>>>>> +        # do_deploy_dep task with a noop to preserve the dependency chain.
>>>>> +        e.data.setVar('do_deploy_deb', '')
>>>>> +        bb.build.deltask('deploy_deb', e.data)
>>>>> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
>>>>> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
>>>> I have now done some more testing and unfortunately find that this
>>>> causes failures when building the -native variant of some dpkg-raw
>>>> packages we have.
>>>>
>>> Hi, do you have an example for such a package? Just to be clear: There
>>> is no "native" variant of a dpkg-raw package. The dpkg-raw packages are
>>> always build on the host architecture (in bitbake terms) and of Debian
>>> arch=all.
>>>
>>>> We use them for certain config files and they are
>>>> intended for the target.
>>>>
>>> Do these configs contain data that is not the same on all
>>> architectures? If so, DPKG_ARCH="all" is wrong.
>> After some debugging, it seems to be a combination of your patch and
>> "2ca3a7e dpkg-source: Build source package only once". There is no
>> problem building our dpkg-raw packages explicitly in the non-native
>> form, e.g. in the host environment for the target arch.
>> But through your patch, the package also runs as -native, which then
>> triggers a problem with 2ca3a7e.
>>
>> ... I only now discover that the other part of your patchset "dpkg-raw:
>> add files to source package" fixes this. Ok.
> Ok, so in general this series is fine.

ACK, to get the sbom series going.

However, I have proposed and would like to invite you to comment on my [RFC 0/5] Improving multiarch support for arch-incompatible packages. I think it provides a straightforward, generic solution that works for "all" and non-all packages alike.


>> However, because of this I went digging on why you introduced the patch.
>> And I wonder why sbom-chroot doesn't just depend on
>> python3-debsbom-native directly? (Which still breaks as long as 2ca3a7e
>> sets the dependency on a function of the non-native package).
> This is a more general thing: The chroot is architecture specific. By
> that, the architecture of the packages (DEPENDS) is selected based on
> that without the need for having -native. The internal logic then takes
> care of building the packages in the correct variant (e.g. -compat,
> -native or without any suffix, which refers to the target arch).

I'm not sure I understand what you mean. If python3-debsbom was an "any" 
package, how would the logic guess that it's needed for the host?

best regards,
Andreas

>
> The 2ca3a7e ("dpkg-source: Build source package only once") just
> ensures that we only create a single source package, no matter for
> which (and how many) architectures we build it.
>
>>
>>>> I dont know why exactly they fail and I'm sure
>>>> this could be fixed, but actually there is no need to build those
>>>> packages in the native environment.
>>>>
>>> There is need to do so, as otherwise we emulate the build process which
>>> is super slow.
>> Yes you're right. I meant there is no need to build them *for* the
>> native architecture.
>>>> So I'm somewhat surprised to see
>>>> that and could image that this causes confusion for others that dont
>>>> know about the "all" intricacies as well.
>>> Probably, but in the end we are building a debian system and by that
>>> the users should be aware of the debian architecture specifiers.
>> Yes sure, they were new to me, but no problem, they are not that
>> complicated.
>>
>> But when I deliberately build -native packages (which I assume to be a
>> valid use case according to the doc), and somehow the buildsystem goes
>> back and forth running functions from the native and the base package,
>> it's difficult to follow why that would be necessary. It doesnt make for
>> ease of debugging when working on new packages either.
>>
>> For the use cases I have in sight right now it would be fine if a
>> package build breaks because it cannot be done cross-architecture. I'd
>> hope to being able to fix this by either improving the package or making
>> sure to call it -native only. But if that's not what the expectation is
>> for Debian Crossbuilding I'm eager to learn.
> If there are no further issues with this patchset, I would like to move
> forward and see it merged. It is a pre-condition for the SBOM patches
> for non target!=host arch.
>
> Best regards,
> Felix
>
>> best regards,
>> Andreas
>>
>>>> Another observation that I see is that dpkg-prebuilt "any" packages,
>>>> which are probably in the dependency chain of an "all" package, now are
>>>> always also built as -native, even though they are needed for the target
>>>> only.
>>> Same here, even if bitbake tells you that they are build as "-native",
>>> there is no difference in the output, as the binary is simply copied.
>>>
>>> Best regards,
>>> Felix
>>>
>>>> best,
>>>> Andras
>>>>
>>>>>     }
>>>>>     addhandler multiarch_virtclass_handler
>>>>>     multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>>>> -- 
>>>> Andreas Naumann
>>>>
>>>> emlix GmbH
>>>> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
>>>> Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
>>>> District Court of Goettingen, Registry Number HR B 3160
>>>> Managing Directors: Heike Jordan, Dr. Uwe Kracke
>>>> VAT ID No. DE 205 198 055
>>>> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
>>>> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
>>>> http://www.emlix.com
>> -- 
>> Andreas Naumann
>>
>> emlix GmbH
>> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
>> Phone +49 (0)551 30664-0, e-mailinfo@emlix.com
>> District Court of Goettingen, Registry Number HR B 3160
>> Managing Directors: Heike Jordan, Dr. Uwe Kracke
>> VAT ID No. DE 205 198 055
>> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
>> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
>> http://www.emlix.com

-- 
Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail info@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

-- 
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/6c272cfc-ca61-4ec9-8913-7497cf43001e%40emlix.com.

Re: [PATCH 2/2] handle DPKG_ARCH=all case for transitive deps

[Zhihang Wei]

p2 was applied to next, thanks.

On 8/20/25 14:41, 'Felix Moessbauer' via isar-users wrote:
> Arch=all packages might build depend on other arch=all packages, hence we
> need to correctly model the dependency chain. Otherwise the transitive
> dependencies are built for the distro arch instead of the native arch.
>
> We implement this by dispatching the non-native variant of DPKG_ARCH=all
> packages to the -native variant by adding a dependency. We further
> replace the non-native do_deploy_dep task with a noop to preserve the
> dependency chain.
>
> Co-developed-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>   meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
>   1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> index babdfbd4..c2bba21f 100644
> --- a/meta/classes/multiarch.bbclass
> +++ b/meta/classes/multiarch.bbclass
> @@ -29,7 +29,11 @@ python() {
>               d.appendVar('BBCLASSEXTEND', ' compat')
>   
>       # build native separately only when it differs from the target variant
> -    if not archIsAll and archDiffers:
> +    # We must not short-circuit for DPKG_ARCH=all packages, as they might
> +    # have transitive dependencies which need to be built for -native.
> +    # This special handling for DPKG_ARCH=all packages is left to the
> +    # multiarch_virtclass_handler
> +    if archDiffers:
>           d.appendVar('BBCLASSEXTEND', ' native')
>       else:
>           extend_provides(pn, 'native', d)
> @@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
>               d.setVar(var, ' '.join(multiarch_var))
>   
>       pn = e.data.getVar('PN')
> +    archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
> +    archIsAll = d.getVar('DPKG_ARCH') == 'all'
>       if pn.endswith('-compat'):
>           e.data.setVar('BPN', pn[:-len('-compat')])
>           e.data.appendVar('OVERRIDES', ':class-compat')
> @@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
>           e.data.appendVar('OVERRIDES', ':class-native')
>           fixup_pn_in_vars(e.data)
>           fixup_depends('-native', e.data)
> +    elif archIsAll and archDiffers:
> +        # Arch=all packages might build depend on other arch=all packages,
> +        # hence we need to correctly model the dependency chain.
> +        # We implement this by dispatching the non-native variant to the -native
> +        # variant by adding a dependency. We further replace the non-native
> +        # do_deploy_dep task with a noop to preserve the dependency chain.
> +        e.data.setVar('do_deploy_deb', '')
> +        bb.build.deltask('deploy_deb', e.data)
> +        bb.build.addtask('deploy_deb', 'do_build', '', e.data)
> +        e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
>   }
>   addhandler multiarch_virtclass_handler
>   multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

-- 
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/9edc443a-88d8-4cae-88b3-d2963b40c1f6%40ilbers.de.