Sender | Message | Time |
---|---|---|
12 Oct 2024 | ||
catch22 | In reply to @artturin:matrix.org I've ended up just adding the fenix toolchain as a home manager package
The nixpkgs | 22:05:46 |
catch22 | In reply to @artturin:matrix.org* I've ended up just adding the fenix toolchain as a home manager package
The nixpkgs | 22:12:54 |
catch22 | Maybe it would be helpful for nixpkgs to provide a standard rust dev toolchain like this alos | 22:21:52 |
catch22 | * Maybe it would be helpful for nixpkgs to provide a standard rust dev toolchain like this also. | 22:22:06 |
13 Oct 2024 | ||
rfvizarra joined the room. | 18:37:01 | |
15 Oct 2024 | ||
yehowshua removed their profile picture. | 17:19:28 | |
16 Oct 2024 | ||
Li-ion changed their profile picture. | 20:04:41 | |
Toma joined the room. | 20:59:05 | |
Toma | I was looking through the recent darwin rework when I encountered an hook which gave me an interesting idea. This may be flawed somewhere but the main idea would be to somehow implement If anyone has some additional ideas, please share them. I'm aware that there's also another idea where there would be only ""One Big Lockfile"" for all cargo stuff. | 21:33:53 |
emily | AIUI not hashing Git deps was a deliberate hack because Cargo changed the format of them in the past. I believe that something on the lines of what you proposed would work | 21:36:11 |
emily | though of course I'm partial to my own major surgery on Rust dependency handling (that I plan to get to after 24.11) :) | 21:36:27 |
Toma | https://github.com/rust-lang/cargo/pull/11414 AFAICT | 21:40:44 |
emily | right | 23:03:32 |
17 Oct 2024 | ||
Theo Paris | This is more of a general nixpkgs bootstrapping question, but I'm having trouble using rust in a complicated flake/overlay. I've encountered a lot of "infinite recursion" errors, first with zlib -> zlib-ng, and openssl -> aws-lc, but now I'm getting recursion errors with rust. I'm currently receiving errors with rustc-bootstrap and auto-patchelfhook which need diffutils and findutils, but they are built with rust in my flake. Also, because of the infinite recursion errors I've gotten, I ended up overriding a lot more than I should need to. I had to make cmake more minimal and then I had to override ninja to bootstrap with clang++ manually since python was causing issues. The flake I'm working on is hosted here: https://codeberg.org/tinted-software/better-overlay/src/branch/rust/flake.nix#L32 | 00:21:57 |
Theo Paris | * This is more of a general nixpkgs bootstrapping question, but I'm having trouble using rust in a complicated flake/overlay. I've encountered a lot of "infinite recursion" errors, first with zlib -> zlib-ng, and openssl -> aws-lc, but now I'm getting recursion errors with rust. I'm currently receiving errors with rustc-bootstrap and auto-patchelfhook which need diffutils and findutils, but they are built with rust in my flake. Also, because of the infinite recursion errors I've gotten, I ended up overriding a lot more than I should need to. I had to make cmake more minimal and then I had to override ninja to bootstrap with clang++ manually since python was causing issues. The flake I'm working on is hosted here: https://codeberg.org/tinted-software/better-overlay/src/branch/rust/flake.nix#L32 I'm not aware of another way to properly override these packages without an overlay, and an overlay seems to be very problematic because it affects bootstrapping... any ideas? | 00:24:00 |
emily | this may cause havoc for us soon: https://github.com/rust-lang/rust/pull/129687 | 04:51:39 |
emily | it's already causing recent nightlies from rust-overlay to depend on the entire Rust distribution in the closure of compiled binaries | 04:51:55 |
emily | it appears that we will need to specify --remap-path-prefix=… in our build infrastructure to avoid unwanted dependencies, unless our toolchains already avoid having rust-src available? | 04:52:33 |
emily | cc Alyssa Ross | 04:52:38 |
emily | maybe we can just set trim-paths / CARGO_TRIM_PATHS ? https://rust-lang.github.io/rfcs/3127-trim-paths.html has more info | 04:54:33 |
emily | though I guess we probably don't want to strip all paths so we might have to do the remap thing (if it applies to us) | 04:54:55 |
K900 | We can --remap-path-prefix | 05:59:23 |
K900 | As it says | 05:59:25 |
emily | yeah. do we always know what the store path to rust-src will be though? | 06:02:16 |
K900 | Well Rust knows | 06:04:04 |
K900 | Presumably | 06:04:06 |
K900 | So we can just ask it | 06:04:08 |
emily | fair | 06:05:00 |
K900 | There is a flag for it IIRC | 06:05:34 |
Toma | Going back to what I talked about yesterday, I realize now that still requiring outputHashes would no longer be required, assuming that the sha-revision of the git repository is a good enough for reproducible output. This new fetcher would essentially just be an alternative implementation of the vendoring logic, but written by us (just like with importCargoLock), meaning that upstream can't mess up our hashes. Is my assumption correct? | 10:47:23 |