Bug 2223347

Summary: dnf repoquery pollutes output with repo loading messages
Product: [Fedora] Fedora Reporter: Miro Hrončok <mhroncok>
Component: dnf5Assignee: amatej
Status: CLOSED DUPLICATE QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 40CC: jkolarik, nsella, petersen, pkratoch, ppisar, rpm-software-management
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-04-04 07:27:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2247867    

Description Miro Hrončok 2023-07-17 12:16:46 UTC
When the standard output of `dnf repoquery` is parsed or redirected to a log, it contains:

Updating and loading repositories:
 fedora                                      100% |   9.3 MiB/s |  22.0 MiB |  00m02s
Repositories loaded.


This makes it hard to process. Please move such output to stderr, where it was in dnf4.

Reproducible: Always

Steps to Reproduce:
1. dnf repoquery --whatsupplements tox > output
2. cat output

Actual Results:  
Updating and loading repositories:
 fedora                                 100% |  82.3 KiB/s |  16.5 KiB |  00m00s
Repositories loaded.
pypy3.9-devel-0:7.3.11-4.3.9.fc39.x86_64
python3-devel-0:3.12.0~b4-1.fc39.i686
python3-devel-0:3.12.0~b4-1.fc39.x86_64
python3.10-devel-0:3.10.12-1.fc39.i686
python3.10-devel-0:3.10.12-1.fc39.x86_64
python3.11-devel-0:3.11.4-2.fc39.i686
python3.11-devel-0:3.11.4-2.fc39.x86_64

Expected Results:  
pypy3.9-devel-0:7.3.11-4.3.9.fc39.x86_64
python3-devel-0:3.12.0~b4-1.fc39.i686
python3-devel-0:3.12.0~b4-1.fc39.x86_64
python3.10-devel-0:3.10.12-1.fc39.i686
python3.10-devel-0:3.10.12-1.fc39.x86_64
python3.11-devel-0:3.11.4-2.fc39.i686
python3.11-devel-0:3.11.4-2.fc39.x86_64

Even with -q, the output is:

 fedora                                 100% | 117.3 KiB/s |  16.5 KiB |  00m00s
pypy3.9-devel-0:7.3.11-4.3.9.fc39.x86_64
python3-devel-0:3.12.0~b4-1.fc39.i686
python3-devel-0:3.12.0~b4-1.fc39.x86_64
python3.10-devel-0:3.10.12-1.fc39.i686
python3.10-devel-0:3.10.12-1.fc39.x86_64
python3.11-devel-0:3.11.4-2.fc39.i686
python3.11-devel-0:3.11.4-2.fc39.x86_64

Comment 1 amatej 2023-07-25 04:17:46 UTC
I have looked into it and in the old dnf only the repolist, search and repoquery commands redirect this output to stderr.
It seems kind of confusing.

For processing we plan to add a machine readable format output: https://github.com/rpm-software-management/dnf5/issues/512
I think that would be a better solution.

Comment 2 Miro Hrončok 2023-07-25 08:03:35 UTC
A machine-readable format output sounds great, but please don't let perfect be the enemy of good. Please restore the dnf4 behavior here.

Comment 3 Fedora Release Engineering 2023-08-16 08:13:05 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 4 Jens Petersen 2024-04-01 10:29:53 UTC
(In reply to Miro Hrončok from comment #2)
> A machine-readable format output sounds great, but please don't let perfect
> be the enemy of good. Please restore the dnf4 behavior here.

+1

Please address this: it is quite common to do repoquery in shell scripts, etc
and including "stderr output" in stdout completely breaks that.
I think the only workaround is to use --quiet.

Further https://github.com/rpm-software-management/dnf5/issues/867 seems not to cover repoquery,
so the argument seems moot.

Comment 5 Jens Petersen 2024-04-01 10:39:18 UTC
I opened https://github.com/rpm-software-management/dnf5/issues/1361 too in the hope that it may get more attention upstream.

Comment 6 Jens Petersen 2024-04-01 10:41:23 UTC
(In reply to Jens Petersen from comment #4)
> I think the only workaround is to use --quiet.

In fact doesn't seem to help, hm

Comment 7 Petr Pisar 2024-04-04 07:27:13 UTC

*** This bug has been marked as a duplicate of bug 2172868 ***