There is no stable Python 3.3 ebuild around. Python 3.3 is a major step forward for Python 3 adoption and I'd like to be able to refer to a stable one. I would hope that 3.3.2 is stable packaged already. If I can help somehow to move this forward, please tell me what to do. Reproducible: Always Steps to Reproduce: 1. emerge dev-lang/python:3.3 2. ... 3. Actual Results: Requires to change keywords. Expected Results: Installs Python 3.3 without additional keyword changes.
You could help with the bugs mentioned in the tracker. We probably need at least some of those fixed before going ahead with stabilization. Personally, I'm not really in a hurry to stabilize this, though.
Hmm. Thanks for referencing that other bug. I'm a bit confused that this would block getting Python 3.3 stable? I'm not sure what the policy is on this. I can perfectly use Python 3.3 without those packages - it's not even the ebuild's fault that those packages aren't compatible. I might be missing something why it can't be stabilized then...
The policy is that we don't like to provide users with a python that doesn't work with their packages. But I suppose we could just make sure those packages don't support installation on python-3.3 just yet. What do others think about this?
Do we have any stats on how many packages support various Python versions? If all affected packages were using the new eclasses, we could go for stabilizing py3.3 without enabling it by default. Then it would be only used by users expecting it. However, in the current situation stabilizing it would mean that shortly all users will be having it installed. Then they would eselect it as suggested and python.eclass will want to use that, and you know what goes next... If a fair number of packages supports py3.3, I'm all for it. Just remember to change the default PYTHON_TARGETS altogether with it.
(In reply to Michał Górny from comment #4) > If all affected packages were using the new eclasses, we could go for > stabilizing py3.3 without enabling it by default. Then it would be only used > by users expecting it. Why is that? Couldn't we stabilize 3.3 without putting it in the default PYTHON_TARGETS?
(In reply to Dirkjan Ochtman from comment #5) > (In reply to Michał Górny from comment #4) > > If all affected packages were using the new eclasses, we could go for > > stabilizing py3.3 without enabling it by default. Then it would be only used > > by users expecting it. > > Why is that? Couldn't we stabilize 3.3 without putting it in the default > PYTHON_TARGETS? There is a fair number of packages that have just 'dev-lang/python' in (R)DEPEND. Unless I'm mistaken, this will cause python3.3 to be installed as an upgrade.
In case anyone was wondering, here's a list of packages which have py3.2 enabled but no py3.3. The tool is pretty early so it may have missed something. app-accessibility/accerciser:0 app-editors/retext:0 app-misc/solaar:0 app-portage/overlint:0 app-portage/portpeek:0 dev-libs/libgit2-glib:0 dev-python/alembic:0 dev-python/astng:0 dev-python/backports-lzma:0 dev-python/beaker:0 dev-python/bitstring:0 dev-python/cement:0 dev-python/cherrypy:0 dev-python/cliff:0 dev-python/cmd2:0 dev-python/colorama:0 dev-python/deform:0 dev-python/guessit:0 dev-python/http-parser:0 dev-python/logilab-common:0 dev-python/mako:0 dev-python/mpi4py:0 dev-python/mpmath:0 dev-python/pandas:0 dev-python/progressbar:0 dev-python/pyasn1:0 dev-python/pyenchant:0 dev-python/pyev:0 dev-python/pylint:0 dev-python/pyside:0 dev-python/pysnmp:0 dev-python/pysvn:0 dev-python/python-ldap:0 dev-python/python-musicbrainz-ngs:0 dev-python/pyudev:0 dev-python/pyxattr:0 dev-python/shiboken:0 dev-python/sleekxmpp:0 dev-python/sympy:0 dev-python/testfixtures:0 dev-python/timelib:0 dev-python/tinycss:0 dev-python/translationstring:0 dev-python/twitter:0 dev-python/txAMQP:0 dev-python/ujson:0 dev-python/versiontools:0 dev-python/virtualenv-clone:0 dev-python/xlrd:0 dev-python/yapsy:0 dev-util/catfish:0 dev-util/cdiff:0 dev-util/devhelp:0/3-1 gnome-extra/gnome-packagekit:0 net-irc/irssi-otr:0 net-p2p/torrentinfo:0 sci-chemistry/openbabel-python:0 sys-fs/bedup:0 sys-libs/libselinux:0
We would need this for some accesibility related packages on Gnome 3.8 Regarding its stabilization, if I don't misremember there was a news item explaining people they they should keep using python2 as "python" provider (I am talking about python.eclass, I guess there shouldn't be any problem for new -r1 eclasses)
I'm not sure if we can make 3.3 stable without putting it to PYTHON_TARGETS. I don't think we're going to have USE change issues like ruby has now but I think python.eclass will start using it, and python-r1 deps will not satisfy that.
I always expected 3.3 to appear in default PYTHON_TARGETS when it hit stable.
(In reply to Dirkjan Ochtman from comment #10) > I always expected 3.3 to appear in default PYTHON_TARGETS when it hit stable. How will -r1 eclasses work if 2.7, 3.2 and 3.3 are in PYTHON_TARGETS? I guess they will be used only if package supports them (I mean, a package only with 3.2 in python compat will only try to use 3.2), right? In that case adding it to PYTHON_TARGETS wouldn't be so problematic
(In reply to Pacho Ramos from comment #11) > (In reply to Dirkjan Ochtman from comment #10) > > I always expected 3.3 to appear in default PYTHON_TARGETS when it hit stable. > > How will -r1 eclasses work if 2.7, 3.2 and 3.3 are in PYTHON_TARGETS? I > guess they will be used only if package supports them (I mean, a package > only with 3.2 in python compat will only try to use 3.2), right? In that > case adding it to PYTHON_TARGETS wouldn't be so problematic OK, looks like it will only end up installing modules for 3.3 that is the wanted behavior :)
Running diff between current stable python-3.2 and 3.3.2-r2 shows no additional *DEPEND to be stabilized with it, but I guess some stuff needs to be done at profiles level: I have seen python3_3 is masked in stable profiles, and I guess 3.3 needs to be appended in PYTHON_TARGETS
I think we're ready for this. Any objections?!
(In reply to Dirkjan Ochtman from comment #14) > I think we're ready for this. Any objections?! I agree we should go with it already. I don't see any major blockers. The remaining packages not supporting 3.3 [1] can be taken care of later, I guess. [1]:http://dev.gentoo.org/~mgorny/python-r1/32-to-33.txt
Arches were CCed in all stable bugs blocking this one :)
(In reply to Pacho Ramos from comment #16) > Arches were CCed in all stable bugs blocking this one :) Yeah, let's move on this once those bugs are resolved.
Ok, so the remaining question for me is whether or not we immediately remove python3_2 from PYTHON_TARGETS. If not, how long do we wait to remove it? In any case, the stabilization procedure for arch testers should go something like this: 1. Un-stable mask the python_targets_python3_3 and python_single_targets_python3_3 locally. 2. Add python3_3 to PYTHON_TARGETS. 3. Update keywords on dev-lang/python:3.3 4. Do a newuse world update to reinstall packages with python3_3 support. As for actually committing the stable keyword, it might be best if we can wait for all arch teams to test and commit them all at once to minimize profile updates. If that does not work out, we will need to update profiles/default/linux/$ARCH/13.0/use.stable.mask as each arch is stabilized.
I think stages should have only one dev-lang/python package installed, when 3.3 is stable it should replace 3.2. But support for 3.2 should not be removed from IUSE. Now 18 packages from tree support python3.2, but do not support python3.3, same number have support for python3.3, but do not support python3.2.
Yeah, I think we should remove 3.2 from the default targets at the same time we add 3.3.
(In reply to Mike Gilbert from comment #18) > Ok, so the remaining question for me is whether or not we immediately remove > python3_2 from PYTHON_TARGETS. If not, how long do we wait to remove it? Maybe other option is to wait for next PYTHON_TARGETS change for that (and, then, minimize rebuilds), when is python3.4 or python2.6 removal scheduled? Too far? > > In any case, the stabilization procedure for arch testers should go > something like this: > > 1. Un-stable mask the python_targets_python3_3 and > python_single_targets_python3_3 locally. > > 2. Add python3_3 to PYTHON_TARGETS. > > 3. Update keywords on dev-lang/python:3.3 > > 4. Do a newuse world update to reinstall packages with python3_3 support. > > As for actually committing the stable keyword, it might be best if we can > wait for all arch teams to test and commit them all at once to minimize > profile updates. > for this, maybe would be interesting to CC arches now to let them start testing it > If that does not work out, we will need to update > profiles/default/linux/$ARCH/13.0/use.stable.mask as each arch is stabilized. Maybe this will be better as, from I see in other bug reports, there are important differences between each arch team :/
(In reply to Pacho Ramos from comment #21) > (In reply to Mike Gilbert from comment #18) > > Ok, so the remaining question for me is whether or not we immediately remove > > python3_2 from PYTHON_TARGETS. If not, how long do we wait to remove it? > > Maybe other option is to wait for next PYTHON_TARGETS change for that (and, > then, minimize rebuilds), when is python3.4 or python2.6 removal scheduled? > Too far? IIUC, Mike is talking about the *default* PYTHON_TARGETS here, and you are talking about the complete/full PYTHON_TARGETS. Is that correct?
I am talking about the default PYTHON_TARGETS in profiles -> from my point of view the problem of keeping 3.2 in default now and, later, dropping it will be that people will get another rebuild round, that could be prevented if we keep 3.2 enabled until we need to modify PYTHON_TARGETS other time
Arches: We would like to begin testing of python-3.3 for stabilization. I have outlined a test procedure in comment 18; if you have any questions, please let me know. Please hold off on actually committing any changes to the tree; right now I just want to collect test results and try to catch any problems early.
Um, so this isn't a stabilisation request as yet. dev-lang/python-3.3.2-r2 works fine on HPPA.
(In reply to Jeroen Roovers from comment #25) > Um, so this isn't a stabilisation request as yet. > > dev-lang/python-3.3.2-r2 works fine on HPPA. Also the case on amd64
(In reply to Mike Gilbert from comment #18) [...] > If that does not work out, we will need to update > profiles/default/linux/$ARCH/13.0/use.stable.mask as each arch is stabilized. Looks like we will need to go with this option as some arches will likely keep taking more time to test (I can try to help with x86, but not others :S)
ping for remaining arches :/ Thanks!
Let's proceed with this. Arches: We are going to have to do some profile juggling to make this happen. Here is my suggested procedure: 1. Test/commit stable keyword on dev-lang/python-3.3.2-r2. 2. Disable the stable mask on python_targets_python3_3 and python_single_target_python3_3 use flags by adding entries to an EAPI 5 use.stable.mask file for your arch. For example: default/linux/amd64/13.0/use.stable.mask default/linux/x86/13.0/use.stable.mask For other arches, a suitable file will need to be added. 3. Remove python3_2 / add python3_3 to PYTHON_TARGETS in your arch profile. This can be accomplished by manipulating the USE variable in arch/$arch/make.defaults. For example: arch/amd64/make.defaults: USE="${USE} -python_targets_python3_2 python_targets_python3_3" The profile changes can be consolidated into the base profile once all stable arches have stabilized dev-lang/python:3.3.
amd64 done
Stable for HPPA.
(In reply to Mike Gilbert from comment #29) > 2. Disable the stable mask on python_targets_python3_3 and > python_single_target_python3_3 use flags by adding entries to an EAPI 5 > use.stable.mask file for your arch. Also, make sure the <eapi> file is up to date: # repoman full --- EAPI '2' does not support 'use.stable.mask': '/newaches/gentoo/cvs/gentoo-x86/profiles/default/linux/hppa/13.0/use.stable.mask'
I think the hardend/linux/$ARCH profiles may also need to be updated since we do not have a shared eapi 5 arch profile directory.
I updated the hardend/linux/amd64 profile. + 01 Dec 2013; Mike Gilbert <floppym@gentoo.org> +linux/amd64/use.stable.mask: + Disable stable-mask for python3.3 flags, bug 474128.
I found that PYTHON_SINGLE_TARGET in AMD64 still does not contain python 3.3. Should it be added?
(In reply to Yichao Zhou from comment #35) > I found that PYTHON_SINGLE_TARGET in AMD64 still does not contain python > 3.3. Should it be added? No. The default value for PYTHON_SINGLE_TARGET remains python2_7.
Release engineering has alerted me that we also need to update BOOTSTRAP_USE to avoid breaking stage1. For example, I committed the following for amd64: Index: make.defaults =================================================================== RCS file: /var/cvsroot/gentoo-x86/profiles/arch/amd64/make.defaults,v retrieving revision 1.19 diff -u -r1.19 make.defaults --- make.defaults 30 Nov 2013 13:18:57 -0000 1.19 +++ make.defaults 4 Dec 2013 19:58:02 -0000 @@ -41,6 +41,7 @@ # Pacho Ramos <pacho@gentoo.org> (30 Nov 2013) # Python 3.3 is going to stable, bug #474128 USE="${USE} -python_targets_python3_2 python_targets_python3_3" +BOOTSTRAP_USE="${BOOTSTRAP_USE} -python_targets_python3_2 python_targets_python3_3" # Michał Górny <mgorny@gentoo.org> (03 Sep 2013) # Enable abi_x86_64 for packages that don't have it forced.
(In reply to Mike Gilbert from comment #37) Actually, with remove of the REQUIRED_USE constraint from the python-r1 eclasses, we probably don't need the BOOTSTRAP_USE hack anymore. Releng will confirm.
x86 stable
alpha stable.
sparc stable
arm stabilized and profiles updated according to comment #29.
How about a hardened profile? =/ # grep -rl python3_3 /usr/portage/profiles/{default,hardened}/ /usr/portage/profiles/default/linux/hppa/13.0/use.stable.mask /usr/portage/profiles/default/linux/arm/13.0/use.stable.mask /usr/portage/profiles/default/linux/amd64/13.0/use.stable.mask /usr/portage/profiles/default/linux/x86/13.0/use.stable.mask /usr/portage/profiles/default/linux/alpha/13.0/use.stable.mask /usr/portage/profiles/hardened/linux/amd64/use.stable.mask /usr/portage/profiles/hardened/linux/x86/use.stable.mask
ppc stable
ppc64 stable
ia64 should probably go directly with the newer versions from bug 497758
ia64 stable. Closing.
most arches are broken due to the python_target mismatch. i've unified things back into base/ now: http://sources.gentoo.org/profiles/arch/alpha/make.defaults?r1=1.5&r2=1.6 http://sources.gentoo.org/profiles/arch/amd64/make.defaults?r1=1.20&r2=1.21 http://sources.gentoo.org/profiles/arch/arm64/make.defaults?r1=1.2&r2=1.3 http://sources.gentoo.org/profiles/arch/arm/make.defaults?r1=1.7&r2=1.8 http://sources.gentoo.org/profiles/arch/hppa/make.defaults?r1=1.8&r2=1.9 http://sources.gentoo.org/profiles/arch/x86/make.defaults?r1=1.11&r2=1.12 http://sources.gentoo.org/profiles/base/make.defaults?r1=1.109&r2=1.110
also had to delete the various use masks: http://sources.gentoo.org/profiles/default/linux/alpha/13.0/use.stable.mask?r1=1.2&r2=1.3 http://sources.gentoo.org/profiles/default/linux/amd64/13.0/use.stable.mask?r1=1.3&r2=1.4 http://sources.gentoo.org/profiles/default/linux/arm/13.0/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/default/linux/arm64/13.0/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/default/linux/hppa/13.0/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/default/linux/x86/13.0/use.stable.mask?r1=1.3&r2=1.4 http://sources.gentoo.org/profiles/eapi-5-files/package.use.stable.mask?r1=1.35&r2=1.36 http://sources.gentoo.org/profiles/eapi-5-files/use.stable.mask?r1=1.7&r2=1.8 http://sources.gentoo.org/profiles/features/prefix/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/hardened/linux/amd64/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/hardened/linux/arm/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/hardened/linux/x86/use.stable.mask?r1=1.1&r2=1.2 http://sources.gentoo.org/profiles/prefix/make.defaults?r1=1.7&r2=1.8
(In reply to SpanKY from comment #49) Thanks for the cleanup work!
