Python 3.12.4: Extract downloaded archive; gzip: stdin: not in gzip format about setup-python HOT 22 CLOSED

The manifest that holds broken releases has been reverted by @HarithaVattikuti : actions/python-versions#282

This removes 3.12.4 & 3.13.0b2. (but installing latest 3.12 or dev 3.13 now works again - using 3.12.3 & 3.13.0b1).

actions/python-versions#285 should resolve the issue.

from setup-python.

@jasmitha-meka as a workaround you can pin the version 3.12.3

from setup-python.

Hello @frenck
Thankyou for creating this issue. we are working on the fix and will get back to you sooner.

from setup-python.

Can confirm pinning version to 3.12.3 allows our actions to pass, thanks all.

from setup-python.

tested all assets from https://github.com/actions/python-versions/releases/tag/3.12.4-9442300799

NONE OF THEM ARE WORKING AS EXPECTED.

from setup-python.

The hashes do not match at all.

3.13.0-beta.2

$ sha256sum -c hashes.sha256
python-3.13.0-beta.2-darwin-arm64.tar.gz: FAILED
python-3.13.0-beta.2-darwin-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-20.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-22.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-linux-24.04-x64.tar.gz: FAILED
python-3.13.0-beta.2-win32-x64.zip: FAILED
python-3.13.0-beta.2-win32-x86.zip: FAILED
sha256sum: WARNING: 7 computed checksums did NOT match

3.12.4

$ sha256sum -c hashes.sha256
python-3.12.4-darwin-arm64.tar.gz: FAILED
python-3.12.4-darwin-x64.tar.gz: FAILED
python-3.12.4-linux-20.04-x64.tar.gz: FAILED
python-3.12.4-linux-22.04-x64.tar.gz: FAILED
python-3.12.4-linux-24.04-x64.tar.gz: FAILED
python-3.12.4-win32-x64.zip: FAILED
python-3.12.4-win32-x86.zip: FAILED
sha256sum: WARNING: 7 computed checksums did NOT match

The files are also double in size than the previous versions because of the corruption. The source archives are fine.

3.12.3

$ sha256sum -c hashes.sha256
python-3.12.3-darwin-arm64.tar.gz: OK
python-3.12.3-darwin-x64.tar.gz: OK
python-3.12.3-linux-20.04-x64.tar.gz: OK
python-3.12.3-linux-22.04-x64.tar.gz: OK
python-3.12.3-linux-24.04-x64.tar.gz: OK
python-3.12.3-win32-x64.zip: OK
python-3.12.3-win32-x86.zip: OK

from setup-python.

I have noticed this is working in ubuntu-latest runner, but not on my self-hosted runner, both using the same container: ubuntu:24.04 for testing purposes.

The hosted runners have an cached toolchain with multiple versions of python already installed. The action is using that instead downloading an version.
The selfhosted image does not have sush toolchain.

GitHub hosted is running on 50Gb+ VMs in Azure to minimize download and install cycles.

Edit:
Info location hosted runner "image": https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md

from setup-python.

However it's weird that the deflate header is kept as-is while the 1f bytes are correct.

The ef bf bd pattern is a specific symbol: https://www.cogsci.ed.ac.uk/~richard/utf-8.cgi?input=%EF%BF%BD&mode=char

That is the symbol you usually see when UTF-8 is being displayed as ASCII. It looks the files have been treated as text causing all the non-ASCII (i.e. binary) data being treated as unprintable characters thus corrupting it in the process.

from setup-python.

Hello Everyone, we merged the fix for this issue. Please validate from your end and confirm.

from setup-python.

Same thing with 3.13.0b2:

Run actions/setup-python@v5
Installed versions
  Version ~3.13.0-0 was not found in the local cache
  Version ~3.13.0-0 is available for downloading
  Download from "https://github.com/actions/python-versions/releases/download/3.13.0-beta.2-9442465578/python-3.13.0-beta.2-linux-22.04-x64.tar.gz"
  Extract downloaded archive
  /usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C /home/runner/work/_temp/ce7441c9-c7c3-405b-8d85-f47fd5f8a722 -f /home/runner/work/_temp/8c32cd5a-e1e8-4874-ac7a-a0c200b8ba14
  
  gzip: stdin: not in gzip format
  /usr/bin/tar: Child returned status 1
  /usr/bin/tar: Error is not recoverable: exiting now
  Error: The process '/usr/bin/tar' failed with exit code 2

https://github.com/pypa/pip/actions/runs/9443536250/job/26007467646

Both 3.12.4 and 3.13.0-beta.2 were released on https://github.com/actions/python-versions a couple of hours ago:

• https://github.com/actions/python-versions/releases/tag/3.12.4-9442300799
• https://github.com/actions/python-versions/releases/tag/3.13.0-beta.2-9442465578

from setup-python.

Seems like the header is incorrect?

λ Downloads » xxd python-3.12.4-linux-22.04-x64.tar.gz | less | head -1
00000000: 1fef bfbd 0800 0000 0000 0003 efbf bd3c  ...............<

1fef isn't a valid magic number for gzip (file is unaware of anything using it) so I'm not sure if this is a weird case of bitflip? Rest of the header seems fine.

from setup-python.

the same with macos and win archives :

  Version 3.12 was not found in the local cache
  Version 3.12 is available for downloading
  Download from "https://github.com/actions/python-versions/releases/download/3.12.4-9442300799/python-3.12.4-darwin-x64.tar.gz"
  Extract downloaded archive
  /usr/bin/tar xz -C /Users/runner/work/_temp/f2bc8ae4-bdba-46b8-823a-bd909c45dd1b -f /Users/runner/work/_temp/623e67b2-44e6-4a3d-8516-abe6e9d12231
  tar: Error opening archive: Unrecognized archive format
  Error: The process '/usr/bin/tar' failed with exit code 1

from setup-python.

Seems like the header is incorrect?

The file is completely garbled. It mostly consists of ef bf bd patterns.

from setup-python.

Thanks @aparnajyothi-y, I can confirm the latest release / manifest fixes the issue in #863 (some GH-hosted workers) and #884 (all GH-hosted workers).

from setup-python.

I have noticed this is working in ubuntu-latest runner, but not on my self-hosted runner, both using the same container: ubuntu:24.04 for testing purposes.

from setup-python.

The file is completely garbled. It mostly consists of ef bf bd patterns.

Ah, nice spotting.

However it's weird that the deflate header is kept as-is while the 1f bytes are correct.

from setup-python.

Please let us know what is the fix ?

from setup-python.

This might be related to the actions/upload-artifact new version (v4). We've had problems in the past with incompatibilities, wrong compression mechanisms etc. They upgraded the version not that long ago: actions/python-versions@c990e6d

This commit is dated on May 22nd whereas the last previous release is from May 9th

from setup-python.

Download artifact will corrupt files if there are any matching file names when merging multiple, this looks suspiciously like that. actions/download-artifact#298

from setup-python.

All looks good for us at flake8-pyi and typeshed now -- thanks @aparnajyothi-y!

from setup-python.

CI now passes at pywin32 for Python 3.13-dev as well! mhammond/pywin32#2260

from setup-python.

Some good confirmations above. Can confirm it works on our end too. Closing the issue for that reason.

Thanks for the fix! ❤️

../Frenck

from setup-python.