Bug 1309065 - dnf history info with range causes Python exception for transaction with no end timestamp
dnf history info with range causes Python exception for transaction with no e...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: dnf (Show other bugs)
23
All Linux
low Severity unspecified
: ---
: ---
Assigned To: Michael Mráka
Fedora Extras Quality Assurance
: EasyFix, Triaged
: 1287513 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-16 13:30 EST by Daniel Miranda
Modified: 2016-07-22 05:07 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-07-22 05:07:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Contents of yumdb that triggers the issue (1.99 MB, application/x-xz)
2016-02-16 13:30 EST, Daniel Miranda
no flags Details

  None (edit)
Description Daniel Miranda 2016-02-16 13:30:45 EST
Created attachment 1127665 [details]
Contents of yumdb that triggers the issue

Description of problem:

A Python exception is thrown while trying to print history information for a range of  transactions, seemingly due to a transaction with no end timestamp.


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

dnf.noarch-1.1.6-2.fc23


How reproducible:

Always with particular yum history


Steps to Reproduce:

1. Set DNF to use the attached db (maybe with --installroot)
2. Run `dnf history info 2088..3215` (respectively, the first and last transactions in the DB)


Actual results:

Information from the range of transactions is printed.


Expected results:

A Python exception is thrown.


Additional info:

Traceback (most recent call last):
  File "/bin/dnf", line 57, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 174, in user_main
    errcode = main(args)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 60, in main
    return _main(base, args)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 112, in _main
    cli.run()
  File "/usr/lib/python3.4/site-packages/dnf/cli/cli.py", line 1095, in run
    return self.command.run(self.base.extcmds)
  File "/usr/lib/python3.4/site-packages/dnf/cli/commands/__init__.py", line 1218, in run
    ret = self.output.historyInfoCmd(extcmds)
  File "/usr/lib/python3.4/site-packages/dnf/cli/output.py", line 1518, in historyInfoCmd
    mobj.merge(tid)
  File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 718, in merge
    if self.end_timestamp < obj.end_timestamp:
TypeError: unorderable types: int() < NoneType()
Comment 1 Igor Gnatenko 2016-02-16 13:54:55 EST
hmm, how you got it without end_timestamp? ;)
Comment 2 Daniel Miranda 2016-02-16 15:22:54 EST
No idea, my history seems to have mutated in some way, it seems full of strange things. It also seems to have weird state transitions that cause asserts to trigger. I also found some other small Py3 issues. I'll open a PR on GitHub with fixes for them.
Comment 3 Earth 2016-06-24 05:19:22 EDT
I have the same problem.

# dnf history info 109..136
Traceback (most recent call last):
  File "/usr/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 174, in user_main
    errcode = main(args)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 60, in main
    return _main(base, args)
  File "/usr/lib/python3.5/site-packages/dnf/cli/main.py", line 112, in _main
    cli.run()
  File "/usr/lib/python3.5/site-packages/dnf/cli/cli.py", line 1096, in run
    return self.command.run(self.base.extcmds)
  File "/usr/lib/python3.5/site-packages/dnf/cli/commands/__init__.py", line 1220, in run
    ret = self.output.historyInfoCmd(extcmds)
  File "/usr/lib/python3.5/site-packages/dnf/cli/output.py", line 1518, in historyInfoCmd
    mobj.merge(tid)
  File "/usr/lib/python3.5/site-packages/dnf/yum/history.py", line 721, in merge
    if self.end_timestamp < obj.end_timestamp:
TypeError: unorderable types: int() < NoneType()
Comment 4 Earth 2016-06-24 05:30:26 EDT
Here's a simple patch that solved the problem on my computer https://github.com/rpm-software-management/dnf/pull/522
Comment 5 Kamil Dudka 2016-06-27 04:51:02 EDT
Still a bug in python3-dnf-1.1.9-2.fc23.noarch:

# dnf history rollback 187
Last metadata expiration check: 0:21:35 ago on Mon Jun 27 10:07:05 2016.
Traceback (most recent call last):
  File "/bin/dnf", line 58, in <module>
    main.user_main(sys.argv[1:], exit_code=True)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 174, in user_main
    errcode = main(args)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 60, in main
    return _main(base, args)
  File "/usr/lib/python3.4/site-packages/dnf/cli/main.py", line 112, in _main
    cli.run()
  File "/usr/lib/python3.4/site-packages/dnf/cli/cli.py", line 1096, in run
    return self.command.run(self.base.extcmds)
  File "/usr/lib/python3.4/site-packages/dnf/cli/commands/__init__.py", line 1233, in run
    ret = self._hcmd_rollback(extcmds[1:])
  File "/usr/lib/python3.4/site-packages/dnf/cli/commands/__init__.py", line 1141, in _hcmd_rollback
    return self.base.history_rollback_transaction(extcmd)
  File "/usr/lib/python3.4/site-packages/dnf/cli/cli.py", line 638, in history_rollback_transaction
    mobj.merge(tid)
  File "/usr/lib/python3.4/site-packages/dnf/yum/history.py", line 721, in merge
    if self.end_timestamp < obj.end_timestamp:
TypeError: unorderable types: int() < NoneType()
Comment 6 Michael Mráka 2016-06-28 07:50:58 EDT
PR merged to master. Thanks.
Comment 7 Igor Gnatenko 2016-07-22 05:06:38 EDT
*** Bug 1287513 has been marked as a duplicate of this bug. ***
Comment 8 Igor Gnatenko 2016-07-22 05:07:23 EDT
Fixed as part of DNF 2.0 release which will be available soon.

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