| 15 Mar 2026 |
|  isabel set a profile picture. | 20:54:56 |
| 16 Mar 2026 |
|  azban joined the room. | 01:33:59 |
|  purepani changed their display name from purepani to purepanid. | 05:54:47 |
| purepani changed their display name from purepanid to purepani. | 05:55:39 |
| 18 Mar 2026 |
|  changed their display name from bemyak to . | 14:14:20 |
| 19 Mar 2026 |
|  @d86leader:matrix.org left the room. | 15:50:05 |
| 20 Mar 2026 |
 PixelHamster | Hi, I'm trying to package my leptos application using a nix flake.
For our CI it seemed very beneficial to have a separate dependency derivation (as crane recommends).
However when compiling the dependencies on their own with crane's buildDepsOnly I get told it cannot find lld during compile of wasm-streams: | 12:19:07 |
| PixelHamster | 
Download image.png | 12:19:10 |
| PixelHamster | My 2 dependency derivations look something like this at the moment:
cargoArtifacts = craneLib.buildDepsOnly commonArgs;
cargoWasmArtifacts = craneLib.buildDepsOnly (commonArgs // {
# wasm-streams wants lld
buildInputs = [ pkgs.lld ];
cargoExtraArgs = "--target=wasm32-unknown-unknown --no-default-features --features hydrate ";
# Additional environment variables can be set directly
CARGO_PROFILE = "wasm-release";
CARGO_TARGET_DIR = "target/front";
});
| 12:19:38 |
| PixelHamster | I looked at wasm-streams and didn't get where the lld requirement came from, otherwise I'd try to patch the crate | 12:22:13 |
| azban | it looks like lld is missing during the cargo phase not during building wasm. can you try to add this as buildInputs at the top level of your derivation or in cargoArtificacts? hard to tell exactly what's going on only with that snippet of your derivation | 23:50:31 |
| 21 Mar 2026 |
 dish [Fox/It/She] | In reply to @pyrox:pyrox.dev
https://github.com/thepowersgang/mrustc/pull/387 mrustc 1.90 support 👀 got merged, do I make the probably bad decision of trying to make a bootstrap chain from this | 14:21:41 |
| dish [Fox/It/She] | * <mx-reply><blockquote><a href="https://matrix.to/#/!FBuJyWXTGcGtHTPphC:nixos.org/$m5Nz8gWgTwg1zAjDa2xN0G7UQGHyPEjvE5NhUCMeLNU?via=pyrox.dev&via=matrix.org&via=catgirl.cloud">In reply to</a> <a href="https://matrix.to/#/@pyrox:pyrox.dev">@pyrox:pyrox.dev</a><br /><a href="https://github.com/thepowersgang/mrustc/pull/387">https://github.com/thepowersgang/mrustc/pull/387</a> mrustc 1.90 support 👀</blockquote></mx-reply>got merged, do I make the probably bad decision of trying to make a rustc bootstrap chain from this | 14:22:33 |
| dish [Fox/It/She] | ouch, the most recent bootstrap chain from dtolnay(mrustc targetting 1.90 -> 1.94 rustc) apparently requires 310gb of disk space. | 14:27:19 |
| dish [Fox/It/She] | * ouch, the most recent bootstrap chain from dtolnay(mrustc targetting 1.90 -> 1.94 rustc) apparently requires 310gb of disk space. though presumably they dont clean up build artifacts as they go, so nix may have an advantage in that area. | 14:28:50 |
 emily | mrustc lags behind regularly and I had to mark it broken at one point, which makes me leery | 14:34:40 |
| emily | esp old Rust keeping around old LLVM would hurt since the packaging is so complex | 14:35:11 |
| dish [Fox/It/She] | yeahhhh | 14:36:26 |
| dish [Fox/It/She] | im glad it got 1.90 support cuz its been at 1.74 for a while | 14:36:42 |
 K900 | Yeah it definitely doesn't feel like mrustc is sustainable | 14:36:59 |
| dish [Fox/It/She] | it is clearly a peoject with a bus factor approaching 1, which definitely isnt good | 14:37:01 |
| K900 | I'm not sure what is sustainable | 14:37:08 |
| K900 | If anything | 14:37:14 |
| K900 | Maybe we'll have gccrs one day | 14:37:19 |
| dish [Fox/It/She] | i mean thats coming along somewhat well apparently | 14:37:33 |
| dish [Fox/It/She] | what they can compile im not sure on tho | 14:37:41 |
 whispers [& it/fae] | their current target rust version is 1.49 so it'll be a hot minute | 14:55:10 |
 Cathal | Would a fix to rustPlatform.fetchCargoVendor have to go through staging? Hit a bug around the recent changes (https://github.com/NixOS/nixpkgs/pull/387337) when building COSMIC packages. | 15:47:43 |
| K900 | Yes | 16:10:43 |
| azban | is it intentional that cargoBuildHook doesn't support Cargo.lock files that have multiple dependencies with the same git repo as source with different commits. it seems like it causing this issue: https://github.com/NixOS/nixpkgs/issues/501981 | 23:27:19 |
