Bug 1276897 - DNF/YUM - Longstanding Dispay Bug
Summary: DNF/YUM - Longstanding Dispay Bug
Alias: None
Product: Fedora
Classification: Fedora
Component: dnf
Version: 25
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: rpm-software-management
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2015-11-01 01:04 UTC by John C. Beima
Modified: 2017-04-18 15:19 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2017-04-18 15:19:18 UTC
Type: Bug

Attachments (Terms of Use)
Photo displaying output. (249.82 KB, image/png)
2015-11-01 01:04 UTC, John C. Beima
no flags Details

Description John C. Beima 2015-11-01 01:04:07 UTC
Created attachment 1088294 [details]
Photo displaying output.

Description of problem:

When you use DNF or YUM to erase 2 kernels, the progress/status section of the output in the "erasing" block says it is "erasing" the first kernel more than once and does not mention the second kernel.

The "verification" section displays properly.

Please see the attached image.

Version-Release number of selected component (if applicable):

All versions, for a very long time have done this.

How reproducible:

Simply erase 2 out of the 3 installed kernels.

Steps to Reproduce:
1. dnf erse kernel-core-1 kernel-core-2
2. "Y"
3. Look at the status Section.

Actual results:

DNF appears to remove the kernels properly. This appears to just be a cosmetic "status" bug in the "erasing" section.

Expected results:

Things work as expected.

Additional info:

Comment 1 Honza Silhan 2015-11-02 15:42:16 UTC
What version of DNF are you using? I remember we were fixing something like that.

Comment 2 John C. Beima 2015-11-02 16:30:58 UTC
I believe teh machine I captured this from is 1.1.3-1, however it has been in all versions of dnf that shipped with Fedora 22.

I also believe this has been in yum for years before this.

I do recall the verification section used to do it as well, but I believe it was fixed at some point. Which appeared strange that only one section was fixed.

I would guess that dnf's status section is not really setup to handle more than one packing with the same name, since the kernel is the only time it happens.

Possibly searching the list of packages to process from the begining everytime instead of from where it is at?

Just a theory.

Comment 3 John C. Beima 2015-11-02 16:32:24 UTC
ONe additional note.

This does happen each and every time.

I am running Fedora 22 x64.

Comment 4 Fedora Admin XMLRPC Client 2016-07-08 09:37:43 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 5 John C. Beima 2016-07-19 19:02:47 UTC
Just updating this to include Fedora 24 so it does not just get closed.

This still exists all his time later.

Comment 6 John C. Beima 2016-12-10 07:51:41 UTC
This bug still exists in Fedora 25.

Very disappointed to see the complete and utter lack of quality in this application and lack of caring by it's maintainers.

Comment 7 Jaroslav Mracek 2017-04-18 15:19:18 UTC
I have good news because I cannot reproduce it anymore with dnf-2.3.0-1.git.3.33e4097.fc25.noarch, libdnf-0.8.1-2g8379fd9.fc25.x86_64. The dnf-2.3 was released into rawhide, but can be installed from out testing repository "dnf copr enable rpmsoftwaremanagement/dnf-nightly". Please if the problem appears with dnf-2.3 or later version, please don't hesitate to reopen the bug report. And I am sorry for so long time that you waited for solving the problem.

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