| 22 May 2025 |
 emily | fair | 12:16:26 |
 Toma | In reply to @tomasajt:matrix.org
It is compressed, because it is how they are downloaded, and it is also not uncompressed so that we don't have file system case sensitiveness bite us with different hashes Also, just in general, the goal was to have the dumbest possible FOD logic so that under no circumstance will the hash break. | 12:16:29 |
| emily | I think moving it into a hook of the actual build would be good? | 12:16:35 |
| emily | that way nothing gets persisted | 12:16:47 |
| Toma | It would be better. Though we'd need some interesting workarounds...
An interesting option would be to have the non-FOD part jus be a directory with a symlink to the FOD and a marker file that the hook can detect. | 12:19:40 |
| Toma | * It would be better. Though we'd need some interesting workarounds...
An interesting option would be to have the non-FOD part just be a directory with a symlink to the FOD and a marker file that the hook can detect. | 12:19:59 |
| Toma | Ideally we'd get rid of the double layering, but I don't know how viable that is really at this point... (It's not backportable, there are no marker files in the FOD part, except maybe the way the directories were named) | 12:22:39 |
| 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 |
