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 1302510

Summary: dnf: unhandled exception for dnf history info command
Product: [Fedora] Fedora Reporter: Marek Doležel <marekdolezel>
Component: dnfAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: elstaal, fulminemizzega, jsilhan, mluscon, packaging-team-maint, pnemade, samuel.rakitnican, vmukhame, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-01 13:04:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
DNF backtrace none

Description Marek Doležel 2016-01-28 02:44:01 UTC
Created attachment 1118979 [details]
DNF backtrace

Description of problem: Unhandled exception occurs when running dnf history info command. 


Version-Release number of selected component (if applicable):1.1.6-1.fc24


How reproducible: Always


Steps to Reproduce:
1. run sudo dnf history info 
or
sudo dnf history 2 # crashes regardless of actual transaction id

Actual results: Exception is not handled and program "crashes".


Expected results:Show information about specified transaction.


Additional info:

Comment 1 Erick 2016-01-29 05:37:49 UTC
I have the described issue since this morning. Also to mention that a repodata directory was mislabeled in SELinux. However relabeling with restorecon didn't fix the issue with dnf history info.

Comment 2 Erick 2016-01-29 07:07:37 UTC
Also another AVC error re performing finds on repodata directories was also found. Fixing this error also didn fix the dnf history info command.

Comment 3 Vít Ondruch 2016-01-29 09:04:57 UTC
I observed the same issue. Disappeared after first installation. Now it seems I can use "history" as I wish.

Comment 4 Vít Ondruch 2016-01-29 09:09:38 UTC
Actually, I was wrong. I can see the history of last operation, but can't see the "last-1". I suspect this will be related to bug 1239274 (yes, I can see the cmdline in output now).

Comment 5 Erick 2016-01-29 10:06:19 UTC
same situation here as at Vit's.

Comment 6 fulminemizzega 2016-01-29 12:42:56 UTC
Vit, Erick,
I'm seeing a different behaviour: dnf history info of every transaction happened after dnf update to 1.1.6 (that fixed bug 1239274) works fine. If you look at the attachment I uploaded in that bug (I'm sorry I did the wrong thing, should I also attach the same file on this bug report?), I did update dnf in transaction 132, and dnf history info works with everything with id >= 133. If I instead try to see info of every id < 133, I get the error.
I did check that every transaction with id < 133 does not work doing this:
for i in {1..132}; do dnf history info $i 2>&1 | grep AttributeError ; done >> output
then wc -l  and got 132 lines.
If you still look at my dnf history attachment, I was running F22 until transaction 92, where you can see that I did the upgrade to F23. So even transactions done with dnf in F22 that didn't have bug 1239274 do not work with dnf history info.

Comment 7 Honza Silhan 2016-02-01 13:04:43 UTC

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

Comment 8 srakitnican 2016-02-01 13:44:20 UTC
By downgrading to dnf-plugins-core-0.1.15-1.fc23.noarch.rpm both history info and history command line works.

http://koji.fedoraproject.org/koji/buildinfo?buildID=706439

Comment 9 srakitnican 2016-02-01 13:51:58 UTC
Never mind, it is working only for last transaction, still the same traceback.

Comment 10 Marek Doležel 2016-02-01 19:53:00 UTC
(In reply to Jan Silhan from comment #7)
> 
> *** This bug has been marked as a duplicate of bug 1303149 ***

I think it should be the other way. As this bug was reported earlier.