The machine-parseable JSON output for the introducer status web page
used to include a key named "announcement_distinct_hosts", which counted
the number of distinct IP addresses advertised by all connected storage
servers. This hasn't worked since Aug-2014 when foolscap-0.6.5 change
the internal hints format.
This removes that field.
A long time ago, the introducer's status web page would show the
advertised IP addresses for all subscribers, by parsing their
RemoteReference's FURL's connection hints. This hasn't worked since
about 12-Aug-2014 when foolscap-0.6.5 changed the internal format of
these hints.
This removes the feature: we no longer attempt to show advertised IP
addresses of subscribed clients. It also removes the code that looked
inside foolscap internals for this information.
Travis builds of branches (i.e. pull-requests) were testing the wrong
thing, because the 'git pull' was causing current trunk to be
auto-merged. At least that's what seemed to break
https://travis-ci.org/tahoe-lafs/tahoe-lafs/jobs/81517826 : it hung
forever waiting for a commit message to be entered.
Also add "sudo: false" to use travis containers (faster) instead of new
VMs. We only use pip to install dependencies, not apt, so we don't need
root.
The previous version would incorrectly add to the output of
get_package_versions_string each time it was called.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This cleans up the mutable-retrieve code a bit, and should fix some
corner cases where an offset/size combinations that reads the last byte
of the file (but not the first) could cause an assert to fire, making
the download hang. Should address ticket:2459 and ticket:2462.
This should tolerate offset/size combinations that read the last byte of
the file, something which was broken before. It quits early in the case
of zero-byte reads, to simplify the resulting "which segments do I need"
logic. Probably addresses ticket:2459.
The Docker build process seems to use 'git pull --depth=1', which
doesn't fetch enough history to see a tag, which means tahoe's setup.py
can't compute a version (then 'tahoe --version' reports "unknown").
Pulling a hundred commits should be enough to see a tag without making
the resulting image unnecessarily large. If we go more than 100 commits
between tags, we'll need to increase this, or come up with something
smarter.
