public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
* [PATCH 1/2] mark cowsay package as architecture all
@ 2026-04-29 10:47 'Felix Moessbauer' via isar-users
  2026-04-29 10:47 ` [PATCH 2/2] sbuild: do not build arch all packages on cross 'Felix Moessbauer' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'Felix Moessbauer' via isar-users @ 2026-04-29 10:47 UTC (permalink / raw)
  To: isar-users; +Cc: konrad.schwarz, quirin.gylstorff, Felix Moessbauer

By that we do not cross-compile the cowsay package. It only consists
of arch=all packages.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta-isar/recipes-app/cowsay/cowsay_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-isar/recipes-app/cowsay/cowsay_git.bb b/meta-isar/recipes-app/cowsay/cowsay_git.bb
index b0b8d3eb..0fa1e67c 100644
--- a/meta-isar/recipes-app/cowsay/cowsay_git.bb
+++ b/meta-isar/recipes-app/cowsay/cowsay_git.bb
@@ -5,6 +5,8 @@
 
 inherit dpkg-gbp
 
+DPKG_ARCH = "all"
+
 SRC_URI = "git://salsa.debian.org/debian/cowsay.git;protocol=https;branch=master"
 SRC_URI += "file://isar.patch"
 SRCREV = "756f0c41fbf582093c0c1dff9ff77734716cb26f"
-- 
2.53.0

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260429104734.1447148-1-felix.moessbauer%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 10:47 [PATCH 1/2] mark cowsay package as architecture all 'Felix Moessbauer' via isar-users
@ 2026-04-29 10:47 ` 'Felix Moessbauer' via isar-users
  2026-04-29 10:53   ` 'Jan Kiszka' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'Felix Moessbauer' via isar-users @ 2026-04-29 10:47 UTC (permalink / raw)
  To: isar-users; +Cc: konrad.schwarz, quirin.gylstorff, Felix Moessbauer

Architecture all packages often cannot be built in cross mode, as the
dependencies cannot be resolved in the host architecture. This
especially applies to all packages which split their build dependencies
into Build-Depends-Arch and Build-Depends-Indep. We already have logic
in isar to built DPKG_ARCH=all packages non-cross, but this does not
work for packages that generate both arch specific and arch all binary
packages.

While sbuild automatically disables builds of arch-all packages on
cross, we previously explicitly overrode this setting. We now change
this by explicitly setting --no-arch-all flag on cross and --arch-all on
non-cross.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
 meta/classes-recipe/dpkg.bbclass |  3 ++-
 2 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
index 856da5de..c83c1599 100644
--- a/RECIPE-API-CHANGELOG.md
+++ b/RECIPE-API-CHANGELOG.md
@@ -1001,3 +1001,18 @@ 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.
+
+### No building of arch=all packages when cross building
+
+Architecture all packages often cannot be built in cross mode, as the
+dependencies cannot be resolved in the foreign architecture. This especially
+applies to all packages which split their build dependencies into
+`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
+in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
+work for packages that generate both arch specific and arch all binary packages.
+
+We now explicitly disable building arch=all binary packages on cross (this
+technically only affects packages that generate arch specific and arch=all
+binary packages). To build the arch=all binary packages of such source packages,
+add an explicit dependency to `${BPN}-native`. Source packages that only
+generate `arch=all` packages, must now be marked `DPKG_ARCH = "all"`.
diff --git a/meta/classes-recipe/dpkg.bbclass b/meta/classes-recipe/dpkg.bbclass
index c1c38184..500aaefe 100644
--- a/meta/classes-recipe/dpkg.bbclass
+++ b/meta/classes-recipe/dpkg.bbclass
@@ -109,8 +109,9 @@ dpkg_runbuild() {
 
     DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name "${DEBIAN_SOURCE}_*.dsc" -print)
 
-    sbuild -A -n -c ${SBUILD_CHROOT} --chroot-mode=schroot \
+    sbuild -n -c ${SBUILD_CHROOT} --chroot-mode=schroot \
         --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
