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%
Packages waiting on other packages
- pyactivemq DONE :
- revelation needs gnome-python2-applet from:
- gnome-python2-desktop, which fails to build against gtk-3.0, apparently due to a missing header
- python-networkx needs:
- gdl needs:
- python-matplotlib (see above)
- plplot needs:
- gnome-python2-canvas, gnome-python2-gnomevfs, gnome-python2-gnome (see below)
- gget needs
- notify-python fails to build with /usr/include/pygtk-2.0/pygtk/pygtk.h:8:21: fatal error: gtk/gtk.h: No such file or directory
- hamster-applet needs:
- many gnome-python2-* packages from gnome-python2-desktop (see above)
- 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:
- conduit needs
- caribou needs
- python-virtkey [DONE]
- lazygal fails with AttributeError: 'module' object has no attribute 'sysconfig' (distutils module)
- planner needs:
- orca 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.
Packages with build errors
- ecryptfs-tools fails to build with test.c:284:6: error: 'lower_byte_offset' may be used uninitialized in this function
- 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.
- system-config-display https://bugzilla.redhat.com/show_bug.cgi?id=617777
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