I’ve been trying to keep Nixos running on an old 32 bit machine. Every time I rebuild I use a local repo that has a couple of patches.
Whenever I do a nixos-rebuild it builds Nix first from sources and that takes a lot of time. Nix should be in the binary cache, right? Even a 32 bit version, too? But I could not find any Hydro jobs relating to the Nix itself, at least within the Nixos Hydra project. What’s the job I want to look at to see the Nix version used by a particular Nixos version?
Am I right in even assuming that if I use a local nixpkgs repo it would still use the Nixos binary cache, as long as it’s set to a revision built by Hydra?
As long as the NixOS binary cache is configured, it will be used to substitute any paths possible.
The reason you are experiencing cache misses is that there is no cache for i686, it was disabled quite some time ago already. The jobsets in the nix project still build Nix on i686, but that is a subtly different derivation from NixOS. In any case building Nix from scratch is probably not the worst, but what comes after, e.g. firefox, GHC, rustc, …
I was able to confirm that myself by trying to update to the latest channel and I would get the very same nix binary package as he did there.
It’s just that when I’m rebuilding from a local nixos repo copy, it’s not trying to grab that existing package, it’s trying to build it from scratch for some reason, even if the nixpkgs repo does not have any changes and it’s set to the very same version the channel is at. And it’s probably not just Nix, so for some reason it’s ignoring the binary cache for me…
I should make it clear that some i686 packages are built on Hydra, e.g. those required for the minimal ISO which is still provided, but the package set is certainly much smaller than for x86_64-linux.
After some more testing, I’ve narrowed the issue I have further.
I have a long running nixpkgs repo copy that’s months old and I’ve been pulling into it as needed. Apparently only when I rebuild from that repo copy(and it’s copies) I have the issue with rebuild not using the binary cache.
I’m very baffled why would that happen, but at least a new repo clone fixed it.
Thanks to some gentlemen on #nixos IRC I now know exactly what I did wrong. At some point through that repo’s existence I did chmod 755 which added +x on all of the files and whenever +x is added on a patch file it causes the package hash to change which in turn makes it miss the binary cache. And I didn’t see that file permissions changed because I for some reason set “filemode = false” in the repo’s git config.