I'm getting multiple test failures with latest Alpine 3.15 and musl-1.2.2-r7. Some test failures may be caused by wrong assumptions in our tests, some might be bugs in musl lib.c

9 tests failed:
test__locale test_c_locale_coercion test_cmd_line test_gdb
test_locale test_os test_posix test_re test_selectors

I have attached the output of

./python -m test -v test__locale test_c_locale_coercion test_cmd_line test_gdb test_locale test_os test_posix test_re test_selectors 2>&1 | tee alpine315-tests.txt

You can use my container to reproduce the test failures:

$ podman run --privileged -ti --rm -v $(pwd):/cpython:Z quay.io/tiran/cpythonbuild:alpine-3.15 /bin/sh
# /cmd.sh
# cd /cpython/builddep/alpine-3.15-x86_64/
# make test

These tests seems to be expected to fail on alpine.

See https://github.com/alpinelinux/aports/blob/b36ed9bba2fdbf49a98dfdc3377c29271525082f/main/python3/APKBUILD#L123

I would put it differently: The package maintainer of Python on Alpine decided to ignore all test failures in these test modules.

The first alpine315-tests.txt appears to be a truncated version of the second. Were you expecting the first to be automatically replaced? Should it be unlinked?

https://www.alpinelinux.org "Alpine Linux is a security-oriented, lightweight Linux distribution based on musl libc and busybox." Fron the doc linked above:

# Maintainer: Natanael Copa <ncopa@alpinelinux.org> ## I nosied Natanael at his CLA-signed Alpine id.
# Contributor: Sheila Aman <sheila@vulpine.house>
...
# musl related
fail="test__locale test_locale test_strptime test_re" # various musl locale deficiencies
fail="$fail test_c_locale_coercion"
fail="$fail test_datetime" # hangs if 'tzdata' installed
fail="$fail test_os" # fpathconf, ttyname errno values
fail="$fail test_posix" # sched_[gs]etscheduler not impl
fail="$fail test_shutil" # lchmod, requires real unzip

Should we change CPython tests to accommodate things that are missing (versus buggy). Should the tests requiring sched_[gs]etscheduler be skipped if missing? Or are they required to be 'posix' and is test_posix meant to test completeness as well as correctness of what is present?

In my opinion we should treat these issues as Alpine / musl libc platform bugs and ask the Alpine maintainers to look into the issue. The tests are passing on Linux with glibc and BSD platforms (FreeBSD, macOS, ...) with BSD libc. It is reasonable to assume that failing test are caused by incompatibilities or deficiencies in musl libc, or by a different interpretation of POSIX and Open Group standards.

I would not ignore or skip any test unless we have a thorough understanding of the problem and the deviation is documented. The issue can also affect user code.

Python's test suite is exhaustive. Our tests have found a fair amount of problems in e.g, libm. A couple of years ago ine of my AF_ALG socket tests even found a Kernel bug by triggered a Kernel fault.

The comment about sched_[gs]etscheduler seems to be outdated. For one CPython's test suite has a @requires_sched decorator that performs a check for sched_getscheduler and the Kernel syscall. musl libc in Alpine 3.13 and 3.15 have sched_setscheduler.

BTW, we do have an Alpine buildbot worker in the unstable set, running only on the main branch: https://buildbot.python.org/all/#/workers/19

GH-92826 is a compiler or musl libc issue on Alpine that manifests on PPC64LE platforms.

FYI neither Alpine nor musl are covered by PEP 11 (PPC64LE is tier-2, though).