Valery Mitsyn wrote: > On Mon, 10 May 2010, Cristina Aiftimiei wrote: > >> Hi, >> >> :-( > > What version and arch of SL4 you are trying on? Scientific Linux SL release 4.8 (Beryllium) # uname -a Linux cert-10.pd.infn.it 2.6.18-xen_3.1.0 #1 SMP Thu May 17 05:35:24 EDT 2007 i686 i686 i386 GNU/Linux Cris > >> >> # 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >