Repository navigation
backport: v0.26 bitcoin#26177 - #64
DCG-Claude wants to merge 1 commit into
Conversation
Potential PR merge conflictsThis is advisory only. It does not block CI, but it marks PRs that will likely need a rebase depending on merge order. If this PR merges firstThese open PRs will likely need a rebase:
|
|
This pull request has conflicts, please rebase. |
DCG-Claude
changed the title
These errors require consensus/params.h to be missing or half-included when versionbits.h is parsed, but versionbits.h includes chain.h which includes consensus/params.h before anything else, there is no include cycle or duplicated guard reaching it, and none of the six commits touches chain.h, versionbits.h, deploymentstatus.h or consensus/params.h; every other job compiling the same TUs passed. The nowallet excerpt shows only container teardown, no compile error, so this looks like a stale/incomplete build tree in those two containers rather than branch breakage — please rerun. 🤖 backportsys, on behalf of the Dash backport pipeline. |
DCG-Claude
changed the title
f84f3e0 to
8701881
Compare
DCG-Claude
changed the title
8701881 to
5728326
Compare
Added node/database_args.cpp to libdashkernel_la_SOURCES (build-system file): bitcoin#25862 makes index/base.cpp call node::ReadDatabaseArgs, and unlike upstream — which had removed index/*.cpp from libbitcoinkernel in f100687 before this PR — Dash's kernel library still compiles index/base.cpp, so the symbol was undefined in libdashkernel.so (nowallet/multiprocess link error). The multiprocess job's versionbits.h errors cannot come from this tree (versionbits.h includes chain.h which includes consensus/params.h, and nothing reachable from consensus/params.h includes versionbits.h, so no cycle exists); that looks like a stale incremental/ccache artifact and should clear on rerun once the link error is gone. (folded into the 🤖 backportsys, on behalf of the Dash backport pipeline. |
The failing headers (versionbits.h, deploymentstatus.h, chain.h, consensus/params.h) are untouched by every commit in this batch, and the reported errors require consensus/params.h to be skipped — impossible here, since chain.h includes it unconditionally and its own includes (uint256.h, llmq/params.h) form no cycle and no duplicate include guard exists. All files added by the batch are listed in src/Makefile.am, so the distdir build used by CI is complete. This looks like a stale/mutated workspace in the RUN_TIDY multiprocess job (its lint path rewrites includes in place with fix_includes.py --nosafe_headers); please rerun. 🤖 backportsys, on behalf of the Dash backport pipeline. |
|
This pull request has conflicts, please rebase. |
DCG-Claude
changed the title
5728326 to
3c85826
Compare
|
Branch rewritten at
🤖 backportsys, on behalf of the Dash backport pipeline. |
|
This pull request has conflicts, please rebase. |
The errors are in versionbits.h and deploymentstatus.h, where consensus/params.h is only half-read (Consensus::DeploymentPos missing, Consensus::Params incomplete). No commit in this batch touches those headers, chain.h or consensus/params.h, and none of the includes the batch added forms a loop back to them. Only the aarch64 multiprocess/tidy job reports it, so it looks environment-specific rather than caused by this backport, and a rerun should confirm; I couldn't get the full log to see which file failed, so if it happens again that log is what to check. 🤖 backportsys, on behalf of the Dash backport pipeline. |
None of the five backports touch the headers the errors point at (consensus/params.h, chain.h, versionbits.h, deploymentstatus.h), and with the files as they are these errors can't happen: chain.h includes consensus/params.h second, and consensus/params.h only pulls in uint256.h and llmq/params.h, so there is no include cycle that could leave Consensus::DeploymentPos or Params undefined. Errors saying the Consensus namespace exists but its contents don't mean the arm64 runner read a missing or truncated consensus/params.h (a damaged checkout, dist copy or ccache), which is a problem with the build environment, not this branch. I couldn't rebuild locally to confirm, so please rerun the job; if it fails the same way again, the full log naming the failing file would show where to look next. 🤖 backportsys, on behalf of the Dash backport pipeline. |
The quoted log is cut off before it names the file that failed. The errors are in versionbits.h and deploymentstatus.h, which this branch does not change, and every missing symbol (MAX_VERSION_BITS_DEPLOYMENTS, DeploymentPos, BuriedDeployment, ValidDeployment, the full Consensus::Params) is still defined in src/consensus/params.h, which is also unchanged and reached through chain.h in both headers. I checked every header this batch changed or added (validation.h, kernel/chainparams.h, kernel/_opts.h, txdb.h, dbwrapper.h, node/_args.h) and found no include cycle, header-guard clash or dropped include, so I made no change. Please rerun, or send the full compile error ('In file included from' chain and file name) so I can place a fix in the right commit if the branch is at fault. 🤖 backportsys, on behalf of the Dash backport pipeline. |
DCG-Claude
changed the title
3c85826 to
97877ba
Compare
|
Branch rewritten at
🤖 backportsys, on behalf of the Dash backport pipeline. |
|
This pull request has conflicts, please rebase. |
ddab1be to
0654da0
Compare
The CI IWYU step rewrites chain.h to forward-declare Consensus::Params instead of including consensus/params.h. versionbits.h relied on that transitive include for DeploymentPos/MAX_VERSION_BITS_DEPLOYMENTS, and bitcoin#26177's validation.h reorder (kernel/chainparams.h now after deploymentstatus.h) stopped hiding it. Added the missing #include <consensus/params.h> to versionbits.h; I reproduced the failure locally with the IWYU-edited chain.h and it is gone with the fix. (folded into the 🤖 backportsys, on behalf of the Dash backport pipeline. |
DCG-Claude
changed the title
0654da0 to
8c6e8c4
Compare
|
Branch rewritten at
🤖 backportsys, on behalf of the Dash backport pipeline. |
|
This pull request has conflicts, please rebase. |
8c6e8c4 to
f36ceda
Compare
DCG-Claude
changed the title
f36ceda to
9ab1778
Compare
|
This pull request has conflicts, please rebase. |
57982c0 to
e4d54cd
Compare
e4d54cd to
d45005f
Compare
d45005f to
d5fea03
Compare
…nctionality to kernel b3e78dc refactor: Don't use global chainparams in chainstatemanager method (TheCharlatan) 382b692 Split non/kernel chainparams (Carl Dong) edabbc7 Add factory functions for Main/Test/Sig/Reg chainparams (Carl Dong) d938098 Remove UpdateVersionBitsParameters (Carl Dong) 84b8578 Decouple RegTestChainParams from ArgsManager (Carl Dong) 76cd4e7 Decouple SigNetChainParams from ArgsManager (Carl Dong) Pull request description: This pull request is part of the `libbitcoinkernel` project bitcoin#24303 https://github.com/bitcoin/bitcoin/projects/18 and more specifically its "Step 2: Decouple most non-consensus code from libbitcoinkernel". dongcarl is the original author of this patchset, these commits were taken from https://github.com/dongcarl/bitcoin/tree/2022-03-libbitcoinkernel-chainparams-args-only. #### Context The bitcoin kernel library currently relies on code containing user configurations through the `ArgsManager`. This is not optimal, since as a stand-alone library it should not rely on bitcoind's argument parsing logic. Instead, its interfaces should accept control and options structs that control the kernel library's desired configuration. Similar work towards decoupling the `ArgsManager` from the kernel has been done in bitcoin#25290, bitcoin#25487, bitcoin#25527 and bitcoin#25862. #### Changes By moving the `CChainParams` class definition into the kernel and giving it new factory functions `CChainParams::{RegTest,SigNet,Main,TestNet}`it can be constructed without an `ArgsManager` reference, unlike the current factory function `CreateChainParams`. The first few commits remove uses of `ArgsManager` within `CChainParams`. Then the `CChainParams` definition is moved to a new file in the `kernel/` subdirectory. ACKs for top commit: MarcoFalke: re-ACK b3e78dc 🛁 ryanofsky: Code review ACK b3e78dc. Only changes since last review were recent review suggestions. ajtowns: ACK b3e78dc Tree-SHA512: 3835aca1d3e3c75cc3303dd584bab3a77e58f6c678724a5e359fe4b0e17e0763a00931ee6191f516b9fde50496f59cc691f0709c0254206db3863bbf7ab2cacd Dash adaptations: - src/kernel/chainparams.{h,cpp}: moves Dash's CChainParams and network classes (all DIP, LLMQ, masternode and spork parameters), not Bitcoin's - src/kernel/chainparams.{h,cpp}: adds CChainParams::DevNet(DevNetOptions) next to Main()/TestNet()/RegTest() for Dash's fourth network - src/kernel/chainparams.h: VersionBitsParameters, RegTestOptions and DevNetOptions carry Dash's extra -vbparams fields and regtest/devnet overrides - src/kernel/chainparams.cpp: LLMQ overrides arrive as quorum names and are resolved in the kernel constructors, which own the per-chain LLMQ list - src/kernel/chainparams.cpp: the devnet name comes from DevNetOptions::name instead of gArgs.GetDevNetName(), keeping the kernel gArgs-free - src/kernel/chainparams.cpp: the moved classes keep develop's current values (EvoSnapshotHash, V24 bit 13, EVO_SHARES; no fRequireStandard after bitcoin#28354) - src/deploymentinfo.cpp: GetBuriedDeployment() maps the 12 names -testactivationheight already accepted (bip147 ... mn_rr) instead of upstream's segwit - src/chainparams.cpp: Dash's arg readers stay split into ReadRegTest*/ReadDevNet* helpers, called from ReadRegTestArgs()/ReadDevNetArgs() - src/chainparams.cpp: -minimumdifficultyblocks/-highsubsidyblocks/-highsubsidyfactor are read as separate optionals, so they log three lines instead of one - src/validation.h: upstream's <fs.h> is not added; Dash uses util/fs.h - src/active/dkgsession.cpp, src/chainlock/signing.cpp, src/instantsend/net_instantsend.cpp and Dash tests: include <chainparams.h>, which validation.h no longer provides Not applicable to Dash (intentionally omitted): - src/kernel/chainparams.cpp: CSigNetParams and CChainParams::SigNet(); Dash has no signet - src/kernel/chainparams.h: SigNetOptions and the SigNet() declaration; Dash has no signet - src/chainparams.cpp: ReadSigNetArgs() and the SIGNET branch of CreateChainParams(); Dash has no signet - src/kernel/chainparams.cpp: segwit/taproot fields, script_flag_exceptions and bech32_hrp of Bitcoin's chain classes; Dash's classes have none - src/deploymentinfo.cpp: the "segwit" -> DEPLOYMENT_SEGWIT mapping; Dash has no segwit deployment
d5fea03 to
153aa3c
Compare
153aa3c Merge bitcoin#26177: refactor / kernel: Move non-gArgs chainparams functionality to kernel (DCG-Claude) Pull request description: <!-- backportsys v1 --> > 🔎 **Needs a careful look.** Commits are ordered by how much they were adapted: 🔴 heavy first, then 🟡 light (at most two invented lines), then 🟢 faithful (identical to upstream apart from context). ## Issue being fixed or feature implemented Backports 1 Bitcoin Core v0.26 pull request(s) that the Dash queue selected, including any discovered prerequisites: bitcoin#26177. ## What was done? | upstream | commit | review | gates | notes | |---|---|---|---|---| | bitcoin#26177 | `d5fea03a6c` | 🔴 heavy | build:pass ci_upstream:pass mech:warn pick:pass tests:pass tree:pass verify:pass | This backports bitcoin#26177: CChainParams and Dash's Main/TestNet/DevNet/RegTest classes move into kernel/cha | Each commit keeps the upstream subject (`partial Merge …` only where a hunk is deferred to a prerequisite still to be backported, named in the commit body; a hunk Dash intentionally never wants is recorded in the commit body or the reviewer's note above and does not make the backport partial). Conflicts were resolved commit by commit; commits that needed no resolution were cherry-picked unchanged. ## How Has This Been Tested? Recorded per commit, at that commit's own sha, not once for the branch: - built at each commit, reusing the worktree build cache - the test suites touched by each diff run at that commit, where the diff selected one - a mechanical diff-of-diffs against the upstream patch (every upstream hunk present, no added line without an upstream counterpart, no Dash-specific line dropped) - an independent verification pass on 1 commit(s) that needed adaptation - fork gate PR thepastaclaw#64 at `d5fea03a6c` — **no passing CI record at this head** Gates that did not come back clean — please weigh these: - bitcoin#26177 `mech`: **warn** — 878 invented line(s); 194 Dash-feature line(s) removed; 6 partial/prereq/low-risk finding(s) ## Breaking Changes None beyond the upstream changes themselves. ## Checklist: _Left for the reviewer; backportsys does not tick boxes on its own behalf._ - [ ] 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 --- ### Maintainer controls <!-- backportsys controls --> Tick a box and backportsys acts on it within a few minutes, then clears the box. For anything else — a hunk to drop, a resolution to redo, a question — just leave a review comment; nothing here needs a box. - [ ] 🔒 **Hands off** — stop every automated update to this branch <!-- bps:hands_off --> - [ ] 🔄 **Rebase** onto current `develop` <!-- bps:rebase --> - [ ] ❌ **Close** — abandon this batch and release its items <!-- bps:close --> <!-- /backportsys controls --> <!-- human notes below; the bot never edits this section --> Top commit has no ACKs. Tree-SHA512: d62000e84d48eaafd4bba81baf58f66fd075ba37e47c087743e44a96a793a8989c3388783ee5ab67c59951315496c09262ffcea0a555da57a776f9120c3d1109
|
merged as dashpay#7806 |
Automated Bitcoin Core v0.26 backports, batch
backport-0.26-b041-src.d5fea03a6cProvenance
Each commit passed: cherry-pick (adapted by an Opus lane only where conflicts existed), build, touched tests, a mechanical diff-of-diffs check (every upstream hunk landed; no added line without an upstream counterpart), and an independent Opus verification lane where anything was adapted. Gate rows and lane artifacts are in the backportsys DB.