Hi, :-( # 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> > -- Cristina Aiftimiei - EMI Project Ist. Naz. di Fisica Nucleare - Padova Address: via F. Marzolo, 8 - 35131 Padova - ITALY Phone: +39.049.8275905 Mobile: +39.3460230488