Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: I apologize in advance if this is not the correct way to request packages. Currently, bpftrace pulls in quite a few large dependencies, such as clang and llvm. While our production environments don't have those dependencies, we would still like to use bpftrace. There is upstream support for static builds - In the official bpftrace repository, there is a .github/include/static.sh file that orchestrates the static build using Docker containers: https://github.com/bpftrace/bpftrace/blob/master/.github/include/static.sh Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The ticket summary is not in the correct format. Expected: Review Request: <main package name here> - <short summary here> Found: Package Request: bpftrace-static As a consequence, the package name cannot be parsed and submitted to be automatically build. Please modify the ticket summary and trigger a build by typing [fedora-review-service-build]. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
In this case the ticket should be opened against the existing bpftrace package, as static versions of packages are typically built as subpackages of the main package in Fedora. I have reassigned the ticket to the right component, so that the maintainers can consider it.
The bpftrace upstream provides statically linked binaries as release artifacts, for example for the latest 0.26.1 release: https://github.com/bpftrace/bpftrace/releases/download/v0.26.1/bpftrace Technically, these are AppImage files, but they should be executable on any modern Linux distro (including Fedora) without additional dependencies. They are built with Nix so should be 100% reproducible, which means that if we packaged them to Fedora, we would end up with exactly the same binary as the one provided upstream. In such a case, you can as well download from upstream. Note: the mentioned .github/include/static.sh script is mostly for testing static build in the CI. The produced binary wouldn't work on Fedora since it's built on Alpine Linux and uses musl libc (instead of glibc).
On the static.sh point, that is correct - I considered making a correction, but I figured this request would be too niche to even be looked at :) You're right about the release being static - I should have verified that using ldd instead of assuming it would be dynamic. Many thanks!
You're welcome :) I believe we can close this ticket now.
Not to dwell on this too much, but I think there's some value-add in just packaging it as an rpm and providing it through EPEL. I would probably have to do this manually anyway, since we have a pretty heavy rpm-centric build system and workflow, so it would be nice if this was provided as an alternative package.