8000 BUG: tarballs attached to releases since 1.26.0 have files with epoch=0 · Issue #25681 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our t 8000 erms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
sandrotosi opened this issue Jan 25, 2024 · 7 comments
Closed

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

sandrotosi opened this issue Jan 25, 2024 · 7 comments
Assignees
@rgommers
Labels
00 - Bug
Milestone
1.26.4 release

Comments

@sandrotosi
Copy link
Contributor

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
Copy link
Member
mattip commented Jan 25, 2024

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
Copy link
Contributor Author

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
Copy link
Member
mattip commented Jan 25, 2024

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

@rgommers
Copy link
Member

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 rgommers added this to the 1.26.4 release milestone Jan 25, 2024
@rgommers
Copy link
Member

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

@sandrotosi
Copy link
Contributor Author

@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
Copy link
Member

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.

@rgommers rgommers self-assigned this Jan 31, 2024
@rgommers rgommers mentioned this issue Feb 2, 2024
Merged
@charris charris closed this as completed Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rgommers rgommers

Labels
00 - Bug
Projects
None yet
Milestone
1.26.4 release
Development

No branches or pull requests
4 participants
@charris @rgommers @sandrotosi @mattip
0