[PATCH v4 0/3] kbuild follow-up

[PATCH v4 0/3] kbuild follow-up

[Adriaan Schmidt]

Ok, this is indeed a tricky one...

It's based on the code from Stefan's "[PATCH] linux-module: Support
emulated module build with cross-compiled kernel" (replacing that patch),
and on the result of staring at dependency graphs with Jan.
This mainly addresses corner cases of the refactored kbuild packaging
when cross-compiling.

I've tested

- cross-compiled custom kernel and cross module build
- cross-compiled custom kernel and emulated module build
- distro kernel and emulated module build

Let me know if one of your use-cases is still missing.

Also including some fixups (p2-3) brought up in recent reviews on the ML.

Adriaan

changes since v3:
- (almost) restored the old API, where a module recipe only depends on
  linux-headers-*. Now it's linux-headers-*-native.
- Removed the -native suffix from all PROVIDES and DEPENDS because
  I realized that those are added automatically by the multiarch logic.
  Only exception is the pseudo target used to pull in the base variant
  (which builds the headers) into the native one (which builds the kbuild
  tools). This still needs to be named "-native".

changes since v2:
- removed a forgotten line of testing code

changes since v1:
- always use linux-kbuild-native as build dependency, even for emulated
  builds, because the multiarch logic will select the correct package


Adriaan Schmidt (3):
  module.inc: fix kbuild dependency
  linux-custom: use to_boolean when checking ISAR_CROSS_COMPILE
  kbuildtarget.bbclass: add missing license header

 meta/recipes-kernel/linux-module/module.inc   |  2 +-
 .../linux/classes/kbuildtarget.bbclass        |  5 ++++
 meta/recipes-kernel/linux/linux-custom.inc    | 27 ++++++++++++-------
 meta/recipes-kernel/linux/linux-distro.bb     |  1 +
 4 files changed, 25 insertions(+), 10 deletions(-)

-- 
2.39.2

[PATCH v4 1/3] module.inc: fix kbuild dependency

[Adriaan Schmidt]

This achieves two things:

* Module builds now depend on linux-headers-*-native as build dependency.
  This is a minimal API change compared to the previous linux-headers-*.
  The dependency on the new linux-kbuild is kept hidden in linux-custom.inc
* Remove the unconditional building of native kbuild when it is
  not needed, i.e. when we're not actually cross-building a module

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
---
 meta/recipes-kernel/linux-module/module.inc |  2 +-
 meta/recipes-kernel/linux/linux-custom.inc  | 25 ++++++++++++++-------
 meta/recipes-kernel/linux/linux-distro.bb   |  1 +
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index eddbf177..229e6a5c 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -17,7 +17,7 @@ PN .= "-${KERNEL_NAME}"
 
 KERNEL_IMAGE_PKG ??= "linux-image-${KERNEL_NAME}"
 KERNEL_HEADERS_PKG ??= "linux-headers-${KERNEL_NAME}"
-DEPENDS += "${KERNEL_HEADERS_PKG}"
+DEPENDS += "${KERNEL_HEADERS_PKG}-native"
 DEBIAN_BUILD_DEPENDS = "${KERNEL_HEADERS_PKG}"
 
 SIGNATURE_KEYFILE ??= ""
diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 0d222332..7b752f2b 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -116,11 +116,19 @@ HEADERS_DEPENDS:cross-profile = ", linux-kbuild-${KERNEL_NAME_PROVIDED}:${HOST_A
 
 # -native: kbuild package for host
 BUILD_PROFILES:class-native = "kbuild"
-RECIPE_PROVIDES:class-native = "linux-kbuild-${KERNEL_NAME_PROVIDED}-native"
+RECIPE_PROVIDES:class-native = " \
+    linux-headers-${KERNEL_NAME_PROVIDED} \
+    linux-kbuild-${KERNEL_NAME_PROVIDED}"
+# Use pseudo target to pull in the base variant of the recipe.
+# Will be auto-extended with -native by multiarch.bbclass.
+RDEPENDS:class-native += "${BPN}-pseudo"
 
 # -kbuildtarget: kbuild package for target, enforcing non-cross-build
 BUILD_PROFILES:class-kbuildtarget = "kbuild"
