This works around package install errors, such as https://github.com/bitcoin/bitcoin/runs/23354020361. Should be possible to reproduce locally via apt update && apt install bpfcc-tools on noble:
0 python3-bpfcc : Depends: libbpfcc (>= 0.29.1+ds-1ubuntu4) but it is not going to be installed
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | hebasto, TheCharlatan |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
Any idea when it could be re-enabled?
I guess, the package issue should be resolved by the Ubuntu 24.04 release date (this month).
It seems unwise to have CI that runs for every PR to be dependent on an unstable OS. From what I can tell, the purpose of using Ubuntu noble is to get access to clang 18. Instead of doing that, could we instead use the LTS release and just use the llvm package repo to get the clang versions we want?
I agree, but that is not possible, because the bpfcc-tools on the Ubuntu 22.04 LTS were outdated as well. So they’d require a ppa as well, see #27510.
I am not sure if two third-party PPAs are more stable than a vanilla Ubuntu, but I won’t object a pull request that implements the changes. (I won’t be working on this myself).
If someone implements this, it may also be good to move the runner to a GHA 22.04 VM, to lift the requirements from the self-hosted runners. (But I won’t be working on this myself either)
Personally I think it is fine to disable the bpf tests for a few days, or even weeks, as the code is unlikely to break. Even if it were to break, and people didn’t run the tests locally, and missed it, it should not be too hard to fix them after the temporary disable.
I’m missing context for this change. Why no PR description and no commit message body?
I put it in the second comment. Edited and moved to the description.
Personally I think it is fine to disable the bpf tests for a few days, or even weeks, as the code is unlikely to break.
To be on the very safe side, maybe open an issue to undo it and tag that for v28.0.
If someone implements this, it may also be good to move the runner to a GHA 22.04 VM, to lift the requirements from the self-hosted runners. (But I won’t be working on this myself either)
Obviously this would expose the CI to GH changing the kernel below the CI without notice, e.g. https://github.com/bitcoin-core/secp256k1/commit/05bfab69aef3622f77f754cfb01220108a109c91 . So it may or may not be more or less fragile.
I agree that the CI task is fragile, because it assumes an exact kernel to be known and available, but I honestly don’t know which alternative is less fragile. Suggestions are more than welcome.
I’m missing context for this change. Why no PR description and no commit message body?
I put it in the second comment. Edited and moved to the description.
Ok, I did a bit more digging: I was missing the context that ~https://github.com/bitcoin/bitcoin/pull/29765 upgraded the CI images to a newer Ubuntu version and that the Cirrus CI / ASan + LSan + UBSan + integer, no depends, USDT job is now failing.~ (edit: only the i686 job was upgraded in #29786).
Is it an option to drop the USDT tests from the Cirrus CI / ASan + LSan + UBSan + integer, no depends, USDT job and move them to a GH actions 23.04 VM if “lifting the requirements from the self-hosted runners” is the general direction we want to go? (probably makes sense to merge this sooner than later before adding a GH actions VM job to have CI green again?).
Is it an option to drop the USDT tests from the
Cirrus CI / ASan + LSan + UBSan + integer, no depends, USDTjob and move them to a GH actions 23.04 VM if “lifting the requirements from the self-hosted runners” is the general direction we want to go? (probably makes sense to merge this sooner than later before adding a GH actions VM job to have CI green again?).
I’ll look into it.
Ok, I did a bit more digging: I was missing the context that #29765 upgraded the CI images to a newer Ubuntu version and that the
Cirrus CI / ASan + LSan + UBSan + integer, no depends, USDTjob is now failing.
29765 didn’t do the switch, it was done in fa83b65ef8934b44fbac02da8dbc27fc0bc230e6 last year.
Is it an option to drop the USDT tests from the
Cirrus CI / ASan + LSan + UBSan + integer, no depends, USDTjob and move them to a GH actions 23.04 VM if “lifting the requirements from the self-hosted runners” is the general direction we want to go? (probably makes sense to merge this sooner than later before adding a GH actions VM job to have CI green again?).
23.04 does not exist. Only ubuntu-22.04, no?
Again, I am not sure what the best solution is, but if someone wants to propose something else and receive the git blame, I am all-in.
GH actions 23.04 VM
GitHub currently only supports: ubuntu-latest (22.04), ubuntu-22.04, and ubuntu-20.04
I am happy to close this pull, if people don’t want it.
However, I don’t see why running the CI not at all is better than skipping just the bpfcc part.
I think merging this temporarily is fine. I think the relevant upstream issue is https://bugs.launchpad.net/ubuntu/+source/bpfcc/+bug/2052813 ? I’m assuming this is going to be resolved soon. Note that the installation issues only seem to be with x86_64? Running apt update && apt install bpfcc-tools on noble, on an aarch64 machine, currently works. I thought that might be because it doesn’t seem to depend on libbpfcc 0.29.1+ds-1ubuntu4, but that is also currently available/installable:
0# cat /etc/lsb-release
1DISTRIB_ID=Ubuntu
2DISTRIB_RELEASE=24.04
3DISTRIB_CODENAME=noble
4DISTRIB_DESCRIPTION="Ubuntu Noble Numbat (development branch)"
5# apt install libbpfcc
6libbpfcc is already the newest version (0.29.1+ds-1ubuntu4).
7# apt install bpfcc-tools
8bpfcc-tools is already the newest version (0.29.1+ds-1ubuntu4).