RuntimeSourceBuildInstructions

From The Linux Foundation
Jump to: navigation, search

lsb-runtime-test Source Build Instructions

This document has instructions on how to build the source for the lsb-runtime-test.

Assumptions

  • BZRTREES should be set to the path where the runtime-test branch lives, if the default is not appropriate
  • SOURCES is set to the system default rpm sources/patches directory, such as
    /usr/src/redhat/SOURCES
    on RHEL or
    /usr/src/packages/SOURCES
    on SLES

Building Steps

1. Update the ChangeLog files for the test suites

a. Make sure you have an up to date branch of the test tree.
bzr branch http://bzr.freestandards.org/lsb/devel/runtime-test
a. In each of the subdirectories of lsb-runtime-test/modules run
createChangeLog.pl (createChangeLog.pl can be found in the /tools/scripts directory).
If you get warning about an unknown username
the perl script needs updating with another username -> realname mapping.
If this happens you'll need to update the perl script, remove the
ChangeLog file do a "cvs update ChangeLog" then rerun the perl script.
NOTE: createChangeLog.pl is not useful since the conversion to bazaar.
Doing a cvs diff on the ChangeLog file is also a useful way of summarising
the changes made since the perl script was last run.
You need to do this for the usergroups directory in the lsb-runtime-test
directory. It really should be in the modules directory but accidentally
was checked into the wrong place. Moving this directory would be a good
idea but requires access to the CVS repository and you should tell
everyone when you move it.
a. Commit the changes to the ChangeLog files.
# cd $LR
# cvs -z9 commit

2. Building new lts_* source test suite modules

a. Checkout a version of the test suites without the CVS directories.
Do this in a temporary area.
# cvs -z9 export -D now tests/lsb-runtime-test
a. Get most recent version of lsb-runtime-tests suite tarball from
the ftp site,
extract the test suites source lts_* and tet_vsxgen tarball files.
For each of them, create a subdirectory (since they all unpack directly
into the current directory) and unpack the related tarball into the
subdirectory.
a. For each of the test suite source modules do a diff (dirdiff is highly
recommended - see the reference section at the end of this document)between
what was exported and the latest release. This should show you all
the changes and you can double check that nothing nasty has accidentally
crept into the system. It is also useful (along with the ChangeLog) in
writing the release notes (eg what people can expect to change with the
test suites). For those test suite modules which have no changes you
obviously don't need to release a new version of that test suite.
a. For the test suites which do need updating, cd *into* the subdirectory,
update the files needed to be updated using what exported from the CVS tree
(using cp -p command to keep tracking the mode, ownership and timestamps
information), and then create a new tarball. Please change the versions
accordingly as the instructions of appendix.
(Remember to create the tarballs such that they will unpack directly
into the current subdirectory)

3. Building tet_vsxgen tarball

a. The files contained in this tarball comes from 3 sources: TET,
vxgen and LSB specific changes. So not all of the tarball is stored in
CVS. We should just merge in the changes into the tarball which
have been changed and bump the minor version when doing so.
Occasionally the Open Group release updated versions of TET or
vsxgen and we have been merging them in. Just need to be very careful
when doing this as there are some LSB specific changes and
the test suites need to be well tested after doing so.
a. Most of the files and directories unpacked from the most recent tarball
come from TET 3.6 (so keep them untouched in normal case) except test_sets
and LSB.tools. The following are where they come from:
  • test_sets tests/lsb-runtime-test/harness/vsxgen
  • LSB.tools/psldefs tests/lsb-runtime-test/harness/psldefs
  • LSB.tools/psldefs-glibc2.1 tests/lsb-runtime-test/harness/psldefs-glibc2.1
  • LSB.tools/tbin tests/lsb-runtime-test/harness/vsxgen/TESTROOT/BIN
Do a diff for these files to check whether they are changed since
last release. If they are changed, update them accordingly.
a. Create a new tarball for tet_vxgen tarball if you update the files.
Please change the versions accordingly as the instructions of
appendix.

