[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: lesstif2 (updated package) [Was: Re: How to give lesstif2 some attention?]



On Wed, 29 Apr 2009 22:09:37 +0200
Paul Gevers <paul@climbing.nl> wrote:

> I am looking for a sponsor for the new version 1:0.95.0-2.2
> of the package "lesstif2", this is not my package but I thought it
> needed some attention.

This is a big package with a high popcon count, do you have the time
for such a large task? On your own? Is there any upstream activity?

> lesstif-bin - user binaries for LessTif
> lesstif-doc - documentation for LessTif
> lesstif2   - OSF/Motif 2.1 implementation released under LGPL
> lesstif2-dev - development library and header files for LessTif 2.1
> 
> The package is not completely lintian clean.
> paul@etna ~/build/sid $ lintian -I -E --pedantic lesstif2/lesstif*.deb
> X: lesstif-bin: spelling-error-in-binary ./usr/bin/mwm dont don't
> I: lesstif2: no-symbols-control-file usr/lib/libMrm.so.2.0.1
> I: lesstif2: no-symbols-control-file usr/lib/libXm.so.2.0.1
> W: lesstif2: package-name-doesnt-match-sonames libMrm2 libXm2
> paul@etna ~/build/sid $ lintian -I -E --pedantic lesstif2/lesstif*.dsc
> W: lesstif2 source: outdated-autotools-helper-file config.guess
> 2005-05-15 W: lesstif2 source: outdated-autotools-helper-file
> config.sub 2005-05-12

The PTS claims 85 lintian errors and warnings, so that is a
considerable advance. The spelling error appears trivial and the
autotools ones are new, there was an announcement about those on
debian-devel regarding problems with new architectures (and, for that
matter cross-building) when these files are so out of date. autoreconf
will sort those out - you could try it in debian/rules but be aware
that updating such an old package could cause new bugs so it might be
best to do the entire refresh thing upstream.

> I intend to take those on in the next round, although I am not sure if
> the package deserves a rename.

Probably easiest done upstream - doing a new SONAME gives you complete
freedom in the upstream source to make sure that bugs are fixed
cleanly. This would add a significant amount of work to the upstream
though.

It's not a rename necessarily - the package contains two libraries, you
could split those out.

$ objdump -p ./lesstif2-0.95.0/debian/lesstif2/usr/lib/libXm.so.2.0.1 |
sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so
\./\1-/; s/\.so\.//'
libXm2

$ objdump -p ./lesstif2-0.95.0/debian/lesstif2/usr/lib/libMrm.so.2.0.1
| sed -n -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)
| \.so\./\1-/; s/\.so\.//'
libMrm2

Those aren't particularly suitable library names, so you may want to
use a lintian override for now and use a more sensible name in a future
upstream release - again, a large step for a package of this size.

> The current maintainer was not sure in
> the brief discussion I had with him (my only successful communication)
> and at the moment I think it is too intrusive. The warning about the
> outdated-autotools-helper-file are new I believe, I didn't see them
> last month. Probably the way this package builds has to be
> reengineerd.
> 
> The upload would fix these bugs: 43640, 314440, 330057, 356017,
> 396199, 479779, 496081, 503361 (and not in the changelog also bug
> 522157, where the original debdiff is found)

> I would be glad if someone would give feedback or upload the package.

It's good that it does build in pbuilder. 

There needs to be a quick, easy way of testing the package - is there a
script or internal program that can be run or a simple way of writing a
test program? What needs to be done to run stuff in the test/
directory? It doesn't use 'make check' (which appears to do nothing
in particular).

It's probably too big for me to push much further, I don't have time
for that much testing.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/

Attachment: pgp4yvzpeGZZG.pgp
Description: PGP signature


Reply to: