SAC software procedures

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. Configure.ac: Update the version of the component in the configure.ac
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 log > 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 https://ndpfsvn.nikhef.nl/cgi-bin/viewvc.cgi/mwsec/, which can be used with SVN in the following ways:

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

svn+ssh://svn@ndpfsvn.nikhef.nl/repos/mwsec/

SVN with https access:

https://ndpfsvn.nikhef.nl/repos/mwsec/

SVN with http access:

http://ndpfsvn.nikhef.nl/ro/mwsec/

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://svn@ndpfsvn.nikhef.nl/repos/mwsec/tags
cd tags
svn co --depth=immediates svn+ssh://svn@ndpfsvn.nikhef.nl/repos/mwsec/tags/glexec
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 http://software.nikhef.nl/security. The exact procedure is as follows:

• Make a clean/fresh check out the tag:

cd /tmp
svn co svn+ssh://svn@ndpfsvn.nikhef.nl/repos/mwsec/tags/glexec/0_8_10 glexec_0_8_10
cd glexec_0_8_10

• Run the ./bootstrap on fc14.testbed

cd ${topdir}
./bootstrap

• Run the ./configure on mwsecbuild.testbed

cd ${topdir}
mkdir BUILD
../configure

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:

software.nikhef.nl:/project/srv/www/site/software/html/security/<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 grid-mw-security@nikhef.nl.

Generating RPM packages from the distributed tarballs

The creation of RPM packages is automated with Cruisecontrol; this set-up guarantees a clean, reproducible build. The following procedure should be followed to trigger the generation of a new component build.

Procedure for building a new version

If there is a new source release of a component, the following steps need to be taken:

• put the source tar ball on the build machine
• Check the build dependencies
• update the SPEC file

Getting the sources

The source tarball needs to be downloaded to the build machine, as neither Cruisecontrol nor rpmbuild will do this automatically.

ssh usercc@span.nikhef.nl
cd /srv/project/rpmbuild/SOURCES
wget http://software.nikhef.nl/security/component/component-version.tar.gz

Check the build dependencies

A new release may introduce new build dependencies, or drop old build dependencies. The automated build procedure resolves build dependencies by drawing from the base CentOS repository and the EPEL repository. For build dependencies outside of these repositories, RPMs can be provided in a local yum repository

span.nikhef.nl:/srv/project/rpmbuild/RPMS/local-buildreq

After adding files there, run createrepo in that directory:

createrepo .

updating the SPEC file

• Check out the spec directory

svn co svn+ssh://svn@ndpfsvn.nikhef.nl/repos/mwsec/packaging/fedora/trunk

• 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.
• Add a ChangeLog entry to reflect the changes in this release, briefly. See [1] for guidance.
• Check in the spec file. Use the ChangeLog entry as the commit message.

This will trigger the build system. New RPM(s) should appear after a while in

span.nikhef.nl:/srv/project/rpmbuild/RPMS/

Procedure for updating a release

In the following cases a new RPM build needs to be done even if the sources did not change.

1. There is a bug in the way the RPM was build (e.g. wrong build dependencies)
2. There is a bug in the SPEC file, but the resulting RPM is already released
3. A RPM-only patch or fix that is not used upstream is required

In this case, it is not necessary to download the source tarball as it should already be there. The procedure is as follows:

• Check out the spec directory

svn co svn+ssh://svn@ndpfsvn.nikhef.nl/repos/mwsec/packaging/fedora/trunk

• Edit the spec file by increasing the Release: field by 1, but don't delete %{?dist}.
• Edit the spec file as necessary.
• Add a ChangeLog entry to reflect the changes in this release.
• Check in the spec file. Use the ChangeLog entry as the commit message.

All output should show up on

span.nikhef.nl:/srv/project/rpmbuild/(S)RPMS/...

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
RPMS
SOURCES
SPECS
SRPMS
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 generated RPMS should be distributed in a public, yum-installable repository. The repository is composed on span.nikhef.nl:/srv/project/mwsec with the following lay-out:

./el5
./el5/mwsec
./el5/mwsec/SRPMS            <- Here be the source RPMS
./el5/mwsec/SRPMS/repodata
./el5/mwsec/x86_64           <- This will hold the x86_64 RPMS
./el5/mwsec/x86_64/repodata
./el5/mwsec/i386             <- This will contain the i863 RPMS
./el5/mwsec/i386/repodata

The directories that contain the (S)RPMS are populated with symlinks to the rpmbuild directory, e.g.

lcmaps-1.4.28-1.src.rpm -> /srv/project/rpmbuild/SRPMS/lcmaps-1.4.28-1.src.rpm

At the moment, the symlinks will have to be made manually. Afterwards, run

cd /srv/project/mwsec/el5/mwsec/x86_64/ && createrepo .
cd /srv/project/mwsec/el5/mwsec/i386/ && createrepo .
cd /srv/project/mwsec/el5/mwsec/SRPMS/ && createrepo .

After this step, the repositories need to be synced with software.nikhef.nl:

rsync -rLt /srv/project/mwsec/ software.nikhef.nl:/project/srv/www/site/software/html/dist/redhat/

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

[mwsec]
name=Middleware Security Software
baseurl=http://software.nikhef.nl/dist/redhat/el5/mwsec/$basearch
gpgcheck=0

Generating Debian packages from the distributed source tarballs

TODO: this section is coming soon.