Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: festival-freebsoft-utils from epel10 has an unresolved dependency, causing it to be uninstallable. Version-Release number of selected component (if applicable): festival-freebsoft-utils-0.10-37.el10_0 How reproducible: always Steps to Reproduce: 1. dnf install festival-freebsoft-utils Actual results: Error: Problem: conflicting requests - nothing provides festival needed by festival-freebsoft-utils-0.10-37.el10_0.noarch from epel Expected results: successful installation
Hmm, it looks like I branched this too eagerly. In most cases I tested with "fedpkg --release epel10 mockbuild -- --postinstall" before branching, but obviously I missed that here. I’m taking the following steps. 1. Add BuildRequires for all Requires, even if they are not “natural” BuildRequires, so that the package will FTBFS if it would FTI. It’s well worth making the build slightly “heavier” to help avoid mistakes like this. 2. File branch requests for festival and for its dependency speech-tools. 3. File branch requests for sox, which is a weak dependency that it turns out is also unsatisfied, and for its dependency opusfile. Let’s see how all that goes. I can retire this package if I need to, but I’m going to try branch requests for the dependencies first. I think speech support is important, but I don’t really want to help maintain these dependencies. However, they’re all in EPEL8 and EPEL9 (or RHEL9 itself) already, so I suspect the regular maintainers will be willing to handle EPEL10 as well.
Sounds like a solid plan, thanks for digging in. My goal is to eliminate or at least significantly reduce the number of uninstallable EPEL 10 packages by the time we have the official launch. https://discussion.fedoraproject.org/t/epel-10-status-update/124549 We don't necessarily have to retire the package if it isn't resolved by that point. I can untag the current build if you like, the branch will stay active, and a new update with all dependencies satisfied can be shipped at a later date. That will avoid the need to retire and then do an un-retire releng ticket.
(In reply to Carl George 🤠 from comment #2) > We don't necessarily have to retire the package if it isn't resolved by that > point. I can untag the current build if you like, the branch will stay > active, and a new update with all dependencies satisfied can be shipped at a > later date. That will avoid the need to retire and then do an un-retire > releng ticket. Hmm, I think that might be the way to go. I know it’s only been five days, but I’ve only had a response on one of the four branch requests I filed, bug 2313978, and even that isn’t making progress right now. I would be happy to return to this package if/when the dependencies are ready, but I’m not willing to go to great lengths to make it happen. Could you please go ahead and untag festival-freebsoft-utils from EPEL10, then?
festival-freebsoft-utils-0.10-37.el10_0 has been untagged. Do you want to close this bug, or leave it open to track the re-addition later?
I’m going to go ahead and close this. It might be a long time before the dependencies get branched, and I’ve pushed https://src.fedoraproject.org/rpms/festival-freebsoft-utils/c/a4a88f066c8f5a1eab29b564ca89578bfe946ba8?branch=epel10 so that any future build in EPEL10 won’t succeed unless it would also be installable.
Thanks for your help.