Update cfitsio to 4.2.0

[saimn]

Also, update the bundled zlib to 1.2.13

Fix #14015

Description

This pull request is to address ...

Fixes #

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the Extra CI label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the no-changelog-entry-needed label. If this is a manual backport, use the skip-changelog-checks label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but astropy-bot check might be missing; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate backport-X.Y.x label(s) before merge.

[pllim]

Don't want this for 5.2?

[pllim]

😱

eval_l.c(934): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

[saimn]

Don't want this for 5.2?

Yeah probably better to backport, but I don't want to block the release.

So it seems FF_NO_UNISTD_H has been replaced with YY_NO_UNISTD_H ... should be fixed now.

But we have another problem now:

Traceback:
../astropy/astropy/test-sdist/lib/python3.11/site-packages/astropy/convolution/convolve.py:28: in <module>
    _convolve = load_library("_convolve", LIBRARY_PATH)
../astropy/astropy/test-sdist/lib/python3.11/site-packages/numpy/ctypeslib.py:137: in load_library
    from numpy.distutils.misc_util import get_shared_lib_extension
../astropy/astropy/test-sdist/lib/python3.11/site-packages/numpy/distutils/__init__.py:26: in <module>
    from . import ccompiler
../astropy/astropy/test-sdist/lib/python3.11/site-packages/numpy/distutils/ccompiler.py:20: in <module>
    from numpy.distutils import log
../astropy/astropy/test-sdist/lib/python3.11/site-packages/numpy/distutils/log.py:4: in <module>
    from distutils.log import Log as old_Log
E   ImportError: cannot import name 'Log' from 'distutils.log' (/home/runner/work/astropy/astropy/test-sdist/lib/python3.11/site-packages/setuptools/_distutils/log.py)

I think due to setuptools v65.6.0, released 2 days ago with pypa/distutils#183.
For now I guess we can pin setuptools (edit: not in pyproject.toml actually, this is a runtime thing), but with the removal of distutils in Python 3.12 it's time to find a way to replace our use of numpy.ctypeslib.

[saimn]

Also ref numpy/numpy#22623

[Cadair]

it's time to find a way to replace our use of numpy.ctypeslib

Out of interest are we using this for anything other than cfitsio?

[saimn]

It concerns only convolution, not io.fits. I should have opened a dedicated issue but it was late ;). See #14025

[pllim]

I am not sure if we can release anyway until we have a fix for #14025 ?

[saimn]

Rebased on main, tests are passing except one new issue with numpy-dev.

[pllim]

Has this been addressed elsewhere? Looks like it is io.ascii overflow thingy again, @taldcroft / @hamogu / @dhomeier .

AttributeError: module 'numpy' has no attribute 'str'

[pllim]

Do we dare to backport to v5.0.x?

I am going to throw in the cron jobs too, just in case.

[astrofrog]

Looks like this is ready to go and the CI failures are unrelated. I will go ahead and merge this and include in 5.2, but don't think we should backport to LTS?

[hamogu]

They are not very specific about what has changed, but the following note form the release notes indicates that this might be a candidate for backporting, if it can be done with a reasonable level of effort:

This release includes patches to security vulnerabilities. We
strongly encourage this upgrade, particularly for those running
CFITSIO in web accessible applications.

While I don't have a concrete example, it's not inconceivable that a web application that uses astropy might rely on an LTS release. Our LTS policy calls out "critical" security issues as something that we will backport (https://docs.astropy.org/en/stable/lts_policy.html). cfitsio does not use the word "critical" in their description, but "strongly encourage" sounds pretty close to "critical" to me. I'm not experienced enough in the classification system of security vulnerabilities to know the exact definition of "critical", but if this backports cleanly, it might be easier to just do that backport then to decide if the backport is absolutely needed.

Of course, it's easy to say that for me, since I'm not the person doing the backporting...

[pllim]

@meeseeksdev backport to v5.0.x

[pllim]

Huh, what do you know... auto backport works.