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

This commit is contained in:
Joey Hess 2014-03-26 12:58:21 -04:00
commit 2370a2a85d
6 changed files with 174 additions and 0 deletions

View file

@ -0,0 +1,23 @@
### Please describe the problem.
The watcher crashes.
I only need to restart the thread in the pop-up to get everything to work again, but I'm reporting just in case that this issue has any other implications.
### What steps will reproduce the problem?
I open the webapp and in the minutes before it starts syncing (syncing is enabled) I disable it (clicking in the 'syncing enabled' text).
This produces a crash every time.
### What version of git-annex are you using? On what operating system?
5.20140320 in Debian sid and testing
### Please provide any additional information below.
This is all I can see in the logs
[[!format sh """
Watcher crashed: PauseWatcher
[2014-03-26 08:54:57 CET] Watcher: warning Watcher crashed: PauseWatcher
"""]]

View file

@ -0,0 +1,45 @@
### Please describe the problem.
Just a small patch to Tahoe.hs which fixes "initremote repo
type=thaoe" when using the latest tahoe-lafs release available for
download.
I'm trying to add an attachment here but the UI says "prohibited by
allowed_attachments (user is not an admin)" so please have a look also
here: <https://github.com/joeyh/git-annex/pull/21>
### What steps will reproduce the problem?
1. Install latest tahoe-lafs
2. run "TAHOE_FURL=... git annex initremote repo type=tahoe"
### What version of git-annex are you using? On what operating system?
OS: Debian Sid updated to latest packages
git-annex: version 5.20140306
### Please provide any additional information below.
I would like to add few things if i'm able (it's my first time for
haskell, and I'm a bit lost as now):
1. add an optional parameter or envvar for a root dir cap and switch
from storing anonymous files to saving a tree of dirs and files
(much like the webdav back-end) so that i can later renew the
leases on the files to prevent tahoe's garbage collection process
expiration (for details see
<https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/garbage-collection.rst#client-side-renewal>)
The poor man way to that without touching git-annex is to in some
way collect the caps of the files from annex metadatas and to link
them to a directory, which where i can then run "tahoe deep-check
--add-lease" on;
2. add convergence as an optional parameter. As of now many of the
files that i'm willing to manage with git-annex are already on my
grid, mostly because i've used tahoe's backup command to upload
them in the past. By using the same convergence value that i've
already setup on my other tahoe client installation i would be able
to save much time and space by avoiding duplicates.
Do you have any good pointers to pieces code of git-annex that i can
read and hack to try to implement this or any other suggestion?

View file

@ -0,0 +1,86 @@
As per topic, `git annex forget --drop-dead --force` does not behave as expected. Instead of getting rid of dead repositories, it actually revives them.
I messed up the initial setup of the S3 special remote and instead of risking manual intervention, I figured it would be cleanest to nuke the old special remotes, using a new one instead.
And yes, I should have used a test repo :(
As this is apu.debconf.org, you could get access to the repo if that helps.
[[!format sh """
richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
070cff8a-6302-4aa7-a63c-3fdd34e598a2 -- amazon_s3_us_east--SHA512E
0bae683f-bede-43dd-a815-c4f8fb6db32d -- aws_s3_us_east--SHA512E
92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
untrusted repositories: 0
transfers in progress: none
available local disk space: 136.3 gigabytes (+1 megabyte reserved)
local annex keys: 4392
local annex size: 884.64 gigabytes
annexed files in working tree: 4628
size of annexed files in working tree: 885.68 gigabytes
bloom filter size: 16 mebibytes (0.9% full)
backend usage:
SHA512E: 9020
richih@apu (git)-[master] /srv/video/video.debian.net % git annex dead 070cff8a-6302-4aa7-a63c-3fdd34e598a2
dead 070cff8a-6302-4aa7-a63c-3fdd34e598a2 ok
(Recording state in git...)
richih@apu (git)-[master] /srv/video/video.debian.net % git annex dead 0bae683f-bede-43dd-a815-c4f8fb6db32d
dead 0bae683f-bede-43dd-a815-c4f8fb6db32d ok
(Recording state in git...)
richih@apu (git)-[master] /srv/video/video.debian.net % git annex initremote amazon_aws_s3-us_east_1--SHA512E type=S3 encryption='none' embedcreds='no' fileprefix='SHA512E/' bucket='debian-video'
initremote amazon_aws_s3-us_east_1--SHA512E (checking bucket...) git-annex: This bucket is already in use by a different S3 special remote, with UUID: 0bae683f-bede-43dd-a815-c4f8fb6db32d
richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 2
00000000-0000-0000-0000-000000000001 -- web
92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
untrusted repositories: 0
transfers in progress: none
available local disk space: 136.3 gigabytes (+1 megabyte reserved)
local annex keys: 4392
local annex size: 884.64 gigabytes
annexed files in working tree: 4628
size of annexed files in working tree: 885.68 gigabytes
bloom filter size: 16 mebibytes (0.9% full)
backend usage:
SHA512E: 9020
richih@apu (git)-[master] /srv/video/video.debian.net % git annex forget --drop-dead --force
forget git-annex (Recording state in git...)
ok
(Recording state in git...)
richih@apu (git)-[master] /srv/video/video.debian.net % git annex info
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 4
00000000-0000-0000-0000-000000000001 -- web
070cff8a-6302-4aa7-a63c-3fdd34e598a2 -- amazon_s3_us_east--SHA512E
0bae683f-bede-43dd-a815-c4f8fb6db32d -- aws_s3_us_east--SHA512E
92e9fac9-97ec-401f-a421-33f6b4f43e47 -- here (apu.debconf.org/srv/video/conference_videos.annex)
untrusted repositories: 0
transfers in progress: none
available local disk space: 136.3 gigabytes (+1 megabyte reserved)
local annex keys: 4392
local annex size: 884.64 gigabytes
annexed files in working tree: 4628
size of annexed files in working tree: 885.68 gigabytes
bloom filter size: 16 mebibytes (0.9% full)
backend usage:
SHA512E: 9020
richih@apu (git)-[master] /srv/video/video.debian.net % git annex version
git-annex version: 5.20140117~bpo70+2
build flags: Assistant Webapp Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA
key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
remote types: git gcrypt S3 bup directory rsync web tahoe glacier hook external
local repository version: 5
supported repository version: 5
upgrade supported from repository versions: 0 1 2 4
richih@apu (git)-[master] /srv/video/video.debian.net % cat /etc/issue
Debian GNU/Linux 7 \n \l
richih@apu (git)-[master] /srv/video/video.debian.net %
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmJuOOkYYguRbWhXzxihIPBavxITJIMyww"
nickname="Matt"
subject="Excellent News"
date="2014-03-26T14:14:35Z"
content="""
It will be great to see git-annex on f-droid!
"""]]

View file

@ -0,0 +1,3 @@
I have git-annex set up with three clients and a transfer repository and everything was working fine, but a couple of days ago I noticed that git-annex was starting to upload to the transfer repository files that where already present on the three clients, and it hasn't stopped since. It's uploading all my files and I don't really know why.
Is there a way to know why does git-annex think it needs to upload this files?

View file

@ -0,0 +1,9 @@
To properly use amazon AWS S3 for CDN, we need to publish videos to S3. Ideally, we would like to do this via git-annex as the back-end of video.debian.net is being migrated to git-annex by me, atm.
Obviously, we will need clear text names and proper directory structure, not SHA512E file names. This would need to be supported by the S3 special remote.
I talked to TobiasTheViking in the past and he hinted at a reasonably clean way to do this, but that a clean solution would need support from git-annex. I will link him to this page and ask him to supply whatever info is needed.
Thanks,
Richard