bug#29519: ./pre-inst-env: substitute: Failed to autoload make-session in (gnutls)

[Ludovic Courtès]

Hello,

Adonay Felipe Nogueira  skribis:

> starting substituter program 
> `/home/adfeno/Projetos/Software/guix/nix/scripts/substitute'
> substitute: guile: warning: failed to install locale
> substitute: warning: failed to install locale: Invalid argument
> substitute: guix substitute: warning: ACL for archive imports seems to be 
> uninitialized, substitutes may be unavailable
> substitute: ;;; Failed to autoload make-session in (gnutls):
> substitute: ;;; ERROR: missing interface for module (gnutls)
> substitute: Backtrace:
> substitute:1 (primitive-load 
> "/home/adfeno/Projetos/Software/guix/sc?")
> substitute: In guix/ui.scm:
> substitute:   1452:12  0 (run-guix-command _ . _)
> substitute:
> substitute: guix/ui.scm:1452:12: In procedure run-guix-command:
> substitute: guix/ui.scm:1452:12: make-session: unbound variable
> guix build: error: build failed: substituter `substitute' died unexpectedly

The problem is that the (gnutls) module is not in the search path of
‘guix substitute’.

Usually the solution is to start the daemon using something like:

  sudo -E ./pre-inst-env guix-daemon …

so that ‘guix-daemon’ inherits the correct values for ‘GUILE_LOAD_PATH’,
etc.

Does that work for you?

We used to have this suggestion in the doc, but it was reverted in
commit 73a203450d21241eca50375aeb26fb418b287414.  Leo, do you think we
can reinstate it?  I’m not sure why it was reverted in the first place.

Thanks,
Ludo’.

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Ludovic Courtès]

Hi,

Jelle Licht  skribis:

