GNU Cuirass reports arm64 as armhf

Open

Details

6 participants

Bengt Richter
Ludovic Courtès
Maxim Cournoyer
Mathieu Othacehe
Christopher Rodriguez
zimoun

Owner: unassigned

Submitted by: Christopher Rodriguez

Severity: normal

Christopher Rodriguez wrote on 11 Apr 2022 23:55

Recipients:(address . bug-guix@gnu.org)

Message-ID:pkmp4eczhn9sir.fsf@crane.ant.amazon.com

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#221203or 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/54055and

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

Bengt Richter wrote on 12 Apr 2022 01:47

Recipients:(name . Christopher Rodriguez)(address . yewscion@gmail.comis)(address . 54864@debbugs.gnu.org)

Message-ID:20220411234725.GA7517@LionPure

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:

Toggle quote (31 lines)> 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

Christopher Rodriguez wrote on 12 Apr 2022 01:57

[Pending Patch]

Recipients:(address . 54864@debbugs.gnu.org)

Message-ID:pkmp4e5ynf9nad.fsf@crane.ant.amazon.com

Hi Bengt,

Toggle quote (11 lines)> 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#Specificationsto 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

Christopher Rodriguez wrote on 12 Apr 2022 15:31

Also, [BUG]

Recipients:(address . 54864@debbugs.gnu.org)

Message-ID:pkmp4ewnfu8lv3.fsf@crane.ant.amazon.com

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

Ludovic Courtès wrote on 20 Apr 2022 21:55

Re: bug#54864: GNU Cuirass reports arm64 as armhf

Recipients:(name . Christopher Rodriguez)(address . yewscion@gmail.com)(address . 54864@debbugs.gnu.org)

Message-ID:87h76no7gv.fsf@gnu.org

Hi,

Christopher Rodriguez <yewscion@gmail.com> skribis:

Toggle quote (6 lines)

> 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.orgwhere the

problem occurs?

TIA,

Ludo’.

Christopher Rodriguez wrote on 22 Apr 2022 03:33

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID:pkmp4eee1pq4n5.fsf@crane.ant.amazon.com

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

Toggle quote (21 lines)> Hi,
>
> Christopher Rodriguez <yewscion@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/Tupleswhen 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

Maxim Cournoyer wrote on 22 Apr 2022 06:28

Recipients:(name . Christopher Rodriguez)(address . yewscion@gmail.com)

Message-ID:87czh94u83.fsf@gmail.com

Hi Christopher,

[...]

Toggle quote (8 lines)

> 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

Mathieu Othacehe wrote on 26 Apr 2022 09:56

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87fsm0wa5k.fsf@gnu.org

Hello,

Toggle quote (7 lines)

> 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

zimoun wrote on 26 Apr 2022 13:13

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:CAJ3okZ3VRSBtrDjsEsjdhdfcSTwo+Ptip4mCJDppJirOUGizsQ@mail.gmail.com

Hi,

On Tue, 26 Apr 2022 at 10:00, Mathieu Othacehe <othacehe@gnu.org> wrote:

Toggle quote (7 lines)

> > 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.

[...]

Toggle quote (12 lines)> * 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

Ludovic Courtès wrote on 27 Apr 2022 23:37

Recipients:(name . Maxim Cournoyer)(address . maxim.cournoyer@gmail.com)

Message-ID:87r15igqc8.fsf@gnu.org

Hi Maxim,

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

Toggle quote (17 lines)> [...]
>
>> 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:

Toggle snippet (38 lines)$ guix build -s arm64-linux coreutils -n
Backtrace:
In guix/memoization.scm:
    101:0 19 (_ #<hash-table 7f5f81694000 0/31> #<package tar@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@8.32 guix/…>) …))
   586:29 13 (map1 (("grep" #<package grep@3.6 gnu/packages/com…>) …))
   586:29 12 (map1 (("locales" #<package glibc-utf8-locales@2.3…>) …))
   586:29 11 (map1 (("bash" #<package bash-minimal@5.1.8 gnu/pa…>) …))
   586:17 10 (map1 (("gcc" #<package gcc@10.3.0 gnu/packages/co…>) …))
In guix/packages.scm:
  1360:20  9 (rewrite ("gcc" #<package gcc@10.3.0 gnu/packages/com…>))
In guix/memoization.scm:
    101:0  8 (_ #<hash-table 7f5f816f69a0 14/31> #<package gcc@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@10.3.0 gnu/packages/commenceme…>)
In gnu/packages/gcc.scm:
   200:48  4 (arguments #<package gcc@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"

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’.

Ludovic Courtès wrote on 27 Apr 2022 23:52

Recipients:(name . Mathieu Othacehe)(address . othacehe@gnu.org)

Message-ID:87k0bagpob.fsf@gnu.org

Hi,

Mathieu Othacehe <othacehe@gnu.org> skribis:

Toggle quote (10 lines)>> 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. :-)

Toggle quote (16 lines)> 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’.

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 54864@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 54864

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date