Debian 8 (Jessie) has:
- g++ version 4.9.2
- libc version 2.19
Ubuntu 16.04.4 (Xenial) has:
- g++ version 5.3.1
- libc version 2.23.0
CentOS 7 has:
- g++ version 4.8.5
- libc version 2.17
Taking the minimum of these as our target.
According to the GNU ABI document this corresponds to:
- GCC 4.8.5: GCC_4.8.0
- (glibc) GLIBC_2_17
Co-Authored-By: fanquake <fanquake@gmail.com>
Flagged by flake8 v3.6.0, as W605, plus a few others identified
incidentally, e.g. 59ffecf66cf4d08c4b431e457b083878d66a3fd6.
Note that r"\n" matches to "\n" under re.match/search.
1ac454a384 Enable ShellCheck rules (Hennadii Stepanov)
Pull request description:
Enable some simple ShellCheck rules.
Note for reviewers: `bash` and `shellcheck` on macOS are different from ones on Ubuntu.
For local tests the latest `shellcheck` version 0.6.0 should be used (see #15166).
ACKs for top commit:
practicalswift:
utACK 1ac454a384
dongcarl:
utACK 1ac454a
fanquake:
ACK 1ac454a384
Tree-SHA512: 8d0a3a5c09fe1a0c22120178f5e6b80f81f746f8c3356b7701ff301c117acb2edea8fe08f08fb54ed73f94b1617515fb239fa28e7ab4121f74872e6494b6f20e
0e01e4522e devtools: Fetch and display ACKs at sign-off time in github-merge (Wladimir J. van der Laan)
Pull request description:
- Fetch the ACKs only at sign-off time. This makes sure that any last-minute ACKs are included (fixes#16200)
- Show a list of ACKs that will be included and their author before signing off, and warn if there are none


There's a slight change to the merge commit format—before it was
```
ACKs for commit 88884c:
(list of ACKs, could be empty)
```
now it is
```
ACKs for top commit:
jnewbery:
ACK 5ebc6b0eb
... (list of ACKs cannot be empty)
```
or
```
Top commit has no ACKs.
```
I don't think there's a reason to have the abbreviated commit ID there, after all the full commit id is already in the beginning of the merge commit message, and at least the abbreviated one is in every single ACK message.
ACKs for commit 0e01e4:
fanquake:
ACK 0e01e4522e
Tree-SHA512: 8576de016137d71cfc101747e9bb6779c13e0953cf2babee7afc9972bf2bd46f6912be4982b54fa5abf4d91e98e8fdae6b4ca3eef7d6892b7a5f04a7017b6882
- Fetch the ACKs only at sign-off time. This makes sure that any
last-minute ACKs are included (fixes#16200)
- Show a list of ACKs and their author before signing off, and warn if
there are none
b748bf6f50 Fix spelling errors identified by codespell 1.15.0 (Ben Woosley)
Pull request description:
Note all changes are to comments / documentation.
After this commit, the only remaining output is:
```
$ test/lint/lint-spelling.sh
src/test/base32_tests.cpp:14: fo ==> of, for
src/test/base64_tests.cpp:14: fo ==> of, for
^ Warning: codespell identified likely spelling errors. Any false positives? Add them to the list of ignored words in test/lint/lint-spelling.ignore-words.txt
```
Note:
* I ignore several valid alternative spellings ~, but changed homogenous
to homogeneous as the latter is a more specific term according to the
Google dictionary definitions I found~
* homogenous is present in tinyformat, hence should be addressed upstream
* process' is correct only if there are plural processes
ACKs for commit b748bf:
practicalswift:
ACK b748bf6f50
fanquake:
ACK https://github.com/bitcoin/bitcoin/pull/16186/commits/b748bf6f50dda6bb57eadf697edc320b2695e01a
Tree-SHA512: 9add7044643ce015e0a44d8b27a3f300d72c485ffff550fb6491a17f14528085289ec5caddfe02f291ea9b2cded38a0dd3079652a054e2d7fe2ff4f7b53db5d7
067fba563 devtools: Always use unabbreviated commit IDs in github-merge.py (Wladimir J. van der Laan)
Pull request description:
Always put the unabbreviated commit IDs in the generated commit messages and other places. This prevents the developer's `core.abbrev` git setting from leaking through and is better against ambiguity too.
ACKs for commit 067fba:
MarcoFalke:
ACK 067fba5631 (replaces `h` with `H`, didn't test)
promag:
ACK 067fba5631, from the documentation https://git-scm.com/docs/pretty-formats:
fanquake:
ACK https://github.com/bitcoin/bitcoin/pull/16201/commits/067fba56314f399674dd471c663e663040be52a3. Tested by merging this PR into master, then merging a second PR ontop and checking that full commit hashes were being used. Also checked documentation linked to above. Did not check that this works when a different `core.abbrev` is set locally.
Tree-SHA512: a851d10490cd8bcd8bca29094b08a6b9f883cfe1b0767ccda7ca789e4c8eff6260a4d82c33cb3d9bab01dd30ac8c9100cb7adbcb1911bb399d9385c1e1f15ecd
Always put the unabbreviated commit IDs in the generated commit messages
and other places. This prevents the developer's `core.abbrev` git setting
from leaking through and is better against ambiguity too.