[lsb-discuss] LSB conf call notes for 2008-03-19
ddavis at novell.com
Mon Mar 24 08:32:56 PDT 2008
Jeff Licquia wrote:
> Attendees: Sam, Jeff, Ted, Stew, Dan, Marvin, Alexey, Robert.
> Jeff: Low attendance. Sam: may be because of the conf call bridge;
> should check. Jeff observes that a few people are joining w/o the call
> getting notification.
Also was Novell's BrainShare conference so everybody from Novell was
> SI. Marvin was able to get builds on devel working on all archs except
> ppc64. Sam's fixes so far haven't caused any problems. Now need to add
> the rest of the 3.2 stuff. Sam: no list, is working on one. Ted:
> ProjectPlan32. Alexey: can use the Navigator for that as well. Jeff:
> Marvin's time? Marvin: will work on it this week w/o official support;
> if it takes more than a week, will revisit.
> Jeff: 4.0 SI, domu set up. Ted: power? Marvin: pretty beefy, but the
> more we put on it, the more loaded it gets. Ted: check with Antonio.
> Thinking about getting a 4-way x86_64 box for this sort of thing, still
> working on newer Power box. Markus looking to get a bigger ia64 box.
> Tools. Jeff: what does it mean to improve our tools? What tasks do
> these involve? Ted: sent an email to ISPRAS, should send to the list.
> Packaging: packaging the chroot SI w/ packages, such that one could
> easily launch the SI via a icon, via ssh to a special sshd, or
> something. Make lsbcc work in a slightly more relaxed mode for
> generating an app that ran on multiple distros. Improve ATK Manager;
> Cal can look at filling in the notes. What additional things could we
> do for the tools? Robert: see presentation I gave at F2F. Two areas:
> building an LSB compliant app, and testing it. Building: automation.
> Must make it as easy to automate as possible. What are the requirements
> from an IT perspective of setting that up? SI that "just runs" would be
> nirvana. Second best: install these packages, and that will give you a
> devel system. Chroot not easy. Ted: idea not just chroot, but ways to
> use the chroot that are easy, beyond just "chroot to here". Bind mounts
> to home dirs, etc. Robert: depends on the setup. Ted: what setups have
> you used? Robert: triggers in version control are popular. That's
> where the chroot hooks would have to work. Ted: command-line way to
> launch the chroot and start the build is what you mean? Robert: yes.
> Multiple ways to get in are good; ssh would be useful too. Developer on
> desktop is not the only use case to think about. Back-end build server
> is also a very important tool. Ted: what tools do we need in the build
> env besides the base SI plus the LSB tools plus a compiler? (awk, sed,
> etc.) Robert: easy way to install the chroot, add tools (scons, ant,
> etc.), and build is what we need. Ted: need to think; some stuff may
> not be LSB-compliant. Should think about what tools we provide by
> default. Robert: yes, it's hard to figure out, may be hard to do. Ted:
> incremental approach, start with 1.0 and iterate. Robert: lsbcc should
> produce results the developer can depend on; results with lsbcc should
> match results with SI/buildenv build. Ted: maybe the buildenv is the
> only supported way to do builds; is that useful? Is the buildenv too
> much? Robert: resources not an issue.
> Ted: ATK? Robert: got an email from Alexey; request to test the latest
> ATK, not gotten to it yet. Wants to point ATK to the entry point for
> the app, press "go", get a complete report. Alexey: we believe the
> current ATK Manager should do this. Experimental ATK Manager available
> that does not require root access to install/use. Two reports: journal
> analysis, dependency report; working on better presentation of this
> information. Welcome any ideas. Robert: did you send me the
> experimental version or the public version? Alexey: sent released
> version; experimental version available from the wiki. Robert: send me
> experimental stuff, will test as time constraints allow, will try to
> turn around within a week.
> Ted: dynamic linker proposal. Jeff: quick summary. Robert: how? Ted:
> at early stage of executable (crti.o, init section), code fragment that
> checks for ld-lsb.so and if it's a symlink. If ld-lsb is different from
> standard dynamic linker, re-exec with the LSB interpreter. Robert: ISVs
> need to be able to support customers; don't have the ability to dictate.
> Ted: Enabling building image on multiple distros is a key feature for
> mid-tier ISVs. Robert: reasonable to check at install time for LSB.
> Relaxed mode may not be necessary. Jeff: relaxed mode vs. dynamic
> linker? Ted: relaxed mode means relaxed attitude regarding standard
> libs. Robert: linker thing is a definite win, may not be necessary in
> the long run. Network installs may have an issue with ensuring a LSB
> Ted: received only a few bugzilla ballots; can we get those in by the
> end of the week?
> Ted: will visit Indianapolis on 27th; should set up a meeting.
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
More information about the lsb-discuss