* core-updates: Emacs is only supported on x86_64-linux? @ 2021-03-07 7:56 Chris Marusich 2021-03-07 10:46 ` Mark H Weaver 2021-03-07 13:41 ` Christopher Baines 0 siblings, 2 replies; 14+ messages in thread From: Chris Marusich @ 2021-03-07 7:56 UTC (permalink / raw) To: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-07 7:56 core-updates: Emacs is only supported on x86_64-linux? Chris Marusich @ 2021-03-07 10:46 ` Mark H Weaver 2021-03-07 23:40 ` Leo Famulari 2021-03-08 2:53 ` Chris Marusich 2021-03-07 13:41 ` Christopher Baines 1 sibling, 2 replies; 14+ messages in thread From: Mark H Weaver @ 2021-03-07 10:46 UTC (permalink / raw) To: Chris Marusich, guix-devel 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-07 10:46 ` Mark H Weaver @ 2021-03-07 23:40 ` Leo Famulari 2021-03-08 2:53 ` Chris Marusich 1 sibling, 0 replies; 14+ messages in thread From: Leo Famulari @ 2021-03-07 23:40 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-07 10:46 ` Mark H Weaver 2021-03-07 23:40 ` Leo Famulari @ 2021-03-08 2:53 ` Chris Marusich 2021-03-08 5:29 ` Mark H Weaver 2021-03-08 22:33 ` Christopher Baines 1 sibling, 2 replies; 14+ messages in thread From: Chris Marusich @ 2021-03-08 2:53 UTC (permalink / raw) To: Mark H Weaver, Leo Famulari, Christopher Baines; +Cc: guix-devel [-- 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 --] ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 2:53 ` Chris Marusich @ 2021-03-08 5:29 ` Mark H Weaver 2021-03-08 7:14 ` Ricardo Wurmus ` (2 more replies) 2021-03-08 22:33 ` Christopher Baines 1 sibling, 3 replies; 14+ messages in thread From: Mark H Weaver @ 2021-03-08 5:29 UTC (permalink / raw) To: Chris Marusich, Leo Famulari, Christopher Baines; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 5:29 ` Mark H Weaver @ 2021-03-08 7:14 ` Ricardo Wurmus 2021-03-10 0:09 ` Mark H Weaver 2021-03-08 7:19 ` Ricardo Wurmus 2021-03-09 6:04 ` Chris Marusich 2 siblings, 1 reply; 14+ messages in thread From: Ricardo Wurmus @ 2021-03-08 7:14 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 7:14 ` Ricardo Wurmus @ 2021-03-10 0:09 ` Mark H Weaver 0 siblings, 0 replies; 14+ messages in thread From: Mark H Weaver @ 2021-03-10 0:09 UTC (permalink / raw) To: Ricardo Wurmus; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 5:29 ` Mark H Weaver 2021-03-08 7:14 ` Ricardo Wurmus @ 2021-03-08 7:19 ` Ricardo Wurmus 2021-03-09 6:04 ` Chris Marusich 2 siblings, 0 replies; 14+ messages in thread From: Ricardo Wurmus @ 2021-03-08 7:19 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 5:29 ` Mark H Weaver 2021-03-08 7:14 ` Ricardo Wurmus 2021-03-08 7:19 ` Ricardo Wurmus @ 2021-03-09 6:04 ` Chris Marusich 2021-03-09 8:20 ` Chris Marusich 2 siblings, 1 reply; 14+ messages in thread From: Chris Marusich @ 2021-03-09 6:04 UTC (permalink / raw) To: Mark H Weaver, Ricardo Wurmus, Christopher Baines, Leo Famulari Cc: guix-devel [-- 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 --] ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-09 6:04 ` Chris Marusich @ 2021-03-09 8:20 ` Chris Marusich 2021-03-10 0:05 ` Mark H Weaver 0 siblings, 1 reply; 14+ messages in thread From: Chris Marusich @ 2021-03-09 8:20 UTC (permalink / raw) To: Mark H Weaver, Ricardo Wurmus, Christopher Baines, Leo Famulari Cc: guix-devel [-- 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 --] ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-09 8:20 ` Chris Marusich @ 2021-03-10 0:05 ` Mark H Weaver 0 siblings, 0 replies; 14+ messages in thread From: Mark H Weaver @ 2021-03-10 0:05 UTC (permalink / raw) To: Chris Marusich, Ricardo Wurmus, Christopher Baines, Leo Famulari Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 2:53 ` Chris Marusich 2021-03-08 5:29 ` Mark H Weaver @ 2021-03-08 22:33 ` Christopher Baines 2021-03-09 23:47 ` Mark H Weaver 1 sibling, 1 reply; 14+ messages in thread From: Christopher Baines @ 2021-03-08 22:33 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-08 22:33 ` Christopher Baines @ 2021-03-09 23:47 ` Mark H Weaver 0 siblings, 0 replies; 14+ messages in thread From: Mark H Weaver @ 2021-03-09 23:47 UTC (permalink / raw) To: Christopher Baines, Chris Marusich; +Cc: guix-devel 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: core-updates: Emacs is only supported on x86_64-linux? 2021-03-07 7:56 core-updates: Emacs is only supported on x86_64-linux? Chris Marusich 2021-03-07 10:46 ` Mark H Weaver @ 2021-03-07 13:41 ` Christopher Baines 1 sibling, 0 replies; 14+ messages in thread From: Christopher Baines @ 2021-03-07 13:41 UTC (permalink / raw) To: Chris Marusich; +Cc: guix-devel [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-03-10 0:11 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-07 7:56 core-updates: Emacs is only supported on x86_64-linux? Chris Marusich 2021-03-07 10:46 ` Mark H Weaver 2021-03-07 23:40 ` Leo Famulari 2021-03-08 2:53 ` Chris Marusich 2021-03-08 5:29 ` Mark H Weaver 2021-03-08 7:14 ` Ricardo Wurmus 2021-03-10 0:09 ` Mark H Weaver 2021-03-08 7:19 ` Ricardo Wurmus 2021-03-09 6:04 ` Chris Marusich 2021-03-09 8:20 ` Chris Marusich 2021-03-10 0:05 ` Mark H Weaver 2021-03-08 22:33 ` Christopher Baines 2021-03-09 23:47 ` Mark H Weaver 2021-03-07 13:41 ` Christopher Baines
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/guix.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.