i686 core-updates failure.

[Kaelyn <kaelyn.alexi@protonmail.com>]

Hi,

I've been working on getting wine to build on core-updates, with the most recent blocker being python-numpy failing two tests on i686 (one of which is apparently too big for 32-bit systems, based on the comment in the Gentoo ebuild of python-numpy where they skip the test). I just poked through the CI dashboard for the latest core-updates evaluation to see if it was hitting the same failure (it was), and discovered an odd chain of dependencies. Before going into the chain, I want to mention that wine has 6 failing dependencies[1], one of which is pulseaudio, two of which include pulseaudio as part of why they failed, and two include dependency failures that are on pulseaudio's dependency chain (the 6th failed dependency is due to qtbase which I didn't look into; none are direct failures).

On to the odd chain:
* The sole failed dependency of pulseaudio is bluez
* bluez's sole failed dependency is libical
* libical's sole failed dependency is gtk-doc (also a failed dependency of two other wine dependencies)
* gtk-doc's sole failed dependency is dblatex
* dblatex's sole failed dependency is inkscape(?!?!?)
* inkscape's sole failed dependency is python-numpy, which is failing two tests.

I call the dependency chain odd in that pulseaudio--which is near the heart of a lot of Linux software that supports audio--is failing because inkscape--a graphical vector editor--is a dependency of a tool designed to extract API documentation from source code.

For the dependency chain, I have no real thoughts, goals, or proposed changes other than surprise that pulseaudio fails to build because a GUI SVG editor failed to build.

For the actual failures in python-numpy[2]:
1. TestUfunc::test_identityless_reduction_huge_array in numpy/core/tests/test_ufunc.py: as I alluded to earlier, the Gentoo ebuild[3] disables this test with a comment that the test is "too large for 32-bit platforms".
2. TestKind::test_all in numpy/f2py/tests/test_kind.py: I'm not sure why this test is failing or what to do about it, since it seems to be seeing incorrect values for objects coming from Fortran code. Perhaps a type size mismatch for 32-bit platforms, but hard for me to say since I don't know Fortran and I haven't had luck finding other reports of that test failing.

Cheers,
Kaelyn


[1] https://ci.guix.gnu.org/build/843194/details
[2] https://ci.guix.gnu.org/build/712672/log/raw
[3] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-python/numpy/numpy-1.24.0.ebuild#n142