+        ${@'--no-arch-all' if 'cross' in isar_deb_build_profiles(d).split() else '--arch-all'} \
         --no-run-lintian --no-run-piuparts --no-run-autopkgtest --resolve-alternatives \
         --bd-uninstallable-explainer=apt \
         --no-apt-update --apt-distupgrade \
-- 
2.53.0

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/20260429104734.1447148-2-felix.moessbauer%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 10:47 ` [PATCH 2/2] sbuild: do not build arch all packages on cross 'Felix Moessbauer' via isar-users
@ 2026-04-29 10:53   ` 'Jan Kiszka' via isar-users
  2026-04-29 10:55     ` 'Jan Kiszka' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2026-04-29 10:53 UTC (permalink / raw)
  To: Felix Moessbauer, isar-users; +Cc: konrad.schwarz, quirin.gylstorff

On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
> Architecture all packages often cannot be built in cross mode, as the
> dependencies cannot be resolved in the host architecture. This
> especially applies to all packages which split their build dependencies
> into Build-Depends-Arch and Build-Depends-Indep. We already have logic
> in isar to built DPKG_ARCH=all packages non-cross, but this does not
> work for packages that generate both arch specific and arch all binary
> packages.
> 
> While sbuild automatically disables builds of arch-all packages on
> cross, we previously explicitly overrode this setting. We now change
> this by explicitly setting --no-arch-all flag on cross and --arch-all on
> non-cross.
> 
> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> ---
>  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
>  meta/classes-recipe/dpkg.bbclass |  3 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> index 856da5de..c83c1599 100644
> --- a/RECIPE-API-CHANGELOG.md
> +++ b/RECIPE-API-CHANGELOG.md
> @@ -1001,3 +1001,18 @@ 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.
> +
> +### No building of arch=all packages when cross building
> +
> +Architecture all packages often cannot be built in cross mode, as the
> +dependencies cannot be resolved in the foreign architecture. This especially
> +applies to all packages which split their build dependencies into
> +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
> +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
> +work for packages that generate both arch specific and arch all binary packages.
> +
> +We now explicitly disable building arch=all binary packages on cross (this
> +technically only affects packages that generate arch specific and arch=all
> +binary packages). To build the arch=all binary packages of such source packages,
> +add an explicit dependency to `${BPN}-native`. Source packages that only

That will be fun to find, though likely a rare one. Can't we detect such
cases in Isar and add a bitbake dependency from $BPN to -native?

Jan

> +generate `arch=all` packages, must now be marked `DPKG_ARCH = "all"`.
> diff --git a/meta/classes-recipe/dpkg.bbclass b/meta/classes-recipe/dpkg.bbclass
> index c1c38184..500aaefe 100644
> --- a/meta/classes-recipe/dpkg.bbclass
> +++ b/meta/classes-recipe/dpkg.bbclass
> @@ -109,8 +109,9 @@ dpkg_runbuild() {
>  
>      DSC_FILE=$(find ${WORKDIR} -maxdepth 1 -name "${DEBIAN_SOURCE}_*.dsc" -print)
>  
> -    sbuild -A -n -c ${SBUILD_CHROOT} --chroot-mode=schroot \
> +    sbuild -n -c ${SBUILD_CHROOT} --chroot-mode=schroot \
>          --host=${PACKAGE_ARCH} --build=${BUILD_ARCH} ${profiles} \
> +        ${@'--no-arch-all' if 'cross' in isar_deb_build_profiles(d).split() else '--arch-all'} \
>          --no-run-lintian --no-run-piuparts --no-run-autopkgtest --resolve-alternatives \
>          --bd-uninstallable-explainer=apt \
>          --no-apt-update --apt-distupgrade \

-- 
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/177b4f4c-069d-41b0-b510-07912b9ff912%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 10:53   ` 'Jan Kiszka' via isar-users
@ 2026-04-29 10:55     ` 'Jan Kiszka' via isar-users
  2026-04-29 11:10       ` 'MOESSBAUER, Felix' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2026-04-29 10:55 UTC (permalink / raw)
  To: Felix Moessbauer, isar-users; +Cc: konrad.schwarz, quirin.gylstorff

On 29.04.26 12:53, Jan Kiszka wrote:
> On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
>> Architecture all packages often cannot be built in cross mode, as the
>> dependencies cannot be resolved in the host architecture. This
>> especially applies to all packages which split their build dependencies
>> into Build-Depends-Arch and Build-Depends-Indep. We already have logic
>> in isar to built DPKG_ARCH=all packages non-cross, but this does not
>> work for packages that generate both arch specific and arch all binary
>> packages.
>>
>> While sbuild automatically disables builds of arch-all packages on
>> cross, we previously explicitly overrode this setting. We now change
>> this by explicitly setting --no-arch-all flag on cross and --arch-all on
>> non-cross.
>>
>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>> ---
>>  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
>>  meta/classes-recipe/dpkg.bbclass |  3 ++-
>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
>> index 856da5de..c83c1599 100644
>> --- a/RECIPE-API-CHANGELOG.md
>> +++ b/RECIPE-API-CHANGELOG.md
>> @@ -1001,3 +1001,18 @@ 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.
>> +
>> +### No building of arch=all packages when cross building
>> +
>> +Architecture all packages often cannot be built in cross mode, as the
>> +dependencies cannot be resolved in the foreign architecture. This especially
>> +applies to all packages which split their build dependencies into
>> +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
>> +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
>> +work for packages that generate both arch specific and arch all binary packages.
>> +
>> +We now explicitly disable building arch=all binary packages on cross (this
>> +technically only affects packages that generate arch specific and arch=all
>> +binary packages). To build the arch=all binary packages of such source packages,
>> +add an explicit dependency to `${BPN}-native`. Source packages that only
> 
> That will be fun to find, though likely a rare one. Can't we detect such
> cases in Isar and add a bitbake dependency from $BPN to -native?
> 

