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
> 


-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/CSS  CSI Group
__________________________________________________