Remove arm64v8 #69
Remove arm64v8 #69
Conversation
On many builds, we get: > `pypy3: error while loading shared libraries: libffi.so.6: cannot open shared object file: No such file or directory` Which we can't resolve on Bullseye+ (same as s390x). On others, we get: > `pypy: error while loading shared libraries: libtinfow.so.6: cannot open shared object file: No such file or directory` Which appears to be a CentOS-specific library name and I couldn't convince `pypy` to be satisfied by any symlinks to either `libtinfo` or `libtic` (which were the suggestions I found on other projects for fixing similar linking issues).
Changes: - docker-library/pypy@668b905: Merge pull request docker-library/pypy#69 from infosiftr/arm64v8 - docker-library/pypy@a4fbdd3: Remove arm64v8
Changes: - docker-library/pypy@c4bd7bb: Merge pull request docker-library/pypy#70 from infosiftr/sqlite3 - docker-library/pypy@fc08343: Refactor templating for better consistency - docker-library/pypy@c3b9e88: Rebuild sqlite3 against the system-provided version - docker-library/pypy@668b905: Merge pull request docker-library/pypy#69 from infosiftr/arm64v8 - docker-library/pypy@a4fbdd3: Remove arm64v8
|
If you are using the tarballs from https://downloads.python.org/pypy/, there was a problem with the v7.3.8 release for aarch64. As you can see at that page, the correct download is https://downloads.python.org/pypy/pypy3.7-v7.3.8-aarch64-portable.tar.bz2, which properly packages the libraries needed. The tarball without I would suggest you utilize the json file of downloads from https://downloads.python.org/pypy/versions.json to determine which files are the "latest" for each python version. |
|
Oh nice, thanks @mattip! It's probably a stretch, but any chance of getting the checksums in that JSON too? 😇 |
|
I'm also a bit confused about $ wget -qO- 'https://downloads.python.org/pypy/versions.json' | jq 'map(select(.stable and .latest_pypy)) | map(del(.files))'
[
{
"pypy_version": "7.3.8",
"python_version": "3.9.10",
"stable": true,
"latest_pypy": true,
"date": "2022-02-19"
},
{
"pypy_version": "7.3.8",
"python_version": "3.8.12",
"stable": true,
"latest_pypy": true,
"date": "2022-02-19"
},
{
"pypy_version": "7.3.8",
"python_version": "3.7.12",
"stable": true,
"latest_pypy": true,
"date": "2022-02-19"
},
{
"pypy_version": "7.3.8",
"python_version": "2.7.18",
"stable": true,
"latest_pypy": true,
"date": "2022-02-19"
},
{
"pypy_version": "7.3.5",
"python_version": "3.7.10",
"stable": true,
"latest_pypy": true,
"date": "2021-05-23"
},
{
"pypy_version": "7.3.3",
"python_version": "3.6.12",
"stable": true,
"latest_pypy": true,
"date": "2020-11-21"
},
{
"pypy_version": "7.3.3",
"python_version": "3.7.9",
"stable": true,
"latest_pypy": true,
"date": "2020-11-21"
},
{
"pypy_version": "7.3.2",
"python_version": "3.6.9",
"stable": true,
"latest_pypy": true,
"date": "2020-09-25"
},
{
"pypy_version": "7.3.2",
"python_version": "2.7.13",
"stable": true,
"latest_pypy": true,
"date": "2020-09-25"
}
](I would've expected a set of 4 here, not 9 😇 🙈) |
|
Ah, found it in https://github.com/mozillazg/pypy/blob/daab65eb5779f127e616053b995223767ee0d603/pypy/doc/how-to-release.rst#other-steps:
|
I was taught not to put the checksums in the same place with the files, so they are at https://www.pypy.org/checksums.html. |
|
BTW, the versions.json was set up to be used by the setup-python github action so there may be some documentation and code you can use there (by searching for pypy or versions.json). I can add more fields if you can define what would make your life easier. |
|
Thanks! I'll work on a fix to consume that file appropriately. I appreciate the pointer and the help. 😁 The only other thing I can think of is "beta" vs "non-beta" of a particular Python version within a given release -- right now I'm relying on the blog posts, where the latest clearly states that 3.9 is still considered "beta" but 3.8 is now stable. 😄 |
|
I hope using the file makes your life easier, and will help automate updates. |
On many builds, we get:
Which we can't resolve on Bullseye+ (same as s390x).
On others, we get:
Which appears to be a CentOS-specific library name and I couldn't convince
pypyto be satisfied by any symlinks to eitherlibtinfoorlibtic(which were the suggestions I found on other projects for fixing similar linking issues).See also #58 (for where we removed
s390xbullseye builds).Diff: