LSB conf call notes for 2008-08-27

Herrold, Ted Tso, Brian Proffitt, Dalibor Topic, Marc Miller, Alexey Khoroshilov, Vladimir Rubanov, Darren Davis, David Herron, George Kraft, Alan Clark, Dan Kohn Jeff: Kay has to drop at the half-hour; action items? Kay: anything not mentioned on the call can be sent to email. Ted: interesting failures from Hao Liu at Red Hat. Mats: posted some LSB bugs to RH's bugzilla; recent activity is the result of recent prodding. They are testing Fedora 10 (pre-release). Some are the result of changes in F10; some are changes in the compiler; some are upstream changes we will need to adapt to. Ted: one thing was that he was compiling from source? Mats: yes; just trying to debug the failures. Had come from running our binaries. Jeff: do anything besides give him answers to his questions? Ted: should keep him happy; keep him from wasting his time to the extent possible. NSS. Jeff: posted to the list. Ted: will Debian provide the right sonames? Jeff: it seems to currently. Mats: in the devel package? Jeff: no, in the main library package. Ted: two issues: is there a binary incompatibility, and will everyone provide the proper library name. Is the second going to be a problem? Jeff: checked Debian. Mats: some testing has been done; libchk should catch the problem now. Jeff: also, did the NSPR requirement ever get figured out? Mats: still not sure; should probably push a little more. Ted: no one on the call from NSS? Jeff: no; should have made sure it was explicit on the agenda so they would know. Let's continue discussing on the list; if need be, it can be on next week's agenda. Ted: more a bug fix. Ted: technical Java issues? Are we good? Ron: seems so. Dalibor: agrees. Reference is for Java 6 or greater, which is useful for when Java 7 comes out. Ted: seemed to be issues with running on later than Java 5; is there likely to be an issue with that for Java 7? Dalibor: not sure. David: some people are concerned about re-testing against a newer runtime. Ted: wondering about deprecated interfaces, removed interfaces, tighter implementation. David: not aware of any removed interfaces, but the behavior does change: bug fixes, for example. Sun does try to preserve compatibility with important issues. Ted: concern about knowing what runtime they're using. Jeff: specs can have a long life, too. David: can ask the runtime if it's really important. Sun wants to keep forward compatibility. Mats: that matches the LSB philosophy. Ted: it's easy to believe that compatibility issues are the app's fault, but it's still a reality. Can see multiple Java runtimes. Kay: tends to be the big ISVs that are the most paranoid. Marc: also, running older Java could preserve security holes. Ted: intent is full backwards compatibilities, including JNI? Dalibor: yes. Marc: understand the intent, but not sure if those security reports have an impact on the APIs. Dalibor: not on the security team, but do synchronize security updates every two months. So far, security issues have been all over. Jeff: API impacts? Dalibor: generally, the rule is that the API cannot change within a major release. Behavior could change for security (or other bugs). Usually done to tighten implementation compliance with the spec. Since binary compatibility is an issue, there are practical constraints. Have even kept internal-only interfaces to prevent breaking code. Ted: this is equivalent to what the LSB does. Marc: as long as we don't encourage the insecure version, that's OK. Ted: we will be constrained in that LSB apps in LSB 4 will only be able to use Java 6 interfaces. Jeff: when the Java spec is first released, it will be in trial-use; not a final decision. Dalibor: ok, may need to go trial-use this time around. Two useful projects: OpenJDK LSB-compliant, and LSB applying for Java compliance through the TCK. Ted: have we looked at OpenJDK's LSB compliance? Mats: partially; we have data in the Navigator. Dalibor: do you have a link? Mats: will send. Ted: would also be nice to gain the right to redistribute the TCK, but probably don't want to talk about that on this call. Ted: lsbcc issues with Novell? Jeff: not taken a look yet. No one else seems to as well. Ted: is there some tiny feature that would make life much easier for Novell? Mats: one thing that would make life a lot easier for a lot of people: swap the names of several of the packages so they look like they're more derived from each other. For example, lsbappchk and lsbpkgchk come from the same source; could be nice to give them names like lsb-checker-appchk to indicate their common source. Probably don't want to do that now. Ted: probably post-LSB-4. Ted: one possible feature would be enhancing multi-version support for "LSB 4 relaxed", so apps could be forced to link against LSB-supported symbols, but also more relaxed support for non-LSB stuff. Mats: decoupling the tools from LSB releases means we don't have to wait for it, but probably can't do before the 4.0 release. Jeff: crucial thing is to make sure we are decoupled from LSB spec releases. Jeff: autobuilder progress. The autobuilder we actually use is now in version control. Jeff will be trying to set one up as a prelude for making changes to the way it works in a sane manner. Ted: SI/buildenv? Not sure if we're ready there. Jeff: Antonio has been making good progress; has a x86 chroot that should be mostly complete. Will be testing. Ted: test results? Jeff: unknown; probably best to get an independent set of test results anyway. Ted: owned Marc a call. Good time? Marc: yes.