Hi again, Dominic Hargreaves wrote: > On Sun, Mar 31, 2013 at 04:00:24PM +0600, Andrey Rahmatullin wrote: > > On Sat, Mar 30, 2013 at 05:37:27PM +0000, Dominic Hargreaves wrote: > > > In a clean wheezy chroot: > > > > > > ok 51 - code > > > not ok 52 - errstr > > > > > > # Failed test 'errstr' > > > # at t/050-async-client.t line 268. > > > # 'Lua error: stack overflow (call: out of stack)' > > > # doesn't match '(?^:Partial key in)' > > FWIW it didn't fail here in a sid am64 chroot.
FWIW I could _not_ reproduce that FTBFS when building the (0.15-1) package with pbuilder in a Wheezy chroot on Squeeze (all amd64), but I could reproduce this issue on a Wheezy i386 box (without chroot). Dominic, did you experience the build failure on i386? If so, this looks very similar to https://bugs.launchpad.net/tarantool/+bug/1021177 Citing from there: | After gcc-4.7 patches tarantool began returning different errors on | different architectures: | | if you call 'box.select()' (without arguments): | on amd64 You receive an error: "Partial key in an exact match (key | field count: ..." | but on i386 You receive an error: "Lua error: stack overflow (call: | out of stack)" | | both architectures returned the same errors until gcc4.7 patches The above LP bug report has been marked invalid with the following explanation: | I guess that you use different types of indexes on your hosts (HASH on | amd64 and TREE on i386) | | TREE index supports both box.select(0) and | box.space[x]:index[y]:iterator(box.index.ALL) without a key. | box.select() in this case returns all tuples from a space. The number | of returned tuples is limited only by Lua stack size. | If a result set is too large then Lua raises "Lua error: stack | overflow (call: out of stack)" error. | See https://bugs.launchpad.net/tarantool/+bug/1018775 This is again a (confirmed) bug report against tarantool and there is explained: | Currently select_range() can only return 8000 tuples, because it | puts these tuples into a Lua table, and then calls unpack() on the | table. So for me this currently looks like an issue in tarantool and not in libdr-tarantool-perl. I'm though not sure what's the best way to solve that. For wheezy patching the testsuite to accept both types of error messages is possibly an option to solve this issue. > True; in sid, the failure (with 0.15-1) seems to come at > > # Failed test 'errstr' > # at t/020-low_level_client.t line 125. > # 'Duplicate key exists in unique index 0' > # doesn't match '(?^:already exists)' Indeed. That test seems to check for an error message which likely comes from some of the packages built from the tarantool source package and not from libdr-tarantool-perl itself. And since tarantool in Wheezy has 1.4.6+20120629+2158-1 while Sid has 1.4.8+20130306.1415-1 I suspect that this error message has changed in tarantool between those two versions. That test probably should be more fault tolerant to multiple upstream versions. For the latter issue, patching the testsuite to match the current error message is sufficient. But since libdr-tarantool-perl has already 0.35-1 in Sid, it's no more necessary. (Oh, and my 0.35-1 FTBFS from my previous mail ended up in http://bugs.debian.org/704551) Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
