Overriding version, can't find new cargoHash

Help
1

I’m trying to override the version of mdbook-admonish like this

(mdbook-admonish.overrideAttrs (oldAttrs: rec {
  pname = "mdbook-admonish";
  version = "1.10.2";

  src = fetchFromGitHub {
    owner = "tommilligan";
    repo = pname;
    rev = "v${version}";
    hash = "sha256-2c1wSij2MDRdrqxN+cmnFO0z6mH/fgeg9E3cm+8ssww=";
  };

  cargoHash = "";
}))

  1. I changed version and set hash = "" and cargoHash = ""

  2. This gave me the expected hash mismatch, which gave me the new value of hash.

  3. Next I get the error

    direnv: loading /tmp/grr/.envrc
direnv: using flake
warning: Git tree '/tmp/grr' is dirty
error: builder for '/nix/store/w2r948y9y07sih30g9jmjf3dk94qwahh-mdbook-admonish-1.10.2.drv' failed with exit code 1;
       last 10 log lines:
       > ERROR: cargoHash or cargoSha256 is out of date
       >
       > Cargo.lock is not the same in /build/mdbook-admonish-1.9.0-vendor.tar.gz
       >
       > To fix the issue:
       > 1. Set cargoHash/cargoSha256 to an empty string: `cargoHash = "";`
       > 2. Build the derivation and wait for it to fail with a hash mismatch
       > 3. Copy the "got: sha256-..." value back into the cargoHash field
       >    You should have: cargoHash = "sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=";
       >
       For full logs, run 'nix log /nix/store/w2r948y9y07sih30g9jmjf3dk94qwahh-mdbook-admonish-1.10.2.drv'.
error: 1 dependencies of derivation '/nix/store/p31sx5fllmg67wzy0cg76y010a1y5m02-G4-examples-devenv-env.drv' failed to build
error: getting status of '/tmp/grr/.direnv/flake-profile.4105319': No such file or directory
warning: Git tree '/tmp/grr' is dirty
direnv: nix-direnv: renewed cache

    which beautifully explains how to get a new value for cargoHash … except that I can’t find that value anywhere, not even in the output of

    nix log /nix/store/w2r948y9y07sih30g9jmjf3dk94qwahh-mdbook-admonish-1.10.2.drv

What should I do to get the new value of cargoHash?

Why is it talking about Cargo.lock not being the same as in version 1.9.0?

2

Change the current hash a bit to provoke an hash mismatch, the resulting error message will contain the new hash.

Cargo.lock also contains the version

3

I’ve already set it to cargoHash = "", isn’t that enough? It is with hash (as opposed to cargoHash). Anyway, I’ve tried some more modifications, and always get the same result: the closest thing to a new cargoHash that ever appears is the "sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=" reported above.

My question was more about why it’s mentioning version 1.9.0 (which I have overridden with 1.10.2) rather than Cargo.lock.

4

The current nixos-unstable has already bumped the version to the one I was trying to get. So I copied the new cargoHash from nixpkgs to my override, so that the latter now looks like this

    (mdbook-admonish.overrideAttrs (oldAttrs: rec {
      pname = "mdbook-admonish";
      version = "1.10.2";

      src = fetchFromGitHub {
        owner = "tommilligan";
        repo = pname;
        rev = "v${version}";
        hash = "sha256-2c1wSij2MDRdrqxN+cmnFO0z6mH/fgeg9E3cm+8ssww=";
      };

      cargoHash = "sha256-UXH0SstMVprgezyr3I/6rv2uCMdDUUSIsQ3MJ49tdoI=";
    }))
The `nixpkgs` derivation, for comparison 
{ lib, stdenv, fetchFromGitHub, rustPlatform, CoreServices }:

rustPlatform.buildRustPackage rec {
  pname = "mdbook-admonish";
  version = "1.10.2";

  src = fetchFromGitHub {
    owner = "tommilligan";
    repo = pname;
    rev = "v${version}";
    hash = "sha256-2c1wSij2MDRdrqxN+cmnFO0z6mH/fgeg9E3cm+8ssww=";
  };

  cargoHash = "sha256-UXH0SstMVprgezyr3I/6rv2uCMdDUUSIsQ3MJ49tdoI=";

  buildInputs = lib.optionals stdenv.isDarwin [ CoreServices ];

  meta = with lib; {
    description = "A preprocessor for mdbook to add Material Design admonishments";
    license = licenses.mit;
    maintainers = with maintainers; [ jmgilman Frostman ];
    homepage = "https://github.com/tommilligan/mdbook-admonish";
  };
}

But I still get the error

ERROR: cargoHash or cargoSha256 is out of date

Cargo.lock is not the same in /build/mdbook-admonish-1.9.0-vendor.tar.gz

To fix the issue:
1. Set cargoHash/cargoSha256 to an empty string: `cargoHash = "";`
2. Build the derivation and wait for it to fail with a hash mismatch
3. Copy the "got: sha256-..." value back into the cargoHash field
   You should have: cargoHash = "sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=";
5

I’m running into the same issue trying to bump rio to 0.0.23.
Setting hash to = "" works as expected, you get a hash mismatch and copy the correct one.
Setting cargoHash to = "" keeps producting the same error:

ERROR: cargoHash or cargoSha256 is out of date

Cargo.lock is not the same in /build/rio-0.0.19-vendor.tar.gz

To fix the issue:
1. Set cargoHash/cargoSha256 to an empty string: `cargoHash = "";`
2. Build the derivation and wait for it to fail with a hash mismatch
3. Copy the "got: sha256-..." value back into the cargoHash field
   You should have: cargoHash = "sha256-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=";
Overlay itself: 
                  rio = final: prev: {
                    rio-head = prev.rio.overrideAttrs (old: rec {
                      version = "0.0.23";
                      src = nixpkgs.legacyPackages.x86_64-linux.fetchFromGitHub {
                        owner = "raphamorim";
                        repo = "rio";
                        rev = "v${version}";
                        hash = "sha256-X5yQISy8SSSyR0KR5eQ17YbsshjLYqNx6ssaV4qRldg=";
                      };
                      cargoHash = "";
                    });
                  };

It’s also referencing rio-0.0.19 for some reason, same as in your case @jacg.
This is pretty unintuitive and a very bad UX even for someone using nix for over a year.

1 Like
6

@jacg in case you never resolved this, just remembered what it is: overrideAttrs works on stdenv.mkDerivation’s attribues, but not on buildRustPackage.

The key is to override cargoDeps instead of cargoHash. This answer (and the whole thread clarifies the problem).

I’m surprised that this was never tackled though.

2 Likes