Summary: | dev-python/pypy USE=sandbox - Fatal error during initialization: out of memory | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mehrunes Dagon <Me1runes.dagon> |
Component: | New packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | alicef, mgorny |
Priority: | Normal | Keywords: | PMASKED |
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info dev-python/pypy
log of successful build/installation log of failed installation incomplete(!) patch for improving sandbox support |
Description
Mehrunes Dagon
2012-08-01 15:41:07 UTC
Created attachment 319992 [details]
log of successful build/installation
Created attachment 319994 [details]
log of failed installation
Comment on attachment 319994 [details]
log of failed installation
Bug tracker does not let me attach plain text of size 967375 or 639352, so I compressed the files to .zip
Created attachment 320042 [details, diff]
incomplete(!) patch for improving sandbox support
A pypy built with USE=sandbox does not run on its own: it needs to talk to a helper process for any system interaction, including starting up (because this involves looking at one or more env vars, and access to the env is funneled through that helper process). The build fails because the ebuild needs to run the built pypy to build some grammar pickles and the like.
I think a more useful thing for USE=sandbox to do is build an additional pypy executable exclusively sandboxing. We should build that one with more restrictive build flags, as upstream is "more confident" in a sandboxed pypy without JIT, and linking to sqlite and friends defeats the sandboxing. And we can build the sandboxed pypy with the regular pypy we just built for speed. The attached patch does that, and some additional improvements. Note this is incomplete (it won't even work for you unless you edit back out the additional epatch).
However, I'm not entirely sure USE=sandbox is of any use right now, as the only implementation of a sandbox control process I know of sits in the pypy source tree, and needs some undefined (substantial) subset of that source tree to function. If people need to check out a matching version of pypy to actually use a USE=sandbox pypy I think it makes more sense to have them build the executable too.
AFAIR additional sandboxed binary is what other distros do. However, I'm not sure if we really want or need that. In any case, someone needs to provide a complete, well-tested patch. I've masked the flag via package.use.mask. In any case, this is not something we're going to support, I guess. |