4. Building new lsb-runtime-tests source tarball

a. When unpacking most recent version of lsb-runtime-tests suite tarball
in step 2, we'll get two extra files except test suites source lts_*
and tet_vsxgen tarball files, which are README and install.sh. They come
from:
  • install.sh tests/lsb-runtime-test/scripts/build
  • README tests/lsb-runtime-test/scripts/runtime
a. Do a diff for these two files to check whether they are changed since
last release. If they are changed, update them accordingly.
a. Create a new temporary directory and copy the new (or unchanged) lts_*
and tet_vsxgen tarball together with the above two files into a it.
And then cd *into* this directory, and create a new lsb-runtime-tests source
tarball. Please change the versions accordingly as the instructions of
appendix.
(Remember to create the tarballs such that they will unpack directly
into the current subdirectory)

5. Building necessary scripts tarball

a. The necessary scripts used in building lsb-runtime-test suites includes
build_scripts, install_scripts and tjreport, which are not changed very
frequently. Since the files in the CVS tree are not all used, you have
to check whether to build new tarball for them all.
a. Get most recent version of script tarballs from
the ftp site,
For each of them, create a subdirectory (since they all unpack directly
into the current directory) and unpack the related tarball into the
subdirectory.
a. For each of the scripts, do a diff between the files unpacked from the
tarballs and what was exported from the CVS tree. The relations where the
files come from are as followings:
  • build_scripts tests/lsb-runtime-test/scripts/build
  • install_scripts tests/lsb-runtime-test/scripts/runtime
  • tjreport tests/lsb-runtime-test/scripts/support
Make sure whether you need to release a new version of script.
a. For the scripts which do need updating, cd *into* the subdirectory
and create a new tarball. Please change the versions accordingly as the
instructions of appendix.
(Remember to create the tarballs such that they will unpack directly
into the current subdirectory)

6. Building a source rpm

a. The next stage is primarily to build a source rpm, and a binary
rpm for one architecture is got as a side effect.
a. Firstly cd *into* the $SOURCES directory, and copy the new (or unchanged)
lsb-runtime-tests, build_scripts, install_scripts and tjreport tarball
into current directory.
a. Copy lsb-test-runtime.spec file from tests/lsb-runtime-test/scripts/package,
and update necessary information (version numbers, source files,
description, changelog etc).
a. The build itself is straightforward. In current directory, input:
# rpmbuild -ba lsb-test-runtime.spec
(It needs root privilege to build the source rpm, so just wait the message to
input root password. And don't type anything in other way, otherwise the expect
script cannot behave correctly.)
This will produce a binary and source rpm. It is definitely
worth installing and testing the binary rpm before going any further
to make sure that everything is ok, otherwise you have to rebuild
for all the other architectures anyway.

7. Rebuilding the binary on other platform

After getting source rpm, we can rebuild it on other platform:
# rpmbuild --rebuild source_rpm
It is important that all of the binary rpms are build from the source
rpm rather than using the rpmbuild command with the spec file. This
ensures that exactly the same source is used for all of the architectures.

Appendix

Understanding the naming and versioning conventions for files

Versioning

A.B.X.Y

A.B refers to the specification version.

X refers to the major version of the test framework (ie the tet/vsxgen tarball) needed to install/run the test suite. For test suites which don't need the framework just use 0 here.

Y refers to the version of the test suite itself

Naming

Files that start with:

lts_ - This test suite requires the TET/VSXgen framework

tet_vsxgen_X.Y.tgz - X.Y refers to major/minor version number for the TET/VSXgen framework contained in this tarball. Test suites which require a certain version number of this framework refer to the major number and any minor version will work (though later ones should work better)

So in most cases we will only need to bump the last number (Y).

Reference

Highly recommend using dirdiff to do the diffs. Its is really good at highliting what has changed. You can get it from: [1]