Bug 1287513

Created attachment 1101367 [details]
File: _var_log_dnf.log

Created attachment 1101368 [details]
File: backtrace

Created attachment 1101369 [details]
File: dnf-makecache.log

Created attachment 1101370 [details]
File: environ

I can confirm this up to F23 updates-testing 


>> 321 class YumHistoryTransaction(object):
   322     """ Holder for a history transaction. """
   323 
   324     def __init__(self, history, row):


The contents of row[] is as follows:


(Pdb) row
(238, 1461360892, '2556:6d9e7771bb3d3bb28446ed8104a1cb00df7c138a', None, None, 1000, None)


We can see that on L#330: 


330         self.end_timestamp    = row[3]


Assigns the NoneType to senf.end_timestamp, then on L#417 inside class YumMergedHistoryTransaction(YumHistoryTransaction): assumes obj.end_timestap's NoneType


 412         self.end_timestamp    = obj.end_timestamp


Which is compared on (now) L#718


   718         if self.end_timestamp < obj.end_timestamp:


This will likely also be an issue if there are any comparisons being done with:

   331         self.end_rpmdbversion = row[4]
 333         self.return_code      = row[6]

The error is in how "old" (L#1235) is handling partial transactions, now that I think about it, I did ctrl+c out of one of these transactions.... hence, I guess, the None types in the data set. 

>>1235     def old(self, tids=[], limit=None, complete_transactions_only=False):


Setting complete_transactions_only=False to True yields a different error:


ValueError: no transaction with given ID: 242


With the above set, it does list out most of the packages that need to be removed, and clearly fails on the transaction that I did not let complete.


The main thing that I noticed during this troubleshooting step, as I iterated through printing out the various row[]s is that other rows didn't have as many elements as the one that is presumably causing the error.

This perhaps points to the other end of the problem here being "what happens to the history sqlite db when a transaction is abruptly ended" - which is far far above my head. 

Cheers.

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()

I doubt any of this will get resolved until DNF2, as this is the sentiment I've been seeing on their Github issues. FYI

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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