From The Linux Foundation
Revision as of 16:38, 18 January 2008 by Tytso (Talk | contribs)

(diff) ←Older revision | view current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

A page describing the LSB 3.2 project. Rather than a "conventional" project plan, it's been an evolving placeholder for describing things that are going on - it is a wiki page after all. Now close to the release, it has been firmed up a bit and shouldn't be changing much except to update status.

LSB technical work is tracked through bugs and wiki pages. Smaller tasks should have at least a bugzilla entry; large tasks should have their own wiki page and probably should have bugs as well. Add links to those resources on this page. LSB uses bugs with "blocker" entries to search on work to be done, work completed when writing release notes, etc. The tracking bug for the overall LSB 3.2 release is bug 1310.

Bugs blocking the LSB 3.2 release can be found here, using a Bugzilla search.

Task List for release

Please list tasks to be done for the release here; just link to the actual section where the task is described. As tasks are done, please remove them from this list.


This tracks new things to be added to LSB 3.2.

Core Module

The lsb-core module is tracked through bug 1302


Some research on the new glibc 2.4 was done and described at NewGlibc. [Note: the glibc versioning scheme has changed such that instead of 2.4.1, 2.4.2, etc. 2.4, 2.5 and 2.6 have all been released, so here "2.4" refers generically to releases later than the 2.3.x series] Because of the timing - distros supporting LSB 3.2 may not have made the library switch yet - nothing unique to glibc 2.4 or later is an LSB 3.2 target. However, there are other items on that page that are not 2.4 specific that could be considered, as they are interfaces that existed earlier than 2.4 but are not in the LSB for various reasons, which may include code maturity, availability of supporting kernel functionality, etc. Some of those reasons may no longer be blockers in the LSB 3.2 timeframe: the criteria may be met. These include:

  • __xpg_basename bug 1430, __xpg_strerror_r bug 1256, __xpg_sigpause bug 1486. Complete
  • POSIX message queue interfaces (MSG set) bug 1388. Complete
  • POSIX advisory information interfaces (ADV set) bug 1389. Complete
  • POSIX spawn interfaces (SPN set) bug 1390. Complete
  • POSIX threads interfaces (BAR, SPI, TCT sets) bug 893. Complete

The __xpg functions should all three be in the binary standard, and the build environment should be adjusted such that calls to the base functions use the underlying functions. Currently the specification says these functions work like POSIX but we're getting the traditional/non-POSIX behavior so there's a mismatch between spec and implementation.

These are added. There's work ongoing on the "normal" level of tests for these, although a full set won't be ready in time for the 3.2 issue. Also, these added sets all have some coverage in the Open POSIX Test Suite.

Requested Interfaces, Previously Excluded


  • pselect bug 1392. Complete
  • sendfile. is not likely for 3.2.

pselect is in POSIX; seems to have been forgotten. sendfile was previously intentionally left out (see old bug 25), unclear if one can count on it to "work everywhere" (filesystem support is the current question)


  • pthread_mutex_timedlock bug 1646. Complete

In Posix, seems to have been forgotten.

File I/O

Seems to have been forgotten; we have readdir_r and readdir64.

Memory Interfaces

  • mremap (bug 1578). seems rather widely used. Complete
  • mallinfo, malloc_trim, mallopt. There are no Linux manpages on these, but there are GNU notes on mallinfo and mallopt. Note the mallopt options from SVR4/SVID/old-SUS are defined but don't do anything; glibc has their own set. At LSB F2F November 2007, we decided to put off mallopt, although it is a candidate; mallinfo is probably not a candidate, and malloc_trim may need some more discussion. See ISV Requested Interfaces.

Network Interfaces

A number of "traditional" networking interfaces are not part of the LSB but are still very commonly used in applications.

  • Network interfaces (gethostby*, getservby*, inet_aton). gethostyname_r and gethostbyaddr_r are described by bug 1634 Complete; inet_aton is described by bug 1696 Complete. gethostyname2 and gethostbyname2_r are described by bug 1742 Complete
  • RPC interfaces. Turns out the set is quite incomplete. bug 1546 (so far, three macros added). Reconciling the more complete set is deferred to LSB 4.0.
  • XDR interface xdrstdio_create also bug 1546 Complete
  • NIS-related interface getdomainname. bug 1697 Complete
  • IPv6 data in6addr_any, in6addr_loopback. These seem pure omission. bug 1311. Complete

While some of these either are not in POSIX or are considered obsolete, they do meet the general criteria of "everybody has them" (where "everybody" is a wider set than GNU/Linux/glibc). Some are controversial, see for example [1] and [2]

Socket ioctls

There's been a request for adding more. The set which seems to be a candidate, with already-included ones in bold: SIOCGIFNAME, SIOCSIFNAME, SIOCSIFLINK, SIOCGIFCONF, SIOCGIFFLAGS, SIOCSIFFLAGS, SIOCGIFADDR, SIOCSIFADDR, SIOCGIFDSTADDR, SIOCSIFDSTADDR, SIOCGIFBRDADDR, SIOCSIFBRDADDR, SIOCGIFNETMASK, SIOCSIFNETMASK, SIOCGIFHWADDR. The specific request was for SIOCGIFBRDADDR: bug 1410. SIOCGIFHWADDR is used in MySQL. There's always been some resistance to adding "set" ioctls, while "get" ones have been less controversial. Update: the missing "get" ioctls went in to the 3.1 update

Fcntl functionality

Some async signal behavior can be controlled through fcntl() calls using F_GETSIG/F_SETSIG. According to the manpage,

F_GETOWN, F_SETOWN, F_GETSIG and F_SETSIG are used to manage I/O availability signals ...
Using these mechanisms, a program can implement fully asynchronous I/O without using select(2) or poll(2) most of the time.
The use of O_ASYNC, F_GETOWN, F_SETOWN is specific to BSD and Linux. F_GETSIG and F_SETSIG are Linux-specific. POSIX has asynchronous I/O and the aio_sigevent structure to achieve similar things; these are also available in Linux as part of the GNU C Library (Glibc).

Since we don't have POSIX AIO either, there seems to be no way to get at this kind of functionality. Is this worth adding, even if it's Linux-specific? O_ASYNC, F_GETOWN, F_SETOWN are included in LSB. Tracked as bug 1314.

Sysconf functionality

Issues such as obtaining the number of processors have surfaced occasionally. The sysconf() function provides a standard way to query the system configuration at runtime, but the LSB requires only the queries (_SC_ macros) defined in POSIX, and normal Linux usage defines far more queries. These additional sysconf macros should be examined for possible inclusion. Similar considerations may apply to pathconf(). Tracked as bug 1454. Complete

PAM interfaces

Two new interfaces, pam_getenv and pam_putenv were added to libpam, as they seemed to have been forgotten. bug 1695. Complete

C++ Module

Preserve the status quo. There may need to be fixes to the build tools to preserve compatibility with libstdc++ from gcc 3.4. Verify that gcc 4.2 can still build backward-compatible binaries, and that lsbcc can persuade it to do so.

There may be some other issues in CXX Developments.

Graphics Module

Note that as of LSB 3.1, the lsb-graphics module no longer appears as a separate "book"; the categorization refers to the internal module which still exists even though it's now bundled into a bigger book as the spec is published.

Existing Graphics module

  • A request has been made to insure the Shape extension in libXext is at version 1.1. LSB has not specified extension module versions in the past, in fact it does not even require a particular extension to exist, just the library which is used to access it. Applications are expected to query if the extension exists before using it. In this case, functionality important to Accessibility is added in extension version 1.1. The only API change is an additional flag value which is passed to one of the existing interfaces. On a current distro these versions are provided by the extensions in the LSB: Shape 1.1, Shm 1.1, evi 1.1, so Shape 1.1 may already be "best practice" (more research needed). Note applications are able to query the extension version through a specified interface, so LSB may not need to require anything.

New X11 libraries

  • libXrender. See previous section for additional discussion on extensions and extension libraries. Requested to enable functionality needed for Accessibility. Versions of these found on a current distribution: Render 0.10. Update: Xrender extension library is imported into LSB. For spec, there may an older document online that can help, [3]
  • Proposed libary: Xft - interface between the freetype library and the Render extension. Needed to provide reasonable internationalized character handling without having to move up the stack to Gtk+ or Qt libraries. Update: Xft extension library is imported into LSB.

Desktop Module

Qt 4

The major task right now for Qt 4 is the uplift from Qt 4.1 to 4.2. To accomplish this, we need to do several things:

  • Database work. ISPRAS is working on this; should have an estimate by the F2F for making the necessary changes. There will need to be more work done in the LSB 4.0 timeframe, because our current data is not sufficient for our needs.
    • update (11/26/07): uplift is integrated, and one round of problem fixing is done - stubs and checkers generate and work; a few remaining issues.
  • Testing uplift. New tests have been submitted by TrollTech; Stew is looking at them. Progress is being tracked on bug 1609.
    • update (11/26/07, Stew) - A "working" build in place. 1268 PASS, 101 FAIL on SLES10. Will need to review as we get more results.
  • Appbat. As of this moment, no appbat package exercises Qt 4. TrollTech is working on providing a Qt Designer package which can be easily adapted for the appbat.
    • update (11/30/07, Stew) - pushed bundle for some arch-specific issues, trial builds OK - will see how autobuilders run tonight
  • SDK work. Currently, we pull upstream headers into the SDK; this should be a simple matter of pulling a Qt 4.2 tarball instead of a 4.1 tarball.
    • update (11/26/07) - 4.2 builds on autobuilders, although it runs into some trouble elsewhere.
  • Infrastructure. It turns out that our build platform currently ships Qt 4.1. Markus should be able to deliver an updated Qt from the upcoming service pack to fix this problem.
    • update (11/30/07, Stew) - we have access to pre-release packages for all archs now

Bug 1747 has been filed to track uplift issues.

Beyond that is the task of making Qt 4 a requirement of the LSB. The technical work is simple, and is tracked in bug 1603.


Printing APIs: this is being analyzed on a separate Printing page. It's not completely clear this is a "desktop" problem but it certainly seems to be a more serious problem there. Where should such an interface spec live in the module heirarchy?

We now have a rollup bug for printing (1753).

Status (11/30/07, Stew):

  • CUPS
    • db work mostly done - may need to tweak a couple of elements with multidimensional arrays
    • tests in place, building - Complete
    • spec work in progress
  • ghostscript
    • Tracking bug: 1754.
    • tests in place - building - Complete
    • spec work in progress
  • foomatic-rip
    • Tracking bug: 1755.
    • tests in place, building - Complete
    • spec work in progress
  • PPD Spec
    • Tracking bug: 1756.
    • spec work in progress produced specifications

Following are the specs currently being targeted for LSB 3.2 inclusion. All of these are already best practices for all major distros:

  • Menu specification [4]
  • Desktop entries specification [5]
  • Icon theme specification [6]
  • Base directories specification [7]

The intention here is to cover the desktop integration aspects in LSB 3.2. In 3.1 we started with toolkits and few other libraries and with these specifications in LSB, install time requirements for desktop apps will be covered.

Portland project produced xdg-utils package

Please see for further details. These utilities will be included in LSB 3.2 based on distro adoption (once it becomes common practice). If distro adoption does not allow this, then they should be bundled into the SDK so they can be used, and added as a "future" or "optional" specification. Update: an lsb-xdg-utils package exists.


  • libasound: There is a possibility that libasound (the API for ALSA) will be ready for 3.2.

Additional libraries under consideration

  • freetype: Update: freetype library is imported into LSB and works. Complete

Interpreted Languages

  • What does it mean to standardize an interpreted language? See LsbInterpretedLanguage.
  • Candidate languages for LSB 3.2: LsbPython, LsbPerl. Draft specifications for these two exist (follow the links). They will be integrated into the LSB spec.
  • A little bit of cleanup to do on these specs based on F2F decision. Complete
  • System and application checkers need to be provided. Complete


A separate bug tracks the production of errata against LSB 3.1.1. Large additions (new libraries or major chunks like POSIX option sets) will not get errata, but changes and small additions will. This is not strictly tied to the release of 3.2 but should be very close. bug 1733

Checker and Development Tools

  • lsbcc: generate library list from database instead of hand-coding bug 1509. Complete
  • lsbcc: add an lsbcpp command to aid in autoconfiguration bug 1511. Complete.
  • lsbcc: work better if libtool is used bug 788. Experimental version exists; have had trouble getting reviewers (changes are somewhat intrusive).
  • lsbcc: support for building for multiple architectures on one installation (actually 32/64 issue for a single architecture) bug 1407. Deferred
  • enable lsbappchk to check against multiple versions bug 1236. See also MultiVersion. Complete
    • lsblibchk, lsbpkgchk, and the build tools would also need work for multi-version support. Update: checker tools have some support for this.
  • better support for building conforming packages. A script exists which should make it a bit easier.
  • Fix lsbpkgchk to be more useful.
  • Run LSB applications on a system which doesn't have the LSB linker. This would be a small wrapper to check for the lsb linker and run the app with it if present, or fall back to the system linker. Could be added to the SDK so developers who feel the need to support this behavior could use it. An implementation of this tool exists; needs a package and autobuilding. See bug 1705. Complete
  • update archk. Deferred
  • Update and build build_env as well as the lsbcc development kit.
  • Integrate trial use modules. bug 1770.


Package renaming

  1. rename 'qm' harness to 'lsb-qm' as it conflicts with the same package in the Debian (and maybe other) repositories. bug 1439. Complete
  2. rename the c++ testsuite from 'qmtest-libstdcpp' to 'lsb-test-libstdc++', to match the naming style of the other tests. bug 1548. Complete
  3. rename the runtime-test suite to 'lsb-test-core' to be more reflective of what it's testing, which is just the core module. bug 1549. Complete

