Hi,
(Sorry, didn’t find any better place/category to post this.)
I am using the channel “nixos-24.11-small” and starting today (2024-04-15) or maybe yesterday (2024-04-14) any nixos-rebuild or nix-shell appears to build every package from source (vs. downloading it from cache.nixos.org).
Also hydra-check does not seem to find any successful package build in this channel:
$ hydra-check --channel nixos/release-24.11-small bash
Build Status for nixpkgs.bash.x86_64-linux on nixos/release-24.11-small This job is not a member of the latest evaluation of its jobset. This means it was removed or had an evaluation error.
Yet, I did not find any (obvious) indication of a major issue anywhere.
Switching to the “nixos-24.11” channel fixes the issue.
-small channels are only meant for use in cases where you use some core group of packages that hydra has built before that channel advances. AIUI hydra builds all packages only on the regular channels. So this is a sign that -small is not the channel you want.
But the list of packages I am using has not changed.
(Virtually) all packages I am using were pulled from cache.nixos.org before.
Sorry, I am not able to make sense of this sentence.
(Does it mean that Hydra will only built -small channels until some event occurs; so that the number of packages in -small channels might be very low?)
Small channels (nixos-24.11-small, nixos-unstable-small) are identical to large channels, but are updated as soon as Hydra has finished building a defined set of commonly-used packages. Thus, users following these channels will get faster updates but may need to build any packages they use from outside the defined set themselves. These channels are intended to be used for server setups, for example.
I believe I am within this “defined set of packages” as hardly any local compiling has occurred before.
I do not see why this defined set should change seemingly randomly.
I’d like to check the facts, but I don’t know where to look at.
You misunderstand. That does not mean that using the small channel will never result in getting cached packages outside that defined set. The -small channel is just a subset of the large channel that gets evaluated and updated more promptly. It is entirely possible for packages in the -small channel to have been built / cached by a build of the large channel, even though those packages are not in the “defined set”. e.g. If the -small channel updates, but only some leaf packages, that you don’t use, have changed since the last large channel update, then all the other packages in the -small channel will remain cached, even the ones outside the “defined set”.
So most likely you’ve just been lucky so far. When you’ve updated, you happened to end up on a -small channel revision that was incidentally already cached pretty well by the large channel, either because none of the things you use had changed recently or because the large channel was already far enough along in an ongoing build of a new revision.
I agree with @waffle8946, this makes it sounds like the -small channel is not the one you want to be using. And indeed this unpredictability is exactly why the -small channel is recommended against unless you’re familiar with these details and how it works.
If your entire usecase isn’t covered by those jobs, then -small is not the right channel for you. If you think that list should be expanded, PRs are always welcome. But that list is intentionally extremely minimal.
So I understand that right now (building) the channel nixos-24.11 is more “behind” nixos-24.11-small than usual, and this is why I am seeing so many cache misses.
I am surprised how small the -small channels actually are.
Maybe the documentation should make more clear that hardly any of their packages should be expected to be available pre-built on cache.nixos.org.
This job is not a member of the latest evaluation of its jobset. This means it was removed or had an evaluation error.
