http://youtu.be/X1LYDWtRM84 Have no idea why and no idea how.
Do you still experience this problem with the current version? If you can reproduce, please run: $ abrt-gui -vvv and send us the output.
This seems like a bug in yum. We use the yum API to download the packages like this: current_pkg = 1 for pkg in package_list: print "Downloading %i of %i packages" % (current_pkg, len(package_list)) self.downloadPkgs(pkglist=[pkg]) current_pkg++ - and according to the log it looks like it's looping in the downloadPkgs() which comes from YumBase
Isn't the "print" statement above executed on each iteration, printing "Downloading 13 of 15 .." again and again? downloadPkgs() might fail in some ways, but it very likely does not loop there.
(In reply to comment #3) > Isn't the "print" statement above executed on each iteration, printing > "Downloading 13 of 15 .." again and again? downloadPkgs() might fail in > some ways, but it very likely does not loop there. - oops, sorry, the example is not correct, the message "Downloading .." comes from updateProgress callback which is called from the downloadPkgs() - do the real code is: <snip> err = self.downloadPkgs(pkglist=[pkg]) # normalize the name # just str(pkg) doesn't work because it can have epoch pkg_nvra = pkg.name + "-" + pkg.version + "-" + pkg.release + "." + pkg.arch package_file_name = pkg_nvra + ".rpm" if err: # I observed a zero-length file left on error, # which prevents cleanup later. Fix it: try: os.unlink(self.tmpdir + "/" + package_file_name) except: pass print (_("Downloading package {0} failed").format(pkg)) else: unpack_result = unpack_rpm(package_file_name, files, self.tmpdir, self.cachedir, self.keeprpms, exact_files=download_exact_files) if unpack_result == RETURN_FAILURE: # recursively delete the temp dir on failure print _("Unpacking failed, aborting download...") clean_up() return RETURN_FAILURE downloaded_pkgs += 1 </snip> - and as you can see from the video the code after the line err = self.downloadPkgs(pkglist=[pkg]) is never reached (it should at least increase the downloaded_pkgs counter)
Yes, it's stuck in downloadPkgs(). My guess is it's not an infinite loop, downloader is just trying all mirrors (there are lots of them for F16) to download the remaining 5% of the 375MB file, but it keeps failing. Ran out of space in /var/cache, perhaps?
Author: Jiri Moskovcak <jmoskovc> Date: Thu Sep 20 10:26:44 2012 +0200 added error callback to get notification about download failure rhbz#786640
I added a notification for cases when downloading fails, so user knows what's going on and it doesn't look like it's restarting the download without any reason.
abrt-2.0.13-1.fc18,libreport-2.0.14-1.fc18,btparser-0.19-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/abrt-2.0.13-1.fc18,libreport-2.0.14-1.fc18,btparser-0.19-1.fc18
Package abrt-2.0.13-1.fc18, libreport-2.0.14-1.fc18, btparser-0.19-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing abrt-2.0.13-1.fc18 libreport-2.0.14-1.fc18 btparser-0.19-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-14679/abrt-2.0.13-1.fc18,libreport-2.0.14-1.fc18,btparser-0.19-1.fc18 then log in and leave karma (feedback).
abrt-2.0.13-1.fc17,libreport-2.0.14-1.fc17,btparser-0.19-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/abrt-2.0.13-1.fc17,libreport-2.0.14-1.fc17,btparser-0.19-1.fc17
python-urlgrabber-3.9.1-21.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/python-urlgrabber-3.9.1-21.fc18
python-urlgrabber-3.9.1-21.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.