Meejah pointed out that new users might think the encoding parameters
are fixed, something you must pick correctly when you first set up the
node, and then are never allowed to change again, which is kind of
anxiety-inducing. This updates the comment to explain that the encoding
is stored in each filecap, and the tahoe.cfg values are only used for
newly-uploaded files.
Re-indent the blocks for consistency, improve the explanation of
?filename=foo.jpg to match it's new location, use new-style reference
for urls-and-utf8 footnote.
• mark "/file/" as a synonym for "/named/" to be deprecated (fixes#1903)
• move the options common to all three forms to the bottom and dedent them
• name the protocol/format as "LAFS" and the implementation/client "Tahoe"
• reflow (with fill-column 77)
I set up a raspberry pi buildslave (which, on the "raspbian jesse"
image, uses a 32-bit python, and perhaps a 32-bit kernel too). It fails
test_util.TimeFormat.test_format_time_y2038 with a ValueError inside the
call to time.gmtime(). The test was looking for the equality check to
fail instead. I think catching ValueError is the more-correct way to
detect a system with a 32-bit time type.
One of the buildslaves (Ubuntu wily 15.10) has a very old pip-1.5.6,
which doesn't know how to "pip install" a filepath+extra (like
".[test]") unless --editable is also used.
It's convenient to have --editable set anyways (so you can do subsequent
narrow testing without re-running tox, by running ".tox/py27/bin/trial
TESTCASE" or use .tox/py27/bin/activate), so changing the dependency
from ".[test]" to "--editable=.[test]" is the easiest way to work around
that older buildslave. (I could also have upgraded the buildslave to use
a newer pip, but 15.10 is pretty recent and other people will probably
hit this too, so this way it's fixed for everybody).
refs ticket:2776
With the new Foolscap-0.11.0 (which changed the way connections are
established), I'm seeing DirtyReactorErrors getting thrown by
allmydata.test.test_system.SystemTest.test_filesystem_with_cli_in_subprocess
, on a host that has three IP addresses (one is 127.0.0.1, two is wifi,
three is a VPN). The test itself is getting skipped because bin/tahoe
isn't in the expected place, but by that point, the nodes have already
been launched and have established connections over one of the three
hints (probably 127.0.0.1). The test terminates so quickly that the
connections to the other two addresses have not finished being
abandoned. The extra stall seems to give Foolscap enough time to reap
the cancelled connections and makes the DRT go away.
I think an offline test, or maybe one with a single external IP address,
wouldn't hit this case.
Arbitrary stalls are never very satisfactory, of course. Usually there
is some threshold delay value, below which it fails reliably, above
which it works on my own machine (for now). This one is weird: the
threshold seems to be below the resolution of the system clock. Stalling
for one nanosecond was enough to fix the problem, but using a simple
fireEventually() didn't work.
This little-used debugging feature allowed you to SSH or Telnet "into" a
Tahoe node, and get an interactive Read-Eval-Print-Loop (REPL) that
executed inside the context of the running process. The SSH
authentication code used a deprecated feature of Twisted, this code had
no unit-test coverage, and I haven't personally used it in at least 6
years (despite writing it in the first place). Time to go.
Also experiment with a Twisted-style "topfiles/" directory of NEWS
fragments. The idea is that we require all user-visible changes to
include a file or two (named as $TICKETNUM.$TYPE), and then run a script
to generate NEWS during the release process, instead of having a human
scan the commit logs and summarize the changes long after they landed.
Closes ticket:2367
Note that Twisted doesn't do anything like Versioneer, so this will
generally show e.g. "Twisted-16.1.0" for the entire interval between
16.1.0 and 16.2.0.
Rewrote in Twisted, which lets us read/scan/print all log lines in
realtime. The output is now correctly interleaved (as well as
maintaining the stdout-vs-stderr of each message). The renamed
--warnings= logfile records all relevant lines from *both* stdout and
stderr (i.e. any that includes "DeprecationWarning"), which handles a
change (perhaps in recent Twisteds?) that emits these warnings on stdout
instead of stderr.
This runs trial against the latest (git) Twisted and Foolscap, to give
us an early warning about anything we're currently doing that will
become deprecated in their next releases.
Tox doesn't run shell pipelines, and is unhappy about running tools that
it didn't install itself (including non-python things like "make"). So
this adds misc/build_helpers/run-deprecations.py, a python script that
runs a given command (i.e. trial) and writes stdout into a separate file
where the buildbot can see it, and counts the "DeprecationWarning" lines
from the file to decide the returncode.
This ought to improve the status display on the buildbot "test
deprecations" step.
The udpprot.transport.connect() fails if we don't have a network
connection, but the port is still listening, so trial gives us a
DirtyReactorError. The fix is a "finally:" which does
port.stopListening() even in this case.
Closes ticket:2769
We only really need "Twisted >= 13.0.0", but we must add "[tls]" because
otherwise pip won't install it when Foolscap asks for it later, and we
need ">= 15.1.0" because that's the first version that provided "[tls]".
Fixes ticket:2760.
