Process directories unconditionally.
Also pass overwrite=False and suppress ExistingChildError when creating a
subdirectory, to avoid orphaning any existing directory.
Brian Warner [Tue, 22 Sep 2015 23:37:12 +0000 (16:37 -0700)]
introweb: fix connection hints for server announcements
A long time ago, the introducer's status web page would show the
advertised IP addresses for all published services, by parsing their
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 (the column
has been empty this whole time).
This removes the "Advertised IPs" column from the Service Announcements
table. Instead, the service's full connection hints (not just the IP
address) is displayed in a tooltip/popup on the "Announced" timestamp
column.
The code that pulls these connection hints is now tolerant of all three
foolscap styles:
* foolscap<=0.6.4 : tuples of ("ipv4",host,port)
* 0.6.5 .. 0.8.0 : tuples of ("tcp",host,port)
* foolscap>=0.9.0 : strings
Brian Warner [Tue, 22 Sep 2015 23:34:50 +0000 (16:34 -0700)]
remove "announcement_distinct_hosts" from introweb JSON
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.
Brian Warner [Tue, 22 Sep 2015 23:29:34 +0000 (16:29 -0700)]
introducer: stop tracking hints for subscribed clients
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.
Brian Warner [Tue, 22 Sep 2015 19:10:15 +0000 (12:10 -0700)]
travis: use 'git fetch' to deepen, not 'git pull'
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.
Avoid spurious errors when an imported version is consistent with pkg_resources
but not parseable; also improve related error reporting. fixes ticket:2499
Brian Warner [Tue, 28 Jul 2015 18:02:17 +0000 (11:02 -0700)]
Merge branch 'sdmf-partial-2'
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.
Don't show scary diagnostic warnings from --version[-and-path]
if the only problem is that extra packages are found by pkg_resources.
fixes ticket:2436
Brian Warner [Mon, 15 Jun 2015 21:40:19 +0000 (14:40 -0700)]
Dockerfile: git-pull more history, to get a version string
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.
Brian Warner [Sun, 7 Jun 2015 21:30:58 +0000 (14:30 -0700)]
move Dockerfile back to root. DockerHub can't handle it elsewhere.
It looks like DockerHub's automated builds only have access to the
subtree of the source checkout at+below the Dockerfile. Putting the
Dockerfile in misc/build_helpers/ meant that the build process only had
access to misc/build_helpers/, not the full source tree.
Daira Hopwood [Sat, 6 Jun 2015 21:45:42 +0000 (22:45 +0100)]
Magic Folder design doc: rename "parent DMD" to "collective directory", and don't assume it is mutable.
(An immutable collective directory could be interesting for some use cases, and is no more difficult to support.)
projects / tahoe-lafs / tahoe-lafs.git / log