[PATCH 1/3] Bump rust 1.57 -> 1.58

  • Done
  • quality assurance status badge
Details
3 participants
  • Jim Newsome
  • kiasoc5
  • Maxime Devos
Owner
unassigned
Submitted by
Jim Newsome
Severity
normal
Merged with
J
J
Jim Newsome wrote on 22 Jul 2022 00:01
(address . guix-patches@gnu.org)(name . Jim Newsome)(address . jnewsome@torproject.org)
0dacb7cb72945f7f6886602c47111661b746cbcc.1658440640.git.jnewsome@torproject.org
From: Jim Newsome <jnewsome@torproject.org>

---
gnu/packages/rust.scm | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

Toggle diff (34 lines)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index 67dc5cdaf3..dd0f15a95c 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -644,10 +644,14 @@ (define rust-1.56
rust-1.55 "1.56.1" "04cmqx7nn63hzz7z27b2b0dj2qx18rck9ifvip43s6dampx8v2f3"))
(define rust-1.57
+ (rust-bootstrapped-package
+ rust-1.56 "1.57.0" "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim"))
+
+(define rust-1.58
(let ((base-rust
(rust-bootstrapped-package
- rust-1.56 "1.57.0"
- "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim")))
+ rust-1.57 "1.58.1"
+ "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")))
(package
(inherit base-rust)
(outputs (cons "rustfmt" (package-outputs base-rust)))
@@ -790,7 +794,7 @@ (define rust-1.57
;;; intermediate rusts are built for bootstrapping purposes and should not
;;; be relied upon. This is to ease maintenance and reduce the time
;;; required to build the full Rust bootstrap chain.
-(define-public rust rust-1.57)
+(define-public rust rust-1.58)
(define-public rust-src
(hidden-package

base-commit: 5dfc6ab1ab292b87ceea144aa661d0e64c834031
--
2.25.1
J
J
Jim Newsome wrote on 22 Jul 2022 00:09
[PATCH 2/3] Bump rust 1.58 -> 1.59
(address . 56684@debbugs.gnu.org)(name . Jim Newsome)(address . jnewsome@torproject.org)
49e7d203531129e1fad1106e01d2564c3d0170ab.1658440640.git.jnewsome@torproject.org
From: Jim Newsome <jnewsome@torproject.org>

---
gnu/packages/rust.scm | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

Toggle diff (32 lines)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index dd0f15a95c..cb16fbaf0a 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -648,10 +648,14 @@ (define rust-1.57
rust-1.56 "1.57.0" "06jw8ka2p3kls8p0gd4p0chhhb1ia1mlvj96zn78n7qvp71zjiim"))
(define rust-1.58
+ (rust-bootstrapped-package
+ rust-1.57 "1.58.1" "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8"))
+
+(define rust-1.59
(let ((base-rust
(rust-bootstrapped-package
- rust-1.57 "1.58.1"
- "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8")))
+ rust-1.58 "1.59.0"
+ "1yc5bwcbmbwyvpfq7zvra78l0r8y3lbv60kbr62fzz2vx2pfxj57")))
(package
(inherit base-rust)
(outputs (cons "rustfmt" (package-outputs base-rust)))
@@ -794,7 +798,7 @@ (define rust-1.58
;;; intermediate rusts are built for bootstrapping purposes and should not
;;; be relied upon. This is to ease maintenance and reduce the time
;;; required to build the full Rust bootstrap chain.
-(define-public rust rust-1.58)
+(define-public rust rust-1.59)
(define-public rust-src
(hidden-package
--
2.25.1
J
J
Jim Newsome wrote on 22 Jul 2022 00:09
[PATCH 3/3] Bump rust 1.59 -> 1.60
(address . 56684@debbugs.gnu.org)(name . Jim Newsome)(address . jnewsome@torproject.org)
e82ee99e28aedf3ef565eac4a75eb1f5801eb386.1658440640.git.jnewsome@torproject.org
From: Jim Newsome <jnewsome@torproject.org>

---
gnu/packages/rust.scm | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)

Toggle diff (32 lines)
diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index cb16fbaf0a..8cc734095f 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -652,10 +652,14 @@ (define rust-1.58
rust-1.57 "1.58.1" "1iq7kj16qfpkx8gvw50d8rf7glbm6s0pj2y1qkrz7mi56vfsyfd8"))
(define rust-1.59
+ (rust-bootstrapped-package
+ rust-1.58 "1.59.0" "1yc5bwcbmbwyvpfq7zvra78l0r8y3lbv60kbr62fzz2vx2pfxj57"))
+
+(define rust-1.60
(let ((base-rust
(rust-bootstrapped-package
- rust-1.58 "1.59.0"
- "1yc5bwcbmbwyvpfq7zvra78l0r8y3lbv60kbr62fzz2vx2pfxj57")))
+ rust-1.59 "1.60.0"
+ "1drqr0a26x1rb2w3kj0i6abhgbs3jx5qqkrcwbwdlx7n3inq5ji0")))
(package
(inherit base-rust)
(outputs (cons "rustfmt" (package-outputs base-rust)))
@@ -798,7 +802,7 @@ (define rust-1.59
;;; intermediate rusts are built for bootstrapping purposes and should not
;;; be relied upon. This is to ease maintenance and reduce the time
;;; required to build the full Rust bootstrap chain.
-(define-public rust rust-1.59)
+(define-public rust rust-1.60)
(define-public rust-src
(hidden-package
--
2.25.1
J
J
Jim Newsome wrote on 22 Jul 2022 00:14
This is based on the core-updates branch
(address . 56684@debbugs.gnu.org)
387c9d1f-7d1d-82c8-992a-069c43cffd41@jimnewsome.net
Sorry, forgot to change the initial subject line to [PATCH core-updates].

Happy to follow on to bump further; the latest release is 1.62.1:

1.60 was the minimum I needed for my own project and since this is my
first try contributing to guix I figured I'd try getting that in before
bumping further. Each bump takes a while since I need to build one minor
version at a time.
M
M
Maxime Devos wrote on 22 Jul 2022 02:08
Re: [bug#56684] [PATCH 1/3] Bump rust 1.57 -> 1.58
(name . Jim Newsome)(address . jnewsome@torproject.org)
86c503a4-bd43-6ba8-a307-452c57cf1cfa@telenet.be
merge 54439 56684
thanks
You aren't bumping the version but adding a new version of the Rust
package, the old one is still there. Also, conventionally it is named
updating in Guix, and a commit message is missing. For examples see the
git history.
Are all the intermediate steps needed, or could you reduce the number of
new intermediate packages?
E.g., you could try going directly from 1.57 to 1.60 without
intermediate steps. If that's possible, it would be less inefficient to
compile.
Also, there are already patches for updating rust, see
already existing patches before posting duplicates, to avoid double
work, etc.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
M
M
Maxime Devos wrote on 22 Jul 2022 02:09
(address . control@debbugs.gnu.org)
c27ef8a0-0b8b-3480-1a73-70223ee22ac2@telenet.be
merge 54439 56684
thanks
You aren't bumping the version but adding a new version of the Rust
package, the old one is still there. Also, conventionally it is named
updating in Guix, and a commit message is missing. For examples see the
git history.
Are all the intermediate steps needed, or could you reduce the number of
new intermediate packages?
E.g., you could try going directly from 1.57 to 1.60 without
intermediate steps. If that's possible, it would be less inefficient to
compile.
Also, there are already patches for updating rust, see
already existing patches before posting duplicates, to avoid double
work, etc.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
J
J
Jim Newsome wrote on 22 Jul 2022 02:47
(name . Jim Newsome)(address . jnewsome@torproject.org)
9e59f92b-d6dd-897c-8c28-4beea4b7d5f3@jimnewsome.net
On 7/21/22 19:08, Maxime Devos wrote:
Toggle quote (5 lines)
> You aren't bumping the version but adding a new version of the Rust
> package, the old one is still there. Also, conventionally it is named
> updating in Guix, and a commit message is missing. For examples see the
> git history.

Thanks, got it.

Toggle quote (2 lines)
> Are all the intermediate steps needed, or could you reduce the number of
> new intermediate packages?
>
> E.g., you could try going directly from 1.57 to 1.60 without
> intermediate steps. If that's possible, it would be less inefficient to
> compile.

Good question. I assumed that each version was only compilable from the
previous version based on that being how the java compiler works, and
looking at the chain that's already here. From a quick look I don't see
any documented policy to that effect, though, so maybe it's worth a try.

Toggle quote (5 lines)
> Also, there are already patches for updating rust, see
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54439>. Please look for
> already existing patches before posting duplicates, to avoid double
> work, etc.

Oops! It looks like that is both a bit further along and more ambitious
than my version. It's also been lingering for a while, while guix's
version of Rust falls further behind, making me wonder if it's worth
trying to move things up with something closer to my naive approach in
the meantime.

Still, I'll take a closer look at that and see if there's anything I can
do to help that one along.

Thank you for the quick feedback!

-Jim
J
J
Jim Newsome wrote on 22 Jul 2022 03:33
(name . Jim Newsome)(address . jnewsome@torproject.org)
4a7aaaa8-6a0d-e187-381b-0d6cde010f63@jimnewsome.net
On 7/21/22 19:08, Maxime Devos wrote:
Toggle quote (4 lines)
> E.g., you could try going directly from 1.57 to 1.60 without
> intermediate steps. If that's possible, it would be less inefficient to
> compile.

I dug into this a bit.

The Rust bootstrapping docs say to use x.py to download the stage0

x.py is a thin wrapper around bootstrap.py:

bootstrap.py decides what compiler to use as stage0 from stage0.json:

1.62.1 was compiled with 1.61.0:

1.61.0 was compiled with 1.60.0:

1.60.0 was compiled with 1.59.0:

1.59.0 was compiled with 1.58.0:

1.58.0 was compiled with 1.57.0:

So it looks like each release was compiled with a compiler from one
feature-release back. In my patchset, I took the highest patch-version
at each feature-version, since I don't think it makes sense to include
outdated patch-levels, and it should be safe.

Trying to compile a release with an older compiler than it was
originally compiled with seems unlikely to go well. It's not explicitly
stated that it *won't* work, but it seems unlikely that it would, and
would take a lot of time to verify by trial and error.
M
M
Maxime Devos wrote on 22 Jul 2022 11:07
(name . Jim Newsome)(address . jnewsome@torproject.org)
1e56e8b4-7f93-b6fc-69c7-f23ffa2a766b@telenet.be
On 22-07-2022 03:33, Jim Newsome wrote:
Toggle quote (2 lines)
> Trying to compile a release with an older compiler than it was
> originally compiled with seems unlikely to go well.
It usually works fine for GCC. For Rust, it's a bit less likely given
the rate at which APIs etc are added, but it's possible that once in a
while a version can be skipped. Yes, the upstream docs say that X+1 is
compiled with X, but this is Guix not upstream and upstream doesn't seem
to care about bootstrapping much, I do not recommend just following the
method from the docs as a rule or even a recommendation.
(Basically the is-ought problem in another context.)
Toggle quote (2 lines)
> It's not explicitly stated that it *won't* work, but it seems unlikely
> that it would, and would take a lot of time to verify by trial and error.
? All you need to do is, say, remove 1.58 and bootstrap 1.59 directly
from 1.57 and see if that compiles and then also give current version in
guix -> 1.59 a try, etc, if not try 1.57 -> 1.59..
I don't see much trial and error here, there are only a few possible
combinations.
Yes, it will take some time to compile (rust is big), but this only
needs to be done once (or zero, the previous patch submitter tried out
some combinations, those don't have to be done again) and all the
potential compilation time savings will be shared to everyone, and while
it is compiling you can still do other things.
If it's too much for your computer if that's what you mean, I suppose it
would be possible to set up a branch that tries out various combinations
at ci.guix.gnu.org (it has lots of x86-64 machines).
Toggle quote (5 lines)
> Oops! It looks like that is both a bit further along and more
> ambitious than my version. It's also been lingering for a while, while
> guix's version of Rust falls further behind, making me wonder if it's
> worth trying to move things up with something closer to my naive
> approach in the meantime.
If you mean ignoring the already existing patch and making a new one
that does less, this does not incline me to review your patch and
probably would be frustrating to the original patch submitter, causing
your patch to linger too.  What I meant is: if possible, go for the
_original_ patch, improve it with parts of _your_ patch (taking the best
of both) and submit that as a v2 or such, otherwise just go for the
original patch and review or test it (e.g., verify it compiles
reproducibly and share the hash (with "guix hash
/gnu/store/the-store-item", not the hash in /gnu/store/HASH-...)).
Summarised: double-work tends to cause more lingering, not less.
Greetings,
Maxime.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
K
K
kiasoc5 wrote on 3 Aug 2022 08:54
Cannot bootstrap 1.59/1.60 -> 1.62.1 directly
(address . 56684@debbugs.gnu.org)
20220803065451.0fa002c8@aria
I tried and failed to bootstrap from 1.59 and 1.60 to 1.62.1 directly,
the focus should be on getting Rust 1.61 to build.

It's unlikely that skipping versions for bootstrapping will ever work,
since the latest compiler uses nightly features which might not be
present in lower versions [1]. But it's good to know that it's ok to
skip versions if it does work.

?
Your comment

This issue is archived.

To comment on this conversation send an email to 56684@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 56684
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch