I understand the issue reported , Can you please help to share/provide the steps to reproduce the issue where I can check for the solutions Regards Arulpandiyan V. On Thursday, 11 September 2025 at 10:58:45 UTC+5:30 Jan Kiszka wrote: > On 11.09.25 07:21, Arulpandiyan Vadivel wrote: > > > > > > On Thursday, 11 September 2025 at 10:41:19 UTC+5:30 Jan Kiszka wrote: > > > > On 10.09.25 19:22, 'Jan Kiszka' via isar-users wrote: > > > On 10.09.25 15:55, 'Jan Kiszka' via isar-users wrote: > > >> On 21.01.25 10:47, 'Arulpandiyan Vadivel' via isar-users wrote: > > >>> Debian and Ubuntu use unified kernel headers and a single linux- > > libc-dev > > >>> package is shipped. In contrast, Isar may build multiple kernel > > variants > > >>> with different versions and/or patches and their packages but > > linux-libc-dev > > >>> are suffixed with -${KERNEL_NAME_PROVIDED}: this allows > > >>> each variant to exist in isar-apt (reprepro may not have more > > than one > > >>> version of a given package for a given suite). > > >>> Apply the same suffix to linux-libc-dev / linux-libc-dev- > > ${DISTRO_ARCH}-cross > > >>> and a Provides: clause. > > >>> > > >>> Signed-off-by: Arulpandiyan Vadivel > > >>> > > >>> --- > > >>> Changes since v4 > > >>> - Updated KERNEL_PKG_LIBC_HEADERS path with KERNEL_NAME_PROVIDED > > >>> > > >>> Changes since v3 > > >>> - Updated commit message to include cross packages > > >>> - updated doc/custom_kernel.md documentation > > >>> > > >>> Changes since v2 > > >>> - Updated commit message as suggested > > >>> - Added KERNEL_NAME_PROVIDED for cross packages of linux-libc- > > dev as well > > >>> > > >>> --- > > >>> --- > > >>> RECIPE-API-CHANGELOG.md | 12 ++++++++++++ > > >>> doc/custom_kernel.md | 4 ++-- > > >>> meta/recipes-kernel/linux/files/debian/control.tmpl | 10 +++++++--- > > >>> .../linux/files/debian/isar/common.tmpl | 2 +- > > >>> .../linux/files/debian/isar/install.tmpl | 2 +- > > >>> meta/recipes-kernel/linux/linux-custom.inc | 2 ++ > > >>> 6 files changed, 25 insertions(+), 7 deletions(-) > > >>> > > >>> diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md > > >>> index f310553a..64c0f34a 100644 > > >>> --- a/RECIPE-API-CHANGELOG.md > > >>> +++ b/RECIPE-API-CHANGELOG.md > > >>> @@ -702,3 +702,15 @@ enable cross-compilation. Otherwize > > ISAR_CROSS_COMPILE = "0" now should be set > > >>> in local.conf to disable cross-compilation for all the recipes. > > >>> Sample local.conf from meta-isar used by isar-init-build-env is > > also changed > > >>> to enable cross-compilation by default. > > >>> + > > >>> +### Enable linux-libc-dev package with KERNEL_NAME > > >>> + > > >>> +By default linux-libc-dev and linux-libc-dev-${DISTRO_ARCH}- > > cross package > > >>> +was generated for architecture it builds for. > > >>> + > > >>> +This change helps to generate the `linux-libc-dev- > > ${KERNEL_NAME}` and > > >>> +`linux-libc-dev-${DISTRO_ARCH}-cross-${KERNEL_NAME}`. > > >>> +For example, If `KERNEL_NAME` is configured as `foo` for arm64, > > now > > >>> +`linux-libc-dev-foo` and `linux-libc-dev-arm64-cross-foo` > > package will be > > >>> +generated. This will help to have multiple versions of linux- > > libc-dev packages > > >>> +available for respective bsps in apt feeds. > > >>> diff --git a/doc/custom_kernel.md b/doc/custom_kernel.md > > >>> index ce5f1bf7..2dca577c 100644 > > >>> --- a/doc/custom_kernel.md > > >>> +++ b/doc/custom_kernel.md > > >>> @@ -51,9 +51,9 @@ The linux-custom recipe provides support for: > > >>> > > >>> Only the `host` specific package is built automatically at cross > > builds. > > >>> > > >>> - 10. Produce a `linux-libc-dev` package to support user-land > > builds > > >>> + 10. Produce a `linux-libc-dev-${KERNEL_NAME}` package to > > support user-land builds > > >>> > > >>> - 11. Only build/ship the `linux-libc-dev` package if instructed to > > >>> + 11. Only build/ship the `linux-libc-dev-${KERNEL_NAME}` > > package if instructed to > > >>> (`KERNEL_LIBC_DEV_DEPLOY` equals to `"1"`) > > >>> > > >>> 12. Support both native and cross compiles (`ISAR_CROSS_COMPILE`) > > >>> diff --git a/meta/recipes-kernel/linux/files/debian/control.tmpl > > b/meta/recipes-kernel/linux/files/debian/control.tmpl > > >>> index ec0da1ab..a79b86c4 100644 > > >>> --- a/meta/recipes-kernel/linux/files/debian/control.tmpl > > >>> +++ b/meta/recipes-kernel/linux/files/debian/control.tmpl > > >>> @@ -22,19 +22,23 @@ Description: ${KERNEL_NAME_PROVIDED} Linux > > kernel headers for @KR@ > > >>> . > > >>> This is useful for people who need to build external modules > > >>> > > >>> -Package: linux-libc-dev > > >>> +Package: linux-libc-dev-${KERNEL_NAME_PROVIDED} > > >>> Build-Profiles: > > >>> Section: devel > > >>> -Provides: linux-kernel-headers > > >>> +Conflicts: linux-libc-dev > > >>> +Provides: linux-libc-dev > > >>> +Replaces: linux-libc-dev > > >>> Architecture: ${KERNEL_LIBC_DEV_ARCH} > > >>> Description: Linux support headers for userspace development > > >>> This package provides userspaces headers from the Linux kernel. > > These headers > > >>> are used by the installed headers for GNU glibc and other system > > libraries. > > >>> > > >>> -Package: linux-libc-dev-${DISTRO_ARCH}-cross > > >>> +Package: linux-libc-dev-${DISTRO_ARCH}-cross- > > ${KERNEL_NAME_PROVIDED} > > >>> Build-Profiles: > > >>> Section: devel > > >>> +Conflicts: linux-kernel-headers-${DISTRO_ARCH}-cross > > >>> Provides: linux-kernel-headers-${DISTRO_ARCH}-cross > > >>> +Replaces: linux-kernel-headers-${DISTRO_ARCH}-cross > > > > > > This was also wrong. > > > > > >>> Architecture: all > > >>> Description: Linux Kernel Headers for development (for cross- > > compiling) > > >>> This package provides headers from the Linux kernel. These headers > > >>> diff --git a/meta/recipes-kernel/linux/files/debian/isar/ > > common.tmpl b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl > > >>> index f9cc2f02..b004214f 100644 > > >>> --- a/meta/recipes-kernel/linux/files/debian/isar/common.tmpl > > >>> +++ b/meta/recipes-kernel/linux/files/debian/isar/common.tmpl > > >>> @@ -8,7 +8,7 @@ set -e > > >>> ARCH=${KERNEL_ARCH} > > >>> KERNEL_PKG_IMAGE=linux-image-${KERNEL_NAME_PROVIDED} > > >>> KERNEL_PKG_KERN_HEADERS=linux-headers-${KERNEL_NAME_PROVIDED} > > >>> -KERNEL_PKG_LIBC_HEADERS=linux-libc-dev > > >>> +KERNEL_PKG_LIBC_HEADERS=linux-libc-dev-${KERNEL_NAME_PROVIDED} > > >>> KERNEL_PKG_LIBC_HEADERS_CROSS=linux-libc-dev-${DISTRO_ARCH}-cross > > >> > > >> This broke the cross libc-dev package. Fix is being tested. > > >> > > >> Seems we are lacking tests for this scenario: found via xenomai- > > images > > >> only, and there we were lacking CI for the affected path as well :(. > > >> > > > > > > There is another issue with this patch which was likely hard to > > predict: > > > It broke automatic downgrades, possibly also updates, of libc-dev > > in the > > > sbuild-chroots. As xenomai-images is currently broken in other > > regards > > > as well, I cannot easily point to a demo case, but I reproduced that > > > locally: After reverting this change, I can build libevl, which > > really > > > needs the custom kernel's libc-dev because of extra headers, > > without any > > > extra dependency. > > > > > > [...] > > > Reading package lists... > > > Building dependency tree... > > > Reading state information... > > > Calculating upgrade... > > > The following packages will be upgraded: > > > linux-libc-dev > > > 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > > [...] > > > > > > With this change, I would now have to add the explicit Build- > > Depends on > > > linux-libc-dev-${KERNEL_NAME} or the corresponding cross package. > > That > > > is a very ugly recipe API change that was also not documented. > > > > > > So, I'm not very happy with having this pattern here by default and > > > would prefer only using it if there are actually multiple kernels > > that > > > also deploy their libc-dev packages. > > > > > > Unless someone has a good idea quickly, we should revert this > > first and > > > retry later. > > > > > > > This is a design challenge: Do we really need per-KERNEL_NAME > > linux-libc-dev packages, or is it enough to tell the users to enable > > KERNEL_LIBC_DEV_DEPLOY only for one of them? > > > > When a single apt feeds to support multiple BSP's with same or different > > architecture for a linux-libc-dev package, without this change we may > > not be able to support them. > > If BSPs are breaking the UAPIs of each other, then we may not even > consider them valid BSPs (they should not change the UAPI at all, in > theory) - but I agree that this case is imaginable. > > > > > I think that in way of 90% of the use cases the latter will be enough > > because the kernels only differ in configuration or in patches that do > > not create conflicting changes to the UAPI headers. But can someone > > think of a case where this is not enough? > > > > > > Yes. I agree UAPI headers might be common in 99% cases unless we have > > specific BSP changes pushed and maintained > > So, any ideas how to model a recipe API where you can opt-in to build > multiple linux-libc-dev (which will no longer be simple replacements of > the upstream packages)? > > Or do you have any idea how to fix the issue that the sbuild envs are > not up/downgrading the linux-libc-dev packages anymore when they have > different names? > > Reverting all this is not nice as well because we already broke the > recipe API, but it's currently the only good option I see. > > 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/4be9f176-71d2-4f61-bd98-70d91385574fn%40googlegroups.com.