Mailman 3 February 2014 - Twisted

[Twisted-Python] [ANNOUNCE] Salut à Toi 0.4.0: powerful XMPP client based on Twisted/Wokkel
by Goffi 28 Feb '14

28 Feb '14

G'day, We are proud to announce the 0.4.0 release of "Salut à Toi", a powerful XMPP client with "social" features such has microblogging, group permissions (called elsewhere "aspects" or "circles"), file sharing, multi-user chat, etc. The project is based on Twisted and Wokkel, and is multi-frontends (web, desktop, console interface, CLI), a demo of the web interface is available online at http://www.libervia.org . 0.4.0 announcement: http://www.goffi.org/post/2014/02/26/Salut-%C3%A0-Toi-0.4.0 website: http://www.salut-a-toi.org In addition, a pubsub componant, based on Ralph Meier's Idavoll (http://idavoll.ik.nu/ but the site seems down), SàT PubSub, has also been published. It's build to experiments features, like fine access tuning (http://www.goffi.org/post/2012/06/24/Fine-access-tuning-for-PubSub), and to be complete enough to allow microblogging. You'll find it on the mercurial repository (http://repos.goffi.org) or on ftp://ftp.goffi.org/sat_pubsub/sat_pubsub.tar.bz2 . Big thanks to Twisted team and contributors, and special thanks to Ralph Meier for Wokkel, Idavoll, and the work on XMPP/PubSub :) If anybody feel like contributing, you're welcome :). You'll find us on XMPP muc room sat(a)chat.jabberfr.org, or you can subscribe to dev list on http//lists.goffi.org . Goffi

1 0

[Twisted-Python] Enabling travis-ci tests for reviews via pull requests
by Adi Roiban 28 Feb '14

28 Feb '14

Hi, The possibility of using travis-ci for running tests against patches from non-commiters was raised during a review so I would like to summarize my findings. Travis-CI can run tests on multiple python version and the results are public. It will accept any patch submitted via a pull request and will execute the tests on it. It only provides Ubuntu 12.04 x64 builders... and with some hacks maybe also OSX (as used by pyca / cryptography) I know that Twisted developers don't want to deal with GitHub's pull requests. One option is to accept the .travis.yml in trunk, and then each developer can enable travis-ci build on his/her own fork. If he/she needs to check a patch, he/she could create a pull request for his/her own fork of trunk and if Travis-ci is enabled for that fork, a build is triggers and an email with results is sent. What do you think? Would you accept such path? Are there other (better) ways of allowing developers to run tests before sending a patch? I think that it is nice to allow developers to run a reference set of tests before requesting a review. Thanks! -- Adi Roiban

1 0

[Twisted-Python] inotify tests failing on travis-ci
by Adi Roiban 28 Feb '14

28 Feb '14

I have 4 inotify tests which are failing on travis-ci builders: They pass on my local system which is also Ubuntu 12.04 with virtualenv. Do you know what could be the cause of these failures? Any hint of what can be done to fix them? Thanks! ----- Full log is here: https://travis-ci.org/chevah/twisted/jobs/19803983 Here are the failing tests. [ERROR] Traceback (most recent call last): Failure: twisted.internet.defer.TimeoutError: <twisted.internet.test.test_inotify.TestINotify testMethod=test_deleteSelf> (test_deleteSelf) still running at 120.0 secs twisted.internet.test.test_inotify.TestINotify.test_deleteSelf =============================================================================== [ERROR] Traceback (most recent call last): Failure: twisted.internet.defer.TimeoutError: <twisted.internet.test.test_inotify.TestINotify testMethod=test_ignoreFilePath> (test_ignoreFilePath) still running at 120.0 secs twisted.internet.test.test_inotify.TestINotify.test_ignoreFilePath =============================================================================== [ERROR] Traceback (most recent call last): Failure: twisted.internet.defer.TimeoutError: <twisted.internet.test.test_inotify.TestINotify testMethod=test_seriesOfWatchAndIgnore> (test_seriesOfWatchAndIgnore) still running at 120.0 secs twisted.internet.test.test_inotify.TestINotify.test_seriesOfWatchAndIgnore =============================================================================== [ERROR] Traceback (most recent call last): Failure: twisted.internet.defer.TimeoutError: <twisted.internet.test.test_inotify.TestINotify testMethod=test_simpleDeleteDirectory> (test_simpleDeleteDirectory) still running at 120.0 secs twisted.internet.test.test_inotify.TestINotify.test_simpleDeleteDirectory ------------------------------------------------------------------------------- Ran 9634 tests in 578.574s FAILED (skips=1316, expectedFailures=12, errors=4, successes=8302) -- Adi Roiban

1 0

[Twisted-Python] listenTCP & listenSSL failing silently?
by Matthew Pounsett 27 Feb '14

27 Feb '14

I’ve bumped into a weird one, and can’t figure out what I’m missing. for iface in interfaces: for port in ports: logger.debug("Listening on {}:{}".format(iface, port)) if use_ssl: reactor.listenSSL(port, factory, ssl.DefaultOpenSSLContextFactory(ssl_key, ssl_cert), interface=iface) else: reactor.listenTCP(port, factory, interface=iface) In the above code block, listenSSL() and listenTCP() both fail silently. They do not raise an exception, and netstat reports nothing listening on the appropriate port. Even weirder, if I assign the results of listenSSL() and listenTCP(), then then a v6 connection will succeed but v4 still fails (silently). I get the same behaviour for both (so, regardless of the value of use_ssl in this code). for iface in interfaces: for port in ports: logger.debug("Listening on {}:{}".format(iface, port)) if use_ssl: connector = reactor.listenSSL(port, factory, ssl.DefaultOpenSSLContextFactory(ssl_key, ssl_cert), interface=iface) else: connector = reactor.listenTCP(port, factory, interface=iface) logger.debug( "Connected with connector: {}".format(connector)) logger.debug( "Connector on host {}".format(connector.getHost())) 19:33:43 http Listening on 127.0.0.1:1812 19:33:43 http Connected with connector: <<class 'twisted.internet.tcp.Port'> of twisted.protocols.tls.TLSMemoryBIOFactory on 1812> 19:33:43 http Connector on host IPv4Address(TCP, '127.0.0.1', 1812) 19:33:43 http Listening on ::1:1812 19:33:43 http Connected with connector: <<class 'twisted.internet.tcp.Port'> of twisted.protocols.tls.TLSMemoryBIOFactory on 1812> 19:33:43 http Connector on host IPv6Address(TCP, '::1', 1812) 19:33:43 http Listening on 10.0.2.4:1812 19:33:43 http Connected with connector: <<class 'twisted.internet.tcp.Port'> of twisted.protocols.tls.TLSMemoryBIOFactory on 1812> 19:33:43 http Connector on host IPv4Address(TCP, '10.0.2.4', 1812) > netstat -an | egrep '\.1812.*LISTEN' tcp6 0 0 ::1.1812 *.* LISTEN I’ve used this exact recipe before without any trouble (the first block, with unassigned results from reactor.listen*).. I can’t figure out what I’m missing this time. Does anything stand out to anyone? Using py27-twisted-13.2.0 port on FreeBSD 9.2.

2 2

[Twisted-Python] Issues stemming from CVE-2014-1912?
by Dustin J. Mitchell 27 Feb '14

27 Feb '14

https://www.trustedsec.com/february-2014/python-remote-code-execution-socke… identified a remote code execution vulnerability in Python's `Socket.recvfrom_into method`. Some brief grepping around the Twisted source doesn't find this method, but I'd be interested to hear what the maintainers have to say on the matter: is a twisted app which doesn't, itself use this method safe? Dustin

3 2

[Twisted-Python] maybe video
by kevin mcintyre 26 Feb '14

26 Feb '14

Wanted to share my qt4reactor webkit cv2 video capture script. It's comes in handy whenever I've needed to scrape just the browser and not my whole screen or capture unit tests etc. here is a demo quick demo in action: http://www.youtube.com/watch?v=2XMXtUISY1g&feature=youtu.be It's a hack, but that's why I like python (espeically twisted)...it's so versatile. https://github.com/kmcintyre/scewpt/blob/master/pyscewpt/maybevideo.py Cheers, Kevin

2 1

[Twisted-Python] Raising TypeError in rich comparison methods
by Richard Wall 24 Feb '14

24 Feb '14

Hello everyone, I want to discuss if and when to raise TypeError from Python rich comparison methods. I'm working on a SerialNumber class which represents an RFC1982 serial number value. See https://twistedmatrix.com/trac/ticket/6672 SerialNumber has rich comparison methods to allow it to be compared with other SerialNumber instances. But what should be the behaviour when a SerialNumber is compared to an instance of some foreign type? In https://twistedmatrix.com/trac/ticket/6672?replyto=6#comment:4 JP suggested returning NotImplemented. > The rich comparison methods should probably type check their argument and > return NotImplemented if it is not a SNA. This way the TypeError-generating > logic provided by the runtime will be invoked instead of an > implementation-dependent AttributeError. I agree there should be type checking here, but after doing some research, I think I prefer to raise an explicit TypeError. Here's why. In Python2, returning NotImplemented from __lt__ always seems to return True and False from __gt__. Python3 reacts more sensibly and raises TypeError. I worry that this may cause Python2 users to think that an L{int} and a L{SerialNumber} can be reliably compared. They can't. I think the "return True / False" behaviour is due to a fallback comparison mechanism in Python. * http://stackoverflow.com/questions/18516827/why-does-0-evaluate-to-true-in-… Python 2 is more stubborn and when NotImplemented is returned or no hooks have been implemented, the C code ends up in the default_3way_compare() C function, So I've decided to explicitly raise TypeError instead. This makes it clear that you can only compare L{SerialNumber} with L{SerialNumber}; in both Python2 and Python3. It also means I only have to test for the "raise TypeError" behaviour. Does that make sense? Thanks in advance for your feedback. -RichardW.

1 0

[Twisted-Python] Making twisted web client requests on running reactor
by Ameya Lokare 24 Feb '14

24 Feb '14

Hi everyone, I'm writing a client library that makes (potentially long running) HTTP requests. Since the library will be used within non-Twisted code, I was thinking of running the reactor in a separate thread. The library code looks roughly like this: def start(): Thread(target=reactor.run, args=(False,)).start() def shutdown(): reactor.callFromThread(lambda x: reactor.stop(), None) def make_request(url): agent = Agent(reactor) d = agent.request( 'GET', url, Headers({ 'User-Agent': ['Twisted SSE Client'], 'Cache-Control': ['no-cache'], }), None) d.addCallback(self.cbRequest) Then I make requests from the application like so: start() make_request("http://localhost:12000") .... make_request("http://localhost:12000") ... shutdown() However, it looks like the 'd' deferred never gets fired. From a little playing around, it looks like this is because the reactor is started before the call(s) to agent.request are made. All examples in the twisted docs create the request before running the reactor. I'm sure I'm missing something very obvious here. Also, is there a better way to design such a library? -- -Ameya

3 3

[Twisted-Python] [ANN] pyOpenSSL 0.14
by exarkun＠twistedmatrix.com 23 Feb '14

23 Feb '14

Greetings fellow Pythoneers, I'm happy to announce that pyOpenSSL 0.14 is now available. pyOpenSSL is a set of Python bindings for OpenSSL. It includes some low-level cryptography APIs but is primarily focused on providing an API for using the TLS protocol from Python. Check out the PyPI page (<https://pypi.python.org/pypi/pyOpenSSL>) for downloads. This release of pyOpenSSL adds: * Support for TLSv1.1 and TLSv1.2 * First-class support for PyPy * New flags, such as MODE_RELEASE_BUFFERS and OP_NO_COMPRESSION * Some APIs to access to the SSL session cache * A variety of bug fixes for error handling cases Additionally, there are three major changes to the project: First, the documentation has been converted from LaTeX (CPython's previous documentation system) to Sphinx (CPython's "new" documentation system ;). You can find the new documentation on the PyPI documentation site (<https://pythonhosted.org/pyOpenSSL/>) or <https://pyopenssl.readthedocs.org/>). Second, pyOpenSSL is no longer implemented in C as a collection of extension modules using the Python/C API. Instead, pyOpenSSL is now a pure-Python project with a dependency on a new project, cryptography (<https://github.com/pyca/cryptography>), which provides (among other things) a cffi-based interface to OpenSSL. This change means that pyOpenSSL development is now more accessible to Python programmers with little or no experience with C. This is also how pyOpenSSL is now able to support PyPy. Finally, the project's code hosting has moved from Launchpad to Github. Many branches remain only on Launchpad along with their associated bug reports. Over the coming releases I hope that the fixes and features in these branches will be ported to Python and incorporated into the pyOpenSSL master development branch. Bug tracking has been disabled on Launchpad so that the amount of useful information hosted there can gradually dwindle to nothing. Please use Github (<https://github.com/pyca/pyopenssl>) for further development and bug reporting. Thanks and enjoy, Jean-Paul

1 0

[Twisted-Python] Weekly Bug Summary
by trac＠twistedmatrix.com 23 Feb '14

23 Feb '14

1 0