> 2017-11-30 23:41 GMT+01:00 Adam Van Ymeren :
>
>> I haven't had time to dig in to this further, but in case anyone wants
>> to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.
>>
>> Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
>> jemalloc back to 4.5.0 causes rustc to build successfully again.  It has
>> been broken for some time.
>>
>> https://hydra.gnu.org/job/gnu/master/rustc-1.16.0.x86_64-linux
>>
>>
>>
>>
> It seems that the bundled copy of jemalloc in the rustc repo is currently
> pinned at 4.5.0 partially
> because of this specific issue as well.
>
> I did find an issue on the rust GH repo [0], and it seems this also affects
> the nix-rust project,
> who seem to have the same errors as our currently failing build [1].
>
> A temporary workaround could be to have a custom version of jemalloc with
> the c++ features disabled
> by building with `--disable-cxx'. Alternatively, we could just make use of
> jemalloc 4.5.0 for rustc only
> until this is all sorted our by upstream.

Using a --disable-cxx variant of the latest jemalloc sounds preferable
to me over running an old jemalloc.

How does that sound?

Thanks,
Ludo’.

bug#28034: elixir build fails

[Ludovic Courtès]

Hi nee,

nee  skribis:

> Hello, thank you for the fast and detailed reply.
> I made two patches that upgrade erlang and elixir and disable the
> failing tests in elixir, and got it to build again.

Great, I applied both patches and added a copyright line for you in
elixir.scm.

> I sometimes get this undeterministic compile error (see the attached
> log). It's always the same error, but it doesn't appear every time, so I
> can get a passing build running:
>
> `until ./pre-inst-env guix build elixir; do sleep 1; done`
>
> I don't think that it is related to the version upgrade because I also
> got this with the old versions when I first tried to build it today.

Could you report it upstream?  We definitely need their help to fix this
kind of issues.

> While this still not good, it is at least an improvement over the
> current state where the package will fail to install in 100% of cases.

Indeed, thanks!

Ludo’.

bug#29537: Core updates broken

[Ludovic Courtès]

Hello!

Marius Bakke  skribis:

> Ricardo Wurmus  writes:
>
>> Marius Bakke  writes:
>>
>>> Gábor Boskovits  writes:
>>>
 It seems, that we have a breakage in current core-updates. m4, gettext, and
 at least a few other packages fail to build.
>>>
>>> Hello!
>>>
>>> The problem is that the glibc version string is used a couple of places
>>> to determine where locales are found.
>>>
>>> The attached patch fixes it, though I'm not sure if it's the best
>>> approach.  Thoughts?
>>
>> Thank you.
>>
>> I find it a little ugly to replace the exact version string with only
>> the major+minor version substring.  Why can’t we use the full version
>> string?
>
> I think it's because "glibc-versioned-locpath.patch" uses the libc
> VERSION constant.

Right.  That’s akin to the “effective version” string as defined in
Guile and other packages for cases where you only care about
MAJOR.MINOR.

> Perhaps we could substitute glibcs "version.h", but that might break
> other things.  Or introduce a different variable, say
> GUIX_GLIBC_VERSION, and use that.  WDYT?

FWIW I think your patches does the right thing.  If we want to reduce
ugliness, we can always add an ‘effective-glibc-version’ property in the
glibc package, but that probably won’t be much less ugly than calling
‘version-major+minor’.

Thoughts?

Ludo’.

bug#29537: Core updates broken

[Ludovic Courtès]

Hi,

Marius Bakke  skribis:

> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Sun, 3 Dec 2017 02:32:16 +0100
> Subject: [PATCH] gnu: glibc: Don't use full version string in locale path.
>
> This is a follow-up to commit ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a.
> Fixes .
>
> * gnu/packages/base.scm (glibc/linux)[version]: Change to 2.26.91-gaaa2eb83b8.
> [source](uri): Adjust accordingly.
> [arguments]: Use VERSION-MAJOR+MINOR for locales path.
> (glibc-locales, glibc-utf8-locales): Likewise.
> * guix/profiles.scm (ca-certificate-bundle, profile-derivation): Likewise.

Good catch!  That looks good to me (along with the guix/packages.scm
occurrence you found.)

Thanks!

Ludo’.

bug#29546: Intermittent test failures in 'git'

[Ludovic Courtès]

Hi Mark,

Mark H Weaver  skribis:

> On Hydra, the following intermittent test failure in 'git' has occurred
> twice in the last two days, and twice about a month ago:

This was discussed in , which led to commit
c03ba83c17c91e34e811a909fae0f63aab701ff9 to run tests sequentially.

Currently that seems to work well:

  https://hydra.gnu.org/job/gnu/master/git-2.15.1.x86_64-linux
  https://hydra.gnu.org/job/gnu/master/git-2.15.1.i686-linux

The ARM build is still running though:

  https://hydra.gnu.org/job/gnu/master/git-2.15.1.armhf-linux

Let’s see if the problem shows up again.

Ludo’.

bug#29537: Core updates broken

[Marius Bakke]

Ludovic Courtès  writes:

> Hi,
>
> Marius Bakke  skribis:
>
>> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke 
>> Date: Sun, 3 Dec 2017 02:32:16 +0100
>> Subject: [PATCH] gnu: glibc: Don't use full version string in locale path.
>>
>> This is a follow-up to commit ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a.
>> Fixes .
>>
>> * gnu/packages/base.scm (glibc/linux)[version]: Change to 
>> 2.26.91-gaaa2eb83b8.
>> [source](uri): Adjust accordingly.
>> [arguments]: Use VERSION-MAJOR+MINOR for locales path.
>> (glibc-locales, glibc-utf8-locales): Likewise.
>> * guix/profiles.scm (ca-certificate-bundle, profile-derivation): Likewise.
>
> Good catch!  That looks good to me (along with the guix/packages.scm
> occurrence you found.)

OK, pushed!

Now, it would be good to do a final update of glibc so we get the fix
for CVE-2017-15804 and a few other things.  Could you upload a new
tarball for glibc-2.26-105-g0890d5379c.tar.xz?  I'm getting
"0m8cnp2nik0596adwibhl0f3w649m57i3qciqwpwiix7y0sb7vhi" for it.


signature.asc
Description: PGP signature

bug#29522: [bug#29555] [PATCH] gnu: rust: update rust to 1.22.1 and cargo to 1.23.0

[Nikolai Merinov]

I added "-lstdc++" to rust standard lib to overcome issue. Which solution is 
better: 
1. change link flags for rust standard library, or
2. create rust-specific jemalloc as suggested in #29522?

4 декабря 2017 г. 19:33:31 GMT+05:00, Jelle Licht  пишет:
>2017-12-03 20:01 GMT+01:00 Nikolai Merinov
>:
>
>> Update for a rustc and cargo packages. This update will also fix a
>> build.
>>
>>
>I do not have enough know-how to properly review your patch, but at
>least I
>can verify it seems to work.
>I was able to build rustc and cargo succesfully with your patches, and
>was
>able to build and run a trivial hello world program written in rust.
>When this patch is merged,  I think we can also close
>http://lists.gnu.org/archive/html/bug-guix/2017-12/msg6.html, as it
>will no longer be relevant.

-- 
Nikolai Merinov

bug#29492: tests/guix-system.sh failure on unbound variable check

[Eric Bavier]

Pushed in 42d16037d857aac02add38513bfa58535c1ddcfe

Thanks,

Eric Bavier, Scientific Libraries, Cray Inc.


From: Ludovic Courtès 
Sent: Saturday, December 2, 2017 03:59
To: Eric Bavier
Cc: '29...@debbugs.gnu.org'
Subject: Re: bug#29492: tests/guix-system.sh failure on unbound variable check

Eric Bavier  skribis:

>> -Original Message-
>> From: Ludovic Courtès [mailto:l...@gnu.org]
>> Sent: Thursday, November 30, 2017 4:04 AM
>> To: Eric Bavier
>> Cc: 29...@debbugs.gnu.org
>> Subject: Re: bug#29492: tests/guix-system.sh failure on unbound variable
>> check
>>
>> Hi Eric,
>>
>> Eric Bavier  skribis:
>>
>> > Latest guix master (2cdf78df2d3d5d88c7e6908754233cf37cce1e61) fails
>> tests/guix-system.sh for me, on line 128.  This seems to be caused by the
>> fact that the error output contains a multi-character column number:
>> >
>> > ```
>> > /tmp/bavier/tmpfile:9:14: In procedure #:
>> > /tmp/bavier/tmpfile:9:14: GRUB-config: unbound variable
>> > hint: Did you forget a `use-modules' form?
>>
>> I suppose that’s with Guile 2.0, right?
>
> Right, 2.0.14.
>
>> So the patch would become:
>
> diff --git a/tests/guix-system.sh b/tests/guix-system.sh
> index 4bb866adf..eaa0c4332 100644
> --- a/tests/guix-system.sh
> +++ b/tests/guix-system.sh
> @@ -125,7 +125,8 @@ else
>   # See .
>   grep "$tmpfile:[49]:[0-9]: GRUB-config.*[Uu]nbound variable" 
> "$errorfile"
>  else
> - grep "$tmpfile:9:[0-9]: GRUB-config.*[Uu]nbound variable" "$errorfile"
> + # With Guile 2.0.14 the error is reported on line 14 (the last line).
> + grep "$tmpfile:9:[0-9]\+: GRUB-config.*[Uu]nbound variable" "$errorfile"
>  fi
>  fi
>
> No, at *column* 14.  Which I believe is the desired result, right?  Character 
> 14 is the '(', the 'GRUB-config symbol itself starts at character 15.   But 
> now I wonder whether we should be using a regex for that anyhow.  Do we 
> expect the column number to change ever?

We don’t, but sometimes location info is not as precise as we’d like.

> I think it would be fine to fix the regex for Guile 2.0 only, but once the 
> bug affecting 2.2 is fixed, it'll need to be applied there too.  Maybe it 
> would make sense to fix both at the same time.

Yes, you’re right, it’s better to fix both.

Feel free to push.

Thank you!

Ludo’.

bug#29546: Intermittent test failures in 'git'

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> Hi Mark,
>
> Mark H Weaver  skribis:
>
>> On Hydra, the following intermittent test failure in 'git' has occurred
>> twice in the last two days, and twice about a month ago:
>
> This was discussed in , which led to commit
> c03ba83c17c91e34e811a909fae0f63aab701ff9 to run tests sequentially.
>
> Currently that seems to work well:
>
>   https://hydra.gnu.org/job/gnu/master/git-2.15.1.x86_64-linux
>   https://hydra.gnu.org/job/gnu/master/git-2.15.1.i686-linux
>
> The ARM build is still running though:
>
>   https://hydra.gnu.org/job/gnu/master/git-2.15.1.armhf-linux

Bad news, it failed (see
):

--8<---cut here---start->8---
*** t9167-git-svn-cmd-branch-subproject.sh ***
ok 1 - initialize svnrepo
ok 2 - import into git
not ok 3 - git svn branch tests
#   
#   test_must_fail git svn branch a &&
#   git svn branch --parents a &&
#   test_must_fail git svn branch -t tag1 &&
#   git svn branch --parents -t tag1 &&
#   test_must_fail git svn branch --tag tag2 &&
#   git svn branch --parents --tag tag2 &&
#   test_must_fail git svn tag tag3 &&
#   git svn tag --parents tag3
#   
# failed 1 among 3 test(s)
1..3
make[2]: *** [Makefile:49: t9167-git-svn-cmd-branch-subproject.sh] Error 1
--8<---cut here---end--->8---

I tried building it for i686 on my laptop and it failed similarly.

This bug report seems to be relevant, and it suggests bugs in the Perl
bindings of Subversion:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871562

For now I’ve disabled three of the git-svn tests that were reported to
fail intermittently in commit c7699ebeb4233d81f294ff7e8b8eb3676119ae4a,
so that we can hopefully build Git more reliably.

Ludo’.

bug#29522: [bug#29555] [PATCH] gnu: rust: update rust to 1.22.1 and cargo to 1.23.0

[Danny Milosavljevic]

Hi,

On Mon, 04 Dec 2017 19:54:13 +0500
Nikolai Merinov  wrote:

> I added "-lstdc++" to rust standard lib to overcome issue. Which solution is 
> better: 
> 1. change link flags for rust standard library, or

Sounds hacky and I'm not sure why it helps or whether it will keep working.

> 2. create rust-specific jemalloc as suggested in #29522?

I vote for using a rust-specific jemalloc without the C++ parts (named 
"jemalloc-without-c++" or something, it just has to pass a flag to 
"configure").  It's smaller, too.  Any downsides?

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Adam Van Ymeren]

l...@gnu.org (Ludovic Courtès) writes:

> Hi,
>
> Jelle Licht  skribis:
>
>> 2017-11-30 23:41 GMT+01:00 Adam Van Ymeren :
>>
>>> I haven't had time to dig in to this further, but in case anyone wants
>>> to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.
>>>
>>> Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
>>> jemalloc back to 4.5.0 causes rustc to build successfully again.  It has
>>> been broken for some time.
>>>
>>> https://hydra.gnu.org/job/gnu/master/rustc-1.16.0.x86_64-linux
>>>
>>>
>>>
>>>
>> It seems that the bundled copy of jemalloc in the rustc repo is currently
>> pinned at 4.5.0 partially
>> because of this specific issue as well.
>>
>> I did find an issue on the rust GH repo [0], and it seems this also affects
>> the nix-rust project,
>> who seem to have the same errors as our currently failing build [1].
>>
>> A temporary workaround could be to have a custom version of jemalloc with
>> the c++ features disabled
>> by building with `--disable-cxx'. Alternatively, we could just make use of
>> jemalloc 4.5.0 for rustc only
>> until this is all sorted our by upstream.
>
> Using a --disable-cxx variant of the latest jemalloc sounds preferable
> to me over running an old jemalloc.

