MIPS support

MIPS support

[Christopher Baines]

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

Hey,

I was wondering about MIPS support, mainly because the Guix Data Service
uses QEMU to emulate different systems so that the channel instance
derivations can be computed (like [1]). I'm not sure if the emulation is
really necessary, but that's how it works at the moment.

1: http://data.guix.gnu.org/revision/198571b264547f800803e554c8f21a9c95be959c/channel-instances

I've not enabled the QEMU emulation for MIPS on data.guix.gnu.org,
because I've never managed to get it working locally. Computing the
channel derivation starts building lots of things, but something always
fails.

I've looked in to this a bit more. On master, the bison-boot0 package
tries to do the build and tests in parallel, and
fails. This is fixed on core-updates. If you work around the bison-boot0
issue on master, then I get a segfault during gcc-cross-boot0-7.4.0:

g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic-family -I../../gcc-7.4.0/gcc -I../../gcc-7.4.0/gcc/c-family -I../../gcc-7.4.0/gcc/../include -I../../gcc-7.4.0/gcc/../libcpp/include -I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/gmp -I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/./mpfr/src -I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/mpfr/src -I/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/gcc-7.4.0/mpc/src  -I../../gcc-7.4.0/gcc/../libdecnumber -I../../gcc-7.4.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-7.4.0/gcc/../libbacktrace   -o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../gcc-7.4.0/gcc/c-family/c-common.c
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [Makefile:1099: c-family/c-common.o] Error 4
make[2]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build/gcc'
make[1]: *** [Makefile:4215: all-gcc] Error 2
make[1]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.4.0.drv-0/build'
make: *** [Makefile:881: all] Error 2
command "make" "-j" "1" "LDFLAGS=-Wl,-rpath=/gnu/store/z2i5vj66b6y23v8fywsf7bwnppyhssks-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/z2i5vj66b6y23v8fywsf7bwnppyhssks-glibc-bootstrap-0/lib/ld.so.1" failed with status 2
builder for `/gnu/store/dzgvjam38vn7i7d1iml2a34p5h3lyggd-gcc-cross-boot0-7.4.0.drv' failed with exit code 1
build of /gnu/store/dzgvjam38vn7i7d1iml2a34p5h3lyggd-gcc-cross-boot0-7.4.0.drv failed


On core-updates, it's pretty similar. The gcc-cross-boot0-7.5.0
derivation seems to hang at the same point the gcc-cross-boot0-7.4.0
derivation segfaulted:

g++ -fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Ic-family -I../../gcc-7.5.0/gcc -I../../gcc-7.5.0/gcc/c-family -I../../gcc-7.5.0/gcc/../include -I../../gcc-7.5.0/gcc/../libcpp/include -I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./gmp -I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/gmp -I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/./mpfr/src -I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/mpfr/src -I/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/gcc-7.5.0/mpc/src  -I../../gcc-7.5.0/gcc/../libdecnumber -I../../gcc-7.5.0/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-7.5.0/gcc/../libbacktrace   -o c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo ../../gcc-7.5.0/gcc/c-family/c-common.c


From htop, I can see the QEMU emulated g++ with a QEMU emulated cc1plus
subprocess, but nothing is happening.

Any ideas?

Thanks,

Chris

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

Re: MIPS support

[Leo Famulari]

On Wed, Apr 08, 2020 at 08:32:00PM +0100, Christopher Baines wrote:
> I was wondering about MIPS support, mainly because the Guix Data Service
> uses QEMU to emulate different systems so that the channel instance
> derivations can be computed (like [1]). I'm not sure if the emulation is
> really necessary, but that's how it works at the moment.

I'm not sure if the MIPS port ever resumed after being suspended:

https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00790.html

Re: MIPS support

[Ludovic Courtès]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> On Wed, Apr 08, 2020 at 08:32:00PM +0100, Christopher Baines wrote:
>> I was wondering about MIPS support, mainly because the Guix Data Service
>> uses QEMU to emulate different systems so that the channel instance
>> derivations can be computed (like [1]). I'm not sure if the emulation is
>> really necessary, but that's how it works at the moment.
>
> I'm not sure if the MIPS port ever resumed after being suspended:
>
> https://lists.gnu.org/archive/html/guix-devel/2017-03/msg00790.html

In the intervening years, interest faded away as free software friendly
MIPS hardware became more rare.

Perhaps it would be more honest to officially remove the MIPS port now?

Technically that would involve removing it from the manual, from
configure.ac, and little more.

If there’s a need for it in the future, and developments happening for
MIPS in general (for the GNU tool chain, the kernel, etc.), then we can
always start a new MIPS port.  Until then, POWER9 and perhaps RISC-V
seem to have more appeal to free software hackers.

What do people think?

Ludo’.

Re: MIPS support

[Vincent Legoll]

Hello,

> In the intervening years, interest faded away as free software friendly
> MIPS hardware became more rare.

I grabbed a gnubee during the crowdfunding campaign, but the CPU
is too low spec to do a lot of compilation on it.

> Perhaps it would be more honest to officially remove the MIPS port now?
>
> Technically that would involve removing it from the manual, from
> configure.ac, and little more.

From the manual or from the CI, to let the build farm do more useful things
I'm not against, but is it really making maintenance difficult by still being in
the codebase ?

> If there’s a need for it in the future, and developments happening for
> MIPS in general (for the GNU tool chain, the kernel, etc.), then we can
> always start a new MIPS port.

The kernel side looks good enough to me, there's a lot of openwrt
running on mips and it looks well maintained.

> Until then, POWER9 and perhaps RISC-V seem to have more
> appeal to free software hackers.

I have grabbed an old power8, that I also intend to put guix on.

> What do people think?

I may not be able to put huge time in it so won't ask you to keep it
just for me.

I'll restart working / trying things in the foreign archs area after my
list of pending things is drained a bit (guix-install.sh & tarball CI,
native-inputs lint warning chasing) but that's only wishful thinking
for now.

-- 
Vincent Legoll

Re: MIPS support

[Jack Hill]

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

On Wed, 6 May 2020, Vincent Legoll wrote:

> Hello,
>
>> In the intervening years, interest faded away as free software friendly
>> MIPS hardware became more rare.
>
> I grabbed a gnubee during the crowdfunding campaign, but the CPU
> is too low spec to do a lot of compilation on it.

I also have a gnubee, and would love to be able to put Guix on it. 
However, so far I haven't put much time into getting it working. It would 
certainly be more fun to work on it with others :)

My impression is that the the gnubee is a different class of MIPS than the 
current port. I think that the gnubee is a SoC that is is targeted at home 
routers and is 32-bit, while the current port is 64-bit and targeted at 
chips like the longsoon. Is that correct?

There seems to be a a fair amount of the router-class hardware available 
that works with Free Software, but not much, if any, of the latter, more 
powerful hardware. Unfortunately, I think having the more powerful 
hardware available would make it much easier to work on the port.

[…]

>> What do people think?
>
> I may not be able to put huge time in it so won't ask you to keep it
> just for me.
>
> I'll restart working / trying things in the foreign archs area after my
> list of pending things is drained a bit (guix-install.sh & tarball CI,
> native-inputs lint warning chasing) but that's only wishful thinking
> for now.

I feel similarly. It's always sad to see things go (I used to have a 
collection of SPARC hardware, but let it go when I moved a few years ago), 
but no need to keep it just for me.

Vincent, it sounds like there are at least two of us. Maybe we can work 
together.

Best,
Jack

Re: MIPS support

[Christopher Baines]

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


Vincent Legoll <vincent.legoll@gmail.com> writes:


>> In the intervening years, interest faded away as free software friendly
>> MIPS hardware became more rare.
>
> I grabbed a gnubee during the crowdfunding campaign, but the CPU
> is too low spec to do a lot of compilation on it.

At least the main blocker for me is the lack of substitutes for the
things that fail to build with QEMU. So maybe one or a few machines
which were able to build those specific things would be sufficient to
provide some substitutes.

I did have a look at seeing if I could purchase hardware, but I didn't
really know what to look at. Maybe we could try putting out an appeal
for MIPS hardware, maybe someone has some they don't use and would
donate?

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

Re: MIPS support

[Leo Famulari]

On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> From the manual or from the CI, to let the build farm do more useful things
> I'm not against, but is it really making maintenance difficult by still being in
> the codebase ?

It's not really a maintenance burden currently since we don't actually
build or maintain the Guix on MIPS at all.

I think this discussion is evidence that people find the situation a bit
confusing. When I am looking into a project, I find it demotivating to
read documentation about features that may or may not work — it's best
when the documentation accurately reflects what the software can do.

Re: MIPS support

[Ludovic Courtès]

Hi,

Leo Famulari <leo@famulari.name> skribis:

> On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
>> From the manual or from the CI, to let the build farm do more useful things
>> I'm not against, but is it really making maintenance difficult by still being in
>> the codebase ?
>
> It's not really a maintenance burden currently since we don't actually
> build or maintain the Guix on MIPS at all.
>
> I think this discussion is evidence that people find the situation a bit
> confusing. When I am looking into a project, I find it demotivating to
> read documentation about features that may or may not work — it's best
> when the documentation accurately reflects what the software can do.

Right, that was my point: let’s remove mentions of MIPS from the manual
and from ‘configure.ac’ so people have the right expectations.

Thoughts?

Ludo’.

Re: MIPS support

[Efraim Flashner]

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

On Mon, May 18, 2020 at 12:12:24AM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Leo Famulari <leo@famulari.name> skribis:
> 
> > On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> >> From the manual or from the CI, to let the build farm do more useful things
> >> I'm not against, but is it really making maintenance difficult by still being in
> >> the codebase ?
> >
> > It's not really a maintenance burden currently since we don't actually
> > build or maintain the Guix on MIPS at all.
> >
> > I think this discussion is evidence that people find the situation a bit
> > confusing. When I am looking into a project, I find it demotivating to
> > read documentation about features that may or may not work — it's best
> > when the documentation accurately reflects what the software can do.
> 
> Right, that was my point: let’s remove mentions of MIPS from the manual
> and from ‘configure.ac’ so people have the right expectations.
> 
> Thoughts?

So change it so that mips needs '--with-courage' but not remove the
bootstrap binaries from the code? Do we want to fully remove the mention
of mips as a supported platform or change it to "in the past we had an
active mips64el port which is in need of more attention to bring it back
to a fully supported platform. Help wanted!"

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: MIPS support

[Ludovic Courtès]

Hey!

Efraim Flashner <efraim@flashner.co.il> skribis:

> On Mon, May 18, 2020 at 12:12:24AM +0200, Ludovic Courtès wrote:
>> Hi,
>> 
>> Leo Famulari <leo@famulari.name> skribis:
>> 
>> > On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
>> >> From the manual or from the CI, to let the build farm do more useful things
>> >> I'm not against, but is it really making maintenance difficult by still being in
>> >> the codebase ?
>> >
>> > It's not really a maintenance burden currently since we don't actually
>> > build or maintain the Guix on MIPS at all.
>> >
>> > I think this discussion is evidence that people find the situation a bit
>> > confusing. When I am looking into a project, I find it demotivating to
>> > read documentation about features that may or may not work — it's best
>> > when the documentation accurately reflects what the software can do.
>> 
>> Right, that was my point: let’s remove mentions of MIPS from the manual
>> and from ‘configure.ac’ so people have the right expectations.
>> 
>> Thoughts?
>
> So change it so that mips needs '--with-courage' but not remove the
> bootstrap binaries from the code?

Yes.  (The code has references to those binaries but it no longer has
the binaries themselves.)

> Do we want to fully remove the mention of mips as a supported platform
> or change it to "in the past we had an active mips64el port which is
> in need of more attention to bring it back to a fully supported
> platform. Help wanted!"

Do we really want to call for help in this area?  To me, we just remove
it, and if there’s interest again in this architecture, people might
happily find that part of the work has already been done.

Would you like to send a patch?

Ludo’.

Re: MIPS support

[Efraim Flashner]

[-- Attachment #1.1: Type: text/plain, Size: 614 bytes --]

Here's a first draft at removing mips64el-linux support from the
documentation. I've left it as a supported system in (gnu ci), in (guix
packages) and in the tests. I changed the text where we mention that we
support mips64el-linux as an architecture, and elsewhere in the manual
I've either removed mention of it when it was listed as a supported
target or changed the references to aarch64.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #1.2: 0001-doc-Remove-explicit-support-for-mips64el-linux.patch --]
[-- Type: text/plain, Size: 6167 bytes --]

From ebaef27fd08c29883a8e4bb091ccbd2bef9b2747 Mon Sep 17 00:00:00 2001
From: Efraim Flashner <efraim@flashner.co.il>
Date: Mon, 25 May 2020 12:29:55 +0300
Subject: [PATCH] doc: Remove explicit support for mips64el-linux.

It's been a good run, but no one is maintaining the architecture.
So long, and thanks for all the fish.

* doc/guix.texi (GNU Distribution): Change text for mips64el-linux
to denote it is deprecated.
(Daemon Offload Setup): Change occurrences of mips64el-linux to
aarch64-linux and adjust local code snippets.
(Guix Environment)[cross-compilation]: Change mips64el-linux-gnu to
aarch64-linux-gnu.
(GNU Build System)(package-cross-derivation]: Same.
(G-Expressions)[cross compilation]: Same.
(Additional Build Options)[cross-compilation, build logs]: Same.
(qemu-binfmt-service-type): Remove mips64el.
* doc/contributing.texi (Submitting Patches): Same.
* m4/guix.m4: (GUIX_ASSERT_SUPPORTED_SYSTEM): Remove mips64el-linux.
---
 doc/contributing.texi |  3 +--
 doc/guix.texi         | 25 +++++++++++++------------
 m4/guix.m4            |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 7b1f7e7c94..7496db5aaa 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -938,7 +938,7 @@ your @code{operating-system} configuration:
 @lisp
 (service qemu-binfmt-service-type
  (qemu-binfmt-configuration
-   (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))
+   (platforms (lookup-qemu-platforms "arm" "aarch64"))
    (guix-support? #t)))
 @end lisp
 
@@ -951,7 +951,6 @@ commands, respectively:
 @example
 guix build --system=armhf-linux --rounds=2 hello
 guix build --system=aarch64-linux --rounds=2 hello
-guix build --system=mips64el-linux --rounds=2 hello
 @end example
 
 @item
diff --git a/doc/guix.texi b/doc/guix.texi
index 3d1b097447..50472e0adb 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -464,11 +464,12 @@ and Linux-Libre kernel.
 @item aarch64-linux
 little-endian 64-bit ARMv8-A processors, Linux-Libre kernel.
 
-@item mips64el-linux
+@item mips64el-linux (deprecated)
 little-endian 64-bit MIPS processors, specifically the Loongson series,
 n32 ABI, and Linux-Libre kernel.  This configuration is no longer fully
-supported; in particular, the project's build farms no longer provide
-substitutes for this architecture.
+supported; in particular, there is no ongoing work to ensure that this
+architecture still works. Should someone decide they wish to revive this
+architecture then the code is still available.
 
 @end table
 
@@ -1059,8 +1060,8 @@ The @file{/etc/guix/machines.scm} file typically looks like this:
         (speed 2.))     ;incredibly fast!
 
       (build-machine
-        (name "meeps.example.org")
-        (system "mips64el-linux")
+        (name "armeight.example.org")
+        (system "aarch64-linux")
         (host-key "ssh-rsa AAAAB3Nza@dots{}")
         (user "alice")
         (private-key
@@ -1070,7 +1071,7 @@ The @file{/etc/guix/machines.scm} file typically looks like this:
 
 @noindent
 In the example above we specify a list of two build machines, one for
-the @code{x86_64} architecture and one for the @code{mips64el}
+the @code{x86_64} architecture and one for the @code{aarch64}
 architecture.
 
 In fact, this file is---not surprisingly!---a Scheme file that is
@@ -5329,7 +5330,7 @@ the system type of the build host.
 @item --target=@var{triplet}
 @cindex cross-compilation
 Cross-build for @var{triplet}, which must be a valid GNU triplet, such
-as @code{"mips64el-linux-gnu"} (@pxref{Specifying target triplets, GNU
+as @code{"aarch64-linux-gnu"} (@pxref{Specifying target triplets, GNU
 configuration triplets,, autoconf, Autoconf}).
 
 @item --compression=@var{tool}
@@ -5718,7 +5719,7 @@ Return the @code{<derivation>} object of @var{package} cross-built from
 @var{system} to @var{target}.
 
 @var{target} must be a valid GNU triplet denoting the target hardware
-and operating system, such as @code{"mips64el-linux-gnu"}
+and operating system, such as @code{"aarch64-linux-gnu"}
 (@pxref{Specifying Target Triplets,,, autoconf, Autoconf}).
 @end deffn
 
@@ -7719,7 +7720,7 @@ native package build:
                 "-s"
                 (string-append #$emacs "/bin/emacs")
                 (string-append #$output "/bin/vi")))
-   #:target "mips64el-linux-gnu")
+   #:target "aarch64-linux-gnu")
 @end lisp
 
 @noindent
@@ -8839,7 +8840,7 @@ also be offloaded to a remote machine of the right architecture.
 @item --target=@var{triplet}
 @cindex cross-compilation
 Cross-build for @var{triplet}, which must be a valid GNU triplet, such
-as @code{"mips64el-linux-gnu"} (@pxref{Specifying Target Triplets, GNU
+as @code{"aarch64-linux-gnu"} (@pxref{Specifying Target Triplets, GNU
 configuration triplets,, autoconf, Autoconf}).
 
 @anchor{build-check}
@@ -8909,7 +8910,7 @@ So for instance, imagine you want to see the build log of GDB on MIPS,
 but you are actually on an @code{x86_64} machine:
 
 @example
-$ guix build --log-file gdb -s mips64el-linux
+$ guix build --log-file gdb -s aarch64-linux
 https://@value{SUBSTITUTE-SERVER}/log/@dots{}-gdb-7.10
 @end example
 
@@ -24476,7 +24477,7 @@ emulated:
 @lisp
 (service qemu-binfmt-service-type
          (qemu-binfmt-configuration
-           (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el"))))
+           (platforms (lookup-qemu-platforms "arm" "aarch64"))))
 @end lisp
 
 In this example, we enable transparent emulation for the ARM and aarch64
diff --git a/m4/guix.m4 b/m4/guix.m4
index 961ce838ac..05057aca93 100644
--- a/m4/guix.m4
+++ b/m4/guix.m4
@@ -88,7 +88,7 @@ courageous and port the GNU System distribution to it (see
   # Currently only Linux-based systems are supported, and only on some
   # platforms.
   case "$guix_system" in
-    x86_64-linux|i686-linux|armhf-linux|aarch64-linux|mips64el-linux)
+    x86_64-linux|i686-linux|armhf-linux|aarch64-linux)
       ;;
     *)
       if test "x$guix_courageous" = "xyes"; then
-- 
2.26.2


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

Re: MIPS support

[Ludovic Courtès]

Hi,

Efraim Flashner <efraim@flashner.co.il> skribis:

> Here's a first draft at removing mips64el-linux support from the
> documentation. I've left it as a supported system in (gnu ci), in (guix
> packages) and in the tests. I changed the text where we mention that we
> support mips64el-linux as an architecture, and elsewhere in the manual
> I've either removed mention of it when it was listed as a supported
> target or changed the references to aarch64.

The patch LGTM!

(gnu ci) refers to the cross-compilation target, which is fine, we can
keep it.

However, I think you can remove “mips64el-linux” from
‘%supported-systems’ in (guix packages), especially given the comment
above it, and you can adjust ‘%hydra-supported-systems’ accordingly.

Thanks,
Ludo’.

Re: MIPS support

[Efraim Flashner]

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

On Mon, May 25, 2020 at 11:20:45PM +0200, Ludovic Courtès wrote:
> Hi,
> 
> Efraim Flashner <efraim@flashner.co.il> skribis:
> 
> > Here's a first draft at removing mips64el-linux support from the
> > documentation. I've left it as a supported system in (gnu ci), in (guix
> > packages) and in the tests. I changed the text where we mention that we
> > support mips64el-linux as an architecture, and elsewhere in the manual
> > I've either removed mention of it when it was listed as a supported
> > target or changed the references to aarch64.
> 
> The patch LGTM!
> 
> (gnu ci) refers to the cross-compilation target, which is fine, we can
> keep it.
> 
> However, I think you can remove “mips64el-linux” from
> ‘%supported-systems’ in (guix packages), especially given the comment
> above it, and you can adjust ‘%hydra-supported-systems’ accordingly.

The problem with removing it from %supported-systems is we have a number
of packages which already explicitly remove it from the list.

How about instead we rename %supported-systems to
%linux-systems, add mips64el to a new %deprecated-systems and turn
%supported-systems into a combination of %linux-systems,
%deprecated-systems and %hurd-systems.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

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

Re: MIPS support

[Leo Famulari]

On Wed, May 06, 2020 at 06:27:31PM +0200, Vincent Legoll wrote:
> I grabbed a gnubee during the crowdfunding campaign, but the CPU
> is too low spec to do a lot of compilation on it.

I'm not an expert on MIPS but I *think* the GnuBee uses a different
architecture than what Guix was ported to.

So, whether or not to officially retire the Guix MIPS port would not be
related to supporting Guix on the GnuBee, which would be cool!
Declarative NAS configuration would be nice :)

It would be helpful to get some clarification of the relationship
between these architectures before deciding what to do.

Re: MIPS support

[Vincent Legoll]

Hello everybody,

I'll do a single email answer, hope that is not off limits...

The gnubee is dual-core x 2 threads, 880 MHz 32 bit mips, 512 MB RAM, 2x1Gbps
ethernet, 6 SATA ports, SPI flash & microSD, USB 2 & 3, u-boot bootloader.

http://gnubee.org
https://www.mediatek.com/products/homeNetworking/mt7621n-a

To Jack Hill
> There seems to be a a fair amount of the router-class hardware available
> that works with Free Software, but not much, if any, of the latter, more
> powerful hardware. Unfortunately, I think having the more powerful
> hardware available would make it much easier to work on the port.

Yes, there's only a handful of desktop-class hw available, and it's
hard to find,
probably expensive too.

On the other hand there are a lot of router-class hw, and the gnubee which lies
in between .

Debian has a lot of mips hw available, see:
https://db.debian.org/machines.cgi
maybe we can ask for an account there if needed.

> I feel similarly. It's always sad to see things go (I used to have a
> collection of SPARC hardware, but let it go when I moved a few years ago),
> but no need to keep it just for me.

I never got my hands on sparc (to own one, we used to have sparcs at school, and
even alphas then, I'm getting old...)

> Vincent, it sounds like there are at least two of us. Maybe we can work
> together.

Yes, certainly, I really hope to be able to get something done on that front.

To Christopher Baines
> At least the main blocker for me is the lack of substitutes for the
> things that fail to build with QEMU. So maybe one or a few machines
> which were able to build those specific things would be sufficient to
> provide some substitutes.

I still not have tried mips (arm*, powerpc* and even there I still do not have
gone very far, but only tried cross-compilation which has it own set
of problems).

Can you elaborate a bit, compilation through qemu should be slow but
mostly work,
at least I hope. We should have a look at debian's arches MLs, there
are a lot of
efforts made to fix and upstream things, being done there.

> I did have a look at seeing if I could purchase hardware, but I didn't
> really know what to look at. Maybe we could try putting out an appeal
> for MIPS hardware, maybe someone has some they don't use and would
> donate?

I jumped on the gnubee, as even if it only is 32bit, it was nicer hw than the
available routers. I think the crowdsupply campaign founder still had some
available last I heard. There are 2 versions one for 2"1/2 drives and one for
3"1/2 that was in a following campaign (I didn't grab one of those). It is not
dirt-cheap, though.

To Leo Famulari

> It's not really a maintenance burden currently since we don't actually
> build or maintain the Guix on MIPS at all.

OK, that's (kind of) nice to hear, that it is not a great burden for guix
maintainer

> I think this discussion is evidence that people find the situation a bit
> confusing. When I am looking into a project, I find it demotivating to
> read documentation about features that may or may not work — it's best
> when the documentation accurately reflects what the software can do.

Yes, exactly, that's why I asked if there was any incentive to try to document
the state and actual efforts being done on the porting front.

https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00175.html

> So, whether or not to officially retire the Guix MIPS port would not be
> related to supporting Guix on the GnuBee, which would be cool!

Yes, maybe apart from a few entries in case/switch statements, this would not
cost us a lot of SLOCs, then people can build themselves and/or share the
results with guix publish, and make it into a collective effort...

OpenBSD is also doing a lot of work supporting some select old HW, their ports
building time is in weeks for some of them. So it should be doable.

> Declarative NAS configuration would be nice :)

Yes, the power of guix to the rescue of poor old hw !

> It would be helpful to get some clarification of the relationship
> between these architectures before deciding what to do.

If none of us has access to any mips64 (which is what I think guix support
was targeting), the point is kind of moot.

And there's also the problem of guix/scheme being hard on resources (This is
something I'm not really sure, but the attempts I did on arm32 were not really
promising on that front, which is why I postponed further investigations there.
Hoping to get accustomed with guix porting for ppc64 which don't have those
problems in the mean time)

That was a long one...

Thanks everyone for guix it's a refreshing thing !

--
Vincent Legoll

Re: MIPS support

[Vincent Legoll]

Hello,

I forgot to add that there's actual mips64 HW (Cavium Octeon-based
MIPS64 systems) available in the form of the ubiquity routers.
OpenBSD supports some of them already, and it looks like nice hw
(4 cores @ 1GHz, 1GB RAM). Look for ER-4 or ER-6P, but not the
ER-X line as the CPU is not the same and less interesting.

-- 
Vincent Legoll

Re: MIPS support

[Christopher Baines]

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


Vincent Legoll <vincent.legoll@gmail.com> writes:

> To Christopher Baines
>> At least the main blocker for me is the lack of substitutes for the
>> things that fail to build with QEMU. So maybe one or a few machines
>> which were able to build those specific things would be sufficient to
>> provide some substitutes.
>
> I still not have tried mips (arm*, powerpc* and even there I still do not have
> gone very far, but only tried cross-compilation which has it own set
> of problems).
>
> Can you elaborate a bit, compilation through qemu should be slow but
> mostly work,
> at least I hope. We should have a look at debian's arches MLs, there
> are a lot of
> efforts made to fix and upstream things, being done there.

I forget if I've replied, but I tried building hello using QEMU, and
this was the failure:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [Makefile:1099: c-family/c-common.o] Error 4
make[2]: *** Waiting for unfinished jobs....
config.status: creating Makefile
config.status: creating cc1plugin-config.h
config.status: executing depfiles commands
config.status: executing libtool commands
/gnu/store/48y1i9jxilgvg4n0r0mwsvzgac9yvr20-bootstrap-binaries-0/bin/bash ../../gcc-7.5.0/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
make[2]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build/gcc'
make[1]: *** [Makefile:4215: all-gcc] Error 2
make[1]: Leaving directory '/tmp/guix-build-gcc-cross-boot0-7.5.0.drv-0/build'
make: *** [Makefile:881: all] Error 2
command "make" "-j" "12" "LDFLAGS=-Wl,-rpath=/gnu/store/nlw1v60wfzvf8hccfiyxaa7qq76cpxfh-glibc-bootstrap-0/lib -Wl,-dynamic-linker -Wl,/gnu/store/nlw1v60wfzvf8hccfiyxaa7qq76cpxfh-glibc-bootstrap-0/lib/ld.so.1" failed with status 2
builder for `/gnu/store/bfsginlm0wbkwxzy5a39j6kin562ay34-gcc-cross-boot0-7.5.0.drv' failed with exit code 1
build of /gnu/store/bfsginlm0wbkwxzy5a39j6kin562ay34-gcc-cross-boot0-7.5.0.drv failed

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