Bug 462329 - "yum repolist" nothing output in debug level less then 2
"yum repolist" nothing output in debug level less then 2
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-09-15 08:44 EDT by Pavel Alexeev
Modified: 2014-01-21 18:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-27 11:31:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Alexeev 2008-09-15 08:44:39 EDT
Description of problem:
$ yum -d1 repolist
(nothing output)

Version-Release number of selected component (if applicable):
$ rpm -q yum
yum-3.2.19-3.fc9.noarch

Actual results:
nothing uotput.

Expected results:
As in greater debug level but without outside debug messages, only list of repos:
$ yum -d2 repolist
Loaded plugins: aliases, changelog, downloadonly, fastestmirror, list-data,
              : merge-conf, presto, verify
Setting up and reading Presto delta metadata
No Presto metadata available for gemi
No Presto metadata available for kde
No Presto metadata available for kde-testing
No Presto metadata available for updates-testing
No Presto metadata available for livna
No Presto metadata available for google
No Presto metadata available for kde-all
No Presto metadata available for freshrpms-F9
No Presto metadata available for Hubbitus-F9
No Presto metadata available for adobe-linux-i386
No Presto metadata available for kde-testing-all
No Presto metadata available for remi-F9
No Presto metadata available for dribble
No Presto metadata available for fedora
No Presto metadata available for tigro
No Presto metadata available for remi-test-F9
No Presto metadata available for updates
repo id              repo name                                status  
Hubbitus-F9          Hubbitus F9                              enabled :     117
adobe-linux-i386     Adobe Systems Incorporated               enabled :      17
dribble              Dribble for Fedora 9 - i386              enabled :      89
freshrpms-F9         freshrpms F9                             enabled :     147
gemi                 Fedora 9 - i386 - gemi                   enabled :     110
google               Google - i386                            enabled :       4
kde                  kde                                      enabled :       0
kde-all              kde-all                                  enabled :     478
kde-testing          kde-testing                              enabled :       0
kde-testing-all      kde-testing-all                          enabled :       1
livna                Livna for Fedora Core 9 - i386 - Base    enabled :     788
remi-F9              Les RPM de remi pour F9                  enabled :     101
remi-test-F9         Les RPM de remi en test pour F9          enabled :      79
tigro                Tigro for Fedora 9 - i386                enabled :     167
updates-testing      Fedora 9 - i386 - Test Updates           enabled :     840
Comment 1 seth vidal 2008-10-27 11:31:55 EDT
repolisting only happens at debug level 2 and above. I don't think we'll be changing this behavior. If you want only a list of repos you can use repoquery --qf from yum-utils to achieve that result.
Comment 2 Pavel Alexeev 2008-10-28 08:15:23 EDT
(In reply to comment #1)
> repolisting only happens at debug level 2 and above. I don't think we'll be
> changing this behavior.
Excuse me, but why capacity to work off *command* depend of *debug messages* level??

In other words, in debug level < 2 command repolist is not working completely. Furthermore, this behavior don't described in man, as I can see.

> If you want only a list of repos you can use repoquery
> --qf from yum-utils to achieve that result.
May be it is a workaround. Thank for the hint.

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