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