Bug 688636 - Scipy missing from EPEL 6
Summary: Scipy missing from EPEL 6
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: scipy
Version: el6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Jef Spaleta
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-17 15:24 UTC by Dario Landazuri
Modified: 2011-05-18 19:58 UTC (History)
3 users (show)

Fixed In Version: scipy-0.7.2-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-18 19:58:56 UTC
Type: ---


Attachments (Terms of Use)
captured output of scipy test suite run via python script (11.29 KB, text/plain)
2011-03-17 16:03 UTC, Dario Landazuri
no flags Details

Description Dario Landazuri 2011-03-17 15:24:06 UTC
Description of problem:
It appears that scipy hasn't yet been built for EPEL 6.  I have users who use that package pretty heavily who I'd like to be able to support without having to build and maintain my own source-built package.  It would be nice to have the latest (0.9.0) version if possible.

Comment 1 Dario Landazuri 2011-03-17 16:02:20 UTC
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)

Comment 2 Dario Landazuri 2011-03-17 16:03:16 UTC
Created attachment 486047 [details]
captured output of scipy test suite run via python script

Comment 3 Dario Landazuri 2011-03-17 16:06:20 UTC
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()

Comment 4 Jef Spaleta 2011-03-19 02:36:30 UTC
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

Comment 5 Orion Poplawski 2011-03-30 15:34:16 UTC
Any reason not to jump to scipy 0.9.0 for EL6?  I can help with this.

Comment 6 Dario Landazuri 2011-03-30 16:39:06 UTC
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

Comment 7 Orion Poplawski 2011-03-30 16:44:18 UTC
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. :)

Comment 8 Orion Poplawski 2011-04-01 16:33:19 UTC
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.

Comment 9 Orion Poplawski 2011-04-01 17:52:36 UTC
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

Comment 10 Dario Landazuri 2011-04-01 18:15:54 UTC
(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?

Comment 11 Dario Landazuri 2011-04-01 18:16:18 UTC
(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.

Comment 12 Orion Poplawski 2011-04-01 19:19:31 UTC
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?

Comment 13 Dario Landazuri 2011-04-01 19:31:27 UTC
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?

Comment 14 Orion Poplawski 2011-04-01 19:42:24 UTC
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.

Comment 15 Dario Landazuri 2011-04-01 19:46:10 UTC
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. ;)

Comment 16 Jef Spaleta 2011-04-02 00:47:36 UTC
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

Comment 17 Fedora Update System 2011-05-03 20:27:23 UTC
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

Comment 18 Fedora Update System 2011-05-03 23:02:43 UTC
scipy-0.7.2-5.el6 has been pushed to the Fedora EPEL 6 testing repository.

Comment 19 Fedora Update System 2011-05-18 19:58:51 UTC
scipy-0.7.2-5.el6 has been pushed to the Fedora EPEL 6 stable repository.


Note You need to log in before you can comment on or make changes to this bug.