hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
What is the procedure for accepting patches for platforms for which we
don't have a continuous testing system ?
This is a follow up of the review from
There is a patch for Cygwin but AFAIK there is no current builder for
running Twisted with Python on Cygwin.
My first reaction was that before accepting such patches we should set
up a continuous testing system.
With such a system in place we can run the tests to see that the
reported bug is present in trunk and that it is fixed in a branch.
If that can't be done, we need at least someone to manually run the
tests to check the patch.
Twisted is supported on so many systems and I don't think that is OK
to ask reviewers to have each supported system at hand, ready to fire
a manual test.
I hit a strange behavior in which the clone connection error from one
test is raised as the error for another test.
The tests are not written using trial, but I have thousands of other
tests and I have never seen this behaviour.
I tried to put a self-contained example at
you will need to run it in a virtulenv as it will pull quite a few of
I have traced the error to this code
err.value = smtp.SMTPConnectError(
-1, "Unable to connect to server.")
It looks to me like the initial failure (err) is hijacked here and its
errors will never be cleared.
If I am doing something like
value = smtp.SMTPConnectError(
-1, "Unable to connect to server.")
value = err.value
then the test will pass.
But I still don't understand how the error from one client request is
passed to another client request when they are using different
Do you see anything suspicious with this code?
I have been submitting patches to txkube (Python-based Kubernetes client)
to work with the latest API changes for the reactor and TLS endpoints.
I am down to only 1 test failing. I submitted this patch:
based on changes that I saw in
but haven't gotten it to work.
What I am trying to do is to get txkube to the point where I can install it
with Python 2.7, and
and get it to work.
test_https_bearer_token_authorization is pretty much the same as
test_http_bearer_token_authorization, just going over https.
When running the test_https_bearer_token_authorization test, I traced
things down into the ConnectionCompleter class:
It looks like the serverFactory is not properly creating a serverProtocol,
so no data is going through.
Can someone familiar with the TLS endpoint changes in Twisted 17.1.0 point
me in the right direction for this?
I'm using twisted to host an ssh server.. My requirement that the python
code I did needs to start the reactor and come out of the execution and
needs to stop the reactor once stop is called.. But since the reactor.
Run() seems to be a blocking one.. It isn't moving forward after starting
the reactor.. Any work around on this would be appreciated..
Nandha Kumar S
Users of Twisted and OpenSSL 1.1 and 1.0.2 cannot connect to all HTTPS
sites because Twisted sets its own ECDH curve instead of using the
defaults selected by these versions of OpenSSL.
The gory details are here:
The solution to this bug favored by an OpenSSL maintainer is to drop
support for OpenSSL versions before 1.0.2. I'm also in favor of this
- 1.0.2 is the oldest supported version of OpenSSL
- The ECDH curve selection code would be much simpler if we only
supported OpenSSL 1.0.2
- cryptography wheels installed from PyPI include OpenSSL 1.1
Do you use the latest version of Twisted with OpenSSL 1.0.1? If so, do
the above reasons satisfy your concerns?