Checkout and Build Helpful Hints

The g4svn tool

Geant4 uses g4svn for its interaction with a central SVN/subversion server ( This tool can be check out using:

svn co svn+ssh://${CERNUSER} g4svn_checkout
where ${CERNUSER} is the registered user name (kerberos principal) at CERN .

One can conveniently install it with:

cd ~/bin   # assuming this has been added to your $PATH
svn co svn+ssh://${USER} g4svn_checkout
ln -s g4svn_checkout/g4svn .
ln -s g4svn_checkout/g4svncode .

Passwords, passwords ...

During a normal g4svn interaction it will make several connections to the server, by default each will ask for your password. This gets tedious. Alternatively you can get a CERN kerberos ticket that is valid for that one terminal session.

Put this code in ~/.bash_profile (or equiv.):

function kcern() 
  # assumes ${USER} is your CERN principal if unspecified
  if [ -z "$1" ]; then USERCERN=${USER}; else USERCERN=$1 ; fi
  export KRB5CCNAME=/tmp/${USERCERN}.cern.krb5.cache
  echo $'\e[32m''SETTING UP'$'\e[31m'' CERN '$'\e[32m''KRB5 CACHE'$'\e[0m'
  echo $'\e[32m''good for this terminal session via KRB5CCNAME='$KRB5CCNAME$'\e[0m'
  kinit -f -p -A -c $KRB5CCNAME ${USERCERN}@CERN.CH
Then it will be available for future sessions; if you need to use it immediately issue the command: source ~/.bash_profile.

Then when needed use g4svn, first do:

  kcern             # if your FNAL ${USER} == your CERN principal name
  kcern ${CERNUSER} # otherwise
Authenticate with your CERN password.

If later you need access to your FNAL kerberos ticket in that terminal session, simply unset KRB5CCNAME.

Connection Oddities

If you find that g4svn seems to stall and never proceed, do the following check:

   ssh -v -v -v ${CERNUSER} 
and see if it also stalls at the point called out below:
debug1: identity file /home/${USER}/.ssh/id_ecdsa type -1
debug1: identity file /home/${USER}/.ssh/id_ecdsa-cert type -1
   <=== gpvm + stalls *here*, correct behaviour continues with:
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
[...authentication debug messages are down here ...]

This is because on (many/most) of the GPVMs the environment variable LC_COLLATE="C" set, and while this doesn't cause access issues to nodes, it does cause issues when connecting to

The solution is simple:

export LC_COLLATE="en_US.UTF-8" # default is "C" on these systems

(You might just put that in your ~/.bash_profile).