Description of problem: Crashes while resolving dependencies for glibc Version-Release number of selected component (if applicable): How reproducible: Yes Steps to Reproduce: 1. Start "pup" 2. Include current "glibc" as one of the packages to be updated 3. Start updates Actual results: Crash reported during "resolving dependencies" step Expected results: Not a crash? Additional info:
Created attachment 159512 [details] Crash log
"rpm -qf /usr/bin/pup" returns pirut-1.3.7-1.fc7
What's the output of 'rpm -q --qf "%{NAME}.%{ARCH}\n" glibc'?
"glibc.i686" twice. When I run "rpm -q glibc" two packages are listed: glibc.2.5-10.fc6 and glibc.2.6-3
This stack trace may help you. Component: pirut Summary: TB27ac5246 <string>:68:__iter__:SyntaxError: no element found: line 1, column 0 Traceback (most recent call last): File "/usr/sbin/pup", line 650, in <module> main() File "/usr/sbin/pup", line 643, in main pup = PackageUpdater(not options.autoapply, options.config) File "/usr/sbin/pup", line 88, in __init__ GraphicalYumBase.__init__(self, False, config) File "/usr/lib/python2.5/site-packages/pirut/__init__.py", line 124, in __init__ self.reset() File "/usr/lib/python2.5/site-packages/pirut/__init__.py", line 226, in reset self.doGroupSetup() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 426, in doGroupSetup return self._getGroups() File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 474, in _getGroups self._comps.add(groupfile) File "/usr/lib/python2.5/site-packages/yum/comps.py", line 349, in add for event, elem in parser: File "<string>", line 68, in __iter__ SyntaxError: no element found: line 1, column 0 Local variables in innermost frame: p: <XMLParser object at 0x9a01350> self: <iterparse object at 0x9a1dbec> b: <TreeBuilder object at 0x9a04d78> data: events: []
If you do 'rpm -e --justdb glibc.2.5-10.fc6' and then try again, does it work better?
Yes, that takes care of the problem. Could that be included in some manner so that the extra command doesn't need to be entered manually?
The problem is that you had an update which only partially completed at some point. And there's no way to programatically know that it's the case and that it's not something else going on, therefore, manual intervention is occasionally necessary.
Understood. Would it be possible to avoid the crash listed in the first attachment then? The "rpm -e" resolves the package conflict for me but the underlying problem may still be there. The crash listed in comment #5 is different; likely a separate issue.