SCIENTIFIC-LINUX-DEVEL Archives

May 2010

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Peter Slížik <[log in to unmask]>
Reply To:
Peter Slížik <[log in to unmask]>
Date:
Tue, 11 May 2010 13:45:24 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
Hi,

I apologize for not taking part in the discussion for some time; I've
been quite busy during the last few days. There's some additional info
I believe might help people with locating the problem:

As I said in my first e-mail, the problem appeared when the jpackage
community upgraded to a newer version of createrepo. After they solved
the SHA1-related problem, the familiar "sourcerpm" problem appeared.
Machines, on which I didn't run "yum clean all" kept their old yum
metadata and the update process works there without any problems. On
the other hand, machines on which "yum clean all" was called, rebuilt
their yum metadata anew, switching to the newer version locally.

Here is the contents of my /var/cache/yum/jpackage-* directory before
"yum clean all":

  http://petersbytes.net/tmp/jpackage5-generic-before.tar.gz
  http://petersbytes.net/tmp/jpackage5-generic-nonfree-before.tar.gz

The same directory after "yum clean all" && "yum update":

  http://petersbytes.net/tmp/jpackage5-generic-after.tar.gz
  http://petersbytes.net/tmp/jpackage5-generic-nonfree-after.tar.gz

For those, who are interested only in repomd.xml files:

  http://petersbytes.net/tmp/repomd-before.xml
  http://petersbytes.net/tmp/repomd-nonfree-before.xml
  http://petersbytes.net/tmp/repomd-after.xml
  http://petersbytes.net/tmp/repomd-nonfree-after.xml

As someone has already pointed out, making a backup of the
/var/cache/yum/jpackage5-* directories and restoring them after "yum
clean all" prevents the problems.

By the way, I've noticed yet another problem. If you have gLite
software updated, yum call wrong mdparser.py (from /amga/):

  File "/opt/glite/lib/python2.3/site-packages/amga/mdparser.py", line
73, in __getitem__
      # Check whether it is in our parser dictionary
  KeyError: 'sourcerpm'

If you don't have gLite installed, the correct mdparser.py is called.
However, the sourcerpm problem is still there. I'm afraid this will
bother us after the original problem is mitigated.

I hope I will have some time to look into that more deeply soon.

Best regards,

Peter

ATOM RSS1 RSS2