Sample Implementation, Application Battery and LSB Build Status

Week of September 8, 2003

1. lsbdev 1.3.4 beta release is out.

   Need to build all the appbat apps, not necessarily for re-release, but to prove out lsbdev.

2. lsbdev going forward:
   • ncurses.h to be added as symlink to curses.h (Not done)
   • maintenance branch needed: will branch after 1.3.4 is released so the branch is at a clean spot.
   • Decide what to do with lsbdev chroot bugs (Chris will probably look at these when he gets a chance).
   • Fix Debian packaging. LSB team will not release Debian packages itself, but our tree should have them correctly supported so that the debian maintainer can release them timely with our releases.
   • Mats will investigate operation of lsbdev tools with a non-GCC compiler. This is not a 1.3.4 blocker - any bugs will be evaluated post-1.3.4.
3. George has proposed LSB-delivered packages go into the lsb namespace (/opt/lsb). This would affect the lsbdev packages particulary, might make things a little easier for people to find. 2.0 issue.
4. lsb-rpm is not maintained. We'd like to have an lsb build tool, however. Best would be if a maintained toool could have an lsb mode, instead of needing to maintain a separate tool or our own patchset. How to make this happen for rpm (the most likely candidate)?
5. pkgchk needs to move towards a release. Mats/Marvin will test these on their platforms and provide feedback as Stuart fixes. No date set.
6. A sample download page was floated (see http://www.linuxbase.org/~jeremy/download.php) - this would be a great improvement. The process pointed out the need to clean up some areas of the ftp site. Also need maintainers to update their HEADER.txt files to provide useful non-version-specific descriptions - don't want the descriptions to go out of date.
7. Sample Implementation design is being finalized for the dual-architecture platforms. At the moment it looks like AMD64 will be a pure 64-bit platform similar to Itanium; powerpc64 will be a 32-bit platform (should be able to be a copy of powerpc32) with 64-bit libraries.
8. Discussion on future directions for appbat.
   • A table of packages with new upstream versions is included below.
   • A proposal was floated earlier to start building a libbat: static versions of key libraries that are LSB candidates, but not yet in the specification. This might smooth over some current build issues, and also might enable building some more complex applications, such as gnumeric, mysql, etc. The current model of lsbdev-c++ has indicated this can be useful. At the very least, when a library is "ported", the instructions should be captured so others don't have to reproduce the work. E.g., openssl was worked on as part of an experiement with openssh; libxml2 was worked on as part of an LSB conforming nALFS. One target for lib-bat would seem to be libraries that give us trouble on glibc-2.3 systems building the current appbat, that would be X libraries (Xaw and Xmu, plus the sometimes-external Xpm); libfreetpye, and possibly graphics-format libraries such as tiff, jpeg, png. Note: some preliminay builds done on these.
   • A tool was developed to extract and graph library dependencies. Some graphs are at http://www.linuxbase.org/~mats. The tool is in the LSB-futures web tree http://www.linuxbase.org/futures/identification/dependss/lsbdepgraph.py.
   • Considering uplift to latest nALFS, or maybe returning to build-by-RPM method. The former is okay for us, but is seen as "yet another tool to learn" by outsiders looking at the appbat as build examples.
   • There has been an request to make the FVT capture-and-submit process more automated.
   • Mats would like the rpm packages to include target LSB version as well as package version, so you can read as "rsync 2.5.5 build 5 built for LSB 1.3" - or does the rpm metadata give enough information today?
   • Some problems detected with xpaint on one platform. Question: does this happen with a native xpaint installed, or not - not sure if the app-defaults for xpaint are going to the right place (i.e., may pick up from native xpaint if one is installed, and not find one if the LSB version puts it in the wrong place and there's no native version).
   • Appbat package renaming to include spec version. Or possible put in %description what version it's for. No decision.
   • Existing packages uplift to current upstream versions Decision: try. use judgement on whether to push any new issue through.
   • Appbat packages to use install_initd/remove_initd to install/remove startup scripts (apache at least). No decision.
   • Uplift build tool to latest upstream nALFS (new xml format is different, closer to being "valid xml", whatever that means). Stuart will look into forward porting patches; more discussion next week.
   • Make packages buildable with lsb package-build tool (such a tool is not available today), using a more mainstream way to drive the build (e.g. rpm spec file) - objective is to make a more acceptable example for those contemplating an LSB "port". convert to lsbrpmbuild. Sounnds good, but who's going to make lsbrpmbuild?
   • Dependency tool - capture dependencies to be able to build appbat, reduce the guesswork (again, this is important if people outside the lsb team are going to build the appat as an example). A solution might be to capture these ourselves in libbat - might soolve short-term need.
   • Add new representative sample applications. Candidates: ??? openjade? ImageMagick? mysql? openssh? Fortran apps? Note: mysql built.
   • Possibly install packages to a new path. Check all existing packages for FHS conformance. Possible areas: if an app-defaults file is installed, does the app find it? Are there /var/run scripts that are being put in /var/opt/pkgname/run instead? etc. Conclusion: Don't use new path: example how ISV would do, as opposed to how LSB would do. Note on combine tcl/expect into one install directory (what was this?)
   • Improve the automation of FVT tests where possible. Nebulous goal, I know. My concept is to, where possible, have setup instructions, followed by one or more steps (possibly with further setup in between) that kick off a test and return a pass-fail result, so there's less visual evaluation to determine whether it worked or not.
   • For certification, there's been a request to be able to submit electronically. The CA is not set up to accept multiple submissions that would somehow get associated with a platform submission, they want a single form to be uploaded. Is there a way running each of the FVT forms could post data to a local file that is then used as the upload attachment?
9. Discussion on future directions for lsbsi. A table of packages with new upstream versions is included below.
10. A suggestion was raised to have the appbat packages indexed by rpmfind. This is under discussion. One thought was that maybe the upstream maintainers ought to give permission. A second question was whether we should continue the build-with-nALFS, package-with-rpm policy, or whether we should try to return to building with rpm.
11. Debian seems to be taking lsb requirements quite seriously; some discussion of including lsb testing in the process. This would potentially require modifying the lsb-runtime-test build process, which might in turn have some impacts on lsbdev packages.
12. (Old) The package format requirement was raised on lsb-confcall; a resolution is still pending: is using rpm a strict requirement, or a suggestion?
13. (Old) The 'lsb' packages for other architectures still need to be released. The package has no contents, just supplies a couple of dependencies and basically initializes the rpm database in the lsbsi. It's already autobuilding successfully, all that's needed is for someone with access to the build environments to build packages that look released, rather than like snapshots.
14. (Old). The lsbsi is still missing install_initd and remove_initd (it provides empty dummies). These are really failures to conform to the spec, but as there's no test they aren't flagged as such by the testing procedure. Still looking for volunteers to work on both a sample implementation and a test suite - there was a thought that Novell might be interested, to be explored further. An idea raised in the past might be worth considering: the sample could perhaps work on a non-standard location so that "cheaters" who try to install a startup script directly instead of using the required tool to install them could get detected by installing in the lsbsi.

Appbat Packages with upgraded base

LSB-si Packages with upgraded base

LSB-si Variances

This section documents the known variances of the lsbsi from LSB version 1.3.

The lsbsi does not provide required tools install_initd and remove_initd.

The following are the 44 known internationalization failures in the LSB-si running the 1.3.3 test suites. They show non compliance in the upstream packages diffutils (1), grep (3) and textutils (40). The choice is made to leave these unpatched, although the li18nux website, does have patches available, to highlight the status of the upstream packages.

/tset/LI18NUX2K.L1/utils/diff/diff 2 FAIL
/tset/LI18NUX2K.L1/utils/egrep-tp/egrep-tp 5 FAIL
/tset/LI18NUX2K.L1/utils/fgrep/fgrep 5 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 1 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 2 FAIL
/tset/LI18NUX2K.L1/utils/fold/fold 3 FAIL
/tset/LI18NUX2K.L1/utils/grep-tp/grep-tp 5 FAIL
/tset/LI18NUX2K.L1/utils/join/join 3 FAIL
/tset/LI18NUX2K.L1/utils/join/join 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 1 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 3 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 4 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 5 FAIL
/tset/LI18NUX2K.L1/utils/pr/pr 6 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 8 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 9 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 10 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 11 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 12 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 13 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 14 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 15 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 16 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 24 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 25 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 26 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 27 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 28 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 29 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 30 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 31 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 32 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 40 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 41 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 42 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 43 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 44 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 45 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 46 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 47 FAIL
/tset/LI18NUX2K.L1/utils/sort/sort 48 FAIL
/tset/LI18NUX2K.L1/utils/unexpand/unexpand 1 FAIL
/tset/LI18NUX2K.L1/utils/uniq/uniq 2 FAIL
/tset/LI18NUX2K.L1/utils/uniq/uniq 3 FAIL

There is an additional failure that occurs in beta runtime test 1.3.5, which adds some new tests. This failure is listed separately since it is not yet part of an official certification release. The program is part of the gettext package, and the issue is the subject of LSB bug 703372.

/tset/LI18NUX2K.L1/utils/msgfmt/msgfmt 9 FAIL