-RECIPE_PROVIDES:class-kbuildtarget = "linux-kbuild-${KERNEL_NAME_PROVIDED}"
+RECIPE_PROVIDES:class-kbuildtarget = " \
+    linux-headers-${KERNEL_NAME_PROVIDED} \
+    linux-kbuild-${KERNEL_NAME_PROVIDED}"
+RDEPENDS:class-kbuildtarget = "${BPN}"
 ISAR_CROSS_COMPILE:class-kbuildtarget = "0"
 
 # Make bitbake know we will be producing linux-image and linux-headers packages
@@ -132,11 +140,15 @@ RECIPE_PROVIDES = " \
     linux-libc-dev-${DISTRO_ARCH}-cross \
     linux-image-${KERNEL_NAME_PROVIDED}-dbg \
     linux-kbuild-${KERNEL_NAME_PROVIDED} \
+    ${BPN}-pseudo-native \
 "
 # When cross-profile is active:
-# kbuild package is provided by -native or -kbuildtarget variant
-# Otherwise it's provided by the default variant
-RECIPE_PROVIDES:remove:cross-profile = "linux-kbuild-${KERNEL_NAME_PROVIDED}"
+# kbuild package is provided by -native or -kbuildtarget variant. Also headers
+# provisioning moves over to ensure those variants are pulled, although the
+# package itself is still built by the base recipe.
+RECIPE_PROVIDES:remove:cross-profile = " \
+    linux-headers-${KERNEL_NAME_PROVIDED} \
+    linux-kbuild-${KERNEL_NAME_PROVIDED}"
 
 # Append headers depends
 HEADERS_DEPENDS = ", linux-kbuild-${KERNEL_NAME_PROVIDED}"
@@ -148,9 +160,6 @@ PROVIDES += "${RECIPE_PROVIDES}"
 # Append build profiles
 DEB_BUILD_PROFILES += "${BUILD_PROFILES}"
 
-# Add dependency to build -kbuildtarget and -native automatically
-RDEPENDS:append:cross-profile = " ${BPN}-native"
-
 def get_kernel_arch(d):
     distro_arch = d.getVar("DISTRO_ARCH")
     if distro_arch in ["amd64", "i386"]:
diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
index bc43528c..13b8dc7e 100644
--- a/meta/recipes-kernel/linux/linux-distro.bb
+++ b/meta/recipes-kernel/linux/linux-distro.bb
@@ -10,6 +10,7 @@ python() {
     for kernel in distro_kernels.split():
         d.appendVar('PROVIDES', ' linux-image-' + kernel)
         d.appendVar('PROVIDES', ' linux-headers-' + kernel)
+        d.appendVar('PROVIDES', ' linux-kbuild-' + kernel)
     if d.getVar('KERNEL_IMAGE_PKG'):
         d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_IMAGE_PKG'))
     if d.getVar('KERNEL_HEADERS_PKG'):
-- 
2.39.2

[PATCH v4 2/3] linux-custom: use to_boolean when checking ISAR_CROSS_COMPILE

[Adriaan Schmidt]

we've changed style/convention in Isar sometime during the review of the
kbuild series, and this was missed.

Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
---
 meta/recipes-kernel/linux/linux-custom.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-custom.inc b/meta/recipes-kernel/linux/linux-custom.inc
index 7b752f2b..3fd0c6c2 100644
--- a/meta/recipes-kernel/linux/linux-custom.inc
+++ b/meta/recipes-kernel/linux/linux-custom.inc
@@ -97,7 +97,7 @@ KERNEL_NAME_PROVIDED ?= "${@ d.getVar('BPN').partition('linux-')[2]}"
 
 # Determine cross-profile override
 python() {
-    if d.getVar("DISTRO_ARCH") != d.getVar("HOST_ARCH") and d.getVar("ISAR_CROSS_COMPILE", True) == "1" and "class-native" not in d.getVar("OVERRIDES", True).split(":"):
+    if d.getVar("DISTRO_ARCH") != d.getVar("HOST_ARCH") and bb.utils.to_boolean(d.getVar("ISAR_CROSS_COMPILE")) and "class-native" not in d.getVar("OVERRIDES", True).split(":"):
         d.appendVar("OVERRIDES", ":cross-profile")
 }
 
-- 
2.39.2

[PATCH v4 3/3] kbuildtarget.bbclass: add missing license header

[Adriaan Schmidt]

Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
---
 meta/recipes-kernel/linux/classes/kbuildtarget.bbclass | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
index 26369861..648825e4 100644
--- a/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
+++ b/meta/recipes-kernel/linux/classes/kbuildtarget.bbclass
@@ -1,3 +1,8 @@
+# This software is a part of ISAR.
+# Copyright (C) 2024 Siemens AG
+#
+# SPDX-License-Identifier: MIT
+
 python kbuildtarget_virtclass_handler() {
     pn = e.data.getVar('PN')
     if pn.endswith('-kbuildtarget'):
-- 
2.39.2

Re: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Anton Mikanovich]

14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
> This achieves two things:
>
> * Module builds now depend on linux-headers-*-native as build dependency.
>    This is a minimal API change compared to the previous linux-headers-*.
>    The dependency on the new linux-kbuild is kept hidden in linux-custom.inc
> * Remove the unconditional building of native kbuild when it is
>    not needed, i.e. when we're not actually cross-building a module
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>

Hello Adriaan,
This will fail for distro kernels because linux-distro.bb recipe do not provide
-native package.

Re: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Jan Kiszka]

On 15.05.24 17:07, Anton Mikanovich wrote:
> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
>> This achieves two things:
>>
>> * Module builds now depend on linux-headers-*-native as build dependency.
>>    This is a minimal API change compared to the previous linux-headers-*.
>>    The dependency on the new linux-kbuild is kept hidden in
>> linux-custom.inc
>> * Remove the unconditional building of native kbuild when it is
>>    not needed, i.e. when we're not actually cross-building a module
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> 
> Hello Adriaan,
> This will fail for distro kernels because linux-distro.bb recipe do not
> provide
> -native package.

Does it fail (spoiler: it does not for me) or do you suspect it may fail?

Jan

-- 
Siemens AG, Technology
Linux Expert Center

RE: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Schmidt, Adriaan]

Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
> On 15.05.24 17:07, Anton Mikanovich wrote:
> > 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
> >> This achieves two things:
> >>
> >> * Module builds now depend on linux-headers-*-native as build dependency.
> >>    This is a minimal API change compared to the previous linux-headers-*.
> >>    The dependency on the new linux-kbuild is kept hidden in
> >> linux-custom.inc
> >> * Remove the unconditional building of native kbuild when it is
> >>    not needed, i.e. when we're not actually cross-building a module
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> >
> > Hello Adriaan,
> > This will fail for distro kernels because linux-distro.bb recipe do not
> > provide
> > -native package.
> 
> Does it fail (spoiler: it does not for me) or do you suspect it may fail?

It fails in non-cross cases (amd64 target on amd64 host), regardless of the
value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-native'".

The patch below fixes it, by making the distro kernel dummy recipe provide it.
Although it should also be covered by multiarch.bbclass and your commit
5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case where
we'd want to drop the '-native' from the dependency.
Maybe we need to examine the condition here...

Adriaan

===
diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
index 13b8dc7e..16673b67 100644
--- a/meta/recipes-kernel/linux/linux-distro.bb
+++ b/meta/recipes-kernel/linux/linux-distro.bb
@@ -16,3 +16,5 @@ python() {
     if d.getVar('KERNEL_HEADERS_PKG'):
         d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
 }