I feel like if rust is pegged at jemalloc 4.5.0 then that's what we
should be feeding it.  The changelog suggestst that jemalloc 5 has some
pretty significant changes, changing rust to use that theoretically lead
to some subtle bugs, I feel like I'd rather wait for upstream to make
the upgrade themselves.

>
> How does that sound?
>
> Thanks,
> Ludo’.

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Ludovic Courtès]

Adam Van Ymeren  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Jelle Licht  skribis:

[...]

>>> It seems that the bundled copy of jemalloc in the rustc repo is currently
>>> pinned at 4.5.0 partially
>>> because of this specific issue as well.
>>>
>>> I did find an issue on the rust GH repo [0], and it seems this also affects
>>> the nix-rust project,
>>> who seem to have the same errors as our currently failing build [1].
>>>
>>> A temporary workaround could be to have a custom version of jemalloc with
>>> the c++ features disabled
>>> by building with `--disable-cxx'. Alternatively, we could just make use of
>>> jemalloc 4.5.0 for rustc only
>>> until this is all sorted our by upstream.
>>
>> Using a --disable-cxx variant of the latest jemalloc sounds preferable
>> to me over running an old jemalloc.
>
> I feel like if rust is pegged at jemalloc 4.5.0 then that's what we
> should be feeding it.  The changelog suggestst that jemalloc 5 has some
> pretty significant changes, changing rust to use that theoretically lead
> to some subtle bugs, I feel like I'd rather wait for upstream to make
> the upgrade themselves.

Right, that makes sense.

In that case, we should reintroduce jemalloc 4.5 and use that in Rust.

Ludo’.

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Adam Van Ymeren]

l...@gnu.org (Ludovic Courtès) writes:

> Adam Van Ymeren  skribis:
>
>> l...@gnu.org (Ludovic Courtès) writes:
>>
>>> Hi,
>>>
>>> Jelle Licht  skribis:
>
> [...]
>
 It seems that the bundled copy of jemalloc in the rustc repo is currently
 pinned at 4.5.0 partially
 because of this specific issue as well.

 I did find an issue on the rust GH repo [0], and it seems this also affects
 the nix-rust project,
 who seem to have the same errors as our currently failing build [1].

 A temporary workaround could be to have a custom version of jemalloc with
 the c++ features disabled
 by building with `--disable-cxx'. Alternatively, we could just make use of
 jemalloc 4.5.0 for rustc only
 until this is all sorted our by upstream.
