[Pkg-xen-devel] Unstripped stuff

[Jeremy T. Bouse]

Guido Trotter wrote:

>Hi!
>
>I was running lintian on our package... Among the copious errors and warnings
>there are:
>
>W: xen-utils: manpage-has-errors-from-man usr/share/man/man1/xm.1.gz 668: warning: can't find numbered character 160
>
>Should we try to fix this, perhaps?
>  
>
    We should try to fix this if we can. If this manpage is one from
upstream we should then submit a patch back upstream, but then again we
should be doing that for any patch.

>E: xen-hypervisor-pae: unstripped-binary-or-object ./boot/xen_pae-syms-3.0.1
>E: xen-hypervisor: unstripped-binary-or-object ./boot/xen-syms-3.0.1
>
>What are these syms files? Are they useful? Should we ship them? Can we strip
>them?
>  
>
    These as I understand are the similar to the normal kernel
System.map files. We may just have to include a lintian override file as
I don't think we want to strip these as it would lose their purpose to
provide symbols for debugging.

>W: libxen3.0: package-name-doesnt-match-sonames libxenguest3.0 libxenctrl3.0
>
>???
>  
>
    This is simply lintian expecting one soname library per library
package. I have this same issue with libfwbuilder which has a couple
soname libraries and I just override it.

>E: libxen3.0: unstripped-binary-or-object ./usr/lib/xen/boot/vmxloader
>E: libxen3.0: statically-linked-binary ./usr/lib/xen/boot/vmxloader
>
>vmxloader is the thing needed to boot unmodified guests with processor support,
>right? So I guess it's statically linked because it cannot rely on having
>libraries available when it runs... How about stripping? Can we go ahead? ;)
>  
>
    I think you made the correct assessment and this may need to go in
the override as I don't thnk there is much we can/should do to it.

>E: libxen-dev: no-shlibs-control-file usr/lib/libxenstore.so
>W: libxen-dev: package-name-doesnt-match-sonames libxenstore
>
>This is interesting... It seems libxenstore.so rather than linking to the
>library IS the library... this screws up our -dev package, and probably our
>policy compliance too... Can we fix this? Do we have to give a soname to the
>library and enter into other library black magic? help! ;)
>  
>
    If you try moving the *.so from -dev to libxen3.0 do you still get
the same error? Does everything run properly if you only have libxen3.0
installed and not libxen-dev?

>Guido
>
>
>_______________________________________________
>Pkg-xen-devel mailing list
>Pkg-xen-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/mailman/listinfo/pkg-xen-devel
>
>  
>