---Read Additional info first--- Description of problem: In an attempt to use zif to install the F15 kde 4.7.1 updates I modified '/etc/zif/zif.conf' and set 'metadata_expire=1800'. I then ran 'zif clean' to clear cached data. When I ran a 'zif update' I was granted with the following error Loading repository [ ] (0%) Checking [ ] <1%> primary.sqlite.bz2 Failed to load: failed to resolve in fedora-kde47: failed to load md_primary_sql file: checksum incorrect, wanted 8af34d43b8315976f92e2769167d01786458d408, got 61314e5f07e9cd6f72bb0aa0e635b27f12623709 for /var/cache/zif/x86_64/15/fedora-kde47/primary.sqlite.bz2 Version-Release number of selected component (if applicable): Using - http://repos.fedorapeople.org/repos/kkofler/zif-backport/ Sep 21 10:03:46 Updated: zif-0.2.4-0.93.20110920git.fc15.x86_64 Sep 21 10:03:47 Updated: zif-tools-0.2.4-0.93.20110920git.fc15.x86_64 Sep 21 10:04:19 Updated: PackageKit-yum-0.6.17-1.fc15.libzif.so.3.x86_64 Sep 21 10:04:24 Updated: PackageKit-0.6.17-1.fc15.libzif.so.3.x86_64 Sep 21 10:04:25 Updated: PackageKit-glib-0.6.17-1.fc15.libzif.so.3.x86_64 Sep 21 10:04:26 Updated: PackageKit-gstreamer-plugin-0.6.17-1.fc15.libzif.so.3.x86_64 Sep 21 10:04:27 Updated: PackageKit-qt-0.6.17-1.fc15.libzif.so.3.x86_64 How reproducible: Even after running 'zif clean' again and trying another update it still produced the same checksum incorrect message. I even moved the 'fedora-kde47/primary.sqlite.bz2' out of the way and the next 'zif update' also failed. Steps to Reproduce: 1. N/A 2. 3. Actual results: Package updates could not be performed. Expected results: Updating the packages kde 4.7.1 packages as yum could at the same moment. Additional info: 6 hours later I attempted to run a 'zif update' and it correctly listed all of the kde 4.7.1 package updates. I then installed Sep 22 08:33:31 Updated: zif-0.2.4-0.99.20110921git.fc15.x86_64 Sep 22 08:33:31 Updated: zif-tools-0.2.4-0.99.20110921git.fc15.x86_64 and proceeded to upgrade to kde 4.7.1 without issue! No further problems after update. Not sure how helpful this is :p
If it happens again, can you please re-open this report and provide the "zif --verbose update foo" debug spew please. Thanks.
Richard, This is proving to be a difficult bug to catch. I have had this bug re-appear twice more on two different systems. Unfortunately both times when I re-ran zif with the verbose switch the transaction completed successfully without issue... You can re-close this btw. If I manage to get lucky with the verbose switch on the first run on my next set of updates plus have this error show up and get a proper output I'll bother you then. Here is the latest capture from a normal 'zif update'. Downloading [= ] (2%) 33a1c1...60c00b-prestodelta.xml.gz [2Downloading [= ] (2%) repomd.xml [29.0 MB/sec] Downloading [= ] (2%) i386 Failed to load: failed to resolve in updates: failed to load md_primary_sql file: failed to download missing compressed file: failed to download �< span> 8� </address> </body> </html> from any sources (and after retrying)
(In reply to comment #2) > I have had this bug re-appear twice more on two different systems. Are you behind a captive portal on those systems? > Unfortunately both times when I re-ran zif with the verbose switch the > transaction completed successfully without issue... Hmm, i need the log :( > Here is the latest capture from a normal 'zif update'. > Failed to load: failed to resolve in updates: failed to load md_primary_sql > file: failed to download missing compressed file: failed to download �< > span> > 8� > </address> > </body> > </html> This looks like HTML from a portal login page or something. It also looks like there's some memory corruption going on (�<) -- in which case can you grab me the output from "valgrind zif update -v" if you can reproduce this -- thanks. Richard.
Nope neither system is behind a captive portal and this occurred on two totally separate networks. Although I do have IPv6 enabled via native connectivity and tunnel depending on location. I will begin using "valgrind zif update -v" from now on when running updates in the hope of catching this critter. Regards Cody
Created attachment 525211 [details] valgrind output of valgrind zif install -v libusb-debuginfo valgrind zif install -v libusb-debuginfo
Yum was able to find and install libusb-debuginfo Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package libusb-debuginfo.x86_64 1:0.1.3-9.fc15 will be installed --> Finished Dependency Resolution
Packages used to produce valgrind report zif-tools-0.2.5-0.131.20110927git.fc15.x86_64 zif-0.2.5-0.131.20110927git.fc15.x86_64
What does "zif repo-list" say?
Created attachment 525217 [details] Output of 'zif repo-list' Output of 'zif repo-list'
(In reply to comment #6) > Yum was able to find and install libusb-debuginfo commit 28e9d4e6f5d442f90c8f55acfae4c29d3eb94ead Author: Richard Hughes <richard> Date: Wed Sep 28 12:02:51 2011 +0100 Enable -debuginfo repos when we try to install -debuginfo packages The yum-plugin-auto-update-debug-info code enables debuginfo repos when we try to install -debuginfo packages, so we should probably copy that behaviour. There's a new option called auto_enable_debuginfo (default true) in zif.conf to control this. Resolves some of https://bugzilla.redhat.com/show_bug.cgi?id=740623
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping