BUG: tarballs attached to releases since 1.26.0 have files with epoch=0

[sandrotosi]

Describe the issue:

Hello,
it appears the process to build the release tarballs (what im referring to is the file named [numpy-1.26.3.tar.gz](https://github.com/numpy/numpy/releases/download/v1.26.3/numpy-1.26.3.tar.gz) in the asset section of https://github.com/numpy/numpy/releases/tag/v1.26.3, not the source code lnks) have all files with timestamp epoch = 0, aka Jan 1970, small example:

$ wget --quiet https://github.com/numpy/numpy/releases/download/v1.26.3/numpy-1.26.3.tar.gz
$ TZ=UTC tar tzf numpy-1.26.3.tar.gz  --full-time -v | head
-rw-r--r-- 0/0            5495 1970-01-01 00:00:00 numpy-1.26.3/.circleci/config.yml
-rw-r--r-- 0/0            1842 1970-01-01 00:00:00 numpy-1.26.3/.cirrus.star
-rw-r--r-- 0/0            1133 1970-01-01 00:00:00 numpy-1.26.3/.clang-format
-rw-r--r-- 0/0             230 1970-01-01 00:00:00 numpy-1.26.3/.codecov.yml
-rw-r--r-- 0/0              75 1970-01-01 00:00:00 numpy-1.26.3/.coveragerc
-rw-r--r-- 0/0              19 1970-01-01 00:00:00 numpy-1.26.3/.ctags.d
-rw-r--r-- 0/0             322 1970-01-01 00:00:00 numpy-1.26.3/.devcontainer/devcontainer.json
-rwxr-xr-x 0/0             485 1970-01-01 00:00:00 numpy-1.26.3/.devcontainer/setup.sh
-rw-r--r-- 0/0            2593 1970-01-01 00:00:00 numpy-1.26.3/.gitattributes
-rw-r--r-- 0/0            1660 1970-01-01 00:00:00 numpy-1.26.3/.github/CONTRIBUTING.md

this has started with 1.26.0, and it continues with the latest release 1.26.3, while 1.25.2 is not showing this issue.

has something changed in how the assets are generated for a release? could you look into restoring a more "modern" timestamps for release files? this is causing issues downstream in debian, where we have checks in place to make sure nothing "unusual" happens, and files being dated 1970 got flagged

thanks!

Reproduce the code example:

n/a

Error message:

No response

Python and NumPy Versions:

n/a

Runtime Environment:

No response

Context for the issue:

No response

[mattip]

Strange. That tarball is the same one on PyPI and github, and if I understand correctly is created here

numpy/.github/workflows/wheels.yml

Line 198 in b4bf93b

python -m build --sdist -Csetup-args=-Dallow-noblas=true

[sandrotosi]

and indeed even on pypi i can see the same issue:

$ wget -q https://files.pythonhosted.org/packages/d0/b0/13e2b50c95bfc1d5ee04925eb5c105726c838f922d0aaddd57b7c8be0f8b/numpy-1.26.3.tar.gz
$ TZ=UTC tar tzf numpy-1.26.3.tar.gz  --full-time -v | head
-rw-r--r-- 0/0            5495 1970-01-01 00:00:00 numpy-1.26.3/.circleci/config.yml
-rw-r--r-- 0/0            1842 1970-01-01 00:00:00 numpy-1.26.3/.cirrus.star
-rw-r--r-- 0/0            1133 1970-01-01 00:00:00 numpy-1.26.3/.clang-format
-rw-r--r-- 0/0             230 1970-01-01 00:00:00 numpy-1.26.3/.codecov.yml
-rw-r--r-- 0/0              75 1970-01-01 00:00:00 numpy-1.26.3/.coveragerc
-rw-r--r-- 0/0              19 1970-01-01 00:00:00 numpy-1.26.3/.ctags.d
-rw-r--r-- 0/0             322 1970-01-01 00:00:00 numpy-1.26.3/.devcontainer/devcontainer.json
-rwxr-xr-x 0/0             485 1970-01-01 00:00:00 numpy-1.26.3/.devcontainer/setup.sh
-rw-r--r-- 0/0            2593 1970-01-01 00:00:00 numpy-1.26.3/.gitattributes
-rw-r--r-- 0/0            1660 1970-01-01 00:00:00 numpy-1.26.3/.github/CONTRIBUTING.md

[mattip]

When I run the command python -m build --sdist -Csetup-args=-Dallow-noblas=true locally, it properly sets the timestamps.

[rgommers]

This is due to the issue fixed by mesonbuild/meson-python#452. That fix was included in meson-python 0.14.0 - but that fix was just after we created the 1.26.x release branch.

This is already fixed for main; if we want to fix it for 1.26.4 I'll need to look at it. But only after dealing with more urgent pre-2.0-branching stuff.

[rgommers]

@sandrotosi thanks for reporting. This is completely harmless, so in the meantime you can just bypass the check.

[sandrotosi]

@sandrotosi thanks for reporting. This is completely harmless, so in the meantime you can just bypass the check.

i cannot, as it's built-in the debian archive software

until this is fixed by numpy releasing a new tarball, im unable to upgrade to 1.26 (if this increase or not the urgency of getting addressed is up to you, just reporting data)

[rgommers]

There must be something wrong with Debian tooling then. We never got a report for SciPy, and the meson-python issue showed up for only one package way after the bug was present. Here is SciPy 1.10.1 in Debian: https://packages.debian.org/bookworm/python3-scipy. The sdist for that release has the exact same problem: https://pypi.org/project/scipy/1.10.1/#files.

if this increase or not the urgency of getting addressed

It does, a little at least. NumPy 1.26 does not contain any new features compared to 1.25, so from that perspective it's not that important. There may be bug fixes that are relevant though, and not included in 1.25. So we should fix it.