On Tue, Oct 22, 2024 at 11:16:44AM -0400, Brennan Vincent wrote:
> Efraim Flashner <efr...@flashner.co.il> writes:
> 
> > On Tue, Oct 22, 2024 at 07:51:07AM -0400, Brennan Vincent wrote:
> >> Efraim Flashner <efr...@flashner.co.il> writes:
> >> 
> >> > On Tue, Oct 22, 2024 at 07:31:05AM +0000, Divya wrote:
> >> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent 
> >> >> <bren...@umanwizard.com> wrote:
> >> >> >Note that we already have Rust 1.81 in rust-team, and I have already
> >> >> >sent a patch to update to 1.82 (the latest stable). Usually Efraim
> >> >> >reviews these updates.
> >> >> >
> >> >> >-------------------- Start of forwarded message --------------------
> >> >> >From: help-debb...@gnu.org (GNU bug Tracking System)
> >> >> >To: Brennan Vincent <bren...@umanwizard.com>
> >> >> >Subject: bug#73864: Acknowledgement ([PATCH] gnu: rust: update to 1.82)
> >> >> >Date: Fri, 18 Oct 2024 15:12:01 +0000
> >> >> >
> >> >> >Thank you for filing a new bug report with debbugs.gnu.org.
> >> >> >
> >> >> >This is an automatically generated reply to let you know your message
> >> >> >has been received.
> >> >> >
> >> >> >Your message is being forwarded to the package maintainers and other
> >> >> >interested parties for their attention; they will reply in due course.
> >> >> >
> >> >> >Your message has been sent to the package maintainer(s):
> >> >> > guix-patc...@gnu.org
> >> >> >
> >> >> >If you wish to submit further information on this problem, please
> >> >> >send it to 73...@debbugs.gnu.org.
> >> >> >
> >> >> >Please do not send mail to help-debb...@gnu.org unless you wish
> >> >> >to report a problem with the Bug-tracking system.
> >> >> >
> >> >> >-- 
> >> >> >73864: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73864
> >> >> >GNU Bug Tracking System
> >> >> >Contact help-debb...@gnu.org with problems
> >> >> >-------------------- End of forwarded message --------------------
> >> >> >
> >> >> 
> >> >> Hello Brennan,
> >> >> 
> >> >> That sounds like good news then. It should be available in the guix
> >> >> channel soon then?
> >> 
> >> It will be available after (1) it is reviewed and merged to the
> >> rust-team branch, and (2) the next time after that when rust-team is
> >> merged to master.
> >> 
> >> I can't predict how long that will take, but it could be a few
> >> months. If you urgently need Rust 1.82 faster than that, you need to
> >> take another approach, for example, one of the following:
> >> 
> >> * Configure your system to use the rust-team branch rather than master,
> >> 
> >> * Use my guix-rust-next channel I linked in the other thread (note: not
> >>   supported by the official Guix project, but it's working for me),
> >> 
> >> * If you're on a foreign distro, just install Rustup and don't use Guix
> >>   for Rust stuff. (Less feasible if you're on GuixSD).
> >> 
> >> In general, Guix is not a distribution where major changes to packages
> >> land immediately, so in cases like Rust where the language is
> >> fast-moving enough that most developers want to use the latest version,
> >> you have to get used to using some workaround.
> >> 
> >> >
> >> > I'm not sure I have the time to do all the testing necessary for bumping
> >> > rust to 1.82 currently so right now I'm about to join the merge queue
> >> > with rust-1.81.
> >> 
> >> Efraim, let me know if/how I can help with testing/maintaining new Rust
> >> releases. I've been sending the patches for new versions as they come
> >> out but I'd also be able to help in other ways if you tell me more about
> >> what your workflow is for merging them.
> >
> > Currently I first build the new version on the 3 supported architectures
> > for rust, x86_64, aarch64 and riscv64. I also try building the non-rust
> > package version, since we'll be using that one to build a future version
> > of rust.
> >
> 
> How are you building for riscv64 ? Do you have access to an actual
> risc64 machine or are you using an emulator? Or do you cross-compile
> from x86 or arm?

I've always been jealous of people who have access to exotic hardware so
I've actually picked up a bunch of other machines over the years. I
currently have 3 riscv64 boards which build reasonably quickly and a
number of aarch64 boards, not all of which I actually have in use. I do
occasionally use the qemu-binfmt-service on my x86_64 machine to speed
up builds, but generally for things like deblobbing the kernel or if a
build takes more RAM or storage than I can handle on one of the
machines.

> > After the rust package itself builds I normally try building something
> > simple like zoxide on each architecture, and I'll try cross-compiling it
> > too (only from x86_64) to test that the rust sysroot package doesn't
> > need changes. From there I can be pretty sure everything should be good
> > and I attempt to build the list of cargo-build packages which don't
> > start with "rust-" and fix those or their dependencies as needed. Then
> > I'll try building all the rust packages and fix those I can.
> >
> > In terms of testing, for recent versions it's really only been a failed
> > test here or there for aarch64 and riscv64, so if the zoxide and cross
> > zoxide both build then that's pretty much everything.

I realize I didn't mention it, but if zoxide and cross zoxide work from
x86_64 specifically then generally everything should be fine and I can
run the other architectures through a couple of times to update the
skipped tests there, if there are any.

> > Interesting tidbits:
> > In terms of cross building, on some versions the windows versions work
> > and on some they don't, they generally don't like that we strip out the
> > bundled libraries. The Hurd may or may not work, and a number of crates
> > still need some logic touch-ups to deal with it. 32-bit powerpc has some
> > quirks in rust that prevent some crates from working, but also makes a
> > good cross-target since it's such a niche target, being incredibly old
> > and big-endian. And I can actually test binaries built if necessary.
> >

-- 
Efraim Flashner   <efr...@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

Attachment: signature.asc
Description: PGP signature

Reply via email to