Re: [Twisted-Python] Switch Protocols mid Connection

[Tristan Seligmann]

On Sun, 16 Sep 2018 at 16:02, Randall Smith  wrote:
> and make 16+ calls to transfer a single file.  So I need to switch to a
> more appropriate (not yet determined) protocol for the transfer, and
> then back to AMP.  AMP provides a protocol switch command, which is
> great, but then I'd need to switch back to AMP and I have no idea what
> approach to take here.  It  doesn't help that I don't have a file
> transfer protocol selected.

You might be able to get away with
http://bazaar.launchpad.net/~glyph/%2Bjunk/amphacks/annotate/head%3A/python/amphacks/mediumbox.py

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] How do recommend I run epytext?

[Tristan Seligmann]

On Fri, 3 Aug 2018 at 16:25 Barry Scott  wrote:

> The tox checking does not cover the epytext checks it seems.
>
> How do you recommend I have epytext checked for a patch?
>

Twisted uses pydoctor for generating API documentation; I believe tox -e
apidocs is what you want to run it:

https://github.com/twisted/twisted/blob/ee535041258e7ef0b3223d2e12cd9aaa0bc2289f/tox.ini#L124
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] body producer bug in agent?

[Tristan Seligmann]

On Sun, 12 Nov 2017 at 09:33 Glyph  wrote:

> I attempted to draw some attention to this with github mentions:
>
> https://github.com/twisted/treq/issues/185#issuecomment-331856235
>
>
> but it looks like that didn't work.
>
> Hopefully by posting it here I can motivate someone to look at it?  I
> think it sounds like a pretty bad bug, but I don't have a ton of time to
> look at it myself :-(.  I believe it's in Twisted itself, not Treq, but I
> could be wrong.
>

A cursory glance suggests that 1) the bug is in Twisted, and 2) the impact
of the bug is limited to an annoying log message. Unfortunately I'm
unlikely to be able to chase this further any time soon, but hopefully
somebody else can.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Required tests for a PR to be merged

[Tristan Seligmann]

On Mon, 2 Oct 2017 at 13:36 Adi Roiban  wrote:

> Will it trigger the Buidlbot stable builders?
>
> From what I can see in the code, it only creates the branch.
>

I believe buildbot will trigger a build on the branch being pushed, no need
for a separate PR. Then, because GitHub commit statuses are on the
_commit_, the PR should be green too if the build succeeds.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Nevow 0.14.3rc1 released

[Tristan Seligmann]

On Wed, 26 Jul 2017 at 20:46 Tristan Seligmann 
wrote:

> I've uploaded a prerelease of Nevow 0.14.3 to PyPI[1]. This contains a fix
> for some Athena client-side timeout behaviour (or more specifically, the
> lack of one) and removes use of FilePath.getmtime.
>

I've uploaded the final release of Nevow 0.14.3[1]; the only changes since
the prerelease relate to some issues around versioning and the __version__
attribute.

[1] https://pypi.python.org/pypi/Nevow/0.14.3

>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] trial.unitest-specific segfault with lxml

[Tristan Seligmann]

On Fri, 18 Aug 2017 at 00:47 Phil Mayers  wrote:

> SSCCE - well, hopefully correct - here:
>
> https://gist.github.com/philmayers/387597c7407ab98f159426cea5f44a69
>

Note that I don't think you're allowed to catch GeneratorExit like this;
normally doing so will crash your program with a RuntimeError after the
generator fails to exit (possibly masked here by the generator living until
the end of the program). However, I was able to reproduce the crash even
after removing the try/except, so I don't think this issue is related.

Given that the crash only occurs at exit, I suspect this has something to
do with finalizers running at a bad time during interpreter shutdown, but I
don't have time at the moment to look into this deeply (I just spotted the
GeneratorExit issue and wanted to check if that was the problem).

I suspect this is an lxml or Cython bug, ultimately, but changing the test
base class changes some ordering of events arbitrarily resulting in this
heisencrash. Alternatively, it might have something to do with logging.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Is there a nice way to write transport-agnostic protocols and servers/clients?

[Tristan Seligmann]

On Wed, 16 Aug 2017 at 15:28 Kevin Conway 
wrote:

> Maybe I misunderstand the issue, but I believe the Endpoints API solves
> for this.
> https://twistedmatrix.com/documents/16.4.1/core/howto/endpoints.html
>
> This abstracts the transport and allows you to focus on only interpreting
> the bytes transmitted over that transport by defining a Protocol and a
> Factory that plug into strports. This should allow you to have the business
> logic defined in only one location while listening/requesting over
> different transports.
>
There is no datagram endpoints API as yet, though (see #4471), only stream
endpoints.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Is there a nice way to write transport-agnostic protocols and servers/clients?

[Tristan Seligmann]

On Wed, 16 Aug 2017 at 13:53 Jarosław Fedewicz 
wrote:

> One thing that is also notably missing from the puzzle is that there is no
> support for datagram endpoints.
>

The lack of datagram endpoint abstractions is definitely just a "we haven't
gotten around to it yet"; stream endpoints were the initial focus mainly
because stream protocols are a lot more common than datagram protocols. The
ticket covering datagram endpoints is here, I believe:
https://twistedmatrix.com/trac/ticket/4471 There seems to be some old work
that was never completed, so picking this up again might be a good starting
point if you're keen on contributing in this area.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Weird PyPY twisted.internet.defer.TimeoutError ERROR*12 during full test run

[Tristan Seligmann]

On Sat, 5 Aug 2017 at 00:44 Daniel Sutcliffe  wrote:

> For the buildbot:
> https://buildbot.twistedmatrix.com/builders/ubuntu16.04-pypy5/
> they seem to pretty much consistently happen during:
>   twisted.protocols.test.test_tls.TLSMemoryBIOTests.test_hugeWrite_TLSv1_1
> but running in my own environment(s) I also always see the 12
> TimoutError but they can occur in a variety of different tests, I've
> seen them in these as well as the above:
>twisted.news.test.test_news.NewsTests.testArticleRequest
>twisted.names.test.test_server.DNSServerFactoryTests.test_verboseDefault
>
>  
> twisted.positioning.test.test_nmea.BrokenSentenceCallbackTests.test_dontSwallowCallbackException
> and a bunch of others.
>

This kind of timeout usually means that the test is waiting for some event,
and due to an event ordering that wasn't expected, the event never happens;
for example, it might have already happened before you start waiting for
it, or it might not happen at all due to an error.

Sometimes this means that the test is really stuck, but often it means that
an error has occurred but was not handled by the test, so you get an error
(maybe logged, maybe not) but also the test never ends.

Always exactly 12 and always during same test for a single test run.
> I've not been able to reproduce running anything but the full
> testsuite - but they have always occured for me during full run.
>
> Just wondered if anybody with more experience had a clue/idea as to
> why this could happen (why 12), and how I could go about tracking down
> the root cause.
>

Look for missing error handling in the test to see if an error is occurring
that the test does not notice; if you're lucky, these errors may have been
logged (check test.log). If not, you may need to improve the error handling
and / or play around in a debugger.

If the test really is stuck, a common cause of PyPy vs CPython issues is
garbage collection or weakref callbacks happening in an unpredictable
ordering of events. I haven't looked at the tests in question but I would
check for things like __del__ methods (eg. files not being closed
explicitly) or weakref use in the vicinity.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Nevow 0.14.3rc1 released

[Tristan Seligmann]

On Wed, 26 Jul 2017 at 21:36 Werner Thie  wrote:

> Aloha Tristan
>
> still using Athena in production, will be able to test tomorrow.
>

Great!

Note that there's an rc2 now, because there were some problems with the
version number handling in rc1; pip install --pre nevow should get you the
latest prerelease though.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Nevow 0.14.3rc1 released

[Tristan Seligmann]

Hi all,

I've uploaded a prerelease of Nevow 0.14.3 to PyPI[1]. This contains a fix
for some Athena client-side timeout behaviour (or more specifically, the
lack of one) and removes use of FilePath.getmtime.

If you are using Athena, please a) let me know! and b) give this prerelease
a try to see if anything breaks. As the de facto Nevow release manager, and
one of its last users, I'd like to avoid going overboard on release
engineering if it isn't necessary, but I'd also like to avoid making life
worse for any other remaining users, so it would be useful to hear from any
of you out there still using Nevow.

[1] https://pypi.python.org/pypi/Nevow/0.14.3rc1
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] WebSockets and QUIC for Twisted

[Tristan Seligmann]

On Thu, 6 Jul 2017 at 04:58 Glyph  wrote:

> Why are you interested in QUIC? My understanding was that Google used this
> protocol as an experiment, but HTTP/2 is the successful termination of the
> experiment, and nobody should really be using it.  (For http2 support, `pip
> install twisted[tls,http2]`).
>

You're thinking of SPDY. QUIC is a UDP-based protocol that allows 0-rtt
connection setup (and is also implemented by Chrome / Google services).
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Question regarding patch submission

[Tristan Seligmann]

On Mon, 26 Jun 2017 at 05:34 Jason Litzinger 
wrote:

> However, after incorporating review comments in new commits and,
> force-pushing the feature branch, is it expected that the review comments
> may
> be damaged?
>

I think this is expected; this is just an unfortunate shortcoming of GitHub
PR reviews.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] process manager for twisted daemons?

[Tristan Seligmann]

On Thu, 4 May 2017 at 01:21 jonathan vanasco 
wrote:

> Is anyone deploying their twisted services with something other than
> Supervisor?  If so, I'd love to know.
>

It sounds like systemd has what you want here, and should work fine for
your Twisted services, assuming you don't have other constraints that
exclude its use.

systemctl stop  will temporarily stop a service, but it will be
restarted on boot if it was configured to do so. However, you can do systemctl
disable --now  which will remove the configuration to start it on
boot as well as stopping it. To reverse this, you would do systemctl enable
--now  which would reenable it and start it.

This is basically doing the same as you were doing with supervisord, but
since you can combine the operations into a single command, you don't have
to worry about forgetting to do half of the process.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] new core contributor

[Tristan Seligmann]

On Sat, 22 Apr 2017 at 09:48 Glyph Lefkowitz 
wrote:

> As per our previously documented entirely arbitrary[1] and ad-hoc[2]
> process, I'd like to welcome - should he choose to accept it - Tom Most to
> be a member of the Twisted project.  You've probably seen him around on
> IRC, as 'twm'.  Tom's been reporting nuanced web-related bugs in Twisted
> since at least 2011, if not longer:
> https://twistedmatrix.com/trac/ticket/5434
>

Welcome! :)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] non-merge commits to trunk & "review" keyword

[Tristan Seligmann]

On Tue, 7 Mar 2017 at 09:56 Glyph Lefkowitz  wrote:

> On Mar 6, 2017, at 9:02 PM, Tristan Seligmann 
> wrote:
>
> On Tue, 7 Mar 2017 at 06:38 Glyph Lefkowitz 
> wrote:
>
>
> This is definitely bad, forbidden by existing policy, etc.  In fact I
> remember adjusting the settings so that the 'merge' button would always
> create a merge commit; in fact, the configuration is still set that way.
>
>
> Rebase merging was allowed when I checked earlier, so I disabled it (I
> guess I managed to do this before you looked at the configuration).
>
>
> Perhaps I only did this for some other repos, then.  Did I miss your
> announcement of this?  Hint, hint? :)
>

 By the time I got to my email client (which admittedly was several hours
after I made the configuration change), your email had arrived, so my reply
ended up being the "announcement" too. The last time I looked at these
settings, rebasing was not allowed, so I guess somebody else turned it on
(possibly by accident); the GitHub audit logs don't go far back enough for
me to check who did it and when, but that means the change happened over
several months ago.

> I suspect that is what happened here, but note also that these settings
> only control what is possible by pressing the merge button on GitHub; you
> can construct commits locally however you like and push them, as long as
> you get green commit statuses for all the mandatory commit checks.
>
>
> Is this true even for people with just repo:write?
>

I haven't actually tested this scenario, so I could be mistaken; inferring
from other things it shouldn't matter what your permissions are (for a
non-force push).
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] non-merge commits to trunk & "review" keyword

[Tristan Seligmann]

On Tue, 7 Mar 2017 at 06:38 Glyph Lefkowitz  wrote:

>
> This is definitely bad, forbidden by existing policy, etc.  In fact I
> remember adjusting the settings so that the 'merge' button would always
> create a merge commit; in fact, the configuration is still set that way.
>

Rebase merging was allowed when I checked earlier, so I disabled it (I
guess I managed to do this before you looked at the configuration). I
suspect that is what happened here, but note also that these settings only
control what is possible by pressing the merge button on GitHub; you can
construct commits locally however you like and push them, as long as you
get green commit statuses for all the mandatory commit checks.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] twistedmatrix.com TLS certificate

[Tristan Seligmann]

twistedmatrix.com's current certificate is issued by StartCom Certification
Authority; for certificates issued by this CA prior to 2016-09-21, the
domain must be on a Chrome whitelist for it to be accepted. As of Chrome
58.0.3026.3 (canary/dev channel only, currently, but eventually this will
presumably be in a release version) twistedmatrix.com is no longer[1] on
the whitelist, which means that twistedmatrix.com will issue a certificate
error. Can we switch to another CA? (Let's Encrypt, for example; I hear
somebody wrote a Twisted library for using that)

I'm sending this to the general list in case anyone else has been
scratching their head about why they're getting cert warnings.

[1]
https://chromium.googlesource.com/chromium/src/+/6fc397860ccafa55086456a4d1e6d713c418b41f%5E%21/
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] HTTP Agent persistent connections not closed for some HTTPS sites

[Tristan Seligmann]

On Sun, 5 Mar 2017 at 15:36 Adi Roiban  wrote:

> I have observed this while running some end to end tests in which the
> pool.closeCachedConnections() deferred was not called, even after a
> generous amount of seconds :)
>

The code to abort an HTTP client connection is here:

https://github.com/twisted/twisted/blob/twisted-17.1.0/src/twisted/web/_newclient.py#L1657

This calls loseConnection which for a TLS connection will try to do a TLS
shutdown under most circumstances (in some cases it can't, and will
abortConnection on the underlying transport instead). If the remote end has
stopped responding to the connection, I think this may end up hanging
forever.

I think this code should either call abortConnection directly, or set a
timer which will abort the connection after a little while if a clean
shutdown from loseConnection has not completed yet. I'
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Test coverage requirements

[Tristan Seligmann]

On Mon, 27 Feb 2017 at 21:54 Glyph Lefkowitz 
wrote:

> That said, it has been *improving* and if it keeps improving at the rate
> it has been, I expect that we'd be able to put that coverage blocker back
> in in another 3-4 months.  Perhaps something to talk about at PyCon.
>

I think at least one problem that we're suffering from here is our fault,
rather than Codecov's: the coverage of the test suite is not stable due to
non-determinism in the test suite. That is, the lines executed during a
test run are not the same every time due to things like ordering / timing
races / etc. This means that "changes" to coverage may show up for a
particular PReven though nothing in that PR is actually responsible.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 17.1 Release Announcement

[Tristan Seligmann]

On Wed, 15 Feb 2017 at 15:23 Jean-Paul Calderone 
wrote:

>
> I wonder about the details of how treq's failures went unnoticed.  Is
> development sufficiently inactive that no one looked at CI between the
> breakage and the release?  Wasn't that a period of several months?  Or does
> it have a Twisted trunk@HEAD build that none of the contributors really
> pay attention to?
>

The latter is the case; there are Twisted trunk builds, but they're flagged
as "failures allowed" to avoid disrupting development with transient
breakage. Unfortunately this means that basically nobody ever notices when
they fail. For example, here's a failing build:

https://travis-ci.org/twisted/treq/builds/194691849

I haven't found a good solution to this problem yet in my own projects; I'm
hoping someone else has some ideas?
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Hanging SFTP client operations on server disconnection

[Tristan Seligmann]

On Wed, 15 Feb 2017 at 08:56 Glyph Lefkowitz 
wrote:

>
> PS: There is a stray release notes fragment in conch
>
> https://github.com/twisted/twisted/blob/trunk/src/twisted/conch/8791.feature
>
>
> Oops!
>
> Wait; why do you say this is "stray"?
>

It appears to be in the wrong directory (should be in
src/twisted/conch/topfiles/).
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 17.1 Release Announcement

[Tristan Seligmann]

On Sun, 12 Feb 2017 at 03:45 Glyph Lefkowitz 
wrote:

>
> Yeah, this is a lack of test coverage for the 'default' case.  Technically
> it *is* a regression, but it's probably pretty unusual to use the
> default; point being, I don't think we need an emergency release here.
>

The functionality that was removed was previously deprecated, so I don't
think it counts as a regression. However, the fact that most people
wouldn't ever have seen the DeprecationWarning, and…

There's also a huge problem here with documentation, where `-d´ is a TCP
> port but `-p´ is a strport, and it's hard for end-users to get from the
> command line to the relevant documentation that explains what strports are
> available.
>

…the documentation issue does make things more awkward than they needed to
be.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 17.1 Release Announcement

[Tristan Seligmann]

On Sat, 11 Feb 2017 at 12:04 Amber Hawkie Brown 
wrote:

> - Lots of deprecated code removals, to make a sleeker, less confusing
> Twisted.
>

Something perhaps not obvious from the release notes:

String endpoint descriptions, as used by twist/twistd among other things,
for listening on tcp ports now require the "tcp:": that is, "80" is no
longer accepted, you need to use "tcp:80".

This functionality has been deprecated for a while, but as it is unlikely
that many people run twist/twistd with DeprecationWarnings enabled, most
people relying on this behaviour have unfortunately probably never seen the
warning.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] understanding twisted, better error handling

[Tristan Seligmann]

On Wed, 11 Jan 2017 at 02:26 steven meiers  wrote:

> True, but since python 2.x is still shipped with debian testing for
> example there will be some people running into this issue.
> Just to make twisted more approachable this could he handled.
>

The b'GET' syntax for byte strings works on Python 2.7 (you get a str) as
well as Python 3, so I would suggest we use it everywhere in the
documentation / examples to make it easier on programmers using both Python
2 and 3.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] treq POST abborting with: err: ('Could not adapt', '{"....", "..."} )

[Tristan Seligmann]

On Sun, 8 Jan 2017 at 01:57 Glyph Lefkowitz  wrote:

>
> I see you your standards pedantry, and raise you!
>
> MIME defines content-type to always have a charset:
>
> *https://tools.ietf.org/html/rfc1521#section-4
> *
>

RFC 1521 is obsoleted by RFC 2045 which has more nuanced semantics:
https://tools.ietf.org/html/rfc2045#section-5

But actually, HTTP is not MIME; so we should be looking here instead:
https://tools.ietf.org/html/rfc7231#section-3.1.1.1
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] treq POST abborting with: err: ('Could not adapt', '{"....", "..."} )

[Tristan Seligmann]

On Sat, 7 Jan 2017 at 03:23 Glyph Lefkowitz  wrote:

>
> Maybe we should support unicode for the body as well.  We can set the
> charset in the mime-type and everything so that it will be properly
> intelligible by the server, which doesn't happen if the user manually
> encodes like this.
>

Oh, forgot to comment on this point; in the specific case of JSON, it isn't
necessary to specify UTF-8 in Content-Type[1], but for HTML or XML it's a
pretty good idea. However, I'm not sure if it's possible to modify
Content-Type in a generic fashion to make this sort of thing work; for
example, "Content-Type: application/octet-stream; charset=UTF-8" is
nonsense. I'll defer to some HTTP experts here ;)

[1] https://tools.ietf.org/html/rfc7159#section-8.1
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] treq POST abborting with: err: ('Could not adapt', '{"....", "..."} )

[Tristan Seligmann]

On Sat, 7 Jan 2017 at 03:23 Glyph Lefkowitz  wrote:

>
> Even if we do this though - is there any way to convince json.dumps to
> behave consistently between 2/3 for the purposes of examples?
>

As far as I know, the only way to handle this is with an if PY3 or if
isinstance(…). I don't know of a way to make json.dumps on Python 2
consistently return unicode, and I don't know of a way to make json.dumps
on Python 3 return bytes.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] treq POST abborting with: err: ('Could not adapt', '{"....", "..."} )

[Tristan Seligmann]

On Fri, 6 Jan 2017 at 21:21 steven meiers  wrote:

> glyph (without seeing the the code or backtrace) suggested that:
> "I think the issue might be that it doesn't support bytes() on py3,
> it's registered against str() or something"
>

Actually, the problem is the reverse of this; only bytes is supported, but
you're passing str (unicode) in.


> somepage = yield treq.post(target_url, json.dumps({hmac: key,
> "username": username, 'pw':'', 'gender':'m', '':''}),
>

json.dumps returns str (ie. unicode) on py3; throwing in a .encode('utf-8')
here is probably what you want.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] AWS Auth v4 for Twisted?

[Tristan Seligmann]

On Fri, 30 Dec 2016 at 02:30 Steve Morin  wrote:

> Mark,
>   Did you get confirmation from your work?
>

It seems like he did; see https://github.com/twisted/txaws/pull/16 for more
details.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.6.0rc1 Release Candidate Announcement

[Tristan Seligmann]

On Wed, 23 Nov 2016 at 01:14 Tristan Seligmann 
wrote:

> On Tue, 22 Nov 2016 at 23:37 Glyph Lefkowitz 
> wrote:
>
>
> This is the part that I'm worried about.  It kinda seems like we're moving
> toward "native string" being the type used in IRCClient, and *that* is
> capital-W Wrong.  Native strings are for Python-native types only, i.e.
> docstrings and method names.
>
>
> Unless I'm misunderstanding, we're not "moving towards" it, we have *already
> arrived*: IRCClient deals in str (bytes) on Python 2, and str (unicode)
> on Python 3. Even if we want a unicode API, having it only exist on Python
> 3 seems incredibly confusing from a user standpoint, and would appear to
> require some absurd contortions to write client code that behaves
> approximately the same on both Python 2 and 3.
>

For example, as far as I can tell, the only way to write code to join a
channel named #tëst (UTF-8 encoded) is:

channel = u'#tëst'
if PY3:
channel = channel.encode('utf-8')
client.join(channel)

On Python 3, client.join(b'#t\xc3\xab') will try to send JOIN b'#t\xc3\xab',
which is garbage, whereas on Python 2, client.join(u'#t\xebst') will
produce a UnicodeEncodeError.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.6.0rc1 Release Candidate Announcement

[Tristan Seligmann]

On Wed, 23 Nov 2016 at 01:26 Tristan Seligmann 
wrote:

> if PY3:
>

Argh, the above should be if PY2 of course.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.6.0rc1 Release Candidate Announcement

[Tristan Seligmann]

On Tue, 22 Nov 2016 at 23:37 Glyph Lefkowitz 
wrote:

>
> This is the part that I'm worried about.  It kinda seems like we're moving
> toward "native string" being the type used in IRCClient, and *that* is
> capital-W Wrong.  Native strings are for Python-native types only, i.e.
> docstrings and method names.
>

Unless I'm misunderstanding, we're not "moving towards" it, we have *already
arrived*: IRCClient deals in str (bytes) on Python 2, and str (unicode) on
Python 3. Even if we want a unicode API, having it only exist on Python 3
seems incredibly confusing from a user standpoint, and would appear to
require some absurd contortions to write client code that behaves
approximately the same on both Python 2 and 3.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Endpoint composition syntax

[Tristan Seligmann]

I'm kicking off this discussion on the mailing list as I don't have
anything well-formed enough to take to the bug tracker, and I am hoping to
get some more engagement on the matter.

Currently there is no way to explicitly compose Twisted endpoints, but
several endpoint implementations have arisen that explicitly wrap another
endpoint, and so have needed a way to do this. So far, this has been
implementing by passing in an endpoint description, and then calling
serverFromString/clientFromString internally in the endpoint to construct
the wrapped endpoint. I've seen two different ways of encoding the "inner"
endpoint:

1. Backslash escaping; for example:

tls:awesome.site.example.com:443:endpoint=tcp\:7.6.5.4\:443

This has the advantage that it is endlessly nestable, for example:

tls:internal.hostname.whatever:42:endpoint=tls\:awesome.site.example.com
\:443\:endpoint=tcp\\\:7.6.5.4\\\:443

It has the disadvantage that it is a bit tricky to read and write.

2. Splitting keyword and positional arguments; for example:

txsni:/srv/certs:tcp:443

This has the advantage that it is easier to read and write, but the
disadvantage that it isn't nestable. It also starts to break down when you
have a lot of parameters, as the positional syntax becomes much harder to
read.

Neither of these solutions is entirely satisfactory; I initially followed
approach 2 for txacme, but now that I need to add more parameters to the
le:/lets: endpoints, it is starting to break down.

Cory suggested a third possibility; an explicit syntax for composing
endpoints. In this model, the endpoint string parsing machinery would
construct the different endpoints, and compose them together (presumably
the API of the parsers would need to be extended a bit for this). For
example:

tls:awesome.site.example.com:443->tcp:7.6.5.4:443

A less whimsical syntax than "->" might be better; for example, semicolons,
or something like that.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.4.0 Prerelease 1 Announcement

[Tristan Seligmann]

On Sat, 13 Aug 2016 at 08:19 Amber "Hawkie" Brown 
wrote:

> In a rare Twisted release double feature right after 16.3.1, I bring you
> the first prerelease of Twisted 16.4.0.
>

FWIW my $DAYJOB test suite passes against 16.4.0rc1.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.3.1 Prerelease 1 Announcement

[Tristan Seligmann]

On Wed, 10 Aug 2016 at 14:48 Amber "Hawkie" Brown 
wrote:

> I've just uploaded the first prerelease of Twisted 16.3.1, a security &
> critical bug fix release of the 16.3 series. It contains:
>

FWIW my $DAYJOB test suite passes against 16.3.1rc1.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] INCOMPATIBLE CHANGE: twisted.python.dist renamed to twisted.python._setup

[Tristan Seligmann]

+1 from me

On Mon, 8 Aug 2016 at 02:35 Craig Rodrigues  wrote:

>
> I understand the motivation, but the time to have done this was when
> dist.py
> was originally reviewed.
>
> There are real problems in the Twisted code, and in the Twisted
> infrastructure.
> Focusing on something like this instead of those problems seems pointless,
> gratuitous and of little benefit.
>

The problem is that if we defer this change until later, it becomes a lot
more work then. If we do it now, while nobody is depending on the module,
then we save ourselves that work in future by doing a trivial amount of
work now.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] RFC: IPv6 multicast join/ticket 6597

[Tristan Seligmann]

On Thu, 4 Aug 2016 at 18:04 Jason Litzinger  wrote:

> I did try specifying the loopback index, however, I received a
> "Network Unreachable" error.  I didn't have time to dig into whether
> it was possible to do what I wanted with the loopback interface last
> night.
>

By default, the "multicast" flag is not enabled for the loopback interface
on Linux. Does running "ip link set dev lo multicast on" help here?
(Although requiring this would then be rather problematic for testing, as
doing this in containerized environments and restricted environments like
Travis is presumably impossible)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] New users cannot subscribe to mailing list

[Tristan Seligmann]

On Fri, 15 Jul 2016 at 20:06 Craig Rodrigues  wrote:

> Is anyone working on fixing this?
>

I believe this email explains things:
http://twistedmatrix.com/pipermail/twisted-python/2016-March/030233.html
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted 16.3.0 Prerelease 2 Announcement

[Tristan Seligmann]

On Tue, 12 Jul 2016 at 09:43 Cory Benfield  wrote:

> For that reason, you should adjust your code to use
> OpenSSLCertificateOptions or, even better, use the TLS endpoint directly.
>
> The exported name of this class is actually just "CertificateOptions",
fwiw.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] dropping old pyOpenSSL versions

[Tristan Seligmann]

On Thu, 7 Jul 2016 at 23:07 Clayton Daley  wrote:

> I don't object to this specific change (we're on shiny new code), but want
> to offer some food-for-thought:
>
> 1) Is newer really better in cryptography?  Heartbleed affected 1.0.1, but
> not 1.0.0 and there are a bunch of vulnerabilities that only affect the
> newer libraries (https://www.openssl.org/news/vulnerabilities.html).  It
> even makes sense that the older libraries have been more-thoroughly
> tested... so new code may just mean new vulnerabilities.
>

First of all, newer cryptography and newer OpenSSL are different things.
Given that cryptography itself is mostly made of Python and cffi, not C
code, I think it's unlikely that a newer version of cryptography is likely
to be worse than an older one. Older libraries being "more thoroughly
tested" only really applies where a library has a plethora of simultaneous
release channels; for most libraries, using older versions just means
missing out on any fixes for issues that were found more recently than the
release was released.

Even regarding OpenSSL, which is a horrible pile of C, it's unlikely that
the potential of another *Heartbleed*-like issue is more dangerous than the
lack of actual known improvements.

2) How does this impact regulated industries.  In healthcare (my current
> industry), changing a library (especially cryptography) could mean:
>
>- An internal review to select a new version of the library
>- An internal change management process
>- Technical testing (perhaps a 3rd party audit)
>- A notification to clients of the change
>- Secondary reviews/testing at clients
>
> The intensity of this process depends on the risk level of the system and
> this could be a long and complicated process for some organizations.  Seems
> like a more deliberate deprecation policy would make it easier to plan
> ahead.
>

Wouldn't all of the above apply equally to the new version of Twisted? I
would imagine you could upgrade Twisted and cryptography at the same time,
thus only doing one round of testing/review/etc. for both. (Perhaps I'm
missing something?)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Coverage exceptions

[Tristan Seligmann]

The tests directories can simply be excluded in coverage.py (or codecov), I
don't think there's any need to do something more complicated than that.

While I agree that 100% test coverage is an ideal worth aspiring to, I
think getting there from the current state is going to be a large amount of
work that yields very little benefit at this point in time; I would say
that there are more important things to spend that effort on.

On Sun, 3 Jul 2016 at 10:09 Adi Roiban  wrote:

> Hi,
>
> What decision should be made based on the feedback sent so far?
>
> Should we disabled the codecov coverage enforcement for 100% coverage for
> a patch as it also blocks missing coverage in a test?
>
> If we want to enforce only implementation code, then we need to update the
> tests to send separate reports for implementation and testing... and this
> is not done yet.
>
> Disabling/Enabling codecov.io merge protection is done here
> https://github.com/twisted-infra/braid/issues/213
>
> 
>
> I would argue that testing code should have the same quality standards as
> the implementation code and hence also go for 100% coverage.
>
> It will help detect code which is never executed and which later might get
> out of sync or might break. This include mocked code which is out of sync
> or tests which are skipped on all builders and which will get out of sync
> and fail (ex our apidoc builder tests).
>
> It will also simplify the reporting infrastructure ... and we are
> already short-handed so a simple infrastructure should help move things
> forward much faster.
>
> --
> Adi
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] two minor things

[Tristan Seligmann]

On Wed, 22 Jun 2016 at 10:05 Glyph  wrote:

>
> If we are going to change this, I would really appreciate it if someone in
> favor of the change would write a script to re-name the literally thousands
> of outstanding branches to the new convention, so we don't have a random
> mix.  Luckily git makes this considerably more light weight, since it just
> changes the name of the pointer and doesn't create new revisions :-).
>

I think most of the "outstanding branches" are actually merged, and need to
be deleted. So maybe a script to do that first...? (Sorry, I'm not likely
to get around to this any time soon)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted Challenge Coins!

[Tristan Seligmann]

I'll take 5 coins. I'm in South Africa, but I have a US forwarding address
(in Florida) that can be used to simplify logistics.

On Wed, 15 Jun 2016 at 03:46 Ashwini Oruganti 
wrote:

> Hello!
>
> We are planning to get us some challenge coins, which is exciting! You
> should also be excited with us because this means:
>
> - we can now give it out to contributors at sprints and meetups.
> - challenge coins are awesome.
>
> Each coin costs about $6, and the minimum order is 100 coins. Glyph thinks
> everyone should have some to give out as tokens of appreciation to other
> contributors, and glyph's thoughts are usually worth following.
>
> So, if you are a Twisted contributor and would like to own a challenge
> coin, please respond to this email. Also, do mention how many coins you
> would like, and where you are located so that we can send you your coin(s).
>
>
> -ashfall
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] overview: new review queue venue

[Tristan Seligmann]

Note that even without the bot, I believe you can just create a new PR for
the same branch, so it's not *too* bad, but definitely a little clunky.

On Mon, 23 May 2016 at 06:59 Amber "Hawkie" Brown 
wrote:

> Mark has been working on a bot which would reopen it with a comment:
> https://github.com/markrwilliams/txghbot
>
> - Amber
>
> > On 23 May 2016, at 12:56, Craig Rodrigues 
> wrote:
> >
> > I submitted this PR, which is now closed:
> https://github.com/twisted/twisted/pull/62
> >
> > I don't want to re-open that PR, but I am using that as an example
> > As an example, if I wanted to re-open that, how would I go about doing
> it?
> >
> > I am not an administrator of the Twisted GitHub project, so on that web
> link,
> > there is no option for me to re-open the PR.
> >
> > Are you suggesting that I would need to
> >-> create a new branch in my repo with new commits
> >-> create a new pull request
> >
> > ?
> >
> > --
> > Craig
> >
> > On Sun, May 22, 2016 at 9:39 PM, meejah  wrote:
> >
> > closing a PR with a nice note explaining, "please re-open when X is
> > fixed/changed" scares away a potential contributer I have my doubts as
> > to whether they would fix X if you *didn't* close it...)
> >
> > ___
> > Twisted-Python mailing list
> > Twisted-Python@twistedmatrix.com
> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] overview: new review queue venue

[Tristan Seligmann]

On Sun, 22 May 2016 at 10:12 Ralph Meijer  wrote:

> On May 22, 2016 9:36:28 AM GMT+02:00, Glyph 
> wrote:
> >[..]
> >(Please nobody try to do the clever thing where you configure buildbot
> >to automatically pull all PRs, that would effectively negate any
> >security protections...)
> >
> >I've been assuming that in the worst-case scenario, we'd do what
> >Cryptography does and have a bot that polls for special comments and
> >then triggers buildbot in exactly this way.  Perhaps I should have made
> >that assumption explicit, I thought it was ticketed somewhere in Braid
> >already.
>
> The Jenkins plugin for GitHub PR triggers has this feature, too. However,
> it also has a feature to whitelist users and GitHub teams so that
> PRs/commits can trigger automatically for them. Maybe that's a thing for
> us, too?
>

I don't think we need a whitelist, we can just automatically build branches
that are pushed to the twisted/twisted repository. If you can push a branch
there, you can also push a change directly to trunk, so you can already
execute arbitrary code on the buildbots.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] [ALL OK] [INFRASTRUCTURE OUTAGE] Moving from SVN to Git

[Tristan Seligmann]

On Tue, 10 May 2016 at 20:38 Paweł Miech  wrote:

> Hello Amber,
>
> > we've moved to https://github.com/twisted/twisted as our
> "authoritative" mirror.
>
> are there any consequences of this for Twisted users and/or casual
> contributors?  I used github source for a while not knowing it was not
> "authortiative" mirror, it always seemed fresh and updated.
>

The git mirror has been updated from the Subversion repository on commit
for quite a while, so it was up to date, it just wasn't the correct place
for committers to push changes to; this is what has changed now.

I just got done editing a bunch of the wiki pages about the development
process, primarily https://twistedmatrix.com/trac/wiki/TwistedDevelopment —
so hopefully it should be clearer how to proceed now.


> I remember some discussion on mailing list about moving issue tracking to
> github, is today's migration part of this process? Are there plans to
> accept pull requests on github?
>

The main remaining problem with pull requests is that a committer has to
push a branch to the main repository in order to run builds on the
buildbots; this is due to issues around executing arbitrary code on the
buildbots. Thus a PR-based workflow for non-committers currently doesn't
make much sense.

Issue tracking remains on Trac, at least for the forseeable future
(implementing our workflow with GitHub issues is quite challenging).
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] [ANN] txacme 0.9.0, zero-configuration HTTPS for your Twisted app!

[Tristan Seligmann]

txacme[0][1] provides a TLS endpoint to automatically issue (and renew)
certificates via the Let's Encrypt CA, allowing you to effortlessly turn on
HTTPS for your application. A brief demonstration can be seen here:
https://asciinema.org/a/41758

In support of this, txacme also includes a client implementation of
the draft-ietf-acme-acme-01[2] specification, and a service for
automatically checking and reissuing expired certificates. If the default
zero-configuration endpoint doesn't do what you want, then go wild with
these.

If you have any interest at all in txacme, please take a look at the
currently provided API, and ask questions and/or file issues on GitHub
should there be any aspects of your potential use case that are not covered
by the API as it stands; I would like to use the 0.9.x period to get a
solid API nailed down for the 1.0 release.

[0] https://pypi.python.org/pypi/txacme

[1] https://github.com/mithrandi/txacme

[2] https://tools.ietf.org/html/draft-ietf-acme-acme-01 — support
for draft-ietf-acme-acme-02 will probably be forthcoming once Let's Encrypt
actually supports this server-side.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] where can I find twisted.application.internet.ClientService?

[Tristan Seligmann]

On Sun, 27 Mar 2016 at 04:17 Gelin Yan  wrote:

>
>
> https://twistedmatrix.com/documents/16.0.0/api/twisted.application.internet.ClientService.html
>

Unfortunately ClientService did not make it in time for 16.0.0, but it will
be in the upcoming 16.1.0 release :)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Intended semantics of IReactorTime.seconds

[Tristan Seligmann]

Currently, as far as I can tell, all implementations of
`IReactorTime.seconds()` (excluding twisted.internet.task.Clock, obviously)
are just `time.time()`; IOW, the return value is the number of seconds
since the beginning of the UNIX epoch in UTC. Are these the intended
semantics? The interface docstring doesn't really make this clear at all.

There's some commented out code which suggests the implementation used to
be `time.clock()` on win32, which would not satisfy these semantics.

(The background for this question is that I'm writing some code which takes
an IReactorTime provider for testing purposes, and I'm wondering if I need
a separate provider of `datetime.now()` functionality or not)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] A little present for emacs / flycheck users

[Tristan Seligmann]

The 'python-mode-hook is just a function, so you can put whatever code you
want in there. I'm not sure exactly what the best mechanism to control this
would be, though; maybe a directory variable?

On Tue, 9 Feb 2016 at 15:17 Jonathan Lange  wrote:

> Thanks! https://launchpad.net/twisted-emacs is the best I could find re
> PRs.
>
> Do you have a way to make this conditional? There's precisely one Python
> project where I care about using the twistedchecker linter :)
>
>
> On Tue, 9 Feb 2016 at 07:12 Tristan Seligmann 
> wrote:
>
>> You may find this to be of use:
>>
>> https://gist.github.com/mithrandi/15fca4367e878b6b88cd
>>
>> Is there somewhere I should be submitting this as a PR or something? (I
>> guess I could release the checker as an emacs package, it's somewhat
>> specific though)
>>
> ___
>> Twisted-Python mailing list
>> Twisted-Python@twistedmatrix.com
>> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] A little present for emacs / flycheck users

[Tristan Seligmann]

You may find this to be of use:

https://gist.github.com/mithrandi/15fca4367e878b6b88cd

Is there somewhere I should be submitting this as a PR or something? (I
guess I could release the checker as an emacs package, it's somewhat
specific though)
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Debian unstable builder

[Tristan Seligmann]

Working on tickets such as #8180[1] and #8187[2] suggests that it would be
useful to have a builder running on Debian unstable (and/or other "bleeding
edge" distributions, most of them have something similar) in order to pick
up problematic changes like this sooner. #8180 is just a case of a newer
upstream release (OpenSSH 7.0 disables DSA key support by default), whereas
I think #8187 is a "distro policy" type thing (OpenSSL in Debian unstable
is compiled without SSLv3_METHOD support).

I don't think making such a builder be a supported platform would be
feasible (at least as things currently stand), but at least it would serve
as a canary for this sort of issue.

Thoughts?
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Suggested plan for GitHub migration

[Tristan Seligmann]

On Mon, 30 Nov 2015 at 16:50 Amber "Hawkie" Brown 
wrote:

> The migration will have a handful of policy changes that we will have to
> resolve -- such as ensuring that all merges have a topfile -- which aren't
> possible under a GitHub based system.


You could make master/trunk/whatever a protected branch, and have a
required status check for this, but that would require some external CI
thing that actually performs the status check.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Streaming HTTP

[Tristan Seligmann]

On Sat, 14 Nov 2015 at 17:45 Cory Benfield  wrote:

> A similar approach should be taken with sending data: we should assume
> that users want to chunk it if they do not provide a content-length. An
> extreme position to take (and I do) is that this should be sufficiently
> easy that most users actually *accidentally* end up chunking their data:
> that is, we do not provide special helpers to set content-length, instead
> just checking whether that’s a header users actually send, and if they
> don’t we chunk the data.
>

As far as I know, this is exactly what is done in the existing HTTP/1.x
implementation: if a Content-Length header field is not set before data is
written to the request object (as it is called), chunked transfer encoding
is automatically used for the response. This behaviour is required by
HTTP/1.1.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] HTTP/2 and Twisted

[Tristan Seligmann]

On Thu, 12 Nov 2015 at 12:46 Cory Benfield  wrote:

> However, this may not work: in particular, some of the other classes in
> twisted.web may know altogether too much about HTTP/1.X: in particular, if
> they have the nerve to write directly to a transport we’ve got a real
> problem with this approach, as HTTP/2 does not allow naked writes on its
> sockets (all data is framed).
>

I'd like to point out a few things on this topic:

1) The Twisted project has already experimentally demonstrated the
imprudence of an approach that massively breaks backwards compatibility
with old APIs (even if it does this in concordance with the compatibility
policy, by adding a bunch of new things): see the defunct twisted.web2
project.

Realistically, if you say "hey people, twisted.web now has HTTP/2 support,
all you have to do is port all of your code and all of your libraries over
to these new APIs!", the response isn't going to be "great, I'll get right
on that!". It'll be "oh well, I guess I'll just throw an nginx reverse
proxy in front of my app to get HTTP/2 working" or "oh well, never mind
then".

A successful approach to introducing HTTP/2 into twisted.web needs to allow
for hooking up existing resources to an HTTP/2 (or actually, presumably
multiprotocol) server.

2) Having said that, it's not necessary for the HTTP/2 server to be
completely compatible with the current HTTP/1.x server in twisted.web. For
some things, this is just flat out impossible (I believe there are things
that HTTP/1.x allows, but HTTP/2 doesn't allow), and for other things it
just doesn't make sense (stealing the transport and writing stuff to it
yourself). However, we only need to support the common set of things that
people use in order to be usefully compatible; if you just have some
resources that aren't doing anything particularly crazy (like hijacking the
transport and writing directly to it, rather than via the request object),
you should be able to hook them up and have them work.

For anything that we *can't* support, it's okay for the HTTP/2 server to
just raise an exception or whatever; for anything that we can reasonably
support, but don't actually want to, it's okay to emit a deprecation
warning, and later an exception.

3) Having said *that*, there is widespread agreement that the existing APIs
(IResource, IRequest, etc.) have numerous deficiencies that should be
addressed. For example, the current interfaces don't allow for streaming
request handling, which obstructs implementing 100-continue support (among
other things).

We *do* need newer interfaces which hopefully improve on the new ones; I
don't really feel like I'm in a position to sketch out what these
interfaces should look like, but they should definitely take into account
the constraints of the HTTP/2 protocol, as well as the needs of application
code.

PS: I've used the pronoun "we" multiple times in this email for the sake of
rhetorical convenience, but please don't let this dissuade anyone from
voicing disagreement with any of the claims I've made should they appear
incorrect.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] An error occurred with twisted 15.2.1 & python 3.4.3 on windows

[Tristan Seligmann]

On Mon, 27 Jul 2015 at 13:18 Gelin Yan  wrote:

>   Is it a bug?
>

Yes; see https://twistedmatrix.com/trac/ticket/7626 for more details.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] broken buildbots

[Tristan Seligmann]

On Sun, 7 Jun 2015 at 03:43 Glyph  wrote:

>
> On Jun 6, 2015, at 6:40 PM, Glyph  wrote:
>
> https://buildbot.twistedmatrix.com/buildslaves/hawkowl-debian7-py34 -
> which is apparently maintained by "Your Name Here <
> admin@youraddress.invalid>" - is presently failing all its builds because
> it is running out of memory.  Can someone with access to this box, whoever "
> admin@youraddress.invalid" is, please free up some RAM?
>
> -glyph
>
>
> Oh, I spoke too soon.  All the ENOMEMs are coming out of os.fork, which I
> guess means somehow process spawning got disabled?  I am wondering if the
> buildslave has lingering subprocesses hanging out and blowing its cgroup
> quota inside its docker container (these are running inside docker, right?)
>

ENOMEM on fork() can just mean that overcommit is disabled and there is
insufficient virtual memory available to temporarily accomodate 2x the
process's memory size, even though there is enough memory available to
accomodate 1x.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Multiple plugins in "twistd"

[Tristan Seligmann]

On 21 May 2015 at 04:31, Moshe Zadka  wrote:
> [2a] Since the docstrings do refer to the parent attribute, and since I
> would be surprised if services just implemented the interface without
> inheriting from "Service", I wonder if people object *too* much if I "fix"
> it by documenting the parent attribute as part of the interface?

For what it's worth (not sure if a single anecdote is helpful), almost
none of my IService implementations inherit from Service (mainly
because multiple inheritance is awkward, and they already want to
inherit from axiom.item.Item). However, I'm pretty sure they all have
the "parent" attribute.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] INCOMPATIBLE CHANGE: Removing PAM support from Twisted

[Tristan Seligmann]

On 11 May 2015 at 06:35, Glyph  wrote:
> I'm very much in favor of an outright removal in this case, so consider me 
> signed off.  Given the gnarly security implications of this thing I would 
> take the unusual step of continuing to approve of removal even if we have a 
> real-life user who might be impacted.
>
> That said, lack of actual PAM support (and more generally, 
> platform-integrated user authentication mechanisms) is a sore spot and we 
> should add something less terrible when we can.

What glyph said :)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Fwd: Adding callbacks using loop variables

[Tristan Seligmann]

On 6 May 2015 at 10:26, Saoili  wrote:
> Eg. code BEFORE
> for loop_var in a_dict['loop_vars']:
> d = self.returns_a_deferred(loop_var["x"])
> d.addCallback(
> lambda ret_val: self.do_another_thing(
> other_param, loop_var.copy(), ret_val
> )
> )
> _dlist.append(d)
> return defer.DeferredList(_dlist)
>
> Eg. code AFTER
> def other_func(ret_val, other_param, loop_var):
> return self.do_other_thing(
> other_param, loop_var, ret_val
> )
>
> for loop_var in a_dict['loop_vars']:
> d = self.returns_a_deferred(loop_var["x"])
> d.addCallback(other_func, other_param, loop_var)
> _dlist.append(d)
> return defer.DeferredList(_dlist)

There's another common trick for dealing with this, that relies on the
fact that default argument values are evaluated when the lambda
expression itself (not the body of the lambda!) is initially
evaluated; basically, just add an extra parameter with a default value
of the loop variable. For example:

 for loop_var in a_dict['loop_vars']:
 d = self.returns_a_deferred(loop_var["x"])
 d.addCallback(
 lambda ret_val, loop_var=loop_var: self.do_another_thing(
 other_param, loop_var.copy(), ret_val
 )
 )
 _dlist.append(d)
 return defer.DeferredList(_dlist)

However, separating the code out into a separate function may serve to
make the code clearer.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] [ANN] clj-amp 0.9.0

[Tristan Seligmann]

I am pleased to announce the release of clj-amp 0.9.0[1][2], a Clojure
implementation of the AMP[3] protocol (a reference implementation of
which is found in Twisted). While slightly off-topic for this list,
this project may be of interest to anyone with AMP services they would
like to interoperate with from Clojure code. Also, this is the closest
thing to an AMP mailing list that exists (at least as far as I'm
aware).

Despite this being the first release, clj-amp is essentially feature
complete. The 0.9.0 version number reflects my reluctance to designate
this 1.0.0 for the following reasons:

 * Lack of users and real-world testing: the project was just released.

 * API instability: while I do not have any immediate plans to break
API compatibility, I would like to reserve the right to make API
changes based on initial feedback from users (assuming anyone uses
it...) in order to correct any glaring issues with the API that may be
discovered.

 * Minimal test coverage and documentation: I would still like to
expand the test coverage to include more specimens of AMP encodings,
as well as expand the documentation.

Any feedback on the API as well as the documentation would be greatly
appreciated.

[1] https://github.com/mithrandi/clj-amp

[2] https://clojars.org/clj-amp

[3] http://amp-protocol.net/
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Unhandled Error in python 3 test suite

[Tristan Seligmann]

On 23 March 2015 at 16:25, HawkOwl  wrote:
> It's not really a bug -- it's just that the stderr isn't being captured like 
> real Trial does. Twisted will reraise errors so they show up in logs, but 
> will actually handle them (I think, anyway). The traceback formatting just 
> says it's an unhandled error. That is, it was handled by Twisted, but it was 
> unhandled by user code, and generated an errback or such.

Note that "Unhandled error in Deferred" is the default log message for
log.err, and a lot (most?) of the code that logs a failure calls
log.err without passing a different message.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] __nonzero__ for Deferred

[Tristan Seligmann]

On 19 March 2015 at 00:03, Glyph Lefkowitz  wrote:
> I'd like to deprecate and remove __nonzero__ on Deferreds.

By "remove" do you mean "add an implementation that raises an
exception"? (It seems like this must be what you meant, I just wanted
to be clear since this is a slightly subtle issue)

I'm not sure offhand if I have any code that would be affected by
this, but I don't think I would have a problem considering any such
code incorrect. The most likely case I can think of is where I've
lazily written something like "if d" instead of "if d is not None".

That is to say, "+1".
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Specifying ciphers in ssl.optionsForClientTLS

[Tristan Seligmann]

On 17 February 2015 at 04:19, Jason J. W. Williams
 wrote:
>> Some browsers won’t — Firefox refuses to use RC4 :)
>
> I saw that on Firefox's wiki, but in reality Firefox 35 still does
> allow RC4: http://www.screencast.com/t/AuMRylAV

IIUC, Firefox 36 will only allow RC4 as a fallback (but not disable it
completely), and I think there is talk about disabling RC4 completely
for TLS 1.1/1.2.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] ANN: Axiom 0.7.3

[Tristan Seligmann]

I'm pleased to announce the release of Axiom 0.7.3. Axiom is an
in-process object-relational database for Python, built on SQLite.

This release is a bug fix release to correct another important issue;
anyone using Axiom on PyPy should upgrade as soon as possible to avoid
potential data loss in their application. For more information on this
bug, see the Github issue[1].

The release is available from PyPi as usual[2], signed with my personal key[3].

[1] https://github.com/twisted/axiom/issues/37
[2] https://pypi.python.org/packages/source/A/Axiom/Axiom-0.7.3.tar.gz
[3] https://pypi.python.org/packages/source/A/Axiom/Axiom-0.7.3.tar.gz.asc
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Retiring buildslaves

[Tristan Seligmann]

Hi buildbot infrastructure maintainers,

I am intending to retire my buildslaves (bot-idnar-debian and
bot-idnar-debian64) upon release of jessie (Debian 8.0). The proximate
cause for this is planned changes for the machines currently hosting
the slaves; but given the current situation of Twisted's buildslave
infrastructure, I don't think they're providing much value at this
point, so restoring them after my infrastructure changes doesn't seem
worth it.

I took a look at the buildmaster configuration, however I couldn't
really figure out how to unentangle them since they're currently only
being used for somewhat esoteric builders. Can someone else figure
this out for me? ;)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] 15.0 Prerelease Reports

[Tristan Seligmann]

On 16 January 2015 at 05:42, HawkOwl  wrote:
> Does anyone have some “15.0 worked fine/had an issue/set my codebase on fire 
> via sheer brilliance” reports for me? :) If you want to try them out, you can 
> get the tarballs at http://twistedmatrix.com/Releases/pre/15.0.0pre1/ !

Ran 1116 tests in 26.381s

PASSED (skips=2, expectedFailures=1, successes=1113)

:)

(We actually deploy Twisted directly from SVN, so I don't usually test
prereleases, but it was easy enough to check)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Axiom 0.7.2

[Tristan Seligmann]

I'm pleased to announce the release of Axiom 0.7.2. Axiom is an
in-process object-relational database for Python, built on SQLite.

This release is a bug fix release to correct an important issue;
anyone using Axiom 0.7.0 or 0.7.1 on PyPy (versions prior to 0.7.0 did
not support PyPy) should upgrade as soon as possible to avoid
potential data loss in their application. For more information on this
bug, see the Github issue[1].

The release is available from PyPi as usual[2], signed with my personal key[3].:

[1] https://github.com/twisted/axiom/issues/29
[2] https://pypi.python.org/packages/source/A/Axiom/Axiom-0.7.2.tar.gz
[3] https://pypi.python.org/packages/source/A/Axiom/Axiom-0.7.2.tar.gz.asc
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Importing/Exporting Putty and SSH.com keys

[Tristan Seligmann]

On 30 November 2014 at 18:52, Glyph  wrote:
> PuTTY does not seem to me to be very friendly to automation.

OT: for automation, you probably want Plink not PuTTY.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] natty64-py2.7maint & twistedchecker builders

[Tristan Seligmann]

On 18 September 2014 07:16, Glyph  wrote:
> On Sep 17, 2014, at 8:41 AM, Tristan Seligmann  
> wrote:
>> Speaking of EOL, squeeze is effectively EOL now too (unless you count
>> the squeeze-lts effort, which is very limited in scope); as such, I
>> would like to upgrade or retire my buildslaves (bot-idnar-debian{,64})
>> which are still running squeeze. I think newer version of Debian are
>> already covered by other buildslaves; so are these still needed at
>> all?
>
> Not as far as I know.  I think you can feel free to deprovision them 
> (although I think you need to submit a PR for the buildmaster's config to 
> remove them from the buildmaster and supported list)

Is the buildmaster's config in a publically accessible repo? If so,
where? (If not, how do I get access?)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] natty64-py2.7maint & twistedchecker builders

[Tristan Seligmann]

On 17 September 2014 02:14, Glyph Lefkowitz  wrote:
> For what it's worth, the EOL on Natty was almost 2 years ago now:
>
> 

Speaking of EOL, squeeze is effectively EOL now too (unless you count
the squeeze-lts effort, which is very limited in scope); as such, I
would like to upgrade or retire my buildslaves (bot-idnar-debian{,64})
which are still running squeeze. I think newer version of Debian are
already covered by other buildslaves; so are these still needed at
all?
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Who's doing the merges for reviewed and blessed pull requests at twisted/nevow?

[Tristan Seligmann]

On 12 August 2014 03:45, Werner Thie  wrote:
> Mahalo for enlightening me, Werner

I'm one of the people with write (commit?) access to Nevow. I just
approved and merged your pull request; sorry for taking so long to get
back to this.

I'm not exactly sure where GitHub shows who has write access to a
repository, maybe somebody else knows.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] tor hidden service endpoint parser returns a deferred

[Tristan Seligmann]

On 2 May 2014 15:59, David Stainton  wrote:
> This will work fine for the txsocksx tor client endpoint parser I
> wrote... However the txtorcon Tor Hidden Service endpoint setup
> requires a deferred to fire once the tor process is started... This
> means that the endpoint parser needs to return a deferred. But this
> breaks the interface!... meaning that foolscap or any other api using
> this onion endpoint parser will have to special case the situation
> where serverFromString returns a deferred.

I think you're approaching this from the wrong angle; instead of
starting the tor process during parsing of the endpoint, I think it
would make more sense to start the tor process when the endpoint is
started.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Manhole but no SSH

[Tristan Seligmann]

On 16 April 2014 00:09, Nicholas  wrote:
> Hello, everyone.
>
> Is it possible to implement the Manhole but without using SSH (or telnet,
> for that matter) ?
>
> Say I start a service and I want to be thrown straight in a console, much
> like Manhole does with SSH, but without having to actually listen on a port
> and having to connect to it with an user and password.

This sounds a lot like `python -m twisted.conch.stdio`; I'm not sure
how easily reusable that code is, but hopefully it shouldn't be too
hard to use from an existing application!
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Buildslave outage

[Tristan Seligmann]

Hi all,

Sorry for the short notice. My buildslaves (bot-idnar-debian{,64})
will be down for the next 8 hours or so, due to the host systems being
moved to another datacentre.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] transport.write performance.

[Tristan Seligmann]

On Wed, Aug 7, 2013 at 10:10 PM, Glyph  wrote:

>
>
> On Aug 7, 2013, at 1:06 PM, Laurens Van Houtven <_...@lvh.io> wrote:
>
> FWIW, Maciej commented that they don't expect to be *faster*, because they
> actually care about the JSON spec or checking return values. Things which
> ultrajson conveniently ignores :-) It's pretty easy to do the wrong thing
> fast, but that seems to be a common theme in this thread.
>
>
> I just said "improved", i.e. 2.1 ought to be faster than 2.0, no claims
> relative to anything else :).
>
> I'm aware that ultrajson is pretty bad, but cjson had comparable (if
> slightly slower) performance.  Does it also have correctness and security
> problems?
>

It's also important to note that in a microbenchmark, JIT warmup can be a
significant factor in PyPy. If you're interested in the performance of
short-running applications (eg. command-line tools) then this is very
relevant, but for a long-running server process you're unlikely to care
about the warmup overhead but rather the sustained performance thereafter.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Python 3: bytes vs. str in twisted.python.filepath

[Tristan Seligmann]

On Sun, Jul 14, 2013 at 4:00 AM, Harry Bock  wrote:

> (b) Misunderstandings at the application level about the underlying
> filesystem's path encoding is not the problem of the Twisted API.  Correct
> me if I'm wrong, but that's the responsibility of the system administrator
> or individual user (at least on UNIX) to set the LANG environment variable,
> or for the application to call setlocale(3) to explicitly override it.
>

There is no way to enforce a particular setting of the LANG environment
variable globally; multiple users could use filenames encoded in different
encodings (in fact even a single user could do this), and files could be
transferred from other systems using different encodings. While a
reasonable person might insist on the use of UTF-8 everywhere, there is no
way to guarantee that UNIX filenames are all in the same encoding, or are
even in any particular encoding at all (they might be binary non-text
garbage), and the inability to deal with filenames like this would be
somewhat of a serious defect.

On Windows, the reverse situation obtains, of course.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted web, giant-file POST forwarding and early bail-out.

[Tristan Seligmann]

On Tue, Jul 9, 2013 at 10:41 AM, Phil Mayers wrote:

> This is sort of a problem with HTTP. The client will probably keep sending
> the data.
>

Yes, the only way you can interrupt the client while it is sending a
request is to close the connection, which means that the client will not
read any error response you sent.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] logging

[Tristan Seligmann]

On Sun, Jun 16, 2013 at 4:38 AM, Glyph  wrote:

>
> (I was going to say that without a format string I couldn't have my
> stand-in UUID feature, but then I realized that namespace + set of keys is
> probably good enough to generate that too, so never mind.  Also it seems
> like I'm the only one who likes that feature so maybe it doesn't matter!)
>

I don't have anything useful to contribute at the moment, but you can add
me to the list of people who like that feature.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Release questions

[Tristan Seligmann]

On Fri, Apr 5, 2013 at 2:32 AM, Laurens Van Houtven <_...@lvh.cc> wrote:

> DSA, by default, used SHA-1; recent revisions support SHA-2. A few years
> ago, GnuPG and several big users including Debian and Apache started
> suggesting the move to RSA instead of DSA keys. The algorithms vary a bit
> in speed and signature size, but the main reason was to allow newer hash
> functions.
>
> That said, I'm pretty sure GPG uses a newer revision of DSA: when I left
> the defaults untouched near the end of 2012, it still seemed to prefer
> DSA/ElGamal despite the news from a few years ago. IIRC, the first version
> of the algorithm only allowed 1024 bit keys, whereas my DSA key is 3072.
>

DSA keys larger than 1024 bit(?) are "non-standard", but I think the bigger
issue is that DSA only supports 160-bit hashes; larger hashes will be
truncated, which means you don't gain much by using SHA-256/SHA-512/etc.
instead of SHA-1. DSA2 can handle larger hashes, but there's no real reason
to use DSA2 when RSA is so widespread. I think this is the reason the
defaults are changing (were changed?) in GnuPG.

I guess this is drifting off-topic though...

Here's how you check what you support and in which preference:
>

Thanks, much more useful than my vague speculation about defaults ;)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Release questions

[Tristan Seligmann]

On Thu, Apr 4, 2013 at 12:04 AM, Glyph  wrote:

> Security-wise, signing an actually-secure hash is not that much different
> than signing the tarballs themselves.  Signing MD5 hashes, on the other
> hand, is useless as a security measure.
>
> I think we should carry on with signing the list of signatures for now,
> and just upgrade the hash algorithm.  Baby steps.  Perhaps there are some
> theoretical benefits that come from signing the whole binary blob, but
> that's a much bigger change for a much smaller benefit.
>

In fact, I believe there is no such thing as "signing the whole binary
blob". When you use something like gpg --sign, what is actually signed with
a public key signature algorithm is a hash of the content anyway. Thus,
assuming you use the same hash algorithm as you would have instructed gpg
to use (I think the default is SHA512 these days), there isn't any real
difference between signing the content directly, and signing a hash of the
content.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Release questions

[Tristan Seligmann]

On Wed, Apr 3, 2013 at 11:58 PM, Laurens Van Houtven <_...@lvh.cc> wrote:

> Is the accidental corruption thing a real risk? I thought that was the
> point of, say, TCP checksums :) Perhaps I'm just mistaken as to how often
> his happens in the wild...
>

TCP checksums don't protect you against corruption occurring on the server
or client, only corruption by intermediary routers (and if they recalculate
the checksum, not even that). In practice, the most common form of
accidental corruption I've encountered is truncation; many HTTP user agents
don't report any kind of error when fewer bytes are received from the
server (due to prematurely terminated HTTP connection, bad proxy server,
etc.) than expected.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] eated traceback when decorate method already decorated by inlineCallbacks

[Tristan Seligmann]

On Thu, Mar 14, 2013 at 4:20 PM,   wrote:
> except:
> Failure.printTraceback()

I think this was supposed to be:

except:
Failure().printTraceback()

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] How to dispatch message to different servers

[Tristan Seligmann]

On Sat, Mar 2, 2013 at 10:34 PM, Laurens Van Houtven <_...@lvh.cc> wrote:
> Could you help me write an AMP implementation in Javascript? It's easy,
> right? ;-)

It can't be harder than writing a PB implementation in JavaScript ;)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] How to dispatch message to different servers

[Tristan Seligmann]

On Sat, Mar 2, 2013 at 6:36 PM, Phil Mayers  wrote:
> On 03/02/2013 03:24 PM, Tristan Seligmann wrote:
>
>> I don't really understand how this is any easier with PB than with
>> AMP, though. With AMP, you "just" need the same command definitions on
>> both sides. With PB, you need the exact same Python code versions for
>> every class you are sending over the wire;
>
> I don't use PB like that. I only ever send simple data structures made
> of builtin types (int, str, list, dict).

Interesting; I guess that's obvious in retrospect but I hadn't thought
of using PB like that, and I suppose it's not possible to use AMP like
that.

>> You don't quite have to do a TCP handshake for every request you want
>> to send over an HTTP channel, but there are still some problems.
>
> You're not telling me anything I don't already know.
>
> My point is that, for the use-cases *I* have, those limitations have not
> proven to be a problem, so the effort of deploying a protocol which avoids
> those limitations is not warranted.

Sure, I didn't mean to imply otherwise, just wanted to clarify for the
purposes of the discussion. It sounds like your analysis is sound for
the use cases you're concerned with, I don't have any objection to
that.
--
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] How to dispatch message to different servers

[Tristan Seligmann]

On Sat, Mar 2, 2013 at 3:46 PM, Phil Mayers  wrote:
> AMP would be somewhat more attractive (to me) if it were possible to run
> with the IDL just on the "server" (i.e. callee); this would achieve the
> goal of protocol-level sanity checking, without the cost of having to
> distribute the IDL to the clients. Presumably it would be possible to
> implement this now - have an AMP discovery command that dynamically
> builds the client-side IDLs. But there's no incentive for me to do that.

I don't really understand how this is any easier with PB than with
AMP, though. With AMP, you "just" need the same command definitions on
both sides. With PB, you need the exact same Python code versions for
every class you are sending over the wire; if achieving this is not a
problem, then why is it problematic to get the same AMP command
definitions on both sides?

> You don't need to do a TCP handshake for every request in any of those
> protocols either. Long-lived TCP/HTTP sessions are quite common, though
> not universal.

You don't quite have to do a TCP handshake for every request you want
to send over an HTTP channel, but there are still some problems.
Connection keep-alive means you can send another request after you
have received a response, without reconnecting; pipelining means you
can send another request right away, but you still won't get the
response until after you receive the first response. In addition,
there are various error handling situations where you are basically
forced to close the connection and open a new one. By contrast, an AMP
connection can have any number of AMP request/response exchanges in
flight at one time, in either direction; the closest thing to this in
HTTP-land is SPDY's connection multiplexing, but that's still
asymmetric (client makes requests to the server, server cannot make
requests to the client, so you need to do some kind of long polling /
inversion of control to simulate this).
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Twisted client memory leak

[Tristan Seligmann]

On Tue, Jan 22, 2013 at 3:06 PM, Diego Woitasen  wrote:
> I reproduce the problem with a modification of Echo client example
> from Twisted documentation:

Adding __del__ methods causes the object to become uncollectable if it
forms part of a reference cycle. Thus it is almost always a bad idea
to add __del__ methods when attempting to debug a space leak, as the
most likely outcome is that you introduce a _new_, _different_ leak to
the one you are trying to debug.
--
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Layer 2 and Twitsted

[Tristan Seligmann]

On 15 Jan 2013 7:41 PM, "outcast"  wrote:
>
> Greetings,
>
> Has anyone done any work around using twisted for layer 2 traffic?

Layer 2 traffic would be the domain of twisted.pair; I'm not aware of
anyone using this in a "real" project, though, and I'd wager it needs some
extra work before it'll be useful for most purposes.
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] a question about monotonic clock

[Tristan Seligmann]

On Mon, Oct 29, 2012 at 10:33 AM, Phil Mayers  wrote:
> On 10/28/2012 10:16 PM, Tristan Seligmann wrote:
>> On Mon, Oct 29, 2012 at 12:05 AM, Phil Mayers  
>> wrote:
> Sadly, this is not the case. As has already been pointed out, virtual
> machine clocks can undergo stepping in "normal" oepration. A specfic
> example: if a VMWare installation performs live migration of a host. We
> often see:
>
> ntpd[1793]: time reset +0.263757 s
>
> ...when this happens. This can occur several times a day, as we're
> running vCenter-controlled auto-migration - a very common setup. This is
> forward stepping of course, so is relatively harmless (backward is a pain).

My original reply was perhaps a bit... exclusionary. But I think the
point I was trying to make is still valid; if your VM is suspended for
250ms due to a migration (or CPU throttling, or ...) then it is
impossible to maintain a consistent stream of time events because
there isn't any code executing at all. Whether the clock stalls, or is
jumped forward 250ms, you still have an unavoidable problem as far as
time-keeping is concerned.

>>> Who knows what newer implementations like chrony or openntpd do!
>>
>> If they're doing something silly, then maybe you shouldn't use them.

I didn't intend it that way, but I can see how what I said could be
read in a hostile / defensive tone. Perhaps this would be a better
phrasing:

If chrony or openntpd are doing something sensible, then there
shouldn't be any serious issues with using them; if they're doing
something that seriously destabilizes the system clock, then you
probably shouldn't be using them, at least not if you want reliable
timekeeping. I'm not familiar enough with either of them to know which
case applies, so I didn't intend to come across as bashing chrony
and/or openntpd.

> Maybe "Twisted doesn't need a monotonic clock" is the right reply, but
> it would be wrong to base that on the assumpton that "ntpd doesn't step"
> - that's all I was trying to say.

I don't think anyone in this thread is arguing *against* implementing
this functionality; I think the point was just that this functionality
is only of critical importance under a limited range of circumstances,
as opposed to being something of urgent need for every Twisted-using
program that needs to schedule timed events.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] a question about monotonic clock

[Tristan Seligmann]

On Mon, Oct 29, 2012 at 12:05 AM, Phil Mayers  wrote:
> This depends on how you're running ntpd. If you have "-x" on the command
> line, yes - ntpd will not step.
>
> If not, there are circumstances it will step - clock diffs in excess of
> 128ms iirc?

If an offset of 128ms occurs at any time other than initial ntpd
startup (which will presumably occur at system startup), that means
you've either experienced a significant period of time without
connectivity to time servers[1], you have a hardware / kernel issue
that should be resolved, or some other software on the system is
messing with the clock. Aside from network issues, the other
possibilities are all serious issues that should be corrected, not
tolerated as a normal situation.

> Who knows what newer implementations like chrony or openntpd do!

If they're doing something silly, then maybe you shouldn't use them.

[1] Well, haha, just kidding; if this happens, then ntpd will remove
the servers as being unreachable, and terminate once they have all
been removed, thus resulting in the need to restart ntpd...
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] a question about monotonic clock

[Tristan Seligmann]

On Sun, Oct 28, 2012 at 5:22 PM, Christopher Armstrong
 wrote:
> I think that for *certain* uncommon types of applications, even the very
> minor skewing of ntp can cause problems, but I wonder if gelin yan has

I'm having trouble imagining such an application. In particular, if
the application is sensitive to such minor fluctuations in the time
source, I don't see how it could operate on commodity hardware at all;
such fluctuations are present regardless of whether ntp is slewing the
clock or not. You would need to use a separate hardware time source
that is more reliable, at which point ntp is essentially out of the
picture.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] implementing NAMES in IRC

[Tristan Seligmann]

On Wed, Sep 12, 2012 at 2:12 AM, Adrian Overbury  wrote:
> However it is entirely possible to sanely parse and store replies in a 
> reactionary system because the first component of an RPL_NAMREPLY message is 
> the name of the channel it applies to.
>
> You can log or quietly drop replies that aren't for channels you're currently 
> following, and use the others to build out some kind of structure that 
> maintains an active list of users in that channel and their status 
> (maintained through subsequent joins and parts).  Is this not so?  It doesn't 
> sound that complicated to me.

Handling RPL_NAMREPLY/RPL_ENDOFNAMES responses in order to update a
list of users is perfectly feasible (most user-interactive IRC clients
do something of this nature); the problem is directly associating a
response with a request. If you send NAMES #code, there are three
possibilities: 1) the ircd sends you a sequence of
RPL_NAMREPLY/RPL_ENDOFNAMES with the list of users, 2) you get an
error response, 3) nothing happens. While 3) is unlikely, there's no
particular reason an ircd couldn't behave that way (I don't
specifically know of one, but in general, the IRC protocol and ircds
are written and designed with primarily the interactive use case in
mind, not automated agents). However, the real fly in the ointment is
2); there is no way to know what errors might be returned in response
to a NAMES message, and many of those responses will not even mention
the channel name, thus giving you no way to recognize that the request
will never "complete". If you're keeping a deferred around to fire
with the response, then unless something else intervenes (a
cancellation timer?), the deferred will just hang around, which also
means keeping its callbacks and the objects they reference alive.

Thus, the problem is not with tracking the users in a channel in
general (although there are issues with tracking the channel modes of
those users...), but rather with specifically implementing an API like
names(channel) -> Deferred firing with a list of names. If you're
willing to accept an arbitrary timeout and use that as the only (or at
least the primary) mechanism of failure detection, as well as a few
other compromises (in the area of "overlapping" requests for the same
channel), it would be possible, I just don't feel that the base
IRCClient class is the right place to implement things like this, and
I'd also discourage designing IRC clients (whether they are bots or
user-interactive clients) in a way that requires such an API.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] implementing NAMES in IRC

[Tristan Seligmann]

On Tue, Sep 11, 2012 at 6:46 PM, Glyph  wrote:
> So... you're recommending exactly what twisted.words.im already does? :)

Well, yeah: "The only way to reliably use the NAMES command is the way
twisted.words.im.ircsupport [already does]" :)

> Keep in mind that we can assume to have control over outgoing traffic on our 
> own IRC connection.  If you've already issued one .names(), then another 
> outgoing one doesn't have to send an additional command and try to do weird 
> Deferred-stacking stuff.  It just has to delay sending the actual NAMES 
> request until the previous one has come back, or perhaps just fire both 
> Deferreds with a single response.

On the other hand, if you're writing code that doesn't need to match
requests and responses, you should be able to issue another NAMES
command before the previous one has completed (and bear in mind, if
you want to queue NAMES requests independently of other requests, the
only ways for it to complete will be 1. RPL_ENDOFNAMES and 2.
timeout). That's why I would prefer this not to be baked into the
lowest level of the IRC client API. My earlier responses were probably
worded too harshly; people *are* going to attempt to implement things
like this, no matter how much of a bad idea it might be, so going
LALALALA WE WON'T LET YOU won't improve things. On the other hand, the
compromises needed to do things this way probably shouldn't penalize
people who are doing it the "right" way (insofar as anything about IRC
can be said to be "right").
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] implementing NAMES in IRC

[Tristan Seligmann]

On Tue, Sep 11, 2012 at 3:43 PM,   wrote:
> This is the excuse that is always given for not implementing a new
> feature on `IRCClient`.  However, here's another equivalent way of
> stating the objection:
>
>   IRC is a terrible protocol and it is very difficult to implement a
>   method like `names` reliably, due to the various vague and obscure
>   corner cases presented.  Therefore, instead of Twisted tackling this
>   problem and providing a single (perhaps imperfect) implementation,
>   every single IRC application developer should instead rediscover this
>   sad reality for themselves and then implement their own uniquely buggy
>   version of this functionality.

Actually, my recommendation would be to avoid trying to implement
functionality of this nature in any application at all. The only way
to reliably use the NAMES command is the way
twisted.words.im.ircsupport and real IRC clients do: handle
RPL_NAMREPLY / RPL_ENDOFNAMES without regard to any NAMES command you
may or may not have issued, and then issue a NAMES command at certain
points without any regard for a response that may or may not be sent
to you by the IRC server. Having said that, I guess IRCClient could
handle the parsing of RPL_NAMREPLY / RPL_ENDOFNAMES messages into a
single list of names, which could then be delivered as a single event.

My main concern with most of the more complex implementation
strategies is that they impose a non-zero cost on users of IRCClient,
as well as encouraging the implementation of unreliable features; at
the very least, I think "anti-IRC" code like this should be an extra
layer on top of the basic IRC protocol implementation.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] implementing NAMES in IRC

[Tristan Seligmann]

On Tue, Sep 11, 2012 at 6:05 AM, Glyph  wrote:
> Such a bug may already exist - if you wouldn't mind, would you search for
> it, and if you can't find it, file a new one?

I don't know if there's an existing bug or not, but implementing a
names() method is problematic. The natural API would be something like
names('#foo') -> Deferred firing with a list of names in the channel.
The difficulty in implementing this comes from the fact that there are
two possible results from issuing a NAMES command on IRC: a serious of
zero or more RPL_NAMREPLY messages followed by an RPL_ENDOFNAMES
message, *or* any error message the IRC server feels like. There are a
number of partial workarounds for this, involving various combinations
of queues, timeouts, and unreliable detection of responses, but none
of them seem particularly satisfactory to me.

(On the other hand, a method that just sends NAMES #foo without any
response handling would be pretty straightforward to implement, maybe
that's what you meant?)
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] twisted server config: command line, environment or Axiom?

[Tristan Seligmann]

On Wed, Aug 8, 2012 at 3:58 PM, Laurens Van Houtven <_...@lvh.cc> wrote:
> (3) has the downside that it conflates user data with configuration data. I'm 
> not sure that's a good thing or not. It sounds very similar to axiomatic, 
> which I've heard of, seen, but never played with.

As exarkun mentions in his reply, you don't have to store the
configuration and user data in the same Axiom store. If you're
interested, the way "axiomatic start" works is that it locates all
IService powerups on the store you pass it (which would be the "site
store", in Mantissa), and attaches those to the application. I think
most of the interesting IService implementations are in Mantissa, not
Axiom, but axiomatic itself does not depend on Mantissa and of course
there's no reason you can't write your own IService powerups.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Logging observers and threads

[Tristan Seligmann]

When an error occurs in a database connection thread, adbapi invokes
log.err from that thread, which in turns causes log observers to be
invoked in this thread. Mantissa's TracebackCollector has a log
observer which logs items as Items in an Axiom store; this means that
the log observer tries to run SQLite queries in the wrong thread, and
explodes. However, I'm not sure whose fault this is; it seems there
are three possibilities:

1) log.err and log.msg should not be called from a non-reactor thread,
making this an adbapi bug.
2) twisted.python.log should not invoke log observers in a non-reactor
thread, making this a twisted.python.log bug.
3) log observers should expect to be inovked in non-reactor threads,
making this a Mantissa bug.

Can anyone give a definitive answer on this? The "nothing except
reactor.callFromThread is thread-safe" principle would suggest that 1)
is the case, but logging seems like it might be a special case.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Buildslave upgrades

[Tristan Seligmann]

I'd like to upgrade bot-idnar-debian64 from Debian lenny (5.0) to
squeeze (6.0). I think this host was previously kept back to test
Python 2.4 support on Debian, but it looks like the only thing it's
doing now is building pyopenssl, and I don't think that particularly
needs to be tested on lenny. I'll probably wait a week or two, and if
nobody objects, go ahead with the upgrade the next time I remember
about the host.

I'm also looking into upgrading the buildbot version on both of my
slaves (bot-idnar-*) to 0.8.5.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] accurate periodic call

[Tristan Seligmann]

On Tue, Feb 21, 2012 at 1:05 PM, Phil Mayers  wrote:
> I realise this is tricky to solve, but I'll note it's not impossible for
> really REALLY big clock skews to happen. For example: recently we had a
> server kernel panic and need a cold reboot. The machine booted and read
> it's time from the CMOS clock, which was way WAY out. A minute or two
> after the machine had booted, NTP slewed the clock back by months...

This is kind of a nitpick, but I think it's a fairly important one:
"slewing" the clock refers to a process where the clock frequency is
adjusted to make it run faster or slower in order to catch up or lose
a few seconds, without any discontinuities in the clock. This is a
relatively slow process, so "slewing" the clock by months would take
millennia; instead, beyond a certain threshold (I think a few
seconds?), ntp will always step the clock, not slew it, which is when
applications start running into difficulty as stepping introduces a
discontinuity in the clock.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python