Skip to content

auditable-build panics on Beta #26

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

Closed
Monadic-Cat opened this issue Oct 4, 2020 · 3 comments
Closed

auditable-build panics on Beta #26

Monadic-Cat opened this issue Oct 4, 2020 · 3 comments
Labels
bug Something isn't working third party Work item for a third-party dependency

Comments

@Monadic-Cat
Copy link

I have a crate, mbot for which auditable-build successfully runs and this all works for on Stable, but for which auditable-build panics when building on Beta.
Some relevant command output:

jmn@neogreen:~/Projects/mprojects/mbot$ RUST_BACKTRACE=1 cargo +beta run --release --features auditable-data
   Compiling mbot v0.1.0 (/home/jmn/Projects/mprojects/mbot)
error: failed to run custom build command for `mbot v0.1.0 (/home/jmn/Projects/mprojects/mbot)`

Caused by:
  process didn't exit successfully: `/home/jmn/Projects/mprojects/mbot/target/release/build/mbot-35641d5a1f06aff7/build-script-build` (exit code: 101)
  --- stdout
  cargo:rerun-if-changed=data/maddie.json

  --- stderr
  thread 'main' panicked at 'no entry found for key', cargo/registry/src/github.com-1ecc6299db9ec823/auditable-serde-0.1.0/src/lib.rs:307:51
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/9f0e6fa94be6f97c736e51811d7b58904edfa8cb/library/std/src/panicking.rs:475
     1: core::panicking::panic_fmt
               at /rustc/9f0e6fa94be6f97c736e51811d7b58904edfa8cb/library/core/src/panicking.rs:85
     2: core::option::expect_failed
               at /rustc/9f0e6fa94be6f97c736e51811d7b58904edfa8cb/library/core/src/option.rs:1213
     3: core::option::Option<T>::expect
     4: <std::collections::hash::map::HashMap<K,V,S> as core::ops::index::Index<&Q>>::index
     5: <auditable_serde::VersionInfo as core::convert::TryFrom<&cargo_metadata::Metadata>>::try_from
     6: auditable_build::collect_dependency_list
     7: build_script_build::main
     8: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
@Monadic-Cat
Copy link
Author

Upon regenerating the Cargo.lock in mbot, this issue vanishes. Somehow or other, my Cargo.lock was malformed. Nemo157 on Discord has guessed that this is related to rust-lang/cargo#8522.

@Shnatsel
Copy link
Member

Shnatsel commented Oct 5, 2020

This is caused by an upstream bug: rust-lang/cargo#8756

I'll keep this open until the upstream issue is resolved.

@Shnatsel Shnatsel reopened this Oct 5, 2020
@Shnatsel Shnatsel added bug Something isn't working third party Work item for a third-party dependency labels Oct 5, 2020
@Shnatsel
Copy link
Member

The upstream bug is fixed, so closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working third party Work item for a third-party dependency
Projects
None yet
Development

No branches or pull requests

2 participants