[lsb-discuss] LSB conf call notes for 2008-03-26

Jeff Licquia jeff at licquia.org
Wed Mar 26 09:29:56 PDT 2008


Attendees: Jeff, Robert, Sam, Jesper, Carlos, Mats, Stew, Kay Tate, 
Darren, Marvin, Russ Herrold, Alan Clark, Ted, Alexey, George Kraft.

Project planning.  Jeff: plan is that LSB 4.0 tasks will either be on 
the LSB Project Management list, or a bug in Bugzilla with the proper 
target version set.  Ted: late on lists of interfaces and libraries that 
would enable large numbers of ISV applications.  Did we ever get a 
mapping on the ChipHopper apps?  Kay: Alexey was going to change the 
names of the apps in the Navigator based on info from CH.  Ted: wanted 
to make sure we could prioritize the libs used by the CH apps.  Kay: 
will bring a presentation to the F2F, getting some additional info from 
some of their ISVs.

Ted: lots of wishlist items in ProjectPlan40; which have been turned 
into project pages/bugs?  Jeff: added multi-version tools, ongoing 
database reimports.  Mats: multi-version would be a very good thing for 
reducing maintenance burden.  Ted: has ISPRAS looked at build tools? 
Mats: had reported they wanted to do it.  Ted: bug on build tools? 
Jeff: 1965.  Mats: the checkers are mostly multi-version, all except for 
cmdchk.

JVM.  Ted: Sun guy?  Jeff: had an internal strategy meeting last week; 
hadn't heard how that went.  May be on the call next week.  Ted: reach 
out to others, possibly Ian.

Ted: Use of syscall is a bit problematic; maybe can add syscall to help 
Solaris compatibility in return for help on the Java side.  Problems: 
what to do to make a LSB-compliant JRE, and what do we do to make it 
easy for non-Linux systems?  (syscall, /proc, /sys)  Jeff: could be a 
backward-compatibility thing; use new kernel features conditionally via 
syscall instead of linking the libc symbols.  Ted: appchk could be a 
problem.  Jeff: could use same approach as dlopen: warn, app vendors are 
responsible for fixing apps that use it wrongly.  Ted: also, syscall 
interface differs between archs, which makes portability between archs 
very difficult.  Jeff: would be a show-stopper in his book.

George: could syscall info be put in the Navigator?  Mats: yes, should 
be done; commenting in progress.  Ted: do we have a process to save 
things like comments?  Mats: not a formal process; the database reload 
process includes workarounds to ensure they aren't dropped.  Comments go 
into a separate table which we should be backing up.  Mats: Novell apps 
among those using syscall().  Darren: will figure out why.  Kay will do 
the same for IBM/CH apps.  Jeff: bug/project?  Mats: not at present; 
should probably set up a project.  Ted: should set this up as a project.

Ted: other stuff on ProjectPlan40?  Cairo is starting to be used.  Mats: 
GTK+ 2.8 and greater require Cairo.  Ted: is Cairo ready--docs, etc.? 
Mats: GTK+ family is pretty well documented; Cairo may be a little less 
so.  Jeff: had talked to Behdad.  Ted: should document on the wiki page, 
thought someone else might be important to pull in.  Mats: old desktop 
project did have a page; should look over to see if there's any 
interesting info to report there.

LSB RPM uplift.  Ted: important?  Mats: yes.  Kay: yes, our spec is very 
stale.

Mats: Cairo is well-documented, including deltas.  George: test suite? 
Mats doesn't know.

Jeff: we should definitely uplift RPM, or consider dropping, and 
dropping would be very unpopular with a lot of folks.  Ted: can we build 
LSB RPMs?  Mats: with the caveat that many tags are just ignored, yes.

Alexey: appchk for POSIX shell scripts.  Darren: should also consider 
adding bash directly.  Alexey: agree.  Ted: using #!/bin/sh but 
including bashisms is a problem.  Would Ubuntu have a problem with 
including bash?  George: isn't bash POSIX compliant?  Ted: yes, but 
there's extra stuff, not supported on POSIX.  Two problems: creating a 
strict POSIX checker, clear and concise definition of the bash 
extensions if we include bash.  Mats: also, hash-bang isn't in the spec. 
  Darren: python and perl?  Jeff: we require people to run the 
interpreter manually, but in practice, people rely on hash-bang. 
Darren: use of env?  Jeff: env is in LSB.  No specific path is recorded, 
though.  Might be a symlink in /usr/bin for distros putting it in /bin; 
/usr/bin/env is nearly universal when hash-bang scripts use env.  Mats: 
env is not mentioned in FHS.

Jeff: reiterate: all LSB 4 tasks should be a bugzilla bug or a project 
plan.  Get those set up now, or be prepared to have things put off until 
later.

Mats: rename for ChipHopper apps should happen in next 10 minutes.



More information about the lsb-discuss mailing list