Description of problem: Pressed ^C while dnf was updating cache Version-Release number of selected component: dnf-0.3.8-2.git85524ae.fc19 Additional info: reporter: libreport-2.1.5 cmdline: /usr/bin/python /usr/bin/dnf info executable: /usr/bin/dnf kernel: 3.9.6-301.fc19.x86_64 runlevel: N 5 uid: 1000 Truncated backtrace: repo.py:97:__init__:TypeError: 'NoneType' object has no attribute '__getitem__' Traceback (most recent call last): File "/usr/bin/dnf", line 35, in <module> main.user_main(sys.argv[1:], exit_code=True) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 277, in user_main errcode = main(args) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 48, in main return 1 File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 124, in __exit__ self.close() File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 238, in close self._store_persistent_data() File "/usr/lib/python2.7/site-packages/dnf/yum/base.py", line 166, in _store_persistent_data if r.metadata_expire_in()[1] <= 0] File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 408, in metadata_expire_in self._try_cache() File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 247, in _try_cache self.metadata = self._handle_load(handle) File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 193, in _handle_load return Metadata(result, handle) File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 97, in __init__ self._mirrors = handle.mirrors[:] TypeError: 'NoneType' object has no attribute '__getitem__' Local variables in innermost frame: res: <librepo.Result object at 0x1043ef0> self: <dnf.repo.Metadata object at 0x10489d0> handle: <dnf.repo._Handle object at 0x1047af8>
Created attachment 764928 [details] File: backtrace
Created attachment 764929 [details] File: core_backtrace
Created attachment 764930 [details] File: environ
(In reply to Maciek Borzecki from comment #0) > Description of problem: > Pressed ^C while dnf was updating cache > Hello, Do you mean you pressed ^C on a previous run when DNF was downloading the cache or you pressed ^C on the run that then ended with this traceback? Thank you!
^C was pressed during the run that resulted in backtrace. Quick way to reproduce the problem is to run for instance 'dnf check-update' and press ^C right away, even before the names of repositories are printed. Hope that helps
[mborzecki@COMP_006_THK_mborzecki:~]$ sudo dnf history BDB2053 Freeing read locks for locker 0x1e25: 1071/140545094014976 BDB2053 Freeing read locks for locker 0x1e26: 1071/140545094014976 BDB2053 Freeing read locks for locker 0x1e27: 1071/140545094014976 BDB2053 Freeing read locks for locker 0x1e28: 1071/140545094014976 as a result, locks on rpm DB were not cleaned up
Thanks! Reproducible 3/5 times by pressing ^C 0.5s after executing a DNF command. The traceback we are seeing is mangled, the exception is not really triggered at the time of base.__exit__. Through some experimentation I got this traceback: ^CTraceback (most recent call last): File "/home/akozumpl/dnf/dnf/cli/main.py", line 63, in main return _main(base, args) File "/home/akozumpl/dnf/dnf/cli/main.py", line 138, in _main result, resultmsgs = cli.run() File "/home/akozumpl/dnf/dnf/cli/cli.py", line 1295, in run load_available_repos=lar) File "/home/akozumpl/dnf/dnf/yum/base.py", line 220, in activate_sack self._add_repo_to_sack(r.id) File "/home/akozumpl/dnf/dnf/yum/base.py", line 131, in _add_repo_to_sack repo.load() File "/home/akozumpl/dnf/dnf/repo.py", line 364, in load if self.metadata or self._try_cache(): File "/home/akozumpl/dnf/dnf/repo.py", line 253, in _try_cache self.metadata = self._handle_load(handle) File "/home/akozumpl/dnf/dnf/repo.py", line 198, in _handle_load return Metadata(result, handle) File "/home/akozumpl/dnf/dnf/repo.py", line 102, in __init__ self._mirrors = handle.mirrors[:] TypeError: 'NoneType' object has no attribute '__getitem__' It could be some weird ^C vs. librepo interaction.
> It could be some weird ^C vs. librepo interaction. Which is the case indeed. Opened bug 977803.
with bug 977803 resolved in librepo upstream this only waits for retesting and building DNF against the new version. I'll try to remember it before making the next DNF build.
*** Bug 986480 has been marked as a duplicate of this bug. ***
Fixed in dnf-0.3.10.
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19
Package hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing hawkey-0.3.16-1.git4e79abc.fc19 dnf-0.3.10-1.giteb9dddb.fc19 librepo-0.0.5-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-13415/dnf-0.3.10-1.giteb9dddb.fc19,librepo-0.0.5-2.fc19,hawkey-0.3.16-1.git4e79abc.fc19 then log in and leave karma (feedback).
hawkey-0.3.16-1.git4e79abc.fc19, dnf-0.3.10-1.giteb9dddb.fc19, librepo-0.0.5-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.