Base branch should be staging because it involves many rebuilds.

In the past high-profile packages known to cause widespread failures occasionally had a separate jobset to weed out most failures. I think it avoided a bulk of failures and slightly improved bisectability of nixpkgs.

We don't really have the capacity to do that right now, and we've done a lot of builds locally (I've personally verified all of kdePackages and everything up to the default graphical ISO).

looking at the release schedule, this isn't super viable. emily wanted the hook to be removed (and did an amazing job both with the bump and the hook!), but it took time. If we were to run cmake 4 through its own jobset, we'd end up merging the bump in the last cycle before freeze, and that is just miserable. Given how little time and active maintainers we have available, a merge to staging was the best course of action. These failures aren't even particularly hard to fix, should be simple enough to fix up in a staging cycle.

libvdpau-va-gl: Compatibility with CMake < 3.5 has been removed from CMake.

Proposed the fix as:

• libvdpau-va-gl: pull upstream cmake-4 fix #444579

Now that cmake-4 is default in master I see the following build failures:

• libunarr: Compatibility with CMake < 3.5 has been removed from CMake.
• innoextract: Compatibility with CMake < 3.5 has been removed from CMake.
• fuzzylite: Compatibility with CMake < 3.5 has been removed from CMake.
• flare: Compatibility with CMake < 3.5 has been removed from CMake.

Did not seem like it was fixed in staging-next (it's the same subset of packages from the comment above)

Proposed libunarr fix as:

• libunarr: backport cmake-4 incompatibility #449247

Proposed innoextract fix as:

• innoextract: 1.9 -> 1.9-unstable-2025-02-06 (cmake-4 compatible) #449252

Proposed fuzzylite fix as:

• fuzzylite: 6.0 -> 6.0-unstable-2025-08-30 (cmake-4 compatible) #449261

Proposed flare fix as:

• flare: backport upstream cmake-4 fixes #449265

We don't really have the capacity to do that right now, and we've done a lot of builds locally (I've personally verified all of kdePackages and everything up to the default graphical ISO).

Well, in this case, maybe we don't need to make cmake 4 the default, right before branch-off. This is not a security update!

The ecosystem will catch up by itself anyway, as upstream packages migrate to cmake 4. Dropping the responsibility to fix builds onto nixos maintainers can only exacerbate our capacity problems, especially since we will often lack the domain knowledge to be able to port per-project cmake files.

So just dropping this in and leaving everyone to deal with the fallout it is not responsible way to do this and I'd ask you to do better in the future.

There's still a big list of software that's broken by the in-place upgrade from cmake 3.x to 4.x: #445447.

I'm not happy about it. Why couldn't cmake4 be added without making it the default? Or even make it the default, but keep cmake3 for the software that still need it? Who benefit from this change?

cmake 3.x is EOL, and the fixes are generally expected to be about as easy as pinning a package to cmake3.

cmake 3.x is EOL, and the fixes are generally expected to be about as easy as pinning a package to cmake3.

I'd rather run with EOL cmake 3.x for a bit longer, than to not be able to upgrade my system (due to multiple packages no longer building).

Also, if it's easy to pin, why wasn't this done to begin with? Why break something and leave it to others to fix? (Btw, there is no cmake3 or cmake_3 -- that's part the problem.)

cmake 3.x is EOL, and the fixes are generally expected to be about as easy as pinning a package to cmake3.

You say it's an easy fix, but I haven't been able to run nixos-rebuild for three days off of the main branch because extremely basic packages are broken and the one-line patches are being obstructed with code review.

We shouldn't ship EOL software in our stable 25.11 release. Completely removing cmake 3 makes sense in that context.

Also, if it's easy to pin, why wasn't this done to begin with?

This is not what @K900 said. The claim was "fixes are as easy as pinning", not pinning supposedly being easier. I am inclined to agree: Anyone can pass "-DCMAKE_POLICY_VERSION_MINIMUM=3.10" in an overlay for a temporary fix:

{ lib }:
{
  nixpkgs.overlays = [
    (
      final: prev:
      let
        broken_pkgs = {
          # whatever is broken goes here
          inherit (prev) trlib hpipm;
        };
      in
      lib.mapAttrs (
        n: pkg:
        pkg.overrideAttrs (old: {
          cmakeFlags = old.cmakeFlags or [ ] ++ [ "-DCMAKE_POLICY_VERSION_MINIMUM=3.10" ];
        })
      ) broken_pkgs
    )
  ];
}

This is not overly complex for a local fix, and doing fix PRs is not exactly hard either. Many of the people participating in #445447 are first contributors, for example.

Frankly, it is the same 5-10 people running staging all the time. It is unreasonable to expect these people to fix everything by themselves. The solution can not be to pin old things that won't receive updates. As long as not more people are willing to help out with staging, then breaking and fixing later is the only way. Quite some of the packages being fixed here already had newer releases, but the respective maintainers never opened PRs for those. The blame for new updates breaking old software should not be on the people performing these new updates, but rather with the people refusing to acknowledge these problems and add updates accordingly before a hard break becomes necessary. The cmake 4 update was no surprise, this PR was lengthily discussed and open as a draft for half a year.

one-line patches are being obstructed with code review.

This is because "-DCMAKE_POLICY_VERSION_MINIMUM=3.5" is not the pattern we should be doing to unbreak these from nixpkgs side. This CLI flag runs the risk of later downgrading the cmake min version as defined by upstreams, if upstream happens to be updating to some higher version than we are forcing by CLI flag. As i have said before, patches are preferable because they will start failing once upstream adjusts their cmake scripts. See also #445447.

This is because "-DCMAKE_POLICY_VERSION_MINIMUM=3.5" is not the pattern we should be doing to unbreak these from nixpkgs side. This CLI flag runs the risk of later downgrading the cmake min version as defined by upstreams, if upstream happens to be updating to some higher version than we are forcing by CLI flag. As i have said before, patches are preferable because they will start failing once upstream adjusts their cmake scripts. See also #445447.

I understand the concern. Although it seems like it would apply to any minimum version you choose to enforce with a patch, I don't particularly have an issue with the decision to hold up that kind of change in code review. What I question is to force this change onto master with very little warning.

I will freely admit that I don't know much about nix governance, but don't we have designated package maintainers? Couldn't we have had hydra do a full build with cmake 4.x and generate a comprehensive list of everything that breaks, and then automatically open a bunch of issues assigned to people best equipped to deal with them? Couldn't all of that have happened without breaking everyone's systems for a few days?

Although it seems like it would apply to any minimum version you choose to enforce with a patch

No, because a patch or substituteInPlace --replace-fail will fail to apply, thus not accidentially downgrading the version later. It will be an explicit build failure exactly describing what went wrong, instead of silently doing potentially some wrong thing that ends up hard to debug.

What I question is to force this change onto master with very little warning

I don't see what is being forced on master? The review surely not, these reviews happen to PRs not yet on master. The cmake PR also was a draft for half a year, and after merging it took close to another month to reach master.

don't we have designated package maintainers?

Yes, and we do not have good infra to notify them of failed packages beyond having the packages fail and users complain. While not ideal, that does have its upsides too: We have many maintainers that are only active on paper, and many packages that are effectively unmaintained as a result. Occasionally we can go and just remove packages that were broken a while ago without anyone caring/noticing.

Couldn't we have had hydra do a full build with cmake 4.x and generate a comprehensive list of everything that breaks

Yes, and with more willing participants this is what we would have liked to do. However, this only works if there is someone stewarding the project and managing the dedicated hydra jobset. Very few people have the skills required, and all of them were occupied with different things until recently. Doing this now would mean cmake 4 would not make it into 25.11, but we don't want to keep the EOL cmake 3 around. So that just was not viable anymore this late in the release cycle.

open a bunch of issues assigned to people best equipped to deal with them

this is wishful thinking. Sure would be nice, but experience tells many of the packages being broken by build system upgrades are entirely unmaintained.

Couldn't all of that have happened without breaking everyone's systems for a few days?

I want to note updates are blocked, but the systems are not broken. They do work as expected, they just currently can't update. This is a very different thing. Not ideal, of course: Security fixes are being held up in those updates too. But it should not block anyone from doing productive work with their devices.

I cant find a references that says cmake 3 is EOL (could be i just cant find it stated) - they had a v3 release 14 days ago

I still have projects and 3rd party projects that have nix-shells for that I'd like to use modern build tooling with a unstable/next having a cmake3 package.

I still have projects and 3rd party projects that have nix-shells for that I'd like to use modern build tooling with a unstable/next having a cmake3 package.

PR to add cmake3 here: #450570

PR to add cmake3 here: #450570

Thanks for taking the time. I did my part, re-opened (!) it and added an approval. It is still blocked on unspecified change requests. So unfortunately, this will have to be decided via popularity contest :-/

Everyone feel free to add approvals to #450570

I left a comment at #445447 (comment) that should address many of the points raised here.