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