+
+inherit multiarch
===

> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center

Re: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Jan Kiszka]

On 15.05.24 23:28, Schmidt, Adriaan (T CED EDC-DE) wrote:
> Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
>> On 15.05.24 17:07, Anton Mikanovich wrote:
>>> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
>>>> This achieves two things:
>>>>
>>>> * Module builds now depend on linux-headers-*-native as build dependency.
>>>>    This is a minimal API change compared to the previous linux-headers-*.
>>>>    The dependency on the new linux-kbuild is kept hidden in
>>>> linux-custom.inc
>>>> * Remove the unconditional building of native kbuild when it is
>>>>    not needed, i.e. when we're not actually cross-building a module
>>>>
>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
>>>
>>> Hello Adriaan,
>>> This will fail for distro kernels because linux-distro.bb recipe do not
>>> provide
>>> -native package.
>>
>> Does it fail (spoiler: it does not for me) or do you suspect it may fail?
> 
> It fails in non-cross cases (amd64 target on amd64 host), regardless of the
> value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-native'".
> 
> The patch below fixes it, by making the distro kernel dummy recipe provide it.
> Although it should also be covered by multiarch.bbclass and your commit
> 5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case where
> we'd want to drop the '-native' from the dependency.
> Maybe we need to examine the condition here...
> 
> Adriaan
> 
> ===
> diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
> index 13b8dc7e..16673b67 100644
> --- a/meta/recipes-kernel/linux/linux-distro.bb
> +++ b/meta/recipes-kernel/linux/linux-distro.bb
> @@ -16,3 +16,5 @@ python() {
>      if d.getVar('KERNEL_HEADERS_PKG'):
>          d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
>  }
> +
> +inherit multiarch
> ===
> 

This makes sense as linux-distro is a dummy package to please bitbake,
an it does not generate and debian packages, thus does not inherit
multiarch via dpkg-base.

The reason why multiarch does not help us on example-module side is that
we only append -native to dependencies, we do not remove it anywhere
because we assume hat multiarch will augment PROVIDES with a -native
target when there is no need for a separate one.

Please send v5 then.

Thanks,
Jan

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Jan Kiszka]

On 16.05.24 07:21, 'Jan Kiszka' via isar-users wrote:
> On 15.05.24 23:28, Schmidt, Adriaan (T CED EDC-DE) wrote:
>> Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
>>> On 15.05.24 17:07, Anton Mikanovich wrote:
>>>> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
>>>>> This achieves two things:
>>>>>
>>>>> * Module builds now depend on linux-headers-*-native as build dependency.
>>>>>    This is a minimal API change compared to the previous linux-headers-*.
>>>>>    The dependency on the new linux-kbuild is kept hidden in
>>>>> linux-custom.inc
>>>>> * Remove the unconditional building of native kbuild when it is
>>>>>    not needed, i.e. when we're not actually cross-building a module
>>>>>
>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
>>>>
>>>> Hello Adriaan,
>>>> This will fail for distro kernels because linux-distro.bb recipe do not
>>>> provide
>>>> -native package.
>>>
>>> Does it fail (spoiler: it does not for me) or do you suspect it may fail?
>>
>> It fails in non-cross cases (amd64 target on amd64 host), regardless of the
>> value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-native'".
>>
>> The patch below fixes it, by making the distro kernel dummy recipe provide it.
>> Although it should also be covered by multiarch.bbclass and your commit
>> 5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case where
>> we'd want to drop the '-native' from the dependency.
>> Maybe we need to examine the condition here...
>>
>> Adriaan
>>
>> ===
>> diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
>> index 13b8dc7e..16673b67 100644
>> --- a/meta/recipes-kernel/linux/linux-distro.bb
>> +++ b/meta/recipes-kernel/linux/linux-distro.bb
>> @@ -16,3 +16,5 @@ python() {
>>      if d.getVar('KERNEL_HEADERS_PKG'):
>>          d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
>>  }
>> +
>> +inherit multiarch
>> ===
>>
> 
> This makes sense as linux-distro is a dummy package to please bitbake,
> an it does not generate and debian packages, thus does not inherit
> multiarch via dpkg-base.
> 
> The reason why multiarch does not help us on example-module side is that
> we only append -native to dependencies, we do not remove it anywhere
> because we assume hat multiarch will augment PROVIDES with a -native
> target when there is no need for a separate one.
> 

