Nixpkgs: Cannot install google-fonts: hash mismatch

[wandernauta]

Issue description

When I try to install google-fonts, the installation fails with a hash mismatch:

output path ‘/nix/store/n39mbp5nbw8vmrsnhgc2m7sk1p152qn9-google-fonts’ has r:sha256 hash ‘09r9yn95p76symvmanqbwd3zbwai9aiflrdrfjnz9yr2cbnn577r’ when ‘0q03gg0sh2mljlbmhamnxz28d13znh9dzca84p554s7pwg6z4wca’ was expected

Steps to reproduce

nix-env -i google-fonts

Technical details

My system is as follows:

• System: 16.09.975.1e1112e (Flounder)
• Nix version: nix-env (Nix) 1.11.4
• Nixpkgs version: "16.09.975.1e1112e"

However, the same error appears on other systems.

[copumpkin]

https://github.com/NixOS/nixpkgs/blob/master/pkgs/data/fonts/google-fonts/default.nix looks really strange to me, in effect trying to be a "two-level" fixed-output derivation. @manveru, do you know what's up with that?

[copumpkin]

Oh, it looks like @edolstra did that fairly recently: https://github.com/NixOS/nixpkgs/commit/1681718e2fd81c2613604df0a3fbb259bf213ceb

[copumpkin]

The danger of making a derivation into a fixed-output derivation like that is that if any of the inputs change their behavior slightly, the FO derivation breaks.

[edolstra]

I think this was fixed in c015c2910693f47b641f325f66e690158c3d2652.

[copumpkin]

@edolstra but the hash it was complaining about in OP was the google-fonts output hash, not its source hash (which admittedly will also change with a straight fetchurl, so the commit you linked to is still useful), so my concern about fragility still stands

[edolstra]

Note that there is nothing wrong with using a fixed-output derivation. In fact it revealed an actual problem, namely that the build was non-deterministic in a bad way: depending on directory order it would copy different TTF files.

[sid-kap]

I just had this problem today. I'm on nixos-unstable, so I would expect that the patch should have fixed it. Is there something I can do to check what version of the packages I'm on, to see if the problem persists?

[vcunat]

It seems OK to me on current nixos-unstable (1c50bdd9).

[sid-kap]

@vcunat How do I check whether my nix channel contains that commit? My nixpkgs version is 16.09.1086.7596205.

(I found this by running the command nix-instantiate --eval -E '(import <nixpkgs> {}).lib.nixpkgsVersion'.)

[vcunat]

@sid-kap: you said you were on nixos-unstable, but your version indicates 16.09 (i.e. stable). Still, it does work for me even on your version (7596205).

[vcunat]

...which might be just because http://tarballs.nixos.org is used before the original URL by default.

[sid-kap]

Hmm, I wonder why that is. I followed the instructions in Chapter 4 of the Nixos Manual. Is there something else I need to do to switch to unstable?

[sid-kap]

I ran nixos-rebuild switch --upgrade, and now my version is up to "16.09.1272.81428dd", which still starts with 16.09 and therefore is not unstable. Why did it not upgrade me to unstable? Here is the output of nix-channel --list:

nixos https://nixos.org/channels/nixos-unstable

[sid-kap]

In case this might be useful, the output of cat /nix/var/nix/profiles/per-user/root/channels/nixpkgs/.version is 17.03, but the output of cat /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/.version is 16.09.

[vcunat]

We're getting a bit off-topic, but for nixos-rebuild the root's channels are what you should look at, e.g. sudo nix-channel --list. In the manual that's signified as the command lines starting by #; I'm not sure if there's some explicit statement.

[sid-kap]

Thanks, that worked. Google Fonts now installs properly on my machine.

[vcunat]

Well, let me close. If someone can reproduce the problem on a recent (un)stable channel, we'll reopen.

[vcunat]

I retried ensuring download comes from github, and it succeeded with the same hash we have in 16.09 for months.

[vcunat]

I did yet another two downloads from github, together from three different networks within CZ, and all have the hash we got committed. I've got no idea how some people could get a different one. We could try comparing individual file hashes, etc. but as long as it's just a single package...

[vcunat]

Nix store hashes don't exhibit such "bugs" normally.

[vcunat]

Still, it's possible that fetchzip is buggy in this respect.

[copumpkin]

Still, it's possible that fetchzip is buggy in this respect.

@vcunat @volth is talking about the output hash being a mismatch, not the fetchFromGitHub one.

[vcunat]

Ah, right, it's most likely that buggy usage of find that got fixed on master already but wasn't backported to 16.09 yet. I somehow missed the difference from master.

[vcunat]

Picked all those changes now.