| 15 Feb 2026 |
 emily | why do we need to do this hash in the FOD btw? | 15:53:12 |
| emily | it seems like the same kind of reproducibility-load-bearing logic that makes us reject new complex FOD dep fetchers... maintaining an old zlib forever doesn't sound fun | 15:54:14 |
| emily | we've had to patch Chromium vendored zlibs for new compilers | 15:54:37 |
| emily | the fetchCargoVendor solution is to split the fetcher FOD and the input-addressed derivation that arranges it into the format Cargo accepts, is that not viable here? | 15:57:02 |
| emily | I guess we still might need the old zlib in that drv | 15:57:19 |
| emily | it's sort of only "nice to have" to check downloads against the lock file though if we have our own hash in Nixpkgs pinning it though right? | 15:58:24 |
| emily | (but admittedly introduces another TOFU step) | 15:58:37 |
 Randy Eckenrode | I have a fix: https://github.com/NixOS/nixpkgs/pull/490757. | 17:16:24 |
| Randy Eckenrode | Do I need to target staging-next? | 17:16:59 |
 Vladimír Čunát | Yes, please. | 17:17:41 |
| Vladimír Čunát | The issue plagues staging-next already. | 17:17:51 |
| Randy Eckenrode | I retargeted staging-next. | 17:20:12 |
| Randy Eckenrode | The only issue is Linux. I didn’t do the patches conditionally. Are we okay on Linux rebuilds currently, or do I need to make these conditional? | 17:20:42 |
| emily | should probably conditionalize and revert on staging | 17:28:34 |
| emily | (maybe I should put up my radical proposal to eliminate master-staging merge conflicts and get rid of the "guarded change + revert on staging" medium...) | 17:35:32 |
| emily | * | 17:35:38 |
| Vladimír Čunát | How would you get rid of that? | 17:40:50 |
| Vladimír Čunát | (without increasing rebuild amount in situations like we have with git now) | 17:41:07 |
