GNU bug report logs - #54864
GNU Cuirass reports arm64 as armhf

Previous Next

To reply to this bug, email your comments to 54864 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Rodriguez <yewscion <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: GNU Cuirass reports arm64 as armhf
Date: Mon, 11 Apr 2022 17:55:41 -0400

[Message part 1 (text/plain, inline)]

Reporting this from my local installs of GNU Cuirass, though a cursory glance at
ci.guix.gnu.org (likely) shows the same issue:

GNU Cuirass currently reports both `armhf-linux` and `arm64-linux` targets as
`armhf-linux` on the web interface.

This is not only incorrect, but potentially confusing to newcomers: I have spent
some free time in the last week or two (after purchasing an MNT Reform) trying
to get my home server to build packages for deployment on an ARM-based laptop. I
only discovered that I was targeting the 32-bit version of ARM after asking on
IRC (and then looking through the logs:
https://logs.guix.gnu.org/guix/2022-04-11.log#221203 or thereabouts, where
vagrantc mentions `armhf` as suffering bitrot and goes on to mention both
`aarch64` and `arm64` in another sentence).

This is not helped by the Documentation
(https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications) not giving any
examples of supported platforms, highly-search-engine-ranked issues and blog
posts (https://issues.guix.gnu.org/54055 and
https://guix.gnu.org/en/blog/2021/cuirass-10-released/ for instance, both
front-page google) only mentioning `armhf-linux`, and all running instances of
GNU Cuirass not even listing `arm64-linux` as an option.

When I have time (I am out of town for the rest of the week) I will try to
submit a patch for the documentation to list the available targets. Changing the
UI is more complex (though wider-reaching) and a bit more out of my
wheelhouse. Help there would be appreciated.

--

Christopher Rodriguez

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Bengt Richter <bokr <at> bokr.com>
To: Christopher Rodriguez <yewscion <at> gmail.comis>
Cc: 54864 <at> debbugs.gnu.org
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Tue, 12 Apr 2022 01:47:25 +0200

Hi Christopher,

Tl;dr: [Meta-Reply]

I think IWBN if a busy volunteer like yourself could add
a cookie in an email like yours that would automatically
provide a "heads-up" to readers of the documentation you
intend to patch.

The idea is that emails could be automatically scanned for
such cookies/markup, e.g. maybe "[Pending-Patch]", next to
an URL for the doc in question, which URL could then simply
be appended to a log file of such urls, (maybe together with
date and author from the email header).

People could manually grep it if reading a document that
is confusing, to check if an update is on the way, for starters.

But if it's a good idea, then I would hope document reading
tools would start to make automatic use of it, maybe starting
with a notice like "Heads Up: [Pending-Patch]" when opening the doc or
section of the doc.

It could grow features as people came up with new and better ideas,
but I think there are developers here that could prototype something
useful in an evening :)

Thus, given that you took the time to write your email, it would not have
been much extra trouble adding the cookie so your text below would look like e.g.,

    ([Pending-Patch] https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications)

(IIUC that's the doc you intend to patch) :)

HTH in some way.
Better ideas? I don't mind :)

On +2022-04-11 17:55:41 -0400, Christopher Rodriguez wrote:
> Reporting this from my local installs of GNU Cuirass, though a cursory glance at
> ci.guix.gnu.org (likely) shows the same issue:
> 
> GNU Cuirass currently reports both `armhf-linux` and `arm64-linux` targets as
> `armhf-linux` on the web interface.
> 
> This is not only incorrect, but potentially confusing to newcomers: I have spent
> some free time in the last week or two (after purchasing an MNT Reform) trying
> to get my home server to build packages for deployment on an ARM-based laptop. I
> only discovered that I was targeting the 32-bit version of ARM after asking on
> IRC (and then looking through the logs:
> https://logs.guix.gnu.org/guix/2022-04-11.log#221203 or thereabouts, where
> vagrantc mentions `armhf` as suffering bitrot and goes on to mention both
> `aarch64` and `arm64` in another sentence).
> 
> This is not helped by the Documentation
> (https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications) not giving any
> examples of supported platforms, highly-search-engine-ranked issues and blog
> posts (https://issues.guix.gnu.org/54055 and
> https://guix.gnu.org/en/blog/2021/cuirass-10-released/ for instance, both
> front-page google) only mentioning `armhf-linux`, and all running instances of
> GNU Cuirass not even listing `arm64-linux` as an option.
> 
> When I have time (I am out of town for the rest of the week) I will try to
> submit a patch for the documentation to list the available targets. Changing the
> UI is more complex (though wider-reaching) and a bit more out of my
> wheelhouse. Help there would be appreciated.
> 
> --
> 
> Christopher Rodriguez
-- 
Regards,
Bengt Richter

Message #11 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Rodriguez <yewscion <at> gmail.com>
To: 54864 <at> debbugs.gnu.org
Subject: [Pending Patch]
Date: Mon, 11 Apr 2022 19:57:44 -0400

Hi Bengt,

> I think IWBN if a busy volunteer like yourself could add
> a cookie in an email like yours that would automatically
> provide a "heads-up" to readers of the documentation you
> intend to patch.
> 
> The idea is that emails could be automatically scanned for
> such cookies/markup, e.g. maybe "[Pending-Patch]", next to
> an URL for the doc in question, which URL could then simply
> be appended to a log file of such urls, (maybe together with
> date and author from the email header).

I think this is a great idea. Does something like this already exist? If it
does, I'm unaware of it (and I am sorry I didn't use it here).

