Red Hat Bugzilla – Bug 1069996
[abrt] dnf: repo.py:312:start:AttributeError: 'NoneType' object has no attribute 'start'
Last modified: 2014-11-06 10:43:23 EST
Description of problem: While dnf services work Version-Release number of selected component: dnf-0.4.15-1.fc21 Additional info: reporter: libreport-2.1.12 cmdline: /usr/bin/python /usr/bin/dnf -v makecache timer executable: /usr/bin/dnf kernel: 3.14.0-0.rc4.git0.1.fc21.x86_64 runlevel: N 5 type: Python uid: 0 Truncated backtrace: repo.py:312:start:AttributeError: 'NoneType' object has no attribute 'start' 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 242, in user_main errcode = main(args) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 64, in main return _main(base, args) File "/usr/lib/python2.7/site-packages/dnf/cli/main.py", line 124, in _main cli.run() File "/usr/lib/python2.7/site-packages/dnf/cli/cli.py", line 1459, in run return self.command.run(self.base.extcmds) File "/usr/lib/python2.7/site-packages/dnf/cli/commands.py", line 852, in run self.base.fill_sack() # performs the md sync File "/usr/lib/python2.7/site-packages/dnf/base.py", line 213, in fill_sack self._add_repo_to_sack(r.id) File "/usr/lib/python2.7/site-packages/dnf/base.py", line 120, in _add_repo_to_sack repo.load() File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 548, in load self._handle_load(handle) File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 349, in _handle_load self._md_pload.start(self.name) File "/usr/lib/python2.7/site-packages/dnf/repo.py", line 312, in start self.progress.start(1, 1) AttributeError: 'NoneType' object has no attribute 'start' Local variables in innermost frame: text: u'RPM Fusion for Fedora Rawhide - Free' self: <dnf.repo.MDPayload object at 0x22477d0>
Created attachment 867729 [details] File: backtrace
Created attachment 867730 [details] File: environ
got this bug today
reproducable from CLI: $ dnf makecache &>output
Fixed by 16ca933.
dnf-0.4.16-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/dnf-0.4.16-2.fc20
Only needed to download and install dnf. python-dnf, available in the same build, was not needed.
*** Bug 1070826 has been marked as a duplicate of this bug. ***
if it "works for you", go over to the "admin.fedoraproject.org" page (the link to the update) and leave karma for the package.
Why is dnf crashing when I didn't execute it? I thought it's use was optional for Fedora 20?
If you have installed the package, it's possible that there is something running on the background, IIRC there is a daemon that runs on background and downloads metadata when necessary.
dnf-0.4.16-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Paul Lipps from comment #10) > Why is dnf crashing when I didn't execute it? I thought it's use was > optional for Fedora 20? I recently installed a system from the desktop live media. Anaconda is installed by default and anaconda has dnf as a dependency.
Right. I never installed, nor attempted to execute it, yet I am notified to report bugs on it. It should only be in rawhide until it's ready for mainstream use. Some of us actually use Fedora as our everyday operating system rather than a Red Hat employee playground.
So this is a little bit annoying. This keeps happening on and on, even when I did the upgrade (by the way at this moment there's not any update/upgrade for dnf or for any other package, I did see an upgrade for dnf, I installed it, and nothing, it keeps happening). EOF
Even though this is listed as closed, it is still occurring.
This bug still occurs, several times daily with no apparent rhyme or reason.
Yes this is still a problem after updating. Can someone please reopen this? I can just clone it as well, please advise.
The update solved the problem for me. With all the other queries, it may deserve more investigation.
I'm not seeing the problem, but I also restarted after applying the update (since I also got a kernel update). Affected users might want to try restarting the computer, or at least restarting systemd with systemctl daemon-reload or daemon-reexec.
The version that's supposed to fix this (dnf-0.4.16-2.fc20) didn't go out in the push it was supposed to, but rather in the one after that (less than 12 hours ago). Anyone who thinks this isn't fixed, please double check which version you have.
Ah I see yes I still have dnf-0.4.15-1.f20
Hello, this bug occurs because dnf is updating its cache in the background. The version this is fixed in is 0.4.16. We release updates frequently so it is possible some of you only got 0.4.15 now.
For some reason I had to pull the latest update (0.4.16) from updates-testing (couldn't find it in stable even like 12 hours after it was supposedly pushed for some reason.) but yeah I can confirm that after doing that update this bug is fixed. Thanks!