When generating the header package, scripts/package/builddeb was inferring the
target architecture by looking at the output of dpkg --print-architecture. This
makes it go instead through the same detection sequence that was previously
implemented in create_package.
Signed-off-by: Nuno Subtil <[email protected]>
---
scripts/package/builddeb | 42 ++++++++++++++++++++++++------------------
1 files changed, 24 insertions(+), 18 deletions(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index f6cbc3d..67a72d2 100644
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -12,21 +12,10 @@
set -e
-create_package() {
- local pname="$1" pdir="$2"
-
- cp debian/copyright "$pdir/usr/share/doc/$pname/"
- cp debian/changelog "$pdir/usr/share/doc/$pname/changelog.Debian"
- gzip -9 "$pdir/usr/share/doc/$pname/changelog.Debian"
- sh -c "cd '$pdir'; find . -type f ! -path './DEBIAN/*' -printf '%P\0' \
- | xargs -r0 md5sum > DEBIAN/md5sums"
-
- # Fix ownership and permissions
- chown -R root:root "$pdir"
- chmod -R go-w "$pdir"
-
+infer_debian_architecture() {
# Attempt to find the correct Debian architecture
- local forcearch="" debarch=""
+ forcearch=""
+ debarch=""
case "$UTS_MACHINE" in
i386|ia64|alpha)
debarch="$UTS_MACHINE" ;;
@@ -60,6 +49,22 @@ create_package() {
if [ -n "$debarch" ] ; then
forcearch="-DArchitecture=$debarch"
fi
+}
+
+create_package() {
+ local pname="$1" pdir="$2"
+
+ cp debian/copyright "$pdir/usr/share/doc/$pname/"
+ cp debian/changelog "$pdir/usr/share/doc/$pname/changelog.Debian"
+ gzip -9 "$pdir/usr/share/doc/$pname/changelog.Debian"
+ sh -c "cd '$pdir'; find . -type f ! -path './DEBIAN/*' -printf '%P\0' \
+ | xargs -r0 md5sum > DEBIAN/md5sums"
+
+ # Fix ownership and permissions
+ chown -R root:root "$pdir"
+ chmod -R go-w "$pdir"
+
+ infer_debian_architecture
# Create the package
dpkg-gencontrol -isp $forcearch -p$pname -P"$pdir"
@@ -246,15 +251,16 @@ mkdir -p "$destdir"
(cd $srctree; tar -c -f - -T /tmp/files$$) | (cd $destdir; tar -xf -)
(cd $objtree; tar -c -f - -T /tmp/objfiles$$) | (cd $destdir; tar -xf -)
rm -f /tmp/files$$ /tmp/objfiles$$
-arch=$(dpkg --print-architecture)
+
+infer_debian_architecture
cat <<EOF >> debian/control
Package: $kernel_headers_packagename
Provides: linux-headers, linux-headers-2.6
-Architecture: $arch
-Description: Linux kernel headers for $KERNELRELEASE on $arch
- This package provides kernel header files for $KERNELRELEASE on $arch
+Architecture: $debarch
+Description: Linux kernel headers for $KERNELRELEASE on $debarch
+ This package provides kernel header files for $KERNELRELEASE on $debarch
.
This is useful for people who need to build external modules
EOF
--
1.7.4.4
It looks like your patch duplicates the arch detection logic that's
already in create_package, except not completely. I think this is not
desirable.
I modified your patch to isolate this logic into a separate function
and respect the KBUILD_DEBARCH override (which mostly means I moved
the original logic into a separate function). This should make your
case work as well, besides respecting the KBUILD_DEBARCH override.
Maks, Michal, can you please take a look at this new patch?
Thanks,
Nuno
On Thu, May 5, 2011 at 11:23, Robert Gordon
<[email protected]> wrote:
> On 5/5/11 10:10 AM, Nuno Subtil wrote:
>
> This patch is not meant to fix that case, only the case where
> KBUILD_DEBARCH is used.
>
> KBUILD_DEBARCH seems to be meant to be used as an override for what
> Debian wants to see as the target architecture. Arguably, the right
> thing to do here might be to do the same arch detection sequence
> that's done in create_package(), which looks at UTS_MACHINE first and
> the KBUILD_DEBARCH override after that (though I'm not entirely sure).
>
> This patch only adds the KBUILD_DEBARCH override, but that is still
> better than the current situation. I can easily get the rest in later
> if needed.
>
> Nuno
>
> On Thu, May 5, 2011 at 08:42, Robert Gordon
> <[email protected]> wrote:
>
> On 05/05/2011 02:07 AM, maximilian attems wrote:
>
> On Wed, May 04, 2011 at 10:48:07PM +0200, Michal Marek wrote:
>
> Adding Maks to CC.
>
> thanks, this one looks, good please disguard the other patch.
>
> On Tue, May 03, 2011 at 10:59:10PM -0700, Nuno Subtil wrote:
>
> When generating the header package, scripts/package/builddeb was inferring
> the
> target architecture by looking at the output of dpkg --print-architecture.
> This
> allows KBUILD_DEBARCH to override that.
>
> Signed-off-by: Nuno Subtil <[email protected]>
>
> Acked-by: maximilian attems <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
> Greetings,
>
> Compile breaks when using the following command:
> ? ?fakeroot make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- deb-pkg
>
> With 'set -x' in scripts/package/builddeb, the relevant output is:
> ? ?+ '[' -n '' ']'
> ? ?++ dpkg --print-architecture
> ? ?+ arch=i386
> This indicates that KBUILD_DEBARCH is not set.
>
> The debian/control file is written with the following section:
> ? ?Package: linux-headers-2.6.39-rc5+
> ? ?Provides: linux-headers, linux-headers-2.6
> ? ?Architecture: i386
> ? ?Description: Linux kernel headers for 2.6.39-rc5+ on i386
> ? ? This package provides kernel header files for 2.6.39-rc5+ on i386
>
> This produces the following error output:
> ? ?+ forcearch=-DArchitecture=armel
> ? ?+ dpkg-gencontrol -isp -DArchitecture=armel
> -plinux-headers-2.6.39-rc5+ -P/opt/kernel-linus/linux-2.6/debian/hdrtmp
> ? ?dpkg-gencontrol: error: current host architecture 'armel' does not
> appear in package's architecture list (i386)
>
> Regards,
> Robert
>
>
> Nuno,
> ???? Thanks for the response.? I am very new at this process, but I am
> trying to learn.? Yesterday, I submitted a patch that was intended to
> address the same issue that you have addressed.? I did what you are
> suggesting by mimicking what is done in create_package(), but leaving
> i386/x86_64 untouched.? Here is the subject of the patch I sent:
>
> [PATCH] kbuild, deb-pkg: set host machine $arch correctly when
> cross-compiling or not
>
> ???? Please advise if I should resend.
>
> Regards,
> Robert
>
> --
>
On Mon, May 09, 2011 at 10:29:22PM -0700, Nuno Subtil wrote:
> It looks like your patch duplicates the arch detection logic that's
> already in create_package, except not completely. I think this is not
> desirable.
>
> I modified your patch to isolate this logic into a separate function
> and respect the KBUILD_DEBARCH override (which mostly means I moved
> the original logic into a separate function). This should make your
> case work as well, besides respecting the KBUILD_DEBARCH override.
>
> Maks, Michal, can you please take a look at this new patch?
thanks doing right now.
Michal please hold off until I have time to give it some runs.
--
maks
On 05/10/2011 05:41 AM, maximilian attems wrote:
> On Mon, May 09, 2011 at 10:29:22PM -0700, Nuno Subtil wrote:
>> It looks like your patch duplicates the arch detection logic that's
>> already in create_package, except not completely. I think this is not
>> desirable.
>>
>> I modified your patch to isolate this logic into a separate function
>> and respect the KBUILD_DEBARCH override (which mostly means I moved
>> the original logic into a separate function). This should make your
>> case work as well, besides respecting the KBUILD_DEBARCH override.
>>
>> Maks, Michal, can you please take a look at this new patch?
> thanks doing right now.
>
> Michal please hold off until I have time to give it some runs.
>
I have tested this patch. It builds fine for arm with the following
command:
fakeroot make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- deb-pkg
However x86_64 fails (when using an i386 machine).
fakeroot make ARCH=x86_64 deb-pkg
The error occurs in scripts/package/builddeb
+ forcearch=-DArchitecture=amd64
+ dpkg-gencontrol -isp -DArchitecture=amd64 -plinux-headers-2.6.39-rc7+
-P/opt/kernel-linus/linux-2.6/debian/hdrtmp
dpkg-gencontrol: error: current host architecture 'i386' does not appear
in package's architecture list (amd64)
The debian/control file is as follows:
cat debian/control
Source: linux-upstream
Section: kernel
Priority: optional
Maintainer: Anonymous <root@robert-VGN-Z690Y>
Standards-Version: 3.8.4
Homepage: http://www.kernel.org/
Package: linux-image-2.6.39-rc7+
Provides: linux-image, linux-image-2.6, linux-modules-2.6.39-rc7+
Suggests: linux-firmware-image
Architecture: any
Description: Linux kernel, version 2.6.39-rc7+
This package contains the Linux kernel, modules and corresponding other
files, version: 2.6.39-rc7+.
Package: linux-headers-2.6.39-rc7+
Provides: linux-headers, linux-headers-2.6
Architecture: amd64
Description: Linux kernel headers for 2.6.39-rc7+ on amd64
This package provides kernel header files for 2.6.39-rc7+ on amd64
.
This is useful for people who need to build external modules
The debian/control file for an unpatched scripts/package/builddeb would
assign 'i386' instead of 'amd64'.
Regards,
Robert
> The debian/control file for an unpatched scripts/package/builddeb would
> assign 'i386' instead of 'amd64'.
That seems wrong to me. Were the resulting packages actually usable on amd64?
On Thu, May 12, 2011 at 07:01, Robert Gordon
<[email protected]> wrote:
> On 05/10/2011 05:41 AM, maximilian attems wrote:
>> On Mon, May 09, 2011 at 10:29:22PM -0700, Nuno Subtil wrote:
>>> It looks like your patch duplicates the arch detection logic that's
>>> already in create_package, except not completely. I think this is not
>>> desirable.
>>>
>>> I modified your patch to isolate this logic into a separate function
>>> and respect the KBUILD_DEBARCH override (which mostly means I moved
>>> the original logic into a separate function). This should make your
>>> case work as well, besides respecting the KBUILD_DEBARCH override.
>>>
>>> Maks, Michal, can you please take a look at this new patch?
>> thanks doing right now.
>>
>> Michal please hold off until I have time to give it some runs.
>>
> I have tested this patch. ?It builds fine for arm with the following
> command:
> fakeroot make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- deb-pkg
>
> However x86_64 fails (when using an i386 machine).
> fakeroot make ARCH=x86_64 deb-pkg
>
> The error occurs in scripts/package/builddeb
> + forcearch=-DArchitecture=amd64
> + dpkg-gencontrol -isp -DArchitecture=amd64 -plinux-headers-2.6.39-rc7+
> -P/opt/kernel-linus/linux-2.6/debian/hdrtmp
> dpkg-gencontrol: error: current host architecture 'i386' does not appear
> in package's architecture list (amd64)
>
> The debian/control file is as follows:
> cat debian/control
> Source: linux-upstream
> Section: kernel
> Priority: optional
> Maintainer: Anonymous <root@robert-VGN-Z690Y>
> Standards-Version: 3.8.4
> Homepage: http://www.kernel.org/
>
> Package: linux-image-2.6.39-rc7+
> Provides: linux-image, linux-image-2.6, linux-modules-2.6.39-rc7+
> Suggests: linux-firmware-image
> Architecture: any
> Description: Linux kernel, version 2.6.39-rc7+
> ?This package contains the Linux kernel, modules and corresponding other
> ?files, version: 2.6.39-rc7+.
>
> Package: linux-headers-2.6.39-rc7+
> Provides: linux-headers, linux-headers-2.6
> Architecture: amd64
> Description: Linux kernel headers for 2.6.39-rc7+ on amd64
> ?This package provides kernel header files for 2.6.39-rc7+ on amd64
> ?.
> ?This is useful for people who need to build external modules
>
>
>
> The debian/control file for an unpatched scripts/package/builddeb would
> assign 'i386' instead of 'amd64'.
>
> Regards,
> Robert
>
>
On 5/12/11 12:45 PM, Nuno Subtil wrote:
>> The debian/control file for an unpatched scripts/package/builddeb would
>> assign 'i386' instead of 'amd64'.
>
> That seems wrong to me. Were the resulting packages actually usable on amd64?
I modeled my patch after behavior I saw in the unpatched script. I had
also originally set x86_64 to amd64 with the exact results I get with
your patch. So, I looked at what the unpatched kernel was doing, which
is putting i386 in those fields when building for x86_64 on an i386
machine. I don't know the results would actually run because I don't
have an x86_64 myself. It may not run, but it does build.
cheers!
--
*http://www.greenroomsoftware.com*