Bug 2437525 - Review Request: rust-rbpf - Rust (user-space) virtual machine for eBPF
Summary: Review Request: rust-rbpf - Rust (user-space) virtual machine for eBPF
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-02-07 19:38 UTC by Ignacio Espósito
Modified: 2026-06-22 20:45 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:
dmellado: needinfo-


Attachments (Terms of Use)
Spec File (2.88 KB, text/plain)
2026-02-07 19:38 UTC, Ignacio Espósito
no flags Details
Metadata Fix (1.07 KB, patch)
2026-02-07 19:38 UTC, Ignacio Espósito
no flags Details | Diff
Scratch Build (119.99 KB, application/x-rpm)
2026-02-07 19:38 UTC, Ignacio Espósito
no flags Details

Description Ignacio Espósito 2026-02-07 19:38:00 UTC
Created attachment 2128569 [details]
Spec File

Copr Build: https://copr.fedorainfracloud.org/coprs/qrow01/rbpf/builds/

Description:
This crate contains a virtual machine for eBPF program execution. BPF, as in Berkeley Packet Filter, is an assembly-like language initially developed for BSD systems, in order to filter packets in the kernel with tools such as tcpdump so as to avoid useless copies to user-space. It was ported to Linux, where it evolved into eBPF (extended BPF), a faster version with more features. While BPF programs are originally intended to run in the kernel, the virtual machine of this crate enables running it in user-space applications; it contains an interpreter, an x86_64 JIT-compiler for eBPF programs, as well as a disassembler.

Comment 1 Ignacio Espósito 2026-02-07 19:38:22 UTC
Created attachment 2128570 [details]
Metadata Fix

Comment 2 Ignacio Espósito 2026-02-07 19:38:45 UTC
Created attachment 2128571 [details]
Scratch Build

Comment 3 Fedora Review Service 2026-02-08 18:28:15 UTC
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.

Comment 4 Fedora Review Service 2026-02-08 18:28:17 UTC
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.

Comment 5 Ben Beasley 2026-02-13 13:34:18 UTC
Please submit your work in the form:

Spec URL: https://….spec
SRPM URL: https://….src.rpm

It’s tedious to piece together the necessary inputs from an idiosyncratic mix of attachments and COPR links.

These will work for now, but COPR will eventually garbage-collect them and the links will stop working.

Spec URL: https://download.copr.fedorainfracloud.org/results/qrow01/rbpf/fedora-43-x86_64/10089473-rust-rbpf/rust-rbpf.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/qrow01/rbpf/fedora-43-x86_64/10089473-rust-rbpf/rust-rbpf-0.4.0-1.fc43.src.rpm

Consider Fedora People, https://fedoraproject.org/wiki/Infrastructure/fedorapeople.org, as a more durable place to upload package submissions.

Comment 6 Ben Beasley 2026-02-13 13:34:52 UTC
Correcting the review title to match the package name: rust-rbpf rather than just rbpf.

Comment 7 Ben Beasley 2026-02-13 13:37:32 UTC
You’ll need to patch out the cranelift feature, because it has missing dependencies (cranelift itself). All subpackages need to be installable. You might be able to get away with using features.hide in rust2rpm.toml; see the man page for rust2rpm.toml for details and cautions.

Comment 8 Daniel Mellado 2026-02-16 11:48:25 UTC
Spec URL: https://dmellado.fedorapeople.org/rbpf/rust-rbpf.spec                                                        
SRPM URL: https://dmellado.fedorapeople.org/rbpf/rust-rbpf-0.4.1-1.fc45.src.rpm                                        
                                                                                                                                         
Description: Rust (user-space) virtual machine for eBPF                                                                
                                                                                                                       
FEdora Account System Username: dmellado

Comment 9 Daniel Mellado 2026-03-11 16:29:33 UTC
Spec URL: https://dmellado.fedorapeople.org/rbpf/rust-rbpf.spec                                                        
SRPM URL: https://dmellado.fedorapeople.org/rbpf/rust-rbpf-0.4.1-1.fc45.src.rpm                                        
                                                                                                                                         
Description: Rust (user-space) virtual machine for eBPF                                                                
                                                                                                                       
Fedora Account System Username: dmellado

Comment 10 Daniel Mellado 2026-03-11 16:30:28 UTC
[fedora-review-service-build]

Comment 11 Ben Beasley 2026-06-22 20:45:53 UTC
I am intentionally not assigning this review to myself at this time, because I am not certain I will have time to revisit it.

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

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

Notes:
=======
- It looks like you used rust2rpm.toml to “hide” the cranelift feature,
  something like:

    [features]
    hide = [
        "cranelift",
    ]

  This is sensible, since cranelift is not packaged.

  None of the caveats in the rust2rpm.toml man page apply here:

      NOTE: Care needs to be taken to only "hide" features / optional
      dependencies that are not dependencies of other "non-hidden" features,
      otherwise the subpackages for the dependent features will have
      unsatisfiable dependencies. All features that are marked as "hidden" by
      this setting must be "unreachable" via feature dependencies from any
      feature subpackages that are still present in the generated spec file. In
      some circumstances, the only way to cleanly handle removal of unused
      non-default features is to patch Cargo.toml instead.

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++/

  OK: the only C source file is examples/load_elf__block_a_port.c, and it’s
  impractical to run the example working from source, without the pre-compiled
  object file, as described in the comments in examples/load_elf.rs. You
  therefore won’t need a C or C++ compiler. Everything else is Rust.

- Package does not contain duplicates in %files.
  Note: warning: File listed twice:
  /usr/share/cargo/registry/rbpf-0.4.1/LICENSE-APACHE
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/#_duplicate_files

  OK: not a serious problem; due to reasonable rust2rpm design decisions.

- The metadata patch disables all of the examples and removes many of the
  dev-dependencies. This may be the right thing to do, but please document why
  you can’t or shouldn’t run the examples. You can use something like the
  following in rust2rpm.toml:

    [package]
    cargo-toml-patch-comments = [
        """\
	Omit all examples, and dev-dependencies required only for the examples, because \
	lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor \
	incididunt ut labore et dolore magna aliqua.\
	""",
    ]

- The file examples/load_elf__block_a_port.o is a pre-compiled ELF binary. You
  must remove this in %prep to prove it is not used when building the package.

  https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries

  You can use something like this in rust2rpm.toml:

    [scripts.prep]
    pre = [
        "# Prove pre-compiled ELF object file(s) in the examples is not used:",
	"rm --verbose examples/*.o",
    ]

  I am a little torn about this, because there is no theoretical difference
  between the pre-compiled bytecode carried in this object file and the
  pre-compiled bytecode (some presumably hand-crafted, some documented as LLVM
  output) written out in hex form as byte strings in the various doctests. One
  is stored in a separate file, and one is inline, but they are both
  pre-compiled binary blobs. A strict reading of the guidelines might suggest
  that the doctests should be stripped out as well, a fairly impractical
  endeavor.

  I am inclined to suggest that as long as the inline bytecode is in the
  doctests, that should provide a reasonable barrier to its actually being
  somehow included in an application, and some flexibility is reasonable given
  that this is a JIT and it operates on bytecode.
  
  I still think that omitting the .o file is the right thing to do, though,
  firstly because it *looks* much more suspicious, and secondly because it’s
  more straightforward for “somthing, somewhere” to link a .o file that’s just
  sitting there in the installed examples than to pull hex strings out of
  rustdoc comments.

- Some tests are omitted, and this is well-documented:

    # Skip doctests that fail in mock environment:
    # - JIT tests segfault (permission/environment issue)
    # - One doctest requires dev-dependency 'elf'
    %cargo_test -- --lib --bins

  However, the elf crate is packaged,
  https://src.fedoraproject.org/rpms/rust-elf, and it’s even at the version the
  dev-dependency asks for. Perhaps these doctests can be run after all?

  I tried this rust2rpm.toml:

    [[package.extra-patches]]
    number = 10
    file = "rbpf-0.4.1-omit-some-jit-doctests.patch"
    comments = [
        """\
    Downstream-only: omit some JIT doctests that would fail (terminated by signal).\
    """,
    ]
    
    [features]
    hide = ["cranelift"]
    
    [scripts.prep]
    pre = [
        "# Prove pre-compiled ELF object file(s) in the examples is not used:",
        "rm --verbose examples/*.o",
    ]

  and this rbpf-0.4.1-omit-some-jit-doctests.patch:

    diff -Naur rbpf-0.4.1-original/src/lib.rs rbpf-0.4.1/src/lib.rs
    --- rbpf-0.4.1-original/src/lib.rs	2006-07-24 02:21:28.000000000 +0100
    +++ rbpf-0.4.1/src/lib.rs	2026-06-22 11:14:09.629966095 +0100
    @@ -299,7 +299,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// use rbpf::lib::{Error, ErrorKind};
         /// use rbpf::ebpf;
         /// use core::any::Any;
    @@ -339,7 +339,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// let prog = &[
         ///     0xb7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // mov r0, 0
         ///     0x95, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00  // exit
    @@ -410,7 +410,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// use std::ptr::addr_of;
         ///
         /// struct MapValue {
    @@ -550,7 +550,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// let prog = &[
         ///     0x79, 0x11, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, // Load mem from mbuff into r1.
         ///     0x69, 0x10, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, // ldhx r1[2], r0
    @@ -1179,7 +1179,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// let prog = &[
         ///     0xb7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // mov r0, 0
         ///     0x79, 0x12, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, // load mem from r1[0x40] to r2
    @@ -1697,7 +1697,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// let prog = &[
         ///     0x71, 0x11, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, // ldxb r1[0x04], r1
         ///     0x07, 0x01, 0x00, 0x00, 0x00, 0x22, 0x00, 0x00, // add r1, 0x22
    @@ -2113,7 +2113,7 @@
         ///
         /// # Examples
         ///
    -    /// ```
    +    /// ```ignore
         /// let prog = &[
         ///     0xb7, 0x00, 0x00, 0x00, 0x11, 0x22, 0x00, 0x00, // mov r0, 0x2211
         ///     0xdc, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, 0x00, // be16 r0

  but I ended up with three failures in doctests that I had already attempted to ignore:

    failures:
    
    ---- src/lib.rs - (line 410) stdout ----
    Test executable failed (exit status: 101).
    
    stderr:
    
    thread 'main' (1104) panicked at /tmp/rustdoctestTlBe0j/doctest_bundle_2024.rs:392:41:
    Could not read file: Os { code: 2, kind: NotFound, message: "No such file or directory" }
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    
    
    ---- src/lib.rs - (line 344) stdout ----
    Test executable failed (terminated by signal).
    
    ---- src/lib.rs - (line 308) stdout ----
    Test executable failed (terminated by signal).
    
    
    failures:
        src/lib.rs - (line 308)
        src/lib.rs - (line 344)
        src/lib.rs - (line 410)
    
    test result: FAILED. 53 passed; 3 failed; 11 ignored; 0 measured; 0 filtered out; finished in 0.06s

  This is really mystifying. I’ve never seen this happen before.  Perhaps you
  can make more progress. It would be nice to run those doctests that are OK!
  Or, perhaps we’ll have to give up on the doctests for now anyway. In that
  case, something like this should run as many non-doc tests as possible:

    [tests]
    run = [
        "lib",
        "test:assembler",
        "test:common",
        # Requires cranelift to actually work, but skips gracefully without it
        "test:cranelift",
        "test:disassembler",
        # Segfaults on non-x86_64 architecture; TODO: why?
        # "test:misc",
        # Segfaults; TODO: why?
        # "test:ubpf_jit_x86_64",
        "test:ubpf_verifier",
        "test:ubpf_vm",
    ]
    comments = [
        "Cannot run doctests because …",
    ]

  Furthermore, the above turns up some s390x-specific test failures that are
  probably little-endian assumptions.

    failures:
    ---- test_vm_be16_high stdout ----
    thread 'test_vm_be16_high' (667) panicked at tests/ubpf_vm.rs:320:5:
    assertion `left == right` failed
      left: 30600
     right: 4386
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    ---- test_vm_be32_high stdout ----
    thread 'test_vm_be32_high' (669) panicked at tests/ubpf_vm.rs:350:5:
    assertion `left == right` failed
      left: 1432778632
     right: 287454020
    ---- test_vm_ldxdw stdout ----
    thread 'test_vm_ldxdw' (736) panicked at tests/ubpf_vm.rs:1796:5:
    assertion `left == right` failed
      left: 1234605616436508552
     right: 9833440827789222417
    ---- test_vm_ldxh stdout ----
    thread 'test_vm_ldxh' (737) panicked at tests/ubpf_vm.rs:1916:5:
    assertion `left == right` failed
      left: 4386
     right: 8721
    ---- test_vm_ldxw stdout ----
    thread 'test_vm_ldxw' (741) panicked at tests/ubpf_vm.rs:1996:5:
    assertion `left == right` failed
      left: 287454020
     right: 1144201745
    ---- test_vm_subnet stdout ----
    thread 'test_vm_subnet' (791) panicked at tests/ubpf_vm.rs:2772:5:
    assertion `left == right` failed
      left: 0
     right: 1
    ---- test_vm_tcp_port80_match stdout ----
    thread 'test_vm_tcp_port80_match' (792) panicked at tests/ubpf_vm.rs:2818:5:
    assertion `left == right` failed
      left: 0
     right: 1
    ---- test_vm_tcp_sack_match stdout ----
    thread 'test_vm_tcp_sack_match' (796) panicked at tests/ubpf_vm.rs:2895:5:
    assertion `left == right` failed
      left: 0
     right: 1
    failures:
        test_vm_be16_high
        test_vm_be32_high
        test_vm_ldxdw
        test_vm_ldxh
        test_vm_ldxw
        test_vm_subnet
        test_vm_tcp_port80_match
        test_vm_tcp_sack_match
    test result: FAILED. 137 passed; 8 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.01s
    error: test failed, to rerun pass `--test ubpf_vm`
    error: 1 target failed:
        `--test ubpf_vm`

  I’m guessing the defects are in test assumptions rather than in the library
  itself, but I haven’t investigated.

===== 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.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "Unknown or generated", "*No copyright* Apache License 2.0",
     "MIT License". 34 files have unknown license. Detailed output of
     licensecheck in /home/ben/fedora/review/2437525-rust-
     rbpf/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[-]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries or specifies bundled libraries
     with Provides: bundled(<libname>) if unbundling is not possible.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.

     Pre-compiled .o file should be removed in %prep; bytecode in docstrings
     discussed above.

[-]: Package contains desktop file if it is a GUI application.
[x]: 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.
[x]: Package contains systemd file(s) if in need.
[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.
     Note: There are rpmlint messages (see attachment).
[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]: 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 0 bytes in 0 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).
[-]: Fully versioned dependency in subpackages if applicable.
     Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in rust-
     rbpf-devel , rust-rbpf+default-devel , rust-rbpf+std-devel
[x]: Package functions as described.

     Most of the tests can be executed, and pass.

[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[!]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.

     It’s not clear why the examples can’t be tested. See Issues.

[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[x]: Package should compile and build into binary rpms on all supported
     architectures.

     As submitted, yes; but if we enable non-lib tests, then we start to see
     some architecture-specific segfaults and some s390x-specific failures. See
     discussion in Issues.

[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]: 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:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)

     OK: differences are solely due to rpmautospec macro expansion.

[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).


Rpmlint
-------
Checking: rust-rbpf-devel-0.4.1-1.fc45.noarch.rpm
          rust-rbpf+default-devel-0.4.1-1.fc45.noarch.rpm
          rust-rbpf+std-devel-0.4.1-1.fc45.noarch.rpm
          rust-rbpf-0.4.1-1.fc45.src.rpm
============================ rpmlint session starts ============================
rpmlint: 2.8.0
configuration:
    /usr/lib/python3.14/site-packages/rpmlint/configdefaults.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/tmpjl9wjc95')]
checks: 32, packages: 4

rust-rbpf+default-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf+default-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
rust-rbpf+std-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf+std-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
rust-rbpf.src: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf.src: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
rust-rbpf-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
 4 packages and 0 specfiles checked; 8 errors, 0 warnings, 19 filtered, 8 badness; has taken 0.2 s 




Rpmlint (installed packages)
----------------------------
============================ rpmlint session starts ============================
rpmlint: 2.9.0
configuration:
    /usr/lib/python3.15/site-packages/rpmlint/configdefaults.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

rust-rbpf-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
rust-rbpf+default-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf+default-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
rust-rbpf+std-devel.noarch: E: spelling-error ('eBPF', 'Summary(en_US) eBPF -> Feb')
rust-rbpf+std-devel.noarch: E: spelling-error ('eBPF', '%description -l en_US eBPF -> Feb')
 3 packages and 0 specfiles checked; 6 errors, 0 warnings, 15 filtered, 6 badness; has taken 0.1 s 



Source checksums
----------------
https://crates.io/api/v1/crates/rbpf/0.4.1/download#/rbpf-0.4.1.crate :
  CHECKSUM(SHA256) this package     : 0c7fd1b4fdf96615efe17cfd01307737988fd17ece498e36f34d30e98726027d
  CHECKSUM(SHA256) upstream package : 0c7fd1b4fdf96615efe17cfd01307737988fd17ece498e36f34d30e98726027d


Requires
--------
rust-rbpf-devel (rpmlib, GLIBC filtered):
    (crate(byteorder) >= 1.5.0 with crate(byteorder) < 2.0.0~)
    (crate(combine) >= 4.6.0 with crate(combine) < 5.0.0~)
    (crate(hashbrown) >= 0.16.0 with crate(hashbrown) < 0.17.0~)
    (crate(hashbrown/default-hasher) >= 0.16.0 with crate(hashbrown/default-hasher) < 0.17.0~)
    (crate(log) >= 0.4.0 with crate(log) < 0.5.0~)
    cargo

rust-rbpf+default-devel (rpmlib, GLIBC filtered):
    cargo
    crate(rbpf)
    crate(rbpf/std)

rust-rbpf+std-devel (rpmlib, GLIBC filtered):
    (crate(combine/std) >= 4.6.0 with crate(combine/std) < 5.0.0~)
    (crate(libc/default) >= 0.2.0 with crate(libc/default) < 0.3.0~)
    cargo
    crate(rbpf)



Provides
--------
rust-rbpf-devel:
    crate(rbpf)
    rust-rbpf-devel

rust-rbpf+default-devel:
    crate(rbpf/default)
    rust-rbpf+default-devel

rust-rbpf+std-devel:
    crate(rbpf/std)
    rust-rbpf+std-devel



Diff spec file in url and in SRPM
---------------------------------
--- /home/ben/fedora/review/2437525-rust-rbpf/srpm/rust-rbpf.spec	2026-06-17 11:06:22.036273416 +0100
+++ /home/ben/fedora/review/2437525-rust-rbpf/srpm-unpacked/rust-rbpf.spec	2026-02-16 00:00:00.000000000 +0000
@@ -1,2 +1,12 @@
+## START: Set by rpmautospec
+## (rpmautospec version 0.8.3)
+## RPMAUTOSPEC: autorelease, autochangelog
+%define autorelease(e:s:pb:n) %{?-p:0.}%{lua:
+    release_number = 1;
+    base_release_number = tonumber(rpm.expand("%{?-b*}%{!?-b:1}"));
+    print(release_number + base_release_number - 1);
+}%{?-e:.%{-e*}}%{?-s:.%{-s*}}%{!?-n:%{?dist}}
+## END: Set by rpmautospec
+
 # Generated by rust2rpm 28
 %bcond check 1
@@ -85,3 +95,6 @@
 
 %changelog
-%autochangelog
+## START: Generated by rpmautospec
+* Mon Feb 16 2026 John Doe <packager> - 0.4.1-1
+- Uncommitted changes
+## END: Generated by rpmautospec


Generated by fedora-review 0.11.0 (05c5b26) last change: 2025-11-29
Command line :/usr/bin/fedora-review -b 2437525
Buildroot used: fedora-rawhide-x86_64
Active plugins: Shell-api, C/C++, Generic
Disabled plugins: Haskell, PHP, R, fonts, Python, SugarActivity, Ocaml, Java, Perl
Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH


Note You need to log in before you can comment on or make changes to this bug.