Re: New release of Debian ROOT packages - Development Snapshot

From: Christian Holm Christensen <cholm_at_nbi.dk>
Date: Mon, 30 Oct 2006 12:20:21 +0100


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_at_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_at_nbi.dk               Web:    www.nbi.dk/~cholm
 | |
Received on Mon Oct 30 2006 - 12:21:54 MET

This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:01 MET