eef5dbc21b3fd52069f2f0855fb76a13234ebbf3 [doc] update release notes 26.2 (glozow)
00f0267ac0fcb8aa08ce4f04274499697335998d [doc] update manpages 26.2 (glozow)
29cbec45ddb0497bf6d5a641e0f5c3800ed1427a [build] bump copyright year (glozow)
fe8dee826d48a7476c3f77b6adca8a843f06e38e [build] bump version to 26.2 (glozow)
Pull request description:
bins were uploaded 2 weeks ago on June 18
website PR: https://github.com/bitcoin-core/bitcoincore.org/pull/1039
ACKs for top commit:
stickies-v:
ACK eef5dbc21b3fd52069f2f0855fb76a13234ebbf3
fanquake:
ACK eef5dbc21b3fd52069f2f0855fb76a13234ebbf3 If you want, you could also backport the changes to get the ASAN job running again, but that isn't blocking here.
theStack:
ACK eef5dbc21b3fd52069f2f0855fb76a13234ebbf3
Tree-SHA512: 7c9e97231fd51784f1cc78a9b7b07b8a201ad7f54715fab6dd3243244e9f52831f57883966f2061cbff7a68018b4345de27e3953c50d7ec801d1a61f216907d1
See: c0a50ce33e
The return value of 2 now indicates:
"A valid connected IGD has been found but its IP address is reserved (non routable)"
We continue to ignore any return value other than 1.
Github-Pull: #30283
Rebased-From: 8acdf66540834b9f9cf28f16d389e8b6a48516d5
This change is a result if pulling the recent translations
from the Transifex website using the
bitcoin-maintainer-tools/update-translations.py tool.
A few manual adjustments were made:
- skipped removing of `bitcoin_af.ts`
- skipped removing of `bitcoin_ar.ts`
- skipped removing of `bitcoin_fa.ts`
- skipped removing of `bitcoin_la.ts`
- skipped removing of `bitcoin_ru.ts`
- skipped removing of `bitcoin_th.ts`
- skipped removing of `bitcoin_uk.ts`
present)
Addnode (manual) peers connected to us via the cjdns network are currently not
detected by CConnman::GetAddedNodeInfo(), i.e. fConnected is always false.
This causes the following issues:
- RPC `getaddednodeinfo` incorrectly shows them as not connected
- CConnman::ThreadOpenAddedConnections() continually retries to connect them
Github-Pull: #30085
Rebased-From: 684da9707040ce25d95b2954eda50b811136d92c
Without explicitly declaring the move, these UniValues get copied,
causing increased memory usage. Fix this by explicitly moving the
UniValue objects.
Used by `rest_block` and `getblock` RPC.
Github-Pull: #30094
Rebased-From: b77bad309e92f176f340598eec056eb7bff86f5f
The 32 to 64-bit time_t transition causes a build failure in the built-in
zlib about conflicting _TIME_BITS and _FILE_OFFSET_BITS.
Note that zlib doesn't use time_t at all, so it is a false alarm.
Take the following patch from upstream zlib:
a566e156b3.patch
Closes#29980.
Github-Pull: #29985
Rebased-From: 2e266f33b5d2be5c233c2c692481f75785714fa1
Pretty much all library packages were renamed in the 64-bit time_t
migration to add `t64` (even on 64-bit platforms).
Instead of complicating the doc with conditional package names, suggest
installing the `-dev` packages which still have the same name, and
besides that, are the right way to go about it as they contain the
"user facing" C++ headers needed to build against Qt5.
For Fedora, devel packages are already suggested.
This affects Ubuntu 24.04 and Debian Testing.
Github-Pull: #29764
Rebased-From: a3c6a13cb23999fa70c428f1229acbf1b3883f11
The script provided for signature might be externally provided, for
instance by way of 'finalizepsbt'. Therefore the script might be
ill-crafted, so don't assume pubkeys are always 32 bytes.
Thanks to Niklas for finding this.
Github-Pull: #29853
Rebased-From: 4d8d21320eba54571ff63931509cd515c3e20339
The issue is that compilation is done with `x86_64-w64-mingw32-g++-posix`,
but then linking is done with `x86_64-w64-mingw32-g++`.
I'm guessing this has been broken since #24131
(01d1845a80ae48d741deea695ddce95d940ab0d8), but have not checked.
Fixes#29734.
Unblocks #29527 (now DEBUG=1 builds can be tested).
Github-Pull: #29747
Rebased-From: b7e7e727abd86104ee58beb648a94e2f453d1f6d
To avoid issues with DNS blacklisting, I've setup a separate domain for my DNS seed.
Github-Pull: #29691
Rebased-From: 4f273ab4360c9aa72c2feb78787e1811ab58dc16
cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1 [doc] add manual pages for 26.1 (glozow)
785242dd4ca5b05155f67a8ab097dc35ee183559 [doc] update release notes 26.1 (glozow)
5f06dcf9c9481ab8f034aece447e12da67ab7ce7 [build] bump version to 26.1 final (glozow)
b53bf22c722309cba923b90840c1e48b98f553c9 ci, macos: Use `--break-system-packages` with Homebrew's python (Hennadii Stepanov)
324e56239960308333ac9e46f1c815020f0b149f ci: Add workaround for Homebrew's python link error (Hennadii Stepanov)
Pull request description:
Final changes for `v26.1`.
Bins for rc2 have been available for 10 days and I haven't seen any bug reports or new things to add.
Includes #29610 backport for the CI, which has no effect on what goes into the release.
Website PR: https://github.com/bitcoin-core/bitcoincore.org/pull/1009
ACKs for top commit:
hebasto:
ACK cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1.
fanquake:
ACK cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1
stickies-v:
ACK cc0553d0d666a6ad5cdd3b88ddb06af883b6d7a1 (modulo CI passing)
Tree-SHA512: d032157c7cdf07a474e40b947f7e51bfc6a8e280e43345522bad67b6ad449d473f29bf03ee845b2e403693c1c81078589d042337c895eceb8a59cb4340432887
Homebrew's python@3.12 is marked as externally managed (PEP 668),
necessitating different approaches for installing Python packages.
For more details, please refer to https://github.com/orgs/Homebrew/discussions/3404.
Github-Pull: #29610
Rebased-From: acc06bc91f80ddf4e015dcdf0b984bbdbfcb5ca3
Promoting Homebrew's python@3.12 to the default python3 breaks symbolic
links on macOS x86_64.
This change adds a workaround for that issue.
Also see: https://github.com/actions/runner-images/issues/9471 etc.
Github-Pull: #29610
Rebased-From: ae5f72027f1776f815a6637c594f0f725a6ccb55
We preemptively perform a block mutation check before further processing
a block message (similar to early sanity checks on other messsage
types). The main reasons for this change are as follows:
- `CBlock::GetHash()` is a foot-gun without a prior mutation check, as
the hash returned only commits to the header but not to the actual
transactions (`CBlock::vtx`) contained in the block.
- We have observed attacks that abused mutated blocks in the past, which
could have been prevented by simply not processing mutated blocks
(e.g. https://github.com/bitcoin/bitcoin/pull/27608).
Github-Pull: #29412
Rebased-From: 49257c0304828a185c273fcb99742c54bbef0c8e
