fa4d6c76b6dc249d02c926ad75725556614fdddd ci/cirrus: Add native ARM64 persistent workers (MarcoFalke)
2262d0eaab2aa1181f900acd2d8cd568047599b6 ci/cirrus: Bring back skeleton .cirrus.yml without jobs (Tim Ruffing)
Pull request description:
ACKs for top commit:
real-or-random:
ACK fa4d6c76b6dc249d02c926ad75725556614fdddd
hebasto:
re-ACK fa4d6c76b6dc249d02c926ad75725556614fdddd, only last two commits have been squashed since my recent [review](https://github.com/bitcoin-core/secp256k1/pull/1426#pullrequestreview-1636119941).
Tree-SHA512: d1fee99d54a41a4126f7eb72695a56137c925dc9ce7cd692a60ea1262ac0789bbd6aa4e4dfc030f0d97d06aeeae0724a5f2d794a85ff533c6cf3cd215f6a4b7a
c45b7c4fbbf41b011f138c465a58322a36664fd3 refactor: introduce testutil.h (deduplicate `random_fe_`, `ge_equals_` helpers) (Sebastian Falbesoner)
dc5514144fb9d412aa3845432b053ee06a27da37 tests: simplify `random_fe_non_zero` (remove loop limit and unneeded normalize) (Sebastian Falbesoner)
Pull request description:
`random_fe_non_zero` contains a loop iteration limit that ensures that we abort if `random_fe` ever yielded zero more than ten times in a row. This construct was first introduced in PR #19 (commit 09ca4f32) for random non-square field elements and was later refactored into the non-zero helper in PR #25 (commit 6d6102fe). The copy-over to the exhaustive tests happened recently in PR #1118 (commit 0f864207).
This case seems to be practically irrelevant and I'd argue for keeping things simple and removing it (which was already suggested in https://github.com/bitcoin-core/secp256k1/pull/1118#discussion_r1067259954); if there's really a worry that the test's random generator is heavily biased towards certain values or value ranges then there should consequently be checks at other places too (e.g. directly in `random_fe` for 256-bit values that repeatedly overflow, i.e. >= p).
Also, the _fe_normalize call is not needed and can be removed, as the result of `random_fe` is already normalized.
ACKs for top commit:
real-or-random:
utACK c45b7c4fbbf41b011f138c465a58322a36664fd3
siv2r:
ACK `c45b7c4` (reviewed the changes and tests for both the commits passed locally).
Tree-SHA512: 4ffa66dd0b8392d7d0083a71e7b0682ad18f9261fd4ce8548c3059b497d3462db97e16114fded9787661ca447a877a27f5b996bd7d47e6f91c4454079d28a8ac
421d84855aeb9324b4f131c3e6c7ee8cf4f5f4e5 ci: Align Autotools/CMake `CI_INSTALL` directory names (Hennadii Stepanov)
9f005c60d6067d94279a3e3e81ec178bf4e2f227 cmake: Install `libsecp256k1.pc` file (Hennadii Stepanov)
Pull request description:
This PR allows downstream projects to use pkg-config to search for the libsecp256k1 library that is built with CMake.
Addressed https://github.com/bitcoin-core/secp256k1/discussions/1419#discussioncomment-6922896:
> We could just ship the pkg-config file also in CMake builds.
ACKs for top commit:
real-or-random:
ACK 421d84855a I compared the generated pc files and they match in autotools and CMake
Tree-SHA512: 8e54eb7c76bc727ab18715258c06cc2a419c6c04892a2bd7bfe34392f9a3223f673ff84d2d21b00b3c222b357f02296ec49c872532d98ea0a2f17ef1ed6b6ac1
9b118bc7fb12203e9bf98eb23bfdd5746adde2b3 release cleanup: bump version after 0.4.0 (Jonas Nick)
Pull request description:
based on #1415
ACKs for top commit:
sipa:
ACK 9b118bc7fb12203e9bf98eb23bfdd5746adde2b3
hebasto:
ACK 9b118bc7fb12203e9bf98eb23bfdd5746adde2b3
real-or-random:
ACK 9b118bc7fb12203e9bf98eb23bfdd5746adde2b3
Tree-SHA512: 76df87c41bdc3379df4e88619645f5110010d7713ebe20bad3e7c99472bd62b90f4bd3c6b558ad5a23119acc4734e39383d96a9800e4a43dfadc086ef66fd0ab
This commit also explicitly initializes shortpubkey. For some reason, removing
surrounding, unrelated lines results in gcc warnings when configured with
--enable-ctime-tests=no --with-valgrind=no.
8659a01714c1b4fcd349ee1a7d733f6934c5d184 ci: Add `release` job (Hennadii Stepanov)
f9b38894baee6b726217e28a4d4591ffdf233e47 ci: Update `actions/checkout` version (Hennadii Stepanov)
Pull request description:
This PR introduces a new "Release" job that conducts sanity checks as defined in [`doc/release-process.md`](https://github.com/bitcoin-core/secp256k1/blob/master/doc/release-process.md#sanity-checks).
ACKs for top commit:
sipa:
ACK 8659a01714c1b4fcd349ee1a7d733f6934c5d184
real-or-random:
ACK 8659a01714c1b4fcd349ee1a7d733f6934c5d184
Tree-SHA512: 84e03fa07f8c41aec0f6d1ccb4ac3643e85d370ef7e388b335365deadb555f2d9ef7e5d80e1255a18e790a774e04ca66f265b9441402b183d4c535a97688f20f
2635068abf93ebcf7f200eef14acafc3300e32f7 ci/gha: Let MSan continue checking after errors in all jobs (Tim Ruffing)
e78c7b68eb7e91cf9b88408c053867f148d62ffa ci/Dockerfile: Reduce size of Docker image further (Tim Ruffing)
2f0d3bbffb288621f4232c90424f77d44cc69166 ci/Dockerfile: Warn if `ulimit -n` is too high when running Docker (Tim Ruffing)
4b8a647ad3a59c2421d1d4c6e653f21d453e2612 ci/gha: Add ARM64 QEMU jobs for clang and clang-snapshot (Tim Ruffing)
6ebe7d2bb39978e70d85a718919d4af31cc00bc2 ci/Dockerfile: Always use versioned clang packages (Tim Ruffing)
Pull request description:
Solves one item in https://github.com/bitcoin-core/secp256k1/issues/1392.
This PR also has a few tweaks to the Dockerfile, see individual commits.
---
I'll follow up soon with a PR for ARM64/gcc. This will rely on Cirrus CI.
ACKs for top commit:
hebasto:
ACK 2635068abf93ebcf7f200eef14acafc3300e32f7.
Tree-SHA512: d290bdd8e8e2a2a2b6ccb1b25ecdc9662c51dab745068a98044b9abed75232d13cb9d2ddc2c63c908dcff6a12317f0c7a35db3288c57bc3b814793f7fce059fd
The underlying issue does not affect our CI hosts, but is an issue on my
development machine (Arch Linux). In particular, this affects the vanilla
configuration of Docker on systemd, which has effectively no limit:
11400a3f5a/pkg/docker-engine/common/systemd/docker.service (L31)
I hope this saves future generations some precious hours of their life.
This commit switches to a new strategy to make sure we're installing the
most recent LLVM packages. Before this commit, we used the unversioned
LLVM packages (e.g., `clang` instead of `clang-18`), which are supposed
to provide the latest snapshot, but this is broken for arm64 [1],
which we want to add in a later PR.
Anyway, the new approach is cleaner because it does not require us to
fiddle with the installed `clang` package by removing a symlink.
[1] https://github.com/llvm/llvm-project/issues/64790
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
cce045630407e662c90279abb2b0e71161f24e74 ci: Make repetitive command the default one (Hennadii Stepanov)
317a4c48f058755019475de79896230dadc6474c ci: Move `git config ...` to `run-in-docker-action` (Hennadii Stepanov)
Pull request description:
This PR addresses the https://github.com/bitcoin-core/secp256k1/pull/1409#discussion_r1301767281:
> couldn't we add this to `run-in-docker-action` to avoid duplication?
ACKs for top commit:
real-or-random:
ACK cce045630407e662c90279abb2b0e71161f24e74
Tree-SHA512: 793cec3d99853a23e06680fe35a7cae2dc8771f22e3940c4a4f36357273164f2d92e196768118d146e956ffca9ef59d4e5f86e1cba5576ebfdc59343581c9924
676ed8f9cf001ebaadf53d5c11e32f7a6b1e5649 ci: Move "C++ (public headers)" from Cirrus to GitHub Actions (Hennadii Stepanov)
61fc3a2dc883a5ffda43658337ec94d3306eb77f ci: Move "C++ -fpermissive..." from Cirrus to GitHub Actions (Hennadii Stepanov)
d51fb0a533e5ae34b216527ea32281ff498310dc ci: Move "MSan" from Cirrus to GitHub Actions (Hennadii Stepanov)
c22ac27529003e828d8a873ca6439f6978e2e1be ci: Move sanitizers task from Cirrus to GitHub Actions (Hennadii Stepanov)
Pull request description:
This PR concludes the migration from Cirrus CI to GitHub Actions.
ACKs for top commit:
real-or-random:
ACK 676ed8f9cf001ebaadf53d5c11e32f7a6b1e5649
Tree-SHA512: d8ea91a20297ff4c2c11a02c0a52f19413fde442c71e2e8b660737c09d62e55e4ae3f9bdbdeb0d967f6720a3dffa1566b7f94e0e32bcd490ac052819d5427c84
ee1be62d84bf6d81e0ed574ef98e980d61a19227 ci: Use concurrency for pull requests only (Hennadii Stepanov)
Pull request description:
This PR is an amendment for https://github.com/bitcoin-core/secp256k1/pull/1403.
It avoids skipping builds when some pushes were done consequentially.
From GitHub Actions [docs](https://docs.github.com/en/actions/using-jobs/using-concurrency):
> When a concurrent ... workflow is queued, if another ... workflow using the same concurrency group in the repository is in progress, the queued ... workflow will be pending. **Any previously pending ... workflow in the concurrency group will be canceled.**
No behavior change for pull requests.
Same as https://github.com/bitcoin/bitcoin/pull/28322.
ACKs for top commit:
real-or-random:
ACK ee1be62d84bf6d81e0ed574ef98e980d61a19227
Tree-SHA512: ce26378c3224a7647eb3b351d19e9308650ad49b933a68d37a0eca8516767a63f55580a33b02864caa539392c9aab0b4b54ecbace85bea6082bf533539a37c9c
