summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn6
-rw-r--r--doc/bugs/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn30
-rw-r--r--doc/bugs/can__39__t_run_the_assistant_from_the_command_line_anymore__63__.mdwn7
3 files changed, 35 insertions, 8 deletions
diff --git a/doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn b/doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn
index ad8d18fcf..1b3879e63 100644
--- a/doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn
+++ b/doc/bugs/assistant___40__OS_X_Lion__41___-___34__too_many_open_files__34___error.mdwn
@@ -24,3 +24,9 @@ What version of git-annex are you using? On what operating system?
Please provide any additional information below.
I imagine I could avoid this error by using the "ulimit -n" command to increase number of files in a shell session and then running assistant manually, so this is really only a bug report about the bundled application.
+
+> This seems to be caused by Command.Add.lockdown not closing the
+> temporary file handle, so when called in a mapM by the committer
+> thread when there are a lot of files, it could build up a lot of
+> open handles before later GC closes them. Added a manual close,
+> so I think this is [[done]]. --[[Joey]]
diff --git a/doc/bugs/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn b/doc/bugs/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
index 68e418023..383410704 100644
--- a/doc/bugs/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
+++ b/doc/bugs/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
@@ -1,6 +1,12 @@
What steps will reproduce the problem?
-Using the assistant, create an SSH remote. Try to use an alias as the name of the remote (e.g. I have a server which I have aliased to "homeworld" in my .ssh/config. When I'm at home, that is an alias for 192.168.1.253. When I'm not at home, I edit .ssh/config so that "homeworld" becomes an alias for a hostname at no-ip.com.) Despite the fact that "homeworld" is a viable ssh target because of the alias, the assistant doesn't recognize it as a valid host to ssh to.
+Using the assistant, create an SSH remote. Try to use an alias as the name
+of the remote (e.g. I have a server which I have aliased to "homeworld" in
+my .ssh/config. When I'm at home, that is an alias for 192.168.1.253.
+When I'm not at home, I edit .ssh/config so that "homeworld" becomes an
+alias for a hostname at no-ip.com.) Despite the fact that "homeworld" is a
+viable ssh target because of the alias, the assistant doesn't recognize it
+as a valid host to ssh to.
I had trouble with an ip address the first time I tried it but just tried it again and it worked fine, so please disregard that part of the title of this bug report.
@@ -18,5 +24,23 @@ What version of git-annex are you using? On what operating system?
Please provide any additional information below.
-I realize this is kind of a power user whine. Using an ssh alias which does not correspond to an actual resolvable hostname (and cannot, because it's supposed to be a layer of indirection over the hostname) is not an everyday problem for an average user.
-
+I realize this is kind of a power user whine. Using an ssh alias which
+does not correspond to an actual resolvable hostname (and cannot, because
+it's supposed to be a layer of indirection over the hostname) is not an
+everyday problem for an average user.
+
+> The assistant tries to resolve the hostname explicitly
+> to catch user's typos, and also expands it to a FQDN, to make
+> it more likely to be able to reach the host when roaming to other
+> networks.
+>
+> Also, the assistant sets up it *own* .ssh/config hostname alias,
+> in order to make it use the special ssh key that it generates for the host.
+> So that is not compatable with using a ssh host alias you've set up.
+> Even if it knew about your alias, it would set up a new hostname alias, and
+> whatever machinery you have to update the alias would not work.
+>
+> You can, of course, add git remotes using any ssh alias you like, by
+> hand, and restart the assistant and it will use them. --[[Joey]]
+
+[[!tag /design/assistant]]
diff --git a/doc/bugs/can__39__t_run_the_assistant_from_the_command_line_anymore__63__.mdwn b/doc/bugs/can__39__t_run_the_assistant_from_the_command_line_anymore__63__.mdwn
index 49a252001..58828e8ca 100644
--- a/doc/bugs/can__39__t_run_the_assistant_from_the_command_line_anymore__63__.mdwn
+++ b/doc/bugs/can__39__t_run_the_assistant_from_the_command_line_anymore__63__.mdwn
@@ -27,8 +27,5 @@ OS X Lion.
Please provide any additional information below.
-
-> You need to install the haskell hfsevents library to build on OSX now.
-> This is a recent change documented in the release notes, but
-> just running `cabal install` should install it automatically. [[done]]
-> --[[Joey]]
+> The cabal file had a typo that prevented it from using hfsevents. I'm
+> uploading a fix now. [[done]] --[[Joey]]