[v22.0.x] backport: release v22.0.0-rc2 #6432
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
c5d5b14 ci: add powerpc64 to GH Guix job matrix (UdjinM6) Pull request description: ## Issue being fixed or feature implemented I guess we should make sure that binaries for every possible platform can be built via Guix with no issues even if we do not want to provide "official" binaries for it. ## What was done? ## How Has This Been Tested? ## Breaking Changes ## Checklist: - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ Top commit has no ACKs. Tree-SHA512: 6464b68a47e680bb379c82842599200d6917adb8f1493fa75ac80ddc7a6fea92a9190215cfa3f32b0bd88e2dd0425d4eb13846ea2d7e19e144afff9c1171ff13
2f18c1a ci: deduplicate depends building (pasta) Pull request description: ## Issue being fixed or feature implemented Currently we build the same host / options multiple times. Don't do this! ## What was done? Now building depends only twice ## How Has This Been Tested? Local CI appears to be working ## Breaking Changes None ## Checklist: _Go over all the following points, and put an `x` in all the boxes that apply._ - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: kwvg: utACK 2f18c1a UdjinM6: utACK 2f18c1a Tree-SHA512: 67460508a2e9458152f7c8bb5f4a1a786aedcfded0e5c54fb03d85010ba8bb87362b66a0c322b51aeba75752e36418fc235d8dc4197ef10695e234ccc5a00a39
9604d87 ci: cache depends/built like gitlab (pasta) Pull request description: ## Issue being fixed or feature implemented Depends build didn't seem to be caching properly ## What was done? changed depends/${{ matrix.host }} to depends/built as gitlab does ## How Has This Been Tested? Depends "build" now takes only ~1 minute instead of ~15 minutes in CI: https://github.com/PastaPastaPasta/dash/actions/runs/11899038167 ## Breaking Changes None ## Checklist: - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: utACK 9604d87 kwvg: utACK 9604d87 Tree-SHA512: 63d2321f41b284be6cc2f0b2d53294cf220b1623af464d411225c0e43ec14268e1c3a701e23973e5c641925b6ea28dcb92062d8cefb9e6baed6ac5bb619ce1a1
9cc29a8 ci: use `actions/cache` to manage depends cache (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Builds after [dash#6401](dashpay#6401) have silently stopped building Dash Qt, see pre-[dash#6401](dashpay#6401) `develop` (6a51ab2)'s [build](https://github.com/dashpay/dash/actions/runs/11881892222/job/33106960691#step:7:725) compared against [build \#1](https://github.com/PastaPastaPasta/dash/actions/runs/11897504945/job/33152711720#step:7:1432) and [build \dashpay#2](https://github.com/kwvg/dash/actions/runs/11898510091/job/33156186503#step:7:1432) from [dash#6401](dashpay#6401 review process. This pull request aims to correct that regression. ## Breaking Changes None expected. ## Checklist - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK dashpay@9cc29a8 UdjinM6: utACK 9cc29a8 Tree-SHA512: 09663987696d29e12c98b48297960c7c1e6484e337ddc8311f340fee1d026ace572674e8cbca578ba743ff781caabb6fcc1853cee8ddff3e13af3fe3d0361776
…f CL 3f2e064 refactor: set `const auto& cbTx` to avoid using optional throughout method (pasta) 0c0d91e fix: functional test feature_llmq_chainlocks.py should activate MN_RR instead v20 (Konstantin Akimov) af93e87 refactor: removed pre-MN_RR logic of validation of CL (Konstantin Akimov) Pull request description: ## Issue being fixed or feature implemented The fork MN_RR is active awhile on testnet and mainnet and no more need legacy check ## What was done? Removes legacy version of checks for CL and related functional tests ## How Has This Been Tested? Run unit / functional test - DONE Reindex testnet - DONE Reindex mainnet - DONE ## Breaking Changes Removed pre-mn_rr version of checks for CL. It's no more relevant on mainnet and testnet. It affects behavior on new devnets and regtest for pre-mn_rr activation blocks. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [x] I have added or updated relevant unit/integration/functional/e2e tests - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone ACKs for top commit: UdjinM6: utACK 3f2e064 Tree-SHA512: 8b4b3a20a54602f4df9d98e17c79004214493b15c0bce9c08c68d667a5cba86b817947f008d646c48ef9f2f86676c02085c7d0ed36e83548ef5425b64faffb89
5078bae fix(test): wait for chainlock before mining a block we expect to include said chainlock (pasta) f39c1e6 fix: guard m_can_tx_relay behind m_tx_relay_mutex; make it private; add additional annotations (pasta) Pull request description: ## Issue being fixed or feature implemented See each commit; fixes two bugs, both discovered while running feature_llmq_chainlocks.py with tsan / debug. one a datarace in net_processing.cpp and the other in the test I was using to ensure this fix was correct, feature_llmq_chainlocks ## What was done? ### net_processing.cpp You can see the datarace here: https://gist.github.com/PastaPastaPasta/c966a9f805758b34524085e3d52ea7f8 We simply guard it with an existing mutex that is always locked in close proximity. ### feature_llmq_chainlocks.py Most of the time, while generating the cycle quorum, there is sufficient time to generate a chainlock; however, this is racey, and I've observed locally where the block gets generated before a chainlock is present and as such `test_coinbase_best_cl` fails. We should instead wait for the chainlock first, and then mine the block. This was we can ensure the mined block will include that chainlock. This was observed locally maybe 1/10 times or so ## How Has This Been Tested? ran feature_llmq_chainlocks.py ~40 times locally with tsan / debug ## Breaking Changes None ## Checklist: _Go over all the following points, and put an `x` in all the boxes that apply._ - [x] I have performed a self-review of my own code - [x] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: kwvg: utACK 5078bae knst: utACK 5078bae UdjinM6: utACK 5078bae Tree-SHA512: b346fc60809df72d0161f625073dce7062bd2641d35e4f80160fac9afeec63707de552e2856940ac2604875908ae3b98a225d352de36bfbfc6ee3fbe1e1538ff
…into net processing / peerman dafa736 fix: respect SENDDSQUEUE message, move DSQ relay into net processing / peerman (pasta) Pull request description: ## Issue being fixed or feature implemented in dashpay#6148, I broke the functionality where a peer must opt in / opt out of DSQUEUE messages. This was mostly ok, and not immediately detected, as with this bug, simply everyone would receive DSQ messages over inventory (or classically, old proto versions were not affected by this bug). But this still would result in quite a bit of wasted bandwidth for peers which may not care about DSQ at all. ## What was done? This commit should restore the prior functionality, where a node should send the SENDDSQUEUE message if they wish to receive DSQs. Once they've sent that, depending on their protocol version, they will either have the messages pushed to them as available, or on modern protocols, they will thereafter receive DSQs over the inventory system. NOTE: I also refactor the code in this commit, moving some network proccessing into.... wait for it... net_processing.cpp! This allowed us to remove some dependencies in coinjoin.h. DSQ messages are now relayed to peers by calling peer_manager.RelayDSQ ## How Has This Been Tested? I have not yet mixed on testnet with this; we should include it in rc.2 and test ## Breaking Changes Slightly breaking for v22.0.x (so rc.1), as they in theory could be relying on this new logic of always receiving the DSQ inv. But I don't think anyone besides core is using this new protocol. ## Checklist: _Go over all the following points, and put an `x` in all the boxes that apply._ - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone ACKs for top commit: UdjinM6: light ACK dafa736 kwvg: utACK dafa736 Tree-SHA512: 18f9b0dfe05cde19db451653db9bb9a00352efd1bc37adffd83f74958010475f2782b1111b1c0d2dd967e7a851c3c4795fa55033b4bd0cc810aa293e754ce314
…lease-process.md` 87c31ad Update doc/release-process.md (UdjinM6) 55d7463 docs: mention building for some HOSTs only in `release-process.md` (UdjinM6) Pull request description: ## Issue being fixed or feature implemented dashpay/guix.sigs#73 dashpay#6390 follow-up ## What was done? ## How Has This Been Tested? ## Breaking Changes ## Checklist: - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ Top commit has no ACKs. Tree-SHA512: b4a2cadf5899a8aea6612b4ff9c0e9f9c530a9e2344eb090967fbcf9a2ab219aff02f11f86434e4082f84c401d578cf2d033b6838c94705f532beca4ab604986
…id, checkpointData, chainTxData for mainnet and testnet 31243ca chore: update nMinimumChainWork, defaultAssumeValid, checkpointData, chainTxData for mainnet and testnet (pasta) Pull request description: ## Issue being fixed or feature implemented Bump chainparams in prep for v22 ## What was done? ## How Has This Been Tested? ## Breaking Changes ## Checklist: _Go over all the following points, and put an `x` in all the boxes that apply._ - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: UdjinM6: utACK 31243ca Tree-SHA512: 6a01bbbaefb69437e053340b968e0ce68e2bd9e5e5fd2900864d88ffc21c5cd3f9c2a50d8f5b19f16515cd4c62a4a8fc2d981dd6d0456e86ef96f40e350e786a
5741d5d chore: update seeds (Kittywhiskers Van Gogh) 2d732fc chore: drop defunct onion seeds, add new existing onion hosts as seeds (pasta) Pull request description: ## Issue being fixed or feature implemented Update onion seeds for upcoming version ## What was done? Update onion seeds to reflect latest status ## How Has This Been Tested? As of today, all of these are able to be connected to on port 9999; I've not actually connected to all of them and verified they're on latest core or something like that; but their addresses my core knows about, and are able to be trivially connected to ## Breaking Changes ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: kwvg: utACK 5741d5d UdjinM6: utACK 5741d5d Tree-SHA512: 541bcc510b2ebf6de08ac91f2b7e5b1c910536dca9bab0b38930d6e5cfa1cd05e8c014ba4c74c14c43ed211cda3275fffb5baaf1489bbd1221567130d804b0ec
|
This pull request has conflicts, please rebase. |
PastaPastaPasta
changed the title
|
This branch merged into master just fine for me: no conflicts |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What was done?
See commits for each particular change
How Has This Been Tested?
To be deployed on testnet
Breaking Changes
N/A
Checklist: