rust: add mips64el to list of bootstrap tarballs

[ghost]

This commit adds the hash for rustc's mips64 bootstrap tarball.

Motivation for this change

To build nix_2_4 natively on mips64 (it depends on mdbook which depends on rustc).

Things done

• Built on platform(s)
  • x86_64-linux
  • mips64el-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.05 Release Notes (or backporting 21.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Mic92]

Would there some way for me to test this? I have powerful x86 machines at my disposal?

[ghost]

There are two commits in this PR. The first one is actually #161158. I have to include that commit in all of my PRs or else OfBorg will give me the "red X of death".

The second commit in this PR is what this PR is really for. That commit is only two lines. You can verify it on any architecture by running pkgs/development/compilers/rust/print-hashes.sh and verifying that the mips64el line it spits out matches exactly the line that this PR commits to pkgs/development/compilers/rust/1_58.nix. As long as that line matches, the second commit in this PR is safe to merge. Unfortunately the first commit needs to wait for #161158.

<blink>I would really really really appreciate it if you could poke some of the other people with write access to get them to review and merge #161158.</blink> That is the blocker almost all of my other mips64 PRs; none of the reviewers for any of the other PRs can merge them until that one is merged. I would appreciate any help in escalating this.

Regarding access to mips64 hardware, Western Semiconductor has offered to donate two mips64el machines to nixpkgs, either with hosting (on our fiber) or without (we ship them to wherever you want). One of these machines is the same rackmount cn6170 Octeon II with the 8gb RAM hack that Debian uses. The other machine is a much faster cn7130 Octeon III but it has soldered-down RAM (only 1gb). We will donate more machines if nixpkgs is serious about using them.

[zowoq]

Western Semiconductor has offered to donate ...

I'd open an issue in https://github.com/NixOS/nixos-org-configurations or email foundation@nixos.org

---

Same as #161165, lets wait until this is useful to merge it.

Also if this is merged when we have a newer version of rust in staging/staging-next (as we do currently, 1.59) we'll end up with a hash mismatch for the mips64el-unknown-linux-gnuabi64 bootstrap when the newer version is merged to master.

[ghost]

Also if this is merged when we have a newer version of rust in staging/staging-next (as we do currently, 1.59) we'll end up with a hash mismatch for the mips64el-unknown-linux-gnuabi64 bootstrap when the newer version is merged to master.

I would think that constitutes an argument for merging the one-line change to print-hashes.sh sooner rather than later.

I have updated this PR to change only print-hashes.sh. That way it won't conflict with any version upgrades, and the mips64el hash will get added automatically the next time somebody runs the print-hashes.sh script.

[ghost]

Would there some way for me to test this? I have powerful x86 machines at my disposal?

Edit: see below #162070 (comment)

So I have a shell script to boot qemu-system-mips64el, but I don't think it will be terribly helpful. After 20 minutes on a 3.2ghz amd64 machine I still don't have the first line of the kernel boot log.

Maybe I am missing some secret "qemu, you go fast" switch? My qemu-fu is not strong.

[grahamc]

@zowoq please have them contact me at graham@nixos.org and we'll get that sorted. Very exciting!

[ghost]

Maybe I am missing some secret "qemu, you go fast" switch? My qemu-fu is not strong.

Okay, my qemu-fu is stronger now.

@Mic92 wrote:

Would there some way for me to test this? I have powerful x86 machines at my disposal?

Here is the shell.nix to get you a mips64el testing VM on other architectures: https://github.com/a-m-joseph/mips64-nixpkgs-qemu

You need #161158 (including the additional commit 97b66ca2548e0586cfea72f1f0da40ac7ef3b36a that I just pushed to it a few minutes ago). Then check out https://github.com/a-m-joseph/mips64-nixpkgs-qemu , run nix-shell, wait for the kernel/initrd/qemu to build, and then you should get a kernel boot and shell inside the mips emulator. See the README.md from that repo for what it should look like.

The initrd created by shell.nix will mount the host machine's /nix/store via 9p (read-only, of course) inside the guest on /nix/store, so if you build something on the host pkgs.pkgsCross.mips64el-linux-gnuabi64.SOME_PACKAGE you can execute it directly once the guest boots. The shell.nix demonstrates this using the hello derivation.

@grahamc, I'll follow up with you. Right now I need to sleep.