Bug 239938 - traceback with yum sqlitedb layout change
Summary: traceback with yum sqlitedb layout change
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: createrepo
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
URL:
Whiteboard:
: 239980 239984 240098 240173 240219 240227 (view as bug list)
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
 
Reported: 2007-05-12 22:14 UTC by David Bartmess
Modified: 2014-01-21 22:58 UTC (History)
9 users (show)

Fixed In Version: yum-metadata-parser-1.1.0-2.fc7
Clone Of:
Environment:
Last Closed: 2007-05-17 20:24:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Bartmess 2007-05-12 22:14:40 UTC
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

Comment 1 Jeremy Katz 2007-05-14 18:42:43 UTC
Something with the db format change isn't getting caught correctly...

Comment 2 Jeremy Katz 2007-05-14 18:43:46 UTC
*** Bug 239980 has been marked as a duplicate of this bug. ***

Comment 3 Jeremy Katz 2007-05-14 18:44:00 UTC
*** Bug 239984 has been marked as a duplicate of this bug. ***

Comment 4 Jeremy Katz 2007-05-15 15:06:53 UTC
*** Bug 240098 has been marked as a duplicate of this bug. ***

Comment 5 Jeremy Katz 2007-05-15 16:13:10 UTC
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.

Comment 6 Jesse Keating 2007-05-15 16:14:32 UTC
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.

Comment 7 Jeremy Katz 2007-05-15 17:14:20 UTC
(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.

Comment 8 Jeremy Katz 2007-05-15 17:24:20 UTC
*** Bug 240173 has been marked as a duplicate of this bug. ***

Comment 9 Jesse Keating 2007-05-15 17:58:47 UTC
Whats the quick workaround for users to get past this to get to the updates (is
there one?)

Comment 10 Jeremy Katz 2007-05-15 18:07:53 UTC
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.

Comment 11 Andrew 2007-05-15 20:36:46 UTC
(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...??

Comment 12 Jeremy Katz 2007-05-15 20:39:20 UTC
*** Bug 240227 has been marked as a duplicate of this bug. ***

Comment 13 Jeremy Katz 2007-05-15 20:39:33 UTC
*** Bug 240219 has been marked as a duplicate of this bug. ***

Comment 14 Kai Engert (:kaie) (inactive account) 2007-05-15 20:42:01 UTC
(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.


Comment 15 Robin Humble 2007-05-16 13:01:09 UTC
'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.

Comment 16 Will Woods 2007-05-17 20:24:05 UTC
I believe this is fixed by yum-metadata-parser-1.1.0-2.fc7, which is now
available in rawhide.


Note You need to log in before you can comment on or make changes to this bug.