Description of problem:

I’m working on updating python-trimesh with the following improvements:

  - Use pyproject-rpm-macros (“new guidelines”) so the many BuildRequires are
    more manageable
  - Update -easy and -all subpackages to follow the pattern in the PythonExtras
    Change (https://fedoraproject.org/wiki/Changes/PythonExtras#Extras_metapackages)
  - Restore the python3dist(xxhash) to the [easy] and [all] extras, now that
    I have packaged it
  - Build HTML documentation and add a -doc subpackage

Additionally, I’m trying to work out the various architecture-dependent issues in the package in a methodical way.

The package is fundamentally noarch, as it is only pure-Python code. However,
it looks like it will nonetheless need to be be switched to an arched package:

  - Arch-dependent test failures (related to issues around endianness or
    native word length) are relatively common. An arched package means builds
    are done on all architectures every time, so these problems are
    discovered early. When there are failures that cannot be worked around
    immediately, it also allows the use of %%ifarch to skip tests
    conditionally.

    This *does not* preclude making all of the binary subpackages noarch,
    as long as the contents match on all architectures.

  - Some dependencies have ExcludeArch restrictions. Normally we would write
      ExclusiveArch:    <arch1> <arch2> … noarch
    per
      https://docs.fedoraproject.org/en-US/packaging-guidelines/
          #_arch_specific_runtime_and_build_time_dependencies
    but in this package nearly all dependencies are *soft*, so rather than
    disabling affected architectures, we instead need to patch out the
    offending dependencies and work around their absence. The result is
    different builds for different architectures, i.e., an arched package.
    This *does* preclude making all of the binary subpackages noarch, since
    building on different architectures produces a different result.

    (Even the upcoming -doc subpackage can be different on different
    architectures, since there are issues converting certain notebooks to HTML
    on certain architectures.)

The purpose of this bug is to precisely document test failures on big-endian
architectures (that is, s390x), and to discuss what to do about them.

Version-Release number of selected component (if applicable): 3.9.20 (release: work in progress in a fork)


How reproducible:

Edit the spec file to ensure all tests are executed and the package is built on all architectures. Skip CacheTest::test_hash, which is likely to fail on architectures other than x86_64 due only to unexpected performance characteristics. Work around any other obvious issues. Do a scratch build.

(Sorry, that’s not very useful. But I can point to a particular commit in a
dist-git fork if reproduction is desired.)

Actual results:

=========================== short test summary info ============================
FAILED tests/test_obj.py::OBJTest::test_vertex_color - AssertionError: assert...
FAILED tests/test_ply.py::PlyTest::test_face_attributes - AssertionError: 
FAILED tests/test_ply.py::PlyTest::test_vertex_attributes - AssertionError: 
==== 3 failed, 439 passed, 2 deselected, 7872 warnings in 155.75s (0:02:35) ====

Detailed logs to be attached.

Expected results:

All tests pass.

Additional info:

I see two ways to proceed:

  1. Skip all of these tests on s390x, understanding that some parts of the
     API really will be broken on this architecture despite the package not
     containing compiled extensions.

  2. Exclude s390x. (Block
     https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-s390x from this
     bug, and link this bug from the spec file.) This keeps users on that
     architecture from being surprised by brokenness, but also keeps them
     from successfully using the APIs that are not broken.

Fixing all the bugs would be great, but is probably not a realistic
short-term goal.

These could be reported upstream in a follow-up to
https://github.com/mikedh/trimesh/issues/249.

See also https://bugzilla.redhat.com/show_bug.cgi?id=2006452, the corresponding
bug for 32-bit issues.