> 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? I have the intention to try. And of course all help is appreciated, but I would say that any improvement over inactivity is good. I really think this cleaning up could solve a lot of bugs and annoyance to users. And, no, there is hardly upstream activity. The last couple of years only some rare patches got applied. > 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. > 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. Except for an override for the package-name-doesnt-match-sonames (with reference to the above statement) the package is now appears completely lintian clean: (pbuild17332) etna lesstif2-0.95.0 # lintian --allow-root -I -E --pedantic ../*.changes N: 1 tag overridden (1 warning) (pbuild17332) etna lesstif2-0.95.0 # lintian --allow-root -I -E --pedantic ../*.deb N: 1 tag overridden (1 warning) Michael Biebl wrote: > A less invasive approach is, to build-depend on autotools-dev and copy > config.(guess,sub) from there. If you backup the exisisting files, you > can easily copy them back on clean to return to a pristine state. I fixed the outdated-autotools-helper-file by using the approach proposed by Mickael. (No need to back them up, just removing them on clean). > 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). Running the tests in the package can be done by running using --enable-build-tests on configure time. Then in the test/Xm or test/Xm-2.1 dir running the testall command. Apparently, a lot of these test have failed for a long time (nobody cared?). To compare, I did the tests (except for printing, where I needed a patch to build anyway) for a build of lesstif2-0.95-2.1 lesstif2-0.95-2.1ubuntu1 and lesstif2-0.95-2.3. The results: 2.1: 350 failed out of 609 2.1ubuntu1: 350 failed out of 609 (although two test results swapped with 2.1) 2.3 351 failed out of 609 I will look into this further, but still, this upload would fix a lot of standing bugs. A new version is available on mentors: - URL: http://mentors.debian.net/debian/pool/main/l/lesstif2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/lesstif2/lesstif2_0.95.0-2.3.dsc I hope somebody is able to give me more feedback (or ultimately upload the package). Paul
Attachment:
signature.asc
Description: OpenPGP digital signature