aboutsummaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)Author
2021-12-09Merge bitcoin/bitcoin#23658: contrib: add check for wget command in ↵W. J. van der Laan
install_db4.sh b062da009001c1beb362169d700663d7220eef5e contrib: add check for wget command in install_db4.sh (Florian Baumgartl) Pull request description: This PR is motivated by https://github.com/bitcoin/bitcoin/commit/7bb8eb0bc352b47ee962283898f9becbb4f36c62 commit (see also https://github.com/bitcoin/bitcoin/pull/23579) and ensures that `install_db4.sh` will check for `curl` and `wget` utilities. Currently, the conditional statement in the `http_get()` function assumes that `wget` is always available but we actually do not know it since there is no check or validation for the `wget` command. So let's make sure that we check for both commands and print an error message if they are missing. ACKs for top commit: jamesob: ACK https://github.com/bitcoin/bitcoin/pull/23658/commits/b062da009001c1beb362169d700663d7220eef5e laanwj: Tested ACK b062da009001c1beb362169d700663d7220eef5e shaavan: ACK b062da009001c1beb362169d700663d7220eef5e Tree-SHA512: bfc1ccad9a5b99764b759e02dde1976616c2af4747b7d5af8e71d33624c2cb21d93a09a60d244756e86bbd5fd7541331c62d7eb84d3458b6a059f1d9cb2a5f42
2021-12-09Merge bitcoin/bitcoin#23585: scripted-diff: Drop Darwin version for better ↵fanquake
maintainability 2f356a0ca8b080c860c8924d201b98f1f9fa0ad5 scripted-diff: Drop Darwin version for better maintainability (Hennadii Stepanov) Pull request description: After this PR, any macOS tools version bumping in the future will touch fewer files in the repo. Pointing a Darwin version for the `--host` system does not matter for the following reasons: - in terms of the resulted binaries, we should only care about the minimum supported macOS version which is a separated parameter in our build system. - in terms of the build system itself, the usage of the `$(host)` variable is self-consistent enough. Btw `$(host_os)` value already has the version dropped: ``` $ make -C depends --no-print-directory print-host_os HOST=x86_64-apple-darwin19 host_os=darwin ``` ACKs for top commit: gruve-p: ACK https://github.com/bitcoin/bitcoin/pull/23585/commits/2f356a0ca8b080c860c8924d201b98f1f9fa0ad5 promag: ACK 2f356a0ca8b080c860c8924d201b98f1f9fa0ad5. fanquake: ACK 2f356a0ca8b080c860c8924d201b98f1f9fa0ad5 Tree-SHA512: 374896ab0ba02b0d8b4b21431fe963bd213b0d09586e0898c13a4c5fa294c1b693f1b2c92880c245c4157c14217b4825b36522f461930477f4d2a727086ebb2a
2021-12-03build: qt 5.15.2fanquake
2021-12-02contrib: add check for wget command in install_db4.shFlorian Baumgartl
2021-11-30test: Bump shellcheck version to 0.8.0Hennadii Stepanov
2021-11-30Merge bitcoin/bitcoin#23506: test: Make more shell scripts verifiable by the ↵W. J. van der Laan
`shellcheck` tool a3f61676e83e908da67664c6163db61d1d11c5d2 test: Make more shell scripts verifiable by the `shellcheck` tool (Hennadii Stepanov) Pull request description: Some shell scripts from `contrib/guix` and `contrib/shell` are not verifiable by the `shellcheck` tool for the following reasons: - they have no extension (see https://github.com/bitcoin/bitcoin/pull/21375/commits/4eccf063b252bfe256cf72d363a24cf0183e926e from bitcoin/bitcoin#21375) - they have the `.bash` extension while `.sh` is expected This PR adds these scripts to the input for the `shellcheck` tool, and it fixes discovered `shellcheck` warnings. ACKs for top commit: dongcarl: Code Review ACK a3f61676e83e908da67664c6163db61d1d11c5d2, this is a good robustness improvement for our shell scripts. jamesob: crACK https://github.com/bitcoin/bitcoin/pull/23506/commits/a3f61676e83e908da67664c6163db61d1d11c5d2 Tree-SHA512: 6703f5369d9c04c1a174491f381afa5ec2cc4d37321c1b93615abcdde4dfd3caae82868b699c25b72132d8c8c6f2e9cf24d38eb180ed4d0f0584d8c282e58935
2021-11-28test: Make more shell scripts verifiable by the `shellcheck` toolHennadii Stepanov
2021-11-28[tracing] tracepoints to utxocache add, spent and uncacheArnab Sen
Signed-off-by: Arnab Sen <arnabsen1729@gmail.com>
2021-11-28[tracing] tracepoint for utxocache flushesArnab Sen
Signed-off-by: Arnab Sen <arnabsen1729@gmail.com>
2021-11-25contrib: Specify wb mode when creating mac sdkJoão Barbosa
Fix the warning: ``` ./contrib/macdeploy/gen-sdk:84: FutureWarning: GzipFile was opened for writing, but this will change in future Python releases. Specify the mode argument for opening it for writing. ```
2021-11-25scripted-diff: Drop Darwin version for better maintainabilityHennadii Stepanov
-BEGIN VERIFY SCRIPT- sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19') -END VERIFY SCRIPT-
2021-11-23script install_db4.sh added check for patch commandNathan Garabedian
2021-11-17scripts: test for PE control flow instrumentationfanquake
2021-11-16build: require glibc 2.18+ for release buildsfanquake
From what I can see the only platform this drops support for is CentOS 7. CentOS 7 reached the end of it's "full update" support at the end of 2020. It does receive maintenance updates until 2024, however I don't think supporting glibc 2.17 until 2024 is realistic. Note that anyone wanting to self-compile and target a glibc 2.17 runtime could build with --disable-threadlocal. glibc 2.18 was released in August 2013. https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html
2021-11-15Merge bitcoin/bitcoin#23462: test: Enable SC2046 and SC2086 shellcheck rulesW. J. van der Laan
fe0ff569ea6c353f88609c0f5f9b6fa80ff74f15 test: Enable SC2046 shellcheck rule (Hennadii Stepanov) 9a1ad7bc0dd8a0769738ca4dffbeb8d55438b0dc test: Enable SC2086 shellcheck rule (Hennadii Stepanov) Pull request description: Closes #20879. Replaces #22695. **Note for reviewers**. Some touched shell scripts are not being run in CI, therefore they require more thorough reviewing: - `contrib/devtools/gen-manpages.sh` - `contrib/macdeploy/detached-sig-apply.sh` - `contrib/windeploy/detached-sig-create.sh` - `src/qt/res/animation/makespinner.sh` ACKs for top commit: laanwj: Code review re-ACK fe0ff569ea6c353f88609c0f5f9b6fa80ff74f15 Tree-SHA512: 73619b9a7bcb6cf0dfc4189a753ef550d40c82a3432bb9d8d8a994310d42594576038daac7e0c2fc004d716976bb1413b9a77848ecf088b25b69ed0773b77e8e
2021-11-14Merge bitcoin/bitcoin#22768: script: Add commits signed with sipas expired ↵W. J. van der Laan
key to allow-revsig-commits 365f35481d5c04109d64e88e548d6985705c2f75 script: Add commits signed with sipas expired key to allow-revsig-commits (nthumann) Pull request description: Fixes https://github.com/bitcoin/bitcoin/issues/22737. While investigating the issue above, I noticed that there are 141 commits that are signed with sipas expired key. To allow `./contrib/verify-commits/verify-commits.py` to succeed, this PR adds them to `allow-revsig-commits`. Feel free to confirm that they're indeed signed with an expired key using e.g. `git show --show-signature d8cd7b137fb075616f31d2b43b85fa2e27ea7477` :) ACKs for top commit: laanwj: Code review ACK 365f35481d5c04109d64e88e548d6985705c2f75 Tree-SHA512: 860e372c5314714c6c205cd234ebec89756c9ade43a2ed65ed25575ae0a0d4d8dd7cf43692a5b267abe742f87e5cba0a3f1fb76a5fed7b1615ea2859902dfcdf
2021-11-13test: Enable SC2046 shellcheck ruleHennadii Stepanov
2021-11-13test: Enable SC2086 shellcheck ruleHennadii Stepanov
2021-11-12Merge bitcoin/bitcoin#23114: Add minisketch subtree and integrate into ↵fanquake
build/test 29173d6c6ca0cc3be9fa6bf2409a509ffea1a02a ubsan: add minisketch exceptions (Cory Fields) 54b5e1aeab73953c1f12ec2c041572038f6f59da Add thin Minisketch wrapper to pick best implementation (Pieter Wuille) ee9dc71c1bc16205494f2a0aebe575a3c062ff52 Add basic minisketch tests (Pieter Wuille) 0659f12b131fc5915fe7a493306af197f4fb838b Add minisketch dependency (Gleb Naumenko) 0eb7928ab8d9dcb840e4965bfa81deb752b00dfa Add MSVC build configuration for libminisketch (Pieter Wuille) 8bc166d5b179205fc56855e2b462aa273a6f8661 build: add minisketch build file and include it (Cory Fields) b2904ceb85b4d440b1f4bbd716fcb601411cc2c9 build: add configure checks for minisketch (Cory Fields) b6487dc4ef47ec9ea894eceac25f37d0b806f8aa Squashed 'src/minisketch/' content from commit 89629eb2c7 (fanquake) Pull request description: This takes over #21859, which has [recently switched](https://github.com/bitcoin/bitcoin/pull/21859#issuecomment-921899200) to my integration branch. A few more build issues came up (and have been fixed) since, and after discussing with sipa it was decided I would open a PR to shepherd any final changes through. > This adds a `src/minisketch` subtree, taken from the master branch of https://github.com/sipa/minisketch, to prepare for Erlay implementation (see #21515). It gets configured for just supporting 32-bit fields (the only ones we're interested in in the context of Erlay), and some code on top is added: > * A very basic unit test (just to make sure compilation & running works; actual correctness checking is done through minisketch's own tests). > * A wrapper in `minisketchwrapper.{cpp,h}` that runs a benchmark to determine which field implementation to use. Only changes since my last update to the branch in the previous PR have been rebasing on master and fixing an issue with a header in an introduced file. ACKs for top commit: naumenkogs: ACK 29173d6c6ca0cc3be9fa6bf2409a509ffea1a02a Tree-SHA512: 1217d3228db1dd0de12c2919314e1c3626c18a416cf6291fec99d37e34fb6eec8e28d9e9fb935f8590273b8836cbadac313a15f05b4fd9f9d3024c8ce2c80d02
2021-11-03contrib: recognize CJDNS seeds as suchVasil Dimov
An IPv6 address from fc00::/8 could be either from the CJDNS network or from a private-unroutable-reserved segment of IPv6. A seed node with such an address must be from the CJDNS network, otherwise other peers will not be able to connect to it.
2021-10-21Add minisketch dependencyGleb Naumenko
2021-10-20Merge bitcoin/bitcoin#22646: build: tighter Univalue integration, remove ↵fanquake
`--with-system-univalue` 0f95247246344510c9a51810c14c633abb382e95 Integrate univalue into our buildsystem (Cory Fields) 9b49ed656fb2b687fbbe8a3236d18285957eee16 Squashed 'src/univalue/' changes from 98fadc0909..a44caf65fe (fanquake) Pull request description: This PR more tightly integrates building Univalue into our build system. This follows the same approach we use for [LevelDB](https://github.com/bitcoin-core/leveldb/), ([`Makefile.leveldb.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.leveldb.include)), and [CRC32C](https://github.com/bitcoin-core/crc32c) ([`Makefile.crc32c.include`](https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.crc32c.include)), and will be the same approach we use for [minisketch](https://github.com/sipa/minisketch); see #23114. This approach yields a number of benefits, including: * Faster configuration due to one less subconfigure being run during `./configure` i.e 22s with this PR vs 26s * Faster autoconf i.e 13s with this PR vs 17s * Improved caching * No more issues with compiler flags i.e https://github.com/bitcoin/bitcoin/pull/12467 * More direct control means we can build exactly the objects we want There might be one argument against making this change, which is that builders should have the option to use "proper shared/system libraries". However, I think that falls down for a few reasons. The first being that we already don't support building with a number of system libraries (secp256k1, leveldb, crc32c); some for good reason. Univalue is really the odd one out at the moment. Note that the only fork of Core I'm aware of, that actively patches in support for using system libs, also explicitly marks them as ["DANGEROUS"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1430) and ["NOT SUPPORTED"](https://github.com/bitcoinknots/bitcoin/blob/a886811721ce66eb586871706b3f5dd27518ac3e/configure.ac#L1312). So it would seem they exist more to satisfy a distro requirement, as opposed to something that anyone should, or would actually use in practice. PRs like #22412 highlight the "issue" with us operating with our own Univalue fork, where we actively fix bugs, and make improvements, when upstream (https://github.com/jgarzik/univalue) may not be taking those improvements, and by all accounts, is not currently actively maintained. Bitcoin Core should not be hamstrung into not being able to fix bugs in a library, and/or have to litter our source with "workarounds", i.e #22412, for bugs we've already fixed, based on the fact that an upstream project is not actively being maintained. Allowing builders to use system libs is really only exacerbating this problem, with little benefit to our project. Bitcoin Core is not quite like your average piece of distro packaged software. There is the potential for us to give the same treatment to libsecp256k1, however it seems doing that is currently less straightforward. ACKs for top commit: dongcarl: ACK 0f95247246 less my comment above, always nice to have an include-able `sources.mk` which makes integration easier. theuni: ACK 0f95247246344510c9a51810c14c633abb382e95. Thanks fanquake for keeping this going. Tree-SHA512: a7f2e41ee7cba06ae72388638e86b264eca1b9a8b81c15d1d7b45df960c88c3b91578b4ade020f8cc61d75cf8d16914575f9a78fa4cef9c12be63504ed804b99
2021-10-18tracing: drop block_connected hash.toString() arg0xb10c
The tracepoint `validation:block_connected` was introduced in #22006. The first argument was the hash of the connected block as a pointer to a C-like String. The last argument passed the hash of the connected block as a pointer to 32 bytes. The hash was only passed as string to allow `bpftrace` scripts to print the hash. It was (incorrectly) assumed that `bpftrace` cannot hex-format and print the block hash given only the hash as bytes. The block hash can be printed in `bpftrace` by calling `printf("%02x")` for each byte of the hash in an `unroll () {...}`. By starting from the last byte of the hash, it can be printed in big-endian (the block-explorer format). ```C $p = $hash + 31; unroll(32) { $b = *(uint8*)$p; printf("%02x", $b); $p -= 1; } ``` See also: https://github.com/bitcoin/bitcoin/pull/22902#discussion_r705176691 This is a breaking change to the block_connected tracepoint API, however this tracepoint has not yet been included in a release.
2021-10-16lint: enable mypy checking for missing importsjosibake
Achieve this by adding some ignore, and making data/ importable. Co-authored-by: João Barbosa <joao.paulo.barbosa@gmail.com>
2021-10-13symbol-check: Check requested ELF interpreterCarl Dong
It is important that binaries request a standard interpreter location where most distros would place the linker-loader. Otherwise, the user would be met with a very confusing message: bash: <path>/<to>/bitcoind: No such file or directory When really it's the interpreter that's not found.
2021-10-13guix: Fix powerpc64(le) dynamic linker nameCarl Dong
I used Guix's values for the powerpc64(le) dynamic linkers, and the /lib-prefix seems to be a Guix-ism rather than standard. The standard path for the linker-loaders start with /lib64. I've taken the new loader values from SYSDEP_KNOWN_INTERPRETER_NAMES in glibc's sysdeps/unix/sysv/linux/powerpc/ldconfig.h file. For future reference, loader path values can also be found on glibc's website: https://sourceware.org/glibc/wiki/ABIList?action=recall&rev=16
2021-10-12scripts: remove pixie.pyfanquake
2021-10-12scripts: only parse the binary once in security-check.pyfanquake
2021-10-12scripts: use LIEF for ELF checks in security-check.pyfanquake
2021-10-12scripts: only parse the binary once in symbol-check.pyfanquake
2021-10-12scripts: use LIEF for ELF checks in symbol-check.pyfanquake
Co-authored-by: Carl Dong <contact@carldong.me>
2021-10-12test-*-check: Pass in *FLAGS and compile with themCarl Dong
These test-*-check scripts should compile "test" binaries in a way that is as close to what autotools would do, since the goal is to make sure that if we run the *-check script, they can correctly detect flaws in binaries which are compiled by our autotools-based system. Therefore, we should emulate what happens when the binary is linked in autotools, meaning that for C binaries, we need to supply the CFLAGS, CPPFLAGS, and LDFLAGS flags in that order. Note to future developers: perhaps it'd be nice to have these test-*-check scripts be part of configure.ac to avoid having to manually replicate autoconf-like behaviour every time we find a discrepancy. Of course, that would also mean you'd have to write more m4...
2021-10-11Integrate univalue into our buildsystemCory Fields
This addresses issues like the one in #12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++17. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Core benefits of this approach include: - Better caching (for ex. ccache and autoconf) - No need for a slow subconfigure - Faster autoconf - No more missing compile flags - Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries. Co-authored-by: fanquake <fanquake@gmail.com>
2021-10-02contrib: Ask for captcha in signet getcoins.pyW. J. van der Laan
As the faucet will always ask for a captcha now, the current script is no longer usable. Change the script to print the captcha in dot-matrix to the terminal, using unicode Braille characters.
2021-09-21Merge bitcoin/bitcoin#22993: build: set OSX_MIN_VERSION to 10.15fanquake
a43b8e955558483d8893996cc3a67bc74cbaf358 build: set OSX_MIN_VERSION to 10.15 (fanquake) Pull request description: Taken out of #20744, as splitting up some of the build changes was mentioned [here](https://github.com/bitcoin/bitcoin/pull/22937#discussion_r707303172). This is required to use `std::filesystem` on macOS, as support for it only landed in the libc++.dylib shipped with 10.15. So if we want to move to using `std::filesystem` for `23.0`, this bump is required. See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes > Clang now supports the C++17 \<filesystem\> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13. macOS 10.15 was released in October 2019. macOS OS's seem to have a life of about 3 years, so it's possible that 10.14 will become officially unsupported by the end of 2021 and prior to the release of 23.0. Guix builds: ```bash bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum abc8b749be65f1339dcdf44bd1ed6ade2533b8e3b5030ad1dde0ae0cede78136 guix-build-a43b8e955558/output/dist-archive/bitcoin-a43b8e955558.tar.gz 1edcc301eb4c02f3baa379beb8d4c78e661abc24a293813bc9d900cf7255b790 guix-build-a43b8e955558/output/x86_64-apple-darwin19/SHA256SUMS.part e9dbb5594a664519da778dde9ed861c3f0f631525672e17a67eeda599f16ff44 guix-build-a43b8e955558/output/x86_64-apple-darwin19/bitcoin-a43b8e955558-osx-unsigned.dmg 11b23a17c630dddc7594c25625eea3de42db50f355733b9ce9ade2d8eba3a8f3 guix-build-a43b8e955558/output/x86_64-apple-darwin19/bitcoin-a43b8e955558-osx-unsigned.tar.gz 257ba64a327927f94d9aa0a68da3a2695cf880b3ed1a0113c5a966dcc426eb5e guix-build-a43b8e955558/output/x86_64-apple-darwin19/bitcoin-a43b8e955558-osx64.tar.gz ``` ACKs for top commit: hebasto: ACK a43b8e955558483d8893996cc3a67bc74cbaf358 jarolrod: ACK a43b8e9 Tree-SHA512: 9ac77be7cb56c068578860a3b2b8b7487c9e18b71b14aedd77a9c663f5d4bb19756d551770c02ddd12f1797beea5757b261588e7b67fb53509bb998ee8022369
2021-09-16Enable TLS in links in documentationJeremy Rand
2021-09-16build: set OSX_MIN_VERSION to 10.15fanquake
This is required to use std::filesystem on macOS as support for it only landed in the libc++ dylib shipped with 10.15. See also: https://developer.apple.com/documentation/xcode-release-notes/xcode-11-release-notes Clang now supports the C++17 <filesystem> library for iOS 13, macOS 10.15, watchOS 6, and tvOS 13.
2021-09-02Merge bitcoin/bitcoin#22418: release: Remove gitianMarcoFalke
ab9c34237ab7b056394e0bd1f7cb131ffd95754c release: remove gitian (fanquake) Pull request description: Note that this doesn't yet touch any glibc back compat related code. ACKs for top commit: laanwj: Code review ACK ab9c34237ab7b056394e0bd1f7cb131ffd95754c Tree-SHA512: 8e2fe3ec1097f54bb11ab9136b43818d90eab5dbb0a663ad6a552966ada4bdb49cc12ff4e66f0ec0ec5400bda5c81f3a3ce70a9ebb6fe1e0db612da9f00a51a7
2021-09-02Merge bitcoin/bitcoin#22847: guix/prelude: Override `VERSION` with ↵fanquake
`FORCE_VERSION` 96cc6bb04f7e173e1f7637b780ac00fc75486671 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 7be143a960e2 3. Aug 30th, sometime before POSIX time 1630315907: With his worktree still on 7be143a960e2, 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 (7be143a960e2), 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 96cc6bb04f7e173e1f7637b780ac00fc75486671 - 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-08-31guix/prelude: Override VERSION with FORCE_VERSIONCarl Dong
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 7be143a960e2 3. Aug 30th, sometime before POSIX time 1630315907: With his worktree still on 7be143a960e2, 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 (7be143a960e2), 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.
2021-08-31builder-keys: add kristapskKristaps Kaupe
https://keys.openpgp.org/search?q=70A1D47DD44F59DF8B22244333E472FE870C7E5D https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/pubkeys/KristapsKaupe.asc
2021-08-31release: remove gitianfanquake
2021-08-26Merge bitcoin/bitcoin#22660: contrib: catch bitcoin-cli RPC call errors in ↵MarcoFalke
getcoins.py 42dbd9025adc200012c103d2c091cf026f1d50b1 contrib: return non-zero status if getcoins.py errors (Sebastian Falbesoner) 8c203cf0e1b9558b54030c284ddf7706d64cdde2 contrib: catch bitcoin-cli RPC call errors in getcoins.py (Sebastian Falbesoner) 0eca5ebaced264d041de815316eaca8cf6fef92f contrib: refactor: introduce bitcoin-cli RPC call helper in getcoins.py (Sebastian Falbesoner) Pull request description: This PR is based on #22565 ("[script] signet's getcoins.py improvements"), which should be reviewed first. The signet faucet script `contrib/signet/getcoins.py` currently issues bitcoin-cli RPC calls without catching errors -- the only case tackled is if there is no `bitcoin-cli` file found. Instead of crashing with a stack-trace on a failed RPC call, the changes in this PR aim to produce a more user-friendly output (see also https://github.com/bitcoin/bitcoin/pull/22565#discussion_r683754875). Additionally, in case of any error, a non-zero status is now returned (instead of 0, indicating success), which could be useful for other scripts taking use of signet faucet script. The most straight-forward way to test this is invoking the script without a `bitcoind` running on signet: PR22565 branch: ``` $ ./contrib/signet/getcoins.py error: Could not connect to the server 127.0.0.1:8332 Make sure the bitcoind server is running and that you are connecting to the correct RPC port. Traceback (most recent call last): File "./contrib/signet/getcoins.py", line 26, in <module> curr_signet_hash = subprocess.check_output([args.cmd] + args.bitcoin_cli_args + ['getblockhash', '1']).strip().decode() File "/usr/local/lib/python3.8/subprocess.py", line 415, in check_output return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, File "/usr/local/lib/python3.8/subprocess.py", line 516, in run raise CalledProcessError(retcode, process.args, subprocess.CalledProcessError: Command '['bitcoin-cli', 'getblockhash', '1']' returned non-zero exit status 1. ``` this PR branch: ``` $ ./contrib/signet/getcoins.py error: Could not connect to the server 127.0.0.1:38332 Make sure the bitcoind server is running and that you are connecting to the correct RPC port. ----- Error while calling "bitcoin-cli -signet getblockhash 1" (see output above). ``` ACKs for top commit: kallewoof: Code ACK 42dbd9025adc200012c103d2c091cf026f1d50b1 Zero-1729: tACK 42dbd90 🧪 Tree-SHA512: 912240a4ed03c87035e370602f4095c7ffe26806421bbbd6cf86588126f2310a01a6a61606e9e2918fb2c1a0debdd0ce768c69ba2e4b8e7750fa3474a56d01a0
2021-08-22script: Add commits signed with sipas expired key to allow-revsig-commitsnthumann
2021-08-23Merge bitcoin/bitcoin#22565: [script] signet's getcoins.py improvementsW. J. van der Laan
b0c8246cac97b7792a50afc22ef1fe39c5028e00 Add cleaner errors for unsuccessful faucet transactions (NikhilBartwal) 1c612b274b1587c43ee6e6a486aed653b9ca5f70 [script] Update signet getcoins.py for custom network (NikhilBartwal) Pull request description: Currently, using the getcoins.py with a custom signet executes successfully and shows the transfer of 0.001 testBTC as complete, however for obvious reasons, it should not. In fact, upon verification it does not actually execute the transaction, but rather gives the output that it did, as shown below which can be misleading: ``` [nikhilb@nikhil-PC bitcoin]$ echo $datadir /home/nikhilb/signet-custom [nikhilb@nikhil-PC bitcoin]$ contrib/signet/getcoins.py -- -datadir=$datadir Payment of 0.00100000 BTC sent with txid dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86 [nikhilb@nikhil-PC bitcoin]$ bitcoin-cli -datadir=$datadir getrawtransaction dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86 error code: -5 error message: No such mempool or blockchain transaction. Use gettransaction for wallet transactions. [nikhilb@nikhil-PC bitcoin]$ bitcoin-cli -datadir=$datadir gettransaction dd22c7d996e95f3e5baf20f73140d517ff48f1b26d0e4fefd61e3c37991b8f86 error code: -5 error message: Invalid or non-wallet transaction id ``` This PR adds a sanity check for custom signet by comparing the current network's first block hash (the block after the genesis block) with global signet's respective block hash (since all signet networks share the same genesis block) and if a custom network is detected, the user is prompted to either work on the global signet or setup their own faucet. The PR was checked to be working successfully, giving the output as below: ``` [nikhilb@nikhil-PC bitcoin]$ git checkout update_signet_getcoins Switched to branch 'update_signet_getcoins' Your branch is ahead of 'upstream/master' by 1 commit. (use "git push" to publish your local commits) [nikhilb@nikhil-PC bitcoin]$ contrib/signet/getcoins.py -- -datadir=$datadir The global faucet cannot be used with a custom Signet network. Please use the global signet or setup your custom faucet for the same. You can have a look here for setting up your own faucet: https://en.bitcoin.it/wiki/Signet ``` ACKs for top commit: prayank23: utACK https://github.com/bitcoin/bitcoin/pull/22565/commits/b0c8246cac97b7792a50afc22ef1fe39c5028e00 kallewoof: ACK b0c8246cac97b7792a50afc22ef1fe39c5028e00 arnabsen1729: utACK b0c8246 prakash1512: utACK b0c8246 0xB10C: Tested ACK b0c8246cac97b7792a50afc22ef1fe39c5028e00 theStack: Tested ACK b0c8246cac97b7792a50afc22ef1fe39c5028e00 Zero-1729: crACK b0c8246 🧉 Tree-SHA512: 144b47a83008521a5cda13f4c1b12809a125a744f865a8e0f792132d52fdb88926d4f4f4d7230452c2e129b5879892cdbeda981b8af10b789e9fc0cda2905a5d
2021-08-20Merge bitcoin/bitcoin#22654: guix: Don't include directory name in SHA256SUMSfanquake
132cae44f2d031bdaa1e459b92ec89ad585dfc9f doc: Mention the flat directory structure for uploads (Andrew Chow) fb17c99e35e72f3b21ec3b5473e84c21dc964776 guix: Don't include directory name in SHA256SUMS (Andrew Chow) Pull request description: The SHA256SUMS file can be used in a sha256sum -c command to verify downloaded binaries. However users are likely to download just a single file and not place this file in the correct directory relative to the SHA256SUMS file for the simple verification command to work. By not including the directory name in the SHA256SUMS file, it will be easier for users to verify downloaded binaries. ACKs for top commit: Zero-1729: re-ACK 132cae44f2d031bdaa1e459b92ec89ad585dfc9f fanquake: ACK 132cae44f2d031bdaa1e459b92ec89ad585dfc9f Tree-SHA512: c9ff416b8dfb2f3ceaf4d63afb84aac9fcaefbbf9092f9e095061b472884ec92c7a809e6530c7132a82cfe3ab115a7328e47994a412072e1d4feb26fc502c8c5
2021-08-18guix: Don't include directory name in SHA256SUMSAndrew Chow
The SHA256SUMS file can be used in a sha256sum -c command to verify downloaded binaries. However users are likely to download just a single file and not place this file in the correct directory relative to the SHA256SUMS file for the simple verification command to work. By not including the directory name in the SHA256SUMS file, it will be easier for users to verify downloaded binaries. Co-authored-by: Carl Dong <contact@carldong.me>
2021-08-21Merge bitcoin/bitcoin#22633: refactor: Replace remaining binascii method callsMarcoFalke
021daedfa100defad553d69cd3d628aaa5bc7caf refactor: replace remaining binascii method calls (Zero-1729) Pull request description: This PR removes the remaining `binascii` method calls outside `test/functional` and `test_framework`, as pointed out here https://github.com/bitcoin/bitcoin/pull/22619#pullrequestreview-722153458. Follow-up to #22593 and #22619 Closes #22605 ACKs for top commit: josibake: re-ACK https://github.com/bitcoin/bitcoin/pull/22633/commits/021daedfa100defad553d69cd3d628aaa5bc7caf theStack: re-ACK 021daedfa100defad553d69cd3d628aaa5bc7caf Tree-SHA512: 2ae9fee8917112c91a5406f219ca70f24cd8902b903db5a61fc2de85ad640d669a772f5c05970be0fcee6ef1cdd32fae2ca5d1ec6dc9798b43352c8160ddde6f
2021-08-18Merge bitcoin/bitcoin#22645: scripts: prevent GCC optimising test symbols in ↵W. J. van der Laan
test-symbol-check 5449d44e37982fcd5251fd47873c5f7d34c39fc9 scripts: prevent GCC optimising test symbols in test-symbol-check (fanquake) Pull request description: I noticed in #22381 that when the test-symbol-check target was being built with Clang and run in the CI it would fail due to using a too-new version of `pow` (used [here](https://github.com/bitcoin/bitcoin/blob/d67330d11245b11fbdd5e2dd5343ee451186931e/contrib/devtools/test-symbol-check.py#L85)). Our CIs use Focal (glibc 2.31) and the version of `pow` was the optimized version introduced in [glibc 2.29](https://lwn.net/Articles/778286/): ```bash * Optimized generic exp, exp2, log, log2, pow, sinf, cosf, sincosf and tanf. ``` This made sense, except for that if it was failing when built using Clang, why hadn't it also been failing when being built with GCC? Turns out GCC is optimizing away that call to `pow` at all optimization levels, including `-O0`, see: https://godbolt.org/z/53MhzMxT7, and this has been the case forever, or at least since GCC 5.x. Clang on the other hand, will only optimize away the `pow` call at `-O1` and `-O2`, not `-O0`: https://godbolt.org/z/Wbnqj3q6c. Thus when this test was built with Clang (we don't pass `-O` so we default to `-O0`) it was failing in the CI environment, because it would actually have a call to the "new" `pow`. Avoid this issue by using a symbol that won't be optimized away, or that we are unlikely to ever have versioning issues with. ACKs for top commit: laanwj: ACK 5449d44e37982fcd5251fd47873c5f7d34c39fc9 Tree-SHA512: 3a26c5c3a5f2905fd0dd90892470e241ba625c0af3be2629d06d5da3a97534c1d6a55b796bbdd41e2e6a26a8fab7d981b98c45d4238565b0eb7edf3c5da02007
2021-08-16refactor: replace remaining binascii method calls Zero-1729
generated by cgit v1.2.3 (git 2.26.2) at 2024-07-19 01:35:04 +0000