[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [ROOT] New release of Debian ROOT packages - Development Snapshot



Hi Roland et al, 

On Mon, 2006-10-30 at 10:32 +0100, Roland Kuhn wrote:
> Hi Christian!
> 
> On 30 Oct 2006, at 08:52, Christian Holm Christensen wrote:
...
> > Well, I guess it did, otherwise it shouldn't build :-)
> >
> Well, I had to install xbase-clients by hand, otherwise there's no  
> X11-forwarding via SSH. This is not in any way related with ROOT, but  
> it made me ask myself whether some dependency might have been missed  
> because some packages are always there by default on a normal desktop  
> install. Up to now it looks fine :-)

xbase-clients is a runtime thing, and particular to the remote
connection you're doing, so as you say, ROOT shouldn't really depend on
that. 

> > Try unsetting the ROOTSYS environment variable (and LD_LIBRARY_PATH  
> > for
> > that matter).  These variables are _not_ needed.
> >
> Without the Qt plugin it gave no errors, but with it I got

So, if you unset ROOTSYS, it works?  Is that correctly understood? 

> rkuhn@rk:~$ root
> Error in <TUnixSystem::ExpandFileName>: input: $ROOTSYS/bin/root.exe,  
> output: $ROOTSYS/bin/root.exe
> Xlib:  extension "XInputExtension" missing on display "localhost:10.0".

I guess this has to do with the remote X server set-up.  It's probably
harmless. 

> Failed to get list of devices\

Does the pointer and keyboard work? 

> ** $Id: TGQt.cxx,v 1.33 2006/10/04 16:08:48 antcheva Exp $ this=0xb12a70
> The font "symbol.ttf" was not installed yet
> Substitute it with "Arial"
> Make sure your local "~/.fonts.conf" or "/etc/fonts/fonts.conf" file  
> points to "$ROOOTSYS/fonts" directory to get the proper support for  
> ROOT TLatex class
> Error in <TUnixSystem::ExpandFileName>: input: $ROOTSYS/cint/include/ 
... <bla bla bla>

All these warnings has to do with some bugs in the Qt code.  The problem
is, that the Qt code does not take into account that one might install
ROOT without the use of the ROOTSYS environment variable (sigh!).  I'll
open a bug report on savannah.cern.ch and add a fix. 

Essentially, the problem is, that there's code like 

              static TString argvString ("$ROOTSYS/bin/root.exe");
              gSystem->ExpandPathName(argvString);
        
This should be coded as 

              static TString argvString (
        #ifdef ROOTBINDIR
        				 ROOTBINDIR "/root.exe" 
        #else
        				 "$ROOTSYS/bin/root.exe"
        #endif
        				 );
              gSystem->ExpandPathName(argvString);

which will take into account the `--prefix' setting done at configure time. 

All this could of course be avoided and done in a more robust way if
ROOT had something like: 

        struct TRootDirectories 
        { 
          static TRootDirectories& Instance() 
          { 
            if (!fgInstance) fgInstance = new TRootDirectories; 
            return *fgInstance;
          }
          const char* GetBinDir() const 
          {
            if (fBinDir.IsNull()) {
              const char* tmp = 0;
              if      ((tmp = gROOT->Getenv("ROOTBINDIR"))) fBinDir = tmp;
              else if ((tmp = gROOT->Getenv("ROOTSYS")))    fBinDir = Form("%s/bin", tmp);
              else                                          fBinDir = ROOTBINDIR;
              if (tmp) delete tmp;
            }
            return fBinDir.Data();
          }
          // Similar functions for other directories
        protected:
          mutable TString fBinDir;
          // Similar members for other directories
        };
        
A bit of care has to be taken though, for the daemons rootd and proofd. 

> To check e.g. library loading I tried 'gSystem.Load("libPhysics.so")'  
> and got again two Errors with qt and none without. The library seems  
> to work, though.

That's because the Qt backend adds wrong stuff to the library path. 

> >> I've put the .deb files on /afs/cern.ch/user/r/rkuhn/public/ 
> Keep in mind that they've been built on testing, not unstable. Should  
> work, but I thought I'd mention it.

These days, I think testing and unstable are close enough that it
doesn't hurt.  Thanks. 

> I'm doing some stress tests now. 

Great.  As far as I can tell, they all work, right? 

> Don't look too much at the  
> performance, I've only got a xen virtual machine on a single CPU host  
> system and memory is quite limited.

OK. 

> Info: TGeoManager::Import : Reading geometry from file: http:// 
> root.cern.ch/files/brahms.root
> Info in <TGeoManager::CloseGeometry>: Geometry loaded from file...
> Info in <TGeoManager::SetTopVolume>: Top volume is CAVE. Master  
> volume is CAVE
> Info in <TGeoManager::CloseGeometry>: Voxelization retrieved from file
> Info in <TGeoManager::CloseGeometry>: 2649 nodes/ 278 volume UID's in  
> brahms.C
> Info in <TGeoManager::CloseGeometry>: ----------------modeler  
> ready----------------
> Creating a local copy: brahms.root
> Info in <TGeoManager::Export>: Exporting brahms brahms.C as root  
> file. Optimizations streamed.
> File: brahms_ref.root does not exist, generating it
> *     stress brahms         : time/ref =   0.63/  1.30............ OK

Whoha, I didn't know you guys (ROOT team) had a copy of that.  Hmm.
Perhaps I should make you a better one one of these days. 


> I've not noticed any failures (stressGraphics seems to require the  
> creation of a file which I cannot write as non-root, 

Probably since you're executing in a directory where you have no write
access.  I'd suggest copying the `test' directory somewhere else (as a
normal user) and compile and run it there. 

> stressHepix  
> seems to want to call only the other stress tests, which fails  
> because I don't have '.' in my PATH, and I shouldn't be forced to).

No you shouldn't.  This is a mistake in the stressHepix program to
assume that. 

Having `.' in ones path is very _very_ bad and is frowned upon by any
serious administrator.   Suppose you have `.' in your PATH, and you cd
to some other users directory.   There you execute `ls'.  Now, what you
don't know, is that the other user has put a malicious version of `ls'
in her directory, say something that forks and runs some bad stuff in
the background, while executing `/bin/ls' in the foreground.

Someone please correct the function `runTest' in `stressHepix.cxx' to
read 

        void runTest(const char *atest, int estimate) {
           printf("Running : %s, (takes %d RT seconds on the ref machine)\n",atest,estimate);
           gSystem->Exec(Form("./%s >>stressHepix.log",atest));
        }

Yours,

-- 
 ___  |  Christian Holm Christensen 
  |_| |  -------------------------------------------------------------
    | |  Address: Sankt Hansgade 23, 1. th.  Phone:  (+45) 35 35 96 91
     _|           DK-2200 Copenhagen N       Cell:   (+45) 24 61 85 91
    _|            Denmark                    Office: (+45) 353  25 404
 ____|   Email:   cholm@nbi.dk               Web:    www.nbi.dk/~cholm
 | |



Reply to: