* [PATCH] linux-custom: repack linux-libc-dev
@ 2019-06-12 20:10 Cedric Hombourger
2019-06-13 8:10 ` Henning Schild
0 siblings, 1 reply; 6+ messages in thread
From: Cedric Hombourger @ 2019-06-12 20:10 UTC (permalink / raw)
To: isar-users; +Cc: Cedric Hombourger
Debian's linux-libc-dev package has "asm" headers in the following
directory: /usr/include/<libc-arch>/asm while the builddeb script
from the Linux kernel places them in: /usr/include/asm. Repack the
linux-libc-dev package (fixing a build error for packages built
against Isar-created distributions shipping a custom kernel in
lieu of Debian's).
Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
---
meta/recipes-kernel/linux/files/build-kernel.sh | 38 +++++++++++++++++++++++--
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh b/meta/recipes-kernel/linux/files/build-kernel.sh
index 8b7b23b..2c97932 100644
--- a/meta/recipes-kernel/linux/files/build-kernel.sh
+++ b/meta/recipes-kernel/linux/files/build-kernel.sh
@@ -9,8 +9,20 @@
source /isar/common.sh
-host_arch=$(dpkg --print-architecture)
+unsupported_arch() {
+ echo "error: unsupported architecture ($1)" >&2
+ exit 1
+}
+
+case $target_arch in
+ amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;;
+ armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;;
+ arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;;
+ mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;;
+ *) unsupported_arch "$target_arch" ;;
+esac
+host_arch=$(dpkg --print-architecture)
if [ "$host_arch" != "$target_arch" ]; then
case $target_arch in
armhf)
@@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then
export CROSS_COMPILE="mipsel-linux-gnu-"
;;
*)
- echo "error: unsupported architecture ($target_arch)"
- exit 1
+ unsupported_arch "$target_arch"
;;
esac
fi
@@ -35,6 +46,7 @@ fi
REPACK_DIR="$1/../repack"
REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
+REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers"
if [ -e .config ]; then
make olddefconfig
@@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}"
mkdir -p "${REPACK_DIR}"
mkdir -p "${REPACK_LINUX_IMAGE_DIR}"
mkdir -p "${REPACK_LINUX_HEADERS_DIR}"
+mkdir -p "${REPACK_LIBC_HEADERS_DIR}"
cp -a debian "${REPACK_DIR}"
@@ -67,6 +80,7 @@ cd ..
dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb "${REPACK_LINUX_IMAGE_DIR}"
dpkg-deb -R linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}"
+dpkg-deb -R linux-libc-dev_${PV}-1_*.deb "${REPACK_LIBC_HEADERS_DIR}"
dpkg-gencontrol -crepack/debian/control \
-lrepack/debian/changelog \
@@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then
gunzip "$vmlinuz.gz"
fi
+# Move libc's asm headers where they are expected
+mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
+mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
+
dpkg-gencontrol -crepack/debian/control \
-lrepack/debian/changelog \
-frepack/debian/files \
@@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \
-DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \
-DArchitecture=$target_arch
+dpkg-gencontrol -crepack/debian/control \
+ -lrepack/debian/changelog \
+ -frepack/debian/files \
+ -plinux-libc-dev \
+ -P"${REPACK_LIBC_HEADERS_DIR}" \
+ -Vkernel:debarch="${KERNEL_NAME}" \
+ -DPackage="linux-libc-dev" \
+ -DSection=kernel \
+ -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \
+ -DArchitecture=$target_arch
+
fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \
linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
rm -f linux-image-${PV}_${PV}-1_*.deb
fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \
linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
rm -f linux-headers-${PV}_${PV}-1_*.deb
+rm -f linux-libc-dev_${PV}-1_*.deb
+fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \
+ linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb
# linux-libc-dev causes dependency problems if we downgrade
# remove it after the build so the downgraded version does not get deployed
--
2.11.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: repack linux-libc-dev
2019-06-12 20:10 [PATCH] linux-custom: repack linux-libc-dev Cedric Hombourger
@ 2019-06-13 8:10 ` Henning Schild
2019-06-13 8:32 ` Hombourger, Cedric
2019-06-13 16:05 ` Baurzhan Ismagulov
0 siblings, 2 replies; 6+ messages in thread
From: Henning Schild @ 2019-06-13 8:10 UTC (permalink / raw)
To: Cedric Hombourger; +Cc: isar-users
Am Wed, 12 Jun 2019 22:10:02 +0200
schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
> Debian's linux-libc-dev package has "asm" headers in the following
> directory: /usr/include/<libc-arch>/asm while the builddeb script
> from the Linux kernel places them in: /usr/include/asm. Repack the
> linux-libc-dev package (fixing a build error for packages built
> against Isar-created distributions shipping a custom kernel in
> lieu of Debian's).
To me that sounds like an upstream bug that should not just get covered
up by repacking. I would propose looking into a kernel patch for the
"debpkg" step. That patch could be carried in your layer(s) and Isar
while it is pending upstream.
Looking at both ubuntu and debian, old and new .. it should never
be /usr/include/asm/.
> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> ---
> meta/recipes-kernel/linux/files/build-kernel.sh | 38
> +++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 3
> deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh
> b/meta/recipes-kernel/linux/files/build-kernel.sh index
> 8b7b23b..2c97932 100644 ---
> a/meta/recipes-kernel/linux/files/build-kernel.sh +++
> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -9,8 +9,20 @@
>
> source /isar/common.sh
>
> -host_arch=$(dpkg --print-architecture)
> +unsupported_arch() {
> + echo "error: unsupported architecture ($1)" >&2
> + exit 1
> +}
> +
> +case $target_arch in
> + amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;;
> + armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;;
> + arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;;
> + mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;;
> + *) unsupported_arch "$target_arch" ;;
> +esac
Looks suspiciously like "${CROSS-COMPILE}gcc -dumpmachine". Using that
would relieve us from carrying those magic strings around.
> +host_arch=$(dpkg --print-architecture)
> if [ "$host_arch" != "$target_arch" ]; then
> case $target_arch in
> armhf)
> @@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then
> export CROSS_COMPILE="mipsel-linux-gnu-"
> ;;
> *)
> - echo "error: unsupported architecture ($target_arch)"
> - exit 1
> + unsupported_arch "$target_arch"
> ;;
> esac
> fi
> @@ -35,6 +46,7 @@ fi
> REPACK_DIR="$1/../repack"
> REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
> REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
> +REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers"
>
> if [ -e .config ]; then
> make olddefconfig
> @@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}"
> mkdir -p "${REPACK_DIR}"
> mkdir -p "${REPACK_LINUX_IMAGE_DIR}"
> mkdir -p "${REPACK_LINUX_HEADERS_DIR}"
> +mkdir -p "${REPACK_LIBC_HEADERS_DIR}"
>
> cp -a debian "${REPACK_DIR}"
>
> @@ -67,6 +80,7 @@ cd ..
>
> dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb
> "${REPACK_LINUX_IMAGE_DIR}" dpkg-deb -R
> linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}"
> +dpkg-deb -R linux-libc-dev_${PV}-1_*.deb
> "${REPACK_LIBC_HEADERS_DIR}" dpkg-gencontrol -crepack/debian/control \
> -lrepack/debian/changelog \
> @@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then
> gunzip "$vmlinuz.gz"
> fi
>
> +# Move libc's asm headers where they are expected
> +mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
> +mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm
> ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} +
> dpkg-gencontrol -crepack/debian/control \
> -lrepack/debian/changelog \
> -frepack/debian/files \
> @@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \
> -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \
> -DArchitecture=$target_arch
>
> +dpkg-gencontrol -crepack/debian/control \
> + -lrepack/debian/changelog \
> + -frepack/debian/files \
> + -plinux-libc-dev \
> + -P"${REPACK_LIBC_HEADERS_DIR}" \
> + -Vkernel:debarch="${KERNEL_NAME}" \
> + -DPackage="linux-libc-dev" \
> + -DSection=kernel \
> + -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \
> + -DArchitecture=$target_arch
> +
> fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \
> linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> rm -f linux-image-${PV}_${PV}-1_*.deb
> fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \
> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> rm -f linux-headers-${PV}_${PV}-1_*.deb
> +rm -f linux-libc-dev_${PV}-1_*.deb
> +fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \
> + linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb
>
> # linux-libc-dev causes dependency problems if we downgrade
> # remove it after the build so the downgraded version does not get
> deployed
Ahh this guy is still somehow in the patch. You might want to have a
look at 7a1f14ca. My guess is that skipping the downgrade is still OK
because the problem just shows once you install the libc-dev package.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: repack linux-libc-dev
2019-06-13 8:10 ` Henning Schild
@ 2019-06-13 8:32 ` Hombourger, Cedric
2019-06-13 15:37 ` Henning Schild
2019-06-13 16:05 ` Baurzhan Ismagulov
1 sibling, 1 reply; 6+ messages in thread
From: Hombourger, Cedric @ 2019-06-13 8:32 UTC (permalink / raw)
To: Henning Schild; +Cc: isar-users
Hi Henning
Agreed but I would think we would need a work-around in Isar until the proposed change gets accepted by k.org folks
(on a different note, I also need to submit a patch to arch/mips/Makefile for builddeb to succeed - my linux-custom recipe would not build without a patch as dtbs don't get built by default while they do on e.g. aarch64)
I would therefore suggest to have build-kernel.sh do something like:
if [ -d <...>/usr/include/asm ]; then
echo "warning: your kernel has incorrectly packaged linux-libc-dev headers" >&2
# apply work-around and repack linux-libc-dev
...
mv <...>/usr/include/asm <...>/usr/include/${LIBC_HEADERS_DIR}/
...
fi
I can submit a v2 if the approach is agreeable
will roll-up my sleeves a prepare a patch for k.org
Cedric
________________________________________
From: Henning Schild <henning.schild@siemens.com>
Sent: Thursday, June 13, 2019 10:10 AM
To: Hombourger, Cedric
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH] linux-custom: repack linux-libc-dev
Am Wed, 12 Jun 2019 22:10:02 +0200
schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
> Debian's linux-libc-dev package has "asm" headers in the following
> directory: /usr/include/<libc-arch>/asm while the builddeb script
> from the Linux kernel places them in: /usr/include/asm. Repack the
> linux-libc-dev package (fixing a build error for packages built
> against Isar-created distributions shipping a custom kernel in
> lieu of Debian's).
To me that sounds like an upstream bug that should not just get covered
up by repacking. I would propose looking into a kernel patch for the
"debpkg" step. That patch could be carried in your layer(s) and Isar
while it is pending upstream.
Looking at both ubuntu and debian, old and new .. it should never
be /usr/include/asm/.
> Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> ---
> meta/recipes-kernel/linux/files/build-kernel.sh | 38
> +++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 3
> deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh
> b/meta/recipes-kernel/linux/files/build-kernel.sh index
> 8b7b23b..2c97932 100644 ---
> a/meta/recipes-kernel/linux/files/build-kernel.sh +++
> b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -9,8 +9,20 @@
>
> source /isar/common.sh
>
> -host_arch=$(dpkg --print-architecture)
> +unsupported_arch() {
> + echo "error: unsupported architecture ($1)" >&2
> + exit 1
> +}
> +
> +case $target_arch in
> + amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;;
> + armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;;
> + arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;;
> + mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;;
> + *) unsupported_arch "$target_arch" ;;
> +esac
Looks suspiciously like "${CROSS-COMPILE}gcc -dumpmachine". Using that
would relieve us from carrying those magic strings around.
> +host_arch=$(dpkg --print-architecture)
> if [ "$host_arch" != "$target_arch" ]; then
> case $target_arch in
> armhf)
> @@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then
> export CROSS_COMPILE="mipsel-linux-gnu-"
> ;;
> *)
> - echo "error: unsupported architecture ($target_arch)"
> - exit 1
> + unsupported_arch "$target_arch"
> ;;
> esac
> fi
> @@ -35,6 +46,7 @@ fi
> REPACK_DIR="$1/../repack"
> REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
> REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
> +REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers"
>
> if [ -e .config ]; then
> make olddefconfig
> @@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}"
> mkdir -p "${REPACK_DIR}"
> mkdir -p "${REPACK_LINUX_IMAGE_DIR}"
> mkdir -p "${REPACK_LINUX_HEADERS_DIR}"
> +mkdir -p "${REPACK_LIBC_HEADERS_DIR}"
>
> cp -a debian "${REPACK_DIR}"
>
> @@ -67,6 +80,7 @@ cd ..
>
> dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb
> "${REPACK_LINUX_IMAGE_DIR}" dpkg-deb -R
> linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}"
> +dpkg-deb -R linux-libc-dev_${PV}-1_*.deb
> "${REPACK_LIBC_HEADERS_DIR}" dpkg-gencontrol -crepack/debian/control \
> -lrepack/debian/changelog \
> @@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then
> gunzip "$vmlinuz.gz"
> fi
>
> +# Move libc's asm headers where they are expected
> +mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
> +mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm
> ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} +
> dpkg-gencontrol -crepack/debian/control \
> -lrepack/debian/changelog \
> -frepack/debian/files \
> @@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \
> -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \
> -DArchitecture=$target_arch
>
> +dpkg-gencontrol -crepack/debian/control \
> + -lrepack/debian/changelog \
> + -frepack/debian/files \
> + -plinux-libc-dev \
> + -P"${REPACK_LIBC_HEADERS_DIR}" \
> + -Vkernel:debarch="${KERNEL_NAME}" \
> + -DPackage="linux-libc-dev" \
> + -DSection=kernel \
> + -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \
> + -DArchitecture=$target_arch
> +
> fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \
> linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> rm -f linux-image-${PV}_${PV}-1_*.deb
> fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \
> linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> rm -f linux-headers-${PV}_${PV}-1_*.deb
> +rm -f linux-libc-dev_${PV}-1_*.deb
> +fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \
> + linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb
>
> # linux-libc-dev causes dependency problems if we downgrade
> # remove it after the build so the downgraded version does not get
> deployed
Ahh this guy is still somehow in the patch. You might want to have a
look at 7a1f14ca. My guess is that skipping the downgrade is still OK
because the problem just shows once you install the libc-dev package.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: repack linux-libc-dev
2019-06-13 8:32 ` Hombourger, Cedric
@ 2019-06-13 15:37 ` Henning Schild
2019-06-13 16:09 ` Henning Schild
0 siblings, 1 reply; 6+ messages in thread
From: Henning Schild @ 2019-06-13 15:37 UTC (permalink / raw)
To: Hombourger, Cedric; +Cc: isar-users
Am Thu, 13 Jun 2019 08:32:26 +0000
schrieb "Hombourger, Cedric" <Cedric_Hombourger@mentor.com>:
> Hi Henning
>
> Agreed but I would think we would need a work-around in Isar until
> the proposed change gets accepted by k.org folks (on a different
> note, I also need to submit a patch to arch/mips/Makefile for
> builddeb to succeed - my linux-custom recipe would not build without
> a patch as dtbs don't get built by default while they do on e.g.
> aarch64)
>
> I would therefore suggest to have build-kernel.sh do something like:
>
> if [ -d <...>/usr/include/asm ]; then
> echo "warning: your kernel has incorrectly packaged
> linux-libc-dev headers" >&2 # apply work-around and repack
> linux-libc-dev ...
> mv <...>/usr/include/asm <...>/usr/include/${LIBC_HEADERS_DIR}/
> ...
> fi
I guess a backport or such a hack would not be a big deal, after
upstream accepted your patch. k.org is probably faster than ilbers
Lets at least see what the discussion brings and how fast it starts.
Maybe upstream will aknowledge the bug right away. Or they might give
valuable feedback on what we do not understand. ... and should not be
putting into Isar on the fast-lane
Henning
> I can submit a v2 if the approach is agreeable
> will roll-up my sleeves a prepare a patch for k.org
>
> Cedric
> ________________________________________
> From: Henning Schild <henning.schild@siemens.com>
> Sent: Thursday, June 13, 2019 10:10 AM
> To: Hombourger, Cedric
> Cc: isar-users@googlegroups.com
> Subject: Re: [PATCH] linux-custom: repack linux-libc-dev
>
> Am Wed, 12 Jun 2019 22:10:02 +0200
> schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
>
> > Debian's linux-libc-dev package has "asm" headers in the following
> > directory: /usr/include/<libc-arch>/asm while the builddeb script
> > from the Linux kernel places them in: /usr/include/asm. Repack the
> > linux-libc-dev package (fixing a build error for packages built
> > against Isar-created distributions shipping a custom kernel in
> > lieu of Debian's).
>
> To me that sounds like an upstream bug that should not just get
> covered up by repacking. I would propose looking into a kernel patch
> for the "debpkg" step. That patch could be carried in your layer(s)
> and Isar while it is pending upstream.
>
> Looking at both ubuntu and debian, old and new .. it should never
> be /usr/include/asm/.
>
> > Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> > ---
> > meta/recipes-kernel/linux/files/build-kernel.sh | 38
> > +++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 3
> > deletions(-)
> >
> > diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh
> > b/meta/recipes-kernel/linux/files/build-kernel.sh index
> > 8b7b23b..2c97932 100644 ---
> > a/meta/recipes-kernel/linux/files/build-kernel.sh +++
> > b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -9,8 +9,20 @@
> >
> > source /isar/common.sh
> >
> > -host_arch=$(dpkg --print-architecture)
> > +unsupported_arch() {
> > + echo "error: unsupported architecture ($1)" >&2
> > + exit 1
> > +}
> > +
> > +case $target_arch in
> > + amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;;
> > + armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;;
> > + arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;;
> > + mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;;
> > + *) unsupported_arch "$target_arch" ;;
> > +esac
>
> Looks suspiciously like "${CROSS-COMPILE}gcc -dumpmachine". Using that
> would relieve us from carrying those magic strings around.
>
>
> > +host_arch=$(dpkg --print-architecture)
> > if [ "$host_arch" != "$target_arch" ]; then
> > case $target_arch in
> > armhf)
> > @@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then
> > export CROSS_COMPILE="mipsel-linux-gnu-"
> > ;;
> > *)
> > - echo "error: unsupported architecture ($target_arch)"
> > - exit 1
> > + unsupported_arch "$target_arch"
> > ;;
> > esac
> > fi
> > @@ -35,6 +46,7 @@ fi
> > REPACK_DIR="$1/../repack"
> > REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
> > REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
> > +REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers"
> >
> > if [ -e .config ]; then
> > make olddefconfig
> > @@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}"
> > mkdir -p "${REPACK_DIR}"
> > mkdir -p "${REPACK_LINUX_IMAGE_DIR}"
> > mkdir -p "${REPACK_LINUX_HEADERS_DIR}"
> > +mkdir -p "${REPACK_LIBC_HEADERS_DIR}"
> >
> > cp -a debian "${REPACK_DIR}"
> >
> > @@ -67,6 +80,7 @@ cd ..
> >
> > dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb
> > "${REPACK_LINUX_IMAGE_DIR}" dpkg-deb -R
> > linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}"
> > +dpkg-deb -R linux-libc-dev_${PV}-1_*.deb
> > "${REPACK_LIBC_HEADERS_DIR}" dpkg-gencontrol
> > -crepack/debian/control \ -lrepack/debian/changelog \
> > @@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then
> > gunzip "$vmlinuz.gz"
> > fi
> >
> > +# Move libc's asm headers where they are expected
> > +mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
> > +mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm
> > ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} +
> > dpkg-gencontrol -crepack/debian/control \
> > -lrepack/debian/changelog \
> > -frepack/debian/files \
> > @@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \
> > -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \
> > -DArchitecture=$target_arch
> >
> > +dpkg-gencontrol -crepack/debian/control \
> > + -lrepack/debian/changelog \
> > + -frepack/debian/files \
> > + -plinux-libc-dev \
> > + -P"${REPACK_LIBC_HEADERS_DIR}" \
> > + -Vkernel:debarch="${KERNEL_NAME}" \
> > + -DPackage="linux-libc-dev" \
> > + -DSection=kernel \
> > + -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \
> > + -DArchitecture=$target_arch
> > +
> > fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \
> > linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> > rm -f linux-image-${PV}_${PV}-1_*.deb
> > fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \
> > linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> > rm -f linux-headers-${PV}_${PV}-1_*.deb
> > +rm -f linux-libc-dev_${PV}-1_*.deb
> > +fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \
> > + linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb
> >
> > # linux-libc-dev causes dependency problems if we downgrade
> > # remove it after the build so the downgraded version does not get
> > deployed
>
> Ahh this guy is still somehow in the patch. You might want to have a
> look at 7a1f14ca. My guess is that skipping the downgrade is still OK
> because the problem just shows once you install the libc-dev package.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: repack linux-libc-dev
2019-06-13 8:10 ` Henning Schild
2019-06-13 8:32 ` Hombourger, Cedric
@ 2019-06-13 16:05 ` Baurzhan Ismagulov
1 sibling, 0 replies; 6+ messages in thread
From: Baurzhan Ismagulov @ 2019-06-13 16:05 UTC (permalink / raw)
To: isar-users
On Thu, Jun 13, 2019 at 10:10:30AM +0200, Henning Schild wrote:
> To me that sounds like an upstream bug that should not just get covered
> up by repacking. I would propose looking into a kernel patch for the
> "debpkg" step. That patch could be carried in your layer(s) and Isar
> while it is pending upstream.
>
> Looking at both ubuntu and debian, old and new .. it should never
> be /usr/include/asm/.
/usr/include/asm is specified in FHS [1]. Debian moves stuff around to support
e.g. installing of cross-dependencies (multiarch [2]). Back when multiarch was
introduced, Debian was alone with that approach; I haven't used other distros
lately, but I haven't heard about others adopting it, either.
That is why I usually use custom kernel packaging in downstream projects. It
arguably ends up simpler than using deb-pkg. But that's a matter of preference.
Given that deb-pkg is Debian-specific, one may ask upstream about that. That
said, Isar aims at providing a working image. And we already repack stuff. I
think the improvement is useful for more than one project, so if there are no
other disadvantages (building for other arches, etc.), I'd be in favor of
merging it.
1. https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf.
2. https://wiki.debian.org/Multiarch/HOWTO
With kind regards,
Baurzhan.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] linux-custom: repack linux-libc-dev
2019-06-13 15:37 ` Henning Schild
@ 2019-06-13 16:09 ` Henning Schild
0 siblings, 0 replies; 6+ messages in thread
From: Henning Schild @ 2019-06-13 16:09 UTC (permalink / raw)
To: Hombourger, Cedric, Kiszka, Jan (CT RDA IOT SES-DE); +Cc: isar-users
Am Thu, 13 Jun 2019 17:37:33 +0200
schrieb "[ext] Henning Schild" <henning.schild@siemens.com>:
> Am Thu, 13 Jun 2019 08:32:26 +0000
> schrieb "Hombourger, Cedric" <Cedric_Hombourger@mentor.com>:
>
> > Hi Henning
> >
> > Agreed but I would think we would need a work-around in Isar until
> > the proposed change gets accepted by k.org folks (on a different
> > note, I also need to submit a patch to arch/mips/Makefile for
> > builddeb to succeed - my linux-custom recipe would not build without
> > a patch as dtbs don't get built by default while they do on e.g.
> > aarch64)
> >
> > I would therefore suggest to have build-kernel.sh do something like:
> >
> > if [ -d <...>/usr/include/asm ]; then
> > echo "warning: your kernel has incorrectly packaged
> > linux-libc-dev headers" >&2 # apply work-around and repack
> > linux-libc-dev ...
> > mv <...>/usr/include/asm <...>/usr/include/${LIBC_HEADERS_DIR}/
> > ...
> > fi
>
> I guess a backport or such a hack would not be a big deal, after
> upstream accepted your patch. k.org is probably faster than ilbers
>
> Lets at least see what the discussion brings and how fast it starts.
> Maybe upstream will aknowledge the bug right away. Or they might give
> valuable feedback on what we do not understand. ... and should not be
> putting into Isar on the fast-lane
Thinking about it again. The whole repacking should maybe be replaced
with patching the original packing code. That would make clearer what
the changes to the kernel actually are.
If patches do not apply anymore on changing kernels, we would have a
clear warning to review that again.
so we would carry meta/recipes-kernel/linux/files/
linux-image-depends.patch
linux-image-aarch64-uncompressed_4.19.patch
linux-image-aarch64-uncompressed_4.4.patch
...
All these would be SRC_URI += ;apply=no from the inc, which would also
get a new magic patch function deciding which ones to apply depending
on PV.
The result would also be a kernel tree that you could actually
"builddeb" outside of Isar, and skipping the repack might save time.
Henning
> Henning
>
> > I can submit a v2 if the approach is agreeable
> > will roll-up my sleeves a prepare a patch for k.org
> >
> > Cedric
> > ________________________________________
> > From: Henning Schild <henning.schild@siemens.com>
> > Sent: Thursday, June 13, 2019 10:10 AM
> > To: Hombourger, Cedric
> > Cc: isar-users@googlegroups.com
> > Subject: Re: [PATCH] linux-custom: repack linux-libc-dev
> >
> > Am Wed, 12 Jun 2019 22:10:02 +0200
> > schrieb Cedric Hombourger <Cedric_Hombourger@mentor.com>:
> >
> > > Debian's linux-libc-dev package has "asm" headers in the following
> > > directory: /usr/include/<libc-arch>/asm while the builddeb script
> > > from the Linux kernel places them in: /usr/include/asm. Repack the
> > > linux-libc-dev package (fixing a build error for packages built
> > > against Isar-created distributions shipping a custom kernel in
> > > lieu of Debian's).
> >
> > To me that sounds like an upstream bug that should not just get
> > covered up by repacking. I would propose looking into a kernel patch
> > for the "debpkg" step. That patch could be carried in your layer(s)
> > and Isar while it is pending upstream.
> >
> > Looking at both ubuntu and debian, old and new .. it should never
> > be /usr/include/asm/.
> >
> > > Signed-off-by: Cedric Hombourger <Cedric_Hombourger@mentor.com>
> > > ---
> > > meta/recipes-kernel/linux/files/build-kernel.sh | 38
> > > +++++++++++++++++++++++-- 1 file changed, 35 insertions(+), 3
> > > deletions(-)
> > >
> > > diff --git a/meta/recipes-kernel/linux/files/build-kernel.sh
> > > b/meta/recipes-kernel/linux/files/build-kernel.sh index
> > > 8b7b23b..2c97932 100644 ---
> > > a/meta/recipes-kernel/linux/files/build-kernel.sh +++
> > > b/meta/recipes-kernel/linux/files/build-kernel.sh @@ -9,8 +9,20 @@
> > >
> > > source /isar/common.sh
> > >
> > > -host_arch=$(dpkg --print-architecture)
> > > +unsupported_arch() {
> > > + echo "error: unsupported architecture ($1)" >&2
> > > + exit 1
> > > +}
> > > +
> > > +case $target_arch in
> > > + amd64) LIBC_HEADERS_DIR="x86_64-linux-gnu" ;;
> > > + armhf) LIBC_HEADERS_DIR="arm-linux-gnueabihf" ;;
> > > + arm64) LIBC_HEADERS_DIR="aarch64-linux-gnu" ;;
> > > + mipsel) LIBC_HEADERS_DIR="mipsel-linux-gnu" ;;
> > > + *) unsupported_arch "$target_arch" ;;
> > > +esac
> >
> > Looks suspiciously like "${CROSS-COMPILE}gcc -dumpmachine". Using
> > that would relieve us from carrying those magic strings around.
> >
> >
> > > +host_arch=$(dpkg --print-architecture)
> > > if [ "$host_arch" != "$target_arch" ]; then
> > > case $target_arch in
> > > armhf)
> > > @@ -26,8 +38,7 @@ if [ "$host_arch" != "$target_arch" ]; then
> > > export CROSS_COMPILE="mipsel-linux-gnu-"
> > > ;;
> > > *)
> > > - echo "error: unsupported architecture ($target_arch)"
> > > - exit 1
> > > + unsupported_arch "$target_arch"
> > > ;;
> > > esac
> > > fi
> > > @@ -35,6 +46,7 @@ fi
> > > REPACK_DIR="$1/../repack"
> > > REPACK_LINUX_IMAGE_DIR="${REPACK_DIR}/linux-image"
> > > REPACK_LINUX_HEADERS_DIR="${REPACK_DIR}/linux-headers"
> > > +REPACK_LIBC_HEADERS_DIR="${REPACK_DIR}/libc-headers"
> > >
> > > if [ -e .config ]; then
> > > make olddefconfig
> > > @@ -56,6 +68,7 @@ rm -rf "${REPACK_DIR}"
> > > mkdir -p "${REPACK_DIR}"
> > > mkdir -p "${REPACK_LINUX_IMAGE_DIR}"
> > > mkdir -p "${REPACK_LINUX_HEADERS_DIR}"
> > > +mkdir -p "${REPACK_LIBC_HEADERS_DIR}"
> > >
> > > cp -a debian "${REPACK_DIR}"
> > >
> > > @@ -67,6 +80,7 @@ cd ..
> > >
> > > dpkg-deb -R linux-image-${PV}_${PV}-1_*.deb
> > > "${REPACK_LINUX_IMAGE_DIR}" dpkg-deb -R
> > > linux-headers-${PV}_${PV}-1_*.deb "${REPACK_LINUX_HEADERS_DIR}"
> > > +dpkg-deb -R linux-libc-dev_${PV}-1_*.deb
> > > "${REPACK_LIBC_HEADERS_DIR}" dpkg-gencontrol
> > > -crepack/debian/control \ -lrepack/debian/changelog \
> > > @@ -110,6 +124,10 @@ if [ "$target_arch" = "arm64" ]; then
> > > gunzip "$vmlinuz.gz"
> > > fi
> > >
> > > +# Move libc's asm headers where they are expected
> > > +mkdir ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR}
> > > +mv ${REPACK_LIBC_HEADERS_DIR}/usr/include/asm
> > > ${REPACK_LIBC_HEADERS_DIR}/usr/include/${LIBC_HEADERS_DIR} +
> > > dpkg-gencontrol -crepack/debian/control \
> > > -lrepack/debian/changelog \
> > > -frepack/debian/files \
> > > @@ -121,12 +139,26 @@ dpkg-gencontrol -crepack/debian/control \
> > > -DDepends="${KERNEL_HEADERS_DEBIAN_DEPENDS}" \
> > > -DArchitecture=$target_arch
> > >
> > > +dpkg-gencontrol -crepack/debian/control \
> > > + -lrepack/debian/changelog \
> > > + -frepack/debian/files \
> > > + -plinux-libc-dev \
> > > + -P"${REPACK_LIBC_HEADERS_DIR}" \
> > > + -Vkernel:debarch="${KERNEL_NAME}" \
> > > + -DPackage="linux-libc-dev" \
> > > + -DSection=kernel \
> > > + -DDepends="${LIBC_HEADERS_DEBIAN_DEPENDS}" \
> > > + -DArchitecture=$target_arch
> > > +
> > > fakeroot dpkg-deb -b "${REPACK_LINUX_IMAGE_DIR}" \
> > > linux-image-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> > > rm -f linux-image-${PV}_${PV}-1_*.deb
> > > fakeroot dpkg-deb -b "${REPACK_LINUX_HEADERS_DIR}" \
> > > linux-headers-${KERNEL_NAME}_${PV}-1_${KERNEL_NAME}.deb
> > > rm -f linux-headers-${PV}_${PV}-1_*.deb
> > > +rm -f linux-libc-dev_${PV}-1_*.deb
> > > +fakeroot dpkg-deb -b "${REPACK_LIBC_HEADERS_DIR}" \
> > > + linux-libc-dev_${PV}-1_${KERNEL_NAME}.deb
> > >
> > > # linux-libc-dev causes dependency problems if we downgrade
> > > # remove it after the build so the downgraded version does not
> > > get deployed
> >
> > Ahh this guy is still somehow in the patch. You might want to have a
> > look at 7a1f14ca. My guess is that skipping the downgrade is still
> > OK because the problem just shows once you install the libc-dev
> > package.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-06-13 16:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-12 20:10 [PATCH] linux-custom: repack linux-libc-dev Cedric Hombourger
2019-06-13 8:10 ` Henning Schild
2019-06-13 8:32 ` Hombourger, Cedric
2019-06-13 15:37 ` Henning Schild
2019-06-13 16:09 ` Henning Schild
2019-06-13 16:05 ` Baurzhan Ismagulov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox