Summary: | dev-python/guppy doesn't work with Python 2.7 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alec Meyers <alecm_88> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 292401 | ||
Attachments: |
build.log
ebuild patch |
Description
Alec Meyers
2011-02-10 20:35:41 UTC
Any chance of the build log ? But it seems to be a bug in guppy - _PyLong_AsScaledDouble, as the name suggests, is private API, that was removed in python 2.7. Created attachment 262085 [details] build.log Here you go. After some googling, I looks like they fixed it in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/guppy/+bug/685127 I haven't had a chance to try it yet, though. That patch is quite amusing: to fix a breakage caused by removal of a private API element, upstream used *another* private API element. Most relevant seems to be the dev input here: http://bugs.python.org/issue5576. Created attachment 294575 [details, diff]
ebuild patch
fixed. The patch above lead to discerning that guppy is calling on the old
_PyLong_AsScaledDouble replaced by that patch long implemented in python 2.7
Fixed with rev bump. Thanks, Ian. (In reply to comment #4 and comment #5) This change breaks support for Python <2.7. Proper fixes from upstream: http://guppy-pe.svn.sourceforge.net/viewvc/guppy-pe?view=revision&revision=87 http://guppy-pe.svn.sourceforge.net/viewvc/guppy-pe?view=revision&revision=88 http://guppy-pe.svn.sourceforge.net/viewvc/guppy-pe?view=revision&revision=90 I don't know why but pythons 2.5 2.6 don't work but my patch wasn't quite right anyway. src_prepare() { if [ $(eselect python show) == "python2.7" ]; then sed -e 's:_PyLong_AsScaledDouble:_PyLong_Frexp:' -i src/sets/bitset.c || die fi } or something equivalent I think should do. I can't get to use the more conventional python_get_version but this amounts to the same thing. It seems it should also be adjusted to it depending on python2.7 alone because pythons 2.5 2.6 don't work emerging with them selected as system python version. Without this change it will work on NO python versions. The package emerges ok but attempting the import in the opening comment it only effectively imports with python2.7, I don't know why. I'm not sure what to do with those links in the previous comment. They're related but perhaps someone can turn them into a patch or such I made this sed thing apply only for 2.7, so bug is fixed now. |