#1098270 trimesh: Build fails on s390x due to math errors in autopkgtest

#1098270#5
Date:
2025-02-18 14:51:07 UTC
From:
To:
Several unit tests of trimesh are currently failing on s390x due to math
errors:
https://buildd.debian.org/status/fetch.php?pkg=trimesh&arch=s390x&ver=4.5.1-3&stamp=1739446909&raw=0

I'm not familiar with IBM Z, but I suspect the errors may be caused by
endianness issues (possibly in a supporting library).
We currently don't have any other big endian builds to compare with, so it's
unclear if this is the case.

Example output:

/build/reproducible-
path/trimesh-4.5.1/.pybuild/cpython3_3.13/build/tests/test_ply.py:127:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

args = (array([-4.0472194e+16, -2.0552418e-08,  8.8456492e+04, ...,
       -2.9970339e+22, -4.0331457e+16, -4.0331457e+16],
 ...95, 1.091329758947, 1.53650744212 , ...,
       2.356194490192, 0.785398163397, 0.785398163397], shape=(8954,)), 7, '')
kwargs = {}, old_name = 'y', new_name = 'desired'

    @functools.wraps(fun)
    def wrapper(*args, **kwargs):
        for old_name, new_name in zip(old_names, new_names):
            if old_name in kwargs:
                if dep_version:
                    end_version = dep_version.split('.')
                    end_version[1] = str(int(end_version[1]) + 2)
                    end_version = '.'.join(end_version)
                    msg = (f"Use of keyword argument `{old_name}` is "
                           f"deprecated and replaced by `{new_name}`. "
                           f"Support for `{old_name}` will be removed "
                           f"in NumPy {end_version}.")
                    warnings.warn(msg, DeprecationWarning, stacklevel=2)
                if new_name in kwargs:
                    msg = (f"{fun.__name__}() got multiple values for "
                           f"argument now known as `{new_name}`")
                    raise TypeError(msg)
                kwargs[new_name] = kwargs.pop(old_name)
E       AssertionError:
E       Arrays are not almost equal to 7 decimals
E
E       nan location mismatch:
E        ACTUAL: array([-4.0472194e+16, -2.0552418e-08,  8.8456492e+04, ...,
E              -2.9970339e+22, -4.0331457e+16, -4.0331457e+16],
E             shape=(8954,), dtype='<f4')
E        DESIRED: array([1.5707963, 1.0913298, 1.5365074, ..., 2.3561945,
0.7853982,
E              0.7853982], shape=(8954,))

#1098270#10
Date:
2025-02-21 09:32:46 UTC
From:
To:
Hi Gregor,

I have started looking at this bug and was able to reproduce it. Continuing my debug, will update further.

Thank you,
Pranav

#1098270#15
Date:
2025-02-22 09:19:04 UTC
From:
To:
I tested the build with Qemu on s390x and ppc64.
Both exhibit the same behavior as reported by buildd[1], which strongly indicates this is an endianness issue.

Investigation is ongoing.

[1] https://buildd.debian.org/status/fetch.php?pkg=trimesh&arch=s390x&ver=4.5.1-3&stamp=1739446909&raw=0

#1098270#20
Date:
2025-02-26 10:07:11 UTC
From:
To:
Hi Pranav,
Thanks for testing!
I didn't see your message and continued to trace the problem via Qemu.

As far as I can see, it's two exporter modules that incorrectly format float32 values in native endianness instead of converting them to little endian format first.
On import, the values are interpreted correctly, which makes the unit tests fail.

I've pushed a patch to Salsa[1], could you test it and verify that it fixes the issue on real hardware?

Thank you very much,
Gregor

[1] https://salsa.debian.org/3dprinting-team/trimesh/

#1098270#25
Date:
2025-02-27 05:51:27 UTC
From:
To:
Hi Gregor,

Thanks for the update.
I am able to successfully build the package on s390x machine with the latest patch applied.

Thank you very much,
Pranav P



Thanks for testing!
I didn't see your message and continued to trace the problem via Qemu.

As far as I can see, it's two exporter modules that incorrectly format float32 values in native endianness instead of converting them to little endian format first.
On import, the values are interpreted correctly, which makes the unit tests fail.

I've pushed a patch to Salsa[1], could you test it and verify that it fixes the issue on real hardware?

Thank you very much,
Gregor

[1] https://salsa.debian.org/3dprinting-team/trimesh/