Bug#1079545: gtk4: test regression in 4.15.x: css/parser/math2.css test fails on armel

[Simon McVittie]

Control: tags -1 + patch pending

On Sat, 24 Aug 2024 at 09:24:02 -0400, Jeremy Bícha wrote:
> A new test added in gtk4 4.15.* is failing on armel but not on any
> other release architecture.
...
> not ok 1 /<<PKGBUILDDIR>>/testsuite/css/parser/math2.css

The bug is that GTK implements CSS expressions like `round(up, 18px, 5px)`
by using fesetround() to select the desired rounding mode, and nearbyint()
to do the rounding.

On all release architectures except armel, this works as intended:
floating point arithmetic is done in hardware, and the FPU supports
all four of the rounding modes required by GTK's CSS implementation
(FE_TONEAREST, FE_UPWARD, FE_DOWNWARD, FE_TOWARDZERO).

On armel, the software implementation of floating-point only implements
the default FE_TONEAREST[1], and the other modes are not available. This
causes the test to fail: `round(to-zero, 18px, 5px)` comes out as 20px
instead of the intended 15px, and similar for `round(down, 18px, 5px)`.

[1] see also https://lists.debian.org/debian-arm/2008/03/msg00001.html

I was able to get this test passing with GTK 4.15.6 by applying the
attached patch, also available as part of the update to 4.15.6 in
<https://salsa.debian.org/gnome-team/gtk4/-/merge_requests/26>
(I have not tried to backport it to 4.15.5 but I suspect it would apply
cleanly there too).

I have intentionally not tried to upstream this patch, because I can
already predict what will happen: upstream will ask why I'm trying to
run GTK on an old embedded device with no FPU and no useful GPU, and I
will not have a good answer, because I, personally, have never wanted
to do that. I find being upstream's punching bag for all of Debian's
architecture support decisions to be really demotivating, and even if
I had unlimited motivation, I think upstreaming this myself would be
tactically a bad idea: every time I try to make upstream spend their
limited time on an architecture that they don't have any interest in
supporting, I feel as though I'm coming one step closer to the point
where they start intentionally ignoring me, which would significantly
harm my ability to do other work that the project expects from me.

So, I'm invoking Debian Constitution §2.1.1 and declining to attempt
to fix this upstream myself. If someone from the ARM porting team
feels strongly that armel should continue to be a first-class-citizen
architecture for GTK for whatever reason, please take over here.

Thanks,
    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtkcssnumbervalue-Don-t-use-fesetround-on-ARM-softfloat.patch
Type: text/x-diff
Size: 2005 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20240901/2039a7a5/attachment.patch>