Install locations

  1. change the runtime-test suite to install to /opt/lsb/test like the other test suites do. The current install to /home causes problems in test machines which may host several distros or distro versions but share /home across them - just about everybody who does this kind of shared testing has destroyed parts of their test setup at least once. bug 1566. Complete

Build issues

  1. enable autobuilding of all distro test suites, which means we can catch build issues right away rather than all in a lump near release time. bug 488. Complete
  2. build runtime-test with lsbcc. It's currently not built with lsbcc but linked with the LSB linker. As a result, it does run against the correct libraries (remember, the runtime linker may select an alternate set of libraries for LSB conformance); but there's the possibility of getting incorrect symbol version references and other non-LSB "leakage" as they are currently built. There are known to be some non-LSB symbols used. Tracked in bugs 225, 792.
  3. build vsw4/xts5 with lsbcc; there are some non-LSB symbols currently used. bug 1572 for vsw4. vsw4 is complete. Patches exist for xts5 bug 1529 for xts5. Complete
  4. try to eliminate the need for building runtime-test as root - this is required in order to use the autobuilders on it as they run non-root. Special note: the recently reintroduced building of debian packages via alien can be supported if fakeroot is used. bug 1539. Complete

Runtime test issues

  1. provide a copy of Xvfb, appropriately configured, for use with the tests so we don't have to depend on each distro having an Xvfb which provides everything the testing needs, when that component is not an LSB requirement itself, only a requirement of the test suite. Also supplying required test fonts with it would help with some of the "need to be root" questions from the previous item as those would now be configured at install time, not test startup time. bug 1225, bug 1579. A sample configuration exists. Complete
  2. switch to xts5 for the X11 testing; this is the far newer and more supportable test suite vs. vsw4 which we're currently using. this is a bit challenging; we do currently have a patch which applies to the one tarball which has released but that patch is unsupportably large due to the tarball snapshot being made *before* the test suite was localized to the source tree. The patch is over 1100 lines and is monolithic, which means as bits of the patch go into upstream it goes out of date. We need to work with upstream (they're willing) to integerate those patches which are generic and get to a *small* delta from current upstream. includes bug 1529 Complete. Need beta period for testing.
  3. lsb-test-desktop should allow running of individual module tests for debugging. Currently the only option is whether to run the Qt4 test or not (and with 3.2, that will become mandatory). For example, if the xml tests are failing within lsb-test-deskop, it should be possible to run just the xml test. For those tests which require Xvfb, add functions for starting and stopping it so that each module test is self-contained. bug 1584. Complete
  4. Integrate the new tests from ISPRAS into the test suites.
  5. Integrate the new tests from IBM India into the test suites. bug 1762 (11/30/07 - batch3 in, starting to look at batch 4)

Application test issues

  • Build ATK Manager? Using ISPRAS packages should be okay for now, not a blocker.

Wishlist Items

  1. Implement a shadow testing mode where tests don't have to run in the installation directory. At least for xts5 (where a prototype implementation is known to exist outside of LSB) this would allow tests to run as non-root while not affecting the location the package manager installed to. Complete for xts5.
  2. Add install_initd testing: bug 7. Tests are integrated but need to be piloted with distributions.
  3. Add curses tests
  4. Add openGL tests

Application Battery

The application battery should be uplifted to recent versions. There's a pending bug on lynx problems (bug 1049). gaim has been renamed. Complete

Need to integrate qt4 package from Trolltech into appbat

We'll probably need a few new applications to cover the new libraries being added.

Sample Implementation

The current sample implementation is difficult to build and maintain. For now, building a new SI will not be a release goal for 3.2.

There may be value in a re-engineered SI, perhaps based on something besides Linux From Scratch.

Release Notes

Write ReleaseNotes32.

Test Results on LSB 3.1 Distributions/Applications

Put results from testing the 3.2 tools/tests here. Longer results may need their own page; link that here.


None yet.


None yet.

Bugs to fix before final release

Bugs exposed in 3.2 beta testing:

  • t2c-desktop-test - need to do something with group ownership of files Bug 1821
  • core-test: posix_madvise tests segfault (sometimes) Bug 1823 (fixed in bzr, beta2)
  • printing test: some tests are disabled that have issues, drop interfaces? Bug 1811
  • desktop-test: excessive failures in qt4 tests with qt < 4.3 Bug 1826 (bundle in bug)

Return to front LSB_Wiki page