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
|
