Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1698209 - dnf install @"Security Lab" : missing packages
Summary: dnf install @"Security Lab" : missing packages
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-repos
Version: 29
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Mohan Boddu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-09 19:53 UTC by Penelope Fudd
Modified: 2019-11-27 21:54 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-27 21:54:52 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Penelope Fudd 2019-04-09 19:53:47 UTC
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!  :-)

Comment 1 Kevin Fenzi 2019-04-09 20:10:11 UTC
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 ***

Comment 2 Penelope Fudd 2019-04-09 21:19:35 UTC
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

Comment 3 Allen Hewes 2019-04-09 22:50:36 UTC
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.

Comment 4 Kevin Fenzi 2019-04-10 17:59:53 UTC
(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.

Comment 5 Ben Cotton 2019-10-31 19:37:55 UTC
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.

Comment 6 Ben Cotton 2019-11-27 21:54:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.