Conversation
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
Github-Pull: bitcoin#30714 Rebased-From: bd7ce05
…k.py Github-Pull: bitcoin#30761 Rebased-From: fa247e6
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
Github-Pull: bitcoin#30834 Rebased-From: fa9d7d5
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
Github-Pull: bitcoin#30880 Rebased-From: 19f4a7c
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
Github-Pull: bitcoin#30884 Rebased-From: e624a9b
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
Github-Pull: bitcoin#30952 Rebased-From: 7bd3ee6
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.