From f499d6f0529e37237480f8dddf4e5f7cb698f98e Mon Sep 17 00:00:00 2001 From: "rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6" Date: Sun, 22 May 2016 19:58:33 +0000 Subject: [PATCH 1/6] Added a comment: Arrived in homebrew - Fix not working? --- ..._e5bc3c7cbe4af61868ac8163cd39c11a._comment | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment new file mode 100644 index 0000000000..d37bb993d0 --- /dev/null +++ b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment @@ -0,0 +1,40 @@ +[[!comment format=mdwn + username="rustikus@9db90d0c115a1825e2f1e5f15257ec1298a6c7b6" + nickname="rustikus" + subject="Arrived in homebrew - Fix not working?" + date="2016-05-22T19:58:32Z" + content=""" +The new version arrived in homebrew today. Thanks for adding the possibility to add GPG decrypt options. +I added --no-tty to annex.gnupg-decrypt-options but unfortunately it is not picked up by gpg. This is the log after removing --no-tty from .gnupg/gpg.conf and only adding it to .git/config. + +[2016-05-22 21:23:15.527812] Committer: Adding test.md +add /Users/xxx/annex/nvatom/test.md ok +[2016-05-22 21:23:15.72065] Committer: Committing changes to git +(recording state in git...) +[2016-05-22 21:23:15.808952] Pusher: Syncing with hidrive +gcrypt: Development version -- Repository format MAY CHANGE +gcrypt: Decrypting manifest +gpg: Signature made Sat May 21 21:12:40 2016 CEST using RSA key ID XXXXXXX +gpg: Good signature from \"Git Annex (Key for git annex encryption) \" [ultimate] +gcrypt: Encrypting to: -r XXXXXXXXXXXXX +gcrypt: Requesting manifest signature +[2016-05-22 21:23:20.955819] Committer: Adding test.md +add /Users/xxx/annex/nvatom/test.md ok +[2016-05-22 21:23:20.973532] Committer: Committing changes to git +(recording state in git...) +gpg: cannot open `/dev/tty': Device not configured + + user error (gpg2 [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2) +gpg: cannot open `/dev/tty': Device not configured + + user error (gpg2 [\"--quiet\",\"--trust-model\",\"always\",\"--decrypt\"] exited 2) +To gcrypt::rsync.hidrive.strato.com:/users/xxx/hidrive.git + b50d4d1..eb9ef83 master -> synced/master + 9504de9..ed2332b git-annex -> synced/git-annex +[2016-05-22 21:23:40.167619] Pusher: Syncing with hidrive + + +Unfortunately there is no upload happening but the status in the webapp is showing no error (everything green). Not sure if the error is actually coming from gcrypt and not git-annex? + + +"""]] From da4d66794010bdf6d5e4578c98a1480d3e110db7 Mon Sep 17 00:00:00 2001 From: ilovezfs Date: Mon, 23 May 2016 06:26:59 +0000 Subject: [PATCH 2/6] Patches for GHC 8 and for cabal configure --- doc/bugs/ghc_8.0.1_build_fixes.mdwn | 39 +++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 doc/bugs/ghc_8.0.1_build_fixes.mdwn diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn new file mode 100644 index 0000000000..69674216a2 --- /dev/null +++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn @@ -0,0 +1,39 @@ +git-annex needs tweaks to build with ghc 8.0.1 and to run "cabal configure" + +Homebrew core only supports the latest stable version of each formula, so the release of ghc 8.0.1, which is now the latest stable version of ghc, will render git-annex unbuildable without patching. + +This affects both HEAD and 6.20160511 + +GHC 8 compatibility: +I have two patches to get it working. 6.20160511 passes all the tests in the "git annex test" suite built against GHC 8.0.1 with the patches. HEAD fails several of the tests but that seems to have nothing to do with GHC 8.0.1 specifically, and I'm sure you're already aware of these test suite issues with current HEAD. + +The first patch for GHC 8 is a cabal change. +(buildpath/"cabal.config").write("allow-newer: base,time,transformers\n") + +The second patch is a code change. + +GHC 8.0.1 complains about these lines: https://github.com/joeyh/git-annex/blob/08625c5a89b14415c1c7fef518f27b07b0899c24/Remote/Bup.hs#L136-L141 + +The variable "runner" fails to monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this): + +[[!format haskell """ + if quiet + then liftIO $ feedWithQuietOutput createProcessSuccess cmd $ \h -> do + meteredWrite p h b + return True + else liftIO $ withHandle StdinHandle createProcessSuccess cmd $ \h -> do + meteredWrite p h b + return True +"""]] + +Making cabal configure work: + +We run "cabal configure --flags=…" to verify the build will successfully enable the expected features, but this fails without addition custom setup dependencies. This affects the git-version of git annex which has the custom setup section (both 6.20160511 and HEAD), but doesn't affect the Hackage 6.20160511 download because it has the custom-setup stanza removed. + +In order to run configure, I make the following change: + +inreplace "git-annex.cabal", + "Setup-Depends: base (>= 4.5), hslogger, MissingH", + "Setup-Depends: base (>= 4.5), hslogger, MissingH, unix-compat, process, unix, filepath, exceptions, bytestring, directory, IfElse, data-default, Cabal" +end + From 724fe1a3d217805b6793450908fa23f021616251 Mon Sep 17 00:00:00 2001 From: ilovezfs Date: Mon, 23 May 2016 06:27:46 +0000 Subject: [PATCH 3/6] --- doc/bugs/ghc_8.0.1_build_fixes.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn index 69674216a2..daa9243188 100644 --- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn +++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn @@ -14,7 +14,7 @@ The second patch is a code change. GHC 8.0.1 complains about these lines: https://github.com/joeyh/git-annex/blob/08625c5a89b14415c1c7fef518f27b07b0899c24/Remote/Bup.hs#L136-L141 -The variable "runner" fails to monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this): +The variable "runner" fails to be monomorphic, so I'm using the following hack (though I'm sure there's a better way to fix this): [[!format haskell """ if quiet From 07383ae9eac47676030a280c40143df36f2aa7bb Mon Sep 17 00:00:00 2001 From: ilovezfs Date: Mon, 23 May 2016 06:31:12 +0000 Subject: [PATCH 4/6] --- doc/bugs/ghc_8.0.1_build_fixes.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn index daa9243188..877010478c 100644 --- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn +++ b/doc/bugs/ghc_8.0.1_build_fixes.mdwn @@ -32,8 +32,10 @@ We run "cabal configure --flags=…" to verify the build will successfully enabl In order to run configure, I make the following change: +[[!format text """ inreplace "git-annex.cabal", "Setup-Depends: base (>= 4.5), hslogger, MissingH", "Setup-Depends: base (>= 4.5), hslogger, MissingH, unix-compat, process, unix, filepath, exceptions, bytestring, directory, IfElse, data-default, Cabal" end +"""]] From fbb955c7f24ce6dcb4165fcafc1acf86eac2f6b4 Mon Sep 17 00:00:00 2001 From: xloem Date: Mon, 23 May 2016 10:55:54 +0000 Subject: [PATCH 5/6] --- ...valid_object__34___errors_cropping_up.mdwn | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn new file mode 100644 index 0000000000..35adfb2d65 --- /dev/null +++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn @@ -0,0 +1,90 @@ +### Please describe the problem. +In my repo network, multiple repos are cropping up with an "invalid object" error. The object in question changes and appears to be from git-annex's hidden branch. + +### What steps will reproduce the problem? +This is happening after I add a mess of new files and sync, within a couple times of doing this, after a day or so. + +### What version of git-annex are you using? On what operating system? +6.20160518-g766728c on linux + +### Please provide any additional information below. + +[[!format sh """ +# Example error, file in question will change + (recording state in git...) + error: invalid object 100644 d547f60ac6c53f8bf38999d93ce954e3dfca1656 for + '051/0b4/SHA3_512-s12447441634--b84ff2ead694b9d355d8deb4eae620b5979f0127f127718d53d02cd32f1020fba45f1e63723484462beb10110328dab29d875ea1788f949ce541640603fa73c0.log' + fatal: git-write-tree: error building trees + git-annex: failed to read sha from git write-tree +# End of transcript or log. + +# log of attempting to determine the issue yesterday +2016-05-22 + +Issue history: +Original annex started being unable to finish commit. +Second annex, I cloned and copied objects folder over. Soon, same issue. +Third annex, cloned from elsewhere, use git annex get to get objects from +broken repo. Same issue developed. +Fourth annex, cloned from elsewhere, was able to commit successfully +prior to adding objects from broken repo. +Some object in the broken repo seems to be causing this issue somehow. + +Plan to resolve: +- copy all objects over again. verify that issue immediately develops. + + I expect the issue will trigger when I add a set of objects with litelog. + So I could narrow it either by narrowing the objects I add with litelog, + or by narrowing the object I copy from the broken repo. + + I'll narrow the issue between the two, first. + +annex: used to be annex.2, busted +annex.3: third repository, busted, holds objects +annex.4: + 1. cloned from delta + 2. added logs, no issue + 3. 10:24:24 EDT rsync --delete-during'd objects in from annex.3 + 4. 10:25:10 EDT added small test file, sync'd with delta fine + 5. 2016-05-22 10:27:38 + I ran fetchall but ran by root by mistake. + files were added with wrong permissions + fixed permissions. only two files were cpied, voicerecorder and muse. + sync works fine.' + 6. ran fetchall (as root) again, got 4 sensorium files + 7. add and sync seems to work fine. + So now this repository is functioning with additional objects copied into + its annex folder. It must have been something else which caused the issue + on the other repo I initialized this way. + 8. I foolishly tried to git annex add the alphabetically first object from + the annex/objects folder to get it annex's logs. It failed when trying to + _delete_ it to replace it with a link to itself, luckily it was not writable. + + I'll try using this repo - 2016-05-22 10:36:24 EDT + + I'll add the remotes one at a time and sync with them, adding litelog after + each one. + + 9. 2016-05-23 00:08 EDT + Issue reoccurred uploading data from phone. Was a larger block of data. + First fetched + then added + then copied to delta + issue showed at end of copy to delta + + perhaps the issue resides on delta ??? but we synced to delta fine before + the issue must happen over time while I am away from the computer + or respond to a large amount of logs being uploaded + or it could have happened as a result of my work on the nested repo + 10. 2016-05-23 00:10:15 EDT + $ git annex copy --to=gitlab + 06:55 EDT + $ git annex sync gitlab + both commands ran without issue + delta also fsck'd fine + +"""]] + +### 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) +Very stable. Still excited. + From 304c5ef17d8c1f8b7e5ff040c88b3263780316ac Mon Sep 17 00:00:00 2001 From: xloem Date: Mon, 23 May 2016 11:01:25 +0000 Subject: [PATCH 6/6] --- doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn index 35adfb2d65..5a06bf0920 100644 --- a/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn +++ b/doc/bugs/__34__invalid_object__34___errors_cropping_up.mdwn @@ -82,7 +82,8 @@ annex.4: $ git annex sync gitlab both commands ran without issue delta also fsck'd fine - + 11. 2016-05-23 07:01 EDT + local repo fsck'd fine """]] ### 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)