The Linux Foundation


From The Linux Foundation


Building an LSB Release

These are the steps needed to build an LSB release. The software steps (from "Build Packages" on) are per-architecture - with seven architectures (as of LSB 2.0) this is a very time-consuming process.

Each release is tracked by a single rollup bug which breaks out into individual rollup bugs at least for the major categories (spec, runtime tests, application tests, application battery, sample implementation, build environment) - add more categories as needed. For easy searching, these special bugs should be tagged with a keyword rollup. All blocker bugs need to be addressed for a final release.

A template completion checklist is provided at the end of this page, and these items at a minimum must be followed for a release (add more as appropriate).

Building a Module Test Release

Most of the same steps apply to test building an individual module intended as an add-on. The database changes should be applied to a local machine with a populated database, and the sources generated from there. There are two objectives to such a build: to make sure that the additions to support the module propagate to the spec and all appropriate tools and are correct; and that the existing content that is not part of this module did not change in any way. It's not necessary to execute the runtime test suites except for the ones which test the module itself. Additional appbat applications which exercise the libraries of the module should be folded in for the test build. The additions to the lsbsi should be built, installed, and subjected to appropriate testing.

Update Database

Database changes should be coordinated through a designated gatekeeper to keep developers from stepping on each other (there's no cvs-style conflict resolution on the live DB). The primary interface to the database is through the dbadmin interface on the web, and the copy on base1 should be considered the master. In some cases sql statements can be fed to the mysql command instead. When the database has changed, it should be dumped (make dump) in
and the dump checked in to cvs. The database changes need to be complete before the rest of the release steps can be completed.

Build Generated Sources

A database change requires some source files to be regenerated. Since a rebuild is not required very often, the generated source is checked in to cvs so that most users can just do a cvs checkout or cvs export and build without setting up the database. To regenerate source you do need the database set up. Do
make distclean
followed by
  • build_env/headers
  • build_env/stub_libs
  • tests/misc/elfchk
  • tests/misc/libchk
  • tests/misc/cmdchk
  • tests/misc/rpmchk
  • tests/misc/devchk/ts/devchk
  • lsbspec/ELF
  • lsbspec/LSB
  • lsbspec/Packaging
Builds can be kicked off in the toplevel directories: do a
and in
, and in the three
directories, do a
make gensrc
. If everything seems okay, check in the generated files.

TODO: add some "make check" type tests to the generation steps to try to validate early.

Generate/Build Specification

The Specification depends on files generated with the headers (see above) so it must be built on a system that also has the
directory checked out. The Specification must be built after the headers and db-generated pages are created.

See XXX for instructions.

Once the Specification is considered "Code Complete" it enters a phase where Release Candidates are produced in addition to daily builds. Release candidates are numbered X.yRCn. Once all bugs have been verified, and the formal review period has ended, a final Release candidate is built, and this version of the spec is then put to a vote in the Specification subgroup. Upon approval of the subgroup, the Specification shall be published as a final release, numbered X.yFinal. This version of the spec is then put to a vote in the LSB Steering Committee. Once approved, it is submitted to the FSG Board of Directors for signoff there.

Upon approval of the FSG BOD, the spec is rebuilt with the number X.y, and copied into the Reference Specification area. At this point, the specification is considered published.

CVS Tagging

As a product is actually released, the cvs tree for that product should be tagged. The naming convention is LSB_X_Y_Z, with the _Z omitted if not needed, as in LSB_3_0 and LSB_2_0_1. For the spec, test releases (betas, release candidates) should also be tagged. Once work is ready to begin on a new major version, a tag should be created to allow a branch - but don't create the branch until it is needed, since as soon as there's a branch developers need to consider whether their changes must be applied to multiple branches. The naming convention here is LSB_X_branch.

Development Packages

In the
directory, build and install lsb-build-base, lsb-build-cc, lsb-build-c++, lsb-libchk and lsb-appchk. To be strictly correct, lsb-build-c++ should be built last, and twice, as it uses itself to build. If there has not been a change to the base packages (gcc-core and gcc-g++) the rebuild may not be needed, although major changes to lsb-build-base do have the possibility of affecting it.

Symbol/Version Verification

  • Run libchk on an expected conforming platform (lsbsi?): no missing symbols or version mismatches. If there are mismatches, the database will probably have to be updated, which restarts the cycle.
  • Examine libchk debug new-symbol output, decide if variances are okay. We don't have to pick up all new symbols, but we should record our decisions on them.
  • Compile and run
    with cc and lsbcc, understand any failures and document. If there are database changes as a result of this process, the cycle will restart.
  • Build
    to check for interface prototype inconsistancies

Runtime Tests

XXX information incomplete

C++ test:

  • Need
    from application battery, which should be built and installed first.
  • Also need qm test harness. Do
    . TODO: move build area to
  • Do
    . TODO: move build area to

Application battery

  • We need to double-check that appbat applications that have not been uplifted at least have a release bump from the previous LSB release build. Since we're basically using the daily snapshots build for the final release, the underlying package content could be different than the LSB-(n-1) build due to underlying changes in the toolchain and build host. This also creates complications for dtk-manager when say for instance lsb-expect for both 3.1 and 3.2 has the same version/release.
  • Install
    , the LSB's informal build of a few development libraries (as .a's)
  • In
    , run
    . Resolve fatal errors by installing missing packages - usually -dev (or -devel) versions of packages that are not installed by default.
  • In
    , run
  • In
    , run
  • Install packages, step through the FVTs for this version described in
  • Install latest lsbappchk
  • Run lsbappchk on at least one binary from each appbat package. Remember that for binaries which use app-supplied shared libraries, like tcl, you need to tell appchk where to find them. TODO: isn't there a script which automates this now?
  • Run lsbpkgchk on each package.
  • TODO: add "make check" steps during appbat build to automate some of this testing - most packages have one (not proposed to start writing a bunch of stuff if packages don't have).

Sample implementation

  • In
  • Build lsbsi:
    make phase3 phase4
  • Create a test tree by unpacking lsb-core-arch, lsb-graphics-arch and lsb-test-arch
  • Run lsblibchk against lsbsi test tree (libchk should not be installed in the lsbsi, instead use LD_LIBRARY_PATH to point at the lib, usr/lib and usr/X11R6/lib (or *64, depending on architecture) in the lsbsi)
  • Copy lsbappchk and appbat rpms to the test tree's
  • Enter the lsbsi as a chroot
  • Install appbat applications and run FVTs as above
  • Install runtime tests (lsb_runtime_test, lsb_test_pam, lsb_test_vsw4, qm, qmtest_libstdcpp) and run. lsb-python is needed for the latter two.
  • TODO: add "make check" steps during lsbsi build so problems are caught early - most packages have one. Current nALFS profiles may provide an example.

Uploading Packages to FTP Site

  • Normal procedure is to upload packages to the beta directory even if they're for release. They can be moved over later - packages used for certification tests are required to have a "soak time".
  • There are four trees for packages on the ftp site:
  • Upload source rpm package to appropriate directory (e.g.
  • Upload source tar.gz package to appropriate directory (e.g.
  • Upload binary rpm package to appropriate directory (e.g.
    - some binary packages have an architecture subdirectory, some do not)
  • Test to ensure new packages show up properly on the download page

Completion Checklist Template

Generic IA32 IA64 PPC32 PPC64 S390 S390X X86_64
Runtime Tests n/a
X11 Tests n/a
C++ Tests n/a
Library Checker n/a
Command Checker n/a
Application Checker n/a
Package Checker n/a
Application Battery n/a
Build Tools n/a
Sample Implementation n/a
Release Notes n/a n/a n/a n/a n/a n/a n/a
Two Distros n/a
INT Review n/a
SC Vote

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