From The Linux Foundation

1 Building an LSB Release
- 1.1 Building a Module Test Release
2 Update Database
3 Build Generated Sources
4 Generate/Build Specification
5 CVS Tagging
6 Development Packages
7 Symbol/Version Verification
8 Runtime Tests
9 Application battery
10 Sample implementation
11 Uploading Packages to FTP Site
12 Completion Checklist Template

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

specdb

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

make

.

```
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

make

in

build_env/stub_libs

and in

tests/misc

, and in the three

lsbspec

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

build_env/headers

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

packaging

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
```
tests/misc/devchk/ts/devchk
```
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
```
tests/misc/dynchk
```
to check for interface prototype inconsistancies

Runtime Tests

XXX information incomplete

C++ test:

Need
```
lsb-python
```
from application battery, which should be built and installed first.
Also need qm test harness. Do
```
make
```
in
```
tests/qm/package
```
. TODO: move build area to
```
packaging
```
directory.
Do
```
make
```
in
```
tests/qmtest_package
```
. TODO: move build area to
```
packaging
```
directory.

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
```
lsb-build-libbat
```
, the LSB's informal build of a few development libraries (as .a's)
In
```
appbat
```
, run
```
./configure
```
. Resolve fatal errors by installing missing packages - usually -dev (or -devel) versions of packages that are not installed by default.
In
```
appbat
```
, run
```
make
```
In
```
appbat/rpm.new
```
, run
```
make
```
Install packages, step through the FVTs for this version described in http://www.linuxbase.org/appbat/cert.html
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
```
si/build
```
run
```
./Configure
```
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
```
/tmp
```
directory
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:
```
app-battery
```
,
```
impl
```
,
```
lsbdev
```
and
```
test_suites
```
Upload source rpm package to appropriate directory (e.g.
```
pub/lsb/test_suites/beta/source/runtime
```
)
Upload source tar.gz package to appropriate directory (e.g.
```
pub/lsb/test_suites/beta/source/runtime
```
)
Upload binary rpm package to appropriate directory (e.g.
```
pub/lsb/test_suites/beta/binary/runtime
```
- 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
Specification
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]