On Tue, Oct 22, 2024 at 11:16:44AM -0400, Brennan Vincent wrote: > Efraim Flashner writes: > > > On Tue, Oct 22, 2024 at 07:51:07AM -0400, Brennan Vincent wrote: > >> Efraim Flashner writes: > >> > >> > On Tue, Oct 22, 2024 at 07:31:05AM +0000, Divya wrote: > >> >> On 21 October 2024 18:08:44 GMT, Brennan Vincent 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-debbugs@gnu.org (GNU bug Tracking System) > >> >> >To: Brennan Vincent > >> >> >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-patches@gnu.org > >> >> > > >> >> >If you wish to submit further information on this problem, please > >> >> >send it to 73864@debbugs.gnu.org. > >> >> > > >> >> >Please do not send mail to help-debbugs@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-debbugs@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 רנשלפ םירפא GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted