Fix platform-compatibility-tags.rst macOS arch table typo.#2062
Conversation
Someone is wrong, and I expect, packaging is de-facto right since its code well used in the wild: https://github.com/pypa/packaging/blob/a9f77f8269d6897a3dbf28f2c0129a354478d5de/src/packaging/tags.py#L543-L548 If packaging is actually wrong here, I can go over there and submit a PR.
|
The linkcheck failure is for https://flatpak.org/ (unrelated to this PR) and I find: :; curl -vf https://flatpak.org/
* Host flatpak.org:443 was resolved.
* IPv6: 2a04:4e42:82::347
* IPv4: 146.75.73.91
* Trying [2a04:4e42:82::347]:443...
* Trying 146.75.73.91:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / X25519MLKEM768 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
* subject: CN=n.sni-347-default.ssl.fastly.net
* start date: Sep 17 05:11:14 2025 GMT
* expire date: Oct 19 05:11:13 2026 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Atlas R3 DV TLS CA 2025 Q3
* Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* subjectAltName does not match hostname flatpak.org
* SSL: no alternative certificate subject name matches target hostname 'flatpak.org'
* closing connection #0
curl: (60) SSL: no alternative certificate subject name matches target hostname 'flatpak.org'
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.Apparently #2035 doesn't work / cover all PR scenarios? |
There was a problem hiding this comment.
fat3 is correct. See https://github.com/python/cpython/blob/main/Lib/_osx_support.py#L556. This dates back to macOS 10.6 days when the operating system supported those three architectures in the system binaries. Also fat32 would be inappropriate since x86_64 is a 64-bit architecture.
|
Thanks @ned-deily; so packaging has this wrong then! Since the OS is so old, and unlike Linux and Windows Mac makes owning / operating these old OSes nigh impossible; I suspect its a bug no one has ever hit. I'll close this and send those folks a PR instead. |
|
Yeah, it's very old. We'll probably remove support for those ancient universal build combinations from CPython sometime soon. |
This was introduced in pypa#156 and appears to originate in CPython via distutils via python/cpython@bea37aee6b2d. Afaict this was likely a Windows-user Freudian file-system slip but never was an issue since the PR was in 2019 which was well past the ~2009 3-way fat binary era. C.F.: + Assume packaging was right and this was a spec bug 1st: pypa/packaging.python.org#2062 (review) + Original CPython Issue introducing fat3: https://bugs.python.org/issue6245
|
Fix up in pypa/packaging#1199 |
Someone is wrong, and I expect packaging is de-facto right since its code well used in the wild: https://github.com/pypa/packaging/blob/a9f77f8269d6897a3dbf28f2c0129a354478d5de/src/packaging/tags.py#L543-L548
If packaging is actually wrong here, I can go over there and submit a PR.