ngircd fails to install: nothing provides libident

It seems to me the ngircd package has a problem on Fedora 31:

# dnf repolist
repo id                       repo name
fedora                        Fedora 31 - x86_64
fedora-modular                Fedora Modular 31 - x86_64
updates                       Fedora 31 - x86_64 - Updates
updates-modular               Fedora Modular 31 - x86_64 - Updates
# dnf --refresh install ngircd
Fedora Modular 31 - x86_64                       31 kB/s |  23 kB     00:00    
Fedora Modular 31 - x86_64 - Updates             28 kB/s |  21 kB     00:00    
Fedora 31 - x86_64 - Updates                     29 kB/s |  22 kB     00:00    
Fedora 31 - x86_64                               44 kB/s |  23 kB     00:00    
 Problem: conflicting requests
  - nothing provides needed by ngircd-25-3.fc31.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Whether the problem is libident having been unintentionally removed from the repos or ngircd being built without ident support and the RPM not reflecting that or a misconfiguration of my system I have no idea, so I’m asking here: Is there anybody who can tell me which one it is?

Best regards,
Steinar Knutsen

1 Like

Here you have two option (I suggest to you do both):

1.- Report a Bug against this package follow this procedure:
2.- Install the dependency from fedora 28:

and try again…


  • 28 is the latest build State complete
  • 29 State failed
  • 30 State failed
  • 31 State failed




This is happening with a few packages of Fedora 31, for example with eclipse-m2-core or hibernate-core. I filled a bug in Red Hat Bugzilla about the impossibility to install hibernate-core ( and look at their answer:

As no package depends on hibernate and class mvn(org.hibernate.common:hibernate-commons-annotations) is already orphaned, we are aiming to orphan also hibernate package. If you have a reason, that hibernate should stay in fedora, let us know please.

Funny thing if you take into account that Hibernate is a framework owned by Red Hat and is integrated in their JBoss/Wildfly application server. :thinking:


I just hope it’s not the start of a trend. I’ve used RH/Fedora for many years, partly because its package repo is huge, and it has little bit rot and at the same time pretty fresh packages. That’s really quite rare. “Break, wait, remove” is not exactly the ideal way to EOL a package.