TST: Some fixes & refactoring around glibc-dependent skips in test_umath.py

[h-vetinari]

I was looking at the test skips in the numpy feedstock by chance, and thought of fixing #15179, now that there's a glibc-version check that was introduced in #19209.

First step is taking that check and turning it into a reusable boolean. The second commit applies that also to a different glibc-relevant test (though, strictly speaking, it's left open in 8b2b7a2 whether this also works for 2.17 & 2.18 - I can parametrize the check of course, but not sure that's worth the effort?)

Finally, applying the fix suggested by @r-devulap (which has been tested in a conda-forge PR to work) conditionally on the glibc-version, so that the test in the numpy-feedstock can be switched on unconditionally.

Fixes #15179

[h-vetinari]

The second commit applies that also to a different glibc-relevant test (though, strictly speaking, it's left open in 8b2b7a2 whether this also works for 2.17 & 2.18 - I can parametrize the check of course, but not sure that's worth the effort?)

I decided to fix this, because the correct inclusion/exclusion was actually off for the glibc-version in manylinux 2014.

[h-vetinari]

Not sure what the timeline for 1.22 is, but it would be good if this PR could be looked at before that (and merged, ideally, as it would allow conda-forge to remove a test skip - which are hardly ever looked at and prone to bit rot).

CC @charris @seberg @rgommers

[charris]

The use of alphabetical order works, but it bothers me :)

[h-vetinari]

I tend to agree, but then, it was this way before already, and I didn't want to overengineer something for 3 tests...

What would you prefer? Comparing tuples? Using something like distutils.version.LooseVersion?

[charris]

"2.19" or "2.18"?

[h-vetinari]

Not sure what that would do? If it's older than 2.18, ít's definitely older than 2.19?

[charris]

I was looking at the older comment that it was OK for glibc > 2.17.

[charris]

    skip_longcomplex_msg = ('Trig functions of np.longcomplex values known to be '
                            'inaccurate on aarch64 for some compilation '
                            'configurations, should be fixed by building on a '
                            'platform using glibc>2.17')

[h-vetinari]

For the if-branches here, the pertinent part (being deleted) is:

            # Can use 2.1 for > Ubuntu LTS Trusty (2014), glibc = 2.19.
            if skip_longcomplex_msg:
                pytest.skip(skip_longcomplex_msg)

I take from this comment that anything from glibc 2.19 onwards should be fine to take the else-clause (with the 2.1*eps). I cannot very (easily or quickly) how far back in terms of glibc-versions things would work, so I didn't try to change the version-boundaries as stated (or commented) in the code.

[h-vetinari]

[...] should be fixed by building on a platform using glibc>2.17'

Right, I couldn't evaluate that corner case (2.18), so I went with the conservative choice, of still running the check (resp. the looser tolerance) with 2.18.

Before the last commit, I actually had this as glibc_older_than_2_17, but then realized that this would do the wrong thing (due to glibc > 2.17) for manylinux 2014.

[charris]

OK, probably not worth worrying about. Manylinux2014 itself is getting towards end of life.

[h-vetinari]

Thanks a lot for taking the time to review @charris! :)

[charris]

Thanks @h-vetinari .