| 17 Jan 2026 |
 Marien Zwart | I don't think you can reasonably do this unless you can get the upstream build system to export its build graph, but unless that build system is something like bazel that also focuses on reproducible builds I doubt it's practical (...and the natural way of consuming that exported graph would be IFD so it still wouldn't work in nixpkgs) | 07:14:22 |
 eveeifyeve | In reply to @charles:computer.surgery
nix can't do incremental builds, it can only build complete derivations Wasn’t there a plan for this? | 13:23:07 |
 Theo Paris | It seems that mainline m1n1 doesn't build within nixpkgs, with the src overriden to this commit specifically https://github.com/HoolockLinux/m1n1/commit/19d973c873ad3f5396a23faaeb721b305b3d3cc1.
It complains about a missing vendored uuid dependency and a missing .cargo-checksum.json. I'm not sure how to properly fix this since it is not using buildRustPackage because it uses a makefile with mixed C/Rust sources | 21:01:07 |
| Theo Paris | * It seems that mainline m1n1 doesn't build within nixpkgs, with the src overriden to this commit specifically https://github.com/HoolockLinux/m1n1/commit/19d973c873ad3f5396a23faaeb721b305b3d3cc1.
It complains about a missing vendored uuid dependency and a missing .cargo-checksum.json. I'm not sure how to properly fix this since it is not using buildRustPackage because it uses a makefile with mixed C/Rust sources. Any ideas? | 21:01:21 |
| Theo Paris | I figured it out. Using cargoRoot = "rust" + cargoDeps + fetchCargoVendor seems to work. | 21:06:52 |
|  asa joined the room. | 22:10:04 |
| asa | i was looking through rust build infra in nixpkgs and found that lto is entirely opt in, which struct me as strange because lto=thin is the default for cargo and the rest of the rust ecosystem. is there a reason for this? | 22:15:04 |
| asa | i understand -O2 and no LTO by default for c/c++ packages since they could rely on UB that's broken by further optimization, but since the entire rust ecosystem defaults to -03 and thin lto (and rust programs usually don't violate the language's vm), it seems reasonable for that to be the default in nixpkgs as well | 22:18:17 |
 K900 | Rust ecosystem does not default to -O3 | 22:21:14 |
| K900 | Rust's optimization levels don't really map to C++ conventions | 22:21:23 |
| K900 | And even -C opt-level=3 is different from -O3 | 22:21:39 |
| K900 | And no, Cargo does not default to thinlto | 22:22:24 |
| K900 | https://doc.rust-lang.org/cargo/reference/profiles.html#release | 22:22:24 |
| K900 | [profile.release]
opt-level = 3
debug = false
split-debuginfo = '...' # Platform-specific.
strip = "none"
debug-assertions = false
overflow-checks = false
lto = false
panic = 'unwind'
incremental = false
codegen-units = 16
rpath = false
| 22:22:39 |
| asa | oh I see | 22:28:03 |
| asa | sorry for the misunderstanding, I'm not sure where I read the thin lto by default thing | 22:28:31 |
| asa | the profiles page you linked to does say that lto=false is different from lto=off though, and that lto=false enables "thin local lto" | 22:29:54 |
| K900 | That should be our default as well, as I don't think we explicitly pass lto=false? | 22:39:17 |
 whispers (it/fae) | i think we just inherit whatever upstream has profile.release set to? | 22:42:20 |
| asa | probably is? idk how rustc deals with default options | 22:42:21 |
| whispers (it/fae) | * | 22:42:42 |
| whispers (it/fae) | * | 22:43:12 |
| asa | In reply to @k900:0upti.me
And even -C opt-level=3 is different from -O3 never thought about this but I guess it's a good thing rust release builds don't use fast-math by default... | 22:44:11 |
| asa | i looked into this more and it seems thin local lto is redundant with codegen-units=1 anyway (and rustc disables thin local lto if codegen-units=1 and the lto level is unspecified)
buildRustCrate has defaultCodegenUnits ? 1 since the derivation doesn't allow for rebuilds on a higher granularity than per-crate anyway
| 23:28:51 |
| 18 Jan 2026 |
 debtquity | dynamic derivations | 00:21:58 |
| debtquity | ? | 00:21:59 |