>>>
>>> Using a --disable-cxx variant of the latest jemalloc sounds preferable
>>> to me over running an old jemalloc.
>>
>> I feel like if rust is pegged at jemalloc 4.5.0 then that's what we
>> should be feeding it.  The changelog suggestst that jemalloc 5 has some
>> pretty significant changes, changing rust to use that theoretically lead
>> to some subtle bugs, I feel like I'd rather wait for upstream to make
>> the upgrade themselves.
>
> Right, that makes sense.
>
> In that case, we should reintroduce jemalloc 4.5 and use that in Rust.

Sounds good, I have a patch that does this and also bumps rust to latest
upstream, but the build is taking forever.  Will post once I've built it
successfully.

>
> Ludo’.

bug#29570: challenge Backtraces

[Vagrant Cascadian]

After a recent guix pull, I'm getting tracebacks when attempting to run
guix challenge.

I tried switching subsititues to a local caching proxy, not sure if that
could possibly break anything. But after switching back to using the
substitutes directly, the problem still persists.

$ guix --version
guix (GNU guix) 1fa37d1b55b1d25a9d20c7b50a531b763e7a1398

$ guix challenge --substitute-urls="https://berlin.guixsd.org 
https://mirror.hydra.gnu.org"; linux-libre
Backtrace:
  12 (primitive-load "/gnu/store/sy84f3kbjj2f2nl1ljbdcmsqrz8…")
In guix/ui.scm:
  1452:12 11 (run-guix-command _ . _)
In ice-9/boot-9.scm:
837:9 10 (catch _ _ # …)
837:9  9 (catch _ _ # …)
837:9  8 (catch _ _ # …)
In guix/scripts/challenge.scm:
   304:13  7 (_)
In guix/store.scm:
  1444:24  6 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
In guix/scripts/challenge.scm:
   305:15  5 (_ _)
   149:34  4 (_ _)
In srfi/srfi-1.scm:
   679:15  3 (append-map _ _ . _)
   592:17  2 (map1 ("https://berlin.guixsd.org";; "https://mirror.hy…";))
In guix/scripts/substitute.scm:
   725:23  1 (lookup-narinfos "https://berlin.guixsd.org";; _)
   697:16  0 (fetch-narinfos "https://berlin.guixsd.org";; ("/gnu/sto…"))

guix/scripts/substitute.scm:697:16: In procedure fetch-narinfos:
guix/scripts/substitute.scm:697:16: Wrong type to apply: #


live well,
  vagrant


signature.asc
Description: PGP signature

bug#29522: [bug#29555] [PATCH] gnu: rust: update rust to 1.22.1 and cargo to 1.23.0

[Nikolai Merinov]

Please find new version of patch: I removed linkage with libstdc++ and added 
new jemalloc-without-c++

>From 7cc263d0cbed910c9fdfcef57b52538229054e6b Mon Sep 17 00:00:00 2001
From: Nikolay Merinov 
Date: Sun, 3 Dec 2017 19:55:24 +0500
Subject: [PATCH] gnu: rust: update rust to 1.22.1 and cargo to 1.23.0
To: guix-patc...@gnu.org

* gnu/packages/rust.scm (%rust-bootstrap-binaries-version): update version
(%rust-bootstrap-binaries): use x86_64 rust bootstrap package for x86_64 build
(%cargo-reference-project-file): Use specific file as "project" file when
patching rust vendored sources
(%cargo-reference-hash): sha256 sum for %cargo-reference-project-file
(rustc-bootstrap): use bootstrap package with host architecture
(cargo-bootstrap): use bootstrap package with host architecture
(rustc): Add new test dependency, fix build issues, use "./x.py" script for
build instead of "./configure"
(cargo): Update dependencies, patch shebangs for vendored sources
* gnu/packages/jemalloc.scm: add version of jemalloc without c++
---
 gnu/packages/jemalloc.scm |   10 +
 gnu/packages/rust.scm | 1179 ++---
 2 files changed, 808 insertions(+), 381 deletions(-)

diff --git a/gnu/packages/jemalloc.scm b/gnu/packages/jemalloc.scm
index a3bd2c93a..b1f324e1a 100644
--- a/gnu/packages/jemalloc.scm
+++ b/gnu/packages/jemalloc.scm
@@ -23,6 +23,7 @@
   #:use-module ((guix licenses) #:select (bsd-2))
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix utils)
   #:use-module (gnu packages perl)
   #:use-module (guix build-system gnu))
 
@@ -62,3 +63,12 @@
  "This library providing a malloc(3) implementation that emphasizes
 fragmentation avoidance and scalable concurrency support.")
 (license bsd-2)))
