Description of problem: dnsperf-queryparse from EPEL 10.1 has one or more unresolved dependencies, causing it to be uninstallable. Version-Release number of selected component (if applicable): dnsperf-queryparse-2.14.0-1.el10_1 How reproducible: always Steps to Reproduce: 1. dnf install dnsperf-queryparse Actual results: Error: Problem: conflicting requests - nothing provides python3-pcapy needed by dnsperf-queryparse-2.14.0-1.el10_1.noarch from epel Expected results: successful installation Additional info: If the solution to this is to add additional packages to EPEL 10, but you don't have access to add them yourself, follow the request process in the EPEL documentation. Once you have filed the corresponding bugs, mark them as blocking this bug. https://docs.fedoraproject.org/en-US/epel/epel-package-request/ To avoid having the uninstallable packages present in the repos, I have untagged the relevant build so it will not be included in future composes. The epel10 branch has not been retired, so as soon as the dependencies are available you can re-publish the package by creating a new build and update.
This problem has been repeated with dnsperf-2.14.0-1.el10_2. I have untagged that build also. Please do not submit further updates to add this package until all the dependencies are available.
Oh, okay. I were unaware that problem exists, I do not use it often. That needs some tests executed in PR to ensure it stops happens.
A test to run it in %check would be ideal, but in the mean time you could add a buildrequires on python3-pcapy to ensure the build fails if it's missing.
Why was whole dnsperf unlisted from epel repository, when dnsperf-queryparse is a separate subpackage and only that requires python3-pcapy missing in epel10? It seems unnecessary hard way to fix the problem with subpackage only. Okay, disabling queryparse subpackage for now makes sense. Yeah, there should be some check. There is no pcap file in source archive to test it on, but at least --version or --help start should ensure basic dependencies are present.
FEDORA-2026-07caef9555 (dnsperf-2.14.0-3.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-07caef9555
FEDORA-2026-07caef9555 (dnsperf-2.14.0-3.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2026-bf55bec3f4 (dnsperf-2.14.0-3.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-bf55bec3f4
Could you please tag dnsperf back into epel10? broken subpackage has fix scheduled, but it does not prevent usage of dnsperf in EPEL10. I have few RHEL10 tests relying on dnsperf presence, none of them needs queryparse too.
FEDORA-EPEL-2026-bf55bec3f4 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-bf55bec3f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
> Why was whole dnsperf unlisted from epel repository, when dnsperf-queryparse is a separate subpackage and only that requires python3-pcapy missing in epel10? Because the only remedy to remove the uninstallable package is to untag the build in koji, which removes all the packages from that build. For the builds I untagged, the corresponding bodhi updates had failed automated tests that indicated the problem (fedora-ci.koji-build.installability.functional). I have requested that bodhi disable autopush for updates with failed automated tests, but until/unless that happens please check that tab in the bodhi interface before the update moves to stable. https://github.com/fedora-infra/bodhi/issues/5856 > Could you please tag dnsperf back into epel10? No, because dnsperf-2.14.0-1.el10_2 still has the uninstallable subpackage and we shouldn't put that back in the repo. Getting dnsperf-2.14.0-3.el10_2 (which passed the automated installability test) promoted to stable sooner via karma is the preferred route. > I have few RHEL10 tests relying on dnsperf presence, none of them needs queryparse too. It's a bit odd for a package removal in EPEL to affect RHEL testing. That sounds like a good candidate for moving to CRB.
I do not see any problem with having complete package in epel and require them in some RHEL tests. I have not seen any package, which would be completely in CRB. CRB could not be modified by anyone outside Red Hat, which is not what I want. I do not understand how is it better to remove completely package from whole repository, when the only problem with it was minor subpackage problem. Now it cannot be installed at all and with absolutely no functionality.
> I do not see any problem with having complete package in epel and require them in some RHEL tests. You just described the problem in comment 8. The removal of an EPEL package shouldn't affect RHEL testing. > I have not seen any package, which would be completely in CRB. Some examples: aspell, cppunit, doxygen, help2man, javacc, ksc, libdbusmenu, meson, ocaml > CRB could not be modified by anyone outside Red Hat, which is not what I want. Sure they can, the sources would be in https://gitlab.com/redhat/centos-stream/rpms and contributors can send pull requests. > I do not understand how is it better to remove completely package from whole repository, when the only problem with it was minor subpackage problem. EPEL should have successful repoclosure, i.e. no uninstallable packages. If a package in the stable repo is uninstallable, the only way to remove it from the repo is to untag the build. A build with uninstallable subpackages shouldn't be pushed to the stable repo in the first place.
(In reply to Carl George 🤠 from comment #12) > > I have not seen any package, which would be completely in CRB. > > Some examples: aspell, cppunit, doxygen, help2man, javacc, ksc, libdbusmenu, > meson, ocaml > > > CRB could not be modified by anyone outside Red Hat, which is not what I want. > > Sure they can, the sources would be in > https://gitlab.com/redhat/centos-stream/rpms and contributors can send pull > requests. Yes, but only Red Hatter can merge that PR. He has to have time to analyse that change. I want such packages to be handled primarily by community. If I move it into CRB, it would always depend on me. That is not what I want. > > > I do not understand how is it better to remove completely package from whole repository, when the only problem with it was minor subpackage problem. > > EPEL should have successful repoclosure, i.e. no uninstallable packages. If > a package in the stable repo is uninstallable, the only way to remove it > from the repo is to untag the build. A build with uninstallable subpackages > shouldn't be pushed to the stable repo in the first place. Yes, but it was pushed. Because reporting what exactly is failing in the test is often not user-friendly to analyse. I understand what you try to archieve, but you have created more severe regressions to any dnsperf user. Previous one was kind of minor, it was only subpackage. Now they lack whole functionality and there is no simple replacement for that. I admit it should have been noticed, but it was not. Improving testing of spec takes some work and is not done for free. Yes, I made a trivial test to prevent it in the future. But you have made fix somewhere on your list of "broken" packages by breaking it for other users even more. I do not think this is a way to improve things. A needinfo on me was the required action, I admit. I was not aware of the problem. But that should have been sufficient, nothing more should have been done.
In the future, I recommend taking the following actions to avoid pushing uninstallable packages. * use mock's postinstall flag when building locally (`fedpkg mockbuild -- --postinstall`) * check the automated tests tab of the bodhi update for failures * manually test updates that you have submitted
FEDORA-EPEL-2026-bf55bec3f4 (dnsperf-2.14.0-3.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.