* Andreas Beckmann <[email protected]>, 2013-04-03, 12:17:
Traceback (most recent call last): File "/usr/bin/py3compile", line 292, in <module> main() File "/usr/bin/py3compile", line 272, in main options.force, options.optimize, e_patterns) File "/usr/bin/py3compile", line 158, in compile cfn = interpreter.cache_file(fn, version) File "/usr/share/python3/debpython/interpreter.py", line 212, in cache_file (fname[:-3], self.magic_tag(version), last_char)) File "/usr/share/python3/debpython/interpreter.py", line 246, in magic_tag return self._execute('import imp; print(imp.get_tag())', version) File "/usr/share/python3/debpython/interpreter.py", line 359, in _execute raise Exception('{} failed with status code {}'.format(command, output['returncode'])) Exception: python3.2 -c 'import imp; print(imp.get_tag())' failed with status code 134 dpkg: error processing python3-pyinotify (--configure): subprocess installed post-installation script returned error exit status 1 Setting up python3.2-minimal (3.2.3-7) ... Setting up python3.2 (3.2.3-7) ... Errors were encountered while processing: python3-pyinotifypython3.2 seems to be used before it gets configured, that may indicate a bug in another python package (e.g. incorrect dependencies).
It was my theory as well that the problem is that py3compile calls /usr/bin/python3.2 when python3.2(-minimal) in the middle of the upgrade. But on a second thought: - Both python3.2-minimal and python3.2 seem to have their dependencies satisfied, as they could be configured immediately after failure. - I can't see anything vital in their maintainer scripts that would explain such failure.
-- Jakub Wilk -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
