Valery Mitsyn wrote:
> On Mon, 10 May 2010, Cristina Aiftimiei wrote:
>
>> Hi,
>>
>> :-(
>
> What version and arch of SL4 you are trying on?
Scientific Linux SL release 4.8 (Beryllium)
# uname -a
Linux cert-10.pd.infn.it 2.6.18-xen_3.1.0 #1 SMP Thu May 17 05:35:24 EDT
2007 i686 i686 i386 GNU/Linux
Cris
>
>>
>> # 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
|
