| Age | Commit message (Collapse) | Author |
|---|
|
This currently points to the version-1.4.0 branch.
|
|
than generating
e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6 build: use a static .tiff for macOS .dmg over generating (fanquake)
Pull request description:
For demonstration, after [discussion in #23778](https://github.com/bitcoin/bitcoin/pull/23778#issuecomment-1003005503), and the question as to why we can't just have a `background.tiff` that we copy into the macOS DMG, and do away with the somewhat convoluted image generation steps.
From my understanding, the only reason we have this image generation as part of our build system is so that forks of Core can adapt the imagery for their own branding via `PACKAGE_NAME`. It don't think it provides much value to us, and could just have a static .tiff that we copy into the dmg (replacing the .svg that currently lives in macdeploy/).
Doing this would eliminate the following build dependencies:
For native macOS:
* `sed` (usage in Makefile.am)
* `librsvg` (rsvg-convert)
* `tiffutil`
Linux macOS cross-compile:
* `sed` (usage in Makefille.am)
* `librsvg`
* `tiffcp`
* `convert` (imagemagick)
* `font-tuffy`
Guix Build:
```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
c98d67796863f4b1bab0ad600d46bd74e744d94072cbd4bc856a6aeaba3bb329 guix-build-e09773d20a92/output/dist-archive/bitcoin-e09773d20a92.tar.gz
3336f90bab312798cb7665e2b4ae24d1a270fb240647d5fed8dbfcd83e3ed37e guix-build-e09773d20a92/output/x86_64-apple-darwin/SHA256SUMS.part
8fd680c7ee158c64bad212385df7b0b302c6c2143d4e672b4b0eb5da41f9256d guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.dmg
34f54177c2f0700e8cfaf5d85d91e404807cd9d411e22006cdff82653e5f4af2 guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.tar.gz
da6b8f54ef755d40330c8eac4f5bd0329637e827be9ee61318600d5d0bdcc3dc guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx64.tar.gz
```
ACKs for top commit:
hebasto:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
jarolrod:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
Zero-1729:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
Tree-SHA512: 0ad06699a5451daa8cfaaa46759eb7bd85254a72e23f857f70d433a2ffb1a4bf6dd464d9c4ac9f8c20aab045f4e2b61c6dcdcbcceef96ce515b1a0c501665b1f
|
|
This paves the way for using and checking for architecture dependent
flags like -fcf-protection on x86_64 Linux and -mbranch-protection on 64
bit ARM.
|
|
|
|
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
|
|
-BEGIN VERIFY SCRIPT-
./contrib/devtools/copyright_header.py insert contrib/guix/libexec/build.sh
./contrib/devtools/copyright_header.py insert contrib/guix/libexec/codesign.sh
./contrib/devtools/copyright_header.py insert contrib/tracing/log_raw_p2p_msgs.py
./contrib/devtools/copyright_header.py insert contrib/tracing/log_utxocache_flush.py
./contrib/devtools/copyright_header.py insert contrib/tracing/p2p_monitor.py
./contrib/devtools/copyright_header.py insert test/lint/lint-files.sh
-END VERIFY SCRIPT-
|
|
-BEGIN VERIFY SCRIPT-
./contrib/devtools/copyright_header.py update ./
-END VERIFY SCRIPT-
Commits of previous years:
* 2020: fa0074e2d82928016a43ca408717154a1c70a4db
* 2019: aaaaad6ac95b402fe18d019d67897ced6b316ee0
|
|
This change prevents updating copyright years from "2021" to
"2021-2017".
|
|
33b511251acbd0ed802a8843361c7dc8d1512008 contrib: add achow101 to trusted keys (Andrew Chow)
Pull request description:
For maintaining the wallet and psbt things
ACKs for top commit:
glozow:
concept ACK 33b511251acbd0ed802a8843361c7dc8d1512008
michaelfolkson:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
kiminuo:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
jb55:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
gruve-p:
ACK https://github.com/bitcoin/bitcoin/pull/23798/commits/33b511251acbd0ed802a8843361c7dc8d1512008
prayank23:
ACK https://github.com/bitcoin/bitcoin/pull/23798/commits/33b511251acbd0ed802a8843361c7dc8d1512008
meshcollider:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
darosior:
Concept ACK 33b511251acbd0ed802a8843361c7dc8d1512008
shaavan:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
benthecarman:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
hebasto:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
Zero-1729:
ACK 33b511251acbd0ed802a8843361c7dc8d1512008
Tree-SHA512: 2e242b5f763a3d9fab00413760973a41a41c78f327f4a8f7bed788d6dd9f31043a644ff5f612ff033f8a3c7b4e9936737475fec67536935257053a9f6a3fb9bb
|
|
|
|
|
|
For maintaining the wallet and psbt things
|
|
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
|
|
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
|
|
|
|
|
|
|
|
`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
|
|
|
|
Signed-off-by: Arnab Sen <arnabsen1729@gmail.com>
|
|
Signed-off-by: Arnab Sen <arnabsen1729@gmail.com>
|
|
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.
```
|
|
-BEGIN VERIFY SCRIPT-
sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19')
-END VERIFY SCRIPT-
|
|
|
|
|
|
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
|
|
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
|
|
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
|
|
|
|
|
|
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
|
|
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.
|
|
|
|
`--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
|
|
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.
|
|
Achieve this by adding some ignore, and making data/ importable.
Co-authored-by: João Barbosa <joao.paulo.barbosa@gmail.com>
|
|
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.
|
|
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
|
|
|
|
|
|
|
|
|
|
Co-authored-by: Carl Dong <contact@carldong.me>
|
|
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...
|
|
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>
|
|
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.
|
|
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
|
|
|
|
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.
|
|
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
|
