Note that some Rust SIG members have previously been interested in packaging bpftop and have worked towards making all dependencies available.
Not many of them should still be missing or too old in Fedora. Do you have a list of things that's preventing you from building without vendored dependencies? Vendoring is technically only allowed if building without vendored dependencies would incur an unreasonable burden.

Cannot find any valid SRPM URL for this ticket. Common causes are:

- You didn't specify `SRPM URL: ...` in the ticket description
  or any of your comments
- The URL schema isn't HTTP or HTTPS
- The SRPM package linked in your URL doesn't match the package name specified
  in the ticket summary


---
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 reply to Fabio Valentini from comment #1)
> Note that some Rust SIG members have previously been interested in packaging
> bpftop and have worked towards making all dependencies available.
> Not many of them should still be missing or too old in Fedora. Do you have a
> list of things that's preventing you from building without vendored
> dependencies? Vendoring is technically only allowed if building without
> vendored dependencies would incur an unreasonable burden.

Hi Fabio, thanks for letting me know about the bpftop interest from the Rust SIG. These are the crates:

Problem 1: nothing provides requested (crate(libbpf-cargo/default) >= 0.23.1 with crate(libbpf-cargo/default) < 0.24.0~)
Problem 2: nothing provides requested (crate(libbpf-rs/default) >= 0.23.1 with crate(libbpf-rs/default) < 0.24.0~)
Problem 3: nothing provides requested (crate(libbpf-sys/default) >= 1.4.1 with crate(libbpf-sys/default) < 2.0.0~)
Problem 4: nothing provides requested (crate(tracing-journald/default) >= 0.3.0 with crate(tracing-journald/default) < 0.4.0~)
Problem 5: nothing provides requested (crate(tui-input/default) >= 0.8.0 with crate(tui-input/default) < 0.9.0~)

Thanks for checking!

The first three are being worked on as of 1-2 days ago:
https://bugzilla.redhat.com/show_bug.cgi?id=2260404
https://bugzilla.redhat.com/show_bug.cgi?id=2256880
https://bugzilla.redhat.com/show_bug.cgi?id=2272715

That leaves only two missing crates.
At that point, I would strongly prefer if those two missing crates were packaged instead of vendoring dependencies here.

Let me know if you need help with packaging tracing-journald and tui-input.

tui-input: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2282282

tracing-journald: https://bugzilla.redhat.com/show_bug.cgi?id=2282804

Spec URL: https://download.copr.fedorainfracloud.org/results/jfernandez/bpftop/fedora-40-x86_64/07564855-bpftop/bpftop.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/jfernandez/bpftop/fedora-40-x86_64/07564855-bpftop/bpftop-0.5.1-1.fc40.src.rpm

Fabio, the above spec file is no longer using vendored dependencies.

Copr build:
https://copr.fedorainfracloud.org/coprs/build/7565169
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2281565-bpftop/fedora-rawhide-x86_64/07565169-bpftop/fedora-review/review.txt

Please take a look if any issues were found.


---
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.

Officially taking this review.

There are some BuildRequires and Requires that don't look like they are actually necessary:

"""
BuildRequires:  elfutils-libelf-devel
BuildRequires:  zlib-devel
BuildRequires:  clang

Requires:       elfutils-libelf
Requires:       zlib
"""

Is there a specific reason why you added these?

At least the Requires for elfutils-libelf and zlib are unnecessary. Both libraries are dynamically linked, and dependencies on them are generated by RPM automatically.

The BuildRequires on elfutils-libelf-devel, zlib-devel and clang might be leftovers from building with vendored sources? The Packages for Rust crates should already pull in zlib-devel etc. (and clang for bindgen) as needed.

===

Other than that, the package looks good to me!

PS: The spec file you added here: https://github.com/Netflix/bpftop/commit/a737971 is only compatible with recent versions of Fedora and RHEL 9 + EPEL, but will not work for building a package on any other RPM-based linux distribution. So I'm not sure how much benefit there is in keeping it in the upstream github repo.

