bump substrate (because of crate version increase in substrate master branch)

[clangenb]

Substrate has again increased the version of various crates in their master branch, which implies that the api-client build is broken if we don't have the substrate crates in the cargo cache.

Bummer: We need to update the node-metadata crate because the metadata has changed

[haerdib]

frame metadata has been updated to 15.0.0 (https://github.com/paritytech/frame-metadata/blob/main/frame-metadata/Cargo.toml#L3) but it's still on v14: https://github.com/paritytech/frame-metadata/blob/main/frame-metadata/src/lib.rs#L78-L82

[clangenb]

Yeah sorry. I have poorly described the problem. If I remember correctly, we had compiler errors here after the dependency update:

substrate-api-client/node-api/src/metadata.rs

Line 410 in b2bfc0c

impl TryFrom<RuntimeMetadataPrefixed> for Metadata {

[clangenb]

Bummer: paritytech/substrate@bfc6fb4 broke no_std, if full_crypto feature flag is used...

because of:

https://github.com/paritytech/substrate/blob/b36030a6e8c21af9f18bb0d6a667188fac0dbc47/primitives/core/Cargo.toml#L59

where global_context implies std

and full crypto, which we need pulls in this optional dependency in no_std:

https://github.com/paritytech/substrate/blob/b36030a6e8c21af9f18bb0d6a667188fac0dbc47/primitives/core/Cargo.toml#L134

[clangenb]

found with the help of this cmd:

 cargo tree -e features -i secp256k1                                                           ok | 00:10:25  
secp256k1 v0.21.3
├── secp256k1 feature "global-context"
│   └── sp-core v6.0.0 (https://github.com/paritytech/substrate.git?branch=master#b36030a6)
│       ├── sp-application-crypto v6.0.0 (https://github.com/paritytech/substrate.git?branch=master#b36030a6)
│       │   └── sp-application-crypto feature "full_crypto"
│       │       └── substrate-api-client v0.6.0 (/home/clang/code/substrate-api-client)
│       │           └── test-no-std v0.6.0 (/home/clang/code/substrate-api-client/test-no-std)
│       │               └── test-no-std feature "default" (command-line)
│       └── sp-io v6.0.0 (https://github.com/paritytech/substrate.git?branch=master#b36030a6)
│       │   └── sp-core feature "full_crypto"
│       │       └── substrate-api-client v0.6.0 (/home/clang/code/substrate-api-client) (*)
│       │       └── sp-application-crypto feature "full_crypto" (*)
│       ├── sp-core feature "ed25519-dalek"
│       │   └── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "hex"
│       │   └── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "libsecp256k1"
│       │   └── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "merlin"
│       │   └── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "schnorrkel"
│       │   └── sp-core feature "full_crypto" (*)
│       ├── sp-core feature "secp256k1"
│       │   └── sp-core feature "full_crypto" (*)
│       └── sp-core feature "sp-core-hashing"
│           └── sp-core feature "full_crypto" (*)
├── secp256k1 feature "recovery"
│   └── sp-core v6.0.0 (https://github.com/paritytech/substrate.git?branch=master#b36030a6) (*)
└── secp256k1 feature "std"
    └── secp256k1 feature "global-context" (*)

[haerdib]

And the version bumps happened after this commit. Not good. Does parity know about this issue? I didn't see a related issue on substrate side.

[clangenb]

Probably not, they don't use this feature flag, which is why this error could occur in the first place...

I filed an issue there: paritytech/substrate#11005

[clangenb]

They reacted, the issue will be resolved with: paritytech/substrate#11006