| 8 Jan 2026 |
 guiniol | that should figure out all the corrupted paths? | 21:57:39 |
| guiniol | (got interrupted, I'll have to get back to that tomorrow) | 22:18:13 |
|  pltrz set a profile picture. | 23:49:57 |
| 9 Jan 2026 |
| pltrz changed their profile picture. | 00:00:13 |
| guiniol | Getting back to this: after a few tries where `nix-store --verify --check-contents --repair` complained but didn't repair anything, I realised it would work better with a `sudo` in front. It's currently rebuilding stuff | 08:01:39 |
| guiniol | Took a while because I forgot to add cache.nixos.org as a substituter initially but now it's all done and it all looks good. Thanks everybody! | 08:36:30 |
 donn | anyone know what to do when nix run 'nixpkgs#nixpkgs-review' -- pr --post-result 477797 just posts "nothing to build" | 12:58:52 |
| donn | * anyone know what to do when nix run 'nixpkgs#nixpkgs-review' -- pr --post-result 477797 just prints "nothing to build" | 12:59:11 |
 K900 | Why would you need to nixpkgs-review a PR that adds a singular package | 12:59:31 |
| donn | just to prove it builds on aarch64-darwin before the CI gets to it | 13:00:09 |
| K900 | Just build it manually? | 13:00:33 |
| donn | is nixpkgs-review for packages with a lot of dependencies? genuinely asking i may have a mistaken impression about it | 13:01:56 |
| donn | * is nixpkgs-review for packages with a lot of dependents? genuinely asking i may have a mistaken impression about it | 13:02:10 |
| K900 | nixpkgs-review is for testing everything that depends on the package still builds | 13:02:37 |
| donn | gotcha | 13:02:45 |
| K900 | It makes no sense when you're adding a leaf package | 13:02:50 |
| K900 | Except the comments look pretty and some people have github actions set up to spam that shit on their PRs | 13:03:01 |
| K900 | Which is bad, by the way | 13:03:05 |
| donn | oh. darwin wasn't even in the supported systems. that would do it | 13:07:46 |
 sterni | Is there prior discussion on making the default Nix version for Nixpkgs configurable I can read up on? This is obviously a long standing problem since you always wind up with multiple Nix versions if you don't stick to pkgs.nix even if it's not strictly necessary (due to use of the API etc.) and more urgent with Lix existing now… | 17:44:16 |
| K900 | This was never a thing I believe | 17:45:38 |
| K900 | Well technically that's why nixForLinking was introduced | 17:45:47 |
| K900 | But eventually we'll probably see things targeting the Lix APIs instead | 17:46:12 |
| K900 | Which means there will have to be a lixForLinking I guess? | 17:46:24 |
| K900 | But like fundamentally you can't just overlay { nix = final.lix } and have that work | 17:46:38 |
| K900 | Because the APIs have diverged enough | 17:46:43 |
| sterni | what I was thinking about to begin with was the low hanging fruits, i.e. just stable-ish CLI use. E.g. if you have pkgs.nix in your wrapper for prefetch scripts etc. | 17:49:15 |
 raitobezarius | for flags, we are not planning to break existing CLI flags (except if completely buggy / no usage / etc.) in existing CLIs | 17:49:44 |
| sterni | We kind of need a config option for a mostly compatible use of Nix precisely because you can't overlay pkgs.nix properly anymore. | 17:49:49 |
| raitobezarius | we would do nix4 for the new CLI | 17:49:49 |
