Symas OpenLDAP Knowledge Base

Build Process Instructions

Build Servers

Host Type RHEL4 64bit RHEL4 64bit RHEL5 64bit RHEL6 64bit Debian 6 32bit Debian 6 64bit Debian 5 32bit Debian 5 64bit OpenSuSE 12 64bit Debian7 64bit

Archive Steps

  1. SSH to

  2. SSH to build machine

  3. ls -lS /home/build to list all files by sizes

  4. Contact large file owners and request permission to archive

  5. Tar files to be archived (note: run as sudo to compact all jobs)

cd /home/build

sudo tar czf symas.tgz symas-/*

  1. SSH to and browse to /BUILD_ARCHIVE/RHEL4 (or OS specific folder) (archive storage location)

  2. Download file from build box to using the following command:

sudo scp jtrupp@:/home/build/.tgz .

Enter password

Rename to SOL format using sudo mv

  1. Browse to /home/build folder on buildbox and delete all files archived including .tgz file

***NOTE: Complete this step before proceeding with the build!

Prep Steps

  1. SSH to

  2. SSH to build machine

  3. CD /home/build

  4. Make sure that there are no pre-existing installs of SOL or SUUM. They will break the build! To do this run the following command for build type:

        RHEL & SuSE 
                     rpm -qa | grep symas 
                     dpkg --list|grep symas 
                     pkginfo | ggrep -Ei '(symas|suum)' 
                     (not specified) 
                     (not specified) 
                     lslpp -l | grep symas 
  5. You will also need to clean up /tmp due to a perftools bug. The following line removes all the perftool stuff and more:

        sudo rm -rf /tmp/lt-heap* /tmp/sampling_test_dir /tmp/pprof* /tmp/perftool* /tmp/heap_profile_info /tmp/krb* 
  6. Check that you have enough free space for the build. (Off-hand 3 gigs is a medium estimate)

        sudo df -h 
  7. If releases are not already on build machine, copy them from crwth:/tmp//<#>/***.tgz to /home/build

sudo scp crwth:/tmp//<#>/.tgz /home/build/

  1. Make sure Release Notes are updated

        In Stash (Sold/RelNotes.txt) 
        Use Diff to see changes 
        vl RelNotes.txt 
                     Add any changes necessary, save and exit 

Build Steps

  1. Pull in new build source using git clone command included in build request email

     Example: git clone --recursive ssh:// sold- 
  2. CD to build directory (sold-2.. created by git clone command)

  3. Checkout the build

     Example: git checkout symas- 
  4. Download submodule updates by running following command:

     git submodule update 

***NOTE: Notify Matt if errors encountered during this process

  1. Enter git status to see branches

  2. CD into branch to see what submodules have been updated

  3. With multitail installed:

     make #first make that will err 
     make > build.log 2>&1 && make test > test.log 2>&1 & 
     touch test.log; multitail -cs -i build.log -cs -i test.log 

    Without multitail:

     make #first make that will err 
     make > build.log 2>&1 && make test > test.log 2>&1 & 
     touch test.log; tail -f build.log -f test.log 
  4. Regenerate version.var by running following command:

     make (regenerates version.var and exits) 
     nohup make > make.log 2>&1 & 

Build Check

Assuming everything finishes you’ll want to take a look at your log files. Build.log should finish with a list of system packages and .info files. Test.log should finish with an announcement that all tests passed. Note that on machines that build for multiple architectures test.log is a concatenation of the testing for both.

Run this command for respective environment:


      grep -B 1 -A 1 -E '([>=])\1{2,}' test.log -n --color=always| grep -iE 'fail(ed)?' --color -A 2 -B 1 


      ggrep -B 1 -A 1 -E '([>=])\1{2,}' test.log -n --color=always| ggrep -iE 'fail(ed)?' --color -A 2 -B 1 

 Normal Failures: 

      Three failures of test_nist2 in heimdal.  Same failure we always see. 

      One failure of test058-syncrepl-asymmetric for bdb in the nonopt package 

Running individual tests:

 Find copies of the test run binary. 

 In the base of the build directory type: 

      find . -name run 

 Choose which 'run' to use based on what failed then execute the test: 

      ./run <testname> 

Core File Check

 Core files are often generated when a test fails and can point you towards the problem area. Often, with OpenLDAP projects, there is already a patch  

 for the issue upstream. 

 In the base of the build directory run: 

      find ./build/ -name core\* -type f |xargs file |grep -E '(core file|empty)' 

 NOTE: Currently having a slew of core dumps from the perftools tests is ""normal"". We only use libtcmalloc but this SHOULD be fixed at some point.