Hi Cristina, my fault. if you have already: - yum-metadata-parser installed - moved the original sqlitecache.py* to sqlitecache.py*_ - copied new sqlitecache.py* to /usr/lib/python2.3/site-packages/yum/ next do rm -f usr/lib/python2.3/site-packages/yum/sqlitecache.pyc thist file will be recompiled on the next yum run. And finally try to run: yum clean all ; yum update On Sun, 9 May 2010, Cristina Aiftimiei wrote: > Hi, > > just tried all the steps...:-( > but the error changed: > # rpm -Uvh > http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm > Retrieving > http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm > warning: /var/tmp/rpm-xfer.rv5nfu: V3 DSA signature: NOKEY, key ID 443e1821 > Preparing... ########################################### > [100%] > 1:yum-metadata-parser ########################################### [100%] > # mv /usr/lib/python2.3/site-packages/yum/sqlitecache.py > /usr/lib/python2.3/site-packages/yum/sqlitecache.py_ > # mv /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc > /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc_ > # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.py > /usr/lib/python2.3/site-packages/yum/sqlitecache.py > # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyc > /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc > # /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyo > /usr/lib/python2.3/site-packages/yum/sqlitecache.pyo > # yum clean all > Loading "kernel-module" plugin > Cleaning up Everything > 0 headers removed > 0 packages removed > 63 metadata files removed > 0 cache files removed > 13 cache files removed > > # yum update > ..... > jpackage5_generic_free 100% |=========================| 2.3 kB 00:00 > Reading repository metadata in from local files > primary.xml.gz 100% |=========================| 2.3 kB 00:00 > > (process:11551): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): > assertion `timer != NULL' failed > > (process:11551): GLib-CRITICAL **: file gtimer.c: line 88 (g_timer_destroy): > assertion `timer != NULL' failed > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in ? > yummain.main(sys.argv[1:]) > File "/usr/share/yum-cli/yummain.py", line 97, in main > result, resultmsgs = do() > File "/usr/share/yum-cli/cli.py", line 477, in doCommands > return self.updatePkgs() > File "/usr/share/yum-cli/cli.py", line 955, in updatePkgs > self.doRepoSetup() > File "/usr/share/yum-cli/cli.py", line 75, in doRepoSetup > self.doSackSetup(thisrepo=thisrepo) > File "__init__.py", line 260, in doSackSetup > File "repos.py", line 287, in populateSack > File "/usr/lib/python2.3/site-packages/sqlitecachec.py", line 40, in > getPrimary > self.repoid)) > TypeError: Can not create index on requires table: near "NOT": syntax error > > # rpm -qa|grep yum > yum-2.4.3-10.SL > yum-metadata-parser-1.0-8.el4.centos > yum-conf-48-1.SL > > Cris > > > > Valery Mitsyn wrote: >> On Sun, 9 May 2010, Valery Mitsyn wrote: >> >>> Hi, >>> >>> probably this is not very useful for everybody, but >>> it works in this way. >>> 1) install yum-metadata-parser from the CentOS: >>> rpm -Uvh \ >>> http://ftp.chg.ru/pub/Linux/CentOS/4.8/os/i386/CentOS/RPMS/yum-metadata-parser-1.0-8.el4.centos.i386.rpm >>> 2) move away two files: >>> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.py \ >>> /usr/lib/python2.3/site-packages/yum/sqlitecache.py_ >>> mv /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc \ >>> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc_ >> >> 2a) copy 3 files: >> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.py \ >> /usr/lib/python2.3/site-packages/yum/sqlitecache.py >> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyc \ >> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc >> /bin/cp -p /usr/lib/python2.3/site-packages/sqlitecachec.pyo \ >> /usr/lib/python2.3/site-packages/yum/sqlitecache.pyo >> >>> 3) now yum should works with repos: >>> http://mirrors.dotsrc.org/jpackage/5.0/generic/free/ >>> http://mirrors.dotsrc.org/jpackage/5.0/generic/non-free/ >>> yum clean all >>> yum -y --tsflags=test update >>> >>> On Fri, 7 May 2010, Valery Mitsyn wrote: >>> >>>> On Fri, 7 May 2010, Troy Dawson wrote: >>>> >>>>> Hi, >>>>> Sorry, but we are concentrating on SL 5.5 right now. >>>>> The one thing I did find before being distracted was that CentOS did >>>>> several things into their yum that isn't in the standard yum. But you >>>>> didn't give the source rpm for them, and I never got enough time to find >>>>> CentOS's source rpm. so I'm not sure exactly what they did. >>>> >>>> Could it be in the yum-metadata-parser rpm which is in >>>> require list of yum in centos? >>>> One can test this case by installing yum-metadata-parser >>>> from centos repo to SL4X. >>>> >>>>> Their changenotes say something along the lines >>>>> "put in the usual change" >>>>> >>>>> Troy >>>>> >>>>> Cristina Aiftimiei wrote: >>>>>> Hi, >>>>>> >>>>>> is there any news? >>>>>> Sorry to disturb - but we are relly interested in having a solution. >>>>>> >>>>>> Thank you, >>>>>> Cristina >>>>>> >>>>>> >>>>>> Troy Dawson wrote: >>>>>>> Peter Sl??ik wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I believe this list is the right place to report the following yum >>>>>>>> bug, which keeps causing wrinkles to the EGEE community. Apologies >>>>>>>> for >>>>>>>> the length, my intention is to provide as many details as possible. >>>>>>>> >>>>>>>> The problems started approx. on April 6, when people from the >>>>>>>> jpackage >>>>>>>> project changed the digest of their repo's digital signature from SHA >>>>>>>> to SHA1. (I think they just updated their createrepo package, because >>>>>>>> the "repomd.xml" files on my machines contained the text >>>>>>>> "<database_version>9</database_version>" before and >>>>>>>> "<database_version>10</database_version>" after the problem was first >>>>>>>> reported.) Following the change, SL4-based installations refused to >>>>>>>> cooperate, yielding the "[Errno 256] No more mirrors to try" error >>>>>>>> message upon "yum update". (SL5-based machines worked fine.) The >>>>>>>> issue >>>>>>>> was discussed on the LCG-ROLLOUT list and the discussion later moved >>>>>>>> to jpackage-discuss. People from the jpackage project then decided to >>>>>>>> return to the old SHA digest. >>>>>>>> >>>>>>>> After going back to SHA, a strange thing happened. For users who did >>>>>>>> not empty their metadata cache inbetween, the "yum update" command >>>>>>>> worked fine. But if they happened to either had run "yum clean all" >>>>>>>> (as was suggested by somebody on the list) or if they started with a >>>>>>>> fresh SL installation, "yum update" failed with the following error: >>>>>>>> >>>>>>>> File "__init__.py", line 260, in doSackSetup >>>>>>>> File "repos.py", line 287, in populateSack >>>>>>>> File "sqlitecache.py", line 96, in getPrimary >>>>>>>> File "sqlitecache.py", line 89, in _getbase >>>>>>>> File "sqlitecache.py", line 359, in updateSqliteCache >>>>>>>> File "sqlitecache.py", line 251, in addPrimary >>>>>>>> File "sqlitecache.py", line 197, in insertHash >>>>>>>> File "sqlitecache.py", line 449, in values >>>>>>>> File "sqlitecache.py", line 441, in __getitem__ >>>>>>>> File "mdparser.py", line 73, in __getitem__ >>>>>>>> KeyError: 'sourcerpm' >>>>>>>> >>>>>>>> >>>>>>>> Steps to reproduce the problem: >>>>>>>> >>>>>>>> 1. Create two virtual machines. Install CentOS 4.8 and Scientific >>>>>>>> Linux 4.8 on them. >>>>>>>> 2. Run "yum update" on both. This is just to reduce the number of >>>>>>>> yum's outputs later. >>>>>>>> 3. Download the jpackage repository to /etc/yum.repos.d/ >>>>>>>> http://grid-deployment.web.cern.ch/grid-deployment/glite/repos/3.1/jpackage.repo >>>>>>>> 4. Run "yum update". This will succeed on CentOS 4.8 and fail on SL >>>>>>>> 4.8. >>>>>>>> >>>>>>>> >>>>>>>> After some investigation, I found a strange thing. Though "yum >>>>>>>> --version" reports "2.4.3" on both platforms, the actual >>>>>>>> implementations differ. Apart from the obvious configuration stuff >>>>>>>> (e.g. cron.d files, /etc/init.d scripts) they differ also in the way >>>>>>>> they handle cache. The following files are actually different: >>>>>>>> >>>>>>>> config.py >>>>>>>> depsolve.py >>>>>>>> repos.py >>>>>>>> >>>>>>>> The CentOS implementation has also one additional file: >>>>>>>> >>>>>>>> storagefactory.py. >>>>>>>> >>>>>>>> Unfortunatelly, I wasn't able to find the actual cause of the error. >>>>>>>> >>>>>>>> >>>>>>>> If you need to compare the files without installing the whole >>>>>>>> distributions, please feel free to download the following archives: >>>>>>>> >>>>>>>> http://petersbytes.net/tmp/yum-2.4.3-4.el4.centos.noarch.rpm >>>>>>>> http://petersbytes.net/tmp/yum-2.4.3-10.SL.noarch.rpm >>>>>>>> >>>>>>>> There are two possible conclusions: either the CentOS developers >>>>>>>> messed with the implementation without increasing the version number, >>>>>>>> or the Upstream Vendor issued a new release without increasing the >>>>>>>> version number and Scientific Linux did not catch with them. Either >>>>>>>> way, I think the problem needs to be patched in SL, because I don't >>>>>>>> think that jpackage people will fix the problem on their part - >>>>>>>> they're testing their stuff on CentOS and everything works fine for >>>>>>>> them. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Peter Slizik >>>>>>> Hi Peter, >>>>>>> Thanks for the information and the detailed analysis. >>>>>>> I'm looking into this. >>>>>>> I am pretty sure that we did not take any files out of yum 2.4.3. We >>>>>>> changed a file or two, but never took any out. I'll look through >>>>>>> CentOS's yum rpm and see what the difference is and let you know if a >>>>>>> little bit. >>>>>>> Thanks >>>>>>> Troy >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -- Best regards, Valery Mitsyn