i686 core-updates failure.

[Kaelyn]

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