I will present the standard LSB slide deck with a particular focus on progress since the last face to face meeting, to ensure we're all starting the meeting on the same page. I will also present the current draft of the LSB 3.2 roadmap and timeline. Finally, I will talk about organizational issues, the modular structure of the LSB, etc. as they relate to LSB 3.2 development.

Presentation

• High level overview of the LSB infrastructure project - long term objectives
  • Renewed integrated LSB DB with extended information to involve various community parties.
  • New software infrastructure systems (LSB DB Navigator, LSB TEF, LSB Certification System).
  • Linkage between all the key artifacts.
  • Improved test coverage and quality of the standard as a whole.
• Current progress:
  • LSB DB & Scripts clean-up
  • LSB DB Navigator demo
  • LSB Test Execution Framework
• The next stage overview

Presentation

Overview of the plans for the LSB Distribution Testkit (companion to LSB Distribution certification), demos of lsb-autotest and the LSB Test Execution Framework (TEF), and discussion of planned integration with the FSG certification system.

Presentation

Overview of the plans for the LSB Application Testkit (companion to LSB Application certification), demo of the new appchk, and discussion of planned integration with the LSB database and Developer Network.

The current LSB SDK makes it easy to create an LSB compliant binary, but doesn't yet make it easy enough to create a distributable, easy to install LSB compliant application (I'm avoiding the term "package" here, intentionally). Longer term plans will be discussed in Wednesday's Packaging Summit. In this session, we'll discuss shorter term plans for making it easier to create distributable LSB applications that integrate well, such as including RPM helpers, alien, APT/yum repo generators, etc. in the LSB SDK.

An increasing number of "Linux" applications are being written in or augmented with Perl, Python, and other interpreted languages. As a result, we will be adding Perl and Python to LSB 3.2, so that application developers can write LSB compliant applications in those languages in addition to C and C++. However, the addition of interpreted languages presents the LSB with some new challenges, such as whether or not add-ons (e.g., gtk bindings) should be standardized and how to handle binary extensions. See also: LsbInterpretedLanguage, LsbPerl, LsbPython. Martin v. Löwis of Python will be joining us for this discussion and helping with Python standardization in LSB 3.2.

Incorporating Python into LSB: Identification of Issues (Martin v. Löwis)

In October, the FSG launched the LSB Developer Network, a community resource for developers building portable Linux applications via the LSB. In this session, we will discuss current status and future plans for the Developer Network, including collaboration possibilities with other developer communities.

I will present the final LSB 3.2 printing roadmap and timeline prepared at the FSG Printing Summit in October. This presentation is both to inform attendees of our printing related activities for LSB 3.2 as well as to provide a guide of what I want to produce for the rest of LSB 3.2.

Presentation

In general, not much is changing here. However, we need to look at the following issues:

• We are conducting a review of symbols that were previously in the LSB (during 1.x and/or 2.x) and have been removed but are still in widespread use (i.e., are still best practice). Where practical, these symbols will be readded to the LSB in 3.2 and waivers will be granted so that LSB 3.0 and 3.1 applications that wish to use them may do so. The primary consideration here are third party libraries such as FLEXlm that many ISVs use but cannot change to make their applications compliant. See ISV Requested Interfaces.

• In LSB 3.1, compliant applications depend on a single metapackage called 'lsb', so an LSB compliant runtime should provide that metapackage and provide all the required components when it gets installed. In LSB 3.2, we'll allow applications to only depend on the subset of the LSB they require (e.g., lsb-core). This will allow LSB applications that do not require the desktop components to be installed without pulling in the desktop components via the 'lsb' dependency.

• Mats: Other things?

We will be releasing the first update to LSB 3.1 in early 2007. The current working timeline is to release the beta on December 15 and the final version on January 15. In this session, we will finalize the timeline and go through the to-do list to determine what will make it into the update and what won't.

Presentation

LSB 3.2 will focus on device level standards (e.g., ALSA, libao). LSB 4.0 will focus on the higher level multimedia frameworks (e.g., GStreamer, Helix).

Presentation

OpenI18n is being merged into the LSB beginning with LSB 3.2.

• dbus
• Java
• OpenSSL
• Packaging (see Packaging Summit)
• Virtualization
• What else should be on our radar?

• Qt 4
• Desktop base directory spec
• Desktop entry spec
• Icon theme spec?
• Menu spec
• FreeType
• Xft
• Xrender

LSB 3.2 Desktop Updates (Tracy Camp (by phone))

• ABAQUS (Robert Schweikert)
• RealNetworks (Donya Shirzad)
• SAP (Falko Flessner/Andreas Hahn)

• Debian (Joey Hess)
• Red Hat (Paul Nasrat)
• Novell (Thorsten Kukuk/Michael Schroeder) Presentation
• Ubuntu (Michael Vogt)

Some of the loose plans we have for the 3.2.X cycle following on the API freeze for 3.0. What these plans mean for fedora and other distros using yum and what things we hope to do.

Presentation

klik is an easy way to download and use software. The idea behind klik is that software should just run, without the need for installation. To achieve this, klik uses compressed image files, not unlike Mac DMG files, that contain the entire application and all its dependencies that are not part of the (LSB) base system. This allows for "portable applications" that can be run from all media, e.g., USB thumbdrives. Presentation