2:41 p.m.
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
3:37 p.m.
On Thu, Apr 1, 2010 at 11:41 AM, Jeff Spaleta <jspaleta(a)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
3:41 p.m.
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
--
3:48 p.m.
On Thu, Apr 1, 2010 at 12:41 PM, John Reiser <jreiser(a)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
4:36 p.m.
On Thu, Apr 1, 2010 at 12:48 PM, Jeff Spaleta <jspaleta(a)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
1:44 a.m.
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
1:48 a.m.
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura
<spurath(a)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
2:03 a.m.
On Thu, 2010-04-01 at 22:48 -0800, Jeff Spaleta wrote:
On Thu, Apr 1, 2010 at 10:44 PM, Thomas Spura
<spurath(a)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.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
7:11 a.m.
On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola
<jussilehtola(a)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
10:54 a.m.
On Fri, 2010-04-02 at 04:11 -0800, Jeff Spaleta wrote:
On Thu, Apr 1, 2010 at 11:03 PM, Jussi Lehtola
<jussilehtola(a)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
1:39 p.m.
On Fri, Apr 2, 2010 at 7:54 AM, David Malcolm <dmalcolm(a)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
2:30 p.m.
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.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
3:24 p.m.
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.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5148
days inactive
5149
days old
12 comments
7 participants
participants (7)
-
David Malcolm -
Jef Spaleta -
Jesse Keating -
John Reiser -
Matthew Miller -
Susi Lehtola -
Thomas Spura