| 29 Jun 2025 |
 emily | or something | 17:29:22 |
 dramforever | oooh that would makes sense | 17:30:21 |
| dramforever | but then it also shouldn't hurt right? i want to refactor out the rustflags part into a function so we call it twice, once for host and once for target | 17:31:03 |
 Alyssa Ross | Redacted or Malformed Event | 17:34:57 |
| Alyssa Ross | if you set that to static you break proc macros | 17:35:01 |
| Alyssa Ross | so you never want that | 17:35:03 |
| dramforever | oof thanks for the catch | 17:35:40 |
| Alyssa Ross | getting crt-static to work right took a huge amount of investigation and iteration | 17:36:23 |
| Alyssa Ross | so I would be very careful changing anything about it | 17:36:39 |
| dramforever | yeah i'm gonna preserve this | 17:39:55 |
| dramforever | uh, idk if this is too cursed to worth supporting but is that one still broken if we cross from musl static to musl dynamic? | 18:10:12 |
| Alyssa Ross | You can't build on static platforms in Nixpkgs, to my knowledge | 18:13:21 |
| dramforever | good enough | 18:14:24 |
|  cybergui joined the room. | 21:14:10 |
| 30 Jun 2025 |
|  atagen joined the room. | 03:04:02 |
|  apyh joined the room. | 16:51:26 |
| apyh | yo dpc (migrated to @dpc:dpc.pw) , if you're still active on this account -
i'm trying to do some crane + maturin stuff and came across a 2 yr old reddit thread where you mentioned you've done some work with it.
do you have any public code showing how it works?
trying to shove a maturin build --offline into a craneLib.buildPackage is causing me to recompile things, and i can't get a nice deterministic name for the output wheel thru maturin. | 16:53:37 |
|  fxomt (lemmy.dbzer0.com) [he/him] changed their display name from fxomt to fxomt (lemmy.dbzer0.com) [he/him]. | 18:18:16 |
 undltd | When I update nixpkgs input in my flake.nix for a Rust package from 24.11 to 25.05, I get a hash mismatch on cargoHash, although I didn't change anything in Cargo.lock. Is that typical? I.e., cargoHash depends not only on Cargo.lock, but also on nixpkgs? | 19:36:02 |
 K900 | In this case yes | 19:36:44 |
| K900 | The FOD format has changed | 19:36:48 |
| Alyssa Ross | But it shouldn't ever happen again 🤞 | 19:37:28 |
| undltd | I see, thanks! | 19:38:15 |
| 1 Jul 2025 |
 niklaskorz | zed-editor had a huge build time increase on darwin in the past month (roughly takes twice as long now, 1h on my local Macbook vs 30min before that, 2 hours on hydra vs 1 hour before that), and I wonder if disabling thin LTO (enabled by upstream) + increasing cargo codegen units (set to 1 by upstream) could be a viable improvement? it’s getting kind of tedious to review updates at this point, so any suggestions would be appreciated... | 07:58:14 |
| niklaskorz | Linux build time also slightly increased, but only by about ten minutes on hydra, so that is still in an acceptable margin | 07:58:48 |
| niklaskorz | these are the profiles currently set by upstream’s Cargo.toml: | 08:01:13 |
| niklaskorz | [profile.release]
debug = "limited"
lto = "thin"
codegen-units = 1
[profile.release.package]
zed = { codegen-units = 16 }
[profile.release-fast]
inherits = "release"
debug = "full"
lto = false
codegen-units = 16
(not sure where they use release-fast) | 08:01:20 |
| Alyssa Ross | I think in general slow build times for improve runtime performance is what we want in Nixpkgs where people are mostly using Hydra binaries, but it would make sense for that to be standardised rather than following Cargo.toml for each package. | 08:02:33 |
| niklaskorz | hm I see, I just wonder where the build time increase could be coming from, the release profiles seem to be unchanged in the past months, so that’s at least not the origin | 08:03:54 |
| Alyssa Ross | You could consider overriding it for review and taking the risk on there not being divergence | 08:03:57 |
