| 18 May 2025 |
 Makuru | In reply to @k900:0upti.me
For every architecture Oh yeah, oof. | 11:19:31 |
 K900 | And your source for the checksum is "trust me bro" anyway | 11:19:32 |
| K900 | Like, the purpose of reproducible builds is for others to verify that the binary they downloaded corresponds to the source | 11:20:09 |
| Makuru | Yeah | 11:20:18 |
| K900 | If you don't publish binaries, it doesn't do anything | 11:20:19 |
| K900 | And if you do, you don't need a checksum | 11:20:26 |
| Makuru | I guess, it could be useful to have the checksum from a secondary source, besides nixpkgs. | 11:20:57 |
| 19 May 2025 |
| Makuru | Does anyone know here, how to set arbitrary env vars with crane? | 20:18:36 |
|  oak 🏳️🌈♥️ changed their display name from oak 🫱⭕🫲 to oak. | 10:58:20 |
| oak 🏳️🌈♥️ changed their display name from oak to oak 🏳️🌈♥️. | 11:00:30 |
| 21 May 2025 |
|  WeetHet changed their profile picture. | 10:59:08 |
|  oddlama changed their display name from Malte to oddlama. | 17:42:00 |
|  @michael.zeagler:matrix.org joined the room. | 19:15:40 |
|  @bloxx12:matrix.org left the room. | 21:30:01 |
| 22 May 2025 |
 Toma | I'm mostly happy with fetchCargoVendor, though I worry about the impact on the cache:
every time a dependency of fetchCargoVendor changes, the non-FOD part needs to be re-cached, which can accumulate, and take up quite a lot of storage.
I wish there was a way to force hydra to not cache certain packages.
There is meta.hydraPlatforms = [], but AIUI it would only disable building it if it was directly built by hydra, but since it's a dependency of a package that is not disabled on hydra, it will get built and cached anyway...
I guess this could also be handled by content-addressed derivations...
Note: there are >2000 rust-based packages in nixpkgs currently
Question 1: What do you all think, how bad is this problem?
Question 2: How does one check how much storage a certain derivation takes up cached?
| 00:15:18 |
 emily | you can fetch the NAR | 09:00:12 |
| emily | shouldn't the non-FOD part mostly just be a bunch of symlinks? | 09:00:22 |
| emily | Alyssa Ross: do you have a preference between the diffs of https://github.com/NixOS/nixpkgs/pull/408710/files and https://github.com/NixOS/nixpkgs/pull/407790/files? they both fix pkgsStatic.buildPackages.rustc on Darwin, and they'll both leave some other cases unavoidably silently weird/broken (I think maybe slightly different cases between them). the original PR no longer depends on pkgsStatic. it's a bit more noisy but saves a rustc build. the other one is a smaller diff / fewer moving parts, but the ordering change is sort of unprincipled (albeit I think likely to make the build go through in strictly more cases than the status quo) | 09:02:30 |
 Alyssa Ross | I don't think I mind either | 09:06:36 |
| Alyssa Ross | I'd still really like to see the custom target specs eventually | 09:06:50 |
| Alyssa Ross | Consider them both acked | 09:06:59 |
| emily | me too, but cleaning up Rust is more work than I have the capacity for right now :( | 09:08:32 |
| emily | honestly we should really build std in a separate derivation always, I think | 09:08:40 |
| emily | and with the right platform triples | 09:08:43 |
| emily | rather than building a "rustc" that is actually just the target platform std | 09:08:54 |
| Alyssa Ross | IIRC @Ericson2314:matrix.org didn't think it was possible some time in the past | 09:10:08 |
| emily | why not? it's exactly what fastCross does, right? | 09:11:25 |
| emily | like fastCross could just not link in the rustc in installation phase, and swizzle around the targets that it passes, and then we could wrap them together later | 09:12:09 |
| emily | I guess the problem is that the non-cross compiler would still want to build the target std | 09:12:28 |
| emily | -Zbuild-std at least helps… | 09:12:39 |
