Description of problem: Failed to install gqview after update of Fedora Core 6 to Fedora 7 Test4 Version-Release number of selected component (if applicable): How reproducible: Install gqview (2.0.4-1.fc7) on Fedora 7 Test4 platform. Steps to Reproduce: 1.Execute the following: sudo yum install gqview Actual results: [dingodave@Dingo ~]$ sudo yum install gqview Loading "installonlyn" plugin Setting up Install Process Parsing package install arguments primary.sqlite.bz2 100% |=========================| 2.2 MB 00:02 primary.sqlite.bz2 100% |=========================| 3.7 MB 00:03 Resolving Dependencies --> Running transaction check ---> Package gqview.i386 0:2.0.4-1.fc7 set to be updated Checking deps for gqview.i386 0-2.0.4-1.fc7 - u Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: gqview i386 2.0.4-1.fc7 development 868 k Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 868 k Is this ok [y/N]: y Downloading Packages: (1/1): gqview-2.0.4-1.fc7 100% |=========================| 868 kB 00:00 Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.main(sys.argv[1:]) File "/usr/share/yum-cli/yummain.py", line 172, in main base.doTransaction() File "/usr/share/yum-cli/cli.py", line 301, in doTransaction problems = self.downloadPkgs(downloadpkgs) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 808, in downloadPkgs cache=po.repo.http_caching != 'none', File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 534, in getPackage cache=cache File "/usr/lib/python2.5/site-packages/yum/yumRepo.py", line 516, in _getFile http_headers=headers, File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 411, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.5/site-packages/urlgrabber/mirror.py", line 397, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 927, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 845, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.5/site-packages/urlgrabber/grabber.py", line 922, in retryfunc apply(cb_func, (obj, )+cb_args, cb_kwargs) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 705, in verifyPkg if not po.verifyLocalPkg(): File "/usr/lib/python2.5/site-packages/yum/packages.py", line 531, in verifyLocalPkg (csum_type, csum) = self.returnIdSum() File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 162, in returnIdSum return (self.checksum_type, self.checksum_value) File "/usr/lib/python2.5/site-packages/yum/sqlitesack.py", line 102, in __getattr__ (self.pkgId,)) File "/usr/lib/python2.5/site-packages/yum/sqlutils.py", line 148, in executeSQLQmark return cursor.execute(query, params) sqlite3.OperationalError: no such column: checksum_value
Something with the db format change isn't getting caught correctly...
*** Bug 239980 has been marked as a duplicate of this bug. ***
*** Bug 239984 has been marked as a duplicate of this bug. ***
*** Bug 240098 has been marked as a duplicate of this bug. ***
So the problem here is that createrepo has a hard-coded value for the dbversion (9) which doesn't actually match what the dbversion being created is. I'll update createrepo to hard-code 10 for the moment, but we should really make createrepo get that from sqlitecachec. Jesse -- we'll then need to make sure the new createrepo is being used on composes where the sqlitecache is being pre-created.
AFAIK we aren't pre-generating sqlite cache anywhere for devel. There are issues with creating this on an NFS share that haven't been resolved yet.
(From offline conversation) -- the db cache is being generated for devel. And patches for yum-metadata-parser and createrepo sent upstream; will build and apply for the Fedora packages. This should then be fixed for the next rawhide push.
*** Bug 240173 has been marked as a duplicate of this bug. ***
Whats the quick workaround for users to get past this to get to the updates (is there one?)
If you manually update yum and yum-metadata-parser, then you won't hit the traceback. There's unfortunately not much of a better answer.
(In reply to comment #10) > If you manually update yum and yum-metadata-parser, then you won't hit the > traceback. There's unfortunately not much of a better answer. How do we do that...??
*** Bug 240227 has been marked as a duplicate of this bug. ***
*** Bug 240219 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > (In reply to comment #10) > > If you manually update yum and yum-metadata-parser, then you won't hit the > > traceback. There's unfortunately not much of a better answer. > > How do we do that...?? Go to http://download.fedora.redhat.com/pub/fedora/linux/core/development/i386/os/Fedora/ and grab the latest rpm packages of yum yum-metadata-parser and maybe you'll also need yum-updatesd (I needed it) Then do a rpm -Fvh yum-*.rpm This fixed it for me.
'yum upgrade' fails immediately in the above manner after installing a fc7-t4 on x86_64. it makes the distro un-upgradable, so I'd rate this as very serious indeed... presumably the default yum db format is going to be in sync with repos in time for fc7? the workaround above works fine for me for now. thanks.
I believe this is fixed by yum-metadata-parser-1.1.0-2.fc7, which is now available in rawhide.