Summary: | www-client/firefox-15.0.1: virtual embedded python fails to handle libdirs properly (and bundles simplejson) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | josef64, nbowler, nikoli, pastas4, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 393673, 427048 | ||
Attachments: |
correctly support multiarch
build.log 01-proper-multilib-support.patch 02-update-base64.patch |
Description
SpanKY
2012-09-26 05:22:58 UTC
You'll likely find gentoo's virtualenv package has the same problem. If you install dev-python/virtualenv and run "virtualenv myenv" you'll find the same site.py that's causing you pain installed in there. It might make sense to fix up dev-python/virtualenv and then apply the same fix to firefox, but before I can try to do that I'd probably have to build myself an x32 chroot so I can test the result actually works. The "virtualenv embedded business" is a directory with files that get embedded into virtualenv.py (the python module) "in order to support single-file use of virtualenv.py without installing it" (see the contributing section of the virtualenv website). The copying of the host python is what virtualenv is supposed to do: it attempts to build an isolated python environment by copying over the host python and instructing it to only look in its own stdlib directory and the new environment's site-packages, not the system site-packages directory. virtualenv's site.py has diverged from CPython's pretty significantly, but the difference between CPython upstream's and Gentoo's is quite small (the only difference we actually need here is two lib -> lib64 changes). so firefox is also duplicating the system package dev-python/virtualenv instead of depending on it ? nice. x32 stage3 tarballs are already readily available on the mirrors. but really the only fix you need is to use the stuff we have in the python tarball to rewrite lib64 and friends to $(get_libdir). nowhere should any code ever check for "lib64" -- it should check for what the build system has told it to use. Created attachment 335918 [details, diff]
correctly support multiarch
Please test and let us know, thank you
(In reply to comment #3) doesn't apply to 18.0. which ver was i to test ? Created attachment 426636 [details] build.log This is still an issue for firefox 38 and 44. I thought it's because, as mentioned, virtualenv does not have support for multilib as it should. I thus applied the patch in https://github.com/pypa/virtualenv/pull/516 which should properly fix that, but no luck either. I get an error "ImportError: No module named __future__" with or without the patch applied. Here's the build.log file of firefox-44. Created attachment 426638 [details, diff]
01-proper-multilib-support.patch
For reference, this is the patch I used. It's specifically merged against the version of virtualenv that firefox-44 uses (12.0.5).
Created attachment 426640 [details, diff]
02-update-base64.patch
And this is the patch that updates the base64-encoded blob to the result of the previous patch. It is really inconvenient that it has to be done, and it needs to be updated for every single change in site.py, so it will no longer apply even after a minor update to the build system, without redoing it all.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team |