Both Debian and kernel archs are "arm64" but UTS_MACHINE and gcc say
"aarch64". Recognizing just the latter should be enough but let's
accept both in case something regresses again or an user sets
UTS_MACHINE=arm64.
Regressed in cfa88c7: arm64: Set UTS_MACHINE in the Makefile.
Signed-off-by: Adam Borowski <kilobyte@xxxxxxxxxx>
Acked-by: Riku Voipio <riku.voipio@xxxxxxxxxx>
---
scripts/package/builddeb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..3c575cd0 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -51,7 +51,7 @@ set_debarch() {
debarch=hppa ;;
mips*)
debarch=mips$(grep -q CPU_LITTLE_ENDIAN=y $KCONFIG_CONFIG && echo el || true) ;;
- arm64)
+ aarch64|arm64)
debarch=arm64 ;;
arm*)
if grep -q CONFIG_AEABI=y $KCONFIG_CONFIG; then
--
2.10.2
Riku Voipio wrote:
> On 10 November 2016 at 13:04, Michal Marek <mmarek@xxxxxxxx> wrote:
> >
> > UTS_MACHINE is now always aarch64 on this architecture, so maybe stop
> matching "arm64" to avoid confusion?
>
> I was wondering if it might makes sense to keep the arm64 around for a
> while, for example if someone reverts the UTS_MACHINE setting patch
> from arch/arm64 for unrelated reasons and still tries to build a deb.
> But I guess that's a corner case, and it's indeed cleaner without the
> arm64 bit. So either way works for me.
I think that it's better to be liberal in what you accept, especially for
something an user might want to override. It's up to you guys to decide,
though.
Here's a version with no changes but the commit message extended to mention
cfa88c7 and "aarch64" being sufficient.
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
