| 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 |
| midischwarz12 | So for some packages, yes, we do support multiple versions b/c we need to in the current version of nixpkgs (clang, python, gcc, glibc, etc). But for most packages, that is very unnecessary to maintain the current round of packages in nixpkgs | 03:28:01 |
| tavinator | Thanks midischwarz12 I guess I am just looking for a framework to approach the problem. I would not have minded contributing the code to nixpkgs for packaging specific old versions of this or that. But it was pointed out to me that it would have an infeasible impact on Hydra -- a piece of the puzzle I wasn't seeing until now.
override the package with a different version of source.
Sounds like what I am looking for... this means using "overlays" then?
| 09:22:08 |
|  0x9t joined the room. | 09:55:46 |
| John Ericson | @lovesegfault:matrix.org: we make tests require a new enough daemon version all the time | 14:04:52 |
| John Ericson | If you grep for DaemonVersion I think you'll see it | 14:05:28 |
 justinrestivo | Hello! Any chance there's a spec about the different Fields provided for each ActivityType in the nix logger? Right now to answer this question I'm grepping the nix codebase for each ActivityType and looking at the arguments to the Activity::Activity constructor to infer the field types and number (if any exist). I'm wondering if there's an easier/more canonical way to do this. | 15:30:35 |
| midischwarz12 | You overlay when you want to stitch multiple overrides together or want the package that's available across your entire package set such as nixpkgs. What you're really desiring is just a single override and probably not overriding every package that consumes this package as a dependency. So an overlay would be unnecessary | 16:39:36 |
| midischwarz12 | * You overlay when you want to stitch multiple overrides together or want the override available across your entire package set such as nixpkgs. What you're really desiring is just a single override and probably not overriding every package that consumes this package as a dependency. So an overlay would be unnecessary | 16:40:03 |
| midischwarz12 | * You overlay when you want to stitch multiple overrides together or want the override available across your entire package set such as nixpkgs when used as a dependency. What you're really desiring is just a single override and probably not overriding every package that consumes this package as a dependency. So an overlay would be unnecessary | 16:40:25 |
| midischwarz12 | I think overlays are often reached for a bit too early and people should take note more often that this ruins a lot of the reproducible nature of nix. Your nixpkgs will no longer be the same as everyone else's when you use an overlay | 16:41:25 |
