[lsb-discuss] Regarding doubts in LSB support for HPLIP.

Vladimir Rubanov vrub77 at gmail.com
Tue Nov 8 13:04:26 UTC 2011


Sorry for off-topic, but I am also glad to see the list is back. Best 
wishes from Russia, dear colleagues!

Vladimir Rubanov.
--
Vladimir Rubanov, Ph.D., PMP
VP Engineering and Deputy CEO
ROSA Lab / Development Center of Mandriva Linux
Mob.: +7-916-117-25-28
http://rubanov.pro/
http://rosalab.ru/


8 Ноябрь 2011 г. 16:59:23, Wichmann, Mats D писал:
>
> Till, you've managed to get the first post through since the servers
> went away - I didn't even know the
> lists were back yet!!!
>
>
> On Tue, Nov 8, 2011 at 12:51 AM, Till Kamppeter
> <till.kamppeter at gmail.com <mailto:till.kamppeter at gmail.com>> wrote:
>
> Sorry for the late answer, I was on the Ubuntu Developer Summit
> all last week. Now I am back and yesterday I have recovered the
> OpenPrinting web server.
>
> I am CCing also the LSB mailing list to get helps from the people
> who are making the LSB framework.
>
> More inline.
>
> On 10/31/2011 05:06 AM, Kumar, Sanjay wrote:
>
> Hello Till,
>
> While going forward in making HPLIP as LSB compliant, we have some
> doubts. Please help us in providing the clarification on the same.
> Thanks in advance for all the help.
>
> 1) LSB package does not contain the latest versions of
> libraries which
> are LSB compliant.
>
> e.g LSB compliant *libcupsimage.so* does not contain latest
> function
> calls, e.g *cupsRasterReadHeader2* function is not present in
> */opt/lsb/lib/libcupsimage.so.__2*, however HPLIP makes use of
> this.
>
>
> Make sure you use the newest LSB (4.1).
>
>
> The LSB SDK "stub" libraries (/opt/lsb/lib/*) contain only those symbols
> which are part of the agreed ABI for that version. To put what Till
> said in a
> different light, you should use the oldest version of LSB which suits
> your
> needs (as in providing the symbols needed), but no older; 4.1 is the
> latest.
>
> There is a set of analysis tools which can look at an "application" (rpm
> package, single binary, directory tree, whatever) and provide an analysis
> of this situation - use of non-LSB interfaces and libraries, version
> compatibility info, etc. (lsb-app-checker). I believe the LSB
> repositories
> are still unavailable however, so there might be a bit of a delay.
>
> If you find there is no version of LSB that provides what you need, then
> let the project know what's missing (mailing list post is fine, preferred
> method was filing a bug but I don't know if that's been restored yet),
> AND take a look at whether an LSB-mode build can code around the
> absence of those functions. The aforementioned lsb-app-checker can
> submit a report for you if you click a checkbox, that's another way to
> provide usage information back to the project.
>
>
>
> 2) Following shared libraries are not present which are needed
> by HPLIP.
>
> a) libnetsnmp.so
>
> b) libcrypto.so
>
> c) libdbus.so
>
> d) libusb.so
>
> e) libcups.so (present but very old version)
>
> f) libcupsimage.so (present but very old version)
>
>
> Make sure you use LSB 4.1 and if the libraries are too old or
> still missing, link the desired ones statically.
>
> Is there any plan/update on having LSB compliant versions of these
> libraries from the vendors? Because if the package is
> statically linked
> with 3rd party libraries then package will lose the advantage
> of using
> always latest library.
>
>
>
> see after next question for a comment on these
>
>
>
> The distribution vendors do not issue LSB packages of additional
> libraries.
>
> You get an LSB-compliant package if you link the libraries
> statically. If the package once works it is not a big problem if
> the statically linked libraries are not the newest ones. The
> communication protocols provided by the libraries do not change so
> quickly, and as you issue a new driver version every 2-3 months,
> you can make the new version's LSB package always with updatyed
> statically linked libraries.
>
> 3) Sometimes 3^rd party latest libraries cannot be built in LSB
> environment (lsbcc etc), e.g latest version of *libdbus*
> (1.0.8) failed
> tobuilt with lsbcccompiler. Only (0.1.12) version could be
> built with
> lsbcc, just in case we want to link it statically.
>
>
> Can someone from the LSB developers help here, so that the HPLIP
> developers get libdbus 1.0.8 built under LSB?
>
>
> If some details are provided on the failures, I'm sure they'll be
> looked at.
> libdbus is actually on the roadmap; libcrypto has not been since it's
> part
> of the openssl suite, which is excluded for various reasons I don't want
> to rehash here (for ssl support, libnss3 is provided
> in LSB, see here for some conversion notes:
> https://fedoraproject.org/wiki/FedoraCryptoConsolidation). The other
> mentioned libraries have not, I believe, been requested for inclusion.
>
>
> 4) LSB looks mostly to be a coding/building standard. Does it
> assure
> same quality on all distro’s (particularly, from different
> vendors)?
>
>
> Can someone of the LSB developers answer this? Thanks.
>
>
>
>
> "Quality", on the surface, is not a problem solved by LSB. However,
> as part of the compatibility exercise, the fact that interfaces are
> described functionally, rather than by version-of-library, means tests
> can be coded which test for that functionality. To the extent such
> tests exist in the LSB suite, one could consider this a kind of quality
> promise - in order to be certified conforming, a candidate distro will
> have to have passed tests for the LSB functionality. [the caveat is
> that test coverage varies by library, from "very extensive" in the case
> of glibc all the way to "almost none" for certain libraries]
>
>
> 5) The major differences we see across distro’s are in CUPS,
> GS, etc
> which are not LSB compliant and which are being used heavily
> by HPLIP.
> Many issues are caused because of these components like *GS
> versions
> (e.g versions 9.00 and 8.71). So *how much LSB would help us
> in reducing testing efforts and how safe is this to skip
> testing of HPLIP on
> every LSB compliant distribution?
>
>
> Can someone of the LSB developers answer this, too? Thanks.
>
>
>
> There's no simple answer to this question in general, as it varies by
> situation.
> Given this description - if you're running into problems with non-LSB
> components -
> it seems somewhat unlikely. The most conservative view (again - it varies
> by case) is "LSB provides a base for building an application which
> will deploy
> on a wide range of systems but does not remove the need for testing on
> those systems". My guess without knowing the circumstances would be
> that you could over time develop a minimal test suite which
> spot-checks familiar
> problem areas and would not have to do a full test on everything. But
> it's
> only a guess without knowing the precise details.
>
>
>
>
>
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss




More information about the lsb-discuss mailing list