Age | Commit message (Collapse) | Author |
|
only when run fuzzing
0b7c55f157514e1845934fff3f9c66e862c526ca ci: Clone entire bitcoin-core/qa-assets repo only when run fuzzing (Hennadii Stepanov)
Pull request description:
This PR speeds up CI tasks that run unit tests but do not run fuzzing.
On my machine:
```
$ time git clone --depth=1 https://github.com/bitcoin-core/qa-assets
Cloning into 'qa-assets'...
remote: Enumerating objects: 289750, done.
remote: Counting objects: 100% (289750/289750), done.
remote: Compressing objects: 100% (207687/207687), done.
remote: Total 289750 (delta 16863), reused 275449 (delta 12092), pack-reused 0
Receiving objects: 100% (289750/289750), 1.39 GiB | 4.79 MiB/s, done.
Resolving deltas: 100% (16863/16863), done.
Updating files: 100% (294515/294515), done.
real7m43,417s
user2m39,771s
sys0m43,272s
```
ACKs for top commit:
MarcoFalke:
cr ACK 0b7c55f157514e1845934fff3f9c66e862c526ca
Tree-SHA512: 8f8dd63e361c3d9c64a2b31f207f59beea7d2e4142363f7762ec724a61152323fda0c6b98a36386e15f2ca4ef3f7412da763baef65e862fc7f48cdeda8c40e09
|
|
|
|
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
|
|
1362d6173f863428de17c4017f4e3bb6883b0be8 scripted-diff: Insert missed copyright headers (Hennadii Stepanov)
f47dda2c58b5d8d623e0e7ff4e74bc352dfa83d7 scripted-diff: Bump copyright headers (Hennadii Stepanov)
c29105efdc3daac0e8c43138f7c0a50535556455 script: Fix copyright_header.py (Hennadii Stepanov)
Pull request description:
This PR is an alternative to #23903.
It bumps the existing copyright headers as we did every year, and adds the missed copyright headers.
A small fix has been applied to the `copyright_header.py` in order to prevent such weird bumping as `2021` --> `2021-2017`.
ACKs for top commit:
MarcoFalke:
ACK 1362d6173f863428de17c4017f4e3bb6883b0be8
Tree-SHA512: 204d970fe8c51546b26b8f03fe4297db8a9bef5101df851540b7b9eddbd3a09677ee81fdd882c60937d732407f42c9883165bd978272200cff8f90190f075905
|
|
-BEGIN VERIFY SCRIPT-
./contrib/devtools/copyright_header.py update ./
-END VERIFY SCRIPT-
Commits of previous years:
* 2020: fa0074e2d82928016a43ca408717154a1c70a4db
* 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
|
|
|
|
Our minimum required GCC is GCC 8, and this change in required for
changes like #23839 which take advantage of flags introduced in that
version of GCC.
This should have been included as part of
182de7ba10811ec39e24ec5bec7cd2119f776f2f.
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
-BEGIN VERIFY SCRIPT-
sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19')
-END VERIFY SCRIPT-
|
|
fafa66e424cd0c4a4ac3175e0d3b15a54626aa4b ci: Replace soon EOL hirsute with jammy (MarcoFalke)
Pull request description:
`hirsute` will be EOL in about 1.5 months, at which point the package servers may be shut down. Avoid this by hopping to the next LTS release 22.04 (Jammy Jellyfish).
While the release is currently in development, it seems unlikely that anything will break for us. I am doing the hirsute->jammy hop to avoid a hirsute->impish->jammy hop, but if anything does break, we can fall back to that "double hop".
ACKs for top commit:
fanquake:
ACK fafa66e424cd0c4a4ac3175e0d3b15a54626aa4b
Zero-1729:
crACK fafa66e424cd0c4a4ac3175e0d3b15a54626aa4b
Tree-SHA512: a3626b72519c7f54f260477d04265321af7aefe25cc2a7d653dba77f79caca10db3a6aa4249a934184dcdc99832f6b4c6e50330d7630e58720ab0aba3624ab8a
|
|
|
|
|
|
|
|
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
|
|
095f07744cf500adc1f1587eb5b7a61df6e6b05f ci: Do not print `git log` for empty COMMIT_RANGE (Hennadii Stepanov)
Pull request description:
On master (77a2f5d30c5ecb764b8a7c098492e1f5cdec90f0) a CI lint task [log](https://api.cirrus-ci.com/v1/task/4817858858319872/logs/lint.log) exceeds 20K lines.
This PR fixes this issue.
ACKs for top commit:
MarcoFalke:
cr ACK 095f07744cf500adc1f1587eb5b7a61df6e6b05f
Tree-SHA512: 89180018aeccf1599cdf218924cbab12dcbae0f6674bb90e13b64e342cdd908a880b885039c23f0d1d03493e55a94fe04abf39481616ae6550c6a759f5ca9a35
|
|
|
|
|
|
|
|
|
|
|
|
`--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
|
|
|
|
mypy stubs were introduced in 21.0.1
|
|
No behavior change.
|
|
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>
|
|
secure computing mode)
4747da3a5b639b5a336b737e7e3cbf060cf2efcf Add syscall sandboxing (seccomp-bpf) (practicalswift)
Pull request description:
Add experimental syscall sandboxing using seccomp-bpf (Linux secure computing mode).
Enable filtering of system calls using seccomp-bpf: allow only explicitly allowlisted (expected) syscalls to be called.
The syscall sandboxing implemented in this PR is an experimental feature currently available only under Linux x86-64.
To enable the experimental syscall sandbox the `-sandbox=<mode>` option must be passed to `bitcoind`:
```
-sandbox=<mode>
Use the experimental syscall sandbox in the specified mode
(-sandbox=log-and-abort or -sandbox=abort). Allow only expected
syscalls to be used by bitcoind. Note that this is an
experimental new feature that may cause bitcoind to exit or crash
unexpectedly: use with caution. In the "log-and-abort" mode the
invocation of an unexpected syscall results in a debug handler
being invoked which will log the incident and terminate the
program (without executing the unexpected syscall). In the
"abort" mode the invocation of an unexpected syscall results in
the entire process being killed immediately by the kernel without
executing the unexpected syscall.
```
The allowed syscalls are defined on a per thread basis.
I've used this feature since summer 2020 and I find it to be a helpful testing/debugging addition which makes it much easier to reason about the actual capabilities required of each type of thread in Bitcoin Core.
---
Quick start guide:
```
$ ./configure
$ src/bitcoind -regtest -debug=util -sandbox=log-and-abort
…
2021-06-09T12:34:56Z Experimental syscall sandbox enabled (-sandbox=log-and-abort): bitcoind will terminate if an unexpected (not allowlisted) syscall is invoked.
…
2021-06-09T12:34:56Z Syscall filter installed for thread "addcon"
2021-06-09T12:34:56Z Syscall filter installed for thread "dnsseed"
2021-06-09T12:34:56Z Syscall filter installed for thread "net"
2021-06-09T12:34:56Z Syscall filter installed for thread "msghand"
2021-06-09T12:34:56Z Syscall filter installed for thread "opencon"
2021-06-09T12:34:56Z Syscall filter installed for thread "init"
…
# A simulated execve call to show the sandbox in action:
2021-06-09T12:34:56Z ERROR: The syscall "execve" (syscall number 59) is not allowed by the syscall sandbox in thread "msghand". Please report.
…
Aborted (core dumped)
$
```
---
[About seccomp and seccomp-bpf](https://en.wikipedia.org/wiki/Seccomp):
> In computer security, seccomp (short for secure computing mode) is a facility in the Linux kernel. seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), and read() and write() to already-open file descriptors. Should it attempt any other system calls, the kernel will terminate the process with SIGKILL or SIGSYS. In this sense, it does not virtualize the system's resources but isolates the process from them entirely.
>
> […]
>
> seccomp-bpf is an extension to seccomp that allows filtering of system calls using a configurable policy implemented using Berkeley Packet Filter rules. It is used by OpenSSH and vsftpd as well as the Google Chrome/Chromium web browsers on Chrome OS and Linux. (In this regard seccomp-bpf achieves similar functionality, but with more flexibility and higher performance, to the older systrace—which seems to be no longer supported for Linux.)
ACKs for top commit:
laanwj:
Code review and lightly tested ACK 4747da3a5b639b5a336b737e7e3cbf060cf2efcf
Tree-SHA512: e1c28e323eb4409a46157b7cc0fc29a057ba58d1ee2de268962e2ade28ebd4421b5c2536c64a3af6e9bd3f54016600fec88d016adb49864b63edea51ad838e17
|
|
|
|
|
|
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
|
|
* Set missing DOCKER_NAME_TAG
* Update TEST_RUNNER_EXTRA
|
|
* Bump to debian:bookworm to avoid crash in the zmq functional test
(bitcoind: line 2: 33011 Illegal instruction (core dumped)
qemu-s390x)
* Remove RUN_UNIT_TESTS=true, because it is the default
* Add TEST_RUNNER_EXTRA --exclude to skip failing tests
|
|
76630cbfb9247a78c7760aa8dca62c6b599a0c7c doc: add glibc to dependencies.md (fanquake)
a907704e7f0f1989e70b9b073c25b740e9d5003d compat: remove glibc_compat.cpp (fanquake)
62e45da94537ffaecc51441896242ef5123106a5 build: remove glibc-back-compat from build system (fanquake)
2ef0accefc1653ea0845683db8256dddf3b55e04 remove --enable-glibc-back-compat from CI and docs (fanquake)
Pull request description:
This removes our glibc backwards compatibility code (glibcxx sanity checks remain), which is [no-longer used for release builds](https://github.com/bitcoin/bitcoin/pull/22405).
With these changes our minimum required glibc remains at 2.17, as Guix builds [are done with `--disable-thread-local`](https://github.com/bitcoin/bitcoin/blob/d2dd1697cee9d6d0f13f9cb351bce84eaa4a72b4/contrib/guix/libexec/build.sh#L242).
Guix builds:
```bash
d9024376ac06b836800b942fcbe8a6454866ded652e41c43d605255f840e8183 guix-build-76630cbfb924/output/aarch64-linux-gnu/SHA256SUMS.part
bea9607f111b7a501e2410e59ccfca6f83ea075edb299d2f9b878860a4f1ad50 guix-build-76630cbfb924/output/aarch64-linux-gnu/bitcoin-76630cbfb924-aarch64-linux-gnu-debug.tar.gz
b41d7eaec5b598f146ead32a40c0e2281d22138c02a7000fb154fe8ff341ab9d guix-build-76630cbfb924/output/aarch64-linux-gnu/bitcoin-76630cbfb924-aarch64-linux-gnu.tar.gz
9ec0e1b2cd4ca55d5c12354325d7c4552333f1bad7e620db247eb24e15500210 guix-build-76630cbfb924/output/arm-linux-gnueabihf/SHA256SUMS.part
dbb3e92a3b7d6460e0d5319f49c91eb65593d8604807c1b3084c9d657b198271 guix-build-76630cbfb924/output/arm-linux-gnueabihf/bitcoin-76630cbfb924-arm-linux-gnueabihf-debug.tar.gz
ff2fa70b01f92b9fba9f0216deebc3e511d84ff93a7316f6766a405160a20483 guix-build-76630cbfb924/output/arm-linux-gnueabihf/bitcoin-76630cbfb924-arm-linux-gnueabihf.tar.gz
486586b4f3e81855a52e5410127b92f6dde9d1eede2720de260b13552a4b4823 guix-build-76630cbfb924/output/dist-archive/bitcoin-76630cbfb924.tar.gz
466ccc848c39c0ca85c4575c2bfcd1bc7aba2caa5ba8a42147cce60be5120bf6 guix-build-76630cbfb924/output/powerpc64-linux-gnu/SHA256SUMS.part
4c739da127df3738e993dcef48ec8f005b7d7938060197c718e771cdd18c2087 guix-build-76630cbfb924/output/powerpc64-linux-gnu/bitcoin-76630cbfb924-powerpc64-linux-gnu-debug.tar.gz
2294fc23c170d63fc03085d56ba8653e3cf0cff15c8bd5680faa7b7552e1db07 guix-build-76630cbfb924/output/powerpc64-linux-gnu/bitcoin-76630cbfb924-powerpc64-linux-gnu.tar.gz
7be025478c51a1ba7884a7c2f090a1311651fc218d706051b1830cbc4e82ee4d guix-build-76630cbfb924/output/powerpc64le-linux-gnu/SHA256SUMS.part
30600ad6d9bfe70b68a2a4bedc733b56b26232a45d4491b1a6fa30b76cd3f690 guix-build-76630cbfb924/output/powerpc64le-linux-gnu/bitcoin-76630cbfb924-powerpc64le-linux-gnu-debug.tar.gz
70528805fae16b95d1df46011511ca1c2616fb89422c0164e30d02fa0193b6a1 guix-build-76630cbfb924/output/powerpc64le-linux-gnu/bitcoin-76630cbfb924-powerpc64le-linux-gnu.tar.gz
20f4daaa095803e9c34ed8b119f948e3e61d03b4d5814e4b15ca285c2ba5a109 guix-build-76630cbfb924/output/riscv64-linux-gnu/SHA256SUMS.part
6f969d6b6561ea87d1e54a3a643640da54e4e33d2470dbc607ad27f3a87a0f1d guix-build-76630cbfb924/output/riscv64-linux-gnu/bitcoin-76630cbfb924-riscv64-linux-gnu-debug.tar.gz
7c1e925d199d21781c96e9ee8d63d5eac995cbe2574ccedd81c0938531f694c1 guix-build-76630cbfb924/output/riscv64-linux-gnu/bitcoin-76630cbfb924-riscv64-linux-gnu.tar.gz
d0f13a7a9fcd95669cbab3b637940c2014632405037959989768ec2ffa7fd861 guix-build-76630cbfb924/output/x86_64-apple-darwin18/SHA256SUMS.part
ff23fbdd72fd42140bf11773866061cd5571b66d65bbd769b1345969d195b7ce guix-build-76630cbfb924/output/x86_64-apple-darwin18/bitcoin-76630cbfb924-osx-unsigned.dmg
1b51f4a7611b85d4f599291f42887643ddd59babfc6fb71284793123d8a6be33 guix-build-76630cbfb924/output/x86_64-apple-darwin18/bitcoin-76630cbfb924-osx-unsigned.tar.gz
e0dc9be66c3dc9ba30c5224cf0499ef02b3b7e213081561a6d57d5cc76b3e9a7 guix-build-76630cbfb924/output/x86_64-apple-darwin18/bitcoin-76630cbfb924-osx64.tar.gz
ae3fb0320a0f39dae48354fe74f3d071b16b33920b3b7b27244658439fdfbc93 guix-build-76630cbfb924/output/x86_64-linux-gnu/SHA256SUMS.part
9545ccf26a930a3f876058bb0c4965e1320a354ee2d9ce27d95f8bdd2e8679a6 guix-build-76630cbfb924/output/x86_64-linux-gnu/bitcoin-76630cbfb924-x86_64-linux-gnu-debug.tar.gz
4827206220eaa2b36ebb44b68035c6bda0cec0c2f1b27c08b8349f2f7b3f56d5 guix-build-76630cbfb924/output/x86_64-linux-gnu/bitcoin-76630cbfb924-x86_64-linux-gnu.tar.gz
c2ad3ed62b2ac41a25a43e1c38869a588bf93853cae4502880adf0b66ce30369 guix-build-76630cbfb924/output/x86_64-w64-mingw32/SHA256SUMS.part
a88ee3a0cb715d32cf12cb164d8fe4d9c4c810cc417426f3aacc4e7f08460271 guix-build-76630cbfb924/output/x86_64-w64-mingw32/bitcoin-76630cbfb924-win-unsigned.tar.gz
7673ac8df641d185ea7a150ed27eeee9645168e126d186c6ae935eefdff9edae guix-build-76630cbfb924/output/x86_64-w64-mingw32/bitcoin-76630cbfb924-win64-debug.zip
b90d243d292d1b603d744639e5061917035bd8fba6acd0bb61f10479a200f5aa guix-build-76630cbfb924/output/x86_64-w64-mingw32/bitcoin-76630cbfb924-win64-setup-unsigned.exe
fe69d000da647e0fb7ab19252149be4b45af742223b4c37630200b1d5b43de33 guix-build-76630cbfb924/output/x86_64-w64-mingw32/bitcoin-76630cbfb924-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 76630cbfb9247a78c7760aa8dca62c6b599a0c7c
Tree-SHA512: 6bd1e344f0f37cfb0017fb8b2b0eee41c6a043f23f8ccb2ad1d59e7f2a47f4b84fe431d7d059c409b63263a0af38be955961c4b2ba7b03538f77a0597abb7880
|
|
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.
|
|
This works around an issue when trying to use `std::filesystem::remove_all`
with the ARM GCC on Buster. Has been split out of #20744.
See comments starting here:
https://github.com/bitcoin/bitcoin/pull/20744#issuecomment-810279549.
Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93201.
|
|
|
|
|
|
fa0a5fa744108d81bee9600c80bfda6ca11e5255 ci: Fuzz with -ftrivial-auto-var-init=pattern (MarcoFalke)
Pull request description:
This makes memory bugs deterministic. `-ftrivial-auto-var-init=pattern` is incompatible with other memory sanitizers (like valgrind and msan), but that is irrelevant here, because the address sanitizer in this fuzz CI config is already incompatible with them.
`-ftrivial-auto-var-init=pattern` goes well with `-fsanitize=bool` and `-fsanitize=enum`, but those are already enabled via `-fsanitize=undefined`. See https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks
ACKs for top commit:
practicalswift:
cr ACK fa0a5fa744108d81bee9600c80bfda6ca11e5255
Tree-SHA512: ed6be953cd99eadb1ba245ba30170747eff66be54d2773c8d26a3a6aee0fdcd6967c596f4f4ab1d238de6a6526623dac5211f0ba77f1986639395d7921bdc19f
|
|
|
|
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
|
|
fa001602cd5ac61b9258e998ee2b236688c19ef7 ci: Re-enable verify-commits.py check (MarcoFalke)
fa880b10d67542b8eb476a0e1f3ffb67e88d5e53 ci: Unconditionally set the global git author name in cirrys.yml (MarcoFalke)
Pull request description:
Might be useful to detect bugs in the script itself or an accidentally missed signature.
ACKs for top commit:
josibake:
ACK https://github.com/bitcoin/bitcoin/pull/22744/commits/fa001602cd5ac61b9258e998ee2b236688c19ef7
Zero-1729:
tACK fa001602cd5ac61b9258e998ee2b236688c19ef7
fanquake:
untested ACK fa001602cd5ac61b9258e998ee2b236688c19ef7
Tree-SHA512: 8a13a67d325f2477f4088d1034f0d5e4e04937a01ee3c738435fe66394c02b9f33225529952ad331b0ba19b63ca4b2f26911cb5d264890159840cf3e09085969
|
|
|
|
|
|
b367745cfe19f6de3f44b3adc90fa08e36e44bb6 ci: Make Cirrus CI Windows build with --enable-werror (Hennadii Stepanov)
c713bb2b243881a771ab288340ffeb623c82d7f6 Fix Windows build with --enable-werror on Ubuntu Focal (Hennadii Stepanov)
Pull request description:
This PR makes possible to cross-compile Windows build with `--enable-werror --enable-suppress-external-warnings`.
Some problems are fixed, others are silenced.
Also `--enable-werror` is enabled for Cirrus CI Windows build (the last one on Cirrus CI without `--enable-werror`).
ACKs for top commit:
practicalswift:
cr ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6: patch looks correct
laanwj:
Code review ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6
vasild:
ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6
jarolrod:
ACK b367745cfe19f6de3f44b3adc90fa08e36e44bb6
Tree-SHA512: 64f5c99b7dad4c0efce80cd45d7074f275bd8411235dc9e0841287bdab64b812c6f8f9d632c35531d0b8210148531f53aaaac77be7699b29d2d6aaae304dbee0
|
|
|
|
hkps://hkps.pool.sks-keyservers.net is essentially no-longer functional,
and a number of distributions and GPG tools have since switched to using
this key server as their default.
See this Debian patch for additional context:
https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch
Switch to using keys.openpgp.org in the CI as well.
|