[Python-3000] the release gods are angry at python

[Neal Norwitz]

On Thu, Mar 27, 2008 at 11:31 AM, Bill Janssen <janssen at parc.com> wrote:
> > There
>  > have been other tests that have also been flaky like  test_asynchat,
>  > test_smtplib, test_ssl, test_urllib2net, test_urllibnet,
>  > test_xmlrpc_net and some of the tests that use  networking.
>
>  Some of the *other* tests that use networking, I think you mean.

Yes, primarily networking tests.  Also things like signals and threading.

>  Sounds like networking tests in general are flaky.

Anything that connects to a remote host is definitely flaky.  Most of
the tests that connect to localhost are flaky for one reason or
another.  One reason used to be port allocation.  That is mostly fixed
now.

The big reason that most tests fail now is EAGAIN or some other error,
typically on non-blocking sockets.  Switching to blocking sockets
isn't really a great option since the tests are much more likely to
hang.

>  >     - http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0
>
>  Unfortunately, this log has no information about why the test is
>  failing, and I do not have a Debian-unstable machine to try it on
>  (much less a six-processor IBM S/390 mainframe running Debian-unstable
>  -- cool!).  I'm unsure about how to make progress here.  It's
>  interesting to see that most of the stable buildbots running Debian
>  are doing so on big-endian (PPC, Sparc) hardware.
>
>  I also can't tell which branch of Python is being tested, from this
>  logfile.  That would be nice to add.  Is this 2.6 (known problems with
>  SSL) or 3.0 (no known problems with SSL)?  Is this information in the
>  logfile somewhere and I'm not seeing it?

The information happens to be encoded in the URL.  The URL above is for trunk.
You can see more info here:  http://www.python.org/dev/buildbot/all/
That is the landing page for all the info you could want.  Well,
mostly.  The logs often don't really have enough info to debug the
problem.  In that case, it would be better to add more debugging to
the tests.

n