+
+(define-public jemalloc-without-c++
+  (package
+(inherit jemalloc)
+(name "jemalloc-without-c++")
+(arguments
+ (substitute-keyword-arguments (package-arguments jemalloc)
+   ((#:configure-flags cf)
+`(cons "--disable-cxx" ,cf))
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 583ea37c8..11e8a8b25 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -3,6 +3,7 @@
 ;;; Copyright © 2016 Eric Le Bihan 
 ;;; Copyright © 2016 ng0 
 ;;; Copyright © 2017 Ben Woodcroft 
+;;; Copyright © 2017 Nikolai Merinov 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -29,6 +30,7 @@
   #:use-module (gnu packages elf)
   #:use-module (gnu packages flex)
   #:use-module (gnu packages gcc)
+  #:use-module (gnu packages gdb)
   #:use-module (gnu packages jemalloc)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages llvm)
@@ -37,17 +39,19 @@
   #:use-module (gnu packages ssh)
   #:use-module (gnu packages tls)
   #:use-module (gnu packages version-control)
+  #:use-module (gnu packages)
   #:use-module (guix build-system cargo)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system trivial)
   #:use-module (guix download)
+  #:use-module (guix base16)  ;for generated "cargo" native-inputs
   #:use-module ((guix licenses) #:prefix license:)
   #:use-module (guix packages)
   #:use-module (ice-9 match)
   #:use-module (srfi srfi-26))
 
 ;; Should be one less than the current released version.
-(define %rust-bootstrap-binaries-version "1.15.0")
+(define %rust-bootstrap-binaries-version "1.21.0")
 
 (define %rust-bootstrap-binaries
   (origin
@@ -55,10 +59,18 @@
 (uri (string-append
   "https://static.rust-lang.org/dist/";
   "rust-" %rust-bootstrap-binaries-version
-  "-i686-unknown-linux-gnu.tar.gz"))
+  "-" %host-type ".tar.gz"))
 (sha256
  (base32
-  "0wmkfx8pxmkkw021mrq9s3xhra8f0daqdl6j56pxyn4w39i0rzrw"
+  (match %host-type
+	("i686-unknown-linux-gnu"
+ "1vnvqwz30hvyjcfr1f602lg43v2vlqjr3yhb5vr8xnrcc07yvjmp")
+	("x86_64-unknown-linux-gnu"
+ "1s0866qcy0645bqhsbs3pvk2hi52ps8jzs7x096w0as033h707ml"))
+
+(define %cargo-reference-project-file "/dev/null")
+(define %cargo-reference-hash
+  "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855")
 
 (define (increment-rust-version rust-version major patch)
   (match (string-split rust-version #\.)
@@ -92,7 +104,6 @@
 (arguments
  `(#:tests? #f
#:strip-binaries? #f
-   #:system "i686-linux"
#:phases
(modify-phases %standard-phases
  (delete 'configure)
@@ -103,8 +114,7 @@
 (gcc:lib (assoc-ref inputs "gcc:lib"))
 (libc (assoc-ref inputs "libc"))
 (zlib (assoc-ref inputs "zlib"))
-(ld-so (string-append libc
-  ,(glibc-dynamic-linker "i686-linux")))
+(ld-so (string-append libc ,(glibc-dynamic-linker)))
 (rpath (string-append out "/lib:" zlib "/lib:"
   libc "/lib:" gcc:lib "/lib"))
 (rustc (string-