mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2016-12-12 13:28:50 -04:00
commit 63da8d88bb
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
4 changed files with 53 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn Normal file
View file

@ -0,0 +1,26 @@
### Please describe the problem.
The OpenSSH client parses configuration in a "first match wins" manner, and this also applies to `IgnoreUnknown`. This means that when git-annex's `Include ~/.ssh/config` is processed, any user-specified `IgnoreUnknown` setting in the global configuration will be ignored because it has already been set. As a result, every time git-annex runs ssh, it immediately exits with an error:
[[!format text """
drop vol3 somefile.mkv (locking vol5...) (lockcontent failed) (checking vol5...)
/home/grawity/.ssh/config: line 217: Bad configuration option: gssapikeyexchange
/home/grawity/.ssh/config: terminating, 1 bad configuration options
failed
"""]]
To be fair, this might be an OpenSSH bug (IgnoreUnknown ought to be merged), but it seems git-annex is triggering it unnecessarily.
### What steps will reproduce the problem?
1. In `~/.ssh/config`, have some unrecognized options (e.g. `GSSAPIKeyExchange`) and a corresponding `IgnoreUnknown`.
2. Try to use a git-annex feature which directly invokes ssh, e.g. get or drop.
### What version of git-annex are you using? On what operating system?
6.20161210 on Arch, but I think this was introduced in a 201611* release.
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, it's been taking care of my archives for nearly a year.

9
doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730"
nickname="0xloem"
avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
subject="comment 3"
date="2016-12-11T00:26:41Z"
content="""
Thank you so much for the prompt response. My system wouldn't shut down cleanly after this, either, so there may have been something else screwy going on. Still, I'll be using the build for ancient kernels exclusively for the near future. Thank you.
"""]]

9
doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730"
nickname="0xloem"
avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
subject="Verification"
date="2016-12-11T00:59:50Z"
content="""
I saw the new comment on the download page and tried running `git annex test`. I can confirm that `git annex test` eventually segfaults using the normal build on my system, whereas it passes successfully using the 'ancient kernels' build. The version strings output for the two are identical.
"""]]

9
doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730"
nickname="0xloem"
avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b"
subject="Nope a Fluke"
date="2016-12-11T13:26:29Z"
content="""
Apologies. I can't reproduce the segfault running the tests again. The corruption and crashing seems to have been some horrifying fluke.
"""]]