core-updates: Emacs is only supported on x86_64-linux?

core-updates: Emacs is only supported on x86_64-linux?

[Chris Marusich]

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

Hi,

I've noticed that the emacs package only supports x86_64-linux, at least
on core-updates.  Is that intended?

I noticed because it caused "make check" to fail on the wip-ppc64le
branch (which is based on core-updates).  I fixed one failing test on
the wip-ppc64le branch by using coreutils instead of emacs in the test:

https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-ppc64le&id=1900a6227e99427cf3b28a86dbbee2c55f375f8c

I suspect that - on core-updates, at least - Guix does not currently
pass its "make check" test suite on any system other than x86_64-linux.

I would like to cherry-pick the above fix onto core-updates.  However,
before doing that, I wanted to check on this list to see if anyone knew
anything about the current situation.  Is it intended that the emacs
package only supports x86_64-linux?

As for the cause, it looks like one contributing factor might be the
rust package.  It was recently added to the transitive closure of inputs
of emacs.  The rust package explicitly declares x86_64-linux as its only
supported system.  This restriction percolates up to emacs, and indeed
to any other package that contains rust in its transitive closure of
inputs.  However, as of 1ced8379c7641788fa607b19b7a66d18f045362b, emacs
did not contain rust in its transitive closure of inputs, so the change
must have happened in some commit after that.

It would be nice if someday the rust package could support more systems.
However, my primary goal here is just to get Guix to build and pass its
tests on powerpc64le-linux.  Getting things like rust and emacs to work
after that will be another challenge.

-- 
Chris

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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:
> I've noticed that the emacs package only supports x86_64-linux, at least
> on core-updates.  Is that intended?

It's not intended.  Emacs should certainly be supported on every system
that Guix supports.

> As for the cause, it looks like one contributing factor might be the
> rust package.  It was recently added to the transitive closure of inputs
> of emacs.  The rust package explicitly declares x86_64-linux as its only
> supported system.  This restriction percolates up to emacs, and indeed
> to any other package that contains rust in its transitive closure of
> inputs.

Yes, exactly.

For now, I suggest that Emacs should have input 'librsvg' only on
'x86_64-linux' systems.  Something like this (untested), for
core-updates:

--8<---------------cut here---------------start------------->8---
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae..de6101cf17 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg)
   #:use-module (guix utils)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1))
 
 (define-public emacs
@@ -236,7 +237,10 @@
        ("libpng" ,libpng)
        ("zlib" ,zlib)
 
-       ("librsvg" ,librsvg)
+       ,@(match (or (%current-target-system)
+                    (%current-system))
+           ("x86_64-linux" `(("librsvg" ,librsvg)))
+           (_ `()))
        ("libxpm" ,libxpm)
        ("libxml2" ,libxml2)
        ("libice" ,libice)
--8<---------------cut here---------------end--------------->8---

Ditto for all other packages with 'librsvg' as an optional dependency.

> I noticed because it caused "make check" to fail on the wip-ppc64le
> branch (which is based on core-updates).  I fixed one failing test on
> the wip-ppc64le branch by using coreutils instead of emacs in the test:
>
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-ppc64le&id=1900a6227e99427cf3b28a86dbbee2c55f375f8c
>
> I suspect that - on core-updates, at least - Guix does not currently
> pass its "make check" test suite on any system other than x86_64-linux.
>
> I would like to cherry-pick the above fix onto core-updates.  However,
> before doing that, I wanted to check on this list to see if anyone knew
> anything about the current situation.  Is it intended that the emacs
> package only supports x86_64-linux?

While I'm not strongly opposed to the workaround above, it seems to me
the wrong fix.  I think we should simply fix our Emacs package, as
outlined above.  It should be easy.

What do you think?  Would you like to try?

      Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Christopher Baines]

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


Chris Marusich <cmmarusich@gmail.com> writes:

> I've noticed that the emacs package only supports x86_64-linux, at least
> on core-updates.  Is that intended?

The relevant commit [1] does mention the intent "Remove "i686-linux"
from supported systems.", but that does differ from my interpretation of
the change, which is only support x86_64-linux.

1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0ed631866cc0b7cece2b0a0b50e39b37ae91bb67

I've sent a patch that should add back "support" for other systems:

  https://issues.guix.gnu.org/46987

That's for master at least, I haven't looked in to what the situation is
on core-updates. It's worth there checking if the build still fails.

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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Leo Famulari]

On Sun, Mar 07, 2021 at 05:46:24AM -0500, Mark H Weaver wrote:
> For now, I suggest that Emacs should have input 'librsvg' only on
> 'x86_64-linux' systems.  Something like this (untested), for
> core-updates:

I think this is the right approach. We do something similar for FFmpeg
with its dependency rav1e.

Re: core-updates: Emacs is only supported on x86_64-linux?

[Chris Marusich]

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

Hi all,

FYI, I'm sending this message to 46987@debbugs.gnu.org via Bcc, also.
I'm not sure if that works, but we'll see...

Mark H Weaver <mhw@netris.org> writes:

> It's not intended.  Emacs should certainly be supported on every system
> that Guix supports.

Thank you for confirming.  That is what I expected.

> For now, I suggest that Emacs should have input 'librsvg' only on
> 'x86_64-linux' systems.  Something like this (untested), for
> core-updates:
>
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index 98061c93ae..de6101cf17 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -71,6 +71,7 @@
>    #:use-module (gnu packages xml)
>    #:use-module (gnu packages xorg)
>    #:use-module (guix utils)
> +  #:use-module (ice-9 match)
>    #:use-module (srfi srfi-1))
>  
>  (define-public emacs
> @@ -236,7 +237,10 @@
>         ("libpng" ,libpng)
>         ("zlib" ,zlib)
>  
> -       ("librsvg" ,librsvg)
> +       ,@(match (or (%current-target-system)
> +                    (%current-system))
> +           ("x86_64-linux" `(("librsvg" ,librsvg)))
> +           (_ `()))
>         ("libxpm" ,libxpm)
>         ("libxml2" ,libxml2)
>         ("libice" ,libice)
>
> Ditto for all other packages with 'librsvg' as an optional dependency.

I've confirmed that works for emacs, except that you actually have to
also do it for gtk+, too, since rust gets pulled in via gtk+ also.  So,
something like this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-emacs-Use-librsvg-and-gtk-on-x86_64-linux-only.patch --]
[-- Type: text/x-patch, Size: 2004 bytes --]

From 649c89e5862e1ed887f5fd863ef7bb32f97bbe74 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Sun, 7 Mar 2021 17:42:37 -0800
Subject: [PATCH] gnu: emacs: Use librsvg and gtk+ on x86_64-linux only.

* gnu/packages/emacs.scm (emacs)[inputs]: Only add librsvg when the
%current-target-system or %current-system is "x86_64-linux".  This avoids
pulling rust into the transitive closure of inputs on systems where Rust
support is currently lacking.
---
 gnu/packages/emacs.scm | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae0..f0797ae2347 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg)
   #:use-module (guix utils)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1))
 
 (define-public emacs
@@ -219,7 +220,6 @@
 
        ;; TODO: Add the optional dependencies.
        ("libx11" ,libx11)
-       ("gtk+" ,gtk+)
        ("cairo" ,cairo)
        ("pango" ,pango)
        ("harfbuzz" ,harfbuzz)
@@ -236,7 +236,6 @@
        ("libpng" ,libpng)
        ("zlib" ,zlib)
 
-       ("librsvg" ,librsvg)
        ("libxpm" ,libxpm)
        ("libxml2" ,libxml2)
        ("libice" ,libice)
@@ -246,7 +245,15 @@
 
        ;; multilingualization support
        ("libotf" ,libotf)
-       ("m17n-lib" ,m17n-lib)))
+       ("m17n-lib" ,m17n-lib)
+
+       ;; These are optional dependencies that pull in rust.  Rust is not
+       ;; supported well on every architecture yet.
+       ,@(match (or (%current-target-system)
+                    (%current-system))
+           ("x86_64-linux" `(("gtk+" ,gtk+)
+                             ("librsvg" ,librsvg)))
+           (_ '()))))
     (native-inputs
      `(("guix-emacs.el" ,(search-auxiliary-file "emacs/guix-emacs.el"))
        ("pkg-config" ,pkg-config)
-- 
2.26.2


[-- Attachment #1.3: Type: text/plain, Size: 1417 bytes --]


What do you think about that?  If there are no problems, I'll go ahead
and commit it to core-updates.

Note that because that patch re-orders the inputs, it causes emacs to be
rebuilt, which should be fine because it's core-updates.  It seemed
better to group these two inputs in a single match clause, rather than
scattering them in two different but basically identical match clauses
just to keep their original ordering intact.

Christopher Baines <mail@cbaines.net> writes:

> Chris Marusich <cmmarusich@gmail.com> writes:
>
>> I've noticed that the emacs package only supports x86_64-linux, at least
>> on core-updates.  Is that intended?
>
> The relevant commit [1] does mention the intent "Remove "i686-linux"
> from supported systems.", but that does differ from my interpretation of
> the change, which is only support x86_64-linux.
>
> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0ed631866cc0b7cece2b0a0b50e39b37ae91bb67
>
> I've sent a patch that should add back "support" for other systems:
>
>   https://issues.guix.gnu.org/46987
>
> That's for master at least, I haven't looked in to what the situation is
> on core-updates. It's worth there checking if the build still fails.

That patch doesn't apply on core-updates because that rust version
doesn't seem to exist any more on core-updates.  However, the same
change applied to the right rust on core-updates does the trick, like
this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.4: 0001-gnu-rust-Make-it-supported-on-all-systems-but-i686-l.patch --]
[-- Type: text/x-patch, Size: 1236 bytes --]

From e36c4cab40c5b97ffedc72acc586c0b560e7868e Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Sun, 7 Mar 2021 15:58:19 -0800
Subject: [PATCH] gnu: rust: Make it "supported" on all systems but i686-linux.

* gnu/packages/rust.scm (rust-1.30)[supported-systems]: Instead of hard-coding
this to just "x86_64-linux", calculate the supported systems by deleting
"i686-linux" from %supported-systems.
---
 gnu/packages/rust.scm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 70d19e089ab..98c553cb913 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -448,7 +448,9 @@ jemalloc = \"" jemalloc "/lib/libjemalloc_pic.a" "\"
            (search-path-specification
             (variable "LIBRARY_PATH")
             (files '("lib" "lib64")))))
-    (supported-systems '("x86_64-linux"))
+    (supported-systems
+     (delete "i686-linux"  ; fails to build, see bug #35519
+             %supported-systems))
     (synopsis "Compiler for the Rust progamming language")
     (description "Rust is a systems programming language that provides memory
 safety and thread safety guarantees.")
-- 
2.26.2


[-- Attachment #1.5: Type: text/plain, Size: 1986 bytes --]


Both of these patches fix the issue for me.  After applying either one
in isolation (on the wip-ppc64le branch, which was recently rebased onto
core-updates), the list of supported systems for the emacs package
correctly includes other systems, including powerpc64le-linux, and thus
the tests/guix-package.sh test passes on my powerpc64le-linux system.

I think both of these patches are important and needed.  The patch to
restore supported systems to the rust package is important because we
will want rust to build successfully on many systems.  The patch to only
add gtk+ and librsvg inputs to emacs when the system is x86_64-linux is
important because it would be advantageous to be able to use emacs
without depending on rust on systems like powerpc64le-linux, where Rust
support may not be great yet.

It's also convenient for me, personally, because I don't really want to
deal with Rust right now just to get Emacs working on powerpc64le-linux.
Once I can build a Guix release binary for powerpc64le-linux, then I
think I can start worrying more about Rust.  I have taken the liberty of
applying these patches to the wip-ppc64le branch as-is, since they work
for me.  I can remove them later if we don't like it.

We will undoubtedly run into a similar situation with other packages
going forward, like Mark mentioned.  Debian ran into this very issue
some time ago, and apparently it caused a bit of consternation:

https://lwn.net/Articles/771355/

Apparently, powerpc64le-unknown-linux-gnu is a "Tier 2" Rust platform,
which I guess means it's pretty well supported, but not as well as "Tier
1".  I hope that we can get it all working, since librsvg is depended
upon in some way or another by about 2700 packages (about 17% of the
total Guix package collection).  In the meantime, limiting the blast
radius as needed, like Mark suggested, seems like the right thing to do
until Rust support improves on other architectures.

-- 
Chris

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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:
> I've confirmed that works for emacs, except that you actually have to
> also do it for gtk+, too, since rust gets pulled in via gtk+ also.

Ugh.  I'd prefer to avoid removing 'gtk+' from the inputs to 'emacs' on
any system, because the distinguishing characteristic of that package
(compared with the other Emacs variants) is that it's the Gtk+ variant
of Emacs.

For now, it would be good to eliminate the Gtk+ dependency on Rust.
If we reach the point where our Gtk+ package is only supported on
'x86_64-linux', our claim of supporting multiple architectures will
become increasingly dubious.

Does anyone know how Gtk+ depends on Rust?

Aside: I wish that Guix included a convenient tool to answer the
question "Why does package X depend on package Y?", i.e. "What paths of
dependencies lead from package X to package Y?", without having to view
the entire dependency graph (which is often too complex to grasp
visually).

For now: how about changing the failing system test to inherit from
'emacs-no-x-toolkit' instead of 'emacs'.  That, combined with making
'librsvg' a conditional input to Emacs (but leaving 'gtk+' in Emacs'
inputs on all systems), should be enough to get past your immediate
problem.

What do you think?

> From e36c4cab40c5b97ffedc72acc586c0b560e7868e Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Sun, 7 Mar 2021 15:58:19 -0800
> Subject: [PATCH] gnu: rust: Make it "supported" on all systems but i686-linux.
>
> * gnu/packages/rust.scm (rust-1.30)[supported-systems]: Instead of hard-coding
> this to just "x86_64-linux", calculate the supported systems by deleting
> "i686-linux" from %supported-systems.

I don't think we should do this until we have reason to believe that our
Rust packages actually build successfully on the other systems.

> I think both of these patches are important and needed.  The patch to
> restore supported systems to the rust package is important because we
> will want rust to build successfully on many systems.

I agree that we must soon prioritize getting Rust working on other
systems, but I doubt that this simple patch will accomplish much more
than to waste precious cycles on our few non-Intel build slaves.

       Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> writes:

> Aside: I wish that Guix included a convenient tool to answer the
> question "Why does package X depend on package Y?", i.e. "What paths of
> dependencies lead from package X to package Y?", without having to view
> the entire dependency graph (which is often too complex to grasp
> visually).

We have “guix graph --path from to”, but frustratingly it won’t cover
build system packages, so

    guix graph --path emacs rust

will tell us that there is no path from emacs to rust, even though there
is a path via librsvg, which uses rust through the cargo-build-system.

-- 
Ricardo

Re: core-updates: Emacs is only supported on x86_64-linux?

[Ricardo Wurmus]

Mark H Weaver <mhw@netris.org> writes:

> Does anyone know how Gtk+ depends on Rust?

gtk+ -> gdk-pixbuf+svg -> librsvg -> rust

(“guix graph” is of no help here, because it doesn’t show build system
packages, so I looked through the derivations.)

-- 
Ricardo

Re: core-updates: Emacs is only supported on x86_64-linux?

[Christopher Baines]

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


Chris Marusich <cmmarusich@gmail.com> writes:

> Christopher Baines <mail@cbaines.net> writes:
>
>> Chris Marusich <cmmarusich@gmail.com> writes:
>>
>>> I've noticed that the emacs package only supports x86_64-linux, at least
>>> on core-updates.  Is that intended?
>>
>> The relevant commit [1] does mention the intent "Remove "i686-linux"
>> from supported systems.", but that does differ from my interpretation of
>> the change, which is only support x86_64-linux.
>>
>> 1: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=0ed631866cc0b7cece2b0a0b50e39b37ae91bb67
>>
>> I've sent a patch that should add back "support" for other systems:
>>
>>   https://issues.guix.gnu.org/46987
>>
>> That's for master at least, I haven't looked in to what the situation is
>> on core-updates. It's worth there checking if the build still fails.
>
> That patch doesn't apply on core-updates because that rust version
> doesn't seem to exist any more on core-updates.  However, the same
> change applied to the right rust on core-updates does the trick, like
> this:
>
> From e36c4cab40c5b97ffedc72acc586c0b560e7868e Mon Sep 17 00:00:00 2001
> From: Chris Marusich <cmmarusich@gmail.com>
> Date: Sun, 7 Mar 2021 15:58:19 -0800
> Subject: [PATCH] gnu: rust: Make it "supported" on all systems but i686-linux.
>
> * gnu/packages/rust.scm (rust-1.30)[supported-systems]: Instead of hard-coding
> this to just "x86_64-linux", calculate the supported systems by deleting
> "i686-linux" from %supported-systems.
> ---
>  gnu/packages/rust.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
> index 70d19e089ab..98c553cb913 100644
> --- a/gnu/packages/rust.scm
> +++ b/gnu/packages/rust.scm
> @@ -448,7 +448,9 @@ jemalloc = \"" jemalloc "/lib/libjemalloc_pic.a" "\"
>             (search-path-specification
>              (variable "LIBRARY_PATH")
>              (files '("lib" "lib64")))))
> -    (supported-systems '("x86_64-linux"))
> +    (supported-systems
> +     (delete "i686-linux"  ; fails to build, see bug #35519
> +             %supported-systems))
>      (synopsis "Compiler for the Rust progamming language")
>      (description "Rust is a systems programming language that provides memory
>  safety and thread safety guarantees.")
> -- 
> 2.26.2
>
>
> Both of these patches fix the issue for me.  After applying either one
> in isolation (on the wip-ppc64le branch, which was recently rebased onto
> core-updates), the list of supported systems for the emacs package
> correctly includes other systems, including powerpc64le-linux, and thus
> the tests/guix-package.sh test passes on my powerpc64le-linux system.
>
> I think both of these patches are important and needed.  The patch to
> restore supported systems to the rust package is important because we
> will want rust to build successfully on many systems.  The patch to only
> add gtk+ and librsvg inputs to emacs when the system is x86_64-linux is
> important because it would be advantageous to be able to use emacs
> without depending on rust on systems like powerpc64le-linux, where Rust
> support may not be great yet.
>
> It's also convenient for me, personally, because I don't really want to
> deal with Rust right now just to get Emacs working on powerpc64le-linux.
> Once I can build a Guix release binary for powerpc64le-linux, then I
> think I can start worrying more about Rust.  I have taken the liberty of
> applying these patches to the wip-ppc64le branch as-is, since they work
> for me.  I can remove them later if we don't like it.
>
> We will undoubtedly run into a similar situation with other packages
> going forward, like Mark mentioned.  Debian ran into this very issue
> some time ago, and apparently it caused a bit of consternation:
>
> https://lwn.net/Articles/771355/
>
> Apparently, powerpc64le-unknown-linux-gnu is a "Tier 2" Rust platform,
> which I guess means it's pretty well supported, but not as well as "Tier
> 1".  I hope that we can get it all working, since librsvg is depended
> upon in some way or another by about 2700 packages (about 17% of the
> total Guix package collection).  In the meantime, limiting the blast
> radius as needed, like Mark suggested, seems like the right thing to do
> until Rust support improves on other architectures.

I've gone ahead and pushed the patch I proposed to master, I think it's
a step forward.

As you say, adapting the change for core-updates might be good as
well. I want to check though if rust builds for i686-linux on
core-updates, as the path is different to master, so it may well work.

So yeah, once I've found out whether rust works on i686-linux on
core-updates, I might make a change there too.

Chris

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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Chris Marusich]

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

Hi,

Mark H Weaver <mhw@netris.org> writes:

> Ugh.  I'd prefer to avoid removing 'gtk+' from the inputs to 'emacs' on
> any system, because the distinguishing characteristic of that package
> (compared with the other Emacs variants) is that it's the Gtk+ variant
> of Emacs.

How about a patch like the following - would it be acceptable to you?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: patch --]
[-- Type: text/x-patch, Size: 2267 bytes --]

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae..4d2caf205a 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg)
   #:use-module (guix utils)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1))
 
 (define-public emacs
@@ -236,7 +237,12 @@
        ("libpng" ,libpng)
        ("zlib" ,zlib)
 
-       ("librsvg" ,librsvg)
+       ;; librsvg is an optional dependency that pulls in rust.  Rust is not
+       ;; supported well on every architecture yet.
+       ,@(match (or (%current-target-system)
+                    (%current-system))
+                ("x86_64-linux" `(("librsvg" ,librsvg)))
+                           (_ '()))
        ("libxpm" ,libxpm)
        ("libxml2" ,libxml2)
        ("libice" ,libice)
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index f458366fb6..0468cbf830 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -776,7 +776,12 @@ is part of the GNOME accessibility project.")
    (outputs '("out" "bin" "doc"))
    (propagated-inputs
     `(("atk" ,atk)
-      ("gdk-pixbuf" ,gdk-pixbuf+svg)
+      ;; SVG support is optional and requires librsvg, which pulls in rust.
+      ;; Rust is not supported well on every architecture yet.
+      ("gdk-pixbuf" ,(match (or (%current-target-system)
+                                (%current-system))
+                            ("x86_64-linux" gdk-pixbuf+svg)
+                            (_ gdk-pixbuf)))
       ("pango" ,pango)))
    (inputs
     `(("cups" ,cups)
@@ -843,7 +848,12 @@ application suites.")
    (propagated-inputs
     `(("at-spi2-atk" ,at-spi2-atk)
       ("atk" ,atk)
-      ("gdk-pixbuf" ,gdk-pixbuf+svg)
+      ;; SVG support is optional and requires librsvg, which pulls in rust.
+      ;; Rust is not supported well on every architecture yet.
+      ("gdk-pixbuf" ,(match (or (%current-target-system)
+                                (%current-system))
+                            ("x86_64-linux" gdk-pixbuf+svg)
+                            (_ gdk-pixbuf)))
       ("libepoxy" ,libepoxy)
       ("libxcursor" ,libxcursor)
       ("libxi" ,libxi)

[-- Attachment #1.3: Type: text/plain, Size: 2425 bytes --]


I've tested this patch (on its own, applied to wip-ppc64le locally,
without the other two patches mentioned earlier in this thread), and it
successfully restores the "supported systems" for emacs (thus fixing the
tests/package.sh test failure), without changing rust's list of
supported systems, which remains hard-coded to x86_64-linux.

Eventually I think I will definitely need a change like the one Chris
proposed in order to actually troubleshoot build failures involving rust
on powerpc64le-linux, but I suppose when the time comes, I can do it in
a private branch and save the build farm some wasted cycles.  It's fine
with me if we don't make a change like that right now, since it isn't
blocking my porting work.

Mark H Weaver <mhw@netris.org> writes:

> Aside: I wish that Guix included a convenient tool to answer the
> question "Why does package X depend on package Y?", i.e. "What paths of
> dependencies lead from package X to package Y?", without having to view
> the entire dependency graph (which is often too complex to grasp
> visually).

Ricardo Wurmus <rekado@elephly.net> writes:

> (“guix graph” is of no help here, because it doesn’t show build system
> packages, so I looked through the derivations.)

The "--paths" option with "--type=bag" shows you this (results
below were, of course, taken before applying the patch above):

--8<---------------cut here---------------start------------->8---
marusich@suzaku:~/repos/guix$ ./pre-inst-env guix graph --type=bag --path gtk+ rust
gtk+@3.24.24
gdk-pixbuf+svg@2.42.2
librsvg@2.50.3
rust@1.49.0
--8<---------------cut here---------------end--------------->8---

Christopher Baines <mail@cbaines.net> writes:

> I've gone ahead and pushed the patch I proposed to master, I think it's
> a step forward.
>
> As you say, adapting the change for core-updates might be good as
> well. I want to check though if rust builds for i686-linux on
> core-updates, as the path is different to master, so it may well work.
>
> So yeah, once I've found out whether rust works on i686-linux on
> core-updates, I might make a change there too.

I don't have a strong personal opinion about this, since I'm building
everything from source anyway, and I want a patch like this eventually
on core-updates, too.  However, in light of Mark's comments, is it a
good idea to apply that patch right now?

-- 
Chris

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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Chris Marusich]

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

Chris Marusich <cmmarusich@gmail.com> writes:

> How about a patch like the following - would it be acceptable to you?

Actually, I've realized that that patch wasn't quite right.  I've
attached a corrected version to this email.

Although the %current-system parameter will look like "x86_64-linux"
because it's a Guix system name, the %current-target-system parameter
will look like "x86_64-linux-gnu" (or whatever the user happens to
supply, e.g. via the --target option of "guix build") because it's a GNU
triplet.  The attached patch accomplishes the same goal as before, but
it uses string-prefix? to check whether we're building for an x86_64
machine, rather than matching on an exact string.

-- 
Chris

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-Restore-emacs-supported-systems.patch --]
[-- Type: text/x-patch, Size: 3838 bytes --]

From 0eb5583f243a399293ae52a3e78ccf7d3a153a47 Mon Sep 17 00:00:00 2001
From: Chris Marusich <cmmarusich@gmail.com>
Date: Mon, 8 Mar 2021 23:13:39 -0800
Subject: [PATCH] gnu: Restore emacs' supported systems.

Recently, librsvg was updated to depend upon rust.  That change inadvertently
restricted the "supported" systems of emacs (among other package) to
x86_64-linux only, since that is the only system declared in the rust
package's list of supported systems.  This unintentionally made emacs
unavailable on all other systems.

This change fixes that by removing the rust dependency from some packages.
The packages remain unchanged from the perspective of an x86_64-linux system,
but from the perspective of other systems, the packages are now supported
again (albeit without certain optional SVG features).

* gnu/packages/gtk.scm (gtk+, gtk+-2)[propagated-inputs]: If compiling for
x86_64, use gdk-pixbuf+svg as the "gdk-pixbuf" input, as usual.  Otherwise,
use gdk-pixbuf, which avoids adding librsvg (thus rust) to the closure of
inputs.  Note that both gtk+ and gtk+-2 are in the transitive closure of
inputs of emacs, so these two changes are necessary.
* gnu/packages/emacs (emacs)[inputs]: If compiling for x86_64, add librsvg to
the inputs, as usual.  Otherwise, do not add it, which avoids adding rust to
the closure of inputs.
---
 gnu/packages/emacs.scm |  8 +++++++-
 gnu/packages/gtk.scm   | 14 ++++++++++++--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 98061c93ae0..fe5b3b25b3d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -71,6 +71,7 @@
   #:use-module (gnu packages xml)
   #:use-module (gnu packages xorg)
   #:use-module (guix utils)
+  #:use-module (ice-9 match)
   #:use-module (srfi srfi-1))
 
 (define-public emacs
@@ -236,7 +237,12 @@
        ("libpng" ,libpng)
        ("zlib" ,zlib)
 
-       ("librsvg" ,librsvg)
+       ;; librsvg is an optional dependency that pulls in rust.  Rust is not
+       ;; supported well on every architecture yet.
+       ,@(if (string-prefix? "x86_64" (or (%current-target-system)
+                                          (%current-system)))
+             `(("librsvg" ,librsvg))
+             '())
        ("libxpm" ,libxpm)
        ("libxml2" ,libxml2)
        ("libice" ,libice)
diff --git a/gnu/packages/gtk.scm b/gnu/packages/gtk.scm
index f458366fb6a..d396425d9a6 100644
--- a/gnu/packages/gtk.scm
+++ b/gnu/packages/gtk.scm
@@ -776,7 +776,12 @@ is part of the GNOME accessibility project.")
    (outputs '("out" "bin" "doc"))
    (propagated-inputs
     `(("atk" ,atk)
-      ("gdk-pixbuf" ,gdk-pixbuf+svg)
+      ;; SVG support is optional and requires librsvg, which pulls in rust.
+      ;; Rust is not supported well on every architecture yet.
+      ("gdk-pixbuf" ,(if (string-prefix? "x86_64" (or (%current-target-system)
+                                                      (%current-system)))
+                         gdk-pixbuf+svg
+                         gdk-pixbuf))
       ("pango" ,pango)))
    (inputs
     `(("cups" ,cups)
@@ -843,7 +848,12 @@ application suites.")
    (propagated-inputs
     `(("at-spi2-atk" ,at-spi2-atk)
       ("atk" ,atk)
-      ("gdk-pixbuf" ,gdk-pixbuf+svg)
+      ;; SVG support is optional and requires librsvg, which pulls in rust.
+      ;; Rust is not supported well on every architecture yet.
+      ("gdk-pixbuf" ,(if (string-prefix? "x86_64" (or (%current-target-system)
+                                                      (%current-system)))
+                         gdk-pixbuf+svg
+                         gdk-pixbuf))
       ("libepoxy" ,libepoxy)
       ("libxcursor" ,libxcursor)
       ("libxi" ,libxi)
-- 
2.26.2


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

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Christopher Baines <mail@cbaines.net> writes:
> I've gone ahead and pushed the patch I proposed to master, I think it's
> a step forward.

On second thought, maybe you have the right idea.  It's becoming
increasingly clear that we cannot continue to postpone fixing our Rust
packages on non-Intel platforms.  We will need to make this a priority,
and your patch is a step toward that goal.  Also, the Rust build on
'aarch64-linux' got further than I expected, as shown in
<https://bugs.gnu.org/47019>.

     Thanks,
       Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Chris,

Chris Marusich <cmmarusich@gmail.com> writes:

> Actually, I've realized that that patch wasn't quite right.  I've
> attached a corrected version to this email.
>
> Although the %current-system parameter will look like "x86_64-linux"
> because it's a Guix system name, the %current-target-system parameter
> will look like "x86_64-linux-gnu" (or whatever the user happens to
> supply, e.g. via the --target option of "guix build") because it's a GNU
> triplet.

Indeed, good catch.

> The attached patch accomplishes the same goal as before, but
> it uses string-prefix? to check whether we're building for an x86_64
> machine, rather than matching on an exact string.

Your proposed patch looks good to me, as a temporary measure to make
Guix a bit more usable on non-Intel systems until we get Rust working on
them.  I would be in favor of pushing it to 'core-updates'.

     Thanks!
       Mark

Re: core-updates: Emacs is only supported on x86_64-linux?

[Mark H Weaver]

Hi Ricardo, Chris,

Ricardo Wurmus <rekado@elephly.net> writes:
> We have “guix graph --path from to”, but frustratingly it won’t cover
> build system packages, [...]

Chris Marusich <cmmarusich@gmail.com> writes:
> The "--paths" option with "--type=bag" shows you this (results
> below were, of course, taken before applying the patch above):
>
> --8<---------------cut here---------------start------------->8---
> marusich@suzaku:~/repos/guix$ ./pre-inst-env guix graph --type=bag --path gtk+ rust
> gtk+@3.24.24
> gdk-pixbuf+svg@2.42.2
> librsvg@2.50.3
> rust@1.49.0
> --8<---------------cut here---------------end--------------->8---

Thanks to you both for pointing this out!

     Regards,
       Mark