fix: stabilize par help text in manpages - #7394
Conversation
|
@coderabbitai review |
|
✅ Review complete (commit 4e5cc4b) |
✅ Action performedReview finished.
|
✅ No Merge Conflicts DetectedThis PR currently has no conflicts with other open PRs. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
WalkthroughThe help text for Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
thepastaclaw
left a comment
There was a problem hiding this comment.
Code Review
Verified PR #7394 at exact head SHA 4e5cc4b. The diff is limited to stabilizing the -par and -parbls help/manpage text, the generated manpage entries match src/init.cpp, and the runtime parsing still supports auto, negative values, and max clamping as documented.
Note: posted as a COMMENT review because GitHub does not allow approving my own PR.
4e5cc4b fix: stabilize par help text in manpages (PastaClaw) Pull request description: # fix: stabilize par help text in manpages ## Issue being fixed or feature implemented Regenerating manpages currently records the local machine's CPU count in the `-par` and `-parbls` help text. That makes otherwise unrelated release manpage regeneration change those entries depending on which machine generated the pages. ## What was done? Updated the `-par` and `-parbls` help text to avoid printing the dynamic lower bound derived from `GetNumCores()`. Runtime behavior is unchanged: negative values still mean "leave that many cores free", `0` still auto-detects, and the existing max/default values remain documented. The checked-in `dashd` and `dash-qt` manpages were updated to match the new stable generated text. ## How Has This Been Tested? Tested on macOS arm64: ```bash git diff --check python3 -m py_compile contrib/devtools/gen-manpages.py rg -n -e '\\fB\\-[0-9]+\\fR to' doc/man/dashd.1 doc/man/dash-qt.1 ``` The grep command returned no matches, confirming the affected generated manpages no longer contain a CPU-count-specific lower bound. Also ran a pre-PR code review gate against the exact worktree diff: ```text Recommendation: ship ``` Note: this worktree did not have configured Dash Core build artifacts and `help2man` is not installed locally, so I did not rerun full manpage generation from rebuilt binaries here. The manpage edits mirror the changed `src/init.cpp` help text. ## Breaking Changes None. ## 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 - [x] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK 4e5cc4b UdjinM6: utACK 4e5cc4b Tree-SHA512: a547caf7f7dce3c2d4dc8295cba75d23da3870b90fd274ee9a3ebbcb2320d8415ef682afe5ce8a9cd56f6b1c979a9c5b7f680032aa2774fd2d61282fbb4007e5
Bump version metadata, refresh manpages, regenerate the example dash.conf with stable -par/-parbls help text (via dashpay#7394), update Flatpak metainfo, and archive current release notes. Co-Authored-By: Claude <noreply@anthropic.com>
Bump version metadata, refresh manpages, regenerate the example dash.conf with stable -par/-parbls help text (via dashpay#7394), update Flatpak metainfo, and archive current release notes. Co-Authored-By: Claude <noreply@anthropic.com>
The v23.1.8 release-prep regeneration was run against binaries configured with --enable-debug. configure.ac:373 makes that imply -DDEBUG_LOCKCONTENTION, and BCLog::LOCK / its "lock" string are both gated on that macro (logging.h:66, logging.cpp:177). Release binaries therefore reject -debug=lock with "Unsupported logging category", but the generated docs advertised it. This affected three generated files: doc/man/dashd.1, doc/man/dash-qt.1 and contrib/debian/examples/dash.conf (the last one was missed in the original report, but gen-dash-conf.sh reads the same binary). Removing the token reproduces release-build output byte-for-byte rather than approximating it: the v23.1.7 manpages were release-built, and diffing them against these files now leaves only the intended -par/-parbls rewording from dashpay#7394 (src/init.cpp:573,575). Line wrapping is unchanged because "lock, " sat mid-line in an already-filled paragraph. dash-cli/-tx/-util/-wallet are byte-identical to v23.1.7 apart from the version bump. DEBUG_LOCKCONTENTION is the only debug macro that reaches --help output; DEBUG_CORE only alters a runtime LogPackageVersion() line (init/common.cpp:176) and DEBUG_LOCKORDER touches no help text. Reported-by: UdjinM6 Co-Authored-By: Claude <noreply@anthropic.com>
4e5cc4b fix: stabilize par help text in manpages (PastaClaw) Pull request description: # fix: stabilize par help text in manpages ## Issue being fixed or feature implemented Regenerating manpages currently records the local machine's CPU count in the `-par` and `-parbls` help text. That makes otherwise unrelated release manpage regeneration change those entries depending on which machine generated the pages. ## What was done? Updated the `-par` and `-parbls` help text to avoid printing the dynamic lower bound derived from `GetNumCores()`. Runtime behavior is unchanged: negative values still mean "leave that many cores free", `0` still auto-detects, and the existing max/default values remain documented. The checked-in `dashd` and `dash-qt` manpages were updated to match the new stable generated text. ## How Has This Been Tested? Tested on macOS arm64: ```bash git diff --check python3 -m py_compile contrib/devtools/gen-manpages.py rg -n -e '\\fB\\-[0-9]+\\fR to' doc/man/dashd.1 doc/man/dash-qt.1 ``` The grep command returned no matches, confirming the affected generated manpages no longer contain a CPU-count-specific lower bound. Also ran a pre-PR code review gate against the exact worktree diff: ```text Recommendation: ship ``` Note: this worktree did not have configured Dash Core build artifacts and `help2man` is not installed locally, so I did not rerun full manpage generation from rebuilt binaries here. The manpage edits mirror the changed `src/init.cpp` help text. ## Breaking Changes None. ## 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 - [x] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK 4e5cc4b UdjinM6: utACK 4e5cc4b Tree-SHA512: a547caf7f7dce3c2d4dc8295cba75d23da3870b90fd274ee9a3ebbcb2320d8415ef682afe5ce8a9cd56f6b1c979a9c5b7f680032aa2774fd2d61282fbb4007e5 (cherry picked from commit dfe1e5d)
24920a0 chore: prepare v23.1.8 release (pasta) 2194248 Merge #7348: fix: penalize oversized notfound messages (pasta) f5c72c3 Merge #7347: fix: punish invalid dstx messages (pasta) 550caf7 Merge #7465: fix(qt): handle pixel-sized fonts when scaling widgets (pasta) e203710 Merge #7419: fix(net): bound CoinJoin message vector intake (pasta) 5f5b960 Merge #7418: fix(net): bound signing message vector intake (Pasta) 7cc2cca Merge #7450: test: make governance vote fixtures wire-valid (Pasta) f011c80 Merge #7440: fix(net): bound governance vote signature deserialization (Pasta) 4b4d96a Merge #7442: fix(net): authorize governance inv responses via the net-layer per-peer request tracker (Pasta) f855b13 Merge #7444: fix(net): bound bloom message vectors before allocation (Pasta) 5b5c6fb Merge #7415: fix: bound pending sig share queue (Pasta) 9bbe808 Merge #7416: fix(net): bound quorum data response vectors (Pasta) da42f50 Merge #7424: fix: bound ChainLock seen cache (Pasta) 5b310df Merge #7438: fix: bound SPORK signature deserialization (Pasta) e118d0c Merge #7259: fix: dangling point to cj client (Pasta) 9921621 Merge #7439: refactor: add bounded vector deserialization (Pasta) 89bdf7c Merge #7414: fix(net): throttle per-object governance vote sync requests (Pasta) 44c396d Merge #7402: fix: bound pending recovered sig queue to prevent remote OOM (Pasta) 05cfe27 Merge #7351: fix: limit signing share sessions per peer (pasta) 3ef3a5b Merge #7408: fix: bound DKG contribution blob intake (pasta) 0ea6532 Merge #7387: test: migrate governance inv cache coverage to unit tests (Pasta) 8ffdf7f Merge #7398: backport: compact block relay hardening (bitcoin#26898, bitcoin#27626, bitcoin#27743, bitcoin#26969, bitcoin#29412, bitcoin#32646, bitcoin#33296) (Pasta) 2915142 backport: bitcoin#27608 - p2p: Avoid prematurely clearing download state for other peers (PastaClaw) 90b5473 Merge #7396: fix: run of circular-dependencies with python3.15 (Pasta) b003cdc Merge #7395: ci: update GitHub Actions pins for Node 24 (pasta) 97c3dd1 Merge #7394: fix: stabilize par help text in manpages (pasta) 8f8616b Merge #7372: backport: bitcoin#32693: depends: fix cmake compatibility error for freetype (pasta) 48f72be Merge #7360: fix: empty platformP2PPort deprecated field in protx listdiff results (pasta) a8cccff Merge #7298: fix(qt): keep PoSe score visible when hiding banned masternodes (pasta) Pull request description: Release PR for Dash Core v23.1.8, a patch release on top of v23.1.7. Fast-forwards from `v23.1.x` (currently at `chore: prepare v23.1.7 release`), 29 commits, no merge commits, no conflicts. ## Contents Backports of PRs already reviewed and merged on `develop`: `#7259` `#7347` `#7348` `#7351` `#7298` `#7360` `#7372` `#7387` `#7394` `#7395` `#7396` `#7398` `#7402` `#7408` `#7414` `#7415` `#7416` `#7418` `#7419` `#7424` `#7438` `#7439` `#7440` `#7442` `#7444` `#7450` `#7465` Plus `backport: bitcoin#27608`, a single commit taken from Dash #7237 because #7398's compact-block hardening depends on it. The rest of that v0.26 batch is intentionally not included on v23.1.x. The commit is byte-identical to its reviewed counterpart inside #7237. And release preparation: version bump, regenerated man pages, release notes, archived 23.1.7 notes. ## Note for reviewers: this branch was rebuilt An earlier revision of this PR was discarded and the branch rebuilt from scratch. Review comments on the previous revision point at commits that no longer exist, though the feedback itself was carried over (see below). The reason: several commits titled `Merge #NNNN` in the earlier revision contained substantial code that exists nowhere upstream — apparently written from a description of each PR rather than ported from its diff. For example, `feature_llmq_simplepose.py` is byte-identical between v23.1.7 and `develop`, yet the earlier `Merge #7408` rewrote 66 lines of it; `test/functional/p2p_governance_invs.py` does not exist on `develop` at all, yet had grown from 62 to 148 lines. That mislabeling matters because a commit titled `Merge #NNNN` invites less scrutiny, not more. It also had consequences: the earlier revision was **missing #7440 entirely**, and contained eleven consecutive commits that did not compile (code written against newer upstream APIs this branch does not have — `Misbehaving(Peer&)`, and `PeerIsBanned` used five commits before it was declared). Every commit on this branch has now been diffed against its upstream merge commit. Where a backport differs, it is because v23.1.x predates an upstream refactor and the change had to be applied to the pre-refactor file — for example #7418 and #7438 patch `signing_shares.cpp` / `spork.cpp` where upstream patches `net_signing.cpp` / `net_processing.cpp`. ## Dropped from this branch - **#7350** (`net: don't lock cs_main while reading blocks`) — dropped on review feedback. It is a 110-line lock-structure refactor of `ProcessGetBlockData` with no measured benefit, and it would add avoidable churn to the eventual master→develop merge-back. Nothing on this branch depends on it: #7398's compact-block work precedes it, and the remaining 14 commits replay with zero conflicts once it is removed. Thanks @knst. ## Added after the initial review pass - **#7351** (`fix: limit signing share sessions per peer`) — cherry-picked as a single commit and placed before #7402, matching upstream's merge order. The include block additionally carries `<ranges>`: upstream's diff adds only `<algorithm>` because develop already had it, whereas v23.1.x did not and the backported `GetSessionCount()` / `GetAnnouncementSessionCount()` use `std::ranges::count_if`. - **#7465** (`fix(qt): handle pixel-sized fonts when scaling widgets`) — cherry-picked from the five upstream commits. `optiontests.cpp` additionally includes `qt/guiutil_font.h`, because `fontsLoaded()` and `updateFonts()` are declared there on v23.1.x while develop declares them in `qt/guiutil.h`, which is all the upstream test includes. Two further backports were added later and applied without any adaptation -- their diffs are byte-for-byte identical to upstream: - **#7347** (`fix: punish invalid dstx messages`) - **#7348** (`fix: penalize oversized notfound messages`) ## Adaptations worth flagging - **#7360** — upstream gates `platformP2PPort` / `platformHTTPPort` in `protx listdiff` behind `IsServiceDeprecatedRPCEnabled()`. On 23.x those deprecated fields are deliberately not enforced through gating (see `bbcd9d543e6`), so shipping the gate as-is would silently drop two fields that v23.1.7 always returned. Changed to `if (true)` with a comment, per review feedback, keeping the block aligned with `develop`. The substantive fix from #7360 — reading the live port from `netInfo` instead of the always-zero scalar — is retained. - **#7415** — the pending-map caps (`MAX_PENDING_SIG_SHARES_PER_NODE`, `MAX_PENDING_SIG_SHARES_TOTAL`) are backported. The additional bound upstream places on batches awaiting verification is not, because it guards a condition that does not exist here: upstream's dispatcher pushes one task per batch inside an inner loop, whereas v23.1.x pushes a single looping worker per 10 ms tick. There is no unbounded task queue to bound. - **Man pages** — regenerated without the `lock` debug category, which only exists under `DEBUG_LOCKCONTENTION` and so is absent from release binaries. Thanks @UdjinM6 for catching this. ## Known CI failure macOS jobs are expected to fail. `actions/upload-artifact@v6` rejects filenames containing `:`, and the Xcode SDK ships Perl man pages with `::` in the name. A release-branch-only workaround existed on the earlier revision but was dropped as it corresponds to no upstream PR. This is accepted for this release. ## Testing - Every commit through #7465 compiles individually (verified for 27 of the 29; the three additions below were verified at the tip) — verified individually, not just at the tip. - Full build clean; no new warnings. - Unit tests pass. - Functional tests pass: `feature_llmq_signing` (both variants), `feature_llmq_chainlocks`, `feature_llmq_dkgerrors`, `feature_llmq_is_cl_conflicts`, `p2p_instantsend`, `feature_dip3_deterministicmns` (both wallet types), `rpc_coinjoin`. - Qt unit tests pass (32 cases, run under the `cocoa` platform plugin so the pixel-sized font regression from #7465 actually executes rather than self-skipping). - Lint: one pre-existing `lint-cppcheck-dash` failure, identical on v23.1.7, in files this branch does not touch. Top commit has no ACKs. Tree-SHA512: 0fa469c9a33820aa85fbb8b90c5877409d09490f746f1300b05ceda470a600765f900bec42e5aad5d90a2d46b44e28c20e44dc4a8fe719553a072298069eaec4
fix: stabilize par help text in manpages
Issue being fixed or feature implemented
Regenerating manpages currently records the local machine's CPU count in the
-parand-parblshelp text. That makes otherwise unrelated releasemanpage regeneration change those entries depending on which machine generated
the pages.
What was done?
Updated the
-parand-parblshelp text to avoid printing the dynamic lowerbound derived from
GetNumCores().Runtime behavior is unchanged: negative values still mean "leave that many
cores free",
0still auto-detects, and the existing max/default values remaindocumented. The checked-in
dashdanddash-qtmanpages were updated to matchthe new stable generated text.
How Has This Been Tested?
Tested on macOS arm64:
git diff --check python3 -m py_compile contrib/devtools/gen-manpages.py rg -n -e '\\fB\\-[0-9]+\\fR to' doc/man/dashd.1 doc/man/dash-qt.1The grep command returned no matches, confirming the affected generated
manpages no longer contain a CPU-count-specific lower bound.
Also ran a pre-PR code review gate against the exact worktree diff:
Note: this worktree did not have configured Dash Core build artifacts and
help2manis not installed locally, so I did not rerun full manpage generationfrom rebuilt binaries here. The manpage edits mirror the changed
src/init.cpphelp text.
Breaking Changes
None.
Checklist
code-owners and collaborators only)