[lsb-discuss] LSB conf call notes for 2008-08-27

Jeff Licquia 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 mailing list