In fact, -native is practically overshooting. We would need a recipe
target that only build the all package.

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/9af7db0e-a64a-47a9-969a-820f68d9058c%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 10:55     ` 'Jan Kiszka' via isar-users
@ 2026-04-29 11:10       ` 'MOESSBAUER, Felix' via isar-users
  2026-04-29 11:26         ` 'Jan Kiszka' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'MOESSBAUER, Felix' via isar-users @ 2026-04-29 11:10 UTC (permalink / raw)
  To: Kiszka, Jan, isar-users; +Cc: Schwarz, Konrad, Gylstorff, Quirin

On Wed, 2026-04-29 at 12:55 +0200, Jan Kiszka wrote:
> On 29.04.26 12:53, Jan Kiszka wrote:
> > On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
> > > Architecture all packages often cannot be built in cross mode, as the
> > > dependencies cannot be resolved in the host architecture. This
> > > especially applies to all packages which split their build dependencies
> > > into Build-Depends-Arch and Build-Depends-Indep. We already have logic
> > > in isar to built DPKG_ARCH=all packages non-cross, but this does not
> > > work for packages that generate both arch specific and arch all binary
> > > packages.
> > > 
> > > While sbuild automatically disables builds of arch-all packages on
> > > cross, we previously explicitly overrode this setting. We now change
> > > this by explicitly setting --no-arch-all flag on cross and --arch-all on
> > > non-cross.
> > > 
> > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > ---
> > >  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
> > >  meta/classes-recipe/dpkg.bbclass |  3 ++-
> > >  2 files changed, 17 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > > index 856da5de..c83c1599 100644
> > > --- a/RECIPE-API-CHANGELOG.md
> > > +++ b/RECIPE-API-CHANGELOG.md
> > > @@ -1001,3 +1001,18 @@ 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.
> > > +
> > > +### No building of arch=all packages when cross building
> > > +
> > > +Architecture all packages often cannot be built in cross mode, as the
> > > +dependencies cannot be resolved in the foreign architecture. This especially
> > > +applies to all packages which split their build dependencies into
> > > +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
> > > +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
> > > +work for packages that generate both arch specific and arch all binary packages.
> > > +
> > > +We now explicitly disable building arch=all binary packages on cross (this
> > > +technically only affects packages that generate arch specific and arch=all
> > > +binary packages). To build the arch=all binary packages of such source packages,
> > > +add an explicit dependency to `${BPN}-native`. Source packages that only
> > 
> > That will be fun to find, though likely a rare one. Can't we detect such
> > cases in Isar and add a bitbake dependency from $BPN to -native?

We could try to parse the ${S}/debian/control file and detect this, but
I guess that doesn't work, as we would have to add the dependency
before running bitbake tasks (a common case is that the debian part is
fetched, hence the task need to run and then it's too late).

> > 
> 
> In fact, -native is practically overshooting. We would need a recipe
> target that only build the all package.

I thought about this as well. We would need a -all variant that is
basically identical to -native but adds the --no-arch-any sbuild flag.
However, this only helps for first-stage dependencies, as the
transitive dependencies still need to be build in -native. Further, we
need to ensure that either -all or -native is built, but not both. This
would need a model similar to the fetch_common_source task. That's a
lot of complexity for a minimal build-time improvement. By that, I
rather would like to avoid this optimization. If we really need it, we
still can add it in the future.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/09592e57e156f73a7237436d45acc469152689ff.camel%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 11:10       ` 'MOESSBAUER, Felix' via isar-users
@ 2026-04-29 11:26         ` 'Jan Kiszka' via isar-users
  2026-04-29 11:40           ` 'MOESSBAUER, Felix' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2026-04-29 11:26 UTC (permalink / raw)
  To: Moessbauer, Felix (FT RPD CED OES-DE), isar-users
  Cc: Schwarz, Konrad (FT RPD CED OES-DE),
	Gylstorff, Quirin (FT RPD CED OES-DE)

