webmaster has already heard from 4 people who cannot install it.
I sent them to the bug tracker or to python-list but they seem
not to have gone either place. Is there some guide I should be
sending them to, 'how to debug installation problems'?
Over in Ubuntu, we've gotten reports about some performance regressions in
Python 2.7 when moving from Trusty (14.04 LTS) to Xenial (16.04 LTS).
Trusty's version is based on 2.7.6 while Xenial's version is based on 2.7.12
with bits of .13 cherry picked.
We've not been able to identify any change in Python itself (or the
Debian/Ubuntu deltas) which could account for this, so the investigation has
led to various gcc compiler options and version differences. In particular
disabling LTO (link-time optimization) seems to have a positive impact, but
doesn't completely regain the loss.
Louis (Cc'd here) has done a ton of work to measure and analyze the problem,
but we've more or less hit a roadblock, so we're taking the issue public to
see if anybody on this mailing list has further ideas. A detailed analysis is
available in this Google doc:
The document should be public for comments and editing.
If you have any thoughts, or other lines of investigation you think are
worthwhile pursuing, please add your comments to the document.
Last weeks, I worked on a new tool to bisect failing tests because
it's painful to bisect manually reference leaks (I remove as much code
as possible until the code is small enough to be reviewable manually).
See the bisect_test.py script attached to this issue:
With the help of Louie Lu, I added new --list-cases option to "python
-m test", so you can now list all test cases and write it into a text
./python -m test --list-cases test_os > tests
I also added a new --matchfile option, to filter tests using a text
file which contains one pattern per line:
./python -m test --matchfile=tests test_os
fnmatch is used to match test names, so "*" joker character can be
used in test names.
My bisection tool takes a text file with the --matchfile format (one
pattern per line) and creates a random subset of tests with half of
the tests. If tests still fail, use the subset. Otherwise, create a
new random subset. Loop until the subset contains a single test
(configurable threshold, -n command line option).
The long term plan is to integrate the bisection feature directly into regrtest.
Right now, my script is hardcoded to bisect reference leak bugs, but
it should be easy to modify it to bisect other test issues like test
creating files without removing it ("ENV_CHANGED" failure in
For example, a core file is dumped when running test_subprocess on
But I'm unable to reproduce the issue on my FreeBSD. It would be nice
to be able to automate the bisection on the buildbot directly.
--list-cases and --matchfile options are now available in 2.7, 3.5,
3.6 and master (3.7) branches.
TODO: doctest tests are only partially supported, see:
Our buildbots are now even more stable than in my previous buildbot report.
Many random failures have been fixed, even if there are still many
rare random failures (most of them are related to multiprocessing).
Search for issues created by "haypo" (me!) with the Component "Tests"
to see all remaining issues. I'm trying to open an issue for *each*
buildbot failure! So yeah, we have a long list of 44 open issues!
Correct me if I'm wrong, but, for the first time, *all reference
leaks* have been fixed on *all branches* (2.7, 3.5, 3.6 and master),
on *Linux and Windows*! Before, we mostly focused on the master branch
(called "default" in Mercurial) on Linux.
I also started to fix a few "memory block" leaks, most (or all?) of
them should also be fixed (on all branches, on Linux and Windows).
A new policy has been decided (on python-committers): if a commit
breaks too many buildbots and cannot fixed easily nor quickly, the
commit will be reverted, just to keep our buildbots "green". It
doesn't mean that the commit will be rejected forever. It's a
practical solution to give more time to write a proper fix, take time
to review it, and not have to be stressed to fix buildbots "ASAP".
Moreover, keeping green buildbots all the time allows to catch
regressions more quickly, which ease debug in many ways.
You have be warned! Now I will not hesitate to revert your change if
you break my little buildbots ;-)
I mostly care of Linux, Windows, macOS and FreeBSD (10 and CURRENT).
Breaking other platforms is less important, since other platforms
already have issues, but not enough developers interested to fix them.
Obviously, I'm interested in keeping more buildbots green, if someone
shows up and help me to fix remaining issues!
2017-06-29 23:34 GMT+02:00 Rob Boehne <robb(a)datalogics.com>:
> I¹m new to the list, and contributing to Python specifically, and I¹m
> interested in getting master and 3.6 branches building and working
> ³better² on UNIX.
> I¹ve been looking at a problem building 3.6 on HP-UX and see a PR was
> merged into master, https://github.com/python/cpython/pull/1351 and I¹d
> like to see it applied to 3.6. I¹m happy to create a PR with a
> cherry-picked commit, and/or test.
Sure, this change can be backported to 3.6, maybe also to 3.5. But
hum, I may suggest to first focus on the master branch and fix most
HP-UX issues, before spending time on backport. I would prefer to see
most tests of the important modules pass on HP-UX (ex: test_os).
For a backport, you can directly comment http://bugs.python.org/issue30183