SAC software procedures

From PDP/Grid Wiki
Jump to navigationJump to search

This page contains several procedures regarding the release process of the Grid Security Middleware.

Source distribution release procedure

This is the Software release procedure for Grid Security Middleware. This page describes that what to do when your software is ready for public distribution as source tarball. These tarballs can be used by anyone who likes to do their own local builds, but they are also used to generate RPM (Red Hat) and deb (Debian) packages.

Mandatory Check list

  1. make distcheck: sh bootstrap && ./configure && make distcheck must result in "Ready for distribution"
  2. Update the version of the component in the
  3. BUGS: Updated the BUGS file in the component directory with known issues
  4. NEWS Updated the NEWS file: write release notes like information. Hint which version solves the problem.
  5. ChangeLog: a "svn update ; svn log -v > ChangeLog" for the time being.
  6. INSTALL: Update installation instruction file (if applicable)
  7. README: Update the README file with more useful information
  8. Be sure to perform an svn ci here
  9. create a tag in the version control system.

Extra info: Source repository details

The main source repository for these components is, which can be used with SVN in the following ways:

SVN with SSH public key authentication (NB. username is always svn):


SVN with https access:

SVN with http access:

Creating a tag in Grid Security Middleware

We take the example for glexec, but this will be a valid set of sets for any component:

  • Go to the trunk, and make sure it's up to date:
# For glexec:
cd mwsec/trunk
svn update
cd ..
  • Check out the tags directory for the component exclusively:
svn co --depth=empty svn+ssh://
cd tags
svn co --depth=immediates svn+ssh://
cd glexec
  • Copy the HEAD from trunk into the tag directory, the directory name is only named by it's version:
svn copy ../../trunk/glexec 0_8_2
cd 0_8_2
  • Make a list of the used SVN externals. Resolve the externals as local files for each tag:
svn propget svn:externals > my_externals.txt
  • Make a list of the files associated to each external and remove the externals in the current SVN directory:
svn propdel svn:externals
  • For each entry in the my_externals.txt file and each file associated to them do something like:
rm -rf src/{safefile-1.0,environ,realpath,fileutil}
svn copy ../../../trunk/cgul/{safefile-1.0,environ,realpath,fileutil} src/
rm -rf m4
for i in project/*.m4 ; do mfour=`basename $i`;svn cp --parents ../../../trunk/m4/${mfour} m4/${mfour} ; done
rm my_externals.txt
cd ..
  • (easier than the above, just for the m4 macros which is the most common case, DO NOT USE FOR gLExec and EES:)
svn propdel svn:externals
rm -rf m4
for i in project/*.m4 ; do mfour=`basename $i`;svn cp --parents ../../../trunk/m4/${mfour} m4/${mfour} ; done
  • Commit!
svn commit

Release software as tarball

The software tarballs should be released and made available for download in The exact procedure is as follows:

  • Make a clean/fresh check out the tag:
cd $HOME/your_clean_dir/
svn co svn+ssh:// glexec_0_8_10
cd glexec_0_8_10
  • Run the ./bootstrap on fc14.testbed
cd ${topdir}
  • Run the ./configure on mwsecbuild.testbed
cd ${topdir}
mkdir BUILD && cd BUILD

This is required to have consistency in the versions of the autotools that are used in the distributed software.

  • Create release tarbal:
make distcheck
  • generate a SHA1 and SHA256 checksum of the tarball and place it in a file with the same name but with the .sha1 extension.
sha1sum <component>-<version>.tar.gz > <component>-<version>.tar.gz.sha1
sha256sum <component>-<version>.tar.gz > <component>-<version>.tar.gz.sha256
  • Copy the tarball and the sha1 and sha256 checksum files to:<component>/release-candidate/
  • Verify that this tarball can be used for packaging, and that the packaged software works.
  • After sufficient certification, release the software by moving it to to the parent directory, and have the release manager sign the hashes by putting them in a GPG-signed e-mail to

Generating RPM packages from the distributed tarballs

Note: we're making the transition to using koji for automating most of the following steps. See The Koji Testbed page for more information. The creation of RPM packages involves the following steps.

  • Creating a source RPM from the source tarball(s) and SPEC file (on an EL5 machine, e.g. mwsecbuild.testbed);
  • creating a binary RPM from the source RPM by running a mock build (on a reasonable modern mock >= 1.0.7);
  • copying the resulting RPMs (source and binaries) to the mock repository on

For distributing the results more steps are necessary, see below.

Procedure for building a new version or building a new release

The following steps need to be taken:

Update the SPEC file

  • Check out the SPEC directory from the SVN repository (always use trunk):
    svn co svn+ssh://
  • Edit the spec file
    For a new version (the source has changed):
    • Edit the spec file by updating the Version: field to correspond to the new version.
    • Reset the Release: field to 1, but don't delete %{?dist}.
    • Update build dependencies if necessary.
    For a new release (the source has not changed):
    • Edit the spec file by increasing the Release: field by 1, but don't delete %{?dist}.
  • Add a ChangeLog entry to reflect the changes in this release, briefly. See Fedora Guidelines for guidance.
  • Check in the spec file. Use the ChangeLog entry as the commit message.

Generating the source RPM

The source RPM must be generated on an EL5 machine, because EL5 and older systems have a version of RPM that doesn't understand the new SHA1 checksum.

Get the sources from the official software distribution:


Get the SPEC file:


Build the source RPM:

rpmbuild --define "_tmppath /tmp" --define "_sourcedir ." --define "_srcrpmdir ." --nodeps -bs component.spec

This will leave the source RPM in the current directory. This needs to be transferred to the mock build machine.

Alternatively one can use mock (see also Generating the binary and source RPMs):

mock -r epel-5-x86_64 --spec=component.spec --sources=. --resultdir=mock/result --buildsrpm

This will leave the source RPM in mock/result.

Generating the binary and source RPMs

Copy the source RPM to a relatively new mock build machine, e.g. CentOS 6, Fedora Core 14 or higher or Ubuntu :-).

The configuration to be used should be tuned to include the stable mwsec repository at, see mwsec mock setup for details.

Now run mock:

mock --clean -D 'dist .el5' -r mwsec-el5-x86_64 --configdir=mock/config --resultdir=mock/result/64 --rebuild component.src.rpm
mock --clean -D 'dist .el5' -r mwsec-el5-i386 --configdir=mock/config --resultdir=mock/result/32 --rebuild component.src.rpm

This creates source and binary RPMS in mock/result/{32,64} using the configuration setup from mock/config/ NOTE: the explicit setting of the %dist macro is needed to prevent it from becoming the new Centos standard .el5.centos.

On fc14.testbed these configs are installed in the standard directory, and the --configdir option should be left out. In addition, on this machine, two configs which also enable the mwsec testing repo have been installed: mwsec_testing-el5-x86_64 and mwsec_testing-el5-i386. These should only be used for either testing purposes or in rare circumstances when multiple packages need updating at the same time.

Publishing the created binaries

The next steps are

  • upload the mock-created binary and source RPMS to the corresponding directories in
  • create symlinks for the binary RPMS in
  • create a symlink for the source RPM in
  • after the new release has been certified, create symlinks for the binary RPMS in, pointing to those in the testing repository.

See Distribution release of RPMS for further details.

Generating RPMs manually

The above procedure produces 'official' RPMS, in a reproducible way from a clean build environment. However, it is possible to generate RPM packages manually with a simple recipe.

This procedure should work on a machine that matches the build target, i.e. CentOS 5 x86_64 or i386.

  • Create a file called .rpmmacros with the following content:
%_topdir  /home/username/rpmbuild
%_tmppath /home/username/rpmbuild/tmp
  • Create a directory rpmbuild in your home directory, with the following subdirectories:
BUILD -> /tmp/username/rpmbuild/BUILD
tmp -> /tmp/username/rpmbuild/tmp
  • create the tempdirs if necessary
mkdir -p /tmp/`id -un`/rpmbuild/{tmp,BUILD}
  • Check out the SPEC directory
  • test the build dependencies by running rpmbuild specfile
  • Install build dependencies as necessary
  • Run rpmbuild -ba specfile to generate binary and source RPMs.

Adding a new component and/or build target

This procedure is not yet worked out.

Distribution release of RPMS

Warning: this procedure is not yet finalised.

The RPMS should all be on at this time.

The generated RPMS should be distributed in a public, yum-installable repository. The repository is composed on with the following lay-out:

./el5/mwsec/SRPMS            <- symlinks to mock
./el5/mwsec/x86_64           <- symlinks to testing
./el5/mwsec/i386             <- symlinks to testing
./testing/el5/mwsec/i386            <- symlinks to mock
./testing/el5/mwsec/x86_64          <- symlinks to mock

The el5 and testing trees do not contain actual RPMS, but symlinks:

  • the testing RPMS are symlinks to the repective RPMS in mock
  • the el5 binary RPMS are symlinks to the respective files in testing
  • the el5 source RPMS are symlinks to the respective RPMS in mock

The noarch RPMS in mock are symlinked in both x86_64 and i386 (cf. the EPEL repository).

The layout of mock is


After updating the el5 and/or testing directories, update the repodata:

createrepo /srv/project/mwsec/el5/mwsec/SRPMS/
createrepo /srv/project/mwsec/el5/mwsec/i386/
createrepo /srv/project/mwsec/el5/mwsec/x86_64/
createrepo /srv/project/mwsec/el5/mwsec/noarch/
createrepo /srv/project/mwsec/testing/el5/mwsec/i386/
createrepo /srv/project/mwsec/testing/el5/mwsec/x86_64/
createrepo /srv/project/mwsec/testing/el5/mwsec/noarch/
chmod -R g+w /srv/project/mwsec

After this step, the repositories need to be synced with

rsync -rltpgv --copy-unsafe-links /srv/project/mwsec/

Using this repository in a YUM repo file requires something like the following:

name=Middleware Security Software

Generating Debian packages from the distributed source tarballs

Main article: SAC Debian packaging.

With every new release of a software package, the Debian packages for various supported distributions (Debian as well as Ubuntu) need to be updated.

All of the software components that have already been debianized can be updated using the following steps. Of course, any serious changes in the software need to be reviewed carefully, especially when it comes to shared library symbols.

These steps assume that you've set up your personal Debian toolset.

Building e.g. for Debian squeeze

  • svn-buildpackage -S
  • cd ../build-area/
  • dpkg-source -x <component>_<version>-1.dsc
  • cd <component>-<version>
  • dch -D squeeze -b -v <version>-1~bpo60+1 "Rebuild for squeeze"
  • dpkg-buildpackage -S
  • cd ..
  • cowpoke --dist=squeeze --arch=amd64 <component>_<version>-1~bpo60+1.dsc
  • cowpoke --dist=squeeze --arch=i386 --dpkg-opts=-B <component>_<version>-1~bpo60+1.dsc

Putting the results in the main repository

  • ssh ref-debian6-64.testbed
  • dput mwsec-squeeze /var/cache/pbuilder/squeeze-amd64/results/<component>-<version>-1~bpo60+1_amd64.changes
  • dput mwsec-squeeze /var/cache/pbuilder/squeeze-i386/results/<component>-<version>-1~bpo60+1_i386.changes
  • rsync -a -vP --delete /var/local/debian-repository/debian/