Skip to content
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

Update to Polkadot v0.9.29 #1041

Merged
merged 39 commits into from
Oct 25, 2022
Merged

Update to Polkadot v0.9.29 #1041

merged 39 commits into from
Oct 25, 2022

Conversation

NunoAlexandre
Copy link
Contributor

@NunoAlexandre NunoAlexandre commented Oct 18, 2022

Description

Upgrading centrifuge-chain to the latest Polkadot version, v0.9.29

Fixes #976

Changes and Descriptions

This change also includes the upgrade to v0.9.28: https://github.com/paritytech/polkadot/releases/tag/v0.9.28

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • [] Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • cargo build --release
  • cargo test --workspace --release --features test-benchmarks,try-runtime,runtime-benchmarks

Checklist:

  • I have added Rust doc comments to structs, enums, traits and functions
  • I have made corresponding changes to the documentation
  • I have performed a self-review of my code
  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published in downstream modules
  • I rebased on the latest parachain branch

@NunoAlexandre
Copy link
Contributor Author

NunoAlexandre commented Oct 18, 2022

I'm pulling my hair out for this getrandom issue 🤯 all I find online suggests adding an explicit dependency on that crate, like so:

I've tried that + adding default-features = false and add that crate to the /std list.

When I do that, then the error becomes (in short):

error: failed to run custom build command for `centrifuge-runtime v0.10.14 (/Users/n/centrifuge/centrifuge-chain/runtime/centrifuge)`

Caused by:
  process didn't exit successfully: `/Users/n/centrifuge/centrifuge-chain/target/debug/build/centrifuge-runtime-60c64d492688fc79/build-script-build` (exit status: 1)
  --- stdout
  Information that should be included in a bug report.
  Executing build command: "/Users/n/.rustup/toolchains/nightly-2022-05-09-aarch64-apple-darwin/bin/cargo" "rustc" "--target=wasm32-unknown-unknown" "--manifest-path=/Users/n/centrifuge/centrifuge-chain/target/debug/wbuild/centrifuge-runtime/Cargo.toml" "--color=always" "--profile" "release"
  Using rustc version: rustc 1.62.0-nightly (cb1219871 2022-05-08)


  --- stderr
     Compiling secp256k1-sys v0.6.1
  The following warnings were emitted during compilation:

  warning: error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'
  warning: 1 error generated.
  warning: error: unable to create target: 'No available targets are compatible with triple "wasm32-unknown-unknown"'
  warning: 1 error generated.

  error: failed to run custom build command for `secp256k1-sys v0.6.1`

I was trying following the same logic and playing with the default-features and /std for secp256k1 but just spinning my wheels at this point.

@mikiquantum @branan do you maybe have some cue on how to tackle this one?

Edit: I have updated our internal repos that also depend on the parity repos with cargo update to ensure that all the repos are pointing to the same revisions of substrate/polkadot/cumulus but unfortunately that didn't cut it at this time.

Edit 2: interesting lead: interlay/interbtc#504 (comment)

@NunoAlexandre
Copy link
Contributor Author

Got it!

So get around the getrandom issue, I've added it as an explicit dependency with default-features = false and `features = ["js"]' to the root Cargo, and to each of the runtime's Cargo files. I may be wrong but when I just tried adding it to the root Cargo it didn't' seem to work but we should double check.

Past that point I bumped into the secp256k1-syserror reported here; On my machine, an Apple M1, I was able to get around that by installing zig (brew install zig) and retried building with CC="zig cc" cargo build --release. I then faced some substrate-relaed compilation errors, symtoms of some default-features not being set properly (it failed to compile some substrate crates because it didn't know vec![] etc).

At this point I built each runtime separately and realised that altair compiled fine but centrifuge and development failed. So I cherry picked which crates those two runtimes depended on that altair did not and found out that our pallet-claims had some substrate dependencies with default-features = true; setting those to false did the trick, and now we are back to getting the normal and expected update compilation errors 🎉

cc @gruberb

@NunoAlexandre
Copy link
Contributor Author

@gruberb I've just cleaned up the changes I added for the getrandom fix. Let me know if I can help any further, otherwise leaving the rest up to you 👍

@@ -1252,8 +1252,8 @@ impl_runtime_apis! {
let weight = Executive::try_runtime_upgrade().unwrap();
(weight, RuntimeBlockWeights::get().max_block)
}
fn execute_block_no_check(block: Block) -> Weight {
Executive::execute_block_no_check(block)
fn execute_block(block: Block, state_root_check: bool, try_state: TryStateSelect) -> Weight;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Have to figure out how this is actually used vs. and if we used execute_block_no_check in the past.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ASAIR the no-check prevents digest checks for block building. Do not think we can anything about the change and hopefully parity has this correctly ^^

@gruberb gruberb marked this pull request as ready for review October 24, 2022 11:20
@gruberb
Copy link
Contributor

gruberb commented Oct 24, 2022

This PR is finally ready for review! I am currently trying to figure out why one loans benchmark test is failing, but the logic etc. can be reviewed!

Copy link
Collaborator

@mustermeiszer mustermeiszer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some questions and some feature flags that must be set true in dev. Furthermore, there are a few lines that need to be changed in the integrations-tests for instanciating a timestamp.

But damn, this was a lot of work! Thanks, @gruberb!!

libs/proofs/Cargo.toml Outdated Show resolved Hide resolved
libs/traits/Cargo.toml Show resolved Hide resolved
pallets/claims/Cargo.toml Outdated Show resolved Hide resolved
pallets/collator-allowlist/Cargo.toml Outdated Show resolved Hide resolved
pallets/crowdloan-reward/Cargo.toml Show resolved Hide resolved
runtime/integration-tests/src/pools/utils/env.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/pools/utils/env.rs Outdated Show resolved Hide resolved
scripts/frame-weight-template.hbs Outdated Show resolved Hide resolved
scripts/runtime-weight-template.hbs Outdated Show resolved Hide resolved
src/service.rs Show resolved Hide resolved
NunoAlexandre and others added 22 commits October 25, 2022 09:13
Having it on the root Cargo.toml is enough :)
I just realized that we probably only needed this because we were
importing dependencies from pallet-claims with the default-features
enabled, which caused getrandom from being pulled with enabled std WHILE
trying to build it for wasm, which caused the failing compilation
error. Now that those dependencies are imported correctly with
default-features = false, we in fact don't need this getrandom
workaround anymore :)
* loans benchmarks: ensure generated rates match our rules
* integration tests: Do not create duplicate NFT class

I have no idea how either of thesee was working before ¯\_(ツ)_/¯
@gruberb
Copy link
Contributor

gruberb commented Oct 25, 2022

All green now, and comments from @mustermeiszer resolved! Should we try to merge this soon? @branan @NunoAlexandre

Copy link
Collaborator

@mustermeiszer mustermeiszer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gruberb Just a small change needed. Then I will make this green ^^

runtime/integration-tests/src/pools/utils/env.rs Outdated Show resolved Hide resolved
runtime/integration-tests/src/pools/utils/env.rs Outdated Show resolved Hide resolved
Copy link
Collaborator

@mustermeiszer mustermeiszer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for adapting.

@gruberb gruberb merged commit 25fed2e into main Oct 25, 2022
@NunoAlexandre NunoAlexandre deleted the polkadot-v0.9.29 branch November 14, 2022 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade to Polkadot v0.9.29
4 participants