Code change:
On today's master () - and probably others - building the attribute of many package produces an output that differs from the output on another architecture. Nix will display a hash mismatch. I tried with x8664-linux and aarch64-linux. Execute this on aarch64 and x8664. The aarch64 build produces the below output while x8664 is happy with the hash in nixpkgs. Please run and paste the results. system: host os: multi-user?: sandbox: version: nixpkgs: and system: host os: multi-user?: sandbox: version: channels(root): channels(andi): nixpkgs:
x8664 build produces same output for me: system: host os: multi-user?: sandbox: version: channels(root): nixpkgs:
I noticed something similar on macOS in Could some recent change have caused this? Perhaps ?
I reverted in a branch on my fork. My x86_64-linux laptop doesn't complain about the hash sum - as before. The aarch64-linux community box also doesn't complain anymore. Can anyone else confirm this?
I just made a diff of : The left side is aarch64, the right side is x86_64. Both are done on the same git revision ().
What a weird behavior that is missing.
Probably related:
I think this may be related: I also see different hashes on NixOS 19.03 vs. stable. I use the branch, but when CI builds the derivation on 19.03, the hashes do not match. If I build on NixOS 19.03 with from master, the hashes do match. This is quite annoying, because it makes it impossible to have package sets that work on NixOS stable and unstable without using rustPlatform from a nixpkgs newer than 19.03. I'll try to revert and see if I get the same hashes on 19.03 and master.
That's indeed it. When I revert , I get the same as 19.03. Maybe this change should be reverted? Since NixOS is not a rolling distribution and people run both stable and unstable, it would really be nice if package sets and overlays work on both versions. This also makes backporting changes easier.
Diff between the vendored dependencies: Here the differences also seem to be missing dotfiles (e.g. and ). I think this is the upstream PR that changed this behavior: (Edit: oops, I just saw that already mentioned the associated commit.)
is a critical update and reverting it will break multiple Rust packages. Rather I think we should get that change pushed into the channel, and then update any Rust packages whose changes as a result.
The only bummer is that it also breaks people's own packages on the channel as well.
Yeah, it would be bad to break people's derivations as an update to a stable release. At any rate, the 19.09 release notes should probably have a blurb that points out that hashes will change due to changes, so that people who update from 19.03 to 19.09 are prepared. There are probably also derivations in that have incorrect hashes now, since the file that is generated by is now excluded vendored dependencies.
I’ve updated the title of the issue to better reflect what I think we now know. Additionally, I’ve opened to update the hashes for all packages that haven’t been updated in master yet. I would appreciate a review on it. Once that’s merged, I can do the same thing for the affected release branch.
Looks like I misunderstood and this hasn’t made its was into a release branch yet, so we’re almost done here. Somebody just needs to add the release note for 19.09.
with the changelog PR () being merged, is there anything else missing?
Don't think so. :) Somebody can shout if I'm wrong.

Related discussion:
text: sha256 = "1z66m16n4r16zqmnv84a5jndr5x6mdqdq4b1wq929sablwqd2rl4"; }; <del> cargoSha256 = "1xdx0gjqd4zyhnp72hz88rdmgry1m7rcw2j73lh67vp08z74y54y"; </del> <ins> cargoSha256 = "0hp68w5mvk725gzbmlgl8j6wa1dv2fydil7jvq0f09mzxxaqrwcs"; </ins> nativeBuildInputs = [ pkgconfig ];