Compiling python 3.13

Hu · Administrator Joined: 06 Mar 2007 Posts: 22602

Which tests fail? Are they the same ones that fail with USE=pgo? If I recall correctly, the USE=pgo failures were because Python was trying to write and then execute in /tmp (presumably, ignoring $TMPDIR being set to some other directory), and when /tmp is noexec, that failed. I wonder if your container environment has set noexec on some other directories that are normally not mounted noexec.

Can you pastebin the full build.log of a failed build?

grknight · Retired Dev Joined: 20 Feb 2015 Posts: 1902

It is not recommended to enable test in FEATURES unless you are managing the package. For simple daily use, including test in FEATURES will cause many packages to fail.

Hu · Administrator Joined: 06 Mar 2007 Posts: 22602

I recently tried to build dev-lang/python:3.13 with USE=pgo and without FEATURES=test. It failed, with errors relating to trying to execute things in /tmp. That build apparently runs at least some tests without being asked to do so. I subsequently discovered dev-lang/python-3.13.0[pgo] build fails with /tmp mounted noexec, which matched my situation. I did not particularly need USE=pgo, so I disabled it and then python:3.13 installed successfully for me.

sdauth · l33t Joined: 19 Sep 2018 Posts: 644 Location: Ásgarðr

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2390

Hu · Administrator Joined: 06 Mar 2007 Posts: 22602

Yes, Profile Guided Optimization needs a profile, and usually that is collected locally, so that it is consistent with the compiler version and flags used. Python may have been trying to use its own test suite to obtain the profile results, but it printed output as if it were running the tests to check their correctness, not just for the side effect of obtaining PGO training data. Although a test suite is better than nothing for training data, I am a bit dubious whether the test suite is good training data, since test suites typically try to cover all the unlikely paths to ensure those paths are executed correctly. Good PGO training data mimics what users will run daily. Most users will not be routinely running the unlikely error handling paths, so I worry that a PGO build trained on test suites will expect the error paths to be far more common than they are in daily use.

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2390

logrusx · Advocate Joined: 22 Feb 2018 Posts: 2390

I think this is intentional:

sam_ · Developer Joined: 14 Aug 2020 Posts: 1946

Python 3.13 has an upstream change to not ignore test failures when running the testsuite for PGO. It came after they found that most of the tests were failing in their CI when doing PGO runs and nobody had noticed.

We are likely going to revert that change in Gentoo as it's too much hassle for most users who just want PGO to work and many of the people who have it set are understandably not able or willing to try debug issues with tests (if they were, they'd enable the regular testsuite too).

We are using the upstream target/process for PGO which indeed involves running the testsuite.

As for quality of profiling/training data: testsuites are a mixed bag on this. Many packages do not have great coverage in their testsuite or indeed focus too much on degenerate or error cases. At least for CPython, the testsuite I think is pretty extensive and covers real functionality. Whether or not it'd be useful to have it run some real Python applications as well is a good question though.