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