On Mon, 10 May 2010, Cristina Aiftimiei wrote: > Hi, > > :-( What version and arch of SL4 you are trying on? > > # rm -f /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc > # yum clean all > Loading "kernel-module" plugin > Cleaning up Everything > 0 headers removed > 0 packages removed > 51 metadata files removed > 0 cache files removed > 1 cache files removed > # yum update > Loading "kernel-module" plugin > Setting up Update Process > Setting up repositories > [...] > 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:29772): GLib-CRITICAL **: file gtimer.c: line 106 (g_timer_stop): > assertion `timer != NULL' failed > > (process:29772): 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/yum/sqlitecache.py", line 40, in > getPrimary > self.repoid)) > TypeError: Can not create index on requires table: near "NOT": syntax error > > it's true the pyc was recreated: > # ll /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc > -rw-r--r-- 1 root root 2496 May 10 16:40 > /usr/lib/python2.3/site-packages/yum/sqlitecache.pyc > > Cris > > > Valery Mitsyn wrote: >> 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