Hi,,
Note current Debian packages only build a minimal subset of
"important" tests (like the bridgetest, pyuno, sal etc.) That
already is a compromise compared to expecting all tests to pass
which is cumbersome, I know. (only have that requirement for amd64
and arm64(
Greetings!
The following talking are all based on source code compilation.
## Bridge
Bridgetest is partly failed. Cpp to cpp is OK, but the remote call from cpp to java is cracked. The reason is that uno2cpp cannot properly fill some struct data returned from the callee cpp function to uno environment. This causes the wrong order of parameters in the returned struct consist of one float and one int. The failing in Java bridge may causes the following failing test cases:
- [JUT] forms_unoapi_1- [JUT] forms_unoapi_2- [JUT] forms_unoapi_3- [JUT] forms_unoapi_4- [CUT] smoketest
And testtools bridgetest itself. See https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=riscv64&ver=4%3A24.2.0%7Erc1-2&stamp=1704187475&raw=0 for example.
(That's why I did https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/commit/7f3a7bb5e1cee1f8c16939f26a43b63e6be9fa2a now), which leaves the NaN failure....
--without-java is already needed on ppc64el s390x and armhf
anyway. For ppc64el it it found that the Java bridge failure mode
probably is even arch-independent...)
Oh, really? Didn't know :/The python side of pyuno does not work properly. Some simple types(such as bool and uint64) are returned with uncleaned higher bits. This may causes the following failing test cases:
- [CUT] sw_uiwriter5- [UIT] cui_dialogs- [UIT] writer_tests- [UIT] writer_tests4- [UIT] writer_tests7
In conclusion, the UNO bridge need to be refactored. I am working on it and there is still much to do.
## NaN Payload
I do not know how this feature affects the performance of libreoffice, since the error code is shown correctly on riscv64.
Who says it's just performance?
https://bugs.documentfoundation.org/show_bug.cgi?id=152943#c7:
"but Calc heavily [...] relies on NaN payload propagation in all math operators."
Calc without Math is a problem.
The relative failing test cases are:
- [CUT] sc_ucalc_formula2
- [CUT] sal_rtl
These test cases may not be fixed in the short term due to lacking of NaN payload support on most riscv64 machines.
And I am completely uncomfortable disabling that test given the above.
Regards,
Rene