Update the system Python 2 stack in Fedora from 2.6 to 2.7
- Name: Dave Malcolm
- Email: <email@example.com>
- Targeted release: Fedora 14
- Last updated: 2010-07-27
- Percentage of completion: 90%
Tracker bug for packages that fail to rebuild: https://bugzilla.redhat.com/showdependencytree.cgi?id=619913&hide_resolved=1
Fixes for broken packages should be built into both rawhide, and into dist-f14.
Information on the new "dist-git" system can be seen here.
Once it's been successfully rebuilt for F14, an update needs to be filed to get the rebuild into F14.
To make it easier to track things, dmalcolm has been filing bugs using this template against the broken packages. Please set the component and add the name of the component to the front of the subject of the bug. Once an update has been created, the bug should be flipped over to the MODIFIED status, to make it easy to see what works remain.
Packages waiting on other packages
- sugar-tamtam needs:
- boost-python DONE
- build parameter changes
- ipa needs
- TurboGears needs:
- python-peak-rules: fails in %check apparently within peak-util-assembler (is this 2.7-compatible?)
- python-peak-rules (see above)
- python-formencode fails in %check
- python-ruledispatch (fails in %check, with "KeyError: 320" in 4 tests, and "AssertionError: 42529136 == Pointer(<invalid at 0x0x288f170>)" in another)
- python-cherrypy2 (see above)
- python-formencode (see above)
- python-ruledispatch (see above)
- python-turbojson (see above)
- TurboGears needs:
- python-LightBox needs
- TurboGears (and various other packages)
- Needs TG1 and TG2 stack for the serverside code to function. clientside code will function without it.
- Building was blocked on python-cherrypy2 and the TG2 stack. Removed those. This gets us clientside code. Need to remove those changes and rebuild once python-cherrypy2 shows up.
- Needs TG1 stack for the serverside to run. clientside will function without it.
- Built a hacked up package where the serverside will likely fail. This gives us the ability to run the client-side application but needs to be fixed once the TG1 stack is rebiult.
- python-zope-testing is improperly built. It requires non-existing package python-zope-exceptions
- python-zope-testing (see above)
Packages with build errors
- ocfs2-tools fails to build with mount.ocfs2.c:264:2: error: variable-sized object may not be initialized
- onboard fails to build with /usr/bin/python: can't open file 'setup.py': Errno 2 No such file or directory
- sympy fails with TypeError: not enough arguments for format string in sympy-0.6.7/sympy/utilities/runtests.py
- vtk fails to build the SRPM. The vtk-5.6.0-testcxxjavaremove.patch is missing.
- python-wokkel fails to build with test_failureUnknown ERROR during tests
- luci has no cvs record on devel. This package is inherited from dist-f12. See also the bug 526041
gobject-introspection's /usr/bin/g-ir-scanner was incompatible with python 2.7, this led to anything building a .gir file failing.
This was blocking:
Various swig users fail to find the python libraries during "configure":
checking for Python library path... find: `/usr/lib/python/config/': No such file or directory find: `/usr/lib/python/': No such file or directory /usr/lib checking python extra libraries...
Relevant part of "configure" seems to be
python_path=`echo $PYTHON | sed "s,/bin.*$,,"` for i in "$python_path/lib/python$PYTHON_VERSION/config/" "$python_path/lib/python$PYTHON_VERSION/" "$python_path/lib/python/config/" "$python_path/\ lib/python/" "$python_path/" ; do
This sets $python_path to "/usr", and then looks for config within /usr/lib, which fails on 64-bit: the relevant files are in /usr/lib64 (why did this work before? is this a python change?)
Before this we see errors like this:
checking for SWIG version... 2.0.0 configure: WARNING: SWIG version >= 1.3.17 is required. You have 2.0.0. You should look at http://www.swig.org
The test in the configure seems to look for an exact match on major and minor, and >= on the patch level, and thus "2" -ne "1" seems to leave SWIG_LIB unset, and could be the actual problem here.
A workaround is to add this:
# For now (workaround for SWIG major-version bump) BuildRequires: autoconf %prep (snip) # Fixup expected version of SWIG: sed -i -e "s|AC_PROG_SWIG(1.3.17)|AC_PROG_SWIG(2.0.0)|" configure.in # and rebuild the configure script: autoconf
This was blocking:
- DONE: libopensync
- DONE: setools
- Python 2.7 was released on 2010-07-03
This will require a rebuild of everything with
Requires: python(abi) = 2.6. See Mass_Rebuild_SOP for how we do a full rebuild of everything - hopefully we can adapt the scripts there to accomplish the rebuild needed for Python 2.7. See Features/Python_2.7/MassRebuild for notes on this specific rebuild.
Hopefully, little to no porting will be required.
Some notes on changes that may require porting are given on the upstream wiki here: http://docs.python.org/dev/whatsnew/2.7.html#porting-to-python-2-7
Benefit to Fedora
Fedora aims to showcase the latest in free and open source software - we should have the most recent release of Python.
Python is pervasive in Fedora. Everything from yum to system-config-* to anaconda to pungi is written in Python.
How To Test
Interested testers do not need special hardware. If you have a favorite Python script, module, or application, please test it with Python 2.7 and verify that it still works as you expect.
My own test plan:
- Smoketest of the interpreter
- Run the upstream regression test suite
- Ensure that yum still works
- Ensure that anaconda still works
Users should not notice any difference, other than the availability of the 2.7 interpreter
The list is too large to include here.
repoquery --whatrequires --alldeps -s "python(abi) = 2.6" | sort -u
indicates approximately 1200 rpms
- There is none. This is do-or-die.
The system Python 2 stack has been upgraded to 2.7. For a list of changes see http://docs.python.org/dev/whatsnew/2.7.html