I recommend using ESO scisoft libraries for astrophysics software.

I've had very little problem installing it on SL 4.x They have a yum 
repository online. They provide (limited) support.

www.eso.org/scisoft/

P.S. Their software doesn't have much for xray & radio astronomers

--Chris

>>> - cfitsio.   This is the package to read/write FITS files which is the
>>>   astrophysics standard.   There are RPMs available for it at least in
>>>   the Fedora Core extras.
>>>
>
> I tested compiling the Fedora Core 3 Extra's rpm.  It recompiled without 
any
> problems.  Looks do-able.



On Fri, 30 Jun 2006, Troy Dawson wrote:

> Andy Buckley wrote:
>> Paul F. Kunz wrote:
>> 
>>>>>>>> On Fri, 16 Jun 2006 14:42:11 +0100, Andy Buckley 
>>>>>>>> <[log in to unmask]> said:
>>> 
>>> 
>>>> Incidentally, did anything further ever happen with the Scientific
>>>> Linux team re. getting HD into it? There seemed to be some
>>>> misunderstanding about license issues... is that (being) resolved?
>>> 
>>>
>>>    Today I fixed the RPM spec file that comes with the release, so now
>>> it works with the latest changes.   I've also added a license file,
>>> LGPL.
>> 
>> 
>> I've copied this to the SL devel list: SL people, I take it that solves the 
>> problem?
>>
>>>    I realize that HippoDraw is most useful when compiled with some
>>> optional external packages and depending if you are coming from HEP
>>> or Astrophysics, you may want to choose different options.   So what
>>> optinal packages should be built-in to the RPM?   They are ...
>>> 
>>> - Python.   Of coursse it is there, but I need  python-devel.  I can
>>>   put python-devel as a prerequsit
>>> 
>>> - Boost.Python.   RPMs available even with some newer RHEL systems.
>>> 
>>> - Qt.  Of course available, and I can use version 3.1 if needed.
>>>   However, I need qt-devel to compile and this is not a default.
>> 
>> 
>> These are all pretty standard bits of OS these days: again, any problems, 
>> SL people?
>> 
>
> These are all in the release, no problem with any of them that I know of.
>
>>> - Minuit (C++ version).  There's no RPM file for this, altho I could
>>>   contribute one for their next replease.   I could also include
>>>   Minuit sources in the source RPM file and make it a subpackage
>>>   hippodraw-minuit.
>>> 
>
> If he could provide the rpm, that would be best. He probrubly knows more 
> about what should be in it.
>
>>> - ROOT.  Is there an RPM for ROOT?  When I log into lxplus.cern.ch
>>>   (which is SLC 3), there doesn't appear to be any ROOT installed and
>>>   no ROOT in the RPM database.  And if there were, it would be
>>>   compiled with gcc 3.2.3, which I can't use if HippoDraw gets
>>>   compiled with gcc 3.4 or later.  Of course, I could do like Minuit.
>>> 
>
> I've been trying to get root into S.L. from the very beginning.
> At one point I said I was just going to put it in no matter the amount of 
> work, and I have to admit, I was supprised by the reaction of our linux-users 
> group.  They said no, because each of the groups wanted it compiled with 
> something different and none could agree.
> I'm at a loss with this package, I'll let CERN comment.
>
>>> - cfitsio.   This is the package to read/write FITS files which is the
>>>   astrophysics standard.   There are RPMs available for it at least in
>>>   the Fedora Core extras.
>>> 
>
> I tested compiling the Fedora Core 3 Extra's rpm.  It recompiled without any 
> problems.  Looks do-able.
>
>>> - wcslib.  Word Coordinate System, interesting for astrophysics.   No
>>>   RPM available.
>> 
>
> I have a bit of a problem with it's installation.  It recompiled just fine. 
> But partway through it's installation it tried to change the permissions of 
> /usr/lib.  That's a big no no in my book.
> I don't have time to fix this.  In the end, someone needs to bundle this into 
> an rpm, and make it so that when you build the rpm, it isn't messing with 
> permissions on the build machine.
>
>>
>>  > - numarray.   Not part of the standard Python install, but RPM is
>>  >   available at least for Fedora Core.
>> 
>
> In our DAG repository, could be done easily.
>
>>> - Doxygen. Needed for documenatation generation.  RPM available for
>>> - later versions RHEL and Fedora.
>>> 
>
> Already in the release
>
>>> - graphwiz.   Needed for documenation generation.   RPM available in
>>>   later version of RHEL and Fedora.
>> 
>
> Did you mean graphviz or graphwiz.
> We have graphviz already in the release, I can't find graphwiz
>
>> 
>> I'll let the SL people comment on the majority of those.
>> 
>
> Commenting on below.
> There is a python-numeric that is available in the dag repository.  I have 
> also created a numpy rpm, that is currently in our contrib area. I've seen 
> some packages want python-numberic, and some want numpy.
> I personally have not used either.
> is python-numeric the same as numpy?
> Should I include one or the other, or both?
>
>>  From my point of view, I would like numarray (or numpy, as the recent 
>> releases of SciPy and matplotlib use it and they are also obvious things to 
>> provide in SL). Are Doxygen, graphviz and python-devel really necessary for 
>> a binary RPM of HippoDraw? There is already API documentation on your 
>> HippoDraw website and if you wanted it available in e.g. 
>> /usr/share/doc/HippoDraw on SL systems then surely a given set of 
>> Doxygen+Graphviz documentation could be tarred up as part of a 
>> hippodraw-doc RPM.
>>
>>>    So what do you think?   SLC 3 is pretty old (RHEL4 being out over a
>>> year). Some of the external packages are not in SLC 3, but are in
>>> SLC4.
>>>    Independent of CERN's SLC, I plan to try to contribute HippoDraw to
>>> Fedora Core.   If it makes it there, then it will be part of RHEL 5
>>> and thus part of SLC 5 unless CERN people take it out.
>> 
>> 
>> That sounds good to me: personally I'd love to see it in Debian/Ubuntu, 
>> too! Maybe I'll look into that.
>> 
>> Andy
>> 
>
>
>

-- 
Chris Hunter
Systems Programmer, Astronomy, Yale University
[log in to unmask]