Bug#981030: RFS: sctk/2.4.10-20151007-1312Z+dfsg2-4 -- speech recognition scoring toolkit

[Giulio Paci <giuliopaci@gmail.com>]

Hi Bastian,

Il sab 23 ott 2021, 11:58 Bastian Germann <bage@debian.org> ha scritto:

> Am 23.10.21 um 10:43 schrieb Giulio Paci:
> > Since the NMU has already solved the FTBFS, I think I can try to upgrade
> > the tool as well. Unfortunately upstream did not add neither a tag nor a
> > release to github. I have just asked if it is possible to add them
> > (before moving to github upstream used to release tarballs with any new
> > release).
>
> As the last commit is the one changing the version and is from 2018, it
> is reasonable to assume that that commit is the release. There is no
> activity since then and I do not expect upstream to react to your
> request. So please package 2.4.11 regardless of tags.
>

I have discussed with upstream and they agreed to merge some of the
currently open pull requests, as well as tag new versions, so I will
package latest version (currently 2.4.12) as soon as I find time.

>
> I have invited you to https://salsa.debian.org/debian/sctk which also runs
> the Salsa CI pipelines to demonstrate the i386 issue. Please use that repo
> going forward.


I will do. Thank you for setting it up.

Build tests on i386 fail with:

test17: Vietnamese case conversion

Executions complete: Comparing output

   Removing DIFF tests

   Removing SLM tests

    !!!!!  TESTS HAVE FAILED  !!!!!


I checked the issue and found out that the failing tests are test13 and
test13b in sclite.
The failing test case relies on the assumptions that, when a and b have the
same double value:
1) "a < b" is false;
2) "a - b" is 0.0.
For some reason the two above assumptions are sometime disattended on i386,
and thus the "overlap" function in src/sclite/ctm2ctm.c is not always
providing the expected results.
The overlap behavior is unstable and varies according to specific flags
being used to compile the executable (e.g., enabling debug is often enough
to not trigger the failure, but enabling -O3 and -mtune=native generally is
enough to trigger the failure again) or the context surrounding the
operations (e.g., accessing the memory address of the operands).

I guess the main reason for this weird behavior is described in (option
-mfpmath):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/x86-Options.html#x86-Options

and in (option -ffloat-store):

https://gcc.gnu.org/onlinedocs/gcc-10.3.0/gcc/Optimize-Options.html#Optimize-Options