cli/laufey_sums.lock pins Laufey v{pinned} but this build ex

Error message

cli/laufey_sums.lock pins Laufey v{pinned} but this build expects v{laufey_version} — refresh the lock file from the upstream SHA256SUMS

What it means

Same build-time consistency check (check_laufey_pinned_sums_version, cli/build.rs:352-365): cli/laufey_sums.lock carries a '# version:' directive, but it names v<pinned> while the workspace Cargo.lock resolves the laufey crate to v<laufey_version>. The digest file is therefore stale for the binary being built, and the build panics instead of shipping digests that would fail (or worse, not fail) at first launch.

Source

Thrown at cli/build.rs:361

    if !pinned.is_empty() {
      return Some(pinned.to_string());
    }
  }
  None
}

/// Confirm `cli/laufey_sums.lock` targets `laufey_version`. The lock file carries a
/// `# version: vX.Y.Z` directive that must match the `laufey` crate version
/// the binary is built against; a mismatch means the pinned digests are stale.
fn check_laufey_pinned_sums_version(manifest_dir: &str, laufey_version: &str) {
  let Some(pinned) = laufey_version_from_sums(manifest_dir) else {
    panic!(
      "cli/laufey_sums.lock has no pinned laufey version — populate it for \
       v{laufey_version} before building"
    );
  };
  if pinned != laufey_version {
    panic!(
      "cli/laufey_sums.lock pins Laufey v{pinned} but this build expects \
       v{laufey_version} — refresh the lock file from the upstream SHA256SUMS"
    );
  }
}

/// SHA-256 digests of the vendored AppImage Type-2 runtime stubs (from
/// `cli/tools/appimage_runtime/README.md`). Verified at build time so a
/// silent local modification (or a bad rebase) of those checked-in binaries
/// can't slip into a release build undetected.
const APPIMAGE_RUNTIME_HASHES: &[(&str, &str)] = &[
  (
    "tools/appimage_runtime/runtime-x86_64",
    "2fca8b443c92510f1483a883f60061ad09b46b978b2631c807cd873a47ec260d",
  ),
  (
    "tools/appimage_runtime/runtime-aarch64",
    "00cbdfcf917cc6c0ff6d3347d59e0ca1f7f45a6df1a428a0d6d8a78664d87444",

View on GitHub (pinned to 9ad36f7a2c)

Solutions

Refresh cli/laufey_sums.lock from the upstream SHA256SUMS for the new laufey release and set its '# version:' directive to the Cargo.lock version.
Alternatively pin laufey back to what the lock covers: cargo update -p laufey --precise <pinned>.
Commit Cargo.lock and cli/laufey_sums.lock together in the same change so the pair never diverges.

Example fix

# before: Cargo.lock has laufey 0.2.0, lock file still says
# version: 0.1.4

# after: refresh digests from the v0.2.0 SHA256SUMS
# version: 0.2.0
b71c0d...  laufey-linux-x86_64.tar.gz

Defensive patterns

Strategy: validation

Validate before calling

# preflight: lock directive must equal the Cargo.lock laufey version
pinned=$(sed -n 's/^# version: //p' cli/laufey_sums.lock | head -1)
resolved=$(grep -A1 'name = "laufey"' Cargo.lock | sed -n 's/version = "\(.*\)"/\1/p' | head -1)
[ "$pinned" = "$resolved" ] || echo "laufey_sums.lock pins $pinned but Cargo.lock has $resolved"

Prevention

Commit Cargo.lock and cli/laufey_sums.lock together in dependency bumps
After cargo update, re-check the directive before building
Treat the build-time panic as the intended guard — never delete the check to get a build through

When it happens

Trigger: cargo update bumps laufey; editing the laufey version in a Cargo.toml without refreshing the lock; building a branch where Cargo.lock changed but cli/laufey_sums.lock did not; rebases that mix versions across files.

Common situations: Dependency-bump PRs that update the manifest but forget the vendored trust anchor; contributors building a feature branch after an upstream laufey bump; release automation that bumps versions inconsistently.

Related errors

AI-assisted analysis of denoland/deno@9ad36f7a2c (2026-08-20). Data as JSON: /api/errors/70020486ed81c60f. Report an issue: GitHub.