In fact, we are also dropping -native from DEPENDS, in the anonymous
python block of multiarch.bbclass. Maybe we rather have an ordering
issues of all the magics?

Jan

> Please send v5 then.
> 
> Thanks,
> Jan
> 

-- 
Siemens AG, Technology
Linux Expert Center

Re: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Jan Kiszka]

On 16.05.24 08:15, 'Jan Kiszka' via isar-users wrote:
> On 16.05.24 07:21, 'Jan Kiszka' via isar-users wrote:
>> On 15.05.24 23:28, Schmidt, Adriaan (T CED EDC-DE) wrote:
>>> Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
>>>> On 15.05.24 17:07, Anton Mikanovich wrote:
>>>>> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
>>>>>> This achieves two things:
>>>>>>
>>>>>> * Module builds now depend on linux-headers-*-native as build dependency.
>>>>>>    This is a minimal API change compared to the previous linux-headers-*.
>>>>>>    The dependency on the new linux-kbuild is kept hidden in
>>>>>> linux-custom.inc
>>>>>> * Remove the unconditional building of native kbuild when it is
>>>>>>    not needed, i.e. when we're not actually cross-building a module
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>>>>>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
>>>>>
>>>>> Hello Adriaan,
>>>>> This will fail for distro kernels because linux-distro.bb recipe do not
>>>>> provide
>>>>> -native package.
>>>>
>>>> Does it fail (spoiler: it does not for me) or do you suspect it may fail?
>>>
>>> It fails in non-cross cases (amd64 target on amd64 host), regardless of the
>>> value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-native'".
>>>
>>> The patch below fixes it, by making the distro kernel dummy recipe provide it.
>>> Although it should also be covered by multiarch.bbclass and your commit
>>> 5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case where
>>> we'd want to drop the '-native' from the dependency.
>>> Maybe we need to examine the condition here...
>>>
>>> Adriaan
>>>
>>> ===
>>> diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-kernel/linux/linux-distro.bb
>>> index 13b8dc7e..16673b67 100644
>>> --- a/meta/recipes-kernel/linux/linux-distro.bb
>>> +++ b/meta/recipes-kernel/linux/linux-distro.bb
>>> @@ -16,3 +16,5 @@ python() {
>>>      if d.getVar('KERNEL_HEADERS_PKG'):
>>>          d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
>>>  }
>>> +
>>> +inherit multiarch
>>> ===
>>>
>>
>> This makes sense as linux-distro is a dummy package to please bitbake,
>> an it does not generate and debian packages, thus does not inherit
>> multiarch via dpkg-base.
>>
>> The reason why multiarch does not help us on example-module side is that
>> we only append -native to dependencies, we do not remove it anywhere
>> because we assume hat multiarch will augment PROVIDES with a -native
>> target when there is no need for a separate one.
>>
> 
> In fact, we are also dropping -native from DEPENDS, in the anonymous
> python block of multiarch.bbclass. Maybe we rather have an ordering
> issues of all the magics?
> 

Ah, no, needed to read my own comment more carefully again: that removal
is only for the case of enforced emulated builds, not for natural native
ones.

Jan

-- 
Siemens AG, Technology
Linux Expert Center

RE: [PATCH v4 1/3] module.inc: fix kbuild dependency

[Schmidt, Adriaan]

Kiszka, Jan (T CED), 16. Mai 2024 08:21:
> On 16.05.24 08:15, 'Jan Kiszka' via isar-users wrote:
> > On 16.05.24 07:21, 'Jan Kiszka' via isar-users wrote:
> >> On 15.05.24 23:28, Schmidt, Adriaan (T CED EDC-DE) wrote:
> >>> Kiszka, Jan (T CED), Sent: Mittwoch, 15. Mai 2024 19:42:
> >>>> On 15.05.24 17:07, Anton Mikanovich wrote:
> >>>>> 14/05/2024 17:15, 'Adriaan Schmidt' via isar-users wrote:
> >>>>>> This achieves two things:
> >>>>>>
> >>>>>> * Module builds now depend on linux-headers-*-native as build
> dependency.
> >>>>>>    This is a minimal API change compared to the previous linux-
> headers-*.
> >>>>>>    The dependency on the new linux-kbuild is kept hidden in
> >>>>>> linux-custom.inc
> >>>>>> * Remove the unconditional building of native kbuild when it is
> >>>>>>    not needed, i.e. when we're not actually cross-building a module
> >>>>>>
> >>>>>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>>> Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
> >>>>>
> >>>>> Hello Adriaan,
> >>>>> This will fail for distro kernels because linux-distro.bb recipe do not
> >>>>> provide
> >>>>> -native package.
> >>>>
> >>>> Does it fail (spoiler: it does not for me) or do you suspect it may
> fail?
> >>>
> >>> It fails in non-cross cases (amd64 target on amd64 host), regardless of
> the
> >>> value of ISAR_CROSS_COMPILE, with "Nothing PROVIDES 'linux-headers-amd64-
> native'".
> >>>
> >>> The patch below fixes it, by making the distro kernel dummy recipe
> provide it.
> >>> Although it should also be covered by multiarch.bbclass and your commit
> >>> 5c2299c718fa1548057d250318df5bddfea8e2b5, because that seems like a case
> where
> >>> we'd want to drop the '-native' from the dependency.
> >>> Maybe we need to examine the condition here...
> >>>
> >>> Adriaan
> >>>
> >>> ===
> >>> diff --git a/meta/recipes-kernel/linux/linux-distro.bb b/meta/recipes-
> kernel/linux/linux-distro.bb
> >>> index 13b8dc7e..16673b67 100644
> >>> --- a/meta/recipes-kernel/linux/linux-distro.bb
> >>> +++ b/meta/recipes-kernel/linux/linux-distro.bb
> >>> @@ -16,3 +16,5 @@ python() {
> >>>      if d.getVar('KERNEL_HEADERS_PKG'):
> >>>          d.appendVar('PROVIDES', ' ' + d.getVar('KERNEL_HEADERS_PKG'))
> >>>  }
> >>> +
> >>> +inherit multiarch
> >>> ===
> >>>
> >>
> >> This makes sense as linux-distro is a dummy package to please bitbake,
> >> an it does not generate and debian packages, thus does not inherit
> >> multiarch via dpkg-base.
> >>
> >> The reason why multiarch does not help us on example-module side is that
> >> we only append -native to dependencies, we do not remove it anywhere
> >> because we assume hat multiarch will augment PROVIDES with a -native
> >> target when there is no need for a separate one.
> >>
> >
> > In fact, we are also dropping -native from DEPENDS, in the anonymous
> > python block of multiarch.bbclass. Maybe we rather have an ordering
> > issues of all the magics?
> >
> 
> Ah, no, needed to read my own comment more carefully again: that removal
> is only for the case of enforced emulated builds, not for natural native
> ones.

Yes. I also had to read that twice ;)
And I think that's still the right way:

- if the native and "normal" package are the same, the "normal" recipe
  PROVIDES -native. And with v5 that's fixed for linux-distro.bb
- if the native and "normal" packages differ, but conditions (enforced
  emulated build) mean that we need "normal" even though the recipe DEPENDS
  on native, we change the DEPEND side. As it is currently.

Adriaan

> Jan
> 
> --
> Siemens AG, Technology
> Linux Expert Center