Skip to content

[v22.0.x] backport: release v22.0.0-rc2 - #6432

Merged
PastaPastaPasta merged 10 commits into
dashpay:v22.0.xfrom
knst:backports-to-22.0.0-rc2
Nov 26, 2024
Merged

[v22.0.x] backport: release v22.0.0-rc2#6432
PastaPastaPasta merged 10 commits into
dashpay:v22.0.xfrom
knst:backports-to-22.0.0-rc2

Conversation

@knst

@knstknst commented Nov 26, 2024

Copy link
Copy Markdown
Collaborator

What was done?

See commits for each particular change

How Has This Been Tested?

To be deployed on testnet

Breaking Changes

N/A

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)

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 \#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#73dashpay#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
@knstknst added this to the 22 milestone Nov 26, 2024
@PastaPastaPasta
PastaPastaPasta changed the base branch from develop to v22.0.xNovember 26, 2024 16:15
@github-actions

Copy link
Copy Markdown

This pull request has conflicts, please rebase.

@PastaPastaPastaPastaPastaPasta changed the title chore: release v22.0.0-rc2 - backports[v22.0.x] backport: release v22.0.0-rc2Nov 26, 2024
@PastaPastaPasta

Copy link
Copy Markdown
Member

This branch merged into master just fine for me:

git merge --ff-only knst/backports-to-22.0.0-rc2

no conflicts

@UdjinM6UdjinM6 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

utACK 8b88ff7

confirmed that it merges into master with no conflicts
(for some reason gh action just won't use the updated base ref on new attempts 🤷‍♂️ )

@PastaPastaPastaPastaPastaPasta left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

utACK 8b88ff7

@PastaPastaPasta
PastaPastaPasta merged commit a6ee725 into dashpay:v22.0.xNov 26, 2024
Sign up for freeto 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.

3 participants

@knst@PastaPastaPasta@UdjinM6