Summary: | dev-python/requests-2.5.0-r1 - sandbox violation by /usr/bin/pypy setup.py build in: mkdir /usr/lib64/pypy/site-packages/cryptography/hazmat/bindings/__pycache__ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | bay <alex3255> |
Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
bay
2014-12-24 09:28:11 UTC
Created attachment 392308 [details]
build.log
this package poses major problems.
~/cvsPortage/gentoo-x86/dev-python/requests $ PYTHON_TARGETS=pypy ebuild requests-2.5.0-r1.ebuild clean install
yields
>>> Completed installing requests-2.5.0-r1 into /mnt/gen2/TmpDir/portage/dev-python/requests-2.5.0-r1/image/
since I have cryptography emerged.
The log is showing the build is trying to emerge cryptography under pypy, however there is no sign of cryptography as a dep in the ebuild, nor dev-python/pyopenssl.
/var/tmp/portage/dev-python/requests-2.5.0-r1/work/requests-2.5.0/requests/packages/urllib3/contrib/pyopenssl.py
says it's trying to import form pyopenssl installed in the system. pyopenssl pulls in cryptography. It appears the build is building the bundled urllib3 which has its own set of deps, none of which are set in the ebuild. Just to confound further, ebuilds of our urllib3 don't have these deps either, so just unbundling the urllib3 it seems would still leave gaps in required deps for this build.
It's an optional runtime dependency. # Attempt to enable urllib3's SNI support, if possible try: from .packages.urllib3.contrib import pyopenssl pyopenssl.inject_into_urllib3() except ImportError: pass It's probably just broken because dev-python/cryptography needs to be rebuilt due to some timestamp issue or a change in pypy's cffi package. Can you please try that rebuilding dev-python/cryptography? Requests compiled successfully after rebuild dev-python/cryptography (In reply to Mike Gilbert from comment #3) > It's an optional runtime dependency. > > # Attempt to enable urllib3's SNI support, if possible > try: > from .packages.urllib3.contrib import pyopenssl > pyopenssl.inject_into_urllib3() > except ImportError: > pass > > It's probably just broken because dev-python/cryptography needs to be > rebuilt due to some timestamp issue or a change in pypy's cffi package. > > Can you please try that rebuilding dev-python/cryptography? yes we've seen this before. the ebuild lacking cryptography as a dep won't auto rebuild it to make things work. I don't know what would be a comprehensive fix here. The optional part here seems a contradiction though. How optional is it if it breaks a build that doesn't stipulate the option? (In reply to Ian Delaney from comment #5) > yes we've seen this before. the ebuild lacking cryptography as a dep won't > auto rebuild it to make things work. I don't know what would be a > comprehensive fix here. The optional part here seems a contradiction though. > How optional is it if it breaks a build that doesn't stipulate the option? If dev-python/pyopenssl is installed, and dev-python/cryptography is working, requests will have enhanced SSL support. If dev-python/pyopenssl is not installed, requests will function just fine, albeit without the enhanced SSL support. This is the 'optional' part. If dev-python/pyopenssl is installed, and the installed copy dev-python/cryptography is broken, we will encounter the issue presented in this bug report. The real question here is how the cffi-based modules installed by dev-python/cryptography got broken/out-of-date. Given that this problem seems specific to pypy in this bug report, it probably has something to do with the bundled copy of cffi in dev-python/pypy. dev-python/cryptography has the following slot-operator dep to force rebuilds whenever dev-python/cffi is updated: $(python_gen_cond_dep '>=dev-python/cffi-0.8:=[${PYTHON_USEDEP}]' 'python*') For pypy, this slot-operator dep does nothing since cffi is bundled. We would need a slot-operator dep like || ( dev-python/pypy:= dev-python/pypy-bin:= ). However, slot-operators don't really work with || deps, and our subslot on pypy is too broad in any case. I think the only reasonable to really resolve this would be to unbundle cffi from pypy. But I don't see that happening any time soon. I think this is a CANTFIX. |