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