From 5fb7b87bf09de42d84f62a6b309bf1fd8701cf53 Mon Sep 17 00:00:00 2001 From: "0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" <0xloem@web> Date: Sun, 11 Dec 2016 00:26:42 +0000 Subject: [PATCH 1/4] Added a comment --- .../comment_3_886756620cdbb6ab838269fe2f00db4e._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment new file mode 100644 index 0000000000..b5316c0de6 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment @@ -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. +"""]] From f58b13435ebe20c518031c99a0d019cc2ab32958 Mon Sep 17 00:00:00 2001 From: "0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" <0xloem@web> Date: Sun, 11 Dec 2016 00:59:50 +0000 Subject: [PATCH 2/4] Added a comment: Verification --- .../comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment new file mode 100644 index 0000000000..801f702235 --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment @@ -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. +"""]] From 8283b1c924a6ea3b97b7e666d9a5c0c262019896 Mon Sep 17 00:00:00 2001 From: "0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" <0xloem@web> Date: Sun, 11 Dec 2016 13:26:29 +0000 Subject: [PATCH 3/4] Added a comment: Nope a Fluke --- .../comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment new file mode 100644 index 0000000000..9dec23b00d --- /dev/null +++ b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment @@ -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. +"""]] From c3ab3c6682d2df96fad8ff476fa89b3b5777c626 Mon Sep 17 00:00:00 2001 From: "grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f" Date: Sun, 11 Dec 2016 17:46:03 +0000 Subject: [PATCH 4/4] --- ...__breaks_user-specified_IgnoreUnknown.mdwn | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn diff --git a/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn new file mode 100644 index 0000000000..b910ac4087 --- /dev/null +++ b/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn @@ -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.