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

Darren Davis 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 
tied up.

Later,

Darren

> 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 
> environment.
>
> 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
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss
>   




More information about the lsb-discuss mailing list