Skip to content

V28.0 nm#1

Open
dcorral wants to merge 32 commits into
masterfrom
v28.0-nm
Open

V28.0 nm#1
dcorral wants to merge 32 commits into
masterfrom
v28.0-nm

Conversation

@dcorral

@dcorral dcorral commented Aug 13, 2025

Copy link
Copy Markdown
Owner

No description provided.

achow101 and others added 30 commits August 27, 2024 13:16
bd45bc6 doc: Point release notes to wiki draft (Ava Chow)
27b6300 examples: Generate example bitcoin.conf (Ava Chow)
08887d3 doc: Generate manpages (Ava Chow)
6974e30 build: Bump to 28.0rc1 (Ava Chow)

Pull request description:

  * Bump version to 28.0rc1
  * Generated manpages
  * Generated example bitcoin.conf
  * Point release notes to wiki

ACKs for top commit:
  hebasto:
    ACK bd45bc6.

Tree-SHA512: c3cd28b003ead64631b8c2d1bdbf7403d4d9f53ee5ccdc448d89ca25941678f6d1d8966c2f9a92fa021c815b3e36a84056342caa4eaacdab371f0d581e4e58dc
the run_command test under system_tests fails if the locale is anything
other than English ones because results such as "No such file or directory"
will be different under Non-English locales.

On the old version, a `ls nonexistingfile` was used to generate the error
output which is not ideal. In the current version we are using a Python one-liner
to generate a non 0 zero return value and "err" on stderr and check the
expected value against this.

fixes bitcoin#30608

Github-Pull: bitcoin#30788
Rebased-From: ae48a22
Currently, builds of libevent in depends, using CMake, fail on some
systems, like Alpine, with the following:
```bash
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c: In function 'evmap_signal_add_':
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c:456:31: error: 'NSIG' undeclared (first use in this function)
  456 |         if (sig < 0 || sig >= NSIG)
```

From what I can tell the `_GNU_SOURCE` "detection" in libevents CMake build
system, never? really worked, and it's not clear what a nice fix is.

For now, always use `_GNU_SOURCE` when building libevent in depends.

Github-Pull: bitcoin#30743
Rebased-From: 5567754
b2a1379 depends: build libevent with -D_GNU_SOURCE (fanquake)
199bb09 test: fixing failing system_tests/run_command under some Locales (Jadi)
342baab test: Avoid intermittent timeout in p2p_headers_sync_with_minchainwork.py (MarcoFalke)
5577d5a test: fix `TestShell` initialization (late follow-up for bitcoin#30463) (Sebastian Falbesoner)

Pull request description:

  Backports:
  * bitcoin#30714
  * bitcoin#30743
  * bitcoin#30761
  * bitcoin#30788

ACKs for top commit:
  willcl-ark:
    ACK b2a1379
  achow101:
    ACK b2a1379
  stickies-v:
    ACK b2a1379

Tree-SHA512: bf08ac0c613395def974a1b287345d4a64edc066c14f8c9f0184478b0e33e48333760eeb6e96b6b5fbafbb21b40d01875e3f526213a2734e226b2e111d71f3a3
Because AssumeUTXO nodes prioritize tip synchronization, they relay their local
address through the network before completing the background chain sync.
This, combined with the advertising of full-node service (NODE_NETWORK), can
result in an honest peer in IBD connecting to the AssumeUTXO node (while syncing)
and requesting an historical block the node does not have. This behavior leads to
an abrupt disconnection due to perceived unresponsiveness (lack of response)
from the AssumeUTXO node.

This lack of response occurs because nodes ignore getdata requests when they do
not have the block data available (further discussion can be found in PR 30385).

Fix this by refraining from signaling full-node service support while the
background chain is being synced. During this period, the node will only
signal 'NODE_NETWORK_LIMITED' support. Then, full-node ('NODE_NETWORK')
support will be re-enabled once the background chain sync is completed.

Github-Pull: bitcoin#30807
Rebased-From: 6d5812e
Exercising and verifying the following points:

1. An IBD node can sync headers from an AssumeUTXO node at
   any time.

2. IBD nodes do not request historical blocks from AssumeUTXO
   nodes while they are syncing the background-chain.

3. The assumeUTXO node dynamically adjusts the network services
   it offers according to its state.

4. IBD nodes can fully sync from AssumeUTXO nodes after they
   finish the background-chain sync.

Github-Pull: bitcoin#30807
Rebased-From: 992f83b
The crash occurs because 'WalletController::removeAndDeleteWallet' is called
twice for the same wallet model: first in the GUI's button connected function
'WalletController::closeWallet', and then again when the backend emits the
'WalletModel::unload' signal.

This causes the issue because 'removeAndDeleteWallet' inlines an
erase(std::remove()). So, if 'std::remove' returns an iterator to the end
(indicating the element wasn't found because it was already erased), the
subsequent call to 'erase' leads to an undefined behavior.

Github-Pull: bitcoin-core/gui#835
Rebased-From: a965f2b
The recent translations from Transifex.com 28.x fetched with the
bitcoin-maintainer-tools/update-translations.py tool.

Github-Pull: bitcoin#30899
Rebased-From: ae05295
Co-Authored-By: David Gumberg <davidzgumberg@gmail.com>

Github-Pull: bitcoin#30884
Rebased-From: a240e15
06a7df7 doc: Generate manpages (Ava Chow)
5315886 build: Bump to 28.0rc2 (Ava Chow)
ff95cb3 streams: remove AutoFile::Get() entirely (Pieter Wuille)
8229e98 streams: cache file position within AutoFile (Pieter Wuille)
1b853fd qt: Translations update (Hennadii Stepanov)
674dded gui: fix crash when closing wallet (furszy)
d39262e test: Wait for local services to update in feature_assumeutxo (Fabian Jahr)
b329ed7 test: add coverage for assumeUTXO honest peers disconnection (furszy)
c6b5db1 assumeUTXO: fix peers disconnection during sync (furszy)
598415b test: Work around boost compilation error (MarcoFalke)

Pull request description:

  * bitcoin#30834
  * bitcoin#30807
  * bitcoin#30880
  * bitcoin-core/gui#835
  * bitcoin#30899
  * bitcoin#30884

ACKs for top commit:
  stickies-v:
    ACK 06a7df7
  hebasto:
    ACK 06a7df7, I've backported the listed PRs locally. The only merge conflict I faced was in bitcoin#30807. It was trivial to resolve.

Tree-SHA512: 779d734b50fdce379a20865ba30c969def028963ba51da0f497ddf1b5375e1f6166365295f226c1a07bab8be0c1aa0a6a3296fc6acd9fcf17bcc4874aac980a6
The comparison of m_best_invalid with the tip of the respective chainstate
makes no sense for the background chainstate, and can lead to incorrect
error messages.

Github-Pull: bitcoin#30962
Rebased-From: c0a0c72
5de225f doc: 28.0 Release Notes (Ava Chow)
98745e0 doc: generate manpages (Ava Chow)
5feef9c build: Bump to 28.0 (Ava Chow)
7fcd7b8 validation: Disable CheckForkWarningConditions for background chainstate (Martin Zumsande)
e24a25d test: Use shell builtins in run_command test case (Ava Chow)

Pull request description:

  * bitcoin#30952
  * bitcoin#30962
  * Finalize 28.0 (or rc3 if additional backports are needed)

ACKs for top commit:
  sipa:
    utACK 5de225f

Tree-SHA512: b42948a04d4250f2c9ef3331a39a4c3d7de9ceb9f4f294dd283599d08f3e2b7147297ef9ec1c4276e291a015fc2daa5a72c1f1c33fb517e8ea5c740c4459bf32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants