Spec URL: https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10140745/rust-ptools.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10140745/rust-ptools-0.2.2-1.src.rpm Description: Utilities for inspecting Linux processes Fedora Account System Username: basilcrow
Copr build: https://copr.fedorainfracloud.org/coprs/build/10140774 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2440297-ptools/fedora-rawhide-x86_64/10140774-rust-ptools/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.
Fixing the review bug title to match the package name.
Thanks for fixing that, Ben. I'd actually like the package to be named "ptools", since it is a user-facing CLI, the same way the "clippy" package is named "clippy" and not "rust-clippy". I think this would help users find it, since they don't care about the implementation details of it being implemented in Rust. However, the packaging tool I used to convert the crate into a Fedora package specification named it "rust-ptools." I'm not sure what the Rust packaging experts would recommend here.
(In reply to Basil Crow from comment #3) > Thanks for fixing that, Ben. I'd actually like the package to be named > "ptools", since it is a user-facing CLI, the same way the "clippy" package > is named "clippy" and not "rust-clippy". I think this would help users find > it, since they don't care about the implementation details of it being > implemented in Rust. However, the packaging tool I used to convert the crate > into a Fedora package specification named it "rust-ptools." I'm not sure > what the Rust packaging experts would recommend here. Remember the distinction between source and binary package names. If you plan to continue to package this from the crates.io source and maintain it using rust2rpm, then you must keep the *source* package named as rust-ptools, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_package_naming, but note that the *binary* package in your submission is named ptools, so this is the package name that users will see: "dnf install ptools" will already work. Since you sensibly chose not to package the crate library, which doesn’t appear designed for external use, you have the *option* to package from the GitHub source archives instead of the crates.io crates, in which case ptools would be the more appropriate source package name, https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_non_crate_rust_projects. Note that you won’t be able to use rust2rpm if you go this route. Several new releases have appeared in the past few days. When you update to 0.2.9, which also includes pauxv, pflags, prun, psig, pstop, and pwait executables, you will need to figure out how to avoid conflict with the pflags executable from python3-linux-procfs; see https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/. Since the names of the commands are so short and simple, you will need to continue to check carefully for conflicts as upstream implements more tools. The other thing I noticed is that there is a test that fails on s390x, our sole big-endian architecture: https://koji.fedoraproject.org/koji/taskinfo?taskID=142545286. Indeed, this is clearly an endianness bug: running 1 test test test::test_parse_ipv4_sock_addr ... FAILED failures: ---- test::test_parse_ipv4_sock_addr stdout ---- thread 'test::test_parse_ipv4_sock_addr' (878) panicked at src/bin/pfiles.rs:608:9: assertion `left == right` failed left: 1.0.0.127:5432 right: 127.0.0.1:5432 Ideally you could work with upstream to get this fixed.
Thanks Ben for teaching me about the distinction between source and binary package names. I am fine keeping the source package named rust-ptools, and the binary package named ptools. "dnf install ptools" will work which is what I care about. I want to use rust2rpm, so I don't want to package from the GitHub source archives. I have updated to 0.2.11, which includes some new utilities and man pages (now packaged as well). I also think I have fixed the test failure on s390x. As stated in the README at https://github.com/basil/ptools I am deliberately not trying to compete with popular tools like pgrep, pkill, pldd, and pwdx which are part of many Fedora system already as part of procps-ng or glibc. pflags is an outlier, being only distributed as part of python3-linux-procfs and used by tuna and tuned. This doesn't seem as widely used, so I am fine conflicting with it. I have added an explicit Conflicts: line to the package. I have tested the result and all is working. If you could take another look I would be grateful.
https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10155534/rust-ptools.spec https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10155534/rust-ptools-0.2.11-1.src.rpm
(In reply to Basil Crow from comment #5) > Thanks Ben for teaching me about the distinction between source and binary > package names. I am fine keeping the source package named rust-ptools, and > the binary package named ptools. "dnf install ptools" will work which is > what I care about. I want to use rust2rpm, so I don't want to package from > the GitHub source archives. > > I have updated to 0.2.11, which includes some new utilities and man pages > (now packaged as well). I also think I have fixed the test failure on s390x. > As stated in the README at https://github.com/basil/ptools I am deliberately > not trying to compete with popular tools like pgrep, pkill, pldd, and pwdx > which are part of many Fedora system already as part of procps-ng or glibc. > pflags is an outlier, being only distributed as part of python3-linux-procfs > and used by tuna and tuned. This doesn't seem as widely used, so I am fine > conflicting with it. I have added an explicit Conflicts: line to the package. Per https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_incompatible_binary_files_with_conflicting_naming_and_stubborn_upstreams, you’re supposed to try to work with both upstreams. Now, one upstream is the kernel, so I doubt renaming is on the table, and the other upstream appears to be you, and you’re reproducing a historical set of tools, so you can’t rename pflags and maintain “API” compatibility. If you’re going to add explicit Conflicts, though, we need to work with the maintainer of the other package to add it there as well, and I think we’re going to have to do some work to minimize the scope of the conflict. $ repoquery --whatrequires python3-linux-procfs Last metadata expiration check: 0:05:49 ago on Sat 21 Feb 2026 08:39:36 GMT. tuna-0:0.19-13.fc43.noarch tuned-0:2.26.0-2.fc43.noarch tuned-0:2.27.0-0.1.rc1.fc43.noarch Since tuned requires python3-linux-procfs, and tuned is the default power profile management daemon in at least Fedora Workstation and KDE Plasma, if your package conflicts with python3-linux-procfs then it won’t be installable on most Fedora installations. I think the right course of action will be to start a dialogue with the maintainers of the python-linux-procfs package in Fedora about what to do. Here are some possible suggestions: If nothing in Fedora uses the “pflags” executable from python3-linux-procfs, maybe we can just stop shipping it (beginning with F44 if the change is made before Final Freeze, or F45 otherwise, because removing a binary is a breaking change for stable releases). Then there will be no conflict. If nothing in Fedora uses the “pflags” executable from python3-linux-procfs but the maintainers still want to ship it, maybe they would consider renaming it downstream (python-pflags, maybe)? This should also be avoided in stable releases, but would fix the conflict going forward. If the maintainers of the python-linux-procfs don’t want to drop or rename the “pflags” executable, then you should ask them to at least move it to its own subpackage, maybe something like “python-linux-procfs-tools,” that depends on python3-linux-procfs. Then the Conflicts can be added to the subpackage containing the executable, greatly narrowing the scope of the problem, and thereby allowing your package to be parallel-installed with tuned.
Copr build: https://copr.fedorainfracloud.org/coprs/build/10157007 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2440297-rust-ptools/fedora-rawhide-x86_64/10157007-rust-ptools/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.
Thanks again Ben for pointing out that tuned is the default power profile management daemon in Fedora Workstation and KDE Plasma. I had misjudged the prevalence of this package because I personally use Fedora LXQt where it is not installed and where the more lightweight lxqt-powermanagement is used instead. I also see that the maintainer of python-linux-procfs is the kernel at https://git.kernel.org/pub/scm/libs/python/python-linux-procfs/python-linux-procfs.git so per my own policy I don't want to compete with them. I've dropped pflags from my project and created a new build of ptools that explicitly recommends the existing glibc-common, procps-ng, and python3-linux-procfs packages, without any conflicts. If you could please take another look, I think we should be in a good state now. https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10157016/rust-ptools.spec https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10157016/rust-ptools-0.2.11-1.src.rpm
There seems to be some problem with the following file. SRPM URL: https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10157016/rust-ptools-0.2.11-1.src.rpm Fetching it results in a 404 Not Found error. Please make sure the URL is correct and publicly available. --- 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.
Correct links: https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10157016/rust-ptools.spec https://download.copr.fedorainfracloud.org/results/basilcrow/rust-ptools/srpm-builds/10157016/rust-ptools-0.2.13-1.src.rpm
Created attachment 2130458 [details] The .spec file difference from Copr build 10157007 to 10157038
Copr build: https://copr.fedorainfracloud.org/coprs/build/10157038 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2440297-rust-ptools/fedora-rawhide-x86_64/10157038-rust-ptools/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.
Thank you for bringing this useful set of tools to Fedora! The package is APPROVED, provided that you address the build failure on i686 when you import it; see the recommendation below. Feel free to contact me or join the “Fedora Rust” room on Matrix (https://chat.fedoraproject.org/#/room/#rust:fedoraproject.org) if you have questions in the future. === Recommended post-import rust-sig tasks: - set up package on release-monitoring.org: project: $crate homepage: https://crates.io/crates/$crate backend: crates.io version scheme: semantic version filter (*NOT* pre-release filter): alpha;beta;rc;pre distro: Fedora Package: rust-$crate - add @rust-sig with "commit" access as package co-maintainer (should happen automatically) - set bugzilla assignee overrides to @rust-sig (optional) - track package in koschei for all built branches (should happen automatically once rust-sig is co-maintainer) Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated ===== Issues ===== - The package fails to build on i686: https://kojipkgs.fedoraproject.org//work/tasks/2417/142602417/build.log There are several errors of the form: error[E0308]: mismatched types --> src/lib.rs:133:6 | 133 | (libc::AT_BASE, "AT_BASE"), | ^^^^^^^^^^^^^ expected `u64`, found `u32` For Rust crate libraries, we find that it’s helpful if we can avoid ExcludeArch when possible because it propagates through (large, ever-changing) dependency chains. For an application package like this, it’s reasonable (and even mildly desirable) to simply not build an i686 package: # https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval ExcludeArch: %{ix86} You’re welcome to fix the problem upstream if you *want* to support 32-bit platforms, but there’s no need to do it for Fedora’s sake. ===== Notes (no change required for approval) ==== - You might consider adding a spec-file comment above the weak dependencies on glib-common, procps-ng, and python3-linux-procfs explaining their purpose. It’s otherwise pretty hard for a reader of the spec file to discern why they are there and (in the future) whether they are still needed. - If you aren’t already using rust2rpm.toml to represent all or nearly all of your spec-file customization, consider it. Let me know if there’s something you can’t figure out how to make it handle. It can’t replace all hand-editing, but I think it should be able to deal with everything but the license expression in your spec file. - Since the binary names are short and generic, there is a relatively high risk of conflict as you implement more tools. You can check new tools something like this: * sudo dnf install fedora-repos-rawhide * repoquery --repo=rawhide --whatprovides '*bin/pfoo' * If this gives a result, check the actual path (repoquery --repo=rawhide -l $other_packag_ename | grep pfoo) to determine if a bona fide conflict exists. Your use of short and generic names is well-justified in context, considering you are reproducing a historical set of tools. ===== MUST items ===== 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", "Apache License 2.0". 34 files have unknown license. Detailed output of licensecheck in /home/ben/fedora/review/20260221/2440297-rust- ptools/licensecheck.txt [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. [-]: 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. $ for bin in p{args,auxv,cred,env,files,run,sig,stop,tree} > do > printf '==> %s\n' "${bin}" > repoquery --repo=rawhide --whatprovides "*bin/${bin}" 2>/dev/null > done --> pargs --> pauxv --> pcred --> penv --> pfiles --> prun prrte-0:3.0.6-9.fc44.x86_64 --> psig --> pstop --> ptree $ repoquery --repo=rawhide -l prrte 2>/dev/null | grep prun /usr/lib64/openmpi/bin/prun /usr/lib64/openmpi/share/man/man1/prun.1 This was a close one! But the prrte spec file has already moved its executables into %{_ilibdir}/openmpi/bin/ to avoid a conflict with putty, which also provides a “pterm” executable. See: https://src.fedoraproject.org/rpms/prrte/c/f56d6b82348e122458763e6eb4f68ad4b8821235?branch=rawhide So this is OK, and doesn’t constitute a 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. Weak dependencies should preferably be explained in a spec-file comment. [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. [!]: Package is not known to require an ExcludeArch tag. Package requires ExcludeArch: %{ix86} [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: No rpmlint messages. [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 8858 bytes in 2 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). [x]: Package functions as described. Tests pass. Manual “smoke tests” seem OK: <mock-chroot> sh-5.3# pargs $PPID 1: (sd-stubinit) argv[0]: (sd-stubinit) <mock-chroot> sh-5.3# pauxv $PPID 1: (sd-stubinit) AT_SYSINFO_EHDR 0x00007ff6cb881000 […] AT_RSEQ_ALIGN 0x0000000000000020 <mock-chroot> sh-5.3# pcred $PPID 1: e/r/suid=0(root) e/r/sgid=0(root) <mock-chroot> sh-5.3# penv $PPID 1: (sd-stubinit) envp[0]: container=systemd-nspawn envp[1]: container_uuid=48f30bdca3aa49b3890b724bf0a63aad <mock-chroot> sh-5.3# pfiles $PPID 1: (sd-stubinit) Current soft rlimit: 1024 file descriptors Current hard rlimit: 524288 file descriptors Current umask: 022 0: S_IFCHR mode:0600 dev:0,163 ino:3 uid:0 gid:5 rdev:136,0 O_RDWR /dev/pts/0 offset: 0 1: S_IFCHR mode:0600 dev:0,163 ino:3 uid:0 gid:5 rdev:136,0 O_RDWR /dev/pts/0 offset: 0 2: S_IFCHR mode:0600 dev:0,163 ino:3 uid:0 gid:5 rdev:136,0 O_RDWR /dev/pts/0 offset: 0 <mock-chroot> sh-5.3# sh -c 'for i in $(seq 1 10); do echo "$i"; sleep 10; done' & [1] 80 <mock-chroot> sh-5.3# 1 2 pstop 80 [1]+ Stopped(SIGSTOP) sh -c 'for i in $(seq 1 10); do echo "$i"; sleep 10; done' <mock-chroot> sh-5.3# prun 80 3 <mock-chroot> sh-5.3# 4 5 6 fg sh -c 'for i in $(seq 1 10); do echo "$i"; sleep 10; done' ^C <mock-chroot> sh-5.3# psig $PPID 1: (sd-stubinit) HUP default blocked INT default […] RTMIN+29 default blocked RTMAX default blocked <mock-chroot> sh-5.3# ptree $PPID 1 (sd-stubinit) 2 /bin/sh -i -l 93 ptree 1 <mock-chroot> sh-5.3# ptree root 1 (sd-stubinit) 2 /bin/sh -i -l 96 ptree root 2 /bin/sh -i -l 96 ptree root 2 /bin/sh -i -l 96 ptree root <mock-chroot> sh-5.3# sleep 5 & [1] 100 <mock-chroot> sh-5.3# pwait 100 [1]+ Done sleep 5 [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. Note: gpgverify is not used. [!]: Package should compile and build into binary rpms on all supported architectures. Package requires ExcludeArch: %{ix86} [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: [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [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: ptools-0.2.13-1.fc45.x86_64.rpm rust-ptools-0.2.13-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/tmpz3po18ab')] checks: 32, packages: 2 2 packages and 0 specfiles checked; 0 errors, 0 warnings, 7 filtered, 0 badness; has taken 0.4 s Rpmlint (installed packages) ---------------------------- ============================ 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 checks: 32, packages: 1 1 packages and 0 specfiles checked; 0 errors, 0 warnings, 3 filtered, 0 badness; has taken 0.4 s Source checksums ---------------- https://crates.io/api/v1/crates/ptools/0.2.13/download#/ptools-0.2.13.crate : CHECKSUM(SHA256) this package : 3500ac24334e603234f6ec3e2a2c3d50430090f80ee87167f8568892a57e8223 CHECKSUM(SHA256) upstream package : 3500ac24334e603234f6ec3e2a2c3d50430090f80ee87167f8568892a57e8223 Requires -------- ptools (rpmlib, GLIBC filtered): libc.so.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) rtld(GNU_HASH) Provides -------- ptools: ptools ptools(x86-64) Generated by fedora-review 0.11.0 (05c5b26) last change: 2025-11-29 Command line :/usr/bin/fedora-review -b 2440297 Buildroot used: fedora-rawhide-x86_64 Active plugins: Generic, Shell-api Disabled plugins: R, Haskell, C/C++, Perl, Python, SugarActivity, PHP, Java, fonts, Ocaml Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH
The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-ptools
FEDORA-2026-1f71dd90ab (rust-ptools-0.2.13-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1f71dd90ab
FEDORA-2026-1f71dd90ab (rust-ptools-0.2.13-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-d7087d1281 (rust-ptools-0.2.13-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-d7087d1281
Thanks very much Ben, I really appreciate your time getting this package reviewed. I will keep an eye out for any future conflicts and reach out if I have trouble resolving them.