If I've otherwise misstepped some kind of convention here, please let me
know. I'm not great at picking up subtext, but it sounds like I messed up in
some way, and I'd like to learn so I don't do it again (still very new to
contributing to this community).

That said, I do indeed intend to patch [Pending-Patch]
https://guix.gnu.org/cuirass/manual/cuirass.html#Specifications to be clearer
about the available targets. I would amend the subject of this issue, but it
doesn't seem like that's something I can do.

--

Christopher Rodriguez

Message #14 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Rodriguez <yewscion <at> gmail.com>
To: 54864 <at> debbugs.gnu.org
Subject: Also, [BUG]
Date: Tue, 12 Apr 2022 09:31:28 -0400

[Message part 1 (text/plain, inline)]

I also wanted to report a [BUG]: the UI for Gnu Cuirass lists
specifications defined as targetting either `armhf-linux` and
`arm64-linux` as `armhf-linux` on the Web UI, which should be changed to
report the accurate build target (if both `armhf-linux` and
`arm64-linux` are indeed still valid targets for builds).

--

Christopher Rodriguez

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Rodriguez <yewscion <at> gmail.com>
Cc: 54864 <at> debbugs.gnu.org
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Wed, 20 Apr 2022 21:55:28 +0200

Hi,

Christopher Rodriguez <yewscion <at> gmail.com> skribis:

> Reporting this from my local installs of GNU Cuirass, though a cursory glance at
> ci.guix.gnu.org (likely) shows the same issue:
>
> GNU Cuirass currently reports both `armhf-linux` and `arm64-linux` targets as
> `armhf-linux` on the web interface.

There’s no ‘arm64-linux’ system type (in Guix); it’s called
‘aarch64-linux’.

Could it be the source of the confusion?

If not, could you point to a page at https://ci.guix.gnu.org where the
problem occurs?

TIA,
Ludo’.

Message #20 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Rodriguez <yewscion <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Christopher Rodriguez <yewscion <at> gmail.com>, 54864 <at> debbugs.gnu.org
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Thu, 21 Apr 2022 21:33:00 -0400

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hi,
>
> Christopher Rodriguez <yewscion <at> gmail.com> skribis:
>
>> Reporting this from my local installs of GNU Cuirass, though a cursory glance at
>> ci.guix.gnu.org (likely) shows the same issue:
>>
>> GNU Cuirass currently reports both `armhf-linux` and `arm64-linux` targets as
>> `armhf-linux` on the web interface.
>
> There’s no ‘arm64-linux’ system type (in Guix); it’s called
> ‘aarch64-linux’.
>
> Could it be the source of the confusion?
>
> If not, could you point to a page at https://ci.guix.gnu.org where the
> problem occurs?
>
> TIA,
> Ludo’.

Hi Ludo',

I see, yeah, I eventually figured out that aarch64 was what I was
supposed to be using (I think I was reading
https://wiki.debian.org/Multiarch/Tuples when I realized this).

However, what confuses me still was that 'arm64-linux' did work as a
system type: A bunch of packages failed to build, but some builds were
successful. Maybe that input just makes it default to 'armhf-linux'?

--

Christopher Rodriguez

Message #23 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Christopher Rodriguez <yewscion <at> gmail.com>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 54864 <at> debbugs.gnu.org
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Fri, 22 Apr 2022 00:28:44 -0400

Hi Christopher,

[...]

> I see, yeah, I eventually figured out that aarch64 was what I was
> supposed to be using (I think I was reading
> https://wiki.debian.org/Multiarch/Tuples when I realized this).
>
> However, what confuses me still was that 'arm64-linux' did work as a
> system type: A bunch of packages failed to build, but some builds were
> successful. Maybe that input just makes it default to 'armhf-linux'?

I've had this experience before, it's very confusing (it goes on trying
to build a toolchain for something that is sure to fail).  Perhaps we
could at least have a place to refer to in the manual for the common GNU
triplets which make the most sense in for GNU Guix (e.g., the currently
supported GNU system triplets).  Currently I grep the manual for
disparate examples when my memory fail me.

Thanks,

Maxim

Message #26 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Mathieu Othacehe <othacehe <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Christopher Rodriguez <yewscion <at> gmail.com>, 54864 <at> debbugs.gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Tue, 26 Apr 2022 09:56:07 +0200

Hello,

> I've had this experience before, it's very confusing (it goes on trying
> to build a toolchain for something that is sure to fail).  Perhaps we
> could at least have a place to refer to in the manual for the common GNU
> triplets which make the most sense in for GNU Guix (e.g., the currently
> supported GNU system triplets).  Currently I grep the manual for
> disparate examples when my memory fail me.

Yes, I also cannot remember those triplets even though I'm
cross-compiling all day long.

Maybe we could:

* Define all the supported architectures in (gnu platforms). We already
  have ARM and Hurd defined there.

* Define %supported-systems and %supported-targets lists constructed by
  parsing the <platform> records.

* Use those lists to check the values passed to --system and --target
  arguments.

* Add --list-available-systems and --list-available-targets arguments
  for all the commands supporting --system and --target arguments.

WDYT?

In the meantime we can close that one I guess.

Thanks,

Mathieu

Message #29 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Christopher Rodriguez <yewscion <at> gmail.com>, 54864 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Tue, 26 Apr 2022 13:13:27 +0200

Hi,

On Tue, 26 Apr 2022 at 10:00, Mathieu Othacehe <othacehe <at> gnu.org> wrote:
> > I've had this experience before, it's very confusing (it goes on trying
> > to build a toolchain for something that is sure to fail).  Perhaps we
> > could at least have a place to refer to in the manual for the common GNU
> > triplets which make the most sense in for GNU Guix (e.g., the currently
> > supported GNU system triplets).  Currently I grep the manual for
> > disparate examples when my memory fail me.

[...]

> * Define all the supported architectures in (gnu platforms). We already
>   have ARM and Hurd defined there.
>
> * Define %supported-systems and %supported-targets lists constructed by
>   parsing the <platform> records.
>
> * Use those lists to check the values passed to --system and --target
>   arguments.
>
> * Add --list-available-systems and --list-available-targets arguments
>   for all the commands supporting --system and --target arguments.

I agree.  It would ease the dance.

In addition, it would help to have a subsection in the manual about
"cross-compilation"; maybe under the Development section.  For
instance, I do not find clear the difference between 'system' and
'target'.  And the explanations for the triplet are outside the Guix
manual, pointing to [1] which I do not find very clear.  Something
like an explicit list of possible values for this triplet would be
worth.


1: <https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Specifying-target-triplets>

Cheers,
simon

Message #32 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: Christopher Rodriguez <yewscion <at> gmail.com>, 54864 <at> debbugs.gnu.org
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Wed, 27 Apr 2022 23:37:43 +0200

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

> [...]
>
>> I see, yeah, I eventually figured out that aarch64 was what I was
>> supposed to be using (I think I was reading
>> https://wiki.debian.org/Multiarch/Tuples when I realized this).
>>
>> However, what confuses me still was that 'arm64-linux' did work as a
>> system type: A bunch of packages failed to build, but some builds were
>> successful. Maybe that input just makes it default to 'armhf-linux'?
>
> I've had this experience before, it's very confusing (it goes on trying
> to build a toolchain for something that is sure to fail).  Perhaps we
> could at least have a place to refer to in the manual for the common GNU
> triplets which make the most sense in for GNU Guix (e.g., the currently
> supported GNU system triplets).  Currently I grep the manual for
> disparate examples when my memory fail me.

“aarch64-linux” & co. are Nix/Guix “system types”; GNU triplets look
like “aarch64-linux-gnu” or “i686-pc-linux-gnu” (info "(autoconf)
Specifying Target Triplets").  Triplets are passed to ‘--target’.

Note that the current situation is:

--8<---------------cut here---------------start------------->8---
$ guix build -s arm64-linux coreutils -n
Backtrace:
In guix/memoization.scm:
    101:0 19 (_ #<hash-table 7f5f81694000 0/31> #<package tar <at> 1.34 …> …)
In guix/packages.scm:
  1247:37 18 (_)
  1507:16 17 (package->bag _ _ _ #:graft? _)
  1608:48 16 (thunk)
  1403:25 15 (inputs _)
In srfi/srfi-1.scm:
   586:29 14 (map1 (("coreutils" #<package coreutils <at> 8.32 guix/…>) …))
   586:29 13 (map1 (("grep" #<package grep <at> 3.6 gnu/packages/com…>) …))
   586:29 12 (map1 (("locales" #<package glibc-utf8-locales <at> 2.3…>) …))
   586:29 11 (map1 (("bash" #<package bash-minimal <at> 5.1.8 gnu/pa…>) …))
   586:17 10 (map1 (("gcc" #<package gcc <at> 10.3.0 gnu/packages/co…>) …))
In guix/packages.scm:
  1360:20  9 (rewrite ("gcc" #<package gcc <at> 10.3.0 gnu/packages/com…>))
In guix/memoization.scm:
    101:0  8 (_ #<hash-table 7f5f816f69a0 14/31> #<package gcc <at> 10.3…> …)
In guix/packages.scm:
  1374:13  7 (_)
In guix/build-system/gnu.scm:
   157:33  6 (cut? _)
In gnu/packages/commencement.scm:
  3522:39  5 (arguments #<package gcc <at> 10.3.0 gnu/packages/commenceme…>)
In gnu/packages/gcc.scm:
   200:48  4 (arguments #<package gcc <at> 4.8.5 gnu/packages/gcc.scm:382…>)
In gnu/packages/bootstrap.scm:
   342:14  3 (glibc-dynamic-linker _)
In ice-9/boot-9.scm:
  1685:16  2 (raise-exception _ #:continuable? _)
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
dynamic linker name not known for this system "arm64-linux"
--8<---------------cut here---------------end--------------->8---

I suspect Cuirass hides this somewhat and goes on building fixed-output
derivations (i.e., source code downloads), which are system-independent,
giving this impression that it’s kinda working when it really isn’t?

HTH,
Ludo’.

Message #35 received at 54864 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mathieu Othacehe <othacehe <at> gnu.org>
Cc: Christopher Rodriguez <yewscion <at> gmail.com>, 54864 <at> debbugs.gnu.org,
 Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#54864: GNU Cuirass reports arm64 as armhf
Date: Wed, 27 Apr 2022 23:52:04 +0200

Hi,

Mathieu Othacehe <othacehe <at> gnu.org> skribis:

>> I've had this experience before, it's very confusing (it goes on trying
>> to build a toolchain for something that is sure to fail).  Perhaps we
>> could at least have a place to refer to in the manual for the common GNU
>> triplets which make the most sense in for GNU Guix (e.g., the currently
>> supported GNU system triplets).  Currently I grep the manual for
>> disparate examples when my memory fail me.
>
> Yes, I also cannot remember those triplets even though I'm
> cross-compiling all day long.

This bug report was about system types, not triplets, but the problem is
kinda similar and equally in need of a fix.  :-)

> Maybe we could:
>
> * Define all the supported architectures in (gnu platforms). We already
>   have ARM and Hurd defined there.
>
> * Define %supported-systems and %supported-targets lists constructed by
>   parsing the <platform> records.
>
> * Use those lists to check the values passed to --system and --target
>   arguments.
>
> * Add --list-available-systems and --list-available-targets arguments
>   for all the commands supporting --system and --target arguments.
>
> WDYT?

I think it’s “nice” for ‘--target’ to accept a free-form triplet,
because users might want to target a system triplet that Guix
maintainers do not care about (we only cross-build for a handful of
triplets right now).

Based on that, I thought we could emit warnings when ‘cross-gcc’ &
co. were passed a string that doesn’t look like a valid triplet.  But
then I realized that internally these procedures are passed things that
are not quite triplets: see avr.scm and embedded.scm.

So, a list of “supported” triplets like you suggest may be a good idea,
though IMO it should be used to emit a warning rather than error out.

For system types, we can probably error out to strings not in the list.

Thoughts?

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.