Repository navigation
Description
Hello,
Today installed electrs on another machine on my LAN, followed the same install process as before but this time encountered this error.
I did an earlier install on Ubuntu 22.04.5 LTS a week or so ago, todays install was on a different PC running Lubuntu 24.04.4 LTS and got the warning below.
This didn't happen on my other machine when I installed as far as I can see the same thing a week or so back, so IDK why it happened this time.
Anyway, the error message has some advice for dev's as to how to prevent it, so thought I should pass that on.
Details below.
Thanks,
Glen.
Did the standard install of clang/cmake/rustup and all good.
...
info: profile set to default
info: default host triple is x86_64-unknown-linux-gnu
info: syncing channel updates for stable-x86_64-unknown-linux-gnu
info: latest update on 2026-03-26 for version 1.94.1 (e408947bf 2026-03-25)
$ . "$HOME/.cargo/env"
So then tried to compile/run electrs:
$ git clone https://github.com/blockstream/electrs && cd electrs
$ git checkout new-index
Already on 'new-index'
Your branch is up-to-date with 'origin/new-index'.
$ cargo run --release --bin electrs -- -vvv --lightmode --timestamp ... etc etc
info: syncing channel updates for 1.92.0-x86_64-unknown-linux-gnu
info: latest update on 2025-12-11 for version 1.92.0 (ded5c06cf 2025-12-08)
info: downloading 7 components
...
Spent a while time building and compiling and then this happened:
...
Compiling rocksdb v0.24.0
Compiling electrs v0.4.1 (/home/grayner/electrs)
warning: unexpected cfg condition name: has_error_description_deprecated
--> src/errors.rs:1:1
|
1 | / error_chain! {
2 | | types {
3 | | Error, ErrorKind, ResultExt, Result;
... |
34 | | }
| |_^
|
= help: expected names are: docsrs, feature, and test and 31 more
= note: using a cfg inside a macro will use the cfgs from the destination crate and not the ones from the defining crate
= help: try referring to impl_error_chain_processed crate for guidance on how handle this unexpected cfg
= help: the macro impl_error_chain_processed may come from an old version of the error_chain crate, try updating your dependency with cargo update -p error_chain
= note: see https://doc.rust-lang.org/nightly/rustc/check-cfg/cargo-specifics.html for more information about checking conditional configuration
= note: #[warn(unexpected_cfgs)] on by default
= note: this warning originates in the macro impl_error_chain_processed which comes from the expansion of the macro error_chain (in Nightly builds, run with -Z macro-backtrace for more info)
warning: electrs (lib) generated 1 warning
Finished release profile [optimized] target(s) in 49m 38s
Activity
EddieHouston commentedon Apr 7, 2026
Thanks for taking the time to submit this.
What you are seeing is a Rust compiler lint (unexpected_cfgs) that became warn-on-by-default in recent nightly/stable Rust versions. The Rust toolchain in Electrs build was recently updated to 1.92.0 which is when this started showing up. It is a harmless warning.
What's happening
The error_chain! macro (from the error-chain crate) internally checks for a cfg flag called has_error_description_deprecated. Newer versions of rustc now validate all cfg names against a known list and warn when they see unfamiliar ones. Since has_error_description_deprecated isn't a standard cfg, you get the warning.
Why it's appearing now
The error-chain crate is essentially unmaintained (last release was years ago). The electrs codebase still depends on it. When you build with a newer Rust toolchain, this lint fires. It wouldn't have appeared with older Rust versions that didn't have this check.
Impact
None. It's purely cosmetic — the compiled binary is identical and correct. The macro expansion works fine; the compiler is just being stricter about validating cfg names.
How to suppress it (if desired)
You could add to electrs/Cargo.toml:
[lints.rust]
unexpected_cfgs = "allow"
Or pass RUSTFLAGS="--allow unexpected_cfgs" at build time. But it's not worth worrying about unless the warnings bother you in CI output.
The real fix would be for electrs to migrate away from error-chain to something like thiserror or anyhow, but that's a bigger upstream change.