| 1 Apr 2025 |
 jade_ | * we had to do effectively the same change in lix 2.93 because it turns out it was ill-designed from the beginning and the previous behaviour was severely broken in a very hard to fix way that caused eval to be nondeterministic (which seemed like a bigger sin).
the issue i have is not that the output path changed; i don't particularly care about that; but it needs to be in the Breaking Changes section and done on purpose like it is in lix. | 01:45:35 |
| jade_ | btw now that we fixed nixpkgs to not break when you put an overlays.default shaped overlay that overrides pkgs.nix, you should write an equivalent document to https://wiki.lix.systems/books/lix-contributors/page/lix-beta-guide | 01:48:19 |
| jade_ | this is the foundation of lix's QA processes and is one of the main reasons, besides generally immediately prioritizing regressions on main, that lix has relatively few bugs. | 01:52:40 |
| jade_ | * this is the foundation of lix's QA processes and is one of the main reasons, besides generally immediately prioritizing regressions on main when they are found, that lix has relatively few bugs. | 01:52:54 |
 fzakaria | what's new nix ? | 02:45:45 |
| jade_ | it's like updog
(i assume they actually mean the master branch) | 05:28:09 |
 Robert Hensing (roberth) | I'm a fan of IFD too, but I don't see how it helps here | 08:09:11 |
| Robert Hensing (roberth) | goes to show that fetchTree and its tests are in a bad state and needs to be experimental for another while, as implementers (not just us) figure out what the right behavior should even be. It sucks | 08:13:04 |
| Robert Hensing (roberth) | I agree that breaking changes should be in the release notes, also for experimental features | 08:14:02 |
 leona | This seems about right.
John Ericson: I understand your thoughts and constraints. I'm not an expert for the packaging for nix packaging tho. By assuring me that you will be available for fixing broken things, I'm okay with updating nix before the first freeze period (2025-04-09). I trust you with your judgement. Also, I will try nix 2.27 as soon as packaging is ready-enough in nixpkgs.
I'm even more happy when you (as in the team) improves the packaging (in the ways emily, ElvishJerricco and others already mentioned), but not change it in major ways after the actual freeze period (2025-04-23). After branch-off, you can of course test changes in packaging and if no breakages occur, also backport them.
Thanks for the open communication style.
| 08:36:54 |
| leona | I think it would also be good to backport 2.27 to 24.11 (inside nixVersions). That way people on 24.11 can also test compatibility. | 08:40:39 |
|  Hemant Baviskar set a profile picture. | 09:30:34 |
 p14 | I am trying to use nix-store —load-db with a closureInfo registration file. In the closure I put a fixed output deviation for nixpkgs itself: I am baking a machine image with nixpkgs available.
One problem though is I can’t easily get my hands on the nixpkgs path. I tried to use fetchClosure, but this doesn’t work on a machine whose nixpkgs path was registered using nix-store —load-db. So it fails when built using the machine image. ‘Nix path-info’ shows that the ca:fixed: metadata is missing, which results in fetchClosure saying that it is input addressed but inputAddressed = false.
Should the ca metadata be missing in this scenario? Is there a way to put it there? | 13:09:32 |
|  Sandro 🐧 changed their display name from Sandro 🐧 to Sandro 🐧 [c3d2]. | 13:58:06 |
| Sandro 🐧 changed their display name from Sandro 🐧 [c3d2] to Sandro 🐧. | 13:59:29 |
 toonn | I don't really follow the reasoning here, https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2767289529 The build system for Nix 2.24 is already packaged, no? So why would 25.05 sticking to that version of Nix mean having to maintain two build systems? GHC very intentionally did a gradual shift and the Make based build system hasn't been supported as of 9.6.1 from 2023-03-10 latest | 15:37:04 |
