| 25 Mar 2025 |
 emily | we can just bump to HEAD | 13:17:56 |
 K900 | Yeah that's what I'm saying | 13:18:08 |
| emily | I really do not think we want to ship a tool using pinned Kubernetes dependencies from 2019. https://github.com/saschagrunert/kubernix#what-is-inside | 13:18:36 |
| emily | like even if this does still function with current Nixpkgs which I am somewhat sceptical about, it's plain dangerous | 13:18:55 |
| emily | https://github.com/saschagrunert/kubernix/issues/1204 declared unmaintained upstream | 13:19:19 |
| emily | release version is apparently broken: https://github.com/saschagrunert/kubernix/issues/720 | 13:20:01 |
 Toma | https://github.com/NixOS/nixpkgs/pull/393078
https://github.com/NixOS/nixpkgs/pull/393071 | 13:39:59 |
| emily | https://mdsteele.games/syzygy/ wow, Rust game from 2016, very early! | 13:43:13 |
| emily | https://github.com/yxdunc/lipl/commit/f57e702e6d4789cb0c16521d45a8ae2c4787213d uh, hm | 13:45:33 |
| emily | ok, apparently this quotes in the "sane" way | 13:46:15 |
| emily | did we settle on a plan for useFetchCargoVendor? IMO the best route would be to make it default to true, to give an eval error on false, and to detect a fetchCargoTarball FOD in the build and reject it with a migration explanation | 13:47:31 |
| emily | since all the FODs are broken by Rust 1.85, no existing user from 24.11 is correct/safe anyway | 13:48:00 |
| emily | so we should ensure that people with cached versions of them in their store aren't "tricked" into thinking their package hasn't broken | 13:48:14 |
| emily | also, it would be really annoying to ship with a state where you have to manually set it true for every Rust package | 13:48:33 |
| Toma | yes, for sure, remove it after the branchoff
but what about 25.05, I guess we will still need to have that? | 13:49:42 |
| emily | no I meant before the branch-off | 13:50:13 |
| emily | 25.05 is what is going to break everyone | 13:50:20 |
| Toma | hmm I see | 13:50:28 |
| emily | people will have existing FOD hashes, they'll build their package again, and it will "work" because it's in the cache | 13:50:29 |
| emily | but it will not reproduce | 13:50:32 |
| emily | having the broken thing be the default is silly, so we should default useFetchCargoVendor to true. but then we do need code to detect the old FOD format so we can reject it | 13:50:49 |
| Toma | it will not fetch from the cache because the name is different | 13:50:56 |
| emily | as in, defaulting useFetchCargoVendor = true would invalidate the cache even with the same hashes? right, makes sense | 13:51:19 |
| emily | could we do anything to detect old hashes? | 13:51:42 |
| emily | I guess probably not. so maybe it is okay for them to just fail with a mismatch | 13:51:57 |
| Toma | yea | 13:52:07 |
| emily | I was hoping we could print out a more useful message so people don't just go "why is my hash invalidated??" but I guess people are somewhat used to hashes changing anyway :P | 13:52:31 |
| Toma | is the breaking rust version backported btw? | 13:52:43 |
| emily | ok, then I guess we can just do useFetchCargoVendor ? true, assert lib.assertMsg useFetchCargoVendor "buildRustPackage: useFetchCargoVendor is now the only option" | 13:53:14 |
| emily | we never backport Rust versions as rustc | 13:53:28 |
