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 >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >