Package: python-codespeak-lib
Version: 0.9.0-4
Severity: important
Running as me:
$ python -c 'from py.magic import greenlet'
$ [no problem]
Running as root:
# python -c 'from py.magic import greenlet'
Traceback (most recent call last):
File "<string>", line 1, in ?
File "/usr/lib/python2.4/site-packages/py/initpkg.py", line 182, in
__getattr__
result = self.__package__._resolve(extpy)
File "/usr/lib/python2.4/site-packages/py/initpkg.py", line 68, in _resolve
implmodule = self._loadimpl(fspath[:-3])
File "/usr/lib/python2.4/site-packages/py/initpkg.py", line 98, in _loadimpl
return __import__(modpath, None, None, ['__doc__'])
File "/usr/lib/python2.4/site-packages/py/magic/greenlet.py", line 10, in ?
greenlet = path._getpymodule().greenlet
File "/usr/lib/python2.4/site-packages/py/path/local/local.py", line 441,
in _getpymodule
mod = make_module_from_c(self)
File "/usr/lib/python2.4/site-packages/py/misc/buildcmodule.py", line 69,
in make_module_from_c
raise RuntimeError("cannot compile %s: %s\n%s" % (cfile, e,
RuntimeError: cannot compile
/usr/lib/python2.4/site-packages/py/c-extension/greenlet/greenlet.c: error:
command 'gcc' failed with exit status 1
gcc: /usr/lib/python2.4/site-packages/py/c-extension/greenlet/greenlet.c: No
such file or directory
gcc: no input files
Running as me again:
$ python -c 'from py.magic import greenlet'
Traceback (most recent call last):
File "<string>", line 1, in ?
File "/usr/lib/python2.4/site-packages/py/initpkg.py", line 182, in
__getattr__
[etc...]
What's happening is that the complicated machinery in
py/misc/buildcmodule.py is trying to auto-build the C-language
extension. It decides decides to delete the perfectly fine
/usr/lib/python2.4/site-packages/py/c-extension/greenlet/greenlet.so
provided in the package and recompile it from sources which aren't
there. (Obviously it doesn't work when run as a normal user; it notices
the file is still there and just uses it as-is.) It leaves me without
greenlets.so, and in its place, an empty directory called (wait for it...):
/usr/lib/python2.4/site-packages/py/c-extension//greenlet/build/
temp.linux-i686-2.4/usr/lib/python2.4/site-packages/py/c-extension/greenlet/
Now greenlets can't be used by anyone at all. I claim that this is
unsatisfactory.
I've hacked my version by commenting out the lines
##if lib.check():
## try:
## lib.remove()
## except EnvironmentError:
## pass # XXX we just use the existing version, bah
of buildcmodule.py and now it works; this seems OK because packages
probably shouldn't be capriciously messing with themselves inside /usr
anyway.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.23.15 (PREEMPT)
Locale: LANG=C, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages python-codespeak-lib depends on:
ii libc6 2.7-6 GNU C Library: Shared libraries
ii python 2.4.4-6 An interactive high-level object-o
ii python-central 0.5.15-0.1 register and build utility for Pyt
Versions of packages python-codespeak-lib recommends:
ii python-docutils 0.4-5 Utilities for the documentation of
pn python-tkinter <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
