I received some help from tremble in #epel, who did a test build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2920522

The build completed and I was able to cleanly install the x86_64 rpm on the needed system.

Ran the test suite for scipy interactively, and it passed (bottom of output below):

Ran 3486 tests in 42.436s

OK (KNOWNFAIL=4, SKIP=20)
<nose.result.TextTestResult run=3486 errors=0 failures=0>

Ran the test suite via a python script, and it failed - captured output attached (scipy_test.output)

Created attachment 486047 [details]
captured output of scipy test suite run via python script

Forgot to note: per https://github.com/numpy/numpy/blob/master/doc/TESTS.rst.txt#introduction, tests were run the following ways:

1) Interactivly:

[root@r900-4 ~]# python
Python 2.6.5 (r265:79063, Jan 21 2011, 12:09:23) 
[GCC 4.4.4 20100726 (Red Hat 4.4.4-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.test()


2) Via script:

[root@r900-4 ~]# cat scipy_test.py 
#!/usr/bin/python

import scipy

scipy.test()

Dario!

I would absolutely love to get scipy into EPEL 6. Unfortunately my reallife work travel schedule visiting SuperDARN radar sites in far flung bandwidth poor places for the last couple of months have made it near impossible to do any packaging work in my off hours.

As soon as I can get to it (next week?), and if another scipy packager co-maintainer doesn't get to before me I'll make this the top priority on the packaging work.

However please keep refining that test package and if you want to be co-maintainer for the EPEL branch, let me know and I can be your package mentor or whatever the position is called which allows me to slot you in as a co-maintainer based on your packaging work you are doing right now.

-jef

Any reason not to jump to scipy 0.9.0 for EL6?  I can help with this.

Jef:

I'm just a sysadmin, not someone qualified to maintain a package.  AFAICT from my user's feedback, the scipy build that tremble helped me with works just fine.  I'm not sure what to make of the different test results for how I ran the test suite.

I would be happy if scipy were updated to 0.9.0 (per Orion's comment), but at least having 0.7.2 is helpful.

Cheers,
Dario

Dario - Don't sell yourself short.  Packaging isn't that hard.  I'm just a sysadmin myself and packaging is a lot easier than most of what I do. :)

Okay, building 0.7.2 for EPEL6.  Looks like we are stuck there because we have numpy 1.3.0 in RHEL6 and 0.8 and higher all require 1.4.1.

Bah, looks like tests are failing on ppc64.  Thoughts?  I'm tempted to exclude arch ppc64 or not run the tests there.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2966942

(In reply to comment #8)
> Okay, building 0.7.2 for EPEL6.  Looks like we are stuck there because we have
> numpy 1.3.0 in RHEL6 and 0.8 and higher all require 1.4.1.

Would this be a valid reason to request numpy's maintainer to update?

(In reply to comment #10)
> (In reply to comment #8)
> > Okay, building 0.7.2 for EPEL6.  Looks like we are stuck there because we have
> > numpy 1.3.0 in RHEL6 and 0.8 and higher all require 1.4.1.
> 
> Would this be a valid reason to request numpy's maintainer to update?

D'oh, never mind - forgot it is in RHEL now.

Well, we could still *ask*.  numpy is supposed to be backwards compatible.  If we do, do we wait for it or would we be okay with updating from scipy 0.7.2 to 0.9.0 in EPEL6?

Do you mean do no update on scipy at all (other than making it available) in EPEL6 until numpy is updated or update it to 0.7.2 for now, and 0.9.0 if/when RH updates numpy in RHEL6?

I guess my vote (such as it is) would be to update to 0.7.2 now if it's not too much work (i.e., the ppc64 test fail can be resolved quickly) and then to 0.9.0 once RH brings numpy up.

With regards to your other question re: ppc64 - I didn't even remember RHEL was available for ppc64.  Is there any way for us to tell how often people are using EPEL for ppc64?

I filed a request with bug 692959.  Are there any compatibility concerns updatings scipy 0.7.2 to 0.9.0?  I'm not really a user of scipy so I can't judge.  The removal of stsci might be one.  But I suppose we could just remove that in the initial 0.7.2 build.

I honestly couldn't speak to compatibility concerns.  Though if stsci has anything to do with Space Telescope, my users (astronomers) may have concerns, but I don't know. ;)

Just a little history,

When numpy was sucked into RHEL 6 away from EPEL, and I was informed of that. I made the suggestion that RH engineering also take matplotlib and scipy into RHEL in order to keep these things together as they are very closely related upstream.
I do not know the specific reason why numpy made the jump as I am not privy to RHEL engineering decisions as to which software they decide to support.

I'm also not a customer of RHEL as a product so I don't have any skin in the game with regard to setting RHEL engineering policies. And I appreciate the fact that they need to make hard decisions as to what that means in the package landscape and I accept the fact shifts in the packaging support in RHEL necessarily impact what EPEL can deliver.

That being said, from my perspective, I believe that pulling in numpy without pulling in matplotlib and scipy is a mistake.  Mistakes happen, I hold no grudges in that regard.  If there are paying RHEL support customers who come across this ticket who use matplotlib and/or scipy, I would highly encourage you to make RH aware that you would like them to keep numpy/matplotlib/scipy synced and supported as a group of packages because they form a coherent framework for scientific analysis which numpy by itself does not provide for.

-jef

scipy-0.7.2-5.el6 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/scipy-0.7.2-5.el6

scipy-0.7.2-5.el6 has been pushed to the Fedora EPEL 6 testing repository.

scipy-0.7.2-5.el6 has been pushed to the Fedora EPEL 6 stable repository.