The Linux Foundation

 
Parkinglot50

From The Linux Foundation

  • Test framework
    • ALSA test suite based on T2C
      • While it is always nice to have additional test coverage, this is not really a focus for the next release.
    • In general the LSB project should have a goal to increase our text coverage by 10% every year
    • We have at least two test frameworks neither of which appears conducive to upstream integration or distribution level integration, test modularization maybe a priority for the 5.0 release see ProjectPlan50
    • We've had no success getting our tests into upstream projects. This puts us behind the 8-ball in that we always find problems too late and thus getting them fixed is a problem. Can we create a framework that works as "plugin/bolton" such that tests can be pushed upstream and are acceptable and runable outside of the LSB test framework?
    • Uplift qm test harness
  • Non-gcc compiler support
    • Intel CC
    • PGI
  • Modularization
    • Breaking the LSB into chunks that are more easily consumable appears to be an important task, this may be a priority for the next release, see ProjectPlan50
    • If modularization is a 5.0 objective the implementation of a framework becomes part of this objective.
  • lsb-xvfb
    • What to do with it? Lacks full GL support. Leakiness is felt to responsible for qt3/qt4-azov failures (also have issues with system Xvfb in some testing). Attempts to build from newer upstream seem to cause even more problems, particularly with xts5.
  • IceGetPeerName
    • A random interface that was listed as a task
  • Java
    • Java as a language can never be in the LSB due to the non-open source testing and compliance requirements.
    • Oracle has changed the license for distributing Oracle's Java implementation and distributions can only distribute openJDK implementations
    • Despite Java's "promise" of "compile once run anywhere" the practice is that vendors ship their own Java, the LSB would probably not be able to stop this practice.
  • De-prioritized in favor of Java spec. Incorporate JPackage for Java packaging and installation? - Believe this situation has reversed now

Contents

Pre-Work

Per the above, decide target release date, decide target distributions based on date, and fill in the database Tracker Tables.

