events
news
The Linux Foundation
 
 
RuntimeSourceBuildInstructions

From The Linux Foundation

Contents

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/3.1/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]





Retrieved from "http://www.linuxfoundation.org/en/RuntimeSourceBuildInstructions"

                        
            

            

	                      [Article]
                              [Discussion]
                              [View source]
                              [History]
                          

            

          


        
      


    





          






Copyright © 2008 Linux Foundation. All rights reserved.
 LSB is a trademark of the Linux Foundation. Linux is a registered trademark of Linus Torvalds.




Please see our privacy policy.