Bitcoin Core integration/staging tree
Go to file
fanquake 9487b68f06
Merge bitcoin/bitcoin#22847: guix/prelude: Override VERSION with FORCE_VERSION
96cc6bb04f guix/prelude: Override VERSION with FORCE_VERSION (Carl Dong)

Pull request description:

  ```
  Previously, if the builder exported $VERSION in their environment (as
  past Gitian-building docs told them to), but their HEAD does not
  actually point to v$VERSION, their build outputs will differ from those
  of other builders.

  This is because the contrib/guix/guix-* scripts only ever act on the
  current git worktree, and does not try to check out $VERSION if $VERSION
  is set in the environment.

  Setting $VERSION only makes the scripts pretend like the current
  worktree is $VERSION.

  This problem was seen in jonatack's attestation for all.SHA256SUMS,
  where only his bitcoin-22.0rc3-osx-signed.dmg differed from everyone
  else's.

  Here is my deduced sequence of events:

  1. Aug 27th: He guix-builds 22.0rc3 and uploads his attestations up to
     guix.sigs

  2. Aug 30th, sometime after POSIX time 1630310848: he pulls the latest
     changes from master in the same worktree where he guix-built 22.0rc3
     and ends up at 7be143a960

  3. Aug 30th, sometime before POSIX time 1630315907: With his worktree
     still on 7be143a960, he guix-codesigns. Normally, this would result
     in outputs going in guix-build-7be143a960e2, but he had
     VERSION=22.0rc3 in his environment, so the guix-* scripts pretended
     like he was building 22.0rc3, and used 22.0rc3's guix-build directory
     to locate un-codesigned outputs and dump codesigned ones.

     However, our SOURCE_DATE_EPOCH defaults to the POSIX time of HEAD
     (7be143a960), which made all timestamps in the resulting codesigned
     DMG 1630310848, 7be143a960e2's POSIX timestamp. This differs from the
     POSIX timestamp of 22.0rc3, which is 1630348517. Note that the
     windows codesigning procedure does not consider SOURCE_DATE_EPOCH.

  We resolve this by only allowing VERSION overrides via the FORCE_VERSION
  environment variable.
  ```

  Please ignore the branch name, it's not relevant to the change.

ACKs for top commit:
  fanquake:
    ACK 96cc6bb04f  - Also makes sense given there are Guix build guides recommending to set `VERSION` as part of the process. i.e https://gist.github.com/hebasto/7293726cbfcd0b58e1cfd5418316cee3.

Tree-SHA512: 9dca3fc637ce11049286a3ebee3cd61cce2125fc51d31cf472fbed7f659e1846fc44062753e0e71bfaec9e7fbab6f040bb88d9d4bc4f8acb28c6890563584acf
2021-09-02 09:35:15 +08:00
.github doc: Remove label from good first issue template 2020-08-24 09:31:24 +02:00
.tx qt: Bump transifex slug for 22.x 2021-04-21 13:46:41 +02:00
build_msvc Merge bitcoin/bitcoin#22155: wallet test: Add test for subtract fee from recipient behavior 2021-07-27 11:21:46 +02:00
build-aux/m4 build, qt: Fix typo in QtInputSupport check 2021-08-27 17:50:30 +03:00
ci Merge bitcoin/bitcoin#22744: ci: Re-enable verify-commits.py check 2021-08-31 20:48:31 +08:00
contrib Merge bitcoin/bitcoin#22847: guix/prelude: Override VERSION with FORCE_VERSION 2021-09-02 09:35:15 +08:00
depends depends: use latest config.guess and config.sub for sqlite 2021-07-22 11:10:29 +08:00
doc doc: mention bech32m/BIP350 in doc/descriptors.md 2021-08-30 13:45:22 -04:00
share refactor: replace remaining binascii method calls 2021-08-16 19:30:56 +01:00
src Merge bitcoin/bitcoin#22512: Consolidate XOnlyPubKey lookup hack 2021-09-02 13:31:10 +12:00
test Merge bitcoin/bitcoin#22437: test, refactor: add GetTransaction() coverage, improve rpc_rawtransaction 2021-09-01 18:16:20 +02:00
.appveyor.yml Switch Appveyor CI to VS2019 stable image 2021-06-14 20:35:00 +01:00
.cirrus.yml ci: Unconditionally set the global git author name in cirrys.yml 2021-08-26 11:17:07 +02:00
.editorconfig Add EditorConfig file. 2021-02-10 08:00:06 +01:00
.gitattributes Separate protocol versioning from clientversion 2014-10-29 00:24:40 -04:00
.gitignore build: add *~ to .gitignore 2021-05-12 18:10:47 +02:00
.python-version Bump minimum python version to 3.6 2020-11-09 17:53:47 +10:00
.style.yapf test: .style.yapf: Set column_limit=160 2019-03-04 18:28:13 -05:00
autogen.sh scripted-diff: Bump copyright of files changed in 2019 2019-12-30 10:42:20 +13:00
configure.ac Merge bitcoin/bitcoin#20586: Fix Windows build with --enable-werror 2021-08-27 08:31:45 +02:00
CONTRIBUTING.md doc: Update GitHub documentation links 2021-08-19 20:42:26 +02:00
COPYING doc: Update license year range to 2021 2020-12-30 16:24:47 +01:00
INSTALL.md Update INSTALL landing redirection notice for build instructions. 2016-10-06 12:27:23 +13:00
libbitcoinconsensus.pc.in build: remove libcrypto as internal dependency in libbitcoinconsensus.pc 2019-11-19 15:03:44 +01:00
Makefile.am Merge bitcoin/bitcoin#22234: build: Mark print-% target as phony. 2021-07-18 13:41:24 +08:00
README.md doc: Rework internal and external links 2021-02-17 09:18:46 +01:00
REVIEWERS Update REVIEWERS: I've found that I keep track of PRs in need of review without the need for DrahtBot's automated notification :) 2021-06-10 09:00:05 +00:00
SECURITY.md doc: Remove explicit mention of version from SECURITY.md 2019-06-14 06:39:17 -04:00

Bitcoin Core integration/staging tree

https://bitcoincore.org

For an immediately usable, binary version of the Bitcoin Core software, see https://bitcoincore.org/en/download/.

Further information about Bitcoin Core is available in the doc folder.

What is Bitcoin?

Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.

For more information read the original Bitcoin whitepaper.

License

Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.

Development Process

The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. Tags are created regularly from release branches to indicate new official, stable release versions of Bitcoin Core.

The https://github.com/bitcoin-core/gui repository is used exclusively for the development of the GUI. Its master branch is identical in all monotree repositories. Release branches and tags do not exist, so please do not fork that repository unless it is for development reasons.

The contribution workflow is described in CONTRIBUTING.md and useful hints for developers can be found in doc/developer-notes.md.

Testing

Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.

Automated Testing

Developers are strongly encouraged to write unit tests for new code, and to submit new unit tests for old code. Unit tests can be compiled and run (assuming they weren't disabled in configure) with: make check. Further details on running and extending unit tests can be found in /src/test/README.md.

There are also regression and integration tests, written in Python. These tests can be run (if the test dependencies are installed) with: test/functional/test_runner.py

The CI (Continuous Integration) systems make sure that every pull request is built for Windows, Linux, and macOS, and that unit/sanity tests are run automatically.

Manual Quality Assurance (QA) Testing

Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.

Translations

Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.

Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.

Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.