When executing a Python script from within Python, rather than looking for
`python3` in /usr/local/bin and falling back to the script’s shebang line,
_always_ use the same Python that is executing the caller.
I don’t know why this script doesn’t just run `bitcoin_util_test.py`
directly (always using the shebang line), but I assume that is
intentional (but that should be documented). Otherwise, I’d prefer that
approach.
(cherry-picked bitcoin/bitcoin@76f74811c4)
At startup, we choose one peer to serve us the headers chain, until
our best header is close to caught up. Disconnect this peer if more
than 15 minutes + 1ms/expected_header passes and our best header
is still more than 1 day away from current time.
birthday does not cause us to try to "rewind" the Orchard wallet to a
height after its current checkpoint.
potentially fixes#5958
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
(cherrypicked bitcoin/bitcoin@e2652002b6)
nMinimumChainWork is an anti-DoS threshold; wait until we have a proposed
tip with more work than that before downloading blocks towards that tip.
This removes the git hash from gitian-build zcash version strings when
built inside gitian (when the state of the working tree is clean and
corresponds to an annotated tag).
We partially revert 8dbd2edd98 by removing
all instances of setting `GIT_DIR` in the gitian descriptors. Currently,
gitian builds cause zcash to have version strings which look like
`Zcash Daemon version v5.3.0-35186b009-dirty`, which is inaccurate.
Setting `GIT_DIR` with a current working directory of
`/home/debian/build/zcash/distsrc-x86_64-linux-gnu` makes the git
invocations in `genbuild.sh` see that directory as the top of the
working tree, which causes git to believe that a bunch of tracked files
were deleted (namely, those not included by the `make dist` step).
This causes `genbuild.sh` to believe that it is working with a dirty
tree, and with the help of `src/clientversion.cpp`, zcash gets a version
string that includes a hash ending in `-dirty`.
The release commit was built with a `make-release.py` that was before the parallel-gitian commit, causing the parallel gitian descriptor to not be updated.
Have updatecheck look in $XDG_DATA_HOME/zcash/updatecheck/token for the GH
token. Having one in the repo will still take precedence (for pre-existing
users, as well as if you want to override the token used in a particular
case). The new location is standardized, exists at the user level (as the token
logically does), and means that you don't need to copy files around if you get a
new clone or worktree to do a release.
- make the token optional (just will hit a rate limit after a few runs of the
script)
- only load the token once, rather than once per request (this is necessary
after the above change, so you don't get the warning printed repeatedly)
- switch from BasicAuth to an Authorization header (this means we no longer need
the GitHub username, just the token)
- support a token file that doesn't contain a username (it will still parse old
versions of the file properly)
Previously make-release.py checked dependency updates before checking out the
commit to be released. This could be annoying if the release branch had
everything up-to-date, but you ran the script from a different branch. Worse,
you could accidentally update the dependencies on your original branch, and have
it pass the release process with outdated dependencies.