Re: Bug#959845: librsvg: FTBFS on mips*el: transform::tests::parses_transform_list, transform::tests::parses_valid_transform: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))

Control: retitle -1 librsvg: FTBFS on Loongson-3A: assertion failed: t1.y0.approx_eq(t2.y0, (epsilon, 1))
Control: severity -1 wishlist
Control: tags -1 + confirmed wontfix
Control: notforwarded -1

On Mon, 11 May 2020 at 11:50:43 +0200, Aurelien Jarno wrote:
> On 2020-05-06 11:19, Simon McVittie wrote:
> > There seems to be a strong correlation where this test passes on a Rhino
> > Labs UTM8 but fails on a Loongson 3A. Are there known issues with
> > Loongson 3A hardware, or is there different FPU behaviour, or something?
> 
> Thanks for the analysis. Yep the Loongson 3A is known for having an FPU
> bug that could explain that behaviour. Basically it treats the madd,
> msub, nmadd and nmsub instructions as fused while they should not.

It seems strange to me that a release architecture is using
known-to-be-faulty hardware for buildds. Is there any possibility of
replacing those machines, or taking them out of the buildd rotation
entirely?

In particular, we treated this as a RC bug, and prioritized reporting
it upstream; but we should not be wasting upstreams' time with issues
that are a result of faulty hardware. I don't think we can expect every
package maintainer, or every upstream maintainer, to know that Debian's
mips*el buildds have this bug and that failing build-time tests that
touch floating-point are likely to be not a real bug in the software.

At the same time, I don't want to disable build-time tests or ignore
their results, because for most architectures they are the only evidence
we have that a package works at all.

> I am going to blacklist librsvg from the Loongson 3A based buildds so
> that it doesn't happen again.

Thanks. I'll add a check to d/rules to make the build fail sooner if a
Loongson-3A CPU is detected (when not building with nocheck), to make
sure this blacklisting mechanism doesn't regress.

    smcv