[lsb-discuss] LSB conf call notes for 2008-08-27
jeff at licquia.org
Thu Aug 28 08:08:47 PDT 2008
Attendees: Jeff Licquia, Mats Wichmann, Ron Hale-Evans, Kay Tate, Russ
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.
More information about the lsb-discuss