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

This commit is contained in:
Joey Hess 2016-05-23 10:50:18 -04:00
commit 464f06f5c6
Failed to extract signature
3 changed files with 172 additions and 0 deletions

View file

@ -0,0 +1,91 @@
### 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
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)
Very stable. Still excited.

View file

@ -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) <xxx@xxx.de>\" [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?
"""]]

View file

@ -0,0 +1,41 @@
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 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
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:
[[!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
"""]]