-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
backport: bitcoin#17946, #18663, #18946, #18975, #19004, #19115, #19152, #19173, partial #18735 #5802
Conversation
9301c09
to
02b0f08
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
few questions
src/qt/bitcoingui.cpp
Outdated
/* | ||
if (fNetworkBecameActive || fNetworkBecameInactive) { | ||
setNumBlocks(m_node.getNumBlocks(), QDateTime::fromTime_t(m_node.getLastBlockTime()), QString::fromStdString(m_node.getLastBlockHash()), m_node.getVerificationProgress(), false); | ||
} | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
18152: ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see commit description e76f696
src/qt/bitcoingui.cpp
Outdated
/* | ||
setNumBlocks(m_node.getNumBlocks(), QDateTime::fromTime_t(m_node.getLastBlockTime()), QString::fromStdString(m_node.getLastBlockHash()), m_node.getVerificationProgress(), false); | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
18152: ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see commit description e76f696
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Clarification for setAdditionalDataSyncProgres:
The call of masternodeSync.Reset() can happen only if chain is destroyed,
it happens if application is closed. We don't need to update num of blocks
in this situation, as well we don't need to start spinner
This is not true. We force sync reset in a couple of cases in CMasternodeSync
itself and via mnsync reset
RPC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/net.cpp: ::masternodeSync->Reset();
src/net.cpp: ::masternodeSync->Reset();
src/qt/bitcoingui.cpp: // If masternodeSync->Reset() has been called make sure status bar shows the correct information.
src/test/util/setup_common.cpp: ::masternodeSync.reset();
src/rpc/misc.cpp: ::masternodeSync->Reset(true);
src/init.cpp: ::masternodeSync.reset();
ah I see now, reset() and Reset() are different things.
Could you suggest a fix for case of Reset()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we had setNumBlocks
here and in (1) because we wanted up to date info so it should be POST_INIT
(i.e. disable throttling) in both cases I think.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I looked to usages of masternodeSync::Reset()
:
once it is called inside CConnman::SetNetworkActive
- so it means that it can be called if network become active/inactive... Rpc mnsync
can be called before sync is also finish.
So, I'd prefer to keep it as is in e76f696 now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only thing these sync statuses change in setNumBlocks
is app nap state switch and we definitely do not want app nap to be enabled in both cases. POST_INIT
is probably not a safe one then, should pick any other state, doesn't really matter which one exactly but INIT_DOWNLOAD
is probably the less confusing one.
::masternodeSync.reset()
can only happen on shutdown and anything would work there imo, I would just ignore this case.
So, I'd prefer to keep it as is in e76f696 now
I disagree, we should re-enable setNumBlocks
and the spnner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we maybe drop 18152 from this PR and do it in a separate one or will it cause some merge conflicts?
EDIT: just tried it myself, looks like it can be dropped safely
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
here's it: #5804
no conflicts, but 18152 is needed for several further backports from v21/v22 (no PRs for them yet)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT: just tried it myself, looks like it can be dropped safely
yes, I slightly tested before PR is created: run app, stop app before sync is over; restart and wait until sync is over; call re-index; also checked spinner appearance after connection to peers are established.
I didn't check all cases, but looks like main-flow works correctly with e76f696
fa5919a
to
07a76ed
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, utACK
there's no more conflict between #5767 and this PR due to moved backport bitcoin#18152 to new PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK for merging via merge commit
bda62e8 Adding build instructions to Bitcoin Core, fixes bitcoin#18658 (Saahil Shangle) Pull request description: Making the instructions for building Bitcoin Core more clear in the main `README.md` will reduce confusion between the `build_msvc` and `doc` folders. ACKs for top commit: laanwj: ACK bda62e8 Tree-SHA512: ee4c394661eba48d4229e3d1e9ddb67ccb79589429bfa9986cb0242cd615d1f3cc5332063562c1e89c0cdd9ae2e609f61e8bfb209926d8363d35d3da6d94ae9c
…ith simple assignment of T{} fa1f840 rpcwallet: Replace pwallet-> with wallet. (MarcoFalke) fa182a8 rpcwallet: Replace boost::optional<T>::emplace with simple assignment of T{} (MarcoFalke) Pull request description: Closes bitcoin#18943 ACKs for top commit: laanwj: ACK fa1f840 ryanofsky: Code review ACK fa1f840 and thanks for using a standalone commit for the fix promag: Code review ACK fa1f840. hebasto: ACK fa1f840, tested on Linux Mint 19.3. Tree-SHA512: 0838485d1f93f737ce5bf12740669dcafeebb78dbc3fa15dbcc511edce64bf024f60f0497a04149a1e799d893d57b0c9ffe442020c1b9cfc3c69db731f50e712
… on xenial 050e2ee test: Remove const to work around compiler error on xenial (Wladimir J. van der Laan) Pull request description: Fix the following error in travis: test/validationinterface_tests.cpp:26:36: error: default initialization of an object of const type 'const BlockValidationState' without a user-provided default constructor const BlockValidationState state_dummy; ACKs for top commit: MarcoFalke: Tested ACK 050e2ee on xenial with clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final) fanquake: ACK 050e2ee - I see why we didn't hit this on master. We are installing the `clang-8` packages for the tsan job. However on the 0.20 branch we are still just installing `clang`, which is 3.8. Tree-SHA512: 8a1d57289dbe9895ab79f81ca87b4fd723426b8d72f3a34bec9553226fba69f6dc19551c1f1d52db6c4b2652164a02ddc60f3187c3e2ad7bcacb0aaca7fa690a
412d5fe QA: feature_segwit: Check that template "rules" includes "!segwit" as appropriate (Luke Dashjr) 2abe8cc Bugfix: Include "csv","!segwit" in "rules" (Luke Dashjr) Pull request description: bitcoin#16060 removed CSV & segwit from versionbits, breaking the "rules" key returned by GBT. Without this, miners don't know they're mining segwit blocks, and should fall back to pre-segwit block creation. ACKs for top commit: sipa: ACK 412d5fe jnewbery: Tested ACK 412d5fe. Tree-SHA512: 825d72e257dc0dd4941f2fe498d8d4f4f2a21b9505cd21a8f9eb7fb5d6d7dd9219347928cf90bb57a777920ce24295859763e64fa8a22ebb58fc2380f80f5615
c57f03c refactor: Replace const char* to std::string (Calvin Kim) Pull request description: Rationale: Addresses bitcoin#19000 Some functions should be returning std::string instead of const char*. This commit changes that. Main benefits/reasoning: 1. The functions never return nullptr, so returning a string makes code at call sites easier to review (reviewers don't have to read the source code to verify that a nullptr is never returned) 2. All call sites convert to string anyway ACKs for top commit: MarcoFalke: re-ACK c57f03c (no changes since previous review) 🚃 Empact: Fair enough, Code Review ACK bitcoin@c57f03c practicalswift: ACK c57f03c -- patch looks correct hebasto: re-ACK c57f03c Tree-SHA512: 9ce99bb38fe399b54844315048204cafce0f27fd8f24cae357fa7ac6f5d8094d57bbf5f5c1f5878a65f2d35e4a3f95d527eb17f49250b690c591c0df86ca84fd
fae49f6 ci: Add and document BASE_BUILD_DIR (MarcoFalke) Pull request description: Also fixes bitcoin#18768 ACKs for top commit: hebasto: re-ACK fae49f6, which is essentially the same as the previously [reviewed changes](bitcoin#18735 (review)). Tree-SHA512: 216565a05ccd513dd9f114b2333d3c283fd71914d32f9b05f145cb7c70633b083ff8ef60798d6f22f4be6a4d652b03806551fd74b5b596c92968501a4d9726d2
0fef60c build: improved output of configure for build OS (sachinkm77) Pull request description: The purpose of this fix is to improve output of the configure script by providing the build OS. This is done by leveraging the build_os set by the script config.sub / config.guess. bitcoin#18966 ACKs for top commit: fanquake: ACK 0fef60c - thanks for following up. Tree-SHA512: b9f49df901a9d37eb16c67c063bb3611602a84391aa54d097a52b740f474c2785c24bf405522d15d724fde25070d354bf20b885add2ee4405a71cbe9ebab5ff3
0012471 build: turn on --enable-c++17 by --enable-fuzz (Vasil Dimov) Pull request description: Fuzzing code uses C++17 specific code (e.g. std::optional), so it is not possible to compile with --enable-fuzz and without --enable-c++17. Thus, turn on --enable-c++17 whenever --enable-fuzz is used. ACKs for top commit: hebasto: ACK 0012471, tested on Linux Mint 19.3 (x86_64); verified that it fails to compile with `--enable-fuzz` and without `--enable-c++17` on master. Tree-SHA512: 290531ea8d79de3b9251ea4ad21e793478b18150cc0124eea1e50c3a4ed92bab89c3e70ed0aa526906f8723ea952cdba4268f1560ae4be9bd25b9e4f9b97436c
07a76ed
to
d5e709b
Compare
Issue being fixed or feature implemented
Just regular bitcoin backports, mostly from v21
What was done?
Note, that 18735 is partial due to different implementation of our and bitcoin's CI, paths are different, scripts are different... Remaining part DNM (do-not-merge) at least currently
How Has This Been Tested?
Run unit/functional tests
Breaking Changes
N/A
Checklist: