lixPackageSets.lix_2_9{1,2}: drop

[RaitoBezarius]

## Lix 2.90 series

Lix 2.90 is vulnerable to critical CVEs, known vulnerabilities warnings
were emitted. Users should have migrated by then.

There's no reason to keep it in-tree anymore.

This was already dropped in a previous PR.

Lix 2.91 series

Lix 2.91 has been one of our historical LTS releases given that the Lix
2.92 series suffered from an unfortunate curl upstream bug and it took a
lot of time to fix it, in addition of other papercuts with SSH
connections.

Lix 2.91 is the last release not containing the asyncification work we
started.

Lix 2.92 latest minors sorted out these issues and possess bits of
asyncification, it's a much easier target for HEAD cherry-picks because
it also renamed the directory src/nix to lix/.

Plans are the following:

• Lix 2.92 is skipped.
• Lix 2.93 is the new stable.
• Lix 2.94 is the next stable.

Once NixOS 25.11 releases, Lix 2.92 will be dropped.

Lix 2.92 suffers from slight performance issues that are made up in Lix
2.93, your mileage may vary.

Lix 2.92 series

Lix 2.92 is also dropped as we concluded that it is safe to skip over to 2.93 directly which we consider to be strongly stable. This simplifies maintenance for the Lix team.

If you are a user that discovers major regression in your workflows that worked in Lix 2.92, please contact or reach out the Lix team.

Things done

• Add aliases for dropped packages
• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[alois31]

There are quite a few conditionals for older versions in common-lix.nix which could be removed along with the old versions. Similar for the nix-eval-jobs source which can always be assumed to be the same as lix if you end up dropping everything below 2.93.

[RaitoBezarius]

I didn't drop them on purpose to let users reintroduce those versions without breaking the build code, on the next release, I'd drop them. Le ven. 18 juil. 2025, 17:16, alois31 ***@***.***> a écrit :

…