> There are some BuildRequires and Requires that don't look like they are
> actually necessary:
> 
> """
> BuildRequires:  elfutils-libelf-devel
> BuildRequires:  zlib-devel
> BuildRequires:  clang
> 
> Requires:       elfutils-libelf
> Requires:       zlib
> """
> 
> Is there a specific reason why you added these?

I'm under the impression that libelf and zlib are required at link time to build bpftop because it pulls in libbpf-rs, which compiles libbpf. They are also needed for bpftop to run since it loads a bpf program. From the libbpf docs:
"libelf and zlib are internal dependencies of libbpf and thus are required to link against and must be installed on the system for applications to work." 
https://docs.kernel.org/bpf/libbpf/libbpf_build.html

> 
> At least the Requires for elfutils-libelf and zlib are unnecessary. Both
> libraries are dynamically linked, and dependencies on them are generated by
> RPM automatically.

How does RPM detect that they are dependencies?

> 
> The BuildRequires on elfutils-libelf-devel, zlib-devel and clang might be
> leftovers from building with vendored sources? 
> 

Clang is needed for libbpf-rs to compile the bpf program embedded in bpftop. libbpf-cargo handles the bpf compilation when you run `cargo build`, but it relies on clang.

> The Packages for Rust crates
> should already pull in zlib-devel etc. (and clang for bindgen) as needed.

My assumption is that it would be better to be explicit about the dependencies needed and not to rely on transitive deps from the crates. I assumed that it doesn't hurt. But happy to follow what you think is idea.

> Other than that, the package looks good to me!

Thanks! I will wait to hear back and adjust accordingly.

> 
> PS: The spec file you added here:
> https://github.com/Netflix/bpftop/commit/a737971 is only compatible with
> recent versions of Fedora and RHEL 9 + EPEL, but will not work for building
> a package on any other RPM-based linux distribution. So I'm not sure how
> much benefit there is in keeping it in the upstream github repo.

I can remove it. I wanted to put it there while I iterated on the spec.

(In reply to Jose Fernandez from comment #11)
> > There are some BuildRequires and Requires that don't look like they are
> > actually necessary:
> > 
> > """
> > BuildRequires:  elfutils-libelf-devel
> > BuildRequires:  zlib-devel
> > BuildRequires:  clang
> > 
> > Requires:       elfutils-libelf
> > Requires:       zlib
> > """
> > 
> > Is there a specific reason why you added these?
> 
> I'm under the impression that libelf and zlib are required at link time to
> build bpftop because it pulls in libbpf-rs, which compiles libbpf. They are
> also needed for bpftop to run since it loads a bpf program. From the libbpf
> docs:
> "libelf and zlib are internal dependencies of libbpf and thus are required
> to link against and must be installed on the system for applications to
> work." 
> https://docs.kernel.org/bpf/libbpf/libbpf_build.html

If libbpf already pulls these in, then you don't need to depend on them.

> > 
> > At least the Requires for elfutils-libelf and zlib are unnecessary. Both
> > libraries are dynamically linked, and dependencies on them are generated by
> > RPM automatically.
> 
> How does RPM detect that they are dependencies?

From ELF metadata. The bpftop binary installed by this package links against libz.so.1 and libelf.so.1. RPM reads this metadata from all executable binaries in the package and automatically generates dependencies on packages that provide these libraries. So you should not specify them manually in addition to it, since it is redundant.

> > 
> > The BuildRequires on elfutils-libelf-devel, zlib-devel and clang might be
> > leftovers from building with vendored sources? 
> > 
> 
> Clang is needed for libbpf-rs to compile the bpf program embedded in bpftop.
> libbpf-cargo handles the bpf compilation when you run `cargo build`, but it
> relies on clang.

If you're only using libbpf-cargo here, and libbpf-cargo relies on clang internally, then libbpf-cargo should pull in clang.

> > The Packages for Rust crates
> > should already pull in zlib-devel etc. (and clang for bindgen) as needed.
> 
> My assumption is that it would be better to be explicit about the
> dependencies needed and not to rely on transitive deps from the crates. I
> assumed that it doesn't hurt. But happy to follow what you think is idea.

In general, the rule of thumb is to only explicitly depend on things that you need *directly*.

In this case, the package for libbpf-cargo should probably add a dependency on clang, if it's not working without it?

> > Other than that, the package looks good to me!
> 
> Thanks! I will wait to hear back and adjust accordingly.
> 
> > 
> > PS: The spec file you added here:
> > https://github.com/Netflix/bpftop/commit/a737971 is only compatible with
> > recent versions of Fedora and RHEL 9 + EPEL, but will not work for building
> > a package on any other RPM-based linux distribution. So I'm not sure how
> > much benefit there is in keeping it in the upstream github repo.
> 
> I can remove it. I wanted to put it there while I iterated on the spec.

You don't need to remove it.
I just wanted to let you know that keeping a separate copy of it might be of limited value long-term.

Fabio, thanks for detailed explanation. I removed the Requires/BuildRequires for clang, zlib, and libelf. It compiled fine via mock and in Copr. 

I suspect you are right, I originally needed them when I was using the vendored crates. PTAL:

Spec URL: https://download.copr.fedorainfracloud.org/results/jfernandez/bpftop/fedora-rawhide-x86_64/07709028-bpftop/bpftop.spec
SPRM URL: https://download.copr.fedorainfracloud.org/results/jfernandez/bpftop/fedora-rawhide-x86_64/07709028-bpftop/bpftop-0.5.1-1.fc41.src.rpm

Thank you for the update, looks good to me!

Minor nit-pick: I'm not sure the License tag is valid, but I *am* sure that you could simplify it a little bit.

> (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (BSD-2-Clause) AND (BSD-2-Clause OR Apache-2.0 OR MIT) AND (BSD-3-Clause) AND (BSD-3-Clause OR MIT OR Apache-2.0) AND (LGPL-2.1-only OR BSD-2-Clause) AND (MIT) AND (MIT OR Apache-2.0) AND (MIT OR Zlib OR Apache-2.0)

The AND and OR operators are associative and commutative, so you can drop some parentheses and deduplicate some things (like "Apache-2.0 OR MIT" and "MIT OR Apache-2.0").

The simplified version would look like this:

License:        Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND MIT AND (0BSD OR MIT OR Apache-2.0) AND (Apache-2.0 OR BSL-1.0) AND (Apache-2.0 OR MIT) AND (Apache-2.0 WITH LLVM-exception OR Apache-2.0 OR MIT) AND (BSD-2-Clause OR Apache-2.0 OR MIT) AND (BSD-3-Clause OR MIT OR Apache-2.0) AND (LGPL-2.1-only OR BSD-2-Clause) AND (MIT OR Zlib OR Apache-2.0)

It's not *much* simpler in this case, but in general, this is how I would do it.

========================================

You might want to consider adding "ExcludeArch: %{ix86}" between Source0 and the BuildRequires.
This is a leaf package and an application, so there is not much reason to build it for 32-bit x86.

But TL;DR: Package APPROVED.

========================================

Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed

Issues:
=======
- If your application is a C or C++ application you must list a
  BuildRequires against gcc, gcc-c++ or clang.
  Note: No gcc, gcc-c++ or clang found in BuildRequires
  See: https://docs.fedoraproject.org/en-US/packaging-guidelines/C_and_C++/

  This looks like a false positive.

===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package does not contain any libtool archives (.la)
[x]: Package contains no static executables.
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: License field in the package spec file matches the actual license.
[x]: License file installed when any subpackage combination is installed.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
[x]: If (and only if) the source package includes the text of the
     license(s) in its own file, then that file, containing the text of the
     license(s) for the package is included in %license.
[x]: The License field must be a valid SPDX expression.
[x]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package must not depend on deprecated() packages.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package does not use a name that already exists.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 2951 bytes in 1 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
[x]: Spec file according to URL is the same as in SRPM.

Rpmlint
-------
Checking: bpftop-0.5.1-1.fc41.x86_64.rpm
          bpftop-debuginfo-0.5.1-1.fc41.x86_64.rpm
          bpftop-debugsource-0.5.1-1.fc41.x86_64.rpm
          bpftop-0.5.1-1.fc41.src.rpm
============================ rpmlint session starts ============================
rpmlint: 2.5.0
configuration:
    /usr/lib/python3.12/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
rpmlintrc: [PosixPath('/tmp/tmpn5jewybq')]
checks: 32, packages: 4

bpftop.src: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
bpftop.src: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
bpftop.x86_64: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
bpftop.x86_64: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
bpftop.x86_64: W: no-manual-page-for-binary bpftop
 4 packages and 0 specfiles checked; 4 errors, 1 warnings, 16 filtered, 4 badness; has taken 0.5 s 

Rpmlint (debuginfo)
-------------------
Checking: bpftop-debuginfo-0.5.1-1.fc41.x86_64.rpm
============================ rpmlint session starts ============================
rpmlint: 2.5.0
configuration:
    /usr/lib/python3.12/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
rpmlintrc: [PosixPath('/tmp/tmp3o8250k4')]
checks: 32, packages: 1

 1 packages and 0 specfiles checked; 0 errors, 0 warnings, 5 filtered, 0 badness; has taken 0.2 s 

Rpmlint (installed packages)
----------------------------
============================ rpmlint session starts ============================
rpmlint: 2.5.0
configuration:
    /usr/lib/python3.13/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
checks: 32, packages: 3

bpftop.x86_64: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
bpftop.x86_64: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
bpftop.x86_64: W: no-manual-page-for-binary bpftop
 3 packages and 0 specfiles checked; 2 errors, 1 warnings, 13 filtered, 2 badness; has taken 0.3 s 

Source checksums
----------------
https://github.com/Netflix/bpftop/archive/refs/tags/v0.5.1.tar.gz :
  CHECKSUM(SHA256) this package     : 8457caf5ededba38aad01ed6317bd737a8079bbb26ca9a79cfdca5848a8c80f6
  CHECKSUM(SHA256) upstream package : 8457caf5ededba38aad01ed6317bd737a8079bbb26ca9a79cfdca5848a8c80f6

Requires
--------
bpftop (rpmlib, GLIBC filtered):
    ld-linux-x86-64.so.2()(64bit)
    libc.so.6()(64bit)
    libelf.so.1()(64bit)
    libelf.so.1(ELFUTILS_1.0)(64bit)
    libelf.so.1(ELFUTILS_1.3)(64bit)
    libelf.so.1(ELFUTILS_1.5)(64bit)
    libelf.so.1(ELFUTILS_1.6)(64bit)
    libgcc_s.so.1()(64bit)
    libgcc_s.so.1(GCC_3.0)(64bit)
    libgcc_s.so.1(GCC_3.3)(64bit)
    libgcc_s.so.1(GCC_4.2.0)(64bit)
    libm.so.6()(64bit)
    libz.so.1()(64bit)
    libz.so.1(ZLIB_1.2.3.3)(64bit)
    rtld(GNU_HASH)

bpftop-debuginfo (rpmlib, GLIBC filtered):

bpftop-debugsource (rpmlib, GLIBC filtered):

Provides
--------
bpftop:
    bpftop
    bpftop(x86-64)

bpftop-debuginfo:
    bpftop-debuginfo
    bpftop-debuginfo(x86-64)
    debuginfo(build-id)

bpftop-debugsource:
    bpftop-debugsource
    bpftop-debugsource(x86-64)

The Pagure repository was created at https://src.fedoraproject.org/rpms/bpftop

FEDORA-2024-34fced7285 (bpftop-0.5.1-1.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-34fced7285

FEDORA-2024-34fced7285 (bpftop-0.5.1-1.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

Fabio, I just wanted the close the loop. I applied your license and ExcludeArch suggestions in the final spec. Thank you for all your patience and guidance through this process.