On 29.04.26 13:10, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Wed, 2026-04-29 at 12:55 +0200, Jan Kiszka wrote:
>> On 29.04.26 12:53, Jan Kiszka wrote:
>>> On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
>>>> Architecture all packages often cannot be built in cross mode, as the
>>>> dependencies cannot be resolved in the host architecture. This
>>>> especially applies to all packages which split their build dependencies
>>>> into Build-Depends-Arch and Build-Depends-Indep. We already have logic
>>>> in isar to built DPKG_ARCH=all packages non-cross, but this does not
>>>> work for packages that generate both arch specific and arch all binary
>>>> packages.
>>>>
>>>> While sbuild automatically disables builds of arch-all packages on
>>>> cross, we previously explicitly overrode this setting. We now change
>>>> this by explicitly setting --no-arch-all flag on cross and --arch-all on
>>>> non-cross.
>>>>
>>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>>> ---
>>>>  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
>>>>  meta/classes-recipe/dpkg.bbclass |  3 ++-
>>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
>>>> index 856da5de..c83c1599 100644
>>>> --- a/RECIPE-API-CHANGELOG.md
>>>> +++ b/RECIPE-API-CHANGELOG.md
>>>> @@ -1001,3 +1001,18 @@ 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.
>>>> +
>>>> +### No building of arch=all packages when cross building
>>>> +
>>>> +Architecture all packages often cannot be built in cross mode, as the
>>>> +dependencies cannot be resolved in the foreign architecture. This especially
>>>> +applies to all packages which split their build dependencies into
>>>> +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
>>>> +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
>>>> +work for packages that generate both arch specific and arch all binary packages.
>>>> +
>>>> +We now explicitly disable building arch=all binary packages on cross (this
>>>> +technically only affects packages that generate arch specific and arch=all
>>>> +binary packages). To build the arch=all binary packages of such source packages,
>>>> +add an explicit dependency to `${BPN}-native`. Source packages that only
>>>
>>> That will be fun to find, though likely a rare one. Can't we detect such
>>> cases in Isar and add a bitbake dependency from $BPN to -native?
> 
> We could try to parse the ${S}/debian/control file and detect this, but
> I guess that doesn't work, as we would have to add the dependency
> before running bitbake tasks (a common case is that the debian part is
> fetched, hence the task need to run and then it's too late).
> 
>>>
>>
>> In fact, -native is practically overshooting. We would need a recipe
>> target that only build the all package.
> 
> I thought about this as well. We would need a -all variant that is
> basically identical to -native but adds the --no-arch-any sbuild flag.
> However, this only helps for first-stage dependencies, as the
> transitive dependencies still need to be build in -native. Further, we
> need to ensure that either -all or -native is built, but not both. This
> would need a model similar to the fetch_common_source task. That's a
> lot of complexity for a minimal build-time improvement. By that, I
> rather would like to avoid this optimization. If we really need it, we
> still can add it in the future.

The key question is how to ensure that people will find this highly
non-intuitive recipe dependency. We need to explain this even harder
than the difference between IMAGE_INSTALL and IMAGE_PREINSTALL.

BTW, it also affects how recipe writers have to translate their binary
output packages into PROVIDES statements. If you do that incorrectly,
unconditionally, the mess will only get bigger.

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/f5d4bcf5-a8e5-4745-9984-87b3360d23c7%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 11:26         ` 'Jan Kiszka' via isar-users
@ 2026-04-29 11:40           ` 'MOESSBAUER, Felix' via isar-users
  2026-04-29 12:45             ` 'Jan Kiszka' via isar-users
  0 siblings, 1 reply; 8+ messages in thread
From: 'MOESSBAUER, Felix' via isar-users @ 2026-04-29 11:40 UTC (permalink / raw)
  To: Kiszka, Jan, isar-users; +Cc: Schwarz, Konrad, Gylstorff, Quirin

On Wed, 2026-04-29 at 13:26 +0200, Jan Kiszka wrote:
> On 29.04.26 13:10, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Wed, 2026-04-29 at 12:55 +0200, Jan Kiszka wrote:
> > > On 29.04.26 12:53, Jan Kiszka wrote:
> > > > On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
> > > > > Architecture all packages often cannot be built in cross mode, as the
> > > > > dependencies cannot be resolved in the host architecture. This
> > > > > especially applies to all packages which split their build dependencies
> > > > > into Build-Depends-Arch and Build-Depends-Indep. We already have logic
> > > > > in isar to built DPKG_ARCH=all packages non-cross, but this does not
> > > > > work for packages that generate both arch specific and arch all binary
> > > > > packages.
> > > > > 
> > > > > While sbuild automatically disables builds of arch-all packages on
> > > > > cross, we previously explicitly overrode this setting. We now change
> > > > > this by explicitly setting --no-arch-all flag on cross and --arch-all on
> > > > > non-cross.
> > > > > 
> > > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > > > ---
> > > > >  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
> > > > >  meta/classes-recipe/dpkg.bbclass |  3 ++-
> > > > >  2 files changed, 17 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > > > > index 856da5de..c83c1599 100644
> > > > > --- a/RECIPE-API-CHANGELOG.md
> > > > > +++ b/RECIPE-API-CHANGELOG.md
> > > > > @@ -1001,3 +1001,18 @@ 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.
> > > > > +
> > > > > +### No building of arch=all packages when cross building
> > > > > +
> > > > > +Architecture all packages often cannot be built in cross mode, as the
> > > > > +dependencies cannot be resolved in the foreign architecture. This especially
> > > > > +applies to all packages which split their build dependencies into
> > > > > +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
> > > > > +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
> > > > > +work for packages that generate both arch specific and arch all binary packages.
> > > > > +
> > > > > +We now explicitly disable building arch=all binary packages on cross (this
> > > > > +technically only affects packages that generate arch specific and arch=all
> > > > > +binary packages). To build the arch=all binary packages of such source packages,
> > > > > +add an explicit dependency to `${BPN}-native`. Source packages that only
> > > > 
> > > > That will be fun to find, though likely a rare one. Can't we detect such
> > > > cases in Isar and add a bitbake dependency from $BPN to -native?
> > 
> > We could try to parse the ${S}/debian/control file and detect this, but
> > I guess that doesn't work, as we would have to add the dependency
> > before running bitbake tasks (a common case is that the debian part is
> > fetched, hence the task need to run and then it's too late).
> > 
> > > > 
> > > 
> > > In fact, -native is practically overshooting. We would need a recipe
> > > target that only build the all package.
> > 
> > I thought about this as well. We would need a -all variant that is
> > basically identical to -native but adds the --no-arch-any sbuild flag.
> > However, this only helps for first-stage dependencies, as the
> > transitive dependencies still need to be build in -native. Further, we
> > need to ensure that either -all or -native is built, but not both. This
> > would need a model similar to the fetch_common_source task. That's a
> > lot of complexity for a minimal build-time improvement. By that, I
> > rather would like to avoid this optimization. If we really need it, we
> > still can add it in the future.
> 
> The key question is how to ensure that people will find this highly
> non-intuitive recipe dependency. We need to explain this even harder
> than the difference between IMAGE_INSTALL and IMAGE_PREINSTALL.
> 
> BTW, it also affects how recipe writers have to translate their binary
> output packages into PROVIDES statements. If you do that incorrectly,
> unconditionally, the mess will only get bigger.

That's an interesting finding. If you model the PROVIDES correctly, you
don't have to add the explicit RDEPENDS to the -native variant. This is
what we should document instead of the -native dependency.

Will do so in a v2, once I have more feedback.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/981f0f05349be2e03c2113da6bed97dec25206c2.camel%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH 2/2] sbuild: do not build arch all packages on cross
  2026-04-29 11:40           ` 'MOESSBAUER, Felix' via isar-users
@ 2026-04-29 12:45             ` 'Jan Kiszka' via isar-users
  0 siblings, 0 replies; 8+ messages in thread
From: 'Jan Kiszka' via isar-users @ 2026-04-29 12:45 UTC (permalink / raw)
  To: Moessbauer, Felix (FT RPD CED OES-DE), isar-users
  Cc: Schwarz, Konrad (FT RPD CED OES-DE),
	Gylstorff, Quirin (FT RPD CED OES-DE)

On 29.04.26 13:40, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> On Wed, 2026-04-29 at 13:26 +0200, Jan Kiszka wrote:
>> On 29.04.26 13:10, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
>>> On Wed, 2026-04-29 at 12:55 +0200, Jan Kiszka wrote:
>>>> On 29.04.26 12:53, Jan Kiszka wrote:
>>>>> On 29.04.26 12:47, 'Felix Moessbauer' via isar-users wrote:
>>>>>> Architecture all packages often cannot be built in cross mode, as the
>>>>>> dependencies cannot be resolved in the host architecture. This
>>>>>> especially applies to all packages which split their build dependencies
>>>>>> into Build-Depends-Arch and Build-Depends-Indep. We already have logic
>>>>>> in isar to built DPKG_ARCH=all packages non-cross, but this does not
>>>>>> work for packages that generate both arch specific and arch all binary
>>>>>> packages.
>>>>>>
>>>>>> While sbuild automatically disables builds of arch-all packages on
>>>>>> cross, we previously explicitly overrode this setting. We now change
>>>>>> this by explicitly setting --no-arch-all flag on cross and --arch-all on
>>>>>> non-cross.
>>>>>>
>>>>>> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
>>>>>> ---
>>>>>>  RECIPE-API-CHANGELOG.md          | 15 +++++++++++++++
>>>>>>  meta/classes-recipe/dpkg.bbclass |  3 ++-
>>>>>>  2 files changed, 17 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
>>>>>> index 856da5de..c83c1599 100644
>>>>>> --- a/RECIPE-API-CHANGELOG.md
>>>>>> +++ b/RECIPE-API-CHANGELOG.md
>>>>>> @@ -1001,3 +1001,18 @@ 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.
>>>>>> +
>>>>>> +### No building of arch=all packages when cross building
>>>>>> +
>>>>>> +Architecture all packages often cannot be built in cross mode, as the
>>>>>> +dependencies cannot be resolved in the foreign architecture. This especially
>>>>>> +applies to all packages which split their build dependencies into
>>>>>> +`Build-Depends-Arch` and `Build-Depends-Indep`. We already have logic
>>>>>> +in isar to built `DPKG_ARCH = "all"` packages non-cross, but this does not
>>>>>> +work for packages that generate both arch specific and arch all binary packages.
>>>>>> +
>>>>>> +We now explicitly disable building arch=all binary packages on cross (this
>>>>>> +technically only affects packages that generate arch specific and arch=all
>>>>>> +binary packages). To build the arch=all binary packages of such source packages,
>>>>>> +add an explicit dependency to `${BPN}-native`. Source packages that only
>>>>>
>>>>> That will be fun to find, though likely a rare one. Can't we detect such
>>>>> cases in Isar and add a bitbake dependency from $BPN to -native?
>>>
>>> We could try to parse the ${S}/debian/control file and detect this, but
>>> I guess that doesn't work, as we would have to add the dependency
>>> before running bitbake tasks (a common case is that the debian part is
>>> fetched, hence the task need to run and then it's too late).
>>>
>>>>>
>>>>
>>>> In fact, -native is practically overshooting. We would need a recipe
>>>> target that only build the all package.
>>>
>>> I thought about this as well. We would need a -all variant that is
>>> basically identical to -native but adds the --no-arch-any sbuild flag.
>>> However, this only helps for first-stage dependencies, as the
>>> transitive dependencies still need to be build in -native. Further, we
>>> need to ensure that either -all or -native is built, but not both. This
>>> would need a model similar to the fetch_common_source task. That's a
>>> lot of complexity for a minimal build-time improvement. By that, I
>>> rather would like to avoid this optimization. If we really need it, we
>>> still can add it in the future.
>>
>> The key question is how to ensure that people will find this highly
>> non-intuitive recipe dependency. We need to explain this even harder
>> than the difference between IMAGE_INSTALL and IMAGE_PREINSTALL.
>>
>> BTW, it also affects how recipe writers have to translate their binary
>> output packages into PROVIDES statements. If you do that incorrectly,
>> unconditionally, the mess will only get bigger.
> 
> That's an interesting finding. If you model the PROVIDES correctly, you
> don't have to add the explicit RDEPENDS to the -native variant. This is
> what we should document instead of the -native dependency.
> 

Better test it - I bet there will be further devils in the detail.

> Will do so in a v2, once I have more feedback.
> 

I'm afraid we are not stable with this approach yet.

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/b4f295d9-b4c5-4e04-962c-d25545db6070%40siemens.com.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-04-29 12:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-04-29 10:47 [PATCH 1/2] mark cowsay package as architecture all 'Felix Moessbauer' via isar-users
2026-04-29 10:47 ` [PATCH 2/2] sbuild: do not build arch all packages on cross 'Felix Moessbauer' via isar-users
2026-04-29 10:53   ` 'Jan Kiszka' via isar-users
2026-04-29 10:55     ` 'Jan Kiszka' via isar-users
2026-04-29 11:10       ` 'MOESSBAUER, Felix' via isar-users
2026-04-29 11:26         ` 'Jan Kiszka' via isar-users
2026-04-29 11:40           ` 'MOESSBAUER, Felix' via isar-users
2026-04-29 12:45             ` 'Jan Kiszka' via isar-users

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox