Description of problem: Trying to install the "Security Lab" group generates errors. Version-Release number of selected component (if applicable): Fedora release 29 (Twenty Nine) How reproducible: Every time Steps to Reproduce: 1. sudo dnf install @"Security Lab" Actual results: ---- $ sudo dnf install @"Security Lab" Last metadata expiration check: 0:05:24 ago on Tue 09 Apr 2019 11:20:06 AM PDT. No match for group package "nmap-frontend" No match for group package "openscap-content-sectool" Error: Problem: conflicting requests - nothing provides libgdbm.so.4()(64bit) needed by ntop-5.0.1-15.fc28.x86_64 - nothing provides libnetsnmp.so.30()(64bit) needed by ntop-5.0.1-15.fc28.x86_64 (try to add '--skip-broken' to skip uninstallable packages) ---- Expected results: It should just work. Additional info: Is there some automatic test that could be set up to make sure that the groups defined in the Fedora repositories are complete and error-free before release? dnf group list | gawk ' /^Installed/{ok=1;next}; /^Available/{ok=2;next}; ok==2{ sub("^ *",""); print "echo ======================= "$0; print "sudo dnf install @\x22"$0"\x22 < /dev/null" }' | bash 2>&1 > /tmp/output grep ^No /tmp/output | sort | uniq -c | sort -n 1 No match for group package "covered" 1 No match for group package "dinotrace" 1 No match for group package "eclipse-eclox" 1 No match for group package "eclipse-texlipse" 1 No match for group package "eclipse-veditor" 1 No match for group package "emacs-dinotrace" 1 No match for group package "eqntott" 1 No match for group package "gplcver" 1 No match for group package "nmap-frontend" 1 No match for group package "openscap-content-sectool" 1 No match for group package "perl-SystemPerl" 1 No match for group package "picprog" 1 No match for group package "tetex-IEEEtran" 8 No match for group package "xorg-x11-drv-armsoc" 8 No match for group package "xorg-x11-drv-omap" 12 No match for group package "lsvpd" 12 No match for group package "powerpc-utils" grep -A4 Error /tmp/output Error: Problem: conflicting requests - nothing provides libgdbm.so.4()(64bit) needed by ntop-5.0.1-15.fc28.x86_64 - nothing provides libnetsnmp.so.30()(64bit) needed by ntop-5.0.1-15.fc28.x86_64 (try to add '--skip-broken' to skip uninstallable packages) Anyhoo, hope this helps! :-)
This is not a problem with the security lab contents... instead it's because ntop fails to build from source and hasn't been rebuilt against new requirements. If you 'dnf remove ntop' and then try it should work. *** This bug has been marked as a duplicate of bug 1605260 ***
Reopening this bug because of a couple of points: 1. How did ntop get released to the repositories if it failed to build from source? That's not how QA works, is it? 2. When I checked all available groups (not just the "Security Lab" group), there were a high number of error messages of the form: > No match for group package "nmap-frontend" > No match for group package "openscap-content-sectool" Could you address these error messages too? It seems the groups contain packages that don't exist any more. QA should have blocked this from getting into the repositories, shouldn't it? Thanks
I had the same questions... I have applied patches for ntop to work and submitted a scratch build to Koji (in https://bugzilla.redhat.com/show_bug.cgi?id=1605260) but I think there's no maintainer for ntop and it doesn't sound like there will be. Ntop has moved on to a newer generation No one from Fedora picked up my SRPM and committed the changes to make ntop work for Fedora 29. I am not a Fedora contributor.
(In reply to Penelope Fudd from comment #2) > Reopening this bug because of a couple of points: > > 1. How did ntop get released to the repositories if it failed to build from > source? That's not how QA works, is it? It's not in the f30+ repos. It's only in the f29 repos as the last version that built for f28. (you will note the fc28 there) > 2. When I checked all available groups (not just the "Security Lab" group), > there were a high number of error messages of the form: > > No match for group package "nmap-frontend" > > No match for group package "openscap-content-sectool" well, sure, those should be fixed up. > Could you address these error messages too? It seems the groups contain > packages that don't exist any more. QA should have blocked this from > getting into the repositories, shouldn't it? you would need to ask QA, but its not as simple as that. When packages are retired they are supposed to be removed from groups, but I guess people forget/don't do that step. There's currently no 'all packages/groups must exist' test or critera. You could propose such to the test list if you like. Note that those missing group packages don't cause it to fail, only warn. (In reply to Allen Hewes from comment #3) > I had the same questions... > > I have applied patches for ntop to work and submitted a scratch build to > Koji (in https://bugzilla.redhat.com/show_bug.cgi?id=1605260) but I think > there's no maintainer for ntop and it doesn't sound like there will be. Ntop > has moved on to a newer generation Right, there's no maintainer to apply fixes. > > No one from Fedora picked up my SRPM and committed the changes to make ntop > work for Fedora 29. I am not a Fedora contributor. Right. If you would like to be, I can assist you into taking it over, otherwise you could mail the devel list and ask if anyone wants to pick it up. You might get someone willing.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.