Hi,
I know Flemming didn't intend to send his first mail yesterday to the
list, but seeing that his questions are relevant to a number of
people, I will answer via the list.
> oolockserver
> -- I am attempting to do this on rlnx03, so where does the lock server
> run - locally on rlnx03 !? there is no /usr/spool/objy.. On another rcf
> machine!?
oolockserver is running on specific machines at RCF. For Linux this is
rls.rhic.bnl.gov, while for Solaris it is rsun00.rhic.bnl.gov (I
believe rls.rhic.bnl.gov is running Debian GNU/Linux 2.1 - my Linux
distribution of choice!).
Please notice that making a Federated Database at RCF is kind of
restricted. What this amounts to, is that you can only use a Federated
Database ID from a certain range, depening on which experiment you are
attached to. For BRAHMS this range is 6225 - 6249 for production, and
28000-28249 for non-production. I.e. you should edit the Makefile, and
set the variable FDID to a number in the range 28000-28249. oonewfd
will complain if a Federated Database with your chosen id already
exists.
> My aim is first to try building what you have rather than just looking at
> the code which I did last time.
Actually Konstatin succeded in building BRAD at pii3.brahms.bnl.gov,
but as pointed out in the INSTALL file, the executables fail for some
reason.
If anyone fells up to it, I would appriciate if you would try to build
BRAD on a Solaris machine. I don't know if my code (or
the Objectivity/ROOT code) is ANSI enough to comiple out of the
box. Since most of the DAQ system, as far as I know, is running on
Solaris, I believe it would be reasonable if BRAD also worked on that
architecture. However, I do not have reasonable access to a Solaris
machine (of course I could use rcf.rhic.bnl.gov, but the overhead from
the network connection makes it intolarable - sorry), so I was hoping
someone would volanteer for this tidious task - please!
> If you do get into a mode where more frequent updates are going to
> take place, we should consider really having it in a CVS repository,
> and prefereably on the master CVS_ROOT of the RHIC domain.
I like your faith in my Flemming. I don't think frequent updates is a
problem though, but I could ofcourse put BRAD into the main repository
at RCF.
> The alternative to have it (for a while only) at a CVS resp at NBI
> which is then somehow reachable from RCF/BRAHMS , but then you would
> have to give outside users access, which I am sure you will not like.
No I wouldn't, and I know Bjorn Nilsson - our system operator - would
bit my head of.
Also, Konstatin made a quite a lot of remarks concerning the CVS
repositories for BRAHMS.
I believe placing the CVS repository under the daq account is a bad
idea. After all, only a hand full of people have access to this
account, which depreciates broad development. Rather, I would suggest
a more open (and general) approach:
The CVS repository should be placed somewhere public (in BRAHMS
terms), like say /afs/rhic/brahms/BRAHMS_CVS. This repository could
contain sub-reositories like `online', `offline', etc. Then `online'
could contain the DAQ modules, as outlined by Konstantin. `offline'
would contain `brat', `gbrahms', `egread', `brad'(?), etc. Phenix has
a CVS repository layout that looks a lot like this. Maybe, we should
allow (resd-only) checkouts for non-developers.
Another point concerning CVS. Please use tags to mark releases. In
that way, non-developers that checkout software, won't get the latest
non-working buggy alpha version of the software. This simply amounts
to `cvs rtag <release_info>' for taging, and
`cvs checkout -r <release_info>' for checkout, where <release_info>
could be something like `release_0_3_1' for example.
Christian
----------------------------------------------------------------
Christian Holm Christensen Phone: (+45) 35 35 96 91
Sankt Hansgade 23. 1, th Office: (+45) 353 25 307
DK-2200 Copenhagen N Email: cholm@nbi.dk
Denmark Homepage: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Tue Feb 01 2000 - 20:35:05 EST