Found this today with python-basemap. Numpy 1.4.0 introduced some ABI changes. Anything that compiles against numpy and hasn't been rebuilt since Numpy 1.40 was introduced in late January may need to be rebuilt in F-13 and rawhide.
Just a friendly heads up.
I'm fixing python-basemap now and then I'm going to start working through the rest of the potentially affected packages and firing up rawhide rebuilds for those with build times older than the numpy 1.4.0 introduction. Once that is complete I'll be looking at pushing F13 updates. Apologizes to anyone's toes. I'm hoping some of the affected maintainers see this and take care of this before me. Because this is an ABI break, this will show up in weird unexpected runtime breakages for users..some easy to hit...some not. Its best to just do rebuilds now to avoid trying to to track this down in a series of head scratching crash reports.
-jef
Here are the packages that might be affected according to repoquery run on my 32bit box with build timestamps prior to numpy 1.4.0.
gnuplot-py healpy pygrace python-nltk reinteract PyOpenGL gnome-applet-music scitools scitools-extras fonttools pygame PySBIG pygsl ScientificPython python-matplotlib scipy python-biopython PyQuante gausssum expendable PyQwt plplot pyfits python-numdisplay inkscape rpy specto gnuradio python-cclib python-networkx getdata-python mypaint python-fiat Mayavi
On Thu, Apr 1, 2010 at 11:41 AM, Jeff Spaleta jspaleta@gmail.com wrote:
Here are the packages that might be affected according to repoquery run on my 32bit box with build timestamps prior to numpy 1.4.0.
Let me stress the "might" That was a first rough cut at a list. Its really anything that buildrequires numpy and hasn't been rebuilt since numpy 1.4 was introduced into the rawhide and F13 trees.
-jef
Here are the packages that might be affected according to repoquery run on my 32bit box with build timestamps prior to numpy 1.4.0.
<<unsorted list of 35 packages snipped>>
Please sort the list. Yes, many mail user agents do offer text Search, but mostly that works well only for known literal substrings. If you want effective and efficient communication, then make it easy for the audience.
expendable fonttools gausssum getdata-python gnome-applet-music gnuplot-py gnuradio healpy inkscape Mayavi mypaint plplot pyfits pygame pygrace pygsl PyOpenGL PyQuante PyQwt PySBIG python-biopython python-cclib python-fiat python-matplotlib python-networkx python-nltk python-numdisplay reinteract rpy ScientificPython scipy scitools scitools-extras specto
--
On Thu, Apr 1, 2010 at 12:41 PM, John Reiser jreiser@bitwagon.com wrote:
Here are the packages that might be affected according to repoquery run on my 32bit box with build timestamps prior to numpy 1.4.0.
<<unsorted list of 35 packages snipped>>
Please sort the list. Yes, many mail user agents do offer text Search, but mostly that works well only for known literal substrings. If you want effective and efficient communication, then make it easy for the audience.
It was sorted! By build date! Oldest builds at the top. I'm working on narrowing the list to just things that buildrequire...I'll alpanumeric sort that one.
-jef
On Thu, Apr 1, 2010 at 12:48 PM, Jeff Spaleta jspaleta@gmail.com wrote:
It was sorted! By build date! Oldest builds at the top. I'm working on narrowing the list to just things that buildrequire...I'll alpanumeric sort that one.
Here is a revised list, sorted for package name, of packages that probably need a rebuild in both rawhide and F13 according to the buildtime as seen in the rawhide repository.
The highest impact on the Beta release here is probably pygtk2
Package FAS Owner avogadro sdz fonttools roozbeh getdata mtruch gnuplot-py sergiopr gnuradio mmahut healpy jsmidt plplot orion pyfits sergiopr pygame xulchris pygrace jussilehtola pygsl jamatos pygtk2 walters PyQuante jussilehtola PyQwt tadej PySBIG mmahut python-biopython alexlan python-cclib jussilehtola python-matplotlib jspaleta python-Traits rakesh rpy jamatos ScientificPython jspaleta scipy jspaleta slimdata mtruch
And By Owner: alexlan: python-biopython jamatos: pygsl,rpy jsmidt: healpy jspaleta: ScientificPython, python-matplotlib,scipy jussilehtola: pygrace,PyQuante,python-cclib mmahut: PySBIG,gnuradio mtruch: getdata, slimdata orion: plplot rakesh: python-Traits roozbeh: fonttools sdz: avogadro sergiopr: gnuplot-py,pyfits tadej: PyQwt walters: pygtk2 xulchris: pygame
Repoquery commands used : repoquery -q --repoid=rawhide-source --archlist=src --whatrequires numpy --queryformat "%{buildtime}:%{name}"|sort repoquery -q --repoid=rawhide-source --archlist=src --whatrequires numpy-f2py --queryformat "%{buildtime}:%{name}"|sort
Am Donnerstag, den 01.04.2010, 11:41 -0800 schrieb Jeff Spaleta:
Found this today with python-basemap. Numpy 1.4.0 introduced some ABI changes. Anything that compiles against numpy and hasn't been rebuilt since Numpy 1.40 was introduced in late January may need to be rebuilt in F-13 and rawhide.
Just a friendly heads up.
I'm fixing python-basemap now and then I'm going to start working through the rest of the potentially affected packages and firing up rawhide rebuilds for those with build times older than the numpy 1.4.0 introduction. Once that is complete I'll be looking at pushing F13 updates. Apologizes to anyone's toes. I'm hoping some of the affected maintainers see this and take care of this before me. Because this is an ABI break, this will show up in weird unexpected runtime breakages for users..some easy to hit...some not. Its best to just do rebuilds now to avoid trying to to track this down in a series of head scratching crash reports.
-jef
Here are the packages that might be affected according to repoquery run on my 32bit box with build timestamps prior to numpy 1.4.0.
gnuplot-py healpy pygrace python-nltk reinteract PyOpenGL gnome-applet-music scitools scitools-extras fonttools pygame PySBIG pygsl ScientificPython python-matplotlib scipy python-biopython PyQuante gausssum expendable PyQwt plplot pyfits python-numdisplay inkscape rpy specto gnuradio python-cclib python-networkx getdata-python mypaint python-fiat Mayavi
I don't understand, why you need to rebuild the noarch packages. Sure, the compiled *.pyc files might be obsolete, but python should update them automatically. (Means it would be better to rebuild them, but they are very, very unlikely to break, if they are not.)
Are you sure, packages like gnuplot-py *have* to get rebuild? Your first programm that causes troubles 'python-basemap' is not noarch. A compiled programm needs a rebuild, but a programm with just python files in it?
Thomas
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura spurath@students.uni-mainz.de wrote:
Are you sure, packages like gnuplot-py *have* to get rebuild? Your first programm that causes troubles 'python-basemap' is not noarch. A compiled programm needs a rebuild, but a programm with just python files in it?
Apologies, see the revised list I posted later as a follow-up that does a better job of finding the things that buildrequire numpy. The first list was admittedly a rough cut.
-jef
On Thu, 2010-04-01 at 22:48 -0800, Jeff Spaleta wrote:
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura spurath@students.uni-mainz.de wrote:
Are you sure, packages like gnuplot-py *have* to get rebuild? Your first programm that causes troubles 'python-basemap' is not noarch. A compiled programm needs a rebuild, but a programm with just python files in it?
Apologies, see the revised list I posted later as a follow-up that does a better job of finding the things that buildrequire numpy. The first list was admittedly a rough cut.
A Python package BuildRequiring numpy does not need to mean anything. All of my packages on the list BuildRequires numpy simply because the install scripts have a dummy check in them for checking that all necessary runtime modules are installed.. so AFAIK nothing is compiled against numpy.
On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola jussilehtola@fedoraproject.org wrote:
A Python package BuildRequiring numpy does not need to mean anything. All of my packages on the list BuildRequires numpy simply because the install scripts have a dummy check in them for checking that all necessary runtime modules are installed.. so AFAIK nothing is compiled against numpy.
I'm not saying all those packages are affected... I'm saying that's a starting point for packages to be checked.
The ABI break is real. Quoting scipy.org: "NumPy 1.4.0 release pulled. (2010-2-8) Due to an unintended ABI break the 1.4.0 release has temporarily been pulled pending a decision on how to handle the ABI incompatibility."
Its almost two months later and NumPy 1.4.0 is still pulled from upstream. Not a good sign. Do we revert to back to to the old version if upstream doesn't re-release 1.4 before F13 release date? Sort of an important question.
I'm still coming up to speed on the details by reading the upstream mailinglist.
-jef
On Fri, 2010-04-02 at 04:11 -0800, Jeff Spaleta wrote:
On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola jussilehtola@fedoraproject.org wrote:
A Python package BuildRequiring numpy does not need to mean anything. All of my packages on the list BuildRequires numpy simply because the install scripts have a dummy check in them for checking that all necessary runtime modules are installed.. so AFAIK nothing is compiled against numpy.
I'm not saying all those packages are affected... I'm saying that's a starting point for packages to be checked.
The ABI break is real. Quoting scipy.org: "NumPy 1.4.0 release pulled. (2010-2-8) Due to an unintended ABI break the 1.4.0 release has temporarily been pulled pending a decision on how to handle the ABI incompatibility."
Its almost two months later and NumPy 1.4.0 is still pulled from upstream. Not a good sign. Do we revert to back to to the old version if upstream doesn't re-release 1.4 before F13 release date? Sort of an important question.
I'm still coming up to speed on the details by reading the upstream mailinglist.
I haven't looked into the ABI break in detail, but I notice that our "numpy" rpm contains header files: [david@f13 ~]$ rpm -q numpy numpy-1.4.0-4.fc13.x86_64 [david@f13 ~]$ rpm -ql numpy|grep ".h" /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/__multiarray_api.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/__ufunc_api.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/_neighborhood_iterator_imp.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/_numpyconfig.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayobject.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/arrayscalars.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/noprefix.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_common.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_cpu.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_endian.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_interrupt.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_math.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/npy_os.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/numpyconfig.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/old_defines.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/oldnumeric.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ufuncobject.h /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/utils.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/arraybase.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/cfunc.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/ieeespecial.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/libnumarray.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/numcomplex.h /usr/lib64/python2.6/site-packages/numpy/numarray/numpy/nummacro.h /usr/lib64/python2.6/site-packages/numpy/random/randomkit.h
...which define the C-level API and data layout of the various useful PyObject subclasses provided by NumPy.
For example, /usr/lib64/python2.6/site-packages/numpy/core/include/numpy/ndarrayobject.h contains the declaration of struct PyArrayObject and the API to go with it, which extension modules may be using.
Would it help insulate against future changes if these headers were moved to a numpy-devel subpackage? That way, packages that need to have a direct binary API dependency would need a BuildRequires: numpy-devel whereas those that merely go in at the Python level wouldn't need this, and it would be easier to spot packages needing a rebuild.
Doing so now and forcing a rebuild _might_ help isolate the change. I don't know if that's a good idea at this stage for F-13, though.
Hope this is helpful; I haven't had enough coffee yet today so I may be missing something.
Dave
On Fri, Apr 2, 2010 at 7:54 AM, David Malcolm dmalcolm@redhat.com wrote:
Doing so now and forcing a rebuild _might_ help isolate the change. I don't know if that's a good idea at this stage for F-13, though.
Hope this is helpful; I haven't had enough coffee yet today so I may be missing something.
It looks like we may be reverting back to 1.3 regardless...if numpy upstream does not have an expected re-release date for 1.4. Is numpy it critpath for the Beta? I'm looking for input on whether we should revert asap to make sure numpy 1.3 is in the Beta.
-jef
On Fri, Apr 02, 2010 at 10:39:33AM -0800, Jeff Spaleta wrote:
It looks like we may be reverting back to 1.3 regardless...if numpy upstream does not have an expected re-release date for 1.4. Is numpy it critpath for the Beta? I'm looking for input on whether we should revert asap to make sure numpy 1.3 is in the Beta.
Presumably, whatever resolution is taken is going to follow compatibility with 1.3 -- whether it's called 1.4.1 or whatever. That'll make 1.4.0 itself a dead branch with no upgrade path without _more_ breakage.
So I think revert is the best call unless a 1.4.1 comes out, like, now.
On Fri, 2010-04-02 at 10:39 -0800, Jeff Spaleta wrote:
Is numpy it critpath for the Beta? I'm looking for input on whether we should revert asap to make sure numpy 1.3 is in the Beta.
It's basically too late for Beta, I've composed RC4 which should fix all known issues and become the release bits.
-
David Malcolm -
Jef Spaleta -
Jesse Keating -
John Reiser -
Matthew Miller -
Susi Lehtola -
Thomas Spura