@philiptaron @SomeoneSerge Heads up, we will be removing the Nix CI from llama.cpp. Happy to add references to a new repository that maintains the Nix package.

Sounds good. It's in a stable place and I am fine doing CI myself or as per issue reports.

make sense for the nix package to be maintained in a separate repository

Sure, in fact there is an has been a llama.cpp package under NixOS/nixpkgs built by the official NixOS Hydra (and with CUDA support by the nix-community hydra). A "flake" has been contributed upstream, as I understood, for faster iterations, and @philiptaron and I spent a little bit of time refactoring it. We then proposed validating the "flake" in a github workflow, with two motivations:

• to keep the nix code in sync with the c++ and cmake code,
• but also to provide a more immediate signal to llama.cpp contributors for when their changes might not align with the restrictions put on by nix out of its "reproducibility" considerations.

The latter was with the assumption that this signal might indeed be useful for the broader llama.cpp community.

Heads up, we will be removing the Nix CI from llama.cpp. Happy to add references to a new repository that maintains the Nix package.

Thanks, acknowledged. I did suspect that complete pure builds will prove to be too much for an on-push action.

This has already been brought up in #6346, but I've since played a little bit with (injecting an impure) CCache (into the Nix sandbox), albeit outside the context of github actions: this lets one keep the benefit of explicit dependency tracking, but bring down build times by an order of 2-5x. I think for a repo like llama.cpp the current nix build times would need to be brought down by a factor of 10-20x however. Another option might be just disabling the sandbox entirely: e.g. only using a dev-shell to build llama-cpp impurely (yet still with dependencies and flags tracked by nix).