Am Donnerstag, den 10.08.2017, 08:33 +0100 schrieb Edmund Grimley
> > As far as I can see all tests are disabled, failing tests means
> > that
> > the software has bugs, and I'm not sure whether we want to allow
> > software with known bugs into the archives.
> Yes, but if the bug is in the test then disabling the test is one way
> of fixing the bug.
Well, in some cases this might indeed be the case, but ... 

> On the other hand, a test failure on one architecture might (and, in
> a sense, quite likely does)
> indicate a bug in all architectures, so perhaps, to be on the safe
> side...
one typical problem is, that some archs handle "char" as signed and
others as unsigned, and if someone uses char as an int8, then this
results in test failures on one arch but not on the other. This might
be a logical bug on the arch where the test does not fail, but is
doesn't result in wrong calculations.

> Has anyone looked at the failures in detail? If they look like they
> could easily be a consequence of differences in the results of
> floating-point calculations I'd say just disable them for now. If
> there's a segfault, that might be worth investigating.
Unfortunately it is also not that simple: Once I had a bug in some
package I'm actually upstream of where the conversion from a (signed)
float to an unsigned int was handled differently on different archs, in
one case the floating point value was clamped to be non-negative and
then converted, in the other case it was converted to a singed int and
then bit-wise copied to an unsigned, which results in big values for a
negative input, and this is the kind of error I certainly would not
want to ignore. 

In summary, the package is too big for me to fix bugs like these in my
spare time, usually I just forward bugs to upstream, but since they are
not interested in fixing other archs than amd64 and i386 I'm not going
to enable arm64 by myself. If someone else steps up and is willing to
fix bugs on other archs when users start to complain than this someone
is happily invited to co-maintain the package.


Reply via email to