Repository navigation
backport: update man pages, translation strings, SECURITY.md and flatpak for v24.0.0 (#7974) - #7972
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
🕓 Review not started yet because the new head is waiting for the 30-minute push debounce.
Commit 80f6cbe. Normal review starts when eligible; priority review starts as soon as a slot is available. |
thepastaclaw
left a comment
There was a problem hiding this comment.
Final validation — Phase 1 + Phase 2
The PR contains release-maintenance changes only: regenerated v24.0.0 man pages and translation sources, plus SECURITY.md and Flatpak release metadata. The reviewed metadata, generated content, option documentation, and translation updates are consistent with the stated v24.0.0 preparation; no actionable in-scope issues were identified. The depends-source cache failure is unrelated infrastructure, while the container builds passed and manifest jobs were still queued.
Review provenance
Source: reviewer 1: muse-spark-1.3-contributor (agent: phase1-reviewer, role: general); reviewer 2: gpt-6.1-sol (agent: phase2-reviewer, role: general); reviewer 3: gpt-6.1-sol (agent: phase2-reviewer, role: dash-core-commit-history); final verifier: gpt-6.1-sol (agent: sol-verifier, role: final-verifier)
- Triage:
normalbygpt-6.1-sol(effort low) — This is a large release-maintenance diff spanning generated man pages, translation catalogs, Qt strings, metadata, and security documentation, but it does not change runtime-critical behavior or any critical surface. - Phase 1 reviewers:
muse-spark-1.3-contributor— general (completed, effort xhigh); agentphase1-reviewer - Phase 1 model:
muse-spark-1.3-contributor— not quota-gated; passed overgemini-3.8-flash-high(antigravity quota lookup failed),glm-5.3-flash(not used above high effort; tier asks max) - Fresh verifier:
gpt-6.1-sol— final-verifier; agentsol-verifier - Phase 2 reviewers:
gpt-6.1-sol— general (completed, effort high); agentphase2-reviewer,gpt-6.1-sol— dash-core-commit-history (completed, effort high); agentphase2-reviewer
…d and flatpak for v24.0.0 b8f10bc chore: update translation source strings for v24.0.0 (pasta) 97460f6 doc: regenerate man pages for v24.0.0 (pasta) cf37991 chore: add v24.0.0 release entry to flatpak metainfo (pasta) 000ccc6 docs: update supported versions in SECURITY.md for v24 (pasta) Pull request description: ## Issue being fixed or feature implemented For v24.0.0, several per-release files need updating, on develop first and then on `v24.0.x` by backport (#7972). The pattern follows the man page PRs #6928 and #7140 and the SECURITY.md PRs #6117, #6461 and #6552: - develop's man pages still describe v23.1.9; - `SECURITY.md` lists only 23.x as supported; - the flatpak metainfo has no 24.0.0 entry; - the translation source strings were last refreshed in February 2026, before the shared-masternode GUI and the other v24 Qt work. Translators haven't seen those strings. ## What was done? - `SECURITY.md`: added 24.x as supported. 23.x stays supported. - Flatpak metainfo: added a `24.0.0` entry with an estimated release date of 2026-11-05, above the existing `23.1.9` entry. - `doc/man/*.1`: v24.0.0 man pages. develop's man pages describe the latest release, as the v23.0.0 and v23.1.0 pages did when #6928 and #7140 put them on develop. These pages were generated with `contrib/devtools/gen-manpages.py` from a v24.0.0 build of the release branch, with `CLIENT_VERSION_IS_RELEASE` set temporarily and not committed. Every page reads `v24.0.0`, with no rc, git hash or `-dirty` suffix. - Translations: ran `make -C src translate` on develop to refresh `src/qt/dashstrings.cpp`, `src/qt/locale/dash_en.ts` and `src/qt/locale/dash_en.xlf`. `dash_en.ts` goes from 1652 to 2718 source entries, mostly from the shared-masternode GUI. Once this is merged, Transifex picks up the new strings. Pulling translated `.ts` files is a separate step that needs Transifex access. Backport note: in #7972 the translation source files are generated from `v24.0.x` itself, not cherry-picked. develop has a few strings that the release branch doesn't, so `v24.0.x`'s `dash_en.ts` has 2706 entries. The other files are the same on both branches. ## How Has This Been Tested? - Checked that every `doc/man/*.1` reads `v24.0.0` and contains no `-rc`, `-dirty` or git hash. - Built develop with Qt from depends to run `make -C src translate`. - `test/lint/lint-whitespace.py` and `test/lint/lint-files.py` pass. - `git diff upstream/develop --stat` touches only the 11 files listed above. ## Breaking Changes None. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: eb2f424ee2f5bb5968bc41cf7102cf845d4192d1345a620aec4498bafdfb7fbef6b2b9e0aca46b2dcf0338d4a47b409553c1ed3423ddfde54a30ea67519da3d2
…URITY.md and flatpak for v24.0.0 b8f10bc chore: update translation source strings for v24.0.0 (pasta) 97460f6 doc: regenerate man pages for v24.0.0 (pasta) cf37991 chore: add v24.0.0 release entry to flatpak metainfo (pasta) 000ccc6 docs: update supported versions in SECURITY.md for v24 (pasta) Pull request description: ## Issue being fixed or feature implemented For v24.0.0, several per-release files need updating, on develop first and then on `v24.0.x` by backport (dashpay#7972). The pattern follows the man page PRs dashpay#6928 and dashpay#7140 and the SECURITY.md PRs dashpay#6117, dashpay#6461 and dashpay#6552: - develop's man pages still describe v23.1.9; - `SECURITY.md` lists only 23.x as supported; - the flatpak metainfo has no 24.0.0 entry; - the translation source strings were last refreshed in February 2026, before the shared-masternode GUI and the other v24 Qt work. Translators haven't seen those strings. ## What was done? - `SECURITY.md`: added 24.x as supported. 23.x stays supported. - Flatpak metainfo: added a `24.0.0` entry with an estimated release date of 2026-11-05, above the existing `23.1.9` entry. - `doc/man/*.1`: v24.0.0 man pages. develop's man pages describe the latest release, as the v23.0.0 and v23.1.0 pages did when dashpay#6928 and dashpay#7140 put them on develop. These pages were generated with `contrib/devtools/gen-manpages.py` from a v24.0.0 build of the release branch, with `CLIENT_VERSION_IS_RELEASE` set temporarily and not committed. Every page reads `v24.0.0`, with no rc, git hash or `-dirty` suffix. - Translations: ran `make -C src translate` on develop to refresh `src/qt/dashstrings.cpp`, `src/qt/locale/dash_en.ts` and `src/qt/locale/dash_en.xlf`. `dash_en.ts` goes from 1652 to 2718 source entries, mostly from the shared-masternode GUI. Once this is merged, Transifex picks up the new strings. Pulling translated `.ts` files is a separate step that needs Transifex access. Backport note: in dashpay#7972 the translation source files are generated from `v24.0.x` itself, not cherry-picked. develop has a few strings that the release branch doesn't, so `v24.0.x`'s `dash_en.ts` has 2706 entries. The other files are the same on both branches. ## How Has This Been Tested? - Checked that every `doc/man/*.1` reads `v24.0.0` and contains no `-rc`, `-dirty` or git hash. - Built develop with Qt from depends to run `make -C src translate`. - `test/lint/lint-whitespace.py` and `test/lint/lint-files.py` pass. - `git diff upstream/develop --stat` touches only the 11 files listed above. ## Breaking Changes None. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: eb2f424ee2f5bb5968bc41cf7102cf845d4192d1345a620aec4498bafdfb7fbef6b2b9e0aca46b2dcf0338d4a47b409553c1ed3423ddfde54a30ea67519da3d2 (cherry picked from commit 79a220f)
The dashpay#7974 cherry-pick brings develop's translation source files, which contain strings that only exist on develop. Replace them with the output of `make -C src translate` on this branch (from 2a6b76f), so the English source file matches the code that ships in v24.0.0. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Matches the entry develop already has, so merging back stays clean. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
445b9d8 to
80f6cbe
Compare
|
This pull request has conflicts, please rebase. |
914c052 docs: add #8003 to the v24.0.0 release notes and man pages (pasta) e81c511 Merge #8003: fix(net): don't refuse to start over the automatic onion service unless -listenonion=1 (merge-script) 41b4578 ci: run cppcheck as test/lint/cppcheck-dash.py, as develop does since #7966 (pasta) c97f3b3 docs: regenerate man pages for v24.0.0-rc.6 (pasta) 784312c docs: add the v24.0.0-rc.6 changes to the v24.0.0 release notes (pasta) f15a53a Merge #7991: fix(qt): shared masternode wizard fixes for taken shares, unconfirmed funding and reply handling (merge-script) 1c46224 Merge #7995: fix(wallet): don't let a waiting CoinJoin promotion/demotion queue block standard mixing (merge-script) 546db2f Merge #7996: fix(wallet): fill a CoinJoin promotion with sibling coins when needed (merge-script) 349859f Merge #7957: fix(qt): validate shared-masternode shares with the consensus rules (merge-script) 9091f0b Merge #8005: backport: bitcoin#27114, bitcoin#33395 (merge-script) e915ab5 Merge #7990: fix(wallet): pay for 3 byte input and output counts so 253+ input sends work (merge-script) Pull request description: ## Issue being fixed or feature implemented Backports and release prep for v24.0.0-rc.6, on top of `v24.0.x` at d693c69 (the v24.0.0-rc.5 tag 8163290 plus the 2026-10 translations, #7989). After this PR, rc.6 only needs tagging and building. ## What was done? Cherry-picked (`git cherry-pick -m1 -x`) every develop merge since rc.5 that carries `backport-candidate-24.0.x`, in develop merge order: - #7990 fix(wallet): pay for 3 byte input and output counts so 253+ input sends work - #8005 backport: bitcoin#27114, bitcoin#33395 - #7957 fix(qt): validate shared-masternode shares with the consensus rules - #7996 fix(wallet): fill a CoinJoin promotion with sibling coins when needed - #7995 fix(wallet): don't let a waiting CoinJoin promotion/demotion queue block standard mixing - #7991 fix(qt): shared masternode wizard fixes for taken shares, unconfirmed funding and reply handling (labeled for 24.0.x, milestone 24.1) - #8003 fix(net): don't refuse to start over the automatic onion service unless -listenonion=1 (picked after the CI commit below, once it merged) Every pick changes exactly the same lines as its develop merge, except for one test-only adaptation in #8005, described in its commit message, and #8003's `doc/release-notes-7300.md` hunk, which lands in `doc/release-notes.md` (that file was folded in for v24.0.0 by #7970). bitcoin#27114 makes `wallet_import_rescan.py` restart its pruned nodes with their real `-prune` arguments; before, the restart passed only `-whitelist`, so they never actually ran pruned. On develop, #7860 removed the governance-disabled warning that pruned nodes print to stderr. This branch doesn't have #7860, so the test failed at shutdown on the unexpected stderr. The pick now stops the pruned nodes at the end of `run_test` with `EXPECTED_STDERR_NO_GOV_PRUNE`, the way `feature_pruning.py` does. Release prep, in commits after the picks: - `doc/release-notes.md`: `doc/release-notes-27114.md` is folded in and removed, as rc.5 did with the other individual notes (#7970). Also added: #8005's change that address-based `-whitelist` permissions no longer apply to onion inbound peers, and the CoinJoin conversion behaviour from #7995 and #7996. #7990, #7957 and #7991 fix code that is new in v24, so they get no release note. - #8003's release-note change replaces the v24 bullet that said nodes with `-bind` and no onion bind "refuse to start", in a separate docs commit after the #8003 pick that also regenerates `dashd.1` and `dash-qt.1` for its `-bind`/`-listenonion` help. - `doc/man/*.1`: regenerated with `contrib/devtools/gen-manpages.py` from a build of this branch with `CLIENT_VERSION_IS_RELEASE` set temporarily (not committed), as in #7974. Every page reads `v24.0.0`. They pick up #8005's `-whitelist`, `-whitelistrelay`, `-whitelistforcerelay` and `-blocksonly` help changes, and the `-assumevalid` defaults from #7980, which merged after the v24.0.0 man pages were generated. One CI-only commit follows the first six picks. Pull requests into `v24.0.x` run develop's workflow files (`pull_request_target`), and since #7966 develop runs cppcheck in its own job as `test/lint/cppcheck-dash.py`. This branch still had `test/lint/lint-cppcheck-dash.py`, so that job failed with "No such file or directory". The commit takes only #7966's rename (the script is unchanged), which also keeps develop's lint job from running cppcheck a second time through `all-lint.py`. This branch's own `lint.yml` now calls the renamed script after `ci/dash/lint.sh`, so its push CI still runs cppcheck. The rest of #7966 (the ci-slim cppcheck build and the separate job) is left out. Nothing else needs to change for the tag: - `configure.ac` is already 24.0.0 with `CLIENT_VERSION_IS_RELEASE` false, so the build takes its version string from the `v24.0.0-rc.6` tag. - The 2026-10 translations are already on the branch (#7989). - `SECURITY.md` and the flatpak entry were done in #7972. ## How Has This Been Tested? Linux x86_64 against depends, `--enable-debug --enable-werror --disable-hardening`. `dashd`, `dash-qt`, `test_dash` and `test_dash-qt` build cleanly. - `make check`: all unit suites pass, and `test_dash-qt` passes (run with `QT_QPA_PLATFORM=minimal`). - Functional tests, all passing: every test #8005 touches that the runner lists (`feature_cltv.py`, `feature_csv_activation.py`, `feature_dersig.py`, `feature_fee_estimation.py`, `interface_rest.py`, `interface_zmq.py`, `mempool_packages.py`, `p2p_filter.py`, `p2p_invalid_block.py`, `p2p_permissions.py`, `rpc_packages.py`, `rpc_rawtransaction.py`, `wallet_abandonconflict.py`, `wallet_avoidreuse.py`, `wallet_backup.py`, `wallet_balance.py`, `wallet_basic.py`, `wallet_create_tx.py`, `wallet_fundrawtransaction.py`, `wallet_groups.py`, `wallet_hd.py`, `wallet_import_rescan.py`, `wallet_importdescriptors.py`, `wallet_listreceivedby.py`, `wallet_listsinceblock.py`, `wallet_listtransactions.py`, `wallet_send.py`), plus `feature_bind_extra.py`, `feature_masternode_shares.py` and `rpc_coinjoin.py`. - After the #8003 pick: `feature_bind_extra.py`, `feature_proxy.py`, `interface_zmq.py`, `p2p_permissions.py` and `torcontrol_tests` pass. #8003 changes the framework's port allocation, so the full non-extended functional suite was run as well: 313 passed, 12 skipped, 0 failed (`test_runner.py -j12` on a RAM disk). - `wallet_import_rescan.py --legacy-wallet` failed before the adaptation above and passes with it. - Each pick's changed lines were compared with its develop merge. - Checked that every `doc/man/*.1` reads `v24.0.0` with no rc, git hash or `-dirty` suffix. ## Breaking Changes Carried over from the picked PRs: - #8005: address-based `-whitelist` permissions no longer apply to peers that connect through the onion service. Before, an entry such as `-whitelist=noban@127.0.0.1` gave every Tor peer its permissions. `-whitelist` also accepts `in`/`out` flags, so its permissions can apply to manual outbound connections; the default is still incoming only. - #8003, relative to rc.5: nodes with `-bind` and no `=onion` bind start again, as on v23, and get the default onion bind unless `-listenonion=0` is set. If the default onion bind fails, the node starts without an onion service, unless `-listenonion=1` was set explicitly. A wildcard `=onion` bind is still an error while `-listenonion` is enabled; v23 accepted it. - #7990: in wallets with 253 or more spendable coins, changeless transactions pay for 2 more bytes of fee. - #7995: while a wallet still has coins to mix, it joins promotion/demotion queues that others opened, but opens its own only when it has no standard mixing session to join or start. ## Checklist: - [x] I have performed a self-review of my own code - [x] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: 2dfc830eb45d7fbd5d39066fcd9cdb783340b28f15ac5e78c85aedfb2d8eae7d42a1c291811a5ce8e899a675e1144324eda9dca8824108e236a514dbe0297a7e
Issue being fixed or feature implemented
Backport of #7974 (develop, merged as 79a220f) to
v24.0.x. It follows the usual develop-first pattern: #6928 and #7140 for man pages, #6117, #6461 and #6552 for SECURITY.md.Commits:
git cherry-pick -m1 -x 79a220fe72bc. The man pages andSECURITY.mdare identical to develop. The conflicts only came from this branch's different base files: man pages take chore: update man pages, translation strings, SECURITY.md and flatpak for v24.0.0 #7974's version, and the flatpak metainfo gets chore: update man pages, translation strings, SECURITY.md and flatpak for v24.0.0 #7974's24.0.0entry.chore: use translation source strings generated from v24.0.x. chore: update man pages, translation strings, SECURITY.md and flatpak for v24.0.0 #7974'sdash_en.ts,dashstrings.cppanddash_en.xlfwere generated on develop and contain a few develop-only strings. This commit replaces them with the output ofmake -C src translateon this branch: 2706dash_en.tssource entries, against 2718 on develop.chore: add the v23.1.9 release entry to flatpak metainfo. develop already has this entry; adding it here keeps merging back clean.What was done?
SECURITY.md: added 24.x as supported (23.x stays supported).24.0.0entry with an estimated release date of 2026-11-05. Also added the23.1.9entry that develop already has, so merging back stays clean.doc/man/*.1: regenerated withcontrib/devtools/gen-manpages.py. They were built withCLIENT_VERSION_IS_RELEASEtemporarily set (not committed) so that the pages readv24.0.0and not an rc/git-describe string, the same as the v23.0.0 pages.make -C src translaterefresheddashstrings.cpp,dash_en.tsanddash_en.xlf. That adds 1159 source strings (mostly the shared-masternode GUI) and removes 105 obsolete ones. Once this merges, Transifex picks up the new strings. Pulling translated.tsfiles has to be done separately, by someone with Transifex access.configure.acis left alone:CLIENT_VERSION_IS_RELEASEstaysfalseso rc.5 takes its version from the tag. Flipping it is the only change the final v24.0.0 tag needs on top of rc.5.How Has This Been Tested?
.1file contains-rc,-dirtyor a git hash.test/lint/lint-whitespace.pyandtest/lint/lint-files.pypass.git diff upstream/v24.0.x --statonly shows the 11 files listed above.Breaking Changes
None.
Checklist:
🤖 Generated with Claude Code