Bug report

Bug description:

test_build_details.test_platform compares the platform key of build-details.json with sysconfig.get_platform(). On Linux the machine part of both comes from os.uname(), once on the build machine and once on the machine running the tests, and for 32-bit builds the two often differ.

Ubuntu builds its armhf packages on armv7l and runs the autopkgtests on arm64 machines, where 32-bit processes see armv8l. Both 3.14 and 3.15 fail there (3.15 log, 3.14 log):

FAIL: test_platform (test.test_build_details.CPythonBuildDetailsTests.test_platform)
AssertionError: 'linux-armv7l' != 'linux-armv8l'

I see the same with:

• Debian's i386 python3.14/3.15 on an x86_64 kernel: 'linux-i686' != 'linux-x86_64'
• Debian's armhf packages in a container on arm64 without linux32: 'linux-armv8l' != 'linux-aarch64'
• a 32-bit ARM cross build of main run under qemu: 'linux-arm' != 'linux-armv7l' (the cross build takes arm from the host triplet)

The value in build-details.json describes the build, so I don't think the file is wrong. The test just can't expect the kernel it runs on to report the same machine for a 32-bit build.

CPython versions tested on:

3.14, 3.15, CPython main branch

Operating systems tested on:

Linux