topercent2 test fail on i386 and lpia causing FTBFS

[Julien Lavergne]

The topercent2 fail on i386 and lpia, causing FTBFS of xapian-core.
Build on amd64 work fine.

[Julien Lavergne (gilir)]

It occurs on Karmic, with the 1.0.12 version :
http://launchpadlibrarian.net/26494761/buildlog_ubuntu-karmic-i386.xapian-core_1.0.12-2_FAILEDTOBUILD.txt.gz
http://launchpadlibrarian.net/26489109/buildlog_ubuntu-karmic-lpia.xapian-core_1.0.12-2_FAILEDTOBUILD.txt.gz

[Olly Betts (ojwb)]

This testcase is also failing for hurd-i386 on Debian, though with a different backend (your failures are for flint, the hurd-i386 is for remote-prog):

http://buildd.debian-ports.org/fetch.php?pkg=xapian-core&arch=hurd-i386&ver=1.0.12-2&stamp=1241429577&file=log&as=raw

I haven't investigated this yet (I'd have to track down a hurd-i386 to test it on, or install it specially), but had wondered if it was related to excess precision. Does lpia have excession precision (i.e. does it represent FP results in registers with a higher precision than they have in memory)?

It is also curious that 1.0.12-2 built fine for me on jaunty:

https://launchpad.net/~xapian-backports/+archive/ppa

It would be useful to see the output from this run in the build tree on either (or both):

cd tests
./apitest -bflint -v topercent2

[Julien Lavergne (gilir)]

This is the output of the apitest on a i386 Karmic :

gilir@blitz:~/build/tests$ ./runtest ./apitest -v topercent2
Running test: topercent2... ok
./apitest backend inmemory: All 1 tests passed.
Running test: topercent2... ok
./apitest backend flint: All 1 tests passed.
Running test: topercent2...
../../tests/api_anydb.cc:538: ((mymset) == (localmset))
Expected `mymset' and `localmset' to be equal: were Xapian::MSet(Xapian::MSet::Internal(firstitem=0, matches_lower_bound=6, matches_estimated=6, matches_upper_bound=6, max_possible=4.2134211395907756881, max_attained=1.6741219241405633777, Xapian::MSetItem(3, 1.6741219241405633777, ), Xapian::MSetItem(1, 1.0933145716234105027, ), Xapian::MSetItem(4, 0.84896816292121257685, ), Xapian::MSetItem(2, 0.21473351928432724001, ), Xapian::MSetItem(5, 0.18922708513455099855, ), Xapian::MSetItem(6, 0.043131803408968126534, ))) and Xapian::MSet(Xapian::MSet::Internal(firstitem=0, matches_lower_bound=6, matches_estimated=6, matches_upper_bound=6, max_possible=4.2134211395907747999, max_attained=1.6741219241405633777, Xapian::MSetItem(3, 1.6741219241405633777, ), Xapian::MSetItem(1, 1.0933145716234105027, ), Xapian::MSetItem(4, 0.84896816292121257685, ), Xapian::MSetItem(2, 0.21473351928432724001, ), Xapian::MSetItem(5, 0.18922708513455099855, ), Xapian::MSetItem(6, 0.043131803408968126534, )))

 FAILED
./apitest backend multi: 0 tests passed, 1 failed.
Running test: topercent2... ok
./apitest backend quartz: All 1 tests passed.
Running test: topercent2... ok
./apitest backend remoteprog: All 1 tests passed.
Running test: topercent2... ok
./apitest backend remotetcp: All 1 tests passed.
./apitest total: 5 tests passed, 1 failed.

[Olly Betts (ojwb)]

Thanks.

It seems that max_possible is out by a factor of almost exactly (1 + DBL_EPSILON), and everything else is the same, so this doesn't seem to indicate a real problem.

I'll try to find a fix for this, but I'd suggest just adding this to the top of the testcase topercent2 for now:

    SKIP_TEST_FOR_BACKEND("flint");

[Michael Terry (mterry)]

Olly, the failure was in the 'multi' backend, not the 'flint' one.

Here's a debdiff.

[Olly Betts (ojwb)]

Oops, misread the test log - thanks for pointing out my error.

The patch looks good to me as a workaround, assuming it fixes the FTBFS (I would expect it to).

I'll try to sort out a better fix for the next upstream release.

[Olly Betts (ojwb)]

I've just uploaded xapian-core 1.0.13-2 to Debian unstable, which should fix this issue.

I'd suggest just syncing this version to karmic (at least if it does OK on the debian buildds for the archs Ubuntu supports), but FYI this is the patch I added (which also addresses another testsuite bug - the harness was leaking file descriptors due to a bug in the mechanism which was meant to track and close them):

http://trac.xapian.org/export/12902/branches/1.0/xapian-core/debian/patch

[Julien Lavergne (gilir)]

As xapian-core is already in sync with Debian, it should be sync automatically (when the sync machine will wake up).

[Martin Pitt (pitti)]

Got autosynced now.