The "zeromq" feature is already enabled by default in `vcpkg.json`, and
there appears to be no reason to omit this configuration option when
building on Windows.
2e27bd9c3af91eb9fcc626fe65d065df0a80974d ci: Add Windows + UCRT jobs for cross-compiling and native testing (Hennadii Stepanov)
bd130db994e2a3a137bf232e5cc0ed164aa58b17 ci: Rename items specific to Windows + MSVCRT (Hennadii Stepanov)
Pull request description:
This PR is part of the ongoing effort to migrate to the modern UCRT runtime for cross-compiled Windows binaries, including release builds.
For more details about this migration, see:
- https://github.com/bitcoin/bitcoin/issues/30210
- https://github.com/bitcoin/bitcoin/pull/33593
MSVCRT-related CI jobs should be removed from the CI framework once the migration to UCRT is complete.
ACKs for top commit:
maflcko:
review ACK 2e27bd9c3af91eb9fcc626fe65d065df0a80974d 🖊
fanquake:
ACK 2e27bd9c3af91eb9fcc626fe65d065df0a80974d
Tree-SHA512: 222ca5e54646bcce9db6e20191d5891e988274e18b2f30085de6435a3b288a9d0fc414e8f76342e275ae58ee6603f751933d1faa8bdff446edf2695091f8ca4c
Empty public keys in tapscript are rejected by consensus rules, independent of SCRIPT_VERIFY_STRICTENC. Add SCRIPT_ERR_TAPSCRIPT_EMPTY_PUBKEY to distinguish this from STRICTENC policy failures currently reported as SCRIPT_ERR_PUBKEYTYPE.
libfreetype and libfontconfig are our two remaining runtime libs for
bitcoin-qt. According to #29977 Ubuntu 22.04 should be considered the
baseline for what is supported. Document that.
Closes#29977.
3e01b5d0e7be3dabe7f52d70e577f03f31505ad9 contrib: rename gen-sdk to gen-sdk.py (fanquake)
c1213a35abed01a97a9c52954919158f91f974d2 macdeploy: disable compression in macOS gen-sdk script (fanquake)
a33d03454508187abed764e55351ffcececc4c6e contrib: more selectively pick files for macOS SDK (fanquake)
Pull request description:
This includes three changes. The first is to more selectively pick files for inclusion into our macOS SDK tarball (skip manpages, binaries etc), which is nice because it redues the size of the tarball (from ~80mb to 20mb), and makes the size increase that happens with the next commit, less-bad.
The second change removes compression of the tarball. Starting with Python 3.11, Pythons gzip might delegate to zlib. Depending on the OS, i.e Ubuntu vs Fedora, the underlying zlib implementation might differ, resulting in different output.
For now, or until a better solution exists, remove compression. This results in the SDK increasing in size to ~157mb. Which is not unreasonable, to regain determinism (and would be significantly worse without the previous commit).
See: https://docs.python.org/3/library/gzip.html#gzip.compress
The third renames `gen-sdk` to `gen-sdk.py`, so that it will be linted, along with the rest of our Python files.
Fixes#31873. We could probably also put this into 30.x.
ACKs for top commit:
stickies-v:
ACK 3e01b5d0e7 modulo the new .tar SDK being uploaded
davidgumberg:
Tested ACK 3e01b5d0e7be3d
Tree-SHA512: 272164a98e0e6f10822870162c1b3a405693c2f64d3ed085a2d2243a48641d940704b5ef6022256915ac9cf383e87a4f8d4dc2ec4eaa9d25e2abd30f5498778b
e07e57368e9fab8ecfc140d44aef7db9b23c7ce0 ci: clear out space on centos job (will)
Pull request description:
Fixes#33293
Clear out space on jobs running on GHA by deleteing unnecessary files.
Raised in #33293 which pointed to a solution like b7f04d7822 which is adapted slightly here.
Only runs when cache provider (runner) is `gha`.
A run on my fork can be seen here: https://github.com/willcl-ark/bitcoin/actions/runs/19703413734/job/56444984809
ACKs for top commit:
maflcko:
lgtm ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
m3dwards:
ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
janb84:
ACK e07e57368e9fab8ecfc140d44aef7db9b23c7ce0
Tree-SHA512: 723589df4c434dd3eaed43acefe25f1788837743882e910e79eceee25e2bd98990cd01b8b80a46ba82418867b32c5ee1b96341223696244504e118eae6ad4a16
c0bfe72f6e1f63e05772eda959137b3d0bbbf6c3 Change Parse descriptor argument to string_view (Sjors Provoost)
Pull request description:
While investigating a silent merge conflict in #33135 I noticed that #32983 changed the descriptor `Parse` function signature from `const std::string& descriptor` to `std::span<const char> descriptor`.
Calling that new version of `Parse` with a string literal will trigger a confusing "Invalid characters in payload" due to the trailing "\0".
It can be worked around by having (the test) wrap string literals in `std::string()`, but that's easy to forget.
Using `string_view` is easier and more compact than (as a previous version of this PR did) checking for trailing `\0`.
Also add a test.
ACKs for top commit:
maflcko:
review ACK c0bfe72f6e1f63e05772eda959137b3d0bbbf6c3 🍨
enirox001:
tACK c0bfe72
stickies-v:
ACK c0bfe72f6e1f63e05772eda959137b3d0bbbf6c3
rkrux:
crACK c0bfe72f6e1f63e05772eda959137b3d0bbbf6c3
Tree-SHA512: 6b20307f834dae66826c8763f6c2ba0071f4e369375184cb5ff8543b85220fcaf33a47ddb065e418d1af3ed9a3fac401a7854f8924f52aab2b000b1f65328f2c
52230a7f697fd99abdc4550d6a60737be024e246 test: check for output to stdout in `TestShell` test (Sebastian Falbesoner)
Pull request description:
This is a small follow-up PR to the recently added `TestShell` test (#33546), verifying the stdout message "TestShell is already running!" when trying to instantiate a second instance.
ACKs for top commit:
maflcko:
lgtm ACK 52230a7f697fd99abdc4550d6a60737be024e246
rkrux:
crACK 52230a7f697fd99abdc4550d6a60737be024e246
Tree-SHA512: 096d70e1bd0f09c1b389e58fa4b880442406c56f0c8ef8b8fbd0627081bc390b1ce5d6032bcca19b03206b7a444d9c523f9b62078b5ca5b7f1ae3c57bb4129c9
CConnman::Stop() resets semOutbound, yet m_reconnections is not
cleared in Stop. Each ReconnectionInfo contains a grant member
that points to the memory that semOutbound pointed to and ~CConnman
will attempt to access the grant field (memory that was already
freed) when destroying m_reconnections. Fix this by calling
m_reconnections.clear() in CConnman::Stop() and add appropriate
annotations.
2909655fba91a7cc59c484fc74afafdf7ccc0cfa fix: remove redundant mempool lock in ChainImpl::isInMempool() (Fibonacci747)
Pull request description:
This PR removes an unnecessary `LOCK(mempool->cs)` in `ChainImpl::isInMempool()`. The method calls `CTxMemPool::exists()`, which already locks `mempool->cs` internally. Because the mempool mutex is a RecursiveMutex, double-locking was safe but redundant. Dropping the outer lock matches patterns used elsewhere in ChainImpl (e.g. `hasDescendantsInMempool()` and `GetTransactionAncestry()` callers) where mempool read APIs are invoked without an additional lock and rely on the callee’s internal locking. `isRBFOptIn()` remains unchanged since `IsRBFOptIn(tx, pool)` explicitly requires the caller to hold `pool.cs` as indicated by its thread-safety annotation.
ACKs for top commit:
maflcko:
lgtm ACK 2909655fba91a7cc59c484fc74afafdf7ccc0cfa
instagibbs:
utACK 2909655fba91a7cc59c484fc74afafdf7ccc0cfa
stickies-v:
ACK 2909655fba91a7cc59c484fc74afafdf7ccc0cfa
Tree-SHA512: 4dfd88e01d8c7a4b6ceb3c736243fb22bfee5ccfc422d134acb633b908ca14c807637a2aa20de89e86e583b23ec70a1d121d77e35af60e114d93971b2a4bfd3b
Prior to cluster mempool, a policy was in place that
disallowed non-TRUC transactions from being
TX_RECONSIDERABLE in a package setting if it was below
minrelay. This was meant to simplify reasoning about mempool
trimming requirements with non-trivial transaction
topologies in the mempool. This is no longer a concern
post-cluster mempool, so this is relaxed.
In effect, this makes 0-value parent transactions relayable
through the network without the TRUC restrictions and
thus the anti-pinning protections.
Clear out space on the centos job be deleteing unnecessary files.
Raised by #33293 which pointed to a solution like b7f04d7822
Only runs when cache provider (runner) is `gha`, and on the CentOS job.
70d9e8f0a15d07a27ae37befb5c1bce71c98d8de fix: reorg behaviour in mempool tests to match real one (yuvicc)
540ed333f6c81e8d191dfa8fd7cf162e980edfa1 Move the create_empty_fork method to the test framework's blocktools.py module to enable reuse across multiple tests. (yuvicc)
Pull request description:
Updated functional tests to replace direct use of `invalidateblock` with proper fork-based reorg behaviour. The direct invalidation approach bypasses important validation checks and has depth limitations(10 block) that don't match real-world reorg scenarios. For more details see #32531.
Fixes#32531
ACKs for top commit:
instagibbs:
reACK 70d9e8f0a15d07a27ae37befb5c1bce71c98d8de
theStack:
re-ACK 70d9e8f0a15d07a27ae37befb5c1bce71c98d8de
Tree-SHA512: 8aae298bfa295b4e0e4627b522e9eac549399008fd8e336a66f8c9950c886917da0b3f0bdc62d0c8ea2b8082f36639300cac4070986a7766398e15bc1f666da5
3e4355314b1abf8e4456ea41ba738aaae25abb73 depends: latest config.sub (fanquake)
04eb84fe3f73e4d4df457dfdf9fdb4ccff1018cd depends: latest config.guess (fanquake)
Pull request description:
It's been about a year since these were last updated.
Pull in the latest versions.
ACKs for top commit:
hebasto:
ACK 3e4355314b1abf8e4456ea41ba738aaae25abb73, I have reviewed the code and it looks OK.
Tree-SHA512: f18a0b95e71588e9f1ea55efb6379664aa6e9154801448e9425362414c3f3c4dab29dbe0e3ab02c46ac1f2e2ad1d067bc6feb8c550ccde37cabd1c0bd9d1b87c
Starting with Python 3.11, Pythons gzip might delegate to zlib.
Depending on the OS, i.e Ubuntu vs Fedora, the underlying zlib
implementation might differ, resulting in different output.
For now, or until a better solution exists, disable compression. This
results in the SDK increasing in size to ~157mb. Which is not
unreasonable, to regain determinism (and would be significantly worse
without the previous commit).
See: https://docs.python.org/3/library/gzip.html#gzip.compress
Co-authored-by: stickies-v <stickies-v@protonmail.com>
All touched Python scripts already assume and require UTF8, so manually
specifying encoding or decoding for functions in the subprocess module
is redundant to just using text=True, which exists since Python 3.7
Historically, the headers have been bumped some time after a file has
been touched. Do it now to avoid having to touch them again in the
future for that reason.
-BEGIN VERIFY SCRIPT-
sed -i --regexp-extended 's;( 20[0-2][0-9])(-20[0-2][0-9])? The Bitcoin Core developers;\1-present The Bitcoin Core developers;g' $( git show --pretty="" --name-only HEAD~0 )
-END VERIFY SCRIPT-
The encoding arg is confusing, because it is not applied consistently
for all IO.
Also, it is useless, as the majority of files are ASCII encoded, which
are fine to encode and decode with any mode.
Moreover, UTF-8 is already required for most scripts to work properly,
so setting the encoding twice is redundant.
So remove the encoding from most IO. It would be fine to remove from all
IO, however I kept it for two files:
* contrib/asmap/asmap-tool.py: This specifically looks for utf-8
encoding errors, so it makes sense to sepecify the utf-8 encoding
explicitly.
* test/functional/test_framework/test_node.py: Reading the debug log in
text mode specifically counts the utf-8 characters (not bytes), so it
makes sense to specify the utf-8 encoding explicitly.
The check was incomplete and brittle. A better check would be to enable
`PYTHONWARNDEFAULTENCODING=1`
https://docs.python.org/3/whatsnew/3.10.html#optional-encodingwarning-and-encoding-locale-option
However, it is unclear what the goal of adding explicit encodings
everywhere is, given that:
* Most modern systems already have UTF-8 enabled by default, except for
Windows.
* Python 3.15 will likely enable it globally by default, according to
https://peps.python.org/pep-0686/#abstract
* Adding the explicit encodings will bloat all code for no benefit.
So remove the lint check and drop all redundant encoding= kwargs.
All encoding= that are set for a reason, are kept.
It will likely be the default for all systems, starting with Python
3.15, according to https://peps.python.org/pep-0686/#abstract.
It is hard to find a system other than Windows that has it not enabled
today. Nonetheless, Bitcoin Core requires UTF-8 in scripts and normally
enforces it via LC_ALL=C.UTF-8 or PYTHONUTF8=1.
Bash is discouraged, and there was never a need to write locale
dependent Bash.
So remove the option and clarify that the LC_ALL settings enable UTF-8
mode in Python.
Also changes the the non-constant variable NUM_WALLETS to lower case and
refactors the success case scenarios to reuse existing code.
Co-authored-by: rkrux <rkrux.connect@gmail.com>
8558902e576e2c2d66f6083b66953dd6cc464de4 depends: Add patch for Windows11Style plugin (Hennadii Stepanov)
Pull request description:
This PR fixes https://github.com/bitcoin-core/gui/issues/906:
<img width="561" height="179" alt="image" src="https://github.com/user-attachments/assets/6bb6d12b-91a6-4659-b6eb-be64093ec86d" />
ACKs for top commit:
waketraindev:
ACK 8558902e576e2c2d66f6083b66953dd6cc464de4
fanquake:
ACK 8558902e576e2c2d66f6083b66953dd6cc464de4 - did not test on Windows.
Tree-SHA512: c8c0518b9cfccffb364f9305febec238236ef51134e915885f491c7f0bef59401367f60bbb034e0216edf0a74a99a07a3dcc22804d8396260375ea60a60756a9
The Bash script was acceptable, but CI_EXEC_CMD_PREFIX was a single
string, relying on brittle word splitting that the shellcheck SC2086
would warn about.
So just fix that by moving everything to the Python script and deleting
the Bash script.
This also removes the need to export the CI_CONTAINER_ID env var.
In theory one could run the CI without the rsync package installed, and
with DANGER_RUN_CI_ON_HOST=1. However, this seems to be an edge case.
Simply requiring rsync to be installed is less code and avoids brittle
edge cases around rsync failures.
It contains a large `bash -c` string, which is hard to parse. So pull
out components:
* CI_EXEC is only called with absolute folders as args, so the `cd` is
not needed in CI_EXEC. It is only needed to specify the working dir of
running the tests in 03_test_script.sh, so move it there.
* The PATH modification is only needed after commit
4756114e505cff8848fb6344ef9a48d8822066c1 to check that depends does
work properly, even when the PATH contains a space.
* This allows to also drop the `bash -c` and use the proper and safer
"$@" to forward args without the risk of word splitting.
This move-only refactor clarifies that macos assumes and requires
DANGER_RUN_CI_ON_HOST.
So move the snippet under the condition for self-documenting code.
Can be reviewed with the git options:
--color-moved=dimmed-zebra --color-moved-ws=ignore-all-space
The `retry` script is required for CI_RETRY_EXE and there are two ways
to put it into PATH:
* When running in a container engine, by copying it into /usr/bin
* When running without a container engine, by prepending its location to PATH
