| 1 Jul 2025 |
 emily | do we need to support rust.platform | 15:38:58 |
| emily | people can just manually rustcTargetSpec | 15:39:03 |
 dramforever | buf for fastCross this can't be right... right?
mkdir -p build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-{std,rustc}/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/
```
| 15:39:20 |
| dramforever | * buf for fastCross this can't be right... right?
mkdir -p build/${stdenv.hostPlatform.rust.rustcTargetSpec}/stage0-{std,rustc}/${stdenv.hostPlatform.rust.rustcTargetSpec}/release/
| 15:39:25 |
| emily | anyway I believe you can actually make a directory in pure Nix | 15:39:35 |
| emily | by doing awful NAR unpacking hacks or something | 15:39:38 |
| dramforever | oh god | 15:39:48 |
 Alyssa Ross | Okay rust-hypervisor-firmware may not actually be broken. Apparently it's expected to build it without cross compiling explicitly, and you have to allow unsupported systems: https://github.com/NixOS/nixpkgs/pull/378694#issuecomment-2637739053 | 15:40:21 |
| emily | …I'd call that broken | 15:41:01 |
| Alyssa Ross | It's evidently in use, or at least cared about | 15:41:21 |
| dramforever | no i think that's just the meta.platforms being wrong | 15:41:53 |
| dramforever | oh wait no it's doing cross compile in secret | 15:42:07 |
| Alyssa Ross | yeah | 15:42:11 |
| Alyssa Ross | it's horrible | 15:42:12 |
| dramforever | but then that new rustPlatform should pick up the right platform | 15:42:22 |
| dramforever | anyway the unsupported platform thing is just a meta issue i think | 15:42:59 |
| emily | I have a ridiculous idea for the target spec things | 15:43:50 |
| emily | what if we make a directory and put nixpkgs-{build,host,target}-platform.json symlinks to the rustcTargetSpec in there | 15:44:26 |
| emily | then the derivation hashes don't get included in the names | 15:44:51 |
| dramforever | you mean like in prePhases? | 15:45:21 |
| dramforever | wait how do we find the file then | 15:50:03 |
| dramforever | does rustc have a TARGET_SPEC_DIR or something | 15:50:47 |
| dramforever | you know what, nevermind, i'm not actually blocked on r-h-f | 15:59:26 |
| dramforever | i don't have the string with context problem if i use rust.framepointers | 15:59:48 |
| dramforever | * i don't have the string with context problem if i use rust.frame-pointers | 16:02:24 |
 Toma | I have opened https://github.com/NixOS/nixpkgs/pull/421558
But I think this is not the way to go, at least not yet.
I don't want to imagine the merge issues with having made a change in 2000 packages, all of them near often-changing hash values and having them be only in staging but not master.
I think we should first have a staging cycle where the useFetchCargoVendor = true is made an actual NOOP (we filter it out from the attrs passed down to mkDerivation)
After that, we can do the same thing as my PR above, only targeting master directly and have no rebuilds
Any better ideas?
| 17:31:48 |
| Toma | I'd also imagine a similar process for release-25.05, but I guess the merge issues are less severe there | 17:32:46 |
| emily | oh god, it gets passed down still? | 17:32:48 |
| emily | yes, let's do the staging thing then | 17:33:04 |
| emily | and certainly let's backport to 25.05 | 17:33:09 |
