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

[Chris Marusich <cmmarusich@gmail.com>]

[-- 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 --]