Update NixOS flake to latest successful nixos cache build

In order to update my NixOS install (I’m using flake) I do the following:

sudo nix-channel --update
nix flake update .#desktop

The problem is that I often stumble upon a broken package.

I’m trying to understand how can I update all my inputs to the latest revision that is both cached in cachix and the build was successful.

EDIT: I mean http://cache.nixos.org/, the upstream nixos cache, not cachix

If you’re using flakes then nix-channel commands won’t do anything.
And what cachix server are you using?

huh, good to know

doesn’t nixos-rebuild use cachix by default? I haven’t tinkered with anything I just see that some packages that were altered very recently need to rebuild and other packages come pre-compiled as binaries. I assumed that cachix came into play

No, packages in nixpkgs are cached at cache.nixos.org. Cachix is a paid service from an unrelated company.

Oh didn’t know that, I edited the topic

The question though still stands: How can I update to the latest successful build of the cache?

If you have an input like

  inputs.nixpkgs.url = "github:NixOS/nixpkgs";

then it will pull from master, which includes basically everything that is being merged at any given moment (except for stuff going into staging branches first.) If you want some kind of stability, you would want to try a channel, e.g. nixos-unstable:

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

This will track the nixos-unstable branch of the nixpkgs repository, which is updated by Hydra when the respective job succeeds. You can find a bit more information on what exactly that job tests before considering a given revision passing on the Wiki and surely other sources, but it runs some of the NixOS tests.

This branch can fall behind by a few days sometimes, so you might prefer the somewhat stripped down nixos-unstable-small branch if you prefer something a bit more up-to-date.

1 Like

For cachix caches this would be useful https://git.fem.gg/cafkafk/nix-weather

I’m using nixos-unstable so I guess the problem is that some non-critical packages that fail to build are not considered breaking and the unstable branch gets updated even though some packages fail to build?

Right, but you can use nixos-rebuild dry-build (or nix-weather if you like) to get an idea of how much needs to get built.

Also, anything unfree won’t get built by hydra (the build service that feeds cache.nixos.org) FYI.

2 Likes

I’m not exactly sure how much of Nixpkgs is covered by nixos/trunk-combined/tested to be honest. I know where the job is defined, but I haven’t really dug enough to understand the scope. I’m kind of curious, though, if anyone happens to know.

That said it is definitely accurate to say this does not cover all of the packages. (As mentioned directly above me unfree packages are not covered, I’m also aware some things are disabled in Hydra because they have trouble succeeding in it, and I believe only a minimal amount of cross packages are cached, e.g. pkgsMusl.stdenv.)

Out of curiosity, are there particular packages that have proven problematic?

random packages at times, there’s no consistent pattern. I can remember kicad and then another package that needed a python32 related fix.
these happened about a month apart so it’s definitely not a problem, I can either use an earlier revision or wait a day or two and it gets fixed (haven’t been fast enough to fix a package till now) but I’ve caught the nix perfectionist bug :stuck_out_tongue:

Yep, understandable. I’ve definitely ran into problems where it’s just a result of nixos-unstable being broken and I have to hold it back. nixos-unstable is almost good naturally as a rolling release distro, but sometimes it’s a little more unstable than would be ideal. At least atomic upgrades and rollbacks ease the pain a little.

I would love to see this situation improved, but it does seem like it’s a hard problem; nixos-unstable already doesn’t move as fast as I’d like. But, I assume any meaningfully large improvement will either require a lot of thinking, buckets of money, or possibly both.

honestly, the impact of this issue is almost 0 to me so a client-side fix is all I believe it needs