| 10 Oct 2025 |
 John Ericson | :) | 21:15:54 |
 Sergei Zimmerman (xokdvium) | Oh no why | 21:18:54 |
| John Ericson | Sergei Zimmerman (xokdvium): added a commit to make it a set | 21:19:15 |
| John Ericson | the inner thing | 21:19:21 |
 lovesegfault | Sergei Zimmerman (xokdvium): RE https://github.com/NixOS/nix/pull/14209#discussion_r2422146488
I can make the change to include the s3 params in the cacheKey
| 21:56:29 |
| lovesegfault | shouldn't be hard | 21:56:30 |
| Sergei Zimmerman (xokdvium) | I think it should be done somewhat centralized and with a common abstraction for the stores. This is a pre-existing problem already for the s3 store thoughh | 21:57:18 |
| Sergei Zimmerman (xokdvium) | * I think it should be done somewhat centralized and with a common abstraction for the stores. This is a pre-existing problem already for the s3 store though | 21:57:21 |
| lovesegfault | ACK | 22:04:18 |
| lovesegfault | pushed a new rev of https://github.com/NixOS/nix/pull/14209 if you could take another look :) | 22:06:30 |
| 11 Oct 2025 |
| John Ericson | Sergei Zimmerman (xokdvium): oh no c97b050a6c212d0b748303080b5604309b7abdce is this the thing that does the closure that I guess is no good | 00:27:50 |
| John Ericson | nevermind maybe not the same bug | 00:27:54 |
| John Ericson | or at least that one is also a problem | 00:27:59 |
 fzakaria | any good issues to try and tackle?
Sergei Zimmerman (xokdvium) i guess you figured out that weird postgres one | 02:26:09 |
| fzakaria | i'm not sure how you narrowed it down to path length; i missed that part of the RCA | 02:26:20 |
|  perra23 joined the room. | 04:38:38 |
| lovesegfault | Hot off the press: https://github.com/NixOS/nix/pull/14218 | 18:43:30 |
| lovesegfault | Hot off the press: https://github.com/NixOS/nix/pull/14219 | 19:11:00 |
| John Ericson | nevermind, that is just a fairly innocuous boolean field | 20:07:03 |
| John Ericson | so it won't cause "that bad" of UB | 20:07:09 |
| John Ericson | and we just saw the issue from the first commit | 20:07:15 |
| John Ericson | so I am back to my "one bug, two symptoms" theory | 20:07:31 |
|  midischwarz12 joined the room. | 20:27:33 |
 tavinator | nix, or nixpkgs, does not really have a concept of multiple extant versions of a package. i see this worked around in cases of overwhelming importance with e.g. python312, python313 etc.
but in general if you need an older version of package XYZ you are dealing with a git history search and pinning to a commit
there is no fundamental reason why nixpkgs HEAD could not contain the logic for multiple versions of package XYZ
so - to start from the beginning - is there something in nix itself that keeps me from e.g. writing opentofu-1.6.3 or opentofu==1.6.3 or whatever as the package i want to install?
background: i want to introduce nix devshells in a company where this kind of situation happens all the time (i.e. some project has to be checked out from github and worked on using a list of software versions that is both brittle and not recent)
| 22:35:31 |
| 12 Oct 2025 |
| lovesegfault | John Ericson, Sergei Zimmerman (xokdvium) why do we run functional tests against an old version of Nix? It's causing my new multiple-outputs cycle detection functional tests to fail under nix-daemon-compat-tests | 00:05:50 |
| lovesegfault | Should I make the test agnostic to the old version or just not have it run when in compat tests? | 00:06:10 |
| midischwarz12 removed their profile picture. | 02:45:01 |
| midischwarz12 set a profile picture. | 02:45:11 |
| lovesegfault | (i made the test agnostic) | 02:46:01 |
| midischwarz12 | Yea, you're not technically wrong that packages on the same version of nixpkgs could have different versions. But you'd have to have a package for every version of its dependencies as well. At which point, it is usually easier to dig through git or just override the package with a different version of source. That said, you'd have to do the same for its dependencies as well. But it's much easier to push this unto the user than force all of the nixpkgs maintainers to keep every package up to date. That said, I do agree that there should be an easier CLI interface to dig through nixpkgs and find necessary package versions or versions within requirements such as version ranges | 03:26:54 |
