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]