Description of problem: Some of our repos (arbitrary as far I can tell) are throwing the error when they try and sync. Version-Release number of selected component (if applicable): pulp-1.1.10-1.el6.noarch How reproducible: Always Steps to Reproduce: 1. Run a sync on the repo 2. Check /var/log/pulp/pulp.log 3. Actual results: Prints a traceback: 2012-06-21 10:02:04,256 15289:140653122021120: pulp.server.tasking.task:ERROR: task:472 Task failed: Task 2d272b05-bb13-11e1-b915-00505686001a: _sync(sles-11.1-x86_64-sdk-updates, synchronizer=<pulp.server.a pi.synchronizers.YumSynchronizer object at 0x7fec5c9dcd50>, skip=SON([]), progress_callback=<bound method RepoSyncTask.progress_callback of <pulp.server.api.repo_sync_task.RepoSyncTask object at 0x7fec5c9dcd 10>>) Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/pulp/server/tasking/task.py", line 418, in run result = self.callable(*self.args, **self.kwargs) File "/usr/lib/python2.6/site-packages/pulp/server/api/repo_sync.py", line 283, in _sync progress_callback, synchronizer, max_speed, threads) File "/usr/lib/python2.6/site-packages/pulp/server/api/repo_sync.py", line 373, in fetch_content added_packages = synchronizer.process_packages_from_source(repo_dir, repo_id, skip_dict, progress_callback) File "/usr/lib/python2.6/site-packages/pulp/server/api/synchronizers.py", line 215, in process_packages_from_source added_packages = self.add_packages_from_dir(dir, repo_id, skip_dict) File "/usr/lib/python2.6/site-packages/pulp/server/api/synchronizers.py", line 235, in add_packages_from_dir unfiltered_pkglist = pulp.server.util.get_repo_packages(dir) File "/usr/lib/python2.6/site-packages/pulp/server/util.py", line 328, in get_repo_packages sack.populate(r, 'metadata', None, 0) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 165, in populate if self._check_db_version(repo, mydbtype): File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 223, in _check_db_version return repo._check_db_version(mdtype) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1256, in _check_db_version repoXML = self.repoXML File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1455, in <lambda> repoXML = property(fget=lambda self: self._getRepoXML(), File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1447, in _getRepoXML self._loadRepoXML(text=self) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1437, in _loadRepoXML return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes()) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1412, in _groupLoadRepoXML if self._commonLoadRepoXML(text): File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1230, in _commonLoadRepoXML result = self._getFileRepoXML(local, text) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1008, in _getFileRepoXML size=102400) # setting max size as 100K File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 830, in _getFile size=size File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 408, in urlgrab return self._mirror_try(func, url, kw) File "/usr/lib/python2.6/site-packages/urlgrabber/mirror.py", line 394, in _mirror_try return func_ref( *(fullurl,), **kwargs ) File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 985, in urlgrab return self._retry(opts, retryfunc, url, filename) File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 886, in _retry r = apply(func, (opts,) + args, {}) File "/usr/lib/python2.6/site-packages/urlgrabber/grabber.py", line 980, in retryfunc apply(cb_func, (obj, )+cb_args, cb_kwargs) File "/usr/lib/python2.6/site-packages/yum/yumRepo.py", line 1494, in _checkRepoXML repoXML = repoMDObject.RepoMD(self.id, filepath) File "/usr/lib/python2.6/site-packages/yum/repoMDObject.py", line 124, in __init__ self.parse(srcfile) File "/usr/lib/python2.6/site-packages/yum/repoMDObject.py", line 143, in parse for event, elem in parser: File "<string>", line 58, in __iter__ RuntimeError: cannot load dispatch table from pyexpat Expected results: Expected repo to sync Additional info: The server was recently updated to Red Hat Enterprise Linux Server release 6.3 (Santiago). Therefor python also got updated to python-2.6.6-29.el6_2.2.x86_64
I was able to produce the error when trying to sync generic-5-x86_64-pulp Id generic-5-x86_64-pulp Name Generic Repo URL https://mirror2.dontworryaboutit.com/pulp/repos/repos/pulp/pulp/v1/testing/5Server/x86_64/ Feed URL http://repos.fedorapeople.org/repos/pulp/pulp/v1/testing/5Server/x86_64/ Feed Type remote Content Type yum Feed Certs CA:No Cert:No Consumer Certs CA:No Cert:No Architecture x86_64 Sync Schedule 2012-06-21T10:00:00-04:00/P1D Packages 17 Files 0 Distributions None Publish True Clones [u'infra-unstable-generic-5-x86_64-pulp'] Groups None Filters [] Notes {} Preserve Metadata False Checksum Type sha
This bz 814490 may be related. https://bugzilla.redhat.com/show_bug.cgi?id=814490 BZ mentions that an old version of libexpat was being picked up by accident, user removed the old libexpat and the problem was fixed. Please search the server for any instances of libexpat, and remove old versions from ldconfig
(In reply to comment #2) > This bz 814490 may be related. > https://bugzilla.redhat.com/show_bug.cgi?id=814490 > > BZ mentions that an old version of libexpat was being picked up by accident, > user removed the old libexpat and the problem was fixed. > > Please search the server for any instances of libexpat, and remove old > versions from ldconfig This is the only version of libexpat installed on the system. lrwxrwxrwx. 1 root root 17 Jun 20 15:00 /lib64/libexpat.so.1 -> libexpat.so.1.5.2
(In reply to comment #3) > (In reply to comment #2) > > This bz 814490 may be related. > > https://bugzilla.redhat.com/show_bug.cgi?id=814490 > > > > BZ mentions that an old version of libexpat was being picked up by accident, > > user removed the old libexpat and the problem was fixed. > > > > Please search the server for any instances of libexpat, and remove old > > versions from ldconfig > > This is the only version of libexpat installed on the system. > lrwxrwxrwx. 1 root root 17 Jun 20 15:00 /lib64/libexpat.so.1 -> > libexpat.so.1.5.2 It looks like this bug is related to the workaround for pymongo mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=825312 We had to upgrade back to pymongo-2.1.1-1.el6.x86_64. Syncs are working normally again except for packages with a '.' in the name.
The 2.x releases will function correctly with pymongo 2.1 and no longer suffer from the dot in the package name issue. There are no plans for another release in the 1.x stream, so I'm closing this bug out as won't fix.