| 22 May 2025 |
 emily | what kind of workarounds? | 12:23:28 |
| emily | we can get rid of the double layering if we remove the intermediate derivation, right? | 12:23:50 |
| emily | because it will always be the FOD | 12:24:09 |
| emily | or is the problem importCargoLock? | 12:24:13 |
| emily | i.e. having to distinguish the two | 12:24:39 |
 Toma | I guess fetchCargoTarball doesnt exist officially anymore | 12:25:26 |
| Toma | So we're more free to assume our own impl | 12:25:40 |
| emily | right | 12:26:46 |
| emily | I don't think the symlink and marker is a bad idea though, but maybe it's not necessary? | 12:26:54 |
| emily | wait, can't we just set a passthru on the FOD? | 12:30:17 |
| emily | to identify it at eval time? | 12:30:21 |
| emily | that doesn't break any hashes | 12:30:23 |
| emily | I guess the problem is that if you're using hooks they can't necessarily see cargoDeps until build | 12:30:37 |
| Toma | we wouldn't break hashes anyway, just APIs | 12:30:43 |
| emily | I guess I don't have a full picture of the problem | 12:31:01 |
| Toma | So the issue with the complete removal of the middle layer, is that then, we'll have fetchCargoVendor spit out our custom vendor-staging FOD, while other users may have assumed the cargoDeps is going to stay as something that is already the final vendor directory.
Now, if we had a marker in the FOD, we could just condition our logic to only trigger if we detect it.
In any case, the symlink solution doesn't sound that bad, if a little bit unnecessary...
| 12:35:50 |
| Toma | * So the issue with the complete removal of the middle layer, is that then we'll have fetchCargoVendor spit out our custom vendor-staging FOD, while other users may have assumed the cargoDeps is going to stay as something that is already the final vendor directory.
Now, if we had a marker in the FOD, we could just condition our logic to only trigger if we detect it.
In any case, the symlink solution doesn't sound that bad, if a little bit unnecessary...
| 12:36:21 |
 Adam Neverwas | Um...i have a kernel driver or what, patch, idk. I should have to add, because my notebook needs it. It's written in rust. | 17:08:15 |
| Adam Neverwas | Sec. | 17:09:38 |
| Adam Neverwas | However, don't you plan to add the asus-armory driver to the kernel? | 17:23:17 |
 K900 | Once mainline merges it, yes | 17:24:42 |
| K900 | Which so far is looking like it will take a while | 17:24:52 |
| Adam Neverwas | Thanks, asus-linux guys said it should reach somewhen, they dont know, didnt talk with main dev | 17:50:53 |
| K900 | Either way, the answer for "when will nixos have it" is "whenever mainline has it" | 17:51:34 |
| K900 | Which is right now 6.16 at the earliest | 17:51:40 |
| K900 | And I'm going to guess that they'll miss 6.16 | 17:51:46 |
| 23 May 2025 |
 John Ericson | In reply to @qyliss:fairydust.space
IIRC @Ericson2314:matrix.org didn't think it was possible some time in the past Hmm? | 03:21:26 |
| John Ericson | I definitely want to never build computers and standard libraries together | 03:21:39 |
| John Ericson | I would love to crate2nix rustc | 03:21:59 |
 Alyssa Ross | In reply to @Ericson2314:matrix.org
I definitely want to never build computers and standard libraries together I remember you thinking more work had to be done upstream in Rust to enable it | 08:35:10 |
