page is still in development, check back for updates
The core LSB team met for two days of intensive technical work at IBM's Austin office. Present were Marvin Heffler, Sam Hart, Stew Benedict, Jeff Licquia, Mats Wichmann.
The ProjectPlan32 wiki page was reviewed.
The additional POSIX interfaces should be added to the database - they need to be there for research purposes anyway - but not marked as enabled, using the "late binding" strategy to defer a decision on 3.2 inclusion. We don't have any tests for these, it's not otherwise work to add to LSB since documentation exists (POSIX).
On the __xpg* interfaces, we should add the new interfaces, document those, and document the behavior of the old ones correctly. Runtimes will need to continue to provide the old interfaces but they should be moved to the binary spec only and replaced by accessor macros.
On the gethost* and other interfaces, we need to add these back, but there should be some way to indicate their use is not recommended. There's still a question of whether we add back the "complete set", or just those that have been specifically requested.
getdomainname is a real poser, getting anything useful back depends on particular setup which people may not have. At the sprint, several of the developers tried it and got back the helpful string "(none)" - which is documented, by the way. This function truly seems useless.
It was also discussed whether a small "compatibility library" (.a archive) could be used to achieve the same result as adding the interfaces to the LSB; it was concluded we didn't have enough information to know for sure.
If we add back getdtablesize, it has to be documented, as it was removed from POSIX for the current version and we're trying to eliminate references to SUSv2. See previous comment.
There was some discussion of async I/O going back as part of the F_GETSIG/F_SETSIG discussion. Again we don't seem to have enough information, although the two constants don't seem terribly controversial.
We need some more discussion on the "kernel interfaces" topic, which was added to the wiki page without much detail.
X Extension libraries: Xdamage and Xfixes seem to be turning up in a number of applications, although as always it's hard to tell if the interfaces are used directly or if these are pulled in by indirect references. Documentation and tests, like the other extension libraries, is an issue.
Discussed the Qt4 question - interface stability has been questioned on the mailing list, and we've heard that some visible commercial apps are settling on later Qt versions. LSB specifies Qt 4.1; Mathematica is using 4.2; Skype will be using 4.3. We need more tests, but those do seem to be in progress.
Printing - we didn't have a printing representative present, we should update the wiki page soon with more accurate information of what's really going to happen. libcups, with a portion of the interface set, appears to be a strong candidate for inclusion but we've not yet seen any hints of what that submission will look like.
lsb-xdg-utils package exists, but we concluded the package ought to default to a native version if one is available, and don't know if the package build that was contributed supports that mode of operation.
dbus - question if we could get upstream help (John Palmieri?) producing an optional spec for this so it could start being usable and move towards an LSB 4 inclusion.
We thought again about multi-version aware tools; given the current recommendation to use the lowest version of the LSB that will support your application this would seem not to be optional - it doesn't make sense to give instructions to install old versions of the tools when there have been many fixes and improvements that aren't getting backported. We talked about the tools - appchk and lsbcc in particular - becoming version-neutral binaries that loaded the right version data files dynamically (dso, read xml data file, etc.). There's no progress yet towards implementing that, and the thought has been on the table for a very long time.
The team worked through a portion of the over 300 open bugs, and discussed paths to resolution for several of them. Individual team members have taken action items to close them out.
The team will have to resume the weekly "bug day" chats on IRC which worked well for a while but then fell into disuse as people stopped participating. 295 non-rollup bugs is just too many, even if a few are intentionally deferred until later.
The bulk of the open PRs were discussed and will be closed with the appropriate resolution. Two remain: 138 and 139, both of which deal with the S390-on-S390X problem. Since the different data file formats for the S390 ABI and S390X ABI come to us from upstream glibc, we can't just declare a change; we could eliminate these interfaces from the S390 ABI via errata, however, and do some fixups so those were not tested for. The S390 ABI is not going away (unless we are requested to drop it), and as far as we know is actually the default compile mode on an S390X system - that is, you need a flag to get a 64-bit binary.
All of the specification errata for Technical Corrigenda 1 (aka update 1) were reviewed. That list is:
1291-libm.sgml 1293-libc.sgml 1294-libc.sgml 1329-libc.sgml 1334-libc.sgml 1336-libc.sgml 1337-curses.sgml 1338-gzip.sgml 1346-libc.sgml 1347-gzip.sgml 1350-libc.sgml 1352-libc.sgml 1353-gzip.sgml 1361-libc.sgml 1366-libc.sgml 1367-gzip.sgml 1374-libc.sgml 1375-libc.sgml 1377-libm.sgml 1379-gzip.sgml 1380-gzip.sgml 1398-gzip.sgml 1399-gzip.sgml 1405-libm.sgml 1410-libc.sgml 1425-libc.sgml 1432-pthread.sgml 1436-gzip.sgml 1438-dwarf.sgml 1443-libm.sgml 1446-cpio.sgml 1447-libc.sgml 1455-libc.sgml 1474-libc.sgml 1493-jpeg.sgml 1497-libc.sgml 1508-gl.sgml 1518-gzip.sgml 1525-libc.sgml 1530-libz.sgml 1531-libc.sgml 1532-libc.sgml 1533-libc.sgml 1541-libc.sgml 1544-Xt.sgml 1545-libc.sgml
All were approved without change except these numbers: 1291, 1329, 1334, 1361, 1377, 1525. For those, Mats has the action to make some further modifications and resubmit.
Automated nightly testing. There hasn't been much progress yet beyond an initial design. There will be two parts: client and server. Initially, the focus will be on the client; the idea is that it should be as easy as possible for someone to set up a client to provide us with autotesting data. The server will start out doing little more than collecting the raw data; its capabilities can be expanded over time as long as the data collection part works well.
We'd like to get distro help running the testing, and think it would be interesting to them as well. Note there are three interesting test scenarios: stable tests against development distributions, development tests against stable distributions, and development tests against development distributions.
What enhancements are needed to the version control system? A few ideas:
The two top short-term priorities are the smart server and Bundle Buggy, to meet the two biggest complaints about the current typical workflow: there are too many steps with needing to push to a web-visible branch first, then asking for a PQM merge, which happens not in real time but at cron time and sometimes fails inexplicably; and the fact that there's not much current visibility into changes being merged into official branches. Also changes are clogging on official committers (not everyone can call PQM) having to handle everything manually - votes from official maintainers exercise the same level of control with drastically less manual effort. E-mail notification would be nice, but isn't as important. Chapel is still in development; it's an "off-hours" project by Jeff, and might take a while. There's interest in trying to get it approved as a part time LF project to get it done quicker.
lsb linker: One possible approach to the ISV requested ability to be able to run LSB apps on a non-LSB system would be to provide a small wrapper, say "lsbrun" to check for the lsb linker and run the app with it if present, or fall back to the system linker (conceptually a little similar to what the "fakeroot" program does). This could be provided in the SDK, making it easy for ISVs to integrate it into their packaging.
Basic problem for bug 1599 seems to be that crti.o from a SLES10 system (our build platform) seems incompatible with some other systems, like Debian 4. A workaround is providing our own crti.o and passing "-B/opt/lsb/lib" in the gccargs from lsbcc to get the linker to use this copy. Change has been committed to the development branch.
We were not sure how many architectures were affected, but during the session we were able to see that the issue only arises for ppc32, conditional code for a new addressing mode which is enabled in the toolchain on SLES10 but causes problems on other distributions.
Discussion focused on Python, but changing a few of the words would make it apply similarly to Perl. As discussed before, it seems the simplest approach is the only one we can support in the short term. This would involve specifying that runtimes have to provide a python interpreter of a known version at a known path. The standard library would be required/supported, only pure-Python programs would be covered, not extensions in other languages. The tests should be able to be adapted to run-time testing, we already use the Python tests this way as part of the Application Battery testing instructions, and the Perl tests, while a little more dependent on non-LSB things, could presumably also be adapted.
There are some issues with this, even though it sounds straightforward. How does a python program specify the correct interpreter? The #! syntax is not specified in the LSB (bug 780). Application which are installed using Python/Perl tools, like distutils for Python, would pick up the right incantation from that process, but packaged scripts which are installed directly to the library path would have to be aware of the correct interpreter path and library path as described by LSB.
Just saying "you must provide Python in the system path /usr/bin/python" does not seem to be enough; we know of cases where a later version of Python won't run a script that worked on an earlier (e.g.: the qmtest harness used for some LSB testing didn't work under Python 2.5), as well as many cases where scripts written to newer versions don't work on older interpreters.
So if some-other-path-to-Python causes problems, but not saying anything also causes problems, what do we do?
The question arose whether libchk and appchk equivalents are needed for the runtime languages, and how those would be implemented.
Due to changes in structures - in a way that should be ABI-compatible - devchk does not currently build with lsbcc. This problem is described in more detail in bug 1519. During the meeting, Marvin had enough by-hand changes that devchk is back to building and we have results we can look at. But we need a way to handle these in a cleaner way. In at least a few of the cases, reserved fields from one gtk version are now in use in a later version - this is a compatible extension (see bug 1494). However, the mktests script generates code to check structure member sizes and offsets, and so checking the renamed fields by the old "reserved" name when the field now has a new name leads to compilation errors. An earlier approach was to designate these structures as opaque and not check them at all (bug 1507); an approach kicked around at the meeting was to add a way to designate certain structure members as unchecked in the TypeMember table.
We also discovered that devchk's mktests script is not correctly generating some of the sizes, a bug was filed on this. During DB refactoring, devchk had not been given a high priority, but this just looks like a question of going back and doing a few cleanups - the problem is that for some types the generic record has a size of zero to indicate the arch-specific sizes should be used, but mktests isn't looking this deeply (bug 1620).
The fixed package seems to be working okay; need to move this out to a public beta. We agreed two weeks is sufficient. Before announcing the beta, however, we know at least one platform's binaries has a problem - ppc32 (bug 1599).
For that bug - discussed elsewhere - Stew to test the devel branch build on all available platforms (delayed slightly to let the PowerPC fix for lsbcc flow through the autobuilds). If results look satisfactory we'll backport the lsbcc package fixes for a 3.1.1 refresh, all the ppc32 packages need rebuilding, including the C++ test suite. We'll start the beta on that when the rebuild is in place.
Ran autobuild packages from 5/14/07 on SLES10 ia32/x86_64, Debian 4 ia32/ppc, Mandriva 2007.1 ia32/ppc/x86_64 and RHEL5 ia32. Only failure on all platforms was the usual /24_iterators/istreambuf_iterator/2.cc, with 8 "UNTESTED" results on the Debian platforms. (Stew 5/14/07)
various topics came up that don't fit directly under one of the above agenda headings.