Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Different package hashes on x86_64-darwin and aarch64-darwin when building for x86_64 #11554

Open
konradmalik opened this issue Sep 20, 2024 · 1 comment

Comments

@konradmalik
Copy link

konradmalik commented Sep 20, 2024

Recently I was investigating why, even though my cachix has packages for x86_64-darwin, my local machine still builds them from scratch.

Then I noticed that my github runner was running macos-latest, which now defaults to aarch64-darwin but was able to build packages for x86_64-darwin due to rosetta (my assumption).

The problem is that packages build for x86_64-darwin on rosetta are different than those built on native x86_64-darwin (intel) and that's why I had all those cache misses.

The fix was to revert to macos-13 runner which still runs native x86_64-darwin.

The question - is this a bug? Lack of proper sandboxing on darwin? Can this somehow be fixed with proper nix.conf entries?

FYI: this was the fix konradmalik/nixpkgs-extra@e69eb43

The nix I use is installed using cachix/install-nix-action@V28 and the version is nix-2.24.6

@konradmalik konradmalik changed the title Different packages hashes on x86_64-darwin and aarch64-darwin when building for the same architecture Different package hashes on x86_64-darwin and aarch64-darwin when building for the same architecture Sep 20, 2024
@konradmalik konradmalik changed the title Different package hashes on x86_64-darwin and aarch64-darwin when building for the same architecture Different package hashes on x86_64-darwin and aarch64-darwin when building for x86_64 Sep 20, 2024
@roberth
Copy link
Member

roberth commented Sep 20, 2024

I suppose you're referring to the store path hashes, and not necessarily the content hashes (although those are affected whenever you have a reference to another store path).
If only the content hash is different, then the problem is a build impurity, which are usually unnoticeable due to the result being equivalent. So I'll assume we are talking about an evaluation impurity, which reveals itself through different derivation hashes and different store path hashes as a result (unless you're using CA derivations, in which case you may only see some rebuilds).

To get to the bottom of this, I'd recommend to push the .drv files to your cache, so that you can substitute them to your local store for comparison with nix-diff.
.drv files are normally not pushed, although I'm not sure about cachix in watch mode, which I think your CI setup is using. You can achieve this by calling nix-instantiate instead of nix-build, or something like nix eval --raw .#pkg.drvPath | cachix push <cache>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants