| 9 Apr 2025 |
 roberth | The only breakage is moving the location of the header files, so there's no behavioral change, and no risk to stability associated with that | 10:53:07 |
 emily | my personal understanding was also that 2.28 was the intention after the last long discussion in here, I'm just pointing out that the release manager expressed in here yesterday that it was unexpected/not communicated clearly in her view. I'm not the one to talk to here :) (the comments on GitHub were ambiguous and edited a bunch and most people probably did not read the entire discussion in this room, which I don't think the result of got summarized in any Nixpkgs space) | 10:56:00 |
| emily | (FWIW, I did strongly advocate for the header change while trying to use the C++ API with 2.26, so I have no opposition to it in general as a change on its own merits) | 10:56:35 |
 leona | I can only say that I personally don't have much insight into the development of Nix and can't see how much breakage potential a change (like this) can have. And the communication around it is complicated. Personally, I just wish there was better communication. | 11:03:59 |
| leona | I have just seen the breakages in infra and they have worried me... | 11:04:42 |
 Sandro 🐧 | In reply to @leona:leona.is
I have just seen the breakages in infra and they have worried me... Some packages where pinned and the nixpkgs-review showed that only nixStatic failed | 11:33:43 |
| Sandro 🐧 | The only thing that I noticed myself since updating from 2.24 to 2.28 was that the override interface is different | 11:34:12 |
| roberth | The override interface should be very similar now that we've made it a single derivation again, unless you were doing something make related in 2.24 | 11:38:54 |
| roberth |
=2.29 will have the split packaging
| 11:39:35 |
| roberth | * >= 2.29 will have the split packaging | 11:39:47 |
| Sandro 🐧 | Then I probably haven't bumped my nixpkgs to that point yet | 11:41:25 |
| roberth | nixVersions.git has the split packaging if you happen to want to use that | 11:43:04 |
 p14 | Given a content addressed derivation, how might I determine if it is already built in a remote store? Is there a cheap way to do this? | 17:00:14 |
 Mic92 | This is because the hydra overlay upgrades nix on stable nixos, | 17:24:26 |
| Mic92 | That's not ideal and should be fixed in hydra. | 17:24:49 |
| Mic92 | * This is because the hydra overlay upgrades nix when used on stable nixos (what we use for NixOS infra) | 17:27:46 |
 John Ericson | I have also made PRs for the collatoral damage with infra | 17:54:18 |
| John Ericson | and a bunch of other projects linking nix | 17:54:24 |
| John Ericson | I suspect we can remove the nix_2_24 pins quite quickly | 17:54:37 |
| emily | 25.05 will still ship with 2.24 available right? | 17:56:42 |
| Mic92 | Probably. I already dropped other versions that we don't want to support. | 18:39:20 |
| emily | 2.24 being available is what was communicated in https://github.com/NixOS/nixpkgs/issues/393359#issuecomment-2766317573 | 18:45:34 |
| Mic92 | I don't expect that we will backport any bugfixes to this version, only security related stuff. | 19:02:56 |
| 10 Apr 2025 |
| John Ericson | Eelco: I think for the store changes we should get pure eval off the filtering store pronto? | 17:26:50 |
| John Ericson | it would be nice to just use the mounted store | 17:26:58 |
| John Ericson | and mount individual store paths as they become whilelisted | 17:27:11 |
| John Ericson | and just use the filtering store for restricted eval | 17:27:22 |
| 11 Apr 2025 |
 tomberek | nixStatic almost works, just needs:
nixStatic = pkgsStatic.nix.override (attrs: {
enableDocumentation = false;
});
Not sure if there is a conditional misfiring in the new packaging expressions.
| 07:21:27 |
|  kevincox left the room. | 11:50:56 |
| roberth | pkgsStatic.nixVersions.git.doc works | 12:42:57 |
