freestorm77 [Sun, 2 Jan 2011 03:42:14 +0000 (19:42 -0800)]
status_web_pages_review.darcs.patch
I make some changes on status web pages
status.xhtml:
- Delete unused webform_css link
- Align tables on the left
tahoe-css:
- Do some minor changes on code synthax
- changes table.status-download-events style to look like other tables
status.py:
- Align table on the left
- Changes table header
- Add heading tags
- Modify google api graph: add image border, calculate height to feet data
storage: use fileutil's version of get_disk_stats() and get_available_space(), use mockery/fakery in tests, enable large share test on platforms with sparse files and if > 4 GiB of disk space is currently available
david-sarah [Sun, 12 Dec 2010 16:58:00 +0000 (08:58 -0800)]
docs/frontends/CLI.rst: changes to formatting (mainly putting commands and filenames in monospace), and to command syntax to reflect that DIRCAP/... is accepted. Clarify the syntax of 'tahoe put' and other minor corrections. Tahoe -> Tahoe-LAFS.
david-sarah [Tue, 30 Nov 2010 00:21:45 +0000 (16:21 -0800)]
scripts/cli.py: remove the disclaimer in the help for 'tahoe cp' that it does not handle non-ASCII filenames well. (At least, we intend to handle them.)
Brian Warner [Sat, 27 Nov 2010 08:38:09 +0000 (00:38 -0800)]
remove --multiple/-m option from all CLI commands: closes #1262
I personally used "tahoe start/restart -m ../MY-TESTNET/node*" all the time,
to spin up or update a local testgrid while iterating over new code. However,
with the recent switch from "subprocess.Popen(/bin/twistd)" to "import and
call twistd.run()" in scripts/startstop_node.py (yay fewer processes!),
"start -m" broke, and fixing it requires os.fork, which is unavailable on
windows (boo windows!). And I was probably the only one using -m. So in the
interests of uniformity among platforms and simpler code (yay negative code
days!), we're just removing -m from everything. I will start using a little
shell script or something to simulate the removed functionality.
This patch also cleans up CLI-function calling a bit: get the basedir from
the config dict (instead of sometimes from a separate argument), and always
return a numeric exit code.
Brian Warner [Sat, 27 Nov 2010 00:44:11 +0000 (16:44 -0800)]
Revert previous commit: there's an ugly corner-case on windows that fails tests.
Specifically, test_runner.CreateNode.test_client failed, because the
os.fork-is-present test decided that --multiple should not be allowed on
windows, even though --multiple works just fine for 'tahoe create-client'.
The only restriction on --multiple is for 'tahoe start' and 'tahoe restart'.
This needs a different approach, probably by cleaning up BasedirMixin. We
should only be withholding --multiple on windows for "start" and
"restart". (we should continue withholding --multiple on all platforms for
"run").
Brian Warner [Fri, 26 Nov 2010 22:45:38 +0000 (14:45 -0800)]
startstop_node.py: fix "tahoe start -m" by forking before non-final targets
* don't advertise -m flag on tahoe start/restart/run unless os.fork is
available (i.e. windows)
* test_runner.py: add test to exercise "start/stop/restart -m"
david-sarah [Sun, 21 Nov 2010 23:39:57 +0000 (15:39 -0800)]
misc/build_helpers/run_trial.py: allow the module argument to specify a leaf module rather than a directory. This fixes false positive wrong-source errors in the test-from-prefixdir step when we test only allmydata.test.test_runner.
bundled zetuptoolz: prefer locally-available distributions over remotely-downloaded distributions above all
This fixes #1233. Actually the previous patches—[20101103034740-93fa1-9df33552497282eb72a84e5b434d035974bf2dbb] and [20101117080828-92b7f-dc0239f30b26e7e5d40b228114fb399c1e190ec5]—fixed it, but with them zetuptoolz would download a higher-numbered distribution from the net instead of using the locally-available (fake) pycryptopp-0.5.24, thus preventing the tests from passing. This patch changes that behavior (which is an improvement in its own right) and also fixes a bug in the tests.
bundled zetuptoolz: choose a binary dist in preference to a source dist, even if the latter is newer, as long as the former satisfies the requirement
patch by David-Sarah, tiny bugfix to patch by Zooko
ref: #1233
tests: test-with-fake-dists: clean up *just* the pycryptopp-0.5.24 eggs when exiting
also don't set the PATH and PYTHONPATH, which is unnecessary for this test
also wrap the behavior in a couple of functions, just for tidiness
tests: test-with-fake-dists.py has the side-effect of injecting a fake package into ./support, so after that test rm -rf ./support, and likewise with ./pycryptopp*.egg.
setup: when testing, set the __requires__ as precisely as possible even if the version of this particular build of Tahoe-LAFS is not yet known (addresses test failure ref #1190, #1233)
tests: change test-with-fake-pkg to exercise a test suite which actually requires pycryptopp, thus making this a better test which can detect ill-installed pycryptopp
setup: remove --multi-version
It causes copious scary-looking warning messages and I'm no longer sure if it was actually needed to accomplish our goals ref #530.
setup: include pycryptopp in the set of Python packages described in the show-tool-versions step (for cross-referencing with the test-with-fake-dists step, which behaves differently depending on what version(s) of pycryptopp are already present before it starts)
setup: upgrade bundled darcsver from 1.6.3 to 1.7.0
ref #1259, we're going to use its 'versionfiles' setup() keyword argument to specify where to write the version file.
Remember, we have to bundle darcsver to work-around http://bitbucket.org/tarek/distribute/issue/55/revision-control-plugin-automatically-installed-as-a-build-dependency-is-not-present-when-another-build-dependency-is-being
setup: remove separate licensing declaration
Whenever Free Software/Open Source legal folks are examining the Tahoe-LAFS source code, it seems like there has to be a discussion and documentation about every single licensing declaration. Since this one is (was) permissive, then you would think it could be avoided, but I'm not betting on it. We would probably have to install a copy of the MIT licence into every one of the "copyright" files under the debian/ subdirectory, for example. So: let's just let hashbasedsig.py be licensed the same way as the rest of Tahoe-LAFS.
projects / tahoe-lafs / tahoe-lafs.git / log