In order to enable decision support from LSB Navigator, some newer distributions were scanned and added: openSUSE 11.4, Fedora 14, RHEL 6, Oracle Linux 6, Debian 6.0 (these for various architectures, as available.

For completeness, there are some others missing, may be more value in leaving these out to avoid bloat than to put them in:

  • Red Hat Enterprise: 4.9 (?), 5.6
  • Oracle Linux: 5.5, 5.6
  • Centos ? latest in db are 4.7, 5.4, latest released 4.8, 5.5
  • BOSS 4.0
  • Asianux 4.0

Not released yet, all expected April/May:

  • Fedora 15
  • Ubuntu 11.04
  • Mandriva 2011.0

Would a MeeGo scan add any value in portability reports? (it's not an LSB target distro, but might be an interesting porting target)

Modularization

Some time ago, the LSB was reorganized to support modularization, and the specification is delivered in this modular format. However, in all other aspects, LSB remains a "big gulp", and over the years we get comments like "I installed 'lsb' on my distro and it installed 50Mb (various large numbers) of cr*p on my system!", or "We're building a server only, why do we need all these graphical libraries". The correct lsb deps shouldn't install anything like this large of a set deps on a typical desktop system, but may perhaps bring a fairly large number of dependencies on a slimmed-down server type install.

The "big gulp" has one big advantage: it's extremely simple for applications and for OS deployments. "lsb" means the whole thing, you don't have to worry about which pieces are or are not installed. We need to keep discussion whether it's necessary to move to the modular model for certification. Will this dilute the value of LSB, if ISVs have to now specify a correct set of lsb-foo dependencies. Do we have enough resources to implement/test a modular certification system?

During the LSB F2F Spring 2011, this topic became the subject of much of the discussion. As part of LSB 5.0, the thought is that we need to rethink our approach. The topic now has its own page, Modularization50.

FHS

The last FHS revision is quite old, and there has been some evolution in conventions in Linux that are not reflected. The project became a bit stale, and FHS is planned to move more into a mainstream Linux Foundation project. There are a number of open bugs in their bugzilla, many of which would be trivial to fix if we were to take over maintenance of the project. The former FHS maintainers are willing to hand over maintenance to the LSB workgroup, but the transition was never completed.

FHS always intended to be OS-neutral, what should happen with changes that have happened on the Linux side which maybe are not generic. Should FHS become LFHS, should there be a parallel LHFS, or is a "Linux delta" encompased in LSB sufficieng?

Is it time to do this?

Infrastructure

  • Work on autobuilders, autotesting, and version control system are important enablers for the 5.0 work, although not "shippables". See InfrastructureTasks. Mostly done in 4.1 period but possibly room for more improvement to enable "Rapid Releases"
  • Work on autotest-results page
    • Ensure it's updated regularly
    • Fix issues with changed names, moblin stuff, waivers not being handled
    • Possibly add more ways to drill down into results
    • Possibly add a means to link bugzilla entries to fails (and/or problem_db2)
  • Work on problem_db2:
    • commit/revert is a little flakey yet
    • it has been suggested to rework the database (and presumably dist-checker) to track test versions for 'Observed In' and 'Fixed In'

NOTE: After some research, version bounding does seem to work, at least partially, fix pushed to dist-checker 5/2011, Stew

  • Need a means to funnel our bugzilla reports on distro test fails back to distros
    • Select distro(s) in report triggers an automated report into the distro bug tracker
    • Need to "gate" this somehow so we don't overwhelm the distros with bugs

SDK

SDK rollup is bug 3136

  • Should LSB provide Xos.h, Xarch.h, and Xfuncs.h (some test builds use them) bug 3136
  • the lsbcc argument rearranging continues to cause problems, bug XXX

Checkers

Checkers rollup is bug 3167

  • pkgchk is unable to handle non-LSB dependencies in "check payload" mode bug 3206
  • add a tjcat (test-journal-cat) command for concatenating tetj journals. Numbering restarts for each journal which leads to errors by certain processing tools, so a tjcat command would have to adjust this by modifying the second and subsequent file arguments to sync with the first. bug 1583
  • lsbcc support path queries (too hardwired to /opt/lsb/bin at the moment) bug 1537
  • can dynchk finally be released? bug 619
  • can archk finally be released? bug 724

Specificaton

Specification rollup is bug 3165

Deficiencies

  • PAM has spec issues - bug 1097
  • ptrace: bug 1664. Added in 4.1, but some arch-specifics were ignored - revisit?
  • DWARF 3.0 should become the reference specification for dwarf. This is a published LF standard at [1]. bug 1819
  • Thread Local Storage Debug Information: bug 992
  • ELF extensions for thread local storage: bug 993
  • Structure of call frame information: bug 994
  • Clarify DWARF 64-bit support: bug 1034
  • c++ binding support doesn't really exist - LSB is mainly C bindings. some of the needs are low-level like throw semantics, some is higher-level like c++ binding libraries where they exist.
  • Packaging
    • The packaging spec is so far out of touch with current practice it's almost useless.
    • LSB RPM Uplift to version 4 packaging format
    • support for bzip2 (which is widespread) and other newer payload formats (less widespread)
    • 3rd-party-friendly packaging solutions: Berlin Packaging API
    • packagekit?

Uplifts to Track Upstreams

See LibraryUplifts

  • uplift Qt to a more current version (4.4). A missing feature currently is the WebKit integration that comes in with 4.4. Later than 4.4 would be good if possible (check distros)
  • uplift gtk libraries to 2.10 or later, if necessary to accomodate gio, other features (e.g. Acessibility). gio may be available for current version (check)
  • uplift OpenGL to current version: bug 707. See LibraryUplifts

Additions

  • bzip2: bug 404
  • DBus: bug 1857. Also see Freedesktop dbus page. Brings dependencies:
    • libdbus-glib
    • libQtDbus was omitted from the Qt4 specification since the dbus prereq could not be met before.
  • Related to the above, support for xdg-autostart. This would be an alternative to DBus activation and traditional init scripts.
  • sync with POSIX 2008. It may be too early for LSB to require full compliance, but most of the tech changes were actually part of the glibc uplift done for LSB 4.0. At the moment we do not have a good picture of what remains, it may be only tweaking (new sysconf values and other details).
  • can async I/O finally be added? bug 1391
  • do we need libncursesw? or is there some better solution coming? bug 1761
  • libpcre and libpopt have been mentioned because they rate fairly high on the Navigator statistics of used non-LSB libraries
  • libCURL: This is commonly used library for many applications. Given the level of documentation and tests, it should not be too controversial. This was being explored, but there are no resources working on it now - waiting to see if demand rises high enough for this.
  • mount, umount: the system calls, not the command-line utilities. Seem to be particularly popular according to Navigator; should they go in? The standard response has been to tell people to shell out and run the command-line tool. There are also a set of interfaces dealing with mount table entries.
  • mallinfo, mallopt: bug 1768
  • libhal - Not much info here; may need to get some libhal people involved to firm up a standard.
  • libsigc seems to be a popular library; should it be added to the C++ module?
  • boost libraries? some of the material in the boost libs is making its way into ISO C++, at what point does this have to be taken seriously for LSB C++?
  • libXmu: continues to show up high on the list of used non-LSB libraries
  • libgconf seems like it should be in the ABI; programs that want to use Gconf don't really have the opportunity to bundle the library, they should use the system facility.
  • Proposed extension libraries: libXcomposite, libXdamage, libXfixes. Requested to enable functionality needed for Accessibility. Versions of these found on a current distribution: Composite 1.1, Damage 1.0, Fixes 3.0. NOTE: new information questions whether these are needed by applications. It appears a system will have a compositing manager which will be part of the window manager; there can only be one job in charge of compositing anyway. Thus, unless portable window managers seem a concern, these may end up left as "system provided" and not go into the LSB.
  • libxslt: libxml2 is already part of LSB 3.1. libxslt library will complement libxml2
  • libexpat: another popular xml foundational library.
  • libtiff and libXpm are utilities libraries in the graphics space that are commonly used.
  • C++ bindings for several desktop libs could be considered: libglibmm, libgtkmm, libgdkmm, libatkmm, libpangomm, libcairomm, libxml++
  • Proposed and somewhat controversial are libxkbui and libxkbfile. It is felt these are "internal" interfaces that should not be exposed to application developers. LSB does have support for Xkb in the base libX11; it appears this is is actually sufficient and at the moment this request is on hold and will not be elevated to active unless new information surfaces to support it.
  • SANE (Scanner Access Now Easy): It is in all distros and needed to support multi-function devices, also to cover scanners with LSB-DDK-based driver packages - SANE41
  • Add 2 remaining CUPS HTTP/IPP interfaces: CUPS41 bug 3087
  • Printing folks also asked about an uplift of OPVP to 1.0. Currently we do not specify anything beyond "gs" having support for opvp:
  • add more interfaces for libnspr4 (bug 2902)
  • LSB_Kernel_Interfaces.
    • Greg KH has expressed interest in standardizing certain interfaces into the kernel. Most likely, these will be /proc and/or /sys interfaces. It may or may not be a good idea to add a library interface in front of the raw /proc or /sys pathnames. See
  • GTK+ 3. Should be worthy of a Trial Use standard, even though it's not released yet. Also, what does this mean for the status of GTK+ 2?
  • Python 3. As with GTK+ 3, probably Trial Use. The transition is still early, but may also have implications for Python 2 support.

Testing

Testing rollup is bug 3166

  • ALSA T2C test suite - write more normal tests
  • adapt NSS upstream tests for test coverage (started a year or so ago)
  • more robust Perl, Python testing
    • Main, ongoing issue for Perl/Python is using upstream tests across multiple versions and running into failures where tests expect specific behavior that is not part of the specification. Currently we are dealing with this as the issues present themselves, but patching or dropping tests, but a true independent version of the tests would be desirable: Python bug, Perl bug.

Possible new test suites (in question, resources involved are no longer available)

  • t2c-cups?
  • function signature checker?

There have been requests to:

  • add tests for epoll bug 2580 - Added to t2c-core 5/10/2011, stew
  • introduce LSB command tests bug 718
  • Add tests for commands from LTP bug 2588
  • lsb-vsclite needs to 100% cover specified commands found in busybox bug 2323

Open Questions

There has been some discussion on auditing all the distribution tests such they they can be considered "golden" - that any failure can definitively be attributed to the interface under test/distribution, not a test issue.

Application Battery

Appbat rollup is bug 3168

  • Migrate appbat build from nALFS to individual rpm-controlled package builds? DONE
    • Some work done on this, specs attached to bug 1076 (rpm-based builds would be valuable as examples). Local tree has been reworked to keep the same Makefile targets we had before with some of the old xml structure remaining for checking tarballs etc, but no nALFS required and build is all rpm driven (src.rpms generated now too). (Stew)

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