*alois31* left a comment (NixOS/nixpkgs#426260) <#426260 (comment)> There are quite a few conditionals for older versions in common-lix.nix <https://github.com/NixOS/nixpkgs/blob/c4ea7e484bd1de914d3b75481d6457bb06c6144e/pkgs/tools/package-management/lix/common-lix.nix> which could be removed along with the old versions. Similar for the nix-eval-jobs source which can always be assumed to be the same as lix if you end up dropping everything below 2.93. — Reply to this email directly, view it on GitHub <#426260 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACMZRGE7Z6RETM3LVL5MZL3JEFT3AVCNFSM6AAAAACBZNX7TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBZHAZDAOJVGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[wolfgangwalther]

After the discussion in #433057, I believe we should not drop Lix 2.91, yet, at least from a Nixpkgs perspective. Imho, this should only happen in 26.05, not in 25.11. We don't have a formal policy for this, yet, but I think it's reasonable to expect to be able to update from NixOS 24.11 to NixOS 25.11, because they overlap: There is a period where NixOS 24.11 is still supported and NixOS 25.11 is already being developed.

To be able to verify that NixOS 25.11 evaluates with a NixOS 24.11 running Lix, we need to have Lix 2.91 still available in NixOS 25.11 - that's the reasonable amount of effort we can take to run it in CI etc.

Since 24.11 was on 2.91 by default, and also doesn't have any newer Lix version, it would help to keep 2.91 until 26.05 branch-off. Of course, this only makes sense if it's also still supported upstream and doesn't become insecure.

I think the fact that 2.91 is still the default in NixOS 25.05 is another argument for it.

cc @emilazy

(Edit: Note, this is intended to start the discussion about such a policy - how long should we expect Lix versions from one release to be in following releases? I said two cycles, the general answer could also be one cycle only, ofc)

[wolfgangwalther]

(Edit: Note, this is intended to start the discussion about such a policy - how long should we expect Lix versions from one release to be in following releases? I said two cycles, the general answer could also be one cycle only, ofc)

To make some concrete proposals:

1. Default +2

Each NixOS release's default .stable Lix version should be kept for two more NixOS releases.

Consequences (assuming 2.93 becomes the default in 25.11):

• Keep 2.91 for 25.05, 25.11 and 26.05, drop it in 26.11.
• Keep 2.93 for 25.11, 26.05 and 26.11.

2. Latest +2

Each NixOS release's .latest Lix version should be kept for two more NixOS releases.

Consequences:

• Keep 2.91 for 24.11, 25.05 and 25.11, drop it for 26.05.
• Keep 2.93 for 25.05, 25.11 and 26.05.

3. Default +1

Each NixOS release's default .stable Lix version should be kept for one more NixOS release.

Consequences:

• Keep 2.91 for 25.05, 25.11, drop it in 26.05.
• Keep 2.93 for 25.11, 26.05.

4. Latest +1

Each NixOS release's .latest Lix version should be kept for one more NixOS release.

Consequences:

• Keep 2.91 for 24.11, 25.05, drop it in 25.11.
• Keep 2.93 for 25.05, 25.11.

---

This PR, dropping 2.91 right now, would be at the bottom of this list in "Latest +1". I think that might not be enough. My proposal above is "Latest +2", I think. Maybe both of "Latest +2" and "Default +1"?

[llakala]

I think it's more important to base our deprecations on what was stable. Doing a quick Github search, there are currently 476 uses of pkgs.lix and only 101 uses of lixPackageSets.latest. Anyone using latest is opting-in to a version that may not be stable yet.

I don't want to state specific support windows, because I think that's up to the Lix team. My core opinions are:

• Versions that were previously stable should stick around longer. Before removing a version, there should first be a deprecation notice (exceptions can be made for CVEs).
• A version remaining in nixpkgs implies that the Lix team is still providing security fixes for it. If they're not, it should be removed.
• How long old versions persist should reflect how much work the Lix team feels it's able to put into maintaining old versions. If the team feels they can only support old stable versions for one release, then that should be the standard. We don't want bad versions persisting due to overly-optimistic support windows.

Personally, I don't think 2.91 should be removed entirely yet. I'd prefer a deprecation warning for a single release, which reflects that it's only receiving security patches.

[lf-]

Ideologically:

• Lix does not maintain stable releases unless there is a good excuse to use one (e.g. known regressions, for which we have had a horrible few months, mostly due to a series of heisenbugs in external libs and a macOS kernel bug).
  • The code being unmaintained may be okay, but we do not intend to do major security fixes to releases we don't maintain because it is burnout fuel (i.e. the last CVE situation should not repeat)
• That is to say, if we are not screwing up, it is always possible to upgrade lixPackageSets.stable during a nixpkgs stable release, because, to the extent that there are breaking changes, they are intended to always be visible at eval time and we do our absolute best to not change the semantics of anything used by automation.
• The only reason lixPackageSets.latest is different than lixPackageSets.stable is because of known regressions in releases which forced us to maintain older versions. If there were no regressions, these would be the same thing.

So far in Lix development, we've not really had a release that had significant unknown defects in it upon release since we have pretty strong QA on the main branch. Maybe we can keep stable-1 around with minimal maintenance in case something gets really blown up, but backporting further than the current stable means any of those old stable releases do not receive any meaningful QA.

[emilazy]

(What macOS kernel bug, btw?)

[wolfgangwalther]

That is to say, if we are not screwing up, it is always possible to upgrade lixPackageSets.stable _during a nixpkgs stable release.
[...]
If there were no regressions, these would be the same thing.

OK, so let's assume that latest Lix is always backported and becomes the new stable on the release branch as well. Then the above mentioned strategies collapse into two strategies: +1 or +2.

So far in Lix development, we've not really had a release that had significant unknown defects in it upon release since we have pretty strong QA on the main branch. Maybe we can keep stable-1 around with minimal maintenance in case something gets really blown up,

Yeah, if that's only ever going to be an unintended thing, then +1 should be enough. Just to make sure we can verify Nixpkgs still evaluating properly for those who are not on the latest stable NixOS version, yet.

In practical consequences this means:

• Make Lix 2.93 the new stable.
• Backport this change to NixOS 25.05.
• Then Lix 2.91 can be dropped immediately in unstable.
• Lix 2.91 can not be dropped from NixOS 25.05, though, because it is still latest/stable in NixOS 24.11.

This means Lix 2.91 would still have to be supported until November. At least basic support as in: If there is anything security critical coming up, this would be fixed, so that the package doesn't need to be marked insecure.

Does that make sense?

[RaitoBezarius]

Given that I have been in charge of the previous security issues, I think it's plausible we can do security until November but 2.91 is a highly expensive release, so November ought to be the utmost maximum support in nixpkgs IMHO.

[emilazy]

@wolfgangwalther So, I’m not convinced that keeping the previous default in the package set for the next release is that meaningful.

In particular, what we really care about for version upgrades is bug‐compatibility with the entire closure used in that version. For instance, the Lix and Nix decision was that the behaviour relied upon by our lib tests before #433710 was a bug and essentially undefined behaviour, and we’ll soon bump the toml11 version to one that breaks it. But there was no test for this behaviour previously, so if not for the test for the experimental TOML timestamps feature (which broke from the toml11 version update for unrelated reasons), you could silently get different evaluation behaviour depending on what version of toml11 you linked against – and indeed, I believe Nix has maintained support for the previous toml11 version, so the evaluation behaviour will in fact depend on this in practice, such that the same Nix version could fail to evaluate an expression with one dependency closure but not another. If that kind of thing was more load‐bearing for Nixpkgs evaluation… well, that would be unfortunate because it raises bigger questions around evaluation compatibility, but my point is that pinning an individual version doesn’t guarantee the properties you want by itself, when all of its dependencies are changing – and in particular you might not notice when you start depending on something like this. See also: changes in std::regex implementations and so on.

Additionally, I don’t think the Nix team’s version support policy really enables the kind of verification you want, either; a strict reading is that the default version from the previous stable Nixpkgs goes EOL as soon as the next stable Nixpkgs is released, so by our own guidelines we should be dropping the previous default ahead of the enxt Nixpkgs release, as it won’t be supported throughout its lifetime.

So, if you want to truly verify upgrade compatibility properties in CI, I don’t think there’s any way out of simply pinning the Nixpkgs release that you want to verify against, and pulling Nix implementations out of that. The alternative is to maintain that property reactively rather than proactively, fixing it when issues are reported, which I personally feel is fine.

Therefore, it’s my opinion that it doesn’t really matter what versions we have in master, and the Lix team can be free to drop basically whatever they want (although of course it would be very inconvenient to drop security support for the default version on the current Nixpkgs stable release, still). I also think that backporting a bump of the default is risky, not because it’ll definitely include known breaking changes, but simply because it inevitably means exposing users on stable to significant internal changes that are somewhat likely to cause regressions at least some of the time, or bug fixes that break their spacebar‐heating workflow. I’m not saying we should never do it, but in the absence of major bugs or a lack of security support I think it’s best to avoid getting into the habit.

[wolfgangwalther]

A while ago, I came to realize that we'd have to use another pinned nixpkgs in CI for my proposal in #426260 (comment) anyway: If 2.91 is dropped from master, but CI always pins that, we can't test it. So even if it was kept in 25.05, we couldn't use it. Thus, we'd have to use two pins: One to pull the older versions from 25.05 and one to pull the newer versions from unstable. I haven't come around to implementing that, yet.

This is already half-way to what you're proposing. Of course, it makes much more sense to confirm that the whole of NixOS 24.11 can evaluate Nixpkgs 25.05, and not just any specific Nix version, which is also packaged in that release. The good thing is, that this also works around the unsupported-versions-are-marked-as-insecure problem, because these old Nix versions would not be marked insecure on an EOL branch anymore. Thus, we can just do this:

• Confirm that master evaluates fine with a pinned nixpkgs 25.05.
• Confirm that release-25.05 evaluates fine with a pinned nixpkgs 24.11.

Doing it this way means that both Nix/Lix can freely update however they want, because the responsibility to keep Nixpkgs compatible is entirely within Nixpkgs.

[wolfgangwalther]

Did not look at the diff, just confirming that I have no objections for these drops on master.

[emilazy]

Should we make 2.93 the default rather than 2.92? AIUI it fixes perf regressions that 2.92 had or something?

[lf-]

Should we make 2.93 the default rather than 2.92? AIUI it fixes perf regressions that 2.92 had or something?

yes. 2.93 has no known regressions over 2.92. both have a cache query perf regression over 2.91, fixed in 2.94.

[RaitoBezarius]

Should we make 2.93 the default rather than 2.92? AIUI it fixes perf regressions that 2.92 had or something?

It's already the case in this PR.

[emilazy]

Sorry, I somehow missed that. LGTM, but aliases would be nice.

[RaitoBezarius]

I added throw aliases.

[wolfgangwalther]

CI likes it* and so do I.

* except for treefmt, you'll need to run that once more ;)

[RaitoBezarius]

I should have satisfied treefmt, not sure this will keep the properties of every commit builds though because nixfmt wants to move too many things at a time visibly.

[magneticflux-]

@RaitoBezarius I think the patch from #413730 / https://gerrit.lix.systems/c/lix/+/3731 got inadvertently dropped with your last force-push, causing the build to fail for lix_2_93:

./lix/libcmd/markdown.cc:18:10: error: field designator 'cols' does not refer to any field in type 'struct lowdown_opts'
   18 |         .cols = (size_t) std::max(windowWidth - 5, 60),
      |         ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lix/libcmd/markdown.cc:19:10: error: field designator 'hmargin' does not refer to any field in type 'struct lowdown_opts'
   19 |         .hmargin = 0,
      |         ~^~~~~~~~~~~
../lix/libcmd/markdown.cc:20:10: error: field designator 'vmargin' does not refer to any field in type 'struct lowdown_opts'
   20 |         .vmargin = 0,
      |         ~^~~~~~~~~~~

That patch should probably stay in place unless there's an imminent release of Lix 2.93.4 (the release branch does have the patch backported).

As a quick workaround, lixPackageSets.git.lix still builds fine!

[RaitoBezarius]

@magneticflux- Thanks for the quick turnaround, I will fix this.