Tracker bug for all packages that need to be fixed before python 2.6 leaves
I had some issues with lxml and a couple of others, which I think is related to distutils. It seems the new one calls test.test_support (which seems to be a valid python module), but lxml and at least one other package come with a test.py (which then seems to take precedence in the namespace) and the installation comes tumbling down.
The deprecation warnings are also a bit irritating, since pycrypto (which portage doesn't actually need, but will use if present) uses md5 and sha1. They're both PEP 247 compliant, but hashlib (which is what's supposed to be used instead of md5 and sha1) isn't, so it's not a simple patch. The upstream bug is at: https://bugs.launchpad.net/pycrypto/+bug/269429.
I'll start posting full bugs and patches once I've had a crack at fixing them...
(In reply to comment #1)
> I'll start posting full bugs and patches once I've had a crack at fixing
Thanks, your help is appreciated :-]
* Starting Python Updater from 2.5 to 2.6 :
* Adding to list: =dev-python/gdata-1.0.8
* Adding to list: =dev-python/numeric-24.2-r6
* Adding to list: =dev-python/pyrex-0.9.8.5
* Adding to list: =dev-python/pycairo-1.4.12
* Adding to list: =x11-libs/vte-0.16.14
* Adding to list: =sys-apps/file-4.26
All of these packages, for me, all fail with attempting to write to the live filesystem during install phase. Except for vte - vte always shows up in python-updater's output even though it successfully installs.
(In reply to comment #3)
> Except for vte - vte always shows up in
> python-updater's output even though it successfully installs.
vte is in python-updater's manual list, use -dmanual to disable manual packages from being reinstalled. I'll have a look at the other packages now.
All of these fail to merge on my system using python-2.6 because of access violations during the installation phase:
Should I disable the sandbox as a workaround, is this a bug or is there something I've missed which will make me look like an idiot?
Please ignore my previous comment.
All I had to do was a little eselect magic and the access violations disappeared.
I'm deeply sorry for spamming and will report if I find any real breakage.
Don't disable the sandbox, that should be an absolutely last resort.
I found this a couple of times too, directly after the install. Could you please try running "eselect python list" to get a list of the python environments you have installed, and remember the number in front of python-2.6 (in my example I'll use 2), and then run "eselect python set 2". I've found that this generally made the access violation issues and a few other issues go away. I haven't tracked down exactly why it helps, but I think it's some crossed wires when the installer tries not to update symlinks...
ACCESS VIOLATION also with
Please add depends on 240188 and 240149. The latter contains an explanation for the reason the bad symlinks cause distutils-based packages to fail to build, and a workaround to fix those packages without disabling sandboxing. It does not yet have any info on why the symlinks are created improperly, tho.
I was unable to manually install zopeinterface 3.0.1 into Python 2.6. However, 3.0.3 manually installed fine. So it appears the problem has already been fixed upstream and we just need a version bump. There's already a bug requesting a version bump of net-zope/zopeinterface (#191250); someone please add it as a dependency of this bug.
Well, zopeinterface 3.0.1-r1 did install.
Rafal, I agree that ZopeInterface 3.0.1-r1 does work with Python 2.6-r2. I must have done something wrong before. Sorry for the noise.
sci-libs/scipy does not compile, see bug #245100
dev-python/pywebkitgtk-1.0.2 doesn't merge either.
Python 2.6 has been unmasked.
exaile-0.2.x works but throws warnings due to use of "import md5" instead of hashlib.
There's a 0.3-rc in the tree but it's not even nearly feature-complete and so no real replacement for the stable versions.
Want me to file a bug or are warnings not "enough"?
(In reply to comment #16)
> Want me to file a bug or are warnings not "enough"?
You can file such bugs and make them block this bug, but they won't block stabilization of Python 2.6.*.
W00t! Thanks everyone who worked on this.