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