bug#54864: GNU Cuirass reports arm64 as armhf

bug#54864: GNU Cuirass reports arm64 as armhf

[Christopher Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#54864: GNU Cuirass reports arm64 as armhf

[Bengt Richter]

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

bug#54864: [Pending Patch]

[Christopher Rodriguez]

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

bug#54864: Also, [BUG]

[Christopher Rodriguez]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#54864: GNU Cuirass reports arm64 as armhf

[Ludovic Courtès]

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

bug#54864: GNU Cuirass reports arm64 as armhf

[Christopher Rodriguez]

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

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

bug#54864: GNU Cuirass reports arm64 as armhf

[Maxim Cournoyer]

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

bug#54864: GNU Cuirass reports arm64 as armhf

[Mathieu Othacehe]

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

bug#54864: GNU Cuirass reports arm64 as armhf

[zimoun]

Hi,

On Tue, 26 Apr 2022 at 10:00, Mathieu Othacehe <othacehe@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

bug#54864: GNU Cuirass reports arm64 as armhf

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@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@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"
--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’.

bug#54864: GNU Cuirass reports arm64 as armhf

[Ludovic Courtès]

Hi,

Mathieu Othacehe <othacehe@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’.