diff options
| author |  Joey Hess <joeyh@joeyh.name> | 2017-09-29 12:55:42 -0400 |
|---|---|---|
| committer | Joey Hess <joeyh@joeyh.name> | 2017-09-29 12:55:42 -0400 |
| commit | 0dfc1d4e6eb37aadaba47a210539b2438fba97f5 (patch) | |
| tree | e0beee12909c581f06829060a93a72d6686ca730 /doc | |
| parent | bd2a9fb40ef0bbe812e8ea375a5caabd6e628ef2 (diff) | |
remove old closed bugs and todo items to speed up wiki updates and reduce size
Remove closed bugs and todos that were last edited or commented before 2017.
Command line used:
for f in $(grep -l '|done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
for f in $(grep -l '\[\[done\]\]' -- *.mdwn); do d="$(echo "$f" | sed 's/.mdwn$//')"; if [ -z "$(git log --since=01-01-2017 --pretty=oneline -- "$f")" -a -z "$(git log --since=01-01-2017 --pretty=oneline -- "$d")" ]; then git rm -- "./$f" ; git rm -rf "./$d"; fi; done
Diffstat (limited to 'doc')
840 files changed, 0 insertions, 21980 deletions
diff --git a/doc/bugs/403_for_windows_installer_download.mdwn b/doc/bugs/403_for_windows_installer_download.mdwn deleted file mode 100644 index 8778356c3..000000000 --- a/doc/bugs/403_for_windows_installer_download.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. -As of Nov 2, 2016 1:30AM EST, no Windows installer is to be found in https://downloads.kitenet.net/git-annex/windows/current/. Accessing .exe URI directly yields a 403 error. Not sure if this is a temporary hiccup or a script error somewhere -- pardon if this is not the right channel to report this issue. - -### What steps will reproduce the problem? -See https://downloads.kitenet.net/git-annex/windows/current/. - -### What version of git-annex are you using? On what operating system? -N/A - -### Please provide any additional information below. -N/A - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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! Worked like a charm on my Mac. - -> [[done]] diff --git a/doc/bugs/403_for_windows_installer_download/comment_1_5a9d0e95ae3db43d44fe465888327c64._comment b/doc/bugs/403_for_windows_installer_download/comment_1_5a9d0e95ae3db43d44fe465888327c64._comment deleted file mode 100644 index c1f959fc1..000000000 --- a/doc/bugs/403_for_windows_installer_download/comment_1_5a9d0e95ae3db43d44fe465888327c64._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-02T15:05:04Z" - content=""" -Hmm, seems my backup server moved the files off for some reason. -I've copied them back now. -"""]] diff --git a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching.mdwn b/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching.mdwn deleted file mode 100644 index 357517b0e..000000000 --- a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. -When switching between my 2 repositories I now see a "." repository, see screenshot: http://screencast.com/t/0wxugJ9P -If I chose to switch to it, I get this error: http://screencast.com/t/5mndGNlhh8oN - -### What steps will reproduce the problem? -Not sure if this is a real bug, maybe I screwed up? - -### What version of git-annex are you using? On what operating system? -Version: 5.20150929-g7010007 -Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser Database -MAC OSX 10.10.5 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -there is nothing relevant to this error in there unfortunately. - -# End of transcript or log. -"""]] - -### 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) - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_1_70a34d43629075249897bdc5301c55f5._comment b/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_1_70a34d43629075249897bdc5301c55f5._comment deleted file mode 100644 index 3780297f6..000000000 --- a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_1_70a34d43629075249897bdc5301c55f5._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="ovidiu@66ace8a8d99ce938b0538ffa0f26d30db02a9626" - nickname="ovidiu" - subject="comment 1" - date="2015-10-03T19:03:17Z" - content=""" -trying to delete the test-repository I had created I get: -http://screencast.com/t/AhSiNXESvm -trying again I get: -http://screencast.com/t/hpFZL0mL - -but in the end it got deleted. kinda. not sure. :-( one deleted successfully one simply hangs. -still nothing in the logs. -"""]] diff --git a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_2_ffe8e30474e87e8cfa5aee2a3acb0952._comment b/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_2_ffe8e30474e87e8cfa5aee2a3acb0952._comment deleted file mode 100644 index e83842dea..000000000 --- a/doc/bugs/A_weird___34__.__34___repository_shows_up_when_switching/comment_2_ffe8e30474e87e8cfa5aee2a3acb0952._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-12-02T19:36:14Z" - content=""" -Found this in the changelog: - - * webapp: When adding another local repository, and combining it - with the current repository, the new repository's remote path - was set to "." rather than the path to the current repository. - This was a reversion caused by the relative path changes in 5.20150113. - -I guess this is a similar problem, although it seems that the "." in your case -made it into `~/.config/git-annex/autostart` - -I found two ways to do that. One is to tell the webapp to make a repository, and -enter "." as the repository location. The other, which is probably what you -did, is to go to Configuration -> Preferences and uncheck "Auto start", save -and then go back and check it. This wrongly puts in a "." instead of the full -repo path. - -I've fixed all code paths to force absolute paths in the autostart file, -and made any relative paths that got in there be ignored. -"""]] diff --git a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist.mdwn b/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist.mdwn deleted file mode 100644 index 4b88656a2..000000000 --- a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. - -When entering Jabber account data, the assistant responds with: - - Internal Server Error: /etc/resolv.conf does not exist (No such file or directory). - -### What steps will reproduce the problem? - -Get a jabber account at http://jit.si. Enter your jabber name and password on Android assistant, and click "Use This Account". The dark overlay and progress message appears. After about 30 seconds the browser forwards to the "Internal Server Error: /etc/resolv.conf does not exist (No such file or directory)" page. - -### What version of git-annex are you using? On what operating system? - -Android 4.2 on Lenovo 780p. This model is only for sale in China and India and has been rooted, but the original ROM is still on. Often this makes no difference but you might want to confirm with another device. - -git-annex version 5.20131127-g736ce5e - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_1_d4f22335d5b6cb178c77579a1b450f9c._comment b/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_1_d4f22335d5b6cb178c77579a1b450f9c._comment deleted file mode 100644 index 95583cdf7..000000000 --- a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_1_d4f22335d5b6cb178c77579a1b450f9c._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ" - nickname="Christian" - subject="Same on CyaogenMod 10.2" - date="2013-11-29T11:00:58Z" - content=""" -CM10.2 Nightly Build for Sony Experia Mini Pro does show the same behaviour. Creating the resolv.conf does not solve the problem: - - 1|root@mango:/etc # touch resolv.conf; ls resolv.conf - touch resolv.conf; ls resolv.conf - resolv.conf: No such file or directory - -"""]] diff --git a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_2_19dd9ebfebbece9d3654825492ebd5b9._comment b/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_2_19dd9ebfebbece9d3654825492ebd5b9._comment deleted file mode 100644 index 79554ee50..000000000 --- a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_2_19dd9ebfebbece9d3654825492ebd5b9._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawknsDuoV1R2hz6QoCJmMFWLmWgdZfULjMI" - nickname="Jakob" - subject="Moto G" - date="2013-12-02T13:53:55Z" - content=""" -Same proplem on a Moto G - Android 4.3 - not rooted / Stock - -running git-annex version 5.20131202-g5b9eb74 - -Error Message: - - /etc/resolv.conf: openFile: does not exist (No such file or directory) - -command-line output: - - Falling back to hardcoded app location; cannot find expected files in /data/app-lib - git annex webapp - ex webapp -"""]] diff --git a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_3_4a85c4c45768f96bdc6619c193de55ab._comment b/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_3_4a85c4c45768f96bdc6619c193de55ab._comment deleted file mode 100644 index 0bfe15340..000000000 --- a/doc/bugs/Android__58___500___47__etc__47__resolv.conf_does_not_exist/comment_3_4a85c4c45768f96bdc6619c193de55ab._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.64" - subject="comment 3" - date="2013-12-03T17:35:11Z" - content=""" -The dns library used only for srv lookups was trying to use /etc/resolv.conf. I've patched it to use the android getprop command instead to discover the DNS server. - -The daily build has already been updated with this fix. I have not tested it completely myself. -"""]] diff --git a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__.mdwn b/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__.mdwn deleted file mode 100644 index ed0eb1469..000000000 --- a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -### Please describe the problem. - -On Andorid adding a respository on a remote server (ssh) to an exisiting repository does not work. After selecting "Make unencrypted repository" in the webapp the following error message is displayed: - -Internal Server Error -/sdcard/git-annex.home/.ssh/config: setFileMode: permission denied (Operation not permitted) - -The file "/sdcard/git-annex.home/.ssh/config" is created and its content seems to be fine. I could not find anything related to file mode in logcat / daemon.log. - -### What steps will reproduce the problem? - -Add a repository on a remote server to an existing repository. After selecting "Make unencrypted repository" the error messages is displayed. - -### What version of git-annex are you using? On what operating system? - -git-annex version 5.20140116-g2d9ec29 -Android version 4.4 (running on a Nexus 5) - -> I have made this failure to set the file mode not be a fatal error. -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_1_414adc1bee73711e3133c7fe8811aae2._comment b/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_1_414adc1bee73711e3133c7fe8811aae2._comment deleted file mode 100644 index d1a5bf0c1..000000000 --- a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_1_414adc1bee73711e3133c7fe8811aae2._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkViAynw-AW5kjf3w_QDwCVwhPc3k7gY5E" - nickname="Thomas" - subject="I see the same fail" - date="2014-01-29T21:52:18Z" - content=""" -I se the same failure at both my android devices: -Nexus 7, Android 4.4.2, git-annex 5.20140128 and -Xperia phone, Android 4.1.2, git-annex 5.20140108 -"""]] diff --git a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_2_977a529f488ce0c167035675f76ebabf._comment b/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_2_977a529f488ce0c167035675f76ebabf._comment deleted file mode 100644 index 55a368cc3..000000000 --- a/doc/bugs/Android__58___Adding_Repository_on_Remote_Server_fails_with___34__Internal_Server_Error__34__/comment_2_977a529f488ce0c167035675f76ebabf._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx07B9weuZowXqh--1BDvGw8VM25aXsRw" - nickname="Matthew" - subject="comment 2" - date="2014-02-01T02:44:47Z" - content=""" -Same here, any workarounds? -"""]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__.mdwn b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__.mdwn deleted file mode 100644 index 35e751cce..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -### Please describe the problem. - -Seems to not upload files from Android client (set to "Manual mode: only stores files you...") to servers configured to get the files despite "syncing enabled" - -Even when I chose "File source:" mode -- it just dropped all locally stored ones and didn't transfer those I have added. - -### What steps will reproduce the problem? - -Add file to the sdcard (vfat), and see it added to git (annex) but not uploaded - -### What version of git-annex are you using? On what operating system? - -Android build as now of Dec 13 I believe - -### Please provide any additional information below. - -First it just said that nothing to be transfered, I have switched that remote to "Full backup", web dashboard had "Scanning for files to transfer" for a while, then refreshed with "Synced with" and no file transfers running. Below is an excerpt from the log - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -(Recording state in git...) -(Recording state in git...) -(Recording state in git...) -add pics/20131217_125740.jpg ok -add pics/20131217_125740.jpg [2013-12-17 16:19:25 EST] Committer: Committing changes to git -[2013-12-17 16:19:25 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex -Invalid pid specified -Invalid pid specified -warning: no threads support, ignoring --threads -Already up-to-date. -To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/ - bcb7ed7..3672b38 git-annex -> synced/git-annex - e8cc37f..052b758 annex/direct/master -> synced/master -Already up-to-date. -[2013-12-17 16:19:29 EST] Committer: Adding 20131217_125726.jpg -ok -(Recording state in git...) -(Recording state in git...) - - -add pics/20131217_125726.jpg ok -add pics/20131217_125726.jpg [2013-12-17 16:19:30 EST] Committer: Committing changes to git -Invalid pid specified -[2013-12-17 16:19:32 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex -Already up-to-date. -warning: no threads support, ignoring --threads -To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/ - 3672b38..f914fed git-annex -> synced/git-annex - 052b758..859d3c6 annex/direct/master -> synced/master -Already up-to-date. -Invalid pid specified -Invalid pid specified -Invalid pid specified - - -# End of transcript or log. -"""]] - -previous runs experienced different problems, so may be those could lead to unreported problem here? -e.g. from previous run: - -[[!format sh """ -[2013-12-17 16:04:44 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex -Already up-to-date. -warning: no threads support, ignoring --threads -warning: no threads support, ignoring --threads -To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/ - a889d7b..c9a7466 git-annex -> synced/git-annex -error: Ref refs/heads/synced/git-annex is at c9a74663dc863eb95d316deac4657173c92653df but expected a889d7b335738ef1c4f85da18d1bea337cd36522 -remote: error: failed to lock refs/heads/synced/git-annex^[[K -To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/ - ! [remote rejected] git-annex -> synced/git-annex (failed to lock) -error: failed to push some refs to 'ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/' -Everything up-to-date -Invalid pid specified -[2013-12-17 16:08:34 EST] main: Syncing with vagus.cns.dartmouth.edu_annex -Everything up-to-date -Invalid pid specified -~ -]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_1_3f0e3fed240252207020d31ab96d0666._comment b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_1_3f0e3fed240252207020d31ab96d0666._comment deleted file mode 100644 index 60ac15781..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_1_3f0e3fed240252207020d31ab96d0666._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.87" - subject="comment 1" - date="2013-12-17T23:51:32Z" - content=""" -The \"Invalid pid specified\" seems to point at the problem. (Or it's a nice red herring.) I cannot find this error message in either git-annex or in git. - -Enabling debug logging and restarting the assistant should produce a nice log that will both tell us what command it was running when that message showed up, and show some details about its preferred content decisions. -"""]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_2_87746f4fd0b404db7070c0b2346e8e2b._comment b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_2_87746f4fd0b404db7070c0b2346e8e2b._comment deleted file mode 100644 index 4711c2d1c..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_2_87746f4fd0b404db7070c0b2346e8e2b._comment +++ /dev/null @@ -1,66 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="comment 2" - date="2013-12-18T02:07:46Z" - content=""" -enabled debug logging in the preferences of webapp, clicked on 'restart daemon', fetched log: - - $> grep -B 1 pid daemon.log - [2013-12-17 20:51:49 EST] chat: nice [\"ionice\",\"-c3\",\"git-annex\",\"transferkeys\"] - Invalid pid specified - -entire log http://www.onerussian.com/tmp/daemon.log.gz - -in the webbrowser page got stuck white without updating, refreshed it and got - - \"Internal Server Error\" - git-annex: createProcess: runInteractive - Process: pipe: resource exhausted (Too many open files) - -went to terminal, ctrl-c, started again -- seems have managed to start: - - $> grep -B 3 pid daemon.log - (scanning...) [2013-12-17 20:57:36 EST] Watcher: Performing startup scan - Already up-to-date. - Everything up-to-date - Invalid pid specified - -disabled, and then reenabled syncing with vagus, refetched daemon.log to see similar to above message. - -New experiment -- added locally yet another file pics/test.jpg which according to whereis was quickly pushed out from my laptop. - -Then realized that daemon.log is no longer verbose! (i.e. changes in preferences within webapp didn't persist) By now on phone it synced git, but didn't download the load (rightfully since I have instructed not to). - -ok -- went to enable debug logging again in webapp -- it was already selected. - -in the log now found following - -``` - (started...) [2013-12-17 20:59:10 EST] main: Syncing with vagus.cns.dartmouth.edu_annex - Everything up-to-date - Invalid pid specified - [2013-12-17 21:02:37 EST] main: Syncing with vagus.cns.dartmouth.edu_annex - From ssh://git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex - c3a5fd6..29b6694 master -> vagus.cns.dartmouth.edu_annex/master - d9a09e2..0c3e966 synced/git-annex -> vagus.cns.dartmouth.edu_annex/synced/git-annex - c3a5fd6..29b6694 synced/master -> vagus.cns.dartmouth.edu_annex/synced/master - error: Ref refs/heads/annex/direct/master is at 29b6694ee483c4563955bc5ae1ee1664daed7f19 but expected c3a5fd6b7cee1cbd43fbeb5aa4a445a5407067bd - fatal: Cannot lock the ref 'HEAD'. - Updating c3a5fd6..29b6694 - Fast-forward - - (merging vagus.cns.dartmouth.edu_annex/synced/git-annex into git-annex...) - - git-annex: /storage/extSdCard/annex/.git/annex/merge/: getDirectoryContents: does not exist (No such file or directory) - Already up-to-date. - Already up-to-date. - [2013-12-17 21:02:41 EST] Committer: Committing changes to git - [2013-12-17 21:02:42 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex - Everything up-to-date - [2013-12-17 21:02:43 EST] Committer: Committing changes to git - [2013-12-17 21:02:45 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex - Everything up-to-date -``` -I guess I will just try now to enable debug logging in .git/config while in the terminal on the phone -"""]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_3_72c9e9f6bb5ca23ddfd513fcc8bff48c._comment b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_3_72c9e9f6bb5ca23ddfd513fcc8bff48c._comment deleted file mode 100644 index b920df4a9..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_3_72c9e9f6bb5ca23ddfd513fcc8bff48c._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="comment 3" - date="2013-12-18T02:21:17Z" - content=""" -ah -- may be that was debug log, but nothing exciting was happening? .git/config does have annex.debug true - -ok -- went to \"switch repositories\", showed the list of my only repository, clicking on it didn't go anywhere... ok - restarted the beast in the terminal, added a new file to the pics/ directory, again -- registered, added to git, synced, did not 'push' the load, and no informative debug messages: - - add pics/earth-daynight.jpg [2013-12-17 21:17:26 EST] Committer: Committing changes to git - [2013-12-17 21:17:26 EST] Pusher: Syncing with vagus.cns.dartmouth.edu_annex - Invalid pid specified - Already up-to-date. - warning: no threads support, ignoring --threads - To ssh://annex@git-annex-vagus.cns.dartmouth.edu-annex_annex/~/annex/ - 0c3e966..6d94fd4 git-annex -> synced/git-annex - 29b6694..bbd3fa3 annex/direct/master -> synced/master - [2013-12-17 21:17:28 EST] Committer: Adding earth-daynight.jpg - Already up-to-date. - ok - (Recording state in git...) - (Recording state in git...) - - -so again that pid msg but no debug logging seems to be done. Is there some other way to enable debug logging? ;) -"""]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_4_b54c169a96e263e12495690fe14d8b4a._comment b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_4_b54c169a96e263e12495690fe14d8b4a._comment deleted file mode 100644 index 7453e7cea..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_4_b54c169a96e263e12495690fe14d8b4a._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="etset" - ip="188.83.111.161" - subject="comment 4" - date="2013-12-29T15:12:43Z" - content=""" -I also can't transfer from and to an Android tablet with the git-annex assistant. The `daemon.log` shows the same error, `Invalid pid specified`, repeated several times. - -Enabling the debug log mode always shows lines similar to this one before each \"Invalid pid\" line: `[2013-12-29 14:50:49 WET] chat: nice [\"ionice\", \"-c3\", \"git-annex\", \"transferkeys\"]`. - -However, using the `git annex get` and `git annex copy` commands to fetch and send the files from the same tablet work as expected. - -I can post the full log later, if needed. -"""]] diff --git a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_5_56ef816d3d4f3d85d31ccaf806133073._comment b/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_5_56ef816d3d4f3d85d31ccaf806133073._comment deleted file mode 100644 index a96ebd551..000000000 --- a/doc/bugs/Android__58___does_not_upload_added_files___40__neither_to___34__Transfer__34___or___34__Full_backup__34___server__41__/comment_5_56ef816d3d4f3d85d31ccaf806133073._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="reproduced bug" - date="2013-12-29T21:06:30Z" - content=""" -Debug logs shows that the problem is it tries to run ionice. So fix should be trivial. -"""]] diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn b/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn deleted file mode 100644 index 1cca413a6..000000000 --- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -### Please describe the problem. -I'm trying to get an Android development environment set up, but I am running into conflicting library versions inside of the chroot. The package installation script now finishes, but I run into a link-time error during `cabal configure` because it is pulling in two different versions of the unix package for some reason. Please let me know if there is any information I can get from my build environment that would help diagnosing the issue. - -### What steps will reproduce the problem? -Run `buildchroot`, `install-haskell-packages`, `make android` - -### What version of git-annex are you using? On what operating system? -Attempting to build from source, cross-compiling for Android on Debian Jessie. - -### Please provide any additional information below. - -[[!format sh """ -Linking ./dist/setup/setup ... -/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers': -(.text+0x300): multiple definition of `pPrPr_disableITimers' -/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here -collect2: error: ld returned 1 exit status -Makefile:225: recipe for target 'android' failed -make: *** [android] Error 1 -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_1_2ecd076870d75816671dc0950f89c54a._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_1_2ecd076870d75816671dc0950f89c54a._comment deleted file mode 100644 index 9226c385d..000000000 --- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_1_2ecd076870d75816671dc0950f89c54a._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 1" - date="2016-04-15T12:24:07Z" - content=""" -I just created a new chroot, using revision d4b3a8a for both the initial scripts and inside the chroot. - -``` -... -[32 of 32] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o ) -Linking ./dist/setup/setup ... -/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers': -(.text+0x300): multiple definition of `pPrPr_disableITimers' -/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here -collect2: error: ld returned 1 exit status -Makefile:225: recipe for target 'android' failed -make: *** [android] Error 1 -``` -"""]] diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_2_98ad86d951bda7f2f849b084fd40d1c6._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_2_98ad86d951bda7f2f849b084fd40d1c6._comment deleted file mode 100644 index 564bef6da..000000000 --- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_2_98ad86d951bda7f2f849b084fd40d1c6._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-04-19T17:22:48Z" - content=""" -unix-2.6.0.1 is a very old version of that package, and unix-2.7.1.0 is -included with the version of ghc used by the android build. - -So, it seems that some dependency mess is causing cabal to try to install a -second, old version of unix. Which can't possibly work. - -This is apparently happening in the host ghc setup, not the cross compiling -ghc setup. -"""]] diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment deleted file mode 100644 index 7ebe536e5..000000000 --- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_3_6e13c53def5da8d903b220522bbd23ba._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="Further information" - date="2016-04-23T18:31:23Z" - content=""" -I did some further testing, but I'm still stumped. If I run `cabal configure -O0 -fAndroidSplice --ghc-options=-v`, I get the following items in the resulting log file. (trimmed for space) - -``` -Glasgow Haskell Compiler, Version 7.6.3, stage 2 booted by GHC version 7.6.3 -Using binary package database: /usr/lib/ghc/package.conf.d/package.cache -Using binary package database: /home/builder/.ghc/i386-linux-7.6.3/package.conf.d/package.cache -... -hiding package unix-2.6.0.1 to avoid conflict with later version unix-2.7.1.0 -... -Chasing modules from: *dist/setup/setup.hs -Created temporary directory: /tmp/ghc1639_0 -*** C pre-processor: -'/usr/bin/gcc' '-E' '-undef' '-traditional' '-fno-stack-protector' '-Wl,--hash-size=31' '-Wl,--reduce-memory-overheads' ... '-I' '/usr/lib/ghc/unix-2.6.0.1/include' ... '-x' 'c' './Common.hs' '-o' '/tmp/ghc1639_0/ghc1639_0.hscpp' -... -*** Linker: -'/usr/bin/gcc' ... '-L/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0' ... '-L/usr/lib/ghc/unix-2.6.0.1' ... '-lHSunix-2.7.1.0' ... '-lHSunix-2.6.0.1' ... -/usr/lib/ghc/unix-2.6.0.1/libHSunix-2.6.0.1.a(execvpe.o): In function `pPrPr_disableITimers': -(.text+0x300): multiple definition of `pPrPr_disableITimers' -/home/builder/.cabal/lib/i386-linux-ghc-7.6.3/unix-2.7.1.0/libHSunix-2.7.1.0.a(ghcrts.o):ghcrts.c:(.text+0x0): first defined here -collect2: error: ld returned 1 exit status -``` - -I'm not sure what \"hiding\" means in the context of GHC, but clearly it isn't working. -"""]] diff --git a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment b/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment deleted file mode 100644 index abf801c75..000000000 --- a/doc/bugs/Android_chroot_stuck_in_Cabal_hell/comment_4_3dd3b8005fef7a5dad69b7d1c1154235._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-04-28T17:21:00Z" - content=""" -Reproduced, fixed. -"""]] diff --git a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_.mdwn b/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_.mdwn deleted file mode 100644 index cc63ac138..000000000 --- a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### Please describe the problem. - -Two regular repositories created with the assistant, one on the computer and one on an USB stick cannot synchronise. Log reports problem with the index file: - - /media/usb/annex/.git/index: copyFile: does not exist (No such file or directory) - -### What steps will reproduce the problem? - -Create a repository and then another on an usb stick (with `Add another repository`) and add a file to the first one, it doesn't synchronise. - -### What version of git-annex are you using? On what operating system? - -git-annex 5.20141125 from Debian Jessie - -### Please provide any additional information below. - -I was able to solve the problem by copying the .git/index file from the first repository to the second one. - -Also note that the second repository is on a FAT32 usb stick - - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_1_36d1207818c8db747dbf94d9a48e3e98._comment b/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_1_36d1207818c8db747dbf94d9a48e3e98._comment deleted file mode 100644 index 3750d1a28..000000000 --- a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_1_36d1207818c8db747dbf94d9a48e3e98._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-03-16T17:34:22Z" - content=""" -Well, non-bare git repositories are supposed to have a .git/index file. - -Perhaps some damage to your USB stick caused it to lose this file? -"""]] diff --git a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_2_82f1c3c6aaeb488582ee08518b193f99._comment b/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_2_82f1c3c6aaeb488582ee08518b193f99._comment deleted file mode 100644 index 457c288dd..000000000 --- a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_2_82f1c3c6aaeb488582ee08518b193f99._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="clement" - subject="Details" - date="2015-03-27T10:34:26Z" - content=""" -I tried it again with dfifferent usbs and filesystems, and it looks like it only -happens with VFAT (e.g not ext). Retracing my step, here is what I do: - -1. Create a repository on my local machine using git-annex assistant. - -2. Create another non-bare repository on a VFAT usb stick and combine the two. - -3. Add a file to the local repository - -4. I doesn't synchronise and log shows the missing index error. - -It also happens the other way around. If I - -1. Create a repository on the usb device, and - -2. create a paired repository on my machine, I get a straight up - - Internal Server Error - - /mnt/USB/annexdir/.git/index: copyFile: does not exist (No such file or directory) - -"""]] diff --git a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_3_db50cbdc302480c4b1fe0f364aa769d9._comment b/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_3_db50cbdc302480c4b1fe0f364aa769d9._comment deleted file mode 100644 index 515ad0b7b..000000000 --- a/doc/bugs/Assistant__58___synchronisation_between_two_regular_repositories_hangs_/comment_3_db50cbdc302480c4b1fe0f364aa769d9._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-09-22T16:25:15Z" - content=""" -Ok, that seems clear enough, and there's only 1 place where git-annex -copies .git/index; in `mergeDirect`. Indeed, if .git/index doesn't exist -yet when that is called, it'll crash. And, a freshly created git repo -starts off without a .git/index until changes start to be staged. - -However, I can't reproduce the crash with a current version of git-annex, -and this bug report is about a version nearly a year old now. AFAICS, -the sync (or the assistant) will make a commit before merging, and that -commit results in the index file being created, as a side effect. -Also, I can't see anything that VFAT could have to do with this. - -Hmm, I did manage to reproduce the crash using the new --no-commit flag to -git-annex sync. Will fix on that basis. -"""]] diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn deleted file mode 100644 index 7437192a7..000000000 --- a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. -The assistant keeps making merges that deletes all the files in the repository. I "git revert" the merge commit, but the next day it does it again. It also seems to have gone into a merge loop before this happens (will post a screenshot of tig). I can make the repo available privately if that will help. - -### What steps will reproduce the problem? -Unknown. It does it on its own without me even interacting with files in the annex. - -### What version of git-annex are you using? On what operating system? -The host that keeps deleting is running 6.20160428-g1f253e8 on ArchLinux (x86_64). A remote that it keeps syncing with is running 6.20160511-g4633f0b, also on ArchLinux x86_64. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -Updating 8cb69d3..c589c5e -Fast-forward - .gitignore | 3 --- - Bilete/8mars-2013-1.jpg | 1 - -etc. -# End of transcript or log. -"""]] - -### 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) -I use git-annex for everything. I've got 10 repositories and around 2.5TB of data in those repos which in turn is synced all over the place. It's excellent. - -> This seems to be a git bug probably; see -> <http://thread.gmane.org/gmane.comp.version-control.git/297237>. -> -> Luckily, easy to work around the problem. -> -> [[fixed|done]] in [[!commit bfd00a0f8ca69cb0669df50f8d98354f11c5253c]]. -> --[[Joey]] diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment deleted file mode 100644 index a65054ca7..000000000 --- a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_1_951d03de942c19f760e9ff01a3b61f33._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="EskildHustvedt" - subject="comment 1" - date="2016-05-20T07:45:52Z" - content=""" -Right, so I forgot to mention, perhaps crucially. I'm using v6 for these repos. - -Here's the tig grap for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge1-2016-05-20.png]] - -Here's the merge commit itself for master: [[https://ssl.zerodogg.org/~zerodogg/tmp/annexmerge2-2016-05-20.png]] -"""]] diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment deleted file mode 100644 index b56f49466..000000000 --- a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_2_c3408c31cf1c58b6b1e34102127ba613._comment +++ /dev/null @@ -1,56 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-05-23T17:30:07Z" - content=""" -I've now got a copy of the repo, in -~/lib/big/git-annex-test-repos/ssl.zerodogg.org__zerodogg_private_tmp_privateDocs.zerodogg.tar.xz.gpg - -Looking at commit 77c7d149646655fb5851c3db584fe70d64707d04, it merges in -0b4896bc205696630c81cf557959a4aaa24906f0 which has an empty tree. - -0b4896bc205696630c81cf557959a4aaa24906f0 is itself a merge commit. -Both of the commits it merges themselves have empty trees. -And so it goes down quite a way, with empty merge commits including -418367b, 7bab5cf, b651554, cf5de84, c5905f7, 928040e, a590245, 5b53fc9, -6d9f5da, 5f2623d. The freqency of these might indeed indicate some kind -of feedback loop, but I don't think whatever is causing that is the core problem. - -fc6670a37fd9d3984a112a80d9bbaec5c041c005 is the crucial merge it seems. Its -parents are 71b6c8a and f8dfc21. Both of those parents have the same tree, -5f18bed323c29fb77add3a84abcf8b1fb6b646d7, and that tree is populated with all -the files. But somehow this merge deleted everything. - - tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 - parent 71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c - parent f8dfc219a40b2871baed3192ea5806bb4ac551e7 - author xxx 1463570165 +0200 - committer xxx 1463570165 +0200 - - Merge branch 'refs/heads/synced/master' into HEAD - -(There are empty trees earlier where the same thing happened that you -reverted, but it seems best to focus on the most recent occurance.) - -So, can you find fc6670a in .git/annex/daemon.log* in any of the -clones of this repository? It would be good to narrow down on which -machine(s) the bad merge is happening. (Maybe you've already narrowed it down?) - -One of the two parent commits (71b6c8ad3fc44926c9be2bbb1bd308592b6eb05c) -is a manual revert you did, the other commit looks to have been done by -the assistant. -I'm guessing that refs/heads/synced/master was f8dfc219a40b2871baed3192ea5806bb4ac551e7 -when the bad merge was generated. So this bad merge probably happened in -the repository where you did that manual reversion. - -As far as I can tell this was a regular git merge that somehow decided to empty -the tree. It was not a case of git-annex auto-resolving a merge conflict. - -Are you using adjusted branches in any of the clones of this repository? - -What version(s) of git are being used? - -(I noticed that despite using v6 mode, every file in the repository -seems to be locked, so the smudge filters etc should not be involved in the -problem unless using an adjusted branch.) -"""]] diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_3_518bc431b16143b9ec0caa78e54c2d6b._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_3_518bc431b16143b9ec0caa78e54c2d6b._comment deleted file mode 100644 index 305e11192..000000000 --- a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_3_518bc431b16143b9ec0caa78e54c2d6b._comment +++ /dev/null @@ -1,47 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-06-13T16:22:27Z" - content=""" -@EskildHustvedt, are you using adjusted branches in any of your v6 -repositories? - -While investigating a test suite failure that occurs only on FAT, -I think I have reproduced this bug. I used two v6 repos, both of -them using adjusted branches, and added a file with the same name and -content to both independently, then merged the two. - -In a merge of two commits that both had the same tree, a merge -commit was constructed with an empty tree. - -Also, much as in the original bug report, there was a pattern of -repeated merges. - - commit 4bcff45c9670007b8faee5c5514bdd7b9096984a - Merge: 4935ace 63fe78f - # empty tree - - commit 63fe78f28218ad71e865f52e2a833dbd4b452c96 - Merge: 4e42f30 4935ace - # populated tree - - 4935ace has populated tree - 4e42f30 has populated tree - -Notice that 4935ace is merged in twice, a bit oddly. Indeed, that -is not possible to construct with manual git commands: - - joey@darkstar:~/tmp/meep/2>git checkout 63fe78f - HEAD is now at 63fe78f... Merge branch 'refs/heads/synced/master' into HEAD - joey@darkstar:~/tmp/meep/2>git merge 4935ace - Already up-to-date. - joey@darkstar:~/tmp/meep/2>git checkout 4935ace - Previous HEAD position was 63fe78f... Merge branch 'refs/heads/synced/master' into HEAD - HEAD is now at 4935ace... git-annex in joey@darkstar:~/tmp/meep/2 - joey@darkstar:~/tmp/meep/2>git merge 63fe78f - Updating 4935ace..63fe78f - Fast-forward - -In either case, git updates to 63fe78f. So, adusted branches must be -breaking handling of one or the other of these two cases. -"""]] diff --git a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_4_49bdbdc261c8e5b72f84c52014f892df._comment b/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_4_49bdbdc261c8e5b72f84c52014f892df._comment deleted file mode 100644 index 991ad48a8..000000000 --- a/doc/bugs/Assistant_keeps_deleting_all_the_files_in_my_repo/comment_4_49bdbdc261c8e5b72f84c52014f892df._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-06-14T01:55:03Z" - content=""" -Forgot to mention that the repeated merge commits happened because git -merge -no-ff was being used, which makes a merge commit even when it can -just fast-forward. That was removed as part of the fix, so the repeated -merges should also be resolved. -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__.mdwn b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__.mdwn deleted file mode 100644 index e14a9b67c..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -If I create a git annex repository in my home directory, then start the assistant, the assistant will try to annex my entire home dir. - -### What steps will reproduce the problem? - -$ cd -$ git init -$ git annex init - -Applications Menu -> Internet -> Git Annex - -### What version of git-annex are you using? On what operating system? - -Debian Jessie git-annex (5.20141125) - -### Expected behavior - -The assistant shouldn't do anything unless I tell it to. Currently, I cannot play with the assistant at all, because I do not want everything in my homedir to be locked and symlinked. - -### 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) - -I use git annex for managing the image and video resources on my website and it works fine for that. - -> HOME git repo guard added, [[done]] --[[Joey]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_1_af3cc2384e230601851e5379dacd3d29._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_1_af3cc2384e230601851e5379dacd3d29._comment deleted file mode 100644 index ead1d6f03..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_1_af3cc2384e230601851e5379dacd3d29._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-04T20:14:29Z" - content=""" -By creating a git repository in your home directory, -and telling git-annex it's a git-annex repository, and starting -the assistant, what would you say you've told git-annex to do? - -(Note that the webapp has a guard to prevent this mistake. -You have to shoot your foot manually, and repeatedly, to do this.) -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment deleted file mode 100644 index 06f90b081..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_2_36e71b11f30a6fd4e95cd32a6deb57d9._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991" - nickname="timothyhobbs" - subject="comment 2" - date="2016-04-04T21:21:56Z" - content=""" -When I launch the annex assistant web app, it should do nothing to the repository, because I have not told it to do anything. I have only tried to open up what, to me, the naive user, is some gui app. I know of no other gui app that initializes an operation simple by way of being opened. Does synaptic update your system when you click \"Applications Menu -> Settings -> Synaptic package manager\"? - -You say that I have to shoot myself in the foot repeatedly and manually to do it, but that simply isn't true. There is nothing wrong with initializing a git repo in ~/ in order to, say, track changes to dot files. There shouldn't be anything wrong with running \"git annex init\" in that git repo, to, for example, track some binaries in ~/bin. Afterall, I didn't \"git annex add .\" I was trying to use git annex to track specific and manually specified files. - -I actually ended up opening the assistant, from the Applications Menu, for a reason entirely unrelated to the git annex repo that happened to be located in ~/. So I hope you can imagine my shock, when by simply opening what I thought was going to be a gui that I could use to manage some entirely unrelated repositories, I actually ended up running a command on the repository in ~/. -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_3_a29edaf9110cc6e0ed68f92d33ed7735._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_3_a29edaf9110cc6e0ed68f92d33ed7735._comment deleted file mode 100644 index ffdda0bc6..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_3_a29edaf9110cc6e0ed68f92d33ed7735._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991" - nickname="timothyhobbs" - subject="comment 3" - date="2016-04-05T21:28:20Z" - content=""" -If I understand correctly, than if you run the command `git annex webapp` and the $PWD is a git annex repository, then this will start the assistant and annex all of the files in that directory. And that, I think is a bug, no one expects the `webapp` command to do anything besides display a GUI. -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_4_6353daafdf250ea0c4dad1e2fd1233a3._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_4_6353daafdf250ea0c4dad1e2fd1233a3._comment deleted file mode 100644 index 77cbad403..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_4_6353daafdf250ea0c4dad1e2fd1233a3._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="timothyhobbs@8b50ff958c937fa4b6de1f9009f464b9ddfc2991" - nickname="timothyhobbs" - subject="comment 4" - date="2016-04-05T22:29:06Z" - content=""" -Yes, that is the problem. Try: - -```` -$ mkdir foo -$ cd foo -$ echo foo > bar -$ git init -$ git annex init -$ git annex webapp -```` - -You'll get: - -```` -x Committed changes to git -× Added bar -× Performed startup scan -```` - -But I wouldn't expect that. Why should the command `git annex webapp` run an `add` command? -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_5_200e00eb84c9278c9f90fe545cb6531d._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_5_200e00eb84c9278c9f90fe545cb6531d._comment deleted file mode 100644 index 77a42b19c..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_5_200e00eb84c9278c9f90fe545cb6531d._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-04-13T17:40:15Z" - content=""" -If ~/ is a git repository, the assistant will still refuse to run in it, -unless you've manually run `git annex init` in that git repository -at some point in the past. - -Here it is in my home directory, which is indeed a git repo: - - joey@darkstar:~>git annex assistant - git-annex: First run: git-annex init - -When I run the webapp, it doesn't run the assistant, but prompts in the web browser for -where I want to make a new git-annex repository. -"""]] diff --git a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_6_ed1b53ceef3e7a499b92e6f3f0f6d672._comment b/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_6_ed1b53ceef3e7a499b92e6f3f0f6d672._comment deleted file mode 100644 index 5fdcf8e38..000000000 --- a/doc/bugs/Assistant_will_annex_your_files_on_startup_if_you_create_a_repository_in___126____47__/comment_6_ed1b53ceef3e7a499b92e6f3f0f6d672._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-04-13T17:43:34Z" - content=""" -So, I see that you *did* tell git-annex to treat your home git repo as a -git-annex repo. - -And, starting the the assistant/webapp from inside a git annex repository is -intended to start them running in that repository. This behavior makes a -lot of sense in general. It's consistent with running any other git command -inside a git repository causing that command to run on that repository. - -I guess that the issue here is, opening the git-annex webapp from a menu -causes the program to run with its working directory set to HOME. But in -this case, the HOME is only incidental, the intent is not to start the -webapp/assistant in that repository. - -Seems kind of hard for the assistant to determine intent though. - -So, the best that can be done, I suppose, is to make starting the webapp -in the HOME git repository behave as if that git repository was not -initialized for use by git-annex. -"""]] diff --git a/doc/bugs/Build_with_aws_head_fails.mdwn b/doc/bugs/Build_with_aws_head_fails.mdwn deleted file mode 100644 index a96dce0ad..000000000 --- a/doc/bugs/Build_with_aws_head_fails.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. -https://github.com/aristidb/aws/issues/206 was recently resolved in https://github.com/aristidb/aws/pull/213. - -A newer version will be tagged imminently according to https://github.com/aristidb/aws/issues/206#issuecomment-260214736. - -With the http-conduit (<2.2.0) constraint removed from git-annex.cabal, and the aws dependency set to use aws head (currently c8806dc), the git-annex build fails. - -### What steps will reproduce the problem? - -Remove the http-conduit (<2.2.0) constraint and attempt to build git-annex with aws head. - -### What version of git-annex are you using? On what operating system? - -macOS 10.11, git-annex 6.20161118. - -### Please provide any additional information below. -Full build log: https://gist.github.com/ilovezfs/15bcd8f1086b3d825beff58140e04eec -[[!format sh """ -[ 90 of 542] Compiling Types.Crypto ( Types/Crypto.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Types/Crypto.o ) -[ 91 of 542] Compiling Utility.Metered ( Utility/Metered.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Metered.o ) -[ 92 of 542] Compiling Messages.JSON ( Messages/JSON.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Messages/JSON.o ) -[ 93 of 542] Compiling Utility.Url ( Utility/Url.hs, dist/dist-sandbox-6b15e8f0/build/git-annex/git-annex-tmp/Utility/Url.o ) - -Utility/Url.hs:354:34: error: - • The constructor ‘StatusCodeException’ should have 2 arguments, but has been given 3 - • In the pattern: StatusCodeException s _ _ - In an equation for ‘matchStatusCodeException’: - matchStatusCodeException want e@(StatusCodeException s _ _) - | want s = Just e - | otherwise = Nothing - -Utility/Url.hs:354:34: error: - • Couldn't match expected type ‘HttpException’ - with actual type ‘HttpExceptionContent’ - • In the pattern: StatusCodeException s _ _ - In an equation for ‘matchStatusCodeException’: - matchStatusCodeException want e@(StatusCodeException s _ _) - | want s = Just e - | otherwise = Nothing -cabal: Leaving directory '.' -cabal: Error: some packages failed to install: -git-annex-6.20161118 failed during the building phase. The exception was: -ExitFailure 1 -"""]] - -### 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 :) - -> [[done]] via the nice patch! --[[Joey]] diff --git a/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment b/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment deleted file mode 100644 index 536c1569d..000000000 --- a/doc/bugs/Build_with_aws_head_fails/comment_1_d48bc2b3eb48c2a3a4d8608803913000._comment +++ /dev/null @@ -1,149 +0,0 @@ -[[!comment format=mdwn - username="alpernebbi" - avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" - subject="Patch to fix aws head build issue" - date="2016-12-10T13:08:58Z" - content=""" -I think I fixed this. I'm attaching the output of `git format-patch origin/master`. - -In an Arch Linux chroot with their [PKGBUILD](https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/git-annex) (with a small modification to apply the patch), `haskell-http-client 0.5.3.3-1` and `http-conduit 2.2.3-5` both the build and the tests are successful. -It's also successful in a Debian Sid chroot, where `sudo apt build-dep git-annex` gives me `libghc-http-client-dev 0.4.31.1-3+b2`, `libghc-http-conduit-dev 2.1.11-3+b2`. - -### Patch - -[[!format patch \"\"\" -From 2ce09420aa8f3d916c6562abea4ed8911a186902 Mon Sep 17 00:00:00 2001 -From: Alper Nebi Yasak <alpernebiyasak@gmail.com> -Date: Sat, 10 Dec 2016 15:24:27 +0300 -Subject: [PATCH] Remove http-conduit (<2.2.0) constraint - -Since https://github.com/aristidb/aws/issues/206 is resolved, this -constraint is no longer necessary. However, http-conduit (>=2.2.0) -requires http-client (>=0.5.0) which introduces some breaking changes. -This commit also implements those changes depending on the version. -Fixes: https://git-annex.branchable.com/bugs/Build_with_aws_head_fails/ - -Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> ---- - Remote/S3.hs | 8 +++++++- - Remote/WebDAV.hs | 17 +++++++++++++++++ - Utility/Url.hs | 8 ++++++++ - git-annex.cabal | 3 +-- - 4 files changed, 33 insertions(+), 3 deletions(-) - -diff --git a/Remote/S3.hs b/Remote/S3.hs -index 4c1bd57..9563b5a 100644 ---- a/Remote/S3.hs -+++ b/Remote/S3.hs -@@ -49,6 +49,12 @@ import Annex.Content - import Annex.Url (withUrlOptions) - import Utility.Url (checkBoth, managerSettings, closeManager) - -+#if MIN_VERSION_http_client(0,5,0) -+import Network.HTTP.Client (responseTimeoutNone) -+#else -+responseTimeoutNone = Nothing -+#endif -+ - type BucketName = String - - remote :: RemoteType -@@ -430,7 +436,7 @@ withS3HandleMaybe c gc u a = do - where - s3cfg = s3Configuration c - httpcfg = managerSettings -- { managerResponseTimeout = Nothing } -+ { managerResponseTimeout = responseTimeoutNone } - - s3Configuration :: RemoteConfig -> S3.S3Configuration AWS.NormalQuery - s3Configuration c = cfg -diff --git a/Remote/WebDAV.hs b/Remote/WebDAV.hs -index 19dbaa8..14947f1 100644 ---- a/Remote/WebDAV.hs -+++ b/Remote/WebDAV.hs -@@ -5,6 +5,7 @@ - - Licensed under the GNU GPL version 3 or higher. - -} - -+{-# LANGUAGE CPP #-} - {-# LANGUAGE ScopedTypeVariables #-} - - module Remote.WebDAV (remote, davCreds, configUrl) where -@@ -34,6 +35,10 @@ import Utility.Url (URLString, matchStatusCodeException) - import Annex.UUID - import Remote.WebDAV.DavLocation - -+#if MIN_VERSION_http_client(0,5,0) -+import Network.HTTP.Client (HttpExceptionContent(..), responseStatus) -+#endif -+ - remote :: RemoteType - remote = RemoteType { - typename = \"webdav\", -@@ -302,6 +307,17 @@ goDAV (DavHandle ctx user pass _) a = choke $ run $ prettifyExceptions $ do - {- Catch StatusCodeException and trim it to only the statusMessage part, - - eliminating a lot of noise, which can include the whole request that - - failed. The rethrown exception is no longer a StatusCodeException. -} -+#if MIN_VERSION_http_client(0,5,0) -+prettifyExceptions :: DAVT IO a -> DAVT IO a -+prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go -+ where -+ go (HttpExceptionRequest _ (StatusCodeException response message)) = error $ unwords -+ [ \"DAV failure:\" -+ , show (responseStatus response) -+ , show (message) -+ ] -+ go e = throwM e -+#else - prettifyExceptions :: DAVT IO a -> DAVT IO a - prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go - where -@@ -311,6 +327,7 @@ prettifyExceptions a = catchJust (matchStatusCodeException (const True)) a go - , show (statusMessage status) - ] - go e = throwM e -+#endif - - prepDAV :: DavUser -> DavPass -> DAVT IO () - prepDAV user pass = do -diff --git a/Utility/Url.hs b/Utility/Url.hs -index 9b68871..d0e1b37 100644 ---- a/Utility/Url.hs -+++ b/Utility/Url.hs -@@ -350,8 +350,16 @@ hUserAgent = \"User-Agent\" - - - - > catchJust (matchStatusCodeException (== notFound404)) - -} -+#if MIN_VERSION_http_client(0,5,0) -+matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException -+matchStatusCodeException want e@(HttpExceptionRequest _ (StatusCodeException r _)) -+ | want (responseStatus r) = Just e -+ | otherwise = Nothing -+matchStatusCodeException _ _ = Nothing -+#else - matchStatusCodeException :: (Status -> Bool) -> HttpException -> Maybe HttpException - matchStatusCodeException want e@(StatusCodeException s _ _) - | want s = Just e - | otherwise = Nothing - matchStatusCodeException _ _ = Nothing -+#endif -diff --git a/git-annex.cabal b/git-annex.cabal -index ec54a14..83d45a1 100644 ---- a/git-annex.cabal -+++ b/git-annex.cabal -@@ -357,8 +357,7 @@ Executable git-annex - resourcet, - http-client, - http-types, -- -- Old version needed due to https://github.com/aristidb/aws/issues/206 -- http-conduit (<2.2.0), -+ http-conduit, - time, - old-locale, - esqueleto, --- -2.7.4 - -\"\"\"]] - -"""]] diff --git a/doc/bugs/Building_fails__58___Not_in_scope__58_____96__myHomeDir__39___.mdwn b/doc/bugs/Building_fails__58___Not_in_scope__58_____96__myHomeDir__39___.mdwn deleted file mode 100644 index e1d2da4ce..000000000 --- a/doc/bugs/Building_fails__58___Not_in_scope__58_____96__myHomeDir__39___.mdwn +++ /dev/null @@ -1,56 +0,0 @@ -What steps will reproduce the problem? - -Building of the current github HEAD fails with a strange error message regarding OSX. I'm not using OSX but Ubuntu 12.10, why is cabal trying to build these files? - -<pre> -dominik@Atlantis:/var/tmp$ git clone git://github.com/joeyh/git-annex.git -Cloning into 'git-annex'... -remote: Counting objects: 40243, done. -remote: Compressing objects: 100% (10568/10568), done. -remote: Total 40243 (delta 29647), reused 40044 (delta 29449) -Receiving objects: 100% (40243/40243), 9.12 MiB | 184 KiB/s, done. -Resolving deltas: 100% (29647/29647), done. -dominik@Atlantis:/var/tmp$ cd git-annex/ -dominik@Atlantis:/var/tmp/git-annex$ cabal update -Downloading the latest package list from hackage.haskell.org -dominik@Atlantis:/var/tmp/git-annex$ cabal install --only-dependencies -Resolving dependencies... -All the requested packages are already installed: -Use --reinstall if you want to reinstall anyway. -dominik@Atlantis:/var/tmp/git-annex$ cabal configure -Resolving dependencies... -[ 1 of 21] Compiling Utility.FileSystemEncoding ( Utility/FileSystemEncoding.hs, dist/setup/Utility/FileSystemEncoding.o ) -[ 2 of 21] Compiling Utility.Applicative ( Utility/Applicative.hs, dist/setup/Utility/Applicative.o ) -[ 3 of 21] Compiling Utility.PartialPrelude ( Utility/PartialPrelude.hs, dist/setup/Utility/PartialPrelude.o ) -[ 4 of 21] Compiling Utility.UserInfo ( Utility/UserInfo.hs, dist/setup/Utility/UserInfo.o ) -[ 5 of 21] Compiling Utility.Monad ( Utility/Monad.hs, dist/setup/Utility/Monad.o ) -[ 6 of 21] Compiling Utility.Path ( Utility/Path.hs, dist/setup/Utility/Path.o ) -[ 7 of 21] Compiling Utility.OSX ( Utility/OSX.hs, dist/setup/Utility/OSX.o ) - -Utility/OSX.hs:22:17: Not in scope: `myHomeDir' -</pre> - -What is the expected output? What do you see instead? - -I expect cabal to build git-annex. - -What version of git-annex are you using? On what operating system? - -github HEAD on Ubuntu 12.10 - -Please provide any additional information below. - -<pre> -$ cabal --version -cabal-install version 0.14.0 -using version 1.14.0 of the Cabal library - -$ ghc --version -The Glorious Glasgow Haskell Compilation System, version 7.4.2 - -$ uname -a -Linux Atlantis 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux - -</pre> - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Can__39__t_create_remote_for_Google_cloud_storage_DRA___47___nearline_buckets.mdwn b/doc/bugs/Can__39__t_create_remote_for_Google_cloud_storage_DRA___47___nearline_buckets.mdwn deleted file mode 100644 index 57fe32e67..000000000 --- a/doc/bugs/Can__39__t_create_remote_for_Google_cloud_storage_DRA___47___nearline_buckets.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. - -Creating a remote for a GCS durable reduced availability (DRA) or nearline bucket fails with "Invalid argument". - -### What steps will reproduce the problem? - - $ git annex initremote test encryption=none bucket=BUCKET type=S3 host=storage.googleapis.com - -This works if BUCKET is a standard bucket, but fails with "invalid argument" if BUCKET is a DRA or nearline bucket. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20150205 -on macos 10.10 - -### Please provide any additional information below. - -I spent some time in strace, and my best guess is that this is because git-annex is sending x-amz-storage-class: STANDARD. I couldn't figure out a way to disable this; if I did e.g. - - $ git annex initremote test encryption=none bucket=BUCKET type=S3 host=storage.googleapis.com storageclass="NEARLINE" - -it still fails and still sends storage-class: STANDARD. I also tried storageclass="" -- same thing. - -Here's the HTTP request that's failing: - - PUT /annex-uuid HTTP/1.1\r\nAuthorization: AWS GOOG<...>:<...>=\r\nDate: Mon, 16 Mar 2015 01:41:38 GMT\r\nHost: jlebar-backup-annex-nearline-test.storage.googleapis.com\r\nContent-Type: \r\nx-amz-storage-class: STANDARD\r\nContent-Length: 36\r\n\r\n<...> - -And the (rather unhelpful) HTTP response: - - HTTP/1.1 400 Bad Request\r\nContent-Type: application/xml; charset=UTF-8\r\nContent-Length: 117\r\nVary: Origin\r\nDate: Mon, 16 Mar 2015 01:41:38 GMT\r\nServer: UploadServer (\"Built on Feb 27 2015 12:13:16 (1425067996)\")\r\nAlternate-Protocol: 80:quic,p=0.5\r\n\r\n<?xml version='1.0' encoding='UTF-8'?><Error><Code>InvalidArgument</Code><Message>Invalid argument.</ Message></Error> - -[[!format sh """ - -$ AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY="..." git annex --debug initremote test encryption=none bucket=<DRA bucket> type=S3 host=storage.googleapis.com -[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","show-ref","git-annex"] -[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","show-ref","--hash","refs/heads/git-annex"] -[2015-03-15 19:12:19 PDT] read: git ["--git-dir=.git","--work-tree=.","log","refs/heads/git-annex..d7640d68e3bd55735fb275816df0b94ec05031a7","-n1","--pretty=%H"] -[2015-03-15 19:12:20 PDT] chat: git ["--git-dir=.git","--work-tree=.","cat-file","--batch"] -initremote test (checking bucket...) git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidArgument", s3ErrorMessage = "Invalid argument.", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing} - -# End of transcript or log. -"""]] - -> [[dup|done]] of [[todo/Nearline_support]] --[[Joey]] diff --git a/doc/bugs/Can__39__t_keep_gpg_quiet.mdwn b/doc/bugs/Can__39__t_keep_gpg_quiet.mdwn deleted file mode 100644 index b9b254343..000000000 --- a/doc/bugs/Can__39__t_keep_gpg_quiet.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -### Please describe the problem. - -Can't seem to stop gpg writing it's progress/info messages out - -### What steps will reproduce the problem? - -Use a gcrypt-remote, do a git sync - -### What version of git-annex are you using? On what operating system? - -Arch Linux, stable, updated daily. - -git-annex 6.20160613-8 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -I have the following in my config, but I still get the standard gnupg noise produced. I have read that work was done to propogate the gnupg-options and gnupg-decrypt-options through to the required places (in May, and I'm on a June version), but it doesn't appear to work for me. - -[annex] - uuid = 583acd1e-f969-4b7b-89d5-7a4aff9a7077 - version = 6 - gnupg-options = --quiet --batch --no-tty - gnupg-decrypt-options = --quiet --batch --no-tty - - -I still get the output, which I shouldn't@ - - gcrypt: Decrypting manifest - gpg: Signature made Sun 02 Oct 2016 21:04:31 BST - gpg: using RSA key XXXYYYZZZ - gpg: Good signature from "x <xx@x.x>" [ultimate] - gpg: aka "[jpeg image of size 2004]" [ultimate] - -# End of transcript or log. -"""]] - -### 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) - -Mixed bag, works when it works, but I've had quite a few "unexplained" happenings. Perservering for now, hoping me reporting bugs will see things improve... - -> [[done]]; gcrypt.gpg-args is the answer. --[[Joey]] diff --git a/doc/bugs/Can__39__t_keep_gpg_quiet/comment_1_ab0ffdf17fb5caf8db70b77220878a1b._comment b/doc/bugs/Can__39__t_keep_gpg_quiet/comment_1_ab0ffdf17fb5caf8db70b77220878a1b._comment deleted file mode 100644 index 5e6b231e8..000000000 --- a/doc/bugs/Can__39__t_keep_gpg_quiet/comment_1_ab0ffdf17fb5caf8db70b77220878a1b._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-10-17T20:32:02Z" - content=""" -The gnupg-options and gnupg-decrypt-options only apply when git-annex -is running gpg, not when git-annex is running git push which is running -git-remote-gcrypt which is running gpg. - -I don't think there's any way to pass gpg options through that chain of -programs. Even if there is, I don't know that it would make sense to use -the git-annex configuration, which normally is used when git-annex is using -gpg in symmetric encryption mode, for git-remote-gcrypt, which is using gpg -in pubic key encryption mode. - -I think you should just set gcrypt.gpg-args to whatever options are -appropriate for its use of gpg. -"""]] diff --git a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn deleted file mode 100644 index 4acf81e7b..000000000 --- a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__.mdwn +++ /dev/null @@ -1,106 +0,0 @@ -### Please describe the problem. -Git-annex with v6 repo causes weird file creation behavior. - -### What steps will reproduce the problem? -On central repo: - git init --bare central6 - cd central6 - git annex init origin - git annex upgrade -On Client A - git clone {central6 repo path/URI} - cd central6 - git annex init clientA6 - git annex upgrade -On Client B - git clone {central6 repo path/URI} - cd central6 - git annex init clientB6 - git annex upgrade -Start assistant on both clients. -Start webapp on both clients. -Add files to both clients. -Wait for assistant to sync new files. -Force sync with webapp on both clients - -At this point examine files coming from the central repo on the non-originating client. I see: -Client A originated file: --rw-rw-r--. 1 user group 92528731 May 10 20:16 image.png -Client B created file: --rw-rw-r--. 1 user group 103 May 10 20:21 image.png - -Here's the content of Client B's file: -/annex/objects/SHA256E-s92528731--098928032fddbd0327c1d608249a133e276a00b8aa8bffca371bd32bded49777.png - -### What version of git-annex are you using? On what operating system? -Linux (Fedora 23/CentOS 7) -[[!format sh """ -git-annex version: 6.20160428-g1f253e8 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# Client B -[2016-05-10 20:09:51.879642] main: starting assistant version 6.20160428-g1f253e8 -[2016-05-10 20:09:52.127709] Cronner: You should enable consistency checking to protect your data. -[2016-05-10 20:09:57.340186] TransferScanner: Syncing with origin -(scanning...) [2016-05-10 20:09:58.182781] Watcher: Performing startup scan -(started...) - -merge: refs/remotes/origin/master - not something we can merge - -merge: refs/remotes/origin/synced/master - not something we can merge -gpg: Signature made Thu 28 Apr 2016 10:44:48 AM EDT using DSA key ID 89C809CB -gpg: /tmp/git-annex-gpg.tmpOTZtDq/trustdb.gpg: trustdb created -gpg: Good signature from "git-annex distribution signing key (for Joey Hess) <id@joeyh.name>" -gpg: WARNING: This key is not certified with a trusted signature! -gpg: There is no indication that the signature belongs to the owner. -Primary key fingerprint: 4005 5C6A FD2D 526B 2961 E78F 5EE1 DBA7 89C8 09CB -git-annex: Daemon is already running. -[2016-05-10 20:21:19.633914] main: Syncing with origin -From /smb/r7000/USB_Storage/tmp/git-annex/central6 - 7f1d48c..3e6f240 git-annex -> origin/git-annex - * [new branch] master -> origin/master - * [new branch] synced/git-annex -> origin/synced/git-annex - * [new branch] synced/master -> origin/synced/master -(merging origin/git-annex into git-annex...) -(recording state in git...) - -Already up-to-date. -[2016-05-10 20:21:23.337732] Pusher: Syncing with origin -To /smb/r7000/USB_Storage/tmp/git-annex/central6 - 3e6f240..358afc3 git-annex -> synced/git-annex -[2016-05-10 20:21:25.056294] Committer: Adding image.png -add image.png ok -[2016-05-10 20:21:25.543293] Committer: Committing changes to git -(recording state in git...) - -SHA256E-s103--d7d52e9de4a9c7c030743825c3a1ca072062e4ccadefcf1eb34be3004360b9b2.png - 103 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1) -(checksum...) [2016-05-10 20:21:27.240904] Transferrer: Uploaded image.png -[2016-05-10 20:21:27.787233] Pusher: Syncing with origin -[2016-05-10 20:21:28.12119] Committer: Adding image.png -(recording state in git...) -add image.png ok -[2016-05-10 20:21:28.696135] Committer: Committing changes to git -(recording state in git...) -To /smb/r7000/USB_Storage/tmp/git-annex/central6 - 358afc3..e3ef364 git-annex -> synced/git-annex - 15d9319..976e99f master -> synced/master -[2016-05-10 20:21:32.584488] Pusher: Syncing with origin -Everything up-to-date - -# End of transcript or log. -"""]] - -### 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) -It seems to work really well on v5, but the v6 file "corruption" is difficult to recover from. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__/comment_1_b11a50f945002f536ca43b181195c580._comment b/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__/comment_1_b11a50f945002f536ca43b181195c580._comment deleted file mode 100644 index bde9b1930..000000000 --- a/doc/bugs/Central_annex_+_assistant_+_v6___61___weirdness__63__/comment_1_b11a50f945002f536ca43b181195c580._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-12T19:15:28Z" - content=""" -I'd recommend not using the assistant with v6 repos yet. v6 is -still considered experimental. - -In v6 mode, the "/annex/objects/" file content means that an unlocked file's -content is not locally available yet. - -I reproduced this, and here's the log for a single file "bar" which was -created on clientA: - -<pre> -commit 2806e7c46e1df2bfd35ae22cf399a222957caa83 -Author: Joey Hess <joeyh@joeyh.name> -Date: Thu May 12 15:18:28 2016 -0400 - - git-annex in clientB - - bar | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -commit 99160180e14d3920e2b7ce4ded12b86057a8923f -Author: Joey Hess <joeyh@joeyh.name> -Date: Thu May 12 15:18:24 2016 -0400 - - git-annex in clientA - - bar | 1 + - 1 file changed, 1 insertion(+) -</pre> - -So, it looks like clientB changed it for some reason. - - -/annex/objects/SHA256E-s30--325229d85342c107421616848843592c2c1335d4d4e429b2805765af07de59be - +/annex/objects/SHA256E-s93--7493e6fd3acc936ff943283df9aa82ba3ad5f94e3c3168c2599f4fdf9a8c504d - -And, 7493e6fd3acc936ff943283df9aa82ba3ad5f94e3c3168c2599f4fdf9a8c504d is the sha256sum of -"/annex/objects/SHA256E-s30--325229d85342c107421616848843592c2c1335d4d4e429b2805765af07de59be\n", so -it's getting confused and re-adding pointer files, it seems. -"""]] diff --git a/doc/bugs/Doesn__39__t_build_with_QuickCheck_2.8.2.mdwn b/doc/bugs/Doesn__39__t_build_with_QuickCheck_2.8.2.mdwn deleted file mode 100644 index 9293ee530..000000000 --- a/doc/bugs/Doesn__39__t_build_with_QuickCheck_2.8.2.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. -I am getting build errors when trying to compile git-annex with QuickCheck 2.8.2. - -### What steps will reproduce the problem? -Build git-annex with QuickCheck 2.8.2, and get the following errors: - - - [ 30 of 535] Compiling Utility.QuickCheck ( Utility/QuickCheck.hs, dist/build/git-annex/git-annex-tmp/Utility/QuickCheck.o ) - - Utility/QuickCheck.hs:24:10: - Duplicate instance declarations: - instance (Arbitrary k, Arbitrary v, Eq k, Ord k) => - Arbitrary (M.Map k v) - -- Defined at Utility/QuickCheck.hs:24:10 - instance [safe] (Ord k, Arbitrary k, Arbitrary v) => - Arbitrary (M.Map k v) - -- Defined in `Test.QuickCheck.Arbitrary' - - Utility/QuickCheck.hs:27:10: - Duplicate instance declarations: - instance (Arbitrary v, Eq v, Ord v) => Arbitrary (S.Set v) - -- Defined at Utility/QuickCheck.hs:27:10 - instance [safe] (Ord a, Arbitrary a) => Arbitrary (S.Set a) - -- Defined in `Test.QuickCheck.Arbitrary' - -### What version of git-annex are you using? On what operating system? -git-annex 6.20160114, on Arch Linux x86_64. - -### 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 built fine with QuickCheck 2.8. I didn't test with 2.8.1, though. - -> ifdefed those instances out with this version of quickcheck. [[done]] -> --[[Joey]] diff --git a/doc/bugs/External_special_remote_broken__63__.mdwn b/doc/bugs/External_special_remote_broken__63__.mdwn deleted file mode 100644 index b217e143b..000000000 --- a/doc/bugs/External_special_remote_broken__63__.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -[[!meta title="encrypted key not checked when resuming upload to chunked encrypted special remote"]] - -### Please describe the problem. - -Resuming an upload seems not to work when used with chunking. Here is some sample conservation: - - - - - [2016-04-26 21:26:14.465287] chat: git-annex-remote-rclone [] - [2016-04-26 21:26:14.468527] git-annex-remote-rclone --> VERSION 1 - [2016-04-26 21:26:14.468726] git-annex-remote-rclone <-- PREPARE - [2016-04-26 21:26:14.469533] git-annex-remote-rclone --> GETCONFIG prefix - [2016-04-26 21:26:14.469741] git-annex-remote-rclone <-- VALUE annex.datengrotte - [2016-04-26 21:26:14.475725] git-annex-remote-rclone --> GETCONFIG target - [2016-04-26 21:26:14.47597] git-annex-remote-rclone <-- VALUE hubic - [2016-04-26 21:26:14.481164] git-annex-remote-rclone --> PREPARE-SUCCESS - [2016-04-26 21:26:14.485361] git-annex-remote-rclone <-- CHECKPRESENT GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55 - [2016-04-26 21:26:14.485831] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55 - [2016-04-26 21:26:14.485937] git-annex-remote-rclone <-- VALUE GM/2k/ - [2016-04-26 21:26:25.571228] git-annex-remote-rclone --> CHECKPRESENT-FAILURE GPGHMACSHA1--2a63df425e9d018adbc9a6e508817c727e414d55 - [2016-04-26 21:26:25.5726] git-annex-remote-rclone <-- CHECKPRESENT SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4 - [2016-04-26 21:26:25.57296] git-annex-remote-rclone --> DIRHASH SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4 - [2016-04-26 21:26:25.573207] git-annex-remote-rclone <-- VALUE 1v/zK/ - [2016-04-26 21:26:27.392524] git-annex-remote-rclone --> CHECKPRESENT-FAILURE SHA256E-s2885269915-S104857600-C1--186620a13bc048d4c9d75ec3a504f9569e5a43047342be5e5279b14b0c445fa6.mp4 - [2016-04-26 21:26:27.393076] chat: gpg ["--quiet","--trust-model","always","--batch","--passphrase-fd","23","--symmetric","--force-mdc","--no-textmode"] - [2016-04-26 21:26:31.103132] git-annex-remote-rclone <-- TRANSFER STORE GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 ../.git/annex/tmp/GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 - [2016-04-26 21:26:31.103773] git-annex-remote-rclone --> DIRHASH GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100 - [2016-04-26 21:26:31.103888] git-annex-remote-rclone <-- VALUE 8Q/Z9/ - - - - - -There are some steps that do not get in my mind: - -1. What is the first "CHECKPRESENT GPGHMACSHA1" good for? The full file including all chunks? -2. Second: Why is git-annex looking for "CHECKPRESENT SHA256E", the plain file (not encrypted)? -3. And now the 'real' problem: git-annex does a "TRANSFER STORE" of some key, but does not first check with CHECKPRESENT if it's there. And indeed, this file is already in the repo, so a "CHECKPRESENT GPGHMACSHA1--48e285fd650dac05eefa328bfbe8efd8a0ca2100" would return true in my case. Therefore it reuploads all my data, which is not so great ;P. - -### What version of git-annex are you using? On what operating system? - -it-annex version: 6.20160418-geff8673 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment b/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment deleted file mode 100644 index 7fb3b08e5..000000000 --- a/doc/bugs/External_special_remote_broken__63__/comment_1_904a186a6400506303cad772ac1a6751._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-27T16:23:43Z" - content=""" -Reproduced this using a directory special remote. - -The first checkpresent is because a file can be present on a remote in -non-chunked form, since a remote can be reconfigured to add chunking. -So it's nothing to worry about. - -The lack of encryption of the key when checking to resume is definitely a -bug. A bit of a security bug too. -(I double checked the other operations and they all encrypt keys) -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications.mdwn b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications.mdwn deleted file mode 100644 index d4dcc26e3..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications.mdwn +++ /dev/null @@ -1,138 +0,0 @@ -The Date resolution of the FAT filesystem is only 2 seconds for the "last modified time." -This leads to the strange behaviour, that after umount and remount of an usb drive (direct mode) git-annex thinks that suddenly approx. 50% of -the files are modified. (after remount the "seconds" appears to be rounded to even values - the inode cache before unmount had 1 second resolution) So git-annex is not real "guilty" but it would be fine to create a "workaround" for this problem... - -Possible the best solution for this is to set even values for the seconds in the filesystem and in annex internal tables direct after the `git annex get`. -Other solution would be to treat differences up to 1s in modification time as unmodified or create an new parameter like rsync's "modify-window" for this. To do an `git annex sync` or `git annex add` is in my opinion not a good option, because one could add so Bad file content by accident... - -Here's an konsole session to show this behaviour: - - $ mount /mnt/transfer/ - $ git clone source/ /mnt/transfer/transfer-repo - - Klone nach '/mnt/transfer/transfer-repo'... - Fertig. - - $ cd /mnt/transfer/transfer-repo/ - $ git annex init "test" - - init test - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. - ok - (Recording state in git...) - - $ git annex group here transfer - - group here (merging origin/git-annex into git-annex...) - (Recording state in git...) - ok - (Recording state in git...) - - $ git annex wanted here standard - - wanted here ok - (Recording state in git...) - - $ git annex get --auto - - get n01.mp3 (from origin...) - SHA256E-s1159018--5674452792970dc03e9ba47d3a8af5ad7c8da6b3ca19e8e64b9a4cf462d4a92d.mp3 - 1159018 100% 82.62MB/s 0:00:00 (xfer#1, to-check=0/1) - - sent 1159308 bytes received 31 bytes 2318678.00 bytes/sec - total size is 1159018 speedup is 1.00 - ok - - get n02.mp3 (from origin...) - SHA256E-s1622113--03998dc10c4839d5ab9aeaceaa63f0363c9d728aaaca2a2707f025c7b9e920a3.mp3 - 1622113 100% 34.45MB/s 0:00:00 (xfer#1, to-check=0/1) - - sent 1622459 bytes received 31 bytes 3244980.00 bytes/sec - total size is 1622113 speedup is 1.00 - ok - - ... - ... - - –--> All 29 files (n01.mp3 to n29.mp3) successfully got - - (Recording state in git...) - - $ git annex status - $ stat * >../stat-before-umount - $ cd / - $ umount /mnt/transfer - $ mount /mnt/transfer - $ cd /mnt/transfer/transfer-repo - $ stat * >../stat-after-remount - $ git annex status - M n05.mp3 - M n10.mp3 - M n11.mp3 - M n13.mp3 - M n16.mp3 - M n17.mp3 - M n20.mp3 - M n22.mp3 - M n23.mp3 - M n24.mp3 - M n26.mp3 - M n27.mp3 - $ diff -u ../stat-before-umount ../stat-after-remount | grep -B8 "+Modifiziert" | grep -E "Datei:|Modifi" - - Datei: „n05.mp3“ - -Modifiziert: 2014-05-03 19:42:39.000000000 +0200 - +Modifiziert: 2014-05-03 19:42:38.000000000 +0200 - - Datei: „n10.mp3“ - -Modifiziert: 2014-05-03 19:43:05.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:04.000000000 +0200 - - Datei: „n11.mp3“ - -Modifiziert: 2014-05-03 19:43:07.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:06.000000000 +0200 - - Datei: „n13.mp3“ - -Modifiziert: 2014-05-03 19:43:15.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:14.000000000 +0200 - - Datei: „n16.mp3“ - -Modifiziert: 2014-05-03 19:43:21.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:20.000000000 +0200 - - Datei: „n17.mp3“ - -Modifiziert: 2014-05-03 19:43:29.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:28.000000000 +0200 - - Datei: „n20.mp3“ - -Modifiziert: 2014-05-03 19:43:53.000000000 +0200 - +Modifiziert: 2014-05-03 19:43:52.000000000 +0200 - - Datei: „n22.mp3“ - -Modifiziert: 2014-05-03 19:44:13.000000000 +0200 - +Modifiziert: 2014-05-03 19:44:12.000000000 +0200 - - Datei: „n23.mp3“ - -Modifiziert: 2014-05-03 19:44:23.000000000 +0200 - +Modifiziert: 2014-05-03 19:44:22.000000000 +0200 - - Datei: „n24.mp3“ - -Modifiziert: 2014-05-03 19:44:31.000000000 +0200 - +Modifiziert: 2014-05-03 19:44:30.000000000 +0200 - - Datei: „n26.mp3“ - -Modifiziert: 2014-05-03 19:44:35.000000000 +0200 - +Modifiziert: 2014-05-03 19:44:34.000000000 +0200 - - Datei: „n27.mp3“ - -Modifiziert: 2014-05-03 19:44:39.000000000 +0200 - +Modifiziert: 2014-05-03 19:44:38.000000000 +0200 - - -> fixed [[done]] --[[Joey]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment deleted file mode 100644 index fdd123103..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_10_13a35801805ea3d2d4428b1539f96b16._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="193.174.111.250" - subject="specification" - date="2014-06-11T05:43:02Z" - content=""" -What you suggested (to not add if exact 1s or exact 1h time difference and changed checksum) would do the trick but it's hard for the user to test if this really works as expected and it would be more secure and IMHO more clear to do it like this: - -If `git annex add` \"meets\" such files, `git annex add` should not really add / commit these pseudo-modified files but *only adapt the timestamps* (which make the software erroneously thinks the files were modified) to the vfat values. (if checksum is still correct) I guess the timestamps are in the annex branch. - -`git annex add` could - instead of write: \"add ok\" - only write: \"corrected timestamp ok - no need to add\" - -So the user sees whats really happen and after this these files appears again as what they are: unmodified. `git annex status` would say nothing (everything fine), and `git annex fsck` would checksum these files again. - -I suppose that the way i suggest is harder to code :-( Unfortunately I'm not a good coder and not experienced in haskell for sending a patch myself / the open source way... - - -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment deleted file mode 100644 index 2605d69ab..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_11_632456a0a1d399ee2bbac76b7d63a5f1._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 11" - date="2014-06-11T17:22:12Z" - content=""" -@martin, to the best of my knowledge and testing, what you're proposing `git annex add` do in this case is identical to what it already happens to do, except for the message displayed. - -Do you have an example of it not doing that? - -We seem to be talking past one-another, since I've now said three times this is what it does. And I've tested it twice. - -I don't think that the current behavior of add, or your suggested behavior (which again, happens to be nearly identical) is sufficient to close this bug report with. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment deleted file mode 100644 index 8d06ee857..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_12_e4d268f269cc1701736cc5a39719ac20._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 12" - date="2014-06-11T18:05:48Z" - content=""" -The resolution problem does not seems to affect Windows, at least not on NTFS. In my tests, the mtime is fully preserved across reboots there. - -However, any change to the timezone on Windows does manage to mess up all the timestamps. Presumably this same flawed approach is used for DST adjustments. - -Example from inode cache after a 1 hour time zone change, which forced git-annex add to re-checksum: - -<pre> ---1 2221 1395843799 -+-1 2221 1395847399 -</pre> - -Of course, not all time zones are 1 hour offset, so as a heuristic, treating timestamps +- 60*60*Int as the same, would be pretty bad. Instead, it would probably make sense, on windows, to normalize the timestamp, using the current time zone, to get to the UTC timestamp. (Of course on unix, a file's timestamp is always given in UTC.) - -Unfortunately, Data.Time.LocalTime.getCurrentTimeZone doesn't seem to really work on windows. It always returns UTC+1 in my tests. - -Anyway, I'm now looking at this as two separate problems, the Windows Time Zone Sucks problem and the FAT Metadata Sucks problem. They will probably have different solutions.. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment deleted file mode 100644 index 0428fadbd..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_13_962cd8d7280cbc1d61778d69f3a393f0._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="FAT MetaData Sucks: an approach" - date="2014-06-11T18:15:59Z" - content=""" -git-annex already deals with FAT metadata sucking by using the inode sentinal file, to detect when a FAT filesystem has been remounted with new random inodes, and so ignore apparent inode changes. - -So, when a InodeCache is compared in weak mode due to that, it could just treat all mtimes within 2 seconds as the same. This would limit the brain-damange to FAT. - -One problem with this idea is that it's specific to linux's handling of FAT, with its random inodes. A FAT mounted on windows will have -1 for the inodes across remounts. So this method can't detect if a filesystem on windows is FAT, and has the problem, or NTFS and not. - -But, I think the FAT side of this problem is also linux-specific. Linux dummies up good metadata for FAT, and then has to throw it away/degrade on unmount. Windows presumably uses real timestamps, with low resolution on FAT from the beginning. - -I don't know how eg OSX handles this. If it used constant inodes but cached higher resolution mtimes for FAT, this approach would not work there. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_14_5b3bb068b62b12c7cc7504836a8acf32._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_14_5b3bb068b62b12c7cc7504836a8acf32._comment deleted file mode 100644 index e3efdb6d0..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_14_5b3bb068b62b12c7cc7504836a8acf32._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 14" - date="2014-06-11T18:59:49Z" - content=""" -Opened a separate bug for [[Windows_file_timestamp_timezone_madness]]. - -Fixed FAT issue on Linux as discussed in my previous comment. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_15_5271ba4eed013adec8391ddfcc11eda8._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_15_5271ba4eed013adec8391ddfcc11eda8._comment deleted file mode 100644 index cace00555..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_15_5271ba4eed013adec8391ddfcc11eda8._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="89.183.21.108" - subject="In reply to comment 11" - date="2014-06-12T09:22:53Z" - content=""" -Dear joey, - -thanks a lot for fixing this! - -Only for this protocol (not to have the last word ;-) - -What `git annex add` already does now and what i suggested it could do better is indead the same (result) for uncorrupted files (the frequent case). -But i'am afraid, it could be slightly different if we deal with corrupted files. The preset behaviour would add this file, the suggested behaviour would not... - -But this discussion is history now - i'm lucky :-)) - -Now i do some tests with daylight savings time change - hopefully there are no problems! -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_1_7a536b79bae7d8f897f014d17dbb90b6._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_1_7a536b79bae7d8f897f014d17dbb90b6._comment deleted file mode 100644 index 0f23da162..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_1_7a536b79bae7d8f897f014d17dbb90b6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 1" - date="2014-05-13T16:50:57Z" - content=""" -A related issue is that a change from/to daylight-saving time will make files appear to be one hour older/younger. A modify-window couldn’t acommodate that. VFAT is really a huge pain… -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_2_349959a6daa722c8350f73feb0b27162._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_2_349959a6daa722c8350f73feb0b27162._comment deleted file mode 100644 index 7a78362a3..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_2_349959a6daa722c8350f73feb0b27162._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="89.183.46.169" - subject="Possible solution?" - date="2014-05-13T17:51:41Z" - content=""" -How about this quick'n dirty vfat compromise: - -For vfat only we do like this (at least for `git annex fsck` command, so that the user doesn't wonder about the strange effects of vfat and can repair this): - -if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\") -we treat this file as likely unmodified and check this via the normal checksum algorithm. - -if checksum is ok, we give a message to the user, that the \"file has only a vfat timestamp problem\" but has correct checksum and if the user decides to do so git annex sets the timestamp in the filesystem to the value from annex' internal tables... - -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_3_923fc470727ecf21f0bb368b0486b15d._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_3_923fc470727ecf21f0bb368b0486b15d._comment deleted file mode 100644 index 599927cd2..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_3_923fc470727ecf21f0bb368b0486b15d._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 3" - date="2014-06-05T17:06:40Z" - content=""" -> if we have an exact time difference of 1s (probably \"inode problem\") or 1h (\"utc problem\") we treat this file as likely unmodified and check this via the normal checksum algorithm. - -That sort of makes sense, but when is git-annex supposed to do that? - -If `git annex add`, it already checksums the file, and already stages no change if the file's checksum is the same. And if the user has told git-annex to add the file and it's changed, the presumption is they know it's changed and want to add the new version. - -> To do an git annex sync or git annex add is in my opinion not a good option, because one could add so Bad file content by accident... - -If not in add or sync, then when? - ----- - -I am actually having a hard time coming up with a scenario where this problem results in any more than extra checksumming work by git-annex. - -The only scenario I see is: The drive is unmounted, gets corrupted, is remounted, and this timestamp nonsense causes git-annex to think a file (that has already gotten corrupted) has in fact changed, so it commits the corrupted version. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_4_68a8434018430a0d2671c4e23e9a3b12._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_4_68a8434018430a0d2671c4e23e9a3b12._comment deleted file mode 100644 index 32abc28c2..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_4_68a8434018430a0d2671c4e23e9a3b12._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="193.174.111.250" - subject="It confuses users" - date="2014-06-05T19:05:12Z" - content=""" -Other scenario: User thinks, that his usb drive has a problem, because approx. 50% of the files are gone/changed without obvious reason. I spent several hours to find the reason for this... I think we should at least give kind of explanation/warning message to the user -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_5_0b7d69489b9f10bb5ed617b5b62ae063._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_5_0b7d69489b9f10bb5ed617b5b62ae063._comment deleted file mode 100644 index dc27808bb..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_5_0b7d69489b9f10bb5ed617b5b62ae063._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="193.174.111.250" - subject="another scenario" - date="2014-06-05T19:52:04Z" - content=""" -If a user uses such a crippled filesystem as a transfer repo and he does an `git-annex get --auto` on the target pc for getting the content he gets only 50% of the content. (user gets only a strange message that git-annex cannot access the repo or something like this) The user does not have the intuition to do an extra `git-annex add` to get the content because from his perspective he did not made any changes... (sorry for my bad english - i hope you know what i mean) -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment deleted file mode 100644 index 94cbad0e6..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_6_650d950da065eeac966c2498418c668d._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="89.183.56.177" - subject="use case and answer to joey's question "...then when..."" - date="2014-06-08T04:59:42Z" - content=""" -Hi joey, - -i really think we should repair the timestamp instead of force the user to `git-annex add` possibly corrupted files/content (see your comment above) git-annex checksums are excellent for data integrity but they are useless if we bypass them in case of adding and propagating -potentially corrupted content with `git-annex add` - -So here's for example a useful use case: - -1. user fills his transfer repo in town A. He checks (`git annex fsck`) that everything is fine. He unmounts the drive and travels to town B. - -2. In town B user mounts the drive and sees, that he suddenly doesn't have \"access\" to those \"crippled files\" on his transfer repo (the files seems modified for the user without a reason - why should he `git-annex add` them again?? - he'd rather think about data corruption) . He wonders whats going on and thats why he does a - -3. `git-annex fsck` . `git annex fsck` should checksum also such crippled files, should report correct checksums if they are correct (so that the users knows their usb drive is working properly) and should give a message like this: \"checksum ok - crippled timestamp - repair with git-annex fsck --repair-timestamp or define a modify window \"- (to be implemented - in rsync the problem is already solved with this option \"--modify-window=NUM compare mod-times with reduced accuracy\") - -In my case distance between town B and town A was approx 400km and in town B i didnt know what was going on. So i went back to town A without success for further investigation of my usb drive... :-(( - -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_7_834c512e32ad5a157d8fa9fd472831b4._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_7_834c512e32ad5a157d8fa9fd472831b4._comment deleted file mode 100644 index 7a98be0a2..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_7_834c512e32ad5a157d8fa9fd472831b4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 7" - date="2014-06-09T19:29:09Z" - content=""" -A transfer repository is normally bare, so would not have this problem. -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_8_2500e6f9545b916dfa41549140c053fd._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_8_2500e6f9545b916dfa41549140c053fd._comment deleted file mode 100644 index 193038472..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_8_2500e6f9545b916dfa41549140c053fd._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="martin" - ip="89.183.78.73" - subject="`git-annex add` (called by sync) should do the job and bring the files back home (IMHO)" - date="2014-06-10T15:58:25Z" - content=""" -If one does an `git annex sync` these crippled-pseudo-modified-files are *automatically* `git annex add`ed - - git annex status - M datei1 - M datei5 - M datei6 - git annex sync - commit add datei1 ok - add datei5 ok - add datei6 ok - -To avoid the risk of adding and propagating potentially corrupted content `git-annex add` should -\"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp -difference of 1s or 1h - -With this procedure i would have better sleep with this personal second use case: - -repo1: on the computer (direct mode - client) -repo2: on usb stick - (direct mode - client - vfat - music for car) - -From time to time mp3 files are transferred to the stick. Then stick -goes to the car and after some days back to the computer to be -synchronized again. Everytime approx. 50% of the recently new added files are -added again (via sync) because of these nonsens timestamps. - -So i think, the clean solution is to correct only the timestamps instead -of adding again possibly corrupted files. If we dont do this users adapt to -add files again and again (they need not to be added) and one day they -add corrupted content. Like on windows (tm) you klick OK and OK again and -here you add again and again and one day one add once too much ;-) - -Excuse me for this long comment... - -P.S. git annex is an ingenious piece of software - thanks a lot for this joey! -"""]] diff --git a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_9_e2dc3ff80bbd66837f00975b16e17126._comment b/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_9_e2dc3ff80bbd66837f00975b16e17126._comment deleted file mode 100644 index 44ac459c0..000000000 --- a/doc/bugs/FAT__58___Date_resolution_for_mtime_2s--__62___implications/comment_9_e2dc3ff80bbd66837f00975b16e17126._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 9" - date="2014-06-10T19:27:55Z" - content=""" -> To avoid the risk of adding and propagating potentially corrupted content git-annex add should \"simply\" correct the timestamps (adjust to the new even inode values) for files with correct checksum but timestamp difference of 1s or 1h - -Since git-annex add already does that in this case, I think what you're actually suggesting is that, if the timestamp has a 1s or 1h diff, but the checksum has changed, git-annex add should refuse to add the files, on the grounds that it appears to be corrupt. Which obviously fails badly in at least the 1h case, because someone could add a file, then wait 1 hour and git-annex add a modified version. -"""]] diff --git a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12.mdwn b/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12.mdwn deleted file mode 100644 index 161221e47..000000000 --- a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12.mdwn +++ /dev/null @@ -1,28 +0,0 @@ - - [365 of 557] Compiling Assistant.WebApp.Form ( Assistant/WebApp/Form.hs, dist/build/git-annex/git-annex-tmp/Assistant/WebApp/Form.o ) - - Assistant/WebApp/Form.hs:61:60: error: - * Exception when trying to run compile-time code: - " - <a .btn .btn-default data-toggle="collapse" data-target="##{ident}">#{toggle}</a> - <div ##{ident} .collapse> - ^{note} - " (line 2, column 45): - unexpected "d" - expecting ">" - CallStack (from HasCallStack): - error, called at ./Text/Hamlet.hs:421:21 in shakespeare-2.0.12-4ppL9xZ9sKD6RsPGnrhiq:Text.Hamlet - Code: Language.Haskell.TH.Quote.quoteExp - whamlet - "\n\ - \<a .btn .btn-default data-toggle=\"collapse\" data-target=\"##{ident}\">#{toggle}</a>\n\ - \<div ##{ident} .collapse>\n\ - \ ^{note}\n" - * In the quasi-quotation: - [whamlet| - <a .btn .btn-default data-toggle="collapse" data-target="##{ident}">#{toggle}</a> - <div ##{ident} .collapse> - ^{note} - |] - -[[done]] diff --git a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_1_5a8a92244018618134d1851c561c54c6._comment b/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_1_5a8a92244018618134d1851c561c54c6._comment deleted file mode 100644 index fbb799870..000000000 --- a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_1_5a8a92244018618134d1851c561c54c6._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-27T21:19:35Z" - content=""" -Seems that it's choking on the data-target arrtibute. - -Is that legal HTML? It's used by Bootstrap. - -In any case, it's strange that the new minor version of -Hamlet started choking on that when it didn't before. - -See upstream issue which has a fix already: -<https://github.com/yesodweb/shakespeare/issues/200> -"""]] diff --git a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_2_007f09c0bd8bb64a8e2c8f60b1a71612._comment b/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_2_007f09c0bd8bb64a8e2c8f60b1a71612._comment deleted file mode 100644 index 8c914ebf4..000000000 --- a/doc/bugs/Failed_to_compile_with_shakespeare_2.0.12/comment_2_007f09c0bd8bb64a8e2c8f60b1a71612._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~felixonmars" - nickname="felixonmars" - avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" - subject="comment 2" - date="2016-12-28T03:04:52Z" - content=""" -Thank you. I have patched shakespeare with that patch, and all went fine afterwards. -"""]] diff --git a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex.mdwn b/doc/bugs/Files_in___34__here__34___not_known_to_git_annex.mdwn deleted file mode 100644 index 6fd47cc5a..000000000 --- a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex.mdwn +++ /dev/null @@ -1,52 +0,0 @@ -### Please describe the problem. - -Not sure how I created this mess. But here, I have my git annex repository: - - $ cat .git/config - [annex] - uuid = 206e9fb3-0c68-4c45-a3d7-dad1d9425d28 - version = 5 - -And judging from this, I would expect the file to be present: - - $ git annex log Movies/Bad\ Taste\ -\ Englisch.avi - - 2015-10-28 20:51:42 Movies/Bad Taste - Englisch.avi | f53b3f8a-0f04-11e1-93ae-136c6986c818 -- jeff-media [kent] - + 2014-10-13 00:12:50 Movies/Bad Taste - Englisch.avi | 206e9fb3-0c68-4c45-a3d7-dad1d9425d28 -- 1T - + 2011-12-24 13:38:23 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G - - 2011-12-18 14:59:38 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G - + 2011-12-18 12:48:17 Movies/Bad Taste - Englisch.avi | 9dd8c662-296d-11e1-b28a-f3c66fd5e263 -- 500G - + 2011-11-14 22:15:57 Movies/Bad Taste - Englisch.avi | f53b3f8a-0f04-11e1-93ae-136c6986c818 -- jeff-media [kent] - $ ls -l Movies/Bad\ Taste\ -\ Englisch.avi - lrwxrwxrwx 1 jojo jojo 135 Okt 7 2014 Movies/Bad Taste - Englisch.avi -> ../.git/annex/objects/Wx/P0/WORM-s723351552-m1100368371--Bad Taste - Englisch.avi/WORM-s723351552-m1100368371--Bad Taste - Englisch.avi - $ ls -shL Movies/Bad\ Taste\ -\ Englisch.avi - 690M Movies/Bad Taste - Englisch.avi - -But git annex seems to be very confused: - - $ git annex whereis Movies/Bad\ Taste\ -\ Englisch.avi - whereis Movies/Bad Taste - Englisch.avi (0 copies) failed - git-annex: whereis: 1 failed - $ git annex list Movies/Bad\ Taste\ -\ Englisch.avi - here - |kent-direct - ||kent - |||web - ||||bittorrent - ||||| - _____ Movies/Bad Taste - Englisch.avi - $ git annex fsck Movies/Bad\ Taste\ -\ Englisch.avi - fsck Movies/Bad Taste - Englisch.avi (fixing location log) - ** No known copies exist of Movies/Bad Taste - Englisch.avi - failed - (recording state in git...) - git-annex: fsck: 1 failed - -The `fsck` call does not change anything about the problem. - -File system is ext4. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20151019-1, Debian unstable. - -> improved fsck output [[done]] --[[Joey]] diff --git a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_1_d72e2db413d0bc4179c50eaf7550f071._comment b/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_1_d72e2db413d0bc4179c50eaf7550f071._comment deleted file mode 100644 index 52e5f268e..000000000 --- a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_1_d72e2db413d0bc4179c50eaf7550f071._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-02T15:28:09Z" - content=""" -All the output of `git annex log`, `git annex whereis` and `git annex list` -seems internally consistent. Which makes sense as there are 3 different -views of the exact same data. Note that while `git annex log` -shows 2 repositories "1T" and "500G" that contain the file, I guess those -are both marked as dead, since whereis skipps dead repos and doesn't -show them. So, that's all red herrings. - -The problem then is that fsck seems to say "fixing location log" but then -apparently doesn't fix it, since it still complains the file is missing -despite its contents being present. - -I have replicated the situation but I don't reproduce that happening: - - joey@darkstar:~/tmp/r>git annex setpresentkey WORM-s30-m1446479598--Bad\ Taste\ -\ Englisch.avi ebce24f6-3a26-4881-8855-62a0e0d33869 0 - setpresentkey WORM-s30-m1446479598--Bad Taste - Englisch.avi ok - joey@darkstar:~/tmp/r>git annex whereis Movies/Bad\ Taste\ -\ Englisch.avi - whereis Movies/Bad Taste - Englisch.avi (0 copies) failed - git-annex: whereis: 1 failed - joey@darkstar:~/tmp/r>git annex fsck - fsck Movies/Bad Taste - Englisch.avi (fixing location log) ok - (recording state in git...) - joey@darkstar:~/tmp/r>git annex whereis - whereis Movies/Bad Taste - Englisch.avi (1 copy) - ebce24f6-3a26-4881-8855-62a0e0d33869 -- joey@darkstar:~/tmp/r [here] - ok - -Please show the commit that fsck makes to the git-annex branch. Ie, -`git show git-annex` after running fsck. In my example above, that commit included: - - --- a/33f/807/WORM-s30-m1446479598--Bad Taste - Englisch.avi.log - +++ b/33f/807/WORM-s30-m1446479598--Bad Taste - Englisch.avi.log - @@ -1 +1 @@ - -1446479600.453526s 0 ebce24f6-3a26-4881-8855-62a0e0d33869 - +1446479680.344119s 1 ebce24f6-3a26-4881-8855-62a0e0d33869 - -"""]] diff --git a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_2_10b21c1565759c687b562721ed2cc5b8._comment b/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_2_10b21c1565759c687b562721ed2cc5b8._comment deleted file mode 100644 index 566ff56bb..000000000 --- a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_2_10b21c1565759c687b562721ed2cc5b8._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://www.joachim-breitner.de/" - nickname="nomeata" - subject="comment 2" - date="2015-11-07T09:02:08Z" - content=""" -> I guess those are both marked as dead, since whereis skipps dead repos and doesn't show them. - -Well, only `500G` should be marked as dead, not `1T` – that is the repository I am working in!... - -And indeed, `git annex semitrust 1T` solved it. - -Maybe at one point I had re-used uuids, because I was copying repositories? - -So this might have been an issue with PEBKAC, although maybe git-annex could warn, for examle in `git annex fsck` or in other commands, if the current repository is marked dead, or in `git annex sync` if very much alive looking remotes are marked as dead. -"""]] diff --git a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_3_3b94625acd0fda06545243d9c163cfba._comment b/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_3_3b94625acd0fda06545243d9c163cfba._comment deleted file mode 100644 index b08ecd052..000000000 --- a/doc/bugs/Files_in___34__here__34___not_known_to_git_annex/comment_3_3b94625acd0fda06545243d9c163cfba._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-11-10T18:06:36Z" - content=""" -Aha, there is a bug indeed; fscking a dead repository always claims to -be "fixing location log", but the location log is fine and doesn't need -fixing. Fixed that. - -As to discovering when you're in a dead repository, there are a lot of -things that could be done, but most of them seem to add special cases -that are complicating both to implement and for parsing the resulting -output (like putting "(dead)" next to the description/name of a -dead repository). Seems reasonable to have fsck note when the repository -it's checking is dead, and leave it at that. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__.mdwn b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__.mdwn deleted file mode 100644 index d66196acd..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -### Please describe the problem. -Using the webapp to generate a new (local) repository instantly takes it to the following state: -[[!format sh """ -user@local:~/Annex$ git status -# On branch master -# Changes to be committed: -# (use "git reset HEAD <file>..." to unstage) -# -# deleted: uuid.log -# -user@local:~/Annex$ git branch - git-annex -* master -user@local:~/Annex$ git log -commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc -Author: local <user> -Date: Sun Nov 3 15:30:17 2013 +0100 - - created repository -user@local:~/Annex$ git show HEAD -commit 90bfcaf17b0576d8ecdc48ae44dda22d41464acc -Author: local <user> -Date: Sun Nov 3 15:30:17 2013 +0100 - - created repository - -diff --git a/uuid.log b/uuid.log -new file mode 100644 -index 0000000..9df3670 ---- /dev/null -+++ b/uuid.log -@@ -0,0 +1 @@ -+987e7b9a-aa9d-41db-ae92-23fcae7f6187 user@local:~/Annex timestamp=1383489017.181 -user@local:~/Annex$ -"""]] - -I'm new to git-annex, so I'm not quite sure, but looking at [[internals]] this file should only exist in the git-annex branch, not in master. Furthermore, from this state it seems impossible to get "sync with your other devices" to work, because of a merge conflict on this change. - -Perhaps some sort of a race-condition with the annex-assistant picking up the uuid.log file while the repository is being initialized? - -### What version of git-annex are you using? On what operating system? -Ubuntu 13.10 with git-annex 4.20130815 - -> [[fixed|done]]; see comments. (This fix needs to be backported to Ubuntu.) --[[Joey]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment deleted file mode 100644 index 6080e88e4..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_1_6441dd04adc158df22589c81746108a9._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 1" - date="2013-11-03T16:48:25Z" - content=""" -I can't reproduce this at all. What version of git do you have installed? Did you install git-annex from ubuntu's repository? Does the same thing happen if you install the standalone linux tarball and use it to make a new repository? - -git-annex never creates a file named uuid.log on disk, so it's quite strange that it shows up in the initial commit to the master branch. It sort of looks like somehow git-annex's normal use of a separate index file to stage the uuid.log to the git-annex branch is failing. Since I have never seen any problem with that, I have to suspect that the ubuntu build is somehow badly broken. Or that the git in Ubuntu is for some reason ignoring `GIT_INDEX_FILE`. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment deleted file mode 100644 index 50bff5f41..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_2_d1c5d7642284a375f9c455dbf76efa5c._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 2" - date="2013-11-03T17:02:47Z" - content=""" -I made an Ubuntu saucy chroot, apt-get installed git-annex from universe, and ran the webapp in there. I did not reproduce this problem. - -The cause of the problem, it seems, must be something local to your system. Perhaps you have an environment variable set that is messing up git. Or perhaps you have a different, broken version of git installed. - -Can you \"git show git-annex\" in the repository? It should show a commit made to the git-annex branch that adds the uuid.log there. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment deleted file mode 100644 index 7acab1c37..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_3_4b863da1c8ba73ad54da20f7d2ec6e5c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="tanen" - ip="83.128.159.25" - subject="comment 3" - date="2013-11-03T17:35:00Z" - content=""" -Very strange: this is on a machine that I wiped and reinstalled just a few hours ago, it's a completely fresh Ubuntu 13.10 install with barely anything installed but the defaults. Git version is 1.8.3.2-1 - -I initially just pulled git-annex from the Ubuntu repo. After that I grabbed a more recent version from https://launchpad.net/ubuntu/+source/git-annex/4.20131101/+build/5189754 which is showing the same behavior. - -\"git show git-annex\" indeed shows the commit creating the uuid.log file on the git-annex branch. master has just one commit, with description \"created repository\" and creates a \"uuid.log\" file. The contents of the master uuid.log are identical to the one in the git-annex branch. - -I'm currently in the middle of trying out a git-annex setup so I can't switch versions again right now, but given the above I imagine a fresh 13.10 VM should show the same behavior. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_4_8e0f489305ce30ad578b9f8526e86416._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_4_8e0f489305ce30ad578b9f8526e86416._comment deleted file mode 100644 index c020fc3a8..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_4_8e0f489305ce30ad578b9f8526e86416._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 4" - date="2013-11-06T15:09:19Z" - content=""" -Intriguing -- I was able to reproduce this bug after installing the Ubuntu server ISO in a VM. - -Which is really strange, the only difference between this and my debootstrapped chroot should be the kernel.. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment deleted file mode 100644 index a323d7835..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_5_c699034c8e02b2354516414d0ab73aab._comment +++ /dev/null @@ -1,53 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 5" - date="2013-11-06T16:27:49Z" - content=""" -Running the prebuilt tarball build of git-annex, the bug does not occur. - -However, if I remove the git shipped with the prebuilt tarball, so it uses the system git, I do see the bug. So, it's apparently git version dependent. - -Also, I was able to reproduce it in a amd64 chroot. My other chroot was i386. Somehow architecture specific bug? - ---- - -Instrumenting all calls to git to be logged with the full environment and command, I found this: - -<pre> -GIT_INDEX_FILE='/home/foo/annex/.git/annex/index' ---git-dir=/home/foo/annex/.git --work-tree=/home/foo/annex commit --quiet --allow-empty -m created repository -</pre> - -This certainly looks like the index file setting for the git-annex branch is somehow leaking out past the branch commit operations. It continued setting that while setting up `gc.auto`; the next call to git after that stopped setting the index file. - -The only way I can see offhand this could possibly happen is due to an exception. It may be that on ubuntu an exception is thrown by code that runs a git command with the index file set, for whatever reason, and this causes the code that normally resets it back to not run. - ----- - -Ok, found it! - -<pre> -\"withIndex entered\" - -*** Please tell me who you are. - -Run - - git config --global user.email \"you@example.com\" - git config --global user.name \"Your Name\" - -to set your account's default identity. -Omit --global to set the identity only in this repository. - -fatal: unable to auto-detect email address (got 'foo@darkstar.(none)') -\"withIndex entered\" -\"withIndex cleaned up\" -</pre> - -Note lack of clean up after the first withIndex call. Thus leaving the environment passed to git polluted for further calls. - -This also explains why it's only happening on some systems, or with some versions of git. git's got all kinds of complexity around its username and email handling code. - -I have fixed this in git. -"""]] diff --git a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_6_786cb7e643811dfd2496ceeff8f34f44._comment b/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_6_786cb7e643811dfd2496ceeff8f34f44._comment deleted file mode 100644 index ea3e97e8e..000000000 --- a/doc/bugs/Freshly_initialized_repo_has_staged_change___34__deleted__58___uuid.log__34__/comment_6_786cb7e643811dfd2496ceeff8f34f44._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 6" - date="2013-11-06T16:40:57Z" - content=""" -Ubuntu bug report about this: <https://bugs.launchpad.net/ubuntu/+source/git-annex/+bug/1248623> - -It should be pretty easy to backport the fix to the version in Ubuntu. The relevant git commits are ee23be55fd3e7e202bc721c124f78b79d1aba6df and 81117e8a9d19d4739d3773d0515006e1ea41c266 -"""]] diff --git a/doc/bugs/IPv6_literal_ssh_servers_break_git_annex_webapp.mdwn b/doc/bugs/IPv6_literal_ssh_servers_break_git_annex_webapp.mdwn deleted file mode 100644 index ae7809c33..000000000 --- a/doc/bugs/IPv6_literal_ssh_servers_break_git_annex_webapp.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -### Please describe the problem. -When trying to set up the Git Annex webapp to sync with an SSH server on Windows, specifying the remote server address ans an IPv6 literal address will result in an Internal Server Error like this: - -`C:\Users\anovak\.ssh\git-annex\key.git-annex-fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d-anovak_22_.2Fhome.2Fanovak.2Fannex: openFile: invalid argument (Invalid argument)` - -I think the problem is that it's not escaping the colons, and you can't have colons in a filename on Windows. - -### What steps will reproduce the problem? - -1. Have Git Annex Webapp runnign on Windows. -2. Go to the "Adding a remote server using ssh" page. -3. Enter an IPv6 literal address (in brackets), like `[fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d]`, under "Host name". I hyappen to be using cjdns addresses, but I bet you get the same issue with Internet addresses. -4. Add the server, and elect to combine repositories if prompted. -5. You should get the error. - -### What version of git-annex are you using? On what operating system? - -I have Git Annex: `Version: 6.20160613-g35dbe35` on Windows 7. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[2016-07-17 11:11:09.3554208] main: starting assistant version 6.20160613-g35dbe35 -Warning: Couldn't open /dev/urandom -Warning: using system clock for seed instead (quality will be lower) -Launching web browser on file://C:\Users\anovak\annex\.git\annex\webapp.html -[2016-07-17 11:11:09.482428] Cronner: You should enable consistency checking to protect your data. -(scanning...) [2016-07-17 11:11:09.7544436] Watcher: Performing startup scan -(started...) -recv: failed (No error) -recv: failed (No error) -recv: failed (No error) -(recording state in git...) -Generating public/private rsa key pair. -Your identification has been saved in C:\Users\anovak\AppData\Local\Temp\git-annex-keygen.0\key. -Your public key has been saved in C:\Users\anovak\AppData\Local\Temp\git-annex-keygen.0\key.pub. -The key fingerprint is: -SHA256:sNwb2o1rp2ycVaMvEOxKZa2g6YlYVuOtbty8xybl3Uc anovak@Asteria -The key's randomart image is: -+---[RSA 2048]----+ -| | -| | -| .. . | -| o..+= . o | -| o =o=So o . | -| o + oo==o E | -| + + *.*+=.o . | -|. . * =.X.+ o . | -| o. .B+o . . | -+----[SHA256]-----+ -17/Jul/2016:11:15:48 -0700 [Error#yesod-core] C:\Users\anovak\.ssh\git-annex\key.git-annex-fc2e:f79e:da52:bd92:74f8:b045:e365:5e9d-anovak_22_.2Fhome.2Fanovak.2Fannex: openFile: invalid argument (Invalid argument) @(yesod_IAZWSEWTVsBHH7DfZiTwkc:Yesod.Core.Class.Yesod .\Yesod\Core\Class\Yesod.hs:628:5) - -# End of transcript or log. -"""]] - -### 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) - -Yeah, it works great on my Linux machines. I'm just getting started with the web app, though; I'm trying to set up limited-access key-based SSH, and the web app seems to be also trying to do that... - -> Fixed by escaping the hostname when it contains any unusual characters. -> [[done]] --[[Joey]] diff --git a/doc/bugs/Installation_fails__58_____34__Duplicate_instance_declarations__34__.mdwn b/doc/bugs/Installation_fails__58_____34__Duplicate_instance_declarations__34__.mdwn deleted file mode 100644 index db02036f4..000000000 --- a/doc/bugs/Installation_fails__58_____34__Duplicate_instance_declarations__34__.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -[380 of 462] Compiling Assistant.WebApp.Types ( Assistant/WebApp/Types.hs, dist/build/git-annex/git-annex-tmp/Assistant/WebApp/Types.o ) - -Assistant/WebApp/Types.hs:157:10: - Duplicate instance declarations: - instance PathPiece Bool - -- Defined at Assistant/WebApp/Types.hs:157:10 - instance PathPiece Bool - -- Defined in `path-pieces-0.1.4:Web.PathPieces' -cabal: Error: some packages failed to install: -git-annex-5.20140709 failed during the building phase. The exception was: -ExitFailure 1 - - -### What steps will reproduce the problem? - -cabal install git-annex --bindir=$HOME/bin - - -### What version of git-annex are you using? On what operating system? -git-annex-5.20140709, Fedora 20 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Already fixed in git yesterday. [[done]] --[[Joey]] diff --git a/doc/bugs/Installing_from_git___58___local_doc_lacks_style.css.mdwn b/doc/bugs/Installing_from_git___58___local_doc_lacks_style.css.mdwn deleted file mode 100644 index db7d4cd03..000000000 --- a/doc/bugs/Installing_from_git___58___local_doc_lacks_style.css.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -### Please describe the problem. - -Installing from git : local doc has no style. -Unstyled local documentation is less easy to read than the one on http://git-annex.branchable.com/ . - -### What steps will reproduce the problem? - -Follow steps in http://git-annex.branchable.com/install/fromsource/ . -Open share/doc/git-annex/html/index.html in a browser. -All text has same appearance. -Style on branchable.com is minimal yet efficient (very good result-over-cost ratio). - -### What version of git-annex are you using? On what operating system? - -commit c075b58d40f2745e4b79c54e24edf9b94748d7e9 -Merge: 166d70d 455de2f -Author: Joey Hess <joeyh@joeyh.name> -Date: Fri Sep 30 19:52:14 2016 -0400 - - Merge branch 'master' of ssh://git-annex.branchable.com - -(actually commit ade6ab403701b25a540ffee2fbaae89db4473a2c though it most certainly does not change any code) - -OS is Debian 7.11 on AMD64. - -### Please provide any additional information below. - -Copying style.css from branchable.com brings styling. -Doc also refers to local.css which is only comments on branchable.com anyway. - -### 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) - -Been trying shortly git-annex a few times. Considering to put some important stuff inside now (1Tb photos/videos). I love git-annex concept and believes that you Joey have the eye for details that make rock-solid software possible (I do that for a living). I've been using Unison for about 15 years. Unison is nice enough for *sync* if storage devices are mounted always on same machine in same directory. For source code *history*, I've been relying on git with great satisfaction (and seen quite a few git repos wrecked by a missing or corrupted file in .git, good job remote repos come to the rescue). Since git allows to change remote URLs at any time and just work, I believe git-annex will bring the best of both worlds. Also I love your style: everything not essential is just not added, preserving efficiency. Best way for a solid system is adding only what's necessary. - -> Ok, I've added the ikiwiki underlay to get the style sheets. -> [[done]] --[[Joey]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID.mdwn b/doc/bugs/Internal_Server_Error__58___Unknown_UUID.mdwn deleted file mode 100644 index e8e802455..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. - -One of my repositories has no name: -http://screencast.com/t/3OjxFzpz - -And when I try to disable it I get this error: - - Internal Server Error - Unknown UUID - -When I try to delete it I get this error: - - Internal Server Error - unknown UUID; cannot modify - -I think this was the result of adding a Local Computer Repo, and then that computer signed off. Maybe. - -### What version of git-annex are you using? On what operating system? - -git-annex version 4.20130601-g2b6c3f2 -Mac OS 10.7.5 - -### Please provide any additional information below. - -Maybe it's a glitch that only will happen this once, the problem is I can't get rid of it! Are there anyways of manually getting rid of a repo with uid? - -> Also reported here: -> [[Missing_repo_uuid_after_local_pairing_with_older_annex]] and -> [[Internal_Server_Error_unknown_UUID;_cannot_modify]] -> and [[Local_network___40__ssh__41___fails_to_pair__47__sync]] -> and [[Internal_Server_Error:_Unknown_UUID]] -> --[[Joey]] - -[[!meta title="local pairing leads to unknown UUID"]] - -> This bug is [[fixed|done]]. The webapp will detect the problem and -> provides an interface to correct it. --[[Joey]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_1_f42f703a5d267557abf5e932f0890d4a._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_1_f42f703a5d267557abf5e932f0890d4a._comment deleted file mode 100644 index e8494ab17..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_1_f42f703a5d267557abf5e932f0890d4a._comment +++ /dev/null @@ -1,37 +0,0 @@ -[[!comment format=mdwn - username="carlo" - ip="118.208.1.126" - subject="comment 1" - date="2013-07-06T22:52:18Z" - content=""" -I got the same error. Local repo has no name but in the logs I can see that it's trying to make a local connection: - - [2013-07-07 08:29:51 EST] main: starting assistant version 4.20130627 - [2013-07-07 08:29:51 EST] TransferScanner: Syncing with arkham.local_annex - -(snip) - - 07/Jul/2013:08:41:56 +1000 [Error#yesod-core] Unknown UUID @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5) - ssh: Could not resolve hostname arkham.local: Name or service not known - ssh: Could not resolve hostname arkham.local: Name or service not known - fatal: The remote end hung up unexpectedly - git-annex: Unknown UUID - ssh: Could not resolve hostname arkham.local: Name or service not known - ssh: Could not resolve hostname arkham.local: Name or service not known - fatal: The remote end hung up unexpectedly - git-annex: Unknown UUID - ssh: Could not resolve hostname arkham.local: Name or service not known - ssh: Could not resolve hostname arkham.local: Name or service not known - fatal: The remote end hung up unexpectedly - git-annex: Unknown UUID - ssh: Could not resolve hostname arkham.local: Name or service not known - 07/Jul/2013:08:42:32 +1000 [Error#yesod-core] Unknown UUID @(yesod-core-1.2.3:Yesod.Core.Class.Yesod ./Yesod/Core/Class/Yesod.hs:471:5) - ssh: Could not resolve hostname arkham.local: Name or service not known - fatal: The remote end hung up unexpectedly - git-annex: Unknown UUID - ssh: Could not resolve hostname arkham.local: Name or service not known - -When I turn on arkham (the other laptop) I see transfers start up: - - -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_2_eb1999f99c5babf3fcb1ff5d72ea6db6._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_2_eb1999f99c5babf3fcb1ff5d72ea6db6._comment deleted file mode 100644 index 46fcc0898..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_2_eb1999f99c5babf3fcb1ff5d72ea6db6._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkeyfC88gIU4fsEqqkvhzVlSKDUxbtZaTE" - nickname="Selem" - subject="comment 2" - date="2013-07-10T01:41:24Z" - content=""" -I got the same problem (Mac OS X 10.8.4, whatever the latest download package, local computers same network repos) - -To get rid of the noname repo, I just removed git remote in the annex dir. - - # List remote - $ git remote -v - # Remove remote grabbed from running the previous command - $ git remote rm your_remote - -After that, I added the second computer repo successfully. - -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_3_bda72b0d615843d18d6ef21f833432a8._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_3_bda72b0d615843d18d6ef21f833432a8._comment deleted file mode 100644 index 3bdba306d..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_3_bda72b0d615843d18d6ef21f833432a8._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.246.110" - subject="I can't reproduce this problem, but I see several people have reported it." - date="2013-07-27T22:11:15Z" - content=""" -It would be helpful for anyone who can reproduce this problem to do so with debugging enabled on both sides - (run with --debug or turn it on in the Configuration page in webapp), and then send the `.git/annex/daemon.log` -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_4_651440cda405ad40a04479f5d87d581e._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_4_651440cda405ad40a04479f5d87d581e._comment deleted file mode 100644 index 87da8dc31..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_4_651440cda405ad40a04479f5d87d581e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~subito" - nickname="subito" - subject="Same here for SSH remotes" - date="2013-07-29T19:05:55Z" - content=""" -I get the problem while only adding an SSH remote. After deciding I want a git-repo on my server, it says \"Unknown UUID\" and created a remote with no name. I was unable to add any SSH remote (tried with two different servers and a couple different dirs - some completly unknown to my annex) - -I used the Android webapp btw - latest Version. The same version works fine on my Debian maschines. -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_5_21fa189b631c246ac5df16a49c3c0178._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_5_21fa189b631c246ac5df16a49c3c0178._comment deleted file mode 100644 index 1f42daf5f..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_5_21fa189b631c246ac5df16a49c3c0178._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="comment 5" - date="2013-07-30T16:59:50Z" - content=""" -@subito I have tried as hard as I can to reproduce this problem, and cannot. I need the debug information I asked for in my other comment to get any further on this bug report. -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_6_1f712693d2ded5abceb869fdb7f47ef3._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_6_1f712693d2ded5abceb869fdb7f47ef3._comment deleted file mode 100644 index 9e28682b4..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_6_1f712693d2ded5abceb869fdb7f47ef3._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="finally!" - date="2013-07-31T16:47:39Z" - content=""" -I've finally been clued in to the cause of this. If a ssh-agent is running, and has been configured to use a ssh key (by running `ssh-add`), this apparently prevents git-annex from using the key it sets up during local pairing. I have reproduced the described bug by this method. - -Something similar might also affect adding a remote ssh server, I'm not sure about that yet. - - -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_7_7a5ead0ce5c9429d4723ccce4f6a6d6c._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_7_7a5ead0ce5c9429d4723ccce4f6a6d6c._comment deleted file mode 100644 index 136bca8f4..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_7_7a5ead0ce5c9429d4723ccce4f6a6d6c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="workaround" - date="2013-07-31T17:19:01Z" - content=""" -Looks like the fix is to edit ~/.ssh/config and in each stanza added by git-annex, add this line: - - IdentitiesOnly yes - -This prevents the ssh-agent from using the normal key, and allows the git-annex key to be used instead. - -People experiencing this bug can manually make that change. Then if you edit your git-annex repository's `.git/config` and delete the `annex-ignore` line, the assistant should finally learn the UUID and start syncing. -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_8_a4683fd73ae452a9cd7f61d9930f6266._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_8_a4683fd73ae452a9cd7f61d9930f6266._comment deleted file mode 100644 index 54bd855cf..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_8_a4683fd73ae452a9cd7f61d9930f6266._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="comment 8" - date="2013-07-31T20:42:10Z" - content=""" -I've updated the webapp to display nicely when a repository has stalled being set up, rather than crashing. - -There's now an interface to check the status of such a stalled repository, and it will try to clean up after this bug too. -"""]] diff --git a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_9_ced3516c3e7161e4d7e599232f62a511._comment b/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_9_ced3516c3e7161e4d7e599232f62a511._comment deleted file mode 100644 index 4a99ee3ad..000000000 --- a/doc/bugs/Internal_Server_Error__58___Unknown_UUID/comment_9_ced3516c3e7161e4d7e599232f62a511._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnZEanlyzay_QlEAL0CWpyZcRTyN7vay8U" - nickname="Carlo" - subject="Tilde did it for me" - date="2013-10-06T21:59:43Z" - content=""" -I had exactly the same error message, \"Internal Server Error: Unknown UUID\", when I used a path starting with a tilde. Absolute path for home directory worked. -"""]] diff --git a/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn b/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn deleted file mode 100644 index d59f903e2..000000000 --- a/doc/bugs/Interrupted_command_broke_encfs_repository.mdwn +++ /dev/null @@ -1,56 +0,0 @@ -### Please describe the problem. - -I use git annex on my phone on an encfs directory on a debian root put on a sdcard. - -After an interruption, it may happens that git-annex (or git?) changes the -content of a file in the .git directory by a content in a file from the working -directory. - -[[!format sh """ -$ cat .git/config -../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG -$ cat .git/refs/remotes/master -../../../../.git/annex/objects/29/wQ/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG/SHA256E-s2533743--ec986bdbe37257bb5a940469d1e1b64a6016902736ed87315bab5856de322f42.JPG -"""]] - -I only experienced this behavior two or three times since I have been using git-annex (3 years ago). - -Everything else works fine and fsck indicates no problem with the sdcard. - -This is a strange behavior that is a pain to solve, but today, I experienced something -even stranger. - -Instead of writing the content into the .git/ directory. It was put in the encoded file in the crypt directory, with the path correctly encoded. - -[[!format sh """ -$ cat repo/.git/config -cat: repo/.git/config: Input/output error -$ encfsctl encode crypt_repo/ .git/config -CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW -$ cat crypt_repo/CqJBnbpfTEgKPAnmc8Sbo/IA-gS5lOzCF65DW9C7l-3MYU/OKritNqY4ewLnzQ,R2dtBXzW -../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0Txna5LM9CLDD6Pw8x5pZ7D5YKFdNb-yx4APrKVm,EXauZiDQoXo6qOuVCMUI4KJB9kdnprlZ4Bw7h7w2jogW7Q1GDpqKVSgk7VYLuk5D7CpdaslquWbg0Ci5e9k9T7 -$ encfs decode ../../../RSYdwqZh7kgnn3RSbEEx86ax/60jj4hZ60tqcDwSiXy-hHpD9/ebwg,0lJ7hi2iBbgF7HBfdqC/-muvnOVFmMIkfUtJAVyMGRUs/lRm4UHX0Dj2lW6IsCnnBBBSX/O9l1191uPE0a2D-FXhrOEG5,uWeGZHyJccAsw64vy16H3iTcRrxY-75YdRnnMzL27zpC5j0UUVnTaU0TBg0ze-xWCLpoJHZha48Uu8NaekYpn9C5QSSmUV08aZERdCdCfS3/GSOJ0 -../../../.git/annex/objects/f8/gZ/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG/SHA256E-s1455016--03aaa9bcccada56b6615d9e333b8ada2dd6d1fb14c4aacfac87271939377f537.JPG -"""]] - -### What steps will reproduce the problem? -Interruption of a git annex command, I guess an add or an import command. - -### What version of git-annex are you using? On what operating system? - -Android 4.3 Cyanogenmod/Samsung Galaxy S3, chrooted debian. - -[[!format sh """ -$ git annex version -git-annex version: 5.20141125 -build flags: Assistant Pairing Testsuite S3 Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web tahoe glacier ddar hook external -$ cat /etc/debian_version -8.0 -"""]] - -### Please provide any additional information below. -If you ask for additional information, I will gladly provide it. - -> Incremented my `encfs_is_shite` counter; [[done]] --[[Joey]] diff --git a/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment b/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment deleted file mode 100644 index 957fa568e..000000000 --- a/doc/bugs/Interrupted_command_broke_encfs_repository/comment_1_0b5fd2ca4b067becb930206e0ee82b3d._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-07-02T16:57:56Z" - content=""" -git-annex contains no code whatsoever that writes to .git/config. It relies -entirely on `git config` to write that file. I'm pretty sure that `git -config` doesn't contain code to write garbage (in this case a symlink -target belonging to another file) to the .git/config file either. - -The fact that you're having IO errors also points strongly at this being -a level above userspace, so either encfs or the SD card. I think your tech -stack contains at least one POS (namely encfs), and probably more problems -(SD card, whatever nonsense filesystem Android is using for it, etc). -"""]] diff --git a/doc/bugs/Interrupted_command_broke_encfs_repository/comment_2_fc57759cfcec0c454ab80ef8e324aa91._comment b/doc/bugs/Interrupted_command_broke_encfs_repository/comment_2_fc57759cfcec0c454ab80ef8e324aa91._comment deleted file mode 100644 index 2f1b0e43d..000000000 --- a/doc/bugs/Interrupted_command_broke_encfs_repository/comment_2_fc57759cfcec0c454ab80ef8e324aa91._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="konubinix" - subject="Thank you for your answer" - date="2015-07-08T19:33:35Z" - content=""" -The filesystem I use is ext4. I don't think the ext4 module of the linux kernel -present on my version of Android would be much different of the one on my -computer. - -Therefore I guess I shall investigate in encfs. It is a pity there is no -alternative allowing to keep a directory encrypted without requiring -administrative privileges. - -Thank you again. -"""]] diff --git a/doc/bugs/It__39__s_July_not_June.mdwn b/doc/bugs/It__39__s_July_not_June.mdwn deleted file mode 100644 index f2c91341f..000000000 --- a/doc/bugs/It__39__s_July_not_June.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -The new tag created today is named 6.20160619 - -Off-by-one bug ... - -> I really need to automate generating those version numbers. -> I'm not going to re-release it though, and the version number meets -> all other requirements other than matching the release date, so [[done]] --[[Joey]] - ->> JFTR, yesterday, I needed a tag to build the package against and pushed that to the ->> main repo. If you object, feel free to nuke. -- RichiH diff --git a/doc/bugs/It__39__s_July_not_June/comment_1_RichiH._comment b/doc/bugs/It__39__s_July_not_June/comment_1_RichiH._comment deleted file mode 100644 index 98d9b4449..000000000 --- a/doc/bugs/It__39__s_July_not_June/comment_1_RichiH._comment +++ /dev/null @@ -1 +0,0 @@ -Ah, saw this too late. Also see 2aa0841940d309b858eed5bc156262a7d90c949b diff --git a/doc/bugs/Local_pairing_fails__58___PairListener_crashed.mdwn b/doc/bugs/Local_pairing_fails__58___PairListener_crashed.mdwn deleted file mode 100644 index 371b923cf..000000000 --- a/doc/bugs/Local_pairing_fails__58___PairListener_crashed.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -What steps will reproduce the problem? - -Attempting to pair between a local repository and a repository on a remote computer on my LAN. Pairing is initiated from my local machine and I'm interacting with the webapp on the remote machine via firefox running over an ssh -X connection. Pairing appears to work up to a point: I enter the secret at one end, the pairing request shows up at the other end. I then enter the secret at that end. - -What is the expected output? What do you see instead? - -Pairing should complete successfully. Instead I get the error message "PairListener crashed: bad comment in public key", followed by the public key. The pairing process then does not move beyond the 'awaiting pairing' pages. - -What version of git-annex are you using? On what operating system? - -Local Machine: 3.20121127, Debian Wheezy/Sid (the only package from unstable is git-annex). -Remote Machine: 3.20121113, Arch Linux (I installed the version from: https://aur.archlinux.org/packages/git-annex-bin/, which is supposedly the same as above, but reports the version specified here). - -Please provide any additional information below. - -None as yet. Let me know if there are any log files, etc. that I can post. - -> So it was the period in the hostname! [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_1_d9c5d2147cf6d8d8477eb13b72081d46._comment b/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_1_d9c5d2147cf6d8d8477eb13b72081d46._comment deleted file mode 100644 index 4dd77f04d..000000000 --- a/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_1_d9c5d2147cf6d8d8477eb13b72081d46._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.72" - subject="comment 1" - date="2012-12-04T17:38:47Z" - content=""" -On the machine that didn't crash, run: - -ssh-keygen -P \"\" -f test; cat test.pub - -Probably the non-alphanumeric character is part of the machine's hostname, or perhaps your username. We'll see.. -"""]] diff --git a/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_2_60a21105145ac228f486bc4beb2ea54d._comment b/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_2_60a21105145ac228f486bc4beb2ea54d._comment deleted file mode 100644 index 851dfe9f8..000000000 --- a/doc/bugs/Local_pairing_fails__58___PairListener_crashed/comment_2_60a21105145ac228f486bc4beb2ea54d._comment +++ /dev/null @@ -1,32 +0,0 @@ -[[!comment format=mdwn - username="robconnolly" - ip="118.90.115.19" - subject="comment 2" - date="2012-12-06T02:29:56Z" - content=""" -Hi Joey, - -Thanks for your response. Here is the output: - -[robert@laforge ~]$ ssh-keygen -P \"\" -f test; cat test.pub -Generating public/private rsa key pair. -Your identification has been saved in test. -Your public key has been saved in test.pub. -The key fingerprint is: -84:43:aa:f0:ba:a7:f0:11:41:55:3b:c4:63:6a:71:e1 robert@laforge.enterprise -The key's randomart image is: -+--[ RSA 2048]----+ -| ...o=. | -| . .==o | -|. . .=E.. | -| o oo + | -| +. S | -| . . | -|o . | -|.o.. | -|oo. | -+-----------------+ -ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDIeitbarby1thLPEyVpeT/vDaWt0MJwLPvhT7TEZv0FedYalvz/mm3enULHiYdxkjWGBaO/EEzfmz5bjhoJx2tsqSLsUj/UZVv0LxsSfZwTrk0SPuUerzWvAJAXKvtPobDXJoAxsNvzSJN392BMOLKqcjAQTqPA3vd5+EjUVIgJxguz5poGrP0ZRMQD5LmsDrPGUWNJ/EHaVkrqGobAE4DVr8vhJTY41h5Gk2ipnzx+GD6CDZTSNFwl8RorjFAV3mYTTjHc2Cz7GxTLSmwF0+qFZ/UkiO2tD1M37Y4/cPLY7GpVfKvpPHTC8pJUpvj+B4uujHxvZkBJLLz9XhH9KsZ robert@laforge.enterprise - -Let me know if you need any more info. -"""]] diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn deleted file mode 100644 index 26790bea3..000000000 --- a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run.mdwn +++ /dev/null @@ -1,85 +0,0 @@ -### Please describe the problem. - -While running `git-annex metadata --batch --json`, repeatedly assigning a field to the same value in the same run (with different values in between the assignments of the same value) causes a value to get stuck. - -### What steps will reproduce the problem? - - $ touch test.txt - $ git annex add - $ git-annex metadata --batch --json - {"file":"test.txt","fields":{"f":["a"]}} - # prints { ... "f":["a"] ... } - {"file":"test.txt","fields":{"f":["b"]}} - # prints { ... "f":["b"] ... } - {"file":"test.txt","fields":{"f":["c"]}} - # prints { ... "f":["c"] ... } - {"file":"test.txt","fields":{"f":["a"]}} - # prints { ... "f":["a", "c"] ... } - {"file":"test.txt","fields":{"f":["b"]}} - # prints { ... "f":["c"] ... } - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20161122+gitg9f179ae-1~ndall+1 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -I'm using Xubuntu 16.04, with the `git-annex-standalone` package from NeuroDebian repository. - -### Please provide any additional information below. - -If you keep reassigning the same values, things get very weird. Full inputs/outputs from a sample run: - - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=a\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields": {"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"f=b\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b"]}} - {"file":"test.txt","fields":{"f":["c"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":[]}} - {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"lastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"lastchanged":["2016-12-05@21-17-39"]}} - {"file":"test.txt","fields":{"f":["c"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":["c"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=a\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","c"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - {"file":"test.txt","fields":{"f":["b"]}} - {"command":"metadata","note":"f=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=a\nf=b\nf=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["a","b","c"]}} - {"file":"test.txt","fields":{"f":["d"]}} - {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} - {"file":"test.txt","fields":{"f":["a"]}} - {"command":"metadata","note":"f=b\nf=c\nf=d\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["b","c","d"]}} - {"file":"test.txt","fields":{"f":[]}} - {"command":"metadata","note":"f=c\nf-lastchanged=2016-12-05@21-17-39\nlastchanged=2016-12-05@21-17-39\n","success":true,"key":"SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.txt","file":"test.txt","fields":{"f-lastchanged":["2016-12-05@21-17-39"],"lastchanged":["2016-12-05@21-17-39"],"f":["c"]}} - -Restarting the process solves the issue. - -### 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) - -I love the metadata functionality so much that I wrote [[tips/a_gui_for_metadata_operations]] and discovered this bug. -Metadata driven views are awesome (but I don't like the entire folder hierarchy being appended to the filename). -I haven't used the other commands much since I have not yet organized most of my stuff (and their naively copy-pasted backups), but I am glad I discovered git-annex before I began organizing. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment b/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment deleted file mode 100644 index 4f82db153..000000000 --- a/doc/bugs/Metadata_values_get_stuck_when_repeatedly_modified_in_the_same_batch_mode_run/comment_1_627bb742a5042741e9a1c294addd69b2._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-13T14:40:02Z" - content=""" -I thought this would involve the journal, but it seems not; same -behavior occurs if the journal is committed after each metadata change. - -Looking at the new metadata value in the case where a and c both get set, -it is: - - MetaData (fromList [(MetaField "f",fromList [MetaValue (CurrentlySet True) "a",MetaValue (CurrentlySet False) "c"])]) - -That is supposed to unset c, with the CurrentlySet False, but instead c -remains set somehow. - -Aha, the use of `addMetaData'` causes the bug. That reuses the same -timestamp, and indeed the same timestamp is used for all the batch -changes. With the same timestamp for the log line that sets c as the line -that removes it, it's indeterminite which line will be acted on first, and -so the removal can be processed before the addition, leaving c "stuck". - -Fixing.. -"""]] diff --git a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository.mdwn b/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository.mdwn deleted file mode 100644 index 3925b7c10..000000000 --- a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -### Please describe the problem. -Files transferred from one repository to a standard remote by the assistant do not retain the original mtime - -### What steps will reproduce the problem? -Create manually two repositories, in my case on two external drives directly connected to my box, with normal remotes pointing to each other. -Activate git annex assistant and synchronize some files from one to the other. - -### What version of git-annex are you using? On what operating system? -Git annex version 5.20140610-g5ec8bcf on Ubuntu Linux 12.04 - -### Please provide any additional information below. -I've noticed how files synchronized from one repository to another do not retain the original mtime information. -Perhaps it's intended, but in my view retaining the time of modification of the object is essential. - -> [[done]]; dup and/or out of scope, --[[Joey]] diff --git a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_1_651965d8a9f0e0c07313c1a2916f77e5._comment b/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_1_651965d8a9f0e0c07313c1a2916f77e5._comment deleted file mode 100644 index fcb5c4cc6..000000000 --- a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_1_651965d8a9f0e0c07313c1a2916f77e5._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 1" - date="2014-07-02T17:07:33Z" - content=""" -git makes no attempt to maintain mtimes etc, and neither does git-annex. There are open todo items. There is metastore, etc. -"""]] diff --git a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_2_1b17514fb769fa5668f1b77e09ff3de1._comment b/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_2_1b17514fb769fa5668f1b77e09ff3de1._comment deleted file mode 100644 index b70082bdf..000000000 --- a/doc/bugs/Mtime_of_objects_reset_when_synchronized_to_a_different_repository/comment_2_1b17514fb769fa5668f1b77e09ff3de1._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-12-21T15:46:53Z" - content=""" -FWIW well -- git-annex does at least a bit to maintain mtime. E.g. when I 'annex add' a file, the symlink's mtime becomes the one of the original file. Unfortunately it is not the case though whenever I acquire the load for that key, which possibly gets correct mtime again, but then symlink doesn't get mtime adjusted to match to the one of the key. -"""]] diff --git a/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn b/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn deleted file mode 100644 index 5c72b0095..000000000 --- a/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -See transcript. Didn't bisect fully but 6.20160128-g599a3ba seems to work ok, 6.20160211-g479a094 already dies off - -[[!format sh """ - -datalads-imac:~ yoh$ git annex version -git-annex version: 6.20160221-g3d1895e -... -datalads-imac:~ yoh$ mkdir -p /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /private/tmp/123/.git/ -init ok -(recording state in git...) - -datalads-imac:123 yoh$ rm -f /tmp/pipe; mkfifo /tmp/pipe; cat /tmp/pipe | git -c receive.autogc=false annex addurl -c annex.largefiles=exclude=*.txt --with-files --json --batch -{"command":"addurl","file":"1.png","note":"downloading http://www.onerussian.com/tmp/banner.png ..."error: git-annex died of signal 4 - -# now with --debug -datalads-imac:123 yoh$ rm -f /tmp/pipe; mkfifo /tmp/pipe; cat /tmp/pipe | git -c receive.autogc=false annex addurl -c annex.largefiles=exclude=*.txt --with-files --json --batch --debug -[2016-02-23 08:32:49.160686] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","show-ref","git-annex"] -[2016-02-23 08:32:49.167372] process done ExitSuccess -[2016-02-23 08:32:49.167479] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","show-ref","--hash","refs/heads/git-annex"] -[2016-02-23 08:32:49.172795] process done ExitSuccess -[2016-02-23 08:32:49.173039] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","log","refs/heads/git-annex..b2892e67682c5240dadb5d439da810edbdb882df","-n1","--pretty=%H"] -[2016-02-23 08:32:49.178586] process done ExitSuccess -[2016-02-23 08:32:49.179085] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","cat-file","--batch"] -[2016-02-23 08:32:49.183985] read: quvi ["--version"] -{"command":"addurl","file":"1.png","note":"downloading http://www.onerussian.com/tmp/banner.png ..."[2016-02-23 08:32:49.255949] call: curl ["-s","-f","-L","-C","-","-#","-o","/private/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png","http://www.onerussian.com/tmp/banner.png","--user-agent","git-annex/6.20160221-g3d1895e"] -[2016-02-23 08:32:49.302577] process done ExitSuccess -[2016-02-23 08:32:49.303332] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] -[2016-02-23 08:32:49.305653] read: git ["--version"] -[2016-02-23 08:32:49.310314] process done ExitSuccess -error: git-annex died of signal 4 - -"""]] - -[[!meta author=yoh]] - -> [[done]]; this was indeed due to libmagic, and I've fixed it using brew -> --build-bottle to make a portable one. Then had to disable the build -> flag. --[[Joey]] diff --git a/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4/comment_1_36e75e72a1257db3cf8a48a025d42122._comment b/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4/comment_1_36e75e72a1257db3cf8a48a025d42122._comment deleted file mode 100644 index 774381d00..000000000 --- a/doc/bugs/OSX__58___addurl_--batch_--json_spits_out_shortened_output_string__dies_off_with_4/comment_1_36e75e72a1257db3cf8a48a025d42122._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-23T15:03:19Z" - content=""" -OSX signal 4 is SIGILL; git-annex test fails similarly, but so far I've only -had the problem be reported on this same datalads mac; I don't know how -widespread the problem is. - -Occurs to me it could well be libmagic that's dying. That would be -consistent with the point it fails, and IIRC with where git-annex test was -failing. Any use of annex.largefiles will cause the magic library to be -initialized. - -I've seen libraries taken from homebrew (as libmagic is) -be aggressively optimised for the host CPU and sigill on others. - -I've re-installed that using `brew install --build-bottle` now. -Hopefully that will fix the problem. -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn deleted file mode 100644 index 0d442437d..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone.mdwn +++ /dev/null @@ -1,240 +0,0 @@ -### Please describe the problem. - -I had set up git-annex on a mac; I had created an initial repository at ~/annex; I had created a second repository on an external drive, at /Volumes/Biblio/annex; I had paired with three other machines on the same network, (two linux, one other mac) and set up a remote server as a backup-type repository. All seemed well. It had finally finished syncing everything to the remote server (my upload speeds are slow). - -I closed the firefox window showing the dashboard. I wanted to reopen it, so I ran the git-annex.app again, presuming on a running instance that that just opens the browser back at the webapp. Firefox window opened, but the only repository was the second one I'd made on the external drive. - -I restarted, as best as I could work out: git-annex assistant --stop, then because that left behind a process, killall git-annex. Then restarted the app. - -Firefox opened on the webapp. I had two repositories: The one on the external drive (now the "Here" repo) and the one on ~/annex but only as if it was paired from a different machine. - -ie: I see only "celestia.local (rachel@celestia.local~/annex)". This machine *is* celestia.local. - -That's it. Startup scan took a couple of minutes but didn't add anything. Then it decided to sync to celestia.local, which it took a little time over but didn't apparently do anything. - -If I drop files into ~/annex they are not synced anywhere. ~/annex still has a .git directory, populated with git files, it looks intact. It's just not being seen. - -Is it possible because the user is prompted to create their initial repo at ~/Desktop/annex it will by default only look there, then start looking in external drives for it? So the fact I didn't want it on my desktop, but put it directly in home, meant it got lost on restart? - -git-annex vicfg in ~/annex shows me this: - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting uuid = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for web) -#trust 00000000-0000-0000-0000-000000000001 = semitrusted -# (for rachel@octavia:~/annex) -#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted -# (for rachel@celestia.local:~/annex) -#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted -# (for twilight.local_annex (rachel@twilight:~/annex)) -#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted -# (for rachel@octavia:~/annex) -#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted -# (for annex (Biblio's Copy)) -#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted -# (for luna.strangenoises.org_annex) -#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted -# (for octavia.local_annex (rachel@octavia:~/annex)) -#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted -# (for rachel@twilight:~/annex) -#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for rachel@octavia:~/annex) -group 161dec38-e8be-43b8-86c5-555d35ce3416 = client -# (for rachel@celestia.local:~/annex) -group 179fcddf-e247-4577-804b-267feed8abb1 = client -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -group 256d5762-150d-4d5d-9340-517de298c874 = client -# (for twilight.local_annex (rachel@twilight:~/annex)) -group aeef7490-ce27-4255-b800-1947706c4a06 = client -# (for rachel@octavia:~/annex) -group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client -# (for annex (Biblio's Copy)) -group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client -# (for octavia.local_annex (rachel@octavia:~/annex)) -group f748a5ed-d870-48fb-b3ec-811488eb2faa = client -# (for rachel@twilight:~/annex) -group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client -# (for luna.strangenoises.org_annex) -group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer -# (for web) -#group 00000000-0000-0000-0000-000000000001 = - -# Repository preferred contents -# (for rachel@octavia:~/annex) -content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard -# (for rachel@celestia.local:~/annex) -content 179fcddf-e247-4577-804b-267feed8abb1 = standard -# (for 192.168.1.103_annex (rachel@rainbow.local:~/annex)) -content 256d5762-150d-4d5d-9340-517de298c874 = standard -# (for twilight.local_annex (rachel@twilight:~/annex)) -content aeef7490-ce27-4255-b800-1947706c4a06 = standard -# (for rachel@octavia:~/annex) -content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard -# (for annex (Biblio's Copy)) -content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard -# (for luna.strangenoises.org_annex) -content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard -# (for octavia.local_annex (rachel@octavia:~/annex)) -content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard -# (for rachel@twilight:~/annex) -content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard -# (for web) -#content 00000000-0000-0000-0000-000000000001 = -"""]] - -while the same command in /Volumes/Biblio/annex gives: - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting uuid = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for web) -#trust 00000000-0000-0000-0000-000000000001 = semitrusted -# (for rachel@octavia:~/annex) -#trust 161dec38-e8be-43b8-86c5-555d35ce3416 = semitrusted -# (for celestia.local (rachel@celestia.local:~/annex)) -#trust 179fcddf-e247-4577-804b-267feed8abb1 = semitrusted -# (for rachel@rainbow.local:~/annex) -#trust 256d5762-150d-4d5d-9340-517de298c874 = semitrusted -# (for rachel@twilight:~/annex) -#trust aeef7490-ce27-4255-b800-1947706c4a06 = semitrusted -# (for rachel@octavia:~/annex) -#trust c469fbce-f3b4-4e27-a54f-0b747797a7d5 = semitrusted -# (for Biblio's Copy) -#trust c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = semitrusted -# (for ) -#trust f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = semitrusted -# (for rachel@octavia:~/annex) -#trust f748a5ed-d870-48fb-b3ec-811488eb2faa = semitrusted -# (for rachel@twilight:~/annex) -#trust fcaba03e-1ba5-11e3-90f1-57fe1467e006 = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for rachel@octavia:~/annex) -group 161dec38-e8be-43b8-86c5-555d35ce3416 = client -# (for celestia.local (rachel@celestia.local:~/annex)) -group 179fcddf-e247-4577-804b-267feed8abb1 = client -# (for rachel@rainbow.local:~/annex) -group 256d5762-150d-4d5d-9340-517de298c874 = client -# (for rachel@twilight:~/annex) -group aeef7490-ce27-4255-b800-1947706c4a06 = client -# (for rachel@octavia:~/annex) -group c469fbce-f3b4-4e27-a54f-0b747797a7d5 = client -# (for Biblio's Copy) -group c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = client -# (for rachel@octavia:~/annex) -group f748a5ed-d870-48fb-b3ec-811488eb2faa = client -# (for rachel@twilight:~/annex) -group fcaba03e-1ba5-11e3-90f1-57fe1467e006 = client -# (for ) -group f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = transfer -# (for web) -#group 00000000-0000-0000-0000-000000000001 = - -# Repository preferred contents -# (for rachel@octavia:~/annex) -content 161dec38-e8be-43b8-86c5-555d35ce3416 = standard -# (for celestia.local (rachel@celestia.local:~/annex)) -content 179fcddf-e247-4577-804b-267feed8abb1 = standard -# (for rachel@rainbow.local:~/annex) -content 256d5762-150d-4d5d-9340-517de298c874 = standard -# (for rachel@twilight:~/annex) -content aeef7490-ce27-4255-b800-1947706c4a06 = standard -# (for rachel@octavia:~/annex) -content c469fbce-f3b4-4e27-a54f-0b747797a7d5 = standard -# (for Biblio's Copy) -content c9e307e2-1189-47ed-8ad4-03b5c1b64e36 = standard -# (for ) -content f36dbdf8-1bba-11e3-9dbe-f33cfb0e2bed = standard -# (for rachel@octavia:~/annex) -content f748a5ed-d870-48fb-b3ec-811488eb2faa = standard -# (for rachel@twilight:~/annex) -content fcaba03e-1ba5-11e3-90f1-57fe1467e006 = standard -# (for web) -#content 00000000-0000-0000-0000-000000000001 = -"""]] - -### What steps will reproduce the problem? - -As above. I have no idea what just happened, but apart from git-annex assistant --stop and having to mop up leftover processes, I didn't use the git-annex commandline for anything. - -### What version of git-annex are you using? On what operating system? - -Mac OS X 10.8.4 - - Version: 4.20130909-ga29f960 - Build flags: Assistant Webapp Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi - -### Please provide any additional information below. - -The log on ~/annex/.git/annex/daemon.log is huge and full of transfers of files with my personal filenames. I'd rather not. It appears to end normally. - -Now there is a short log in /Volumes/Biblio/annex/.git/annex/daemon.log from, I guess, the time I tried to restart. For some reason therefore, after the successful session finished, on restart it only looks here. This log is appended. - -[[!format sh """ -[2013-09-12 21:35:39 BST] main: starting assistant version 4.20130909-ga29f960 - -[2013-09-12 21:35:39 BST] TransferScanner: Syncing with celestia.local -Already up-to-date. - -(scanning...) [2013-09-12 21:35:39 BST] Watcher: Performing startup scan -From /Users/rachel/annex - * [new branch] git-annex -> celestia.local/git-annex - * [new branch] master -> celestia.local/master - * [new branch] synced/git-annex -> celestia.local/synced/git-annex - * [new branch] synced/master -> celestia.local/synced/master -Updating 4f974a8..74770d9 -Fast-forward -Already up-to-date. -Already up-to-date. -Already up-to-date. -[2013-09-12 21:36:39 BST] Pusher: Syncing with celestia.local -(merging celestia.local/git-annex celestia.local/synced/git-annex into git-annex...) -(Recording state in git...) - - - - -(started...) error: Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764 -remote: error: failed to lock refs/heads/synced/git-annex -To /Users/rachel/annex - 792d2a5..5b4ed9b git-annex -> synced/git-annex -To /Users/rachel/annex - ! [remote rejected] git-annex -> synced/git-annex (failed to lock) -error: failed to push some refs to '/Users/rachel/annex' -Everything up-to-date -"""]] - -Well, I see that thing about "failed to lock". I can imagine that my 'killall git-annex' to kill a leftover process that was hanging around after I'd done git-annex assistant --stop might have left stale lock files, somewhere... but of course I only got as far as doing that because I was already encountering problems, just trying to return to the webapp. - -> The original bug report seems to be a case of user confusion, -> and not a bug. (Although perhaps the UI is confusing?) -> -> The "resource exhausted" that came up later is quite likely the problem -> fixed in [[!commit 4d06037fdd44ba38fcd4c118d1e6330f06e22366]], -> which affected local git remotes. -> -> [[closing|done]]; I don't see any value keeping this open, I'm afraid. -> --[[Joey]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment deleted file mode 100644 index 70e7ba79d..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_1_3a3891c9d7ee808f6a71780cb628f23d._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 1" - date="2013-09-12T21:29:39Z" - content=""" -The git-annex webapp displays a view from \"inside\" one git repository at a time. It seems to me that you have two or more local git repositories; one in ~/annex and one on a removable drive. The webapp is coming up viewing from inside your removable drive's repository. You can change the repository that the webapp views by going to the Repository menu in the upper-right corner and selecting Switch repository. The webapp will remember which repository it viewed last, and come back up showing that same repository. - -It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". - -I think, but am not sure, that the error \"Ref refs/heads/synced/git-annex is at 5b4ed9b3098e936d60b61a1d3915fa29e8c823d0 but expected 792d2a5c14b0b6327d2089e174063c474ba5a764\" is due to having two git-annex assistants running in these two different repositories and both updating them both at the same time. You might want to stop all git-annex processes, edit `~/.config/git-annex/autostart` and remove the removable drive repository from that list, leaving only `~/annex` in the list. -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment deleted file mode 100644 index 10fad2252..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_2_2bc6efb1d9e872cc5d4fbfbaaf5cc10e._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="I don't know whether I've fixed it or confused things further" - date="2013-09-12T21:30:44Z" - content=""" -I shut down the daemon that was running from the webapp itself. - -Instead of launching by using the app, I did: - -[[!format txt \"\"\" -celestia:~ rachel$ cd annex/ -celestia:annex rachel$ git-annex assistant -(merging synced/git-annex into git-annex...) -celestia:annex rachel$ git-annex webapp -Launching web browser on file:///Users/rachel/annex/.git/annex/webapp.html -celestia:annex rachel$ -\"\"\"]] - -It opened the webapp. I could see all the repos back again. - -It also seems to be syncing to everything else, sending the files all over again, even though they haven't changed. - -It's just about possible it's completing the job, as I'm not sure I saw the files syncing now, being synced earlier. But... in that earlier session it had run the queue dry, *it* thought it had completed syncing. - -What's going on? -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment deleted file mode 100644 index 4d44aaf5c..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_3_fff1e778a6334258c173a96e6bf7ef6a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 3" - date="2013-09-12T21:33:18Z" - content=""" -See my explanation above. By manually starting the webapp inside your ~/annex repository you forced it to view that repository. - -It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment deleted file mode 100644 index 16a5a351f..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_4_2a86da97a89e28f0a0f5e160d4932ae6._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="Last night's comment" - date="2013-09-13T10:28:02Z" - content=""" -> It's BTW an unusual configuration to have the git-annex assistant directly running on a removable drive as you seem to have done. You must have previously went to the Repository menu and selected \"Add another local repository\", and then added the removable drive, and then connected that repository up to your ~/annex repository. Which would explain why the webapp was last showing the repository on the removable drive. The more usual way to add a removable drive is to use the \"Add another repository\" button and select \"Removable drive\". - -That is exactly how I'd added that repository, yes. I didn't notice the dedicated \"removable drive\" option until later. :-) I thought it possibly appropriate to leave it that way because, while Biblio is an external drive and remov*able*, in practice I never remove it; it's a permanent fixture. - -After all, this is a mac mini server, originally (no longer running Server) so it has a second *internal* drive. It would have been even more logical for me to have added a second repo on there in the same manner, as it's most definitely not removable without extreme effort; but it still mounts inside /Volumes, and presumably if I'd added it as a non-removable repo, I'd have had the same problem? - -> It's not unusual for the webapp to display it syncing some files that have been synced before. This repository may not be up-to-date on which files have been sent where, and it will quickly notice the file has already been transferred and skip doing anything for that file. - -Yes, that's probably what happened. It finished pretty quickly, about a minute after sending my previous comment. - -Going to bed now, but tomorrow I'll follow the remaining suggestions; basically I'll remove the repo on the external drive then, if I still want it there, I'll add it back in the other way, so it thinks of it as removable. - -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment deleted file mode 100644 index 685d1b024..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_5_41b8e8e58025cc8c8f12efb9a51acd29._comment +++ /dev/null @@ -1,50 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="And this morning..." - date="2013-09-13T10:38:35Z" - content=""" -I tried removing the second repo, by deleting it, it seemed to begin normally. Then it just hung, and hung. - -Looking at logs, it seemed to be hung on dropping one file - a very small file in fact, but it was probably the most recent file to be added. So the end of the log just looked like: - -[[!format txt \"\"\" -drop annex old stuff/renegade/issue7back.pdf ok -drop annex old stuff/renegade/issue7fiction.pdf ok -drop annex postgresql 9.0->9.1 upgrade process -\"\"\"]] - -After a while I started getting problems in other terminal shells where I was doing stuff unrelated to git annex. eg: on trying to open a new terminal window, it would open, then shut immediately, or it would open with just: - -[[!format txt \"\"\" -forkpty: Resource temporarily unavailable -Could not create a new process and open a pseudo-tty. -\"\"\"]] - -Various other commands that would have resulted in a fork were failing too. In the end I shut down git annex (using the shutdown daemon open in the menu in the webapp), and everything went back to normal. - -This is the end of the daemon.log from this morning. I don't want to paste the whole thing, as essentially it lists all my private filenames, and there's a lot. In fact I wonder if the quantity of files may be a factor: - -[[!format txt \"\"\" -drop annex old stuff/renegade/index.html ok -drop annex old stuff/renegade/issue1.pdf ok -drop annex old stuff/renegade/issue2.pdf ok -drop annex old stuff/renegade/issue3.pdf ok -drop annex old stuff/renegade/issue4.pdf ok -drop annex old stuff/renegade/issue4coverpic.pdf ok -drop annex old stuff/renegade/issue6articles.pdf ok -drop annex old stuff/renegade/issue6cover.pdf ok -drop annex old stuff/renegade/issue6fiction.pdf ok -drop annex old stuff/renegade/issue7articles.pdf ok -drop annex old stuff/renegade/issue7back.pdf ok -drop annex old stuff/renegade/issue7fiction.pdf ok -drop annex postgresql 9.0->9.1 upgrade process [2013-09-13 11:25:07 BST] NetWatcherFallback: Syncing with twilight.local_annex, octavia.local_annex, 192.168.1.103_annex, luna.strangenoises.org_annex -NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) -[2013-09-13 11:25:07 BST] NetWatcherFallback: warning NetWatcherFallback crashed: git: createProcess: resource exhausted (Resource temporarily unavailable) -recv: resource vanisrhreeecdcv v:(: C rorenesnsoeoucurtrciceoe n v varanenisiseshthe edbd y ( (CpCoeonennrne)ec -cttiioonn rreesseett bbyy ppeeeerr)) - -[2013-09-13 11:26:32 BST] main: warning git-annex has been shut down -\"\"\"]] - -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment deleted file mode 100644 index c0923b22a..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_6_38afcd8e7fb278ca0ee2e9e0c9f6883e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="comment 6" - date="2013-09-13T10:52:07Z" - content=""" -FYI, if there's any relevance to the number of files in the annex, there are 1899 files in the annex at the moment, so that many in the one being deleted. The one it hung on, \"postgresql 9.0->9.1 upgrade process\" was indeed the last one that comes up in a find command, which I think means the most recently added to this dir. - -Creating too many threads? -"""]] diff --git a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment b/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment deleted file mode 100644 index c11630ef7..000000000 --- a/doc/bugs/On_restart__44___most_repositories__44___including_original_one__44___gone/comment_7_06de36dcde4c52ab74c8134f3242ac02._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlEhzszkzOIy8-Rx8b2mcr75QcnIc6O_OA" - nickname="Rachel" - subject="comment 7" - date="2013-09-13T10:54:37Z" - content=""" -... and resolved for myself by just deleting (dropping in the trash for now) the annex on the external volume, restarting git-annex assistant and *disabling* that repo from the menu rather than deleting it. - -"""]] diff --git a/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__.mdwn b/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__.mdwn deleted file mode 100644 index 7d0e7ba4a..000000000 --- a/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -### Please describe the problem. - -When using 'git annex repair --verbose' the '--verbose' option is not passed to 'git fsck', on large annexes it takes ages and you don't have feedback... - -### What steps will reproduce the problem? - -Just run 'git-annex repair --verbose' - -### What version of git-annex are you using? On what operating system? - -not important, this is just a suggestion - -> [[done]] see comment --[[Joey]] diff --git a/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__/comment_1_04c49dd8c74c717e9401b0f11dec3e3c._comment b/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__/comment_1_04c49dd8c74c717e9401b0f11dec3e3c._comment deleted file mode 100644 index 84ccf280e..000000000 --- a/doc/bugs/Pass_--verbose_option_to___39__git_fsck__39___from___39__git-annex_repair_--verbose__39__/comment_1_04c49dd8c74c717e9401b0f11dec3e3c._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-21T17:23:18Z" - content=""" -git-annex is parsing the output of git fsck to see what sha1s it outputs, -as those may have problems, --verbose would confuse that since it causes -many more sha1s to be output to stdout. - -Passing --progress enables a progress display, but it is -displayed on stderr, which is the same place git fsck displays -some errors which git-annex also parses. Any attempt to untangle the -progress and the error messages could be broken by changes to the git fsck -output, so would not be a good idea. - -So while this is a good idea, it doesn't work out. -"""]] diff --git a/doc/bugs/Prefered_Content_not_Taken_into_Account.mdwn b/doc/bugs/Prefered_Content_not_Taken_into_Account.mdwn deleted file mode 100644 index bdb3c9d97..000000000 --- a/doc/bugs/Prefered_Content_not_Taken_into_Account.mdwn +++ /dev/null @@ -1,364 +0,0 @@ -### Please describe the problem. - -This is a follow up to the question [1]. I've created 4 repos with the following vicfg. - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting field = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for web) -#trust 00000000-0000-0000-0000-000000000001 = semitrusted -# (for bittorrent) -#trust 00000000-0000-0000-0000-000000000002 = semitrusted -# (for repo2) -#trust 2837f3d7-7c58-4177-8877-620213cf5146 = semitrusted -# (for repo3) -#trust b3cbb656-e797-45ba-bf43-08523d463146 = semitrusted -# (for repo1) -#trust e7673de4-d465-4557-be8f-b1400acf923e = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for repo3) -group b3cbb656-e797-45ba-bf43-08523d463146 = PodA -# (for repo1) -group e7673de4-d465-4557-be8f-b1400acf923e = PodA -# (for repo2) -group 2837f3d7-7c58-4177-8877-620213cf5146 = PodB -# (for web) -#group 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#group 00000000-0000-0000-0000-000000000002 = - -# Repository preferred contents -# (Set to "standard" to use a repository's group's preferred contents) -# (for repo2) -wanted 2837f3d7-7c58-4177-8877-620213cf5146 = groupwanted -# (for repo1) -wanted e7673de4-d465-4557-be8f-b1400acf923e = groupwanted -# (for web) -#wanted 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#wanted 00000000-0000-0000-0000-000000000002 = -# (for repo3) -#wanted b3cbb656-e797-45ba-bf43-08523d463146 = - -# Group preferred contents -# (Used by repositories with "groupwanted" in their preferred contents) -groupwanted PodA = not copies=PodA:1 -groupwanted PodB = not copies=PodB:1 -#groupwanted archive = -#groupwanted backup = -#groupwanted client = -#groupwanted incrementalbackup = -#groupwanted manual = -#groupwanted public = -#groupwanted smallarchive = -#groupwanted source = -#groupwanted transfer = -#groupwanted unwanted = - -# Standard preferred contents -# (Used by wanted or groupwanted expressions containing "standard") -# (For reference only; built-in and cannot be changed!) -# standard client = (include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1 -# standard transfer = (not (inallgroup=client and copies=client:2) and ((include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1)) or approxlackingcopies=1 -# standard backup = anything -# standard incrementalbackup = ((not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1 -# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1 -# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1 -# standard source = not (copies=1) -# standard manual = present and ((include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1) -# standard public = inpreferreddir -# standard unwanted = not anything - -# Repository required contents -# (for web) -#required 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#required 00000000-0000-0000-0000-000000000002 = -# (for repo2) -#required 2837f3d7-7c58-4177-8877-620213cf5146 = -# (for repo3) -#required b3cbb656-e797-45ba-bf43-08523d463146 = -# (for repo1) -#required e7673de4-d465-4557-be8f-b1400acf923e = - -# Scheduled activities -# (Separate multiple activities with "; ") -# (for web) -#schedule 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#schedule 00000000-0000-0000-0000-000000000002 = -# (for repo2) -#schedule 2837f3d7-7c58-4177-8877-620213cf5146 = -# (for repo3) -#schedule b3cbb656-e797-45ba-bf43-08523d463146 = -# (for repo1) -#schedule e7673de4-d465-4557-be8f-b1400acf923e = -"""]] - -This works as expected each file lands in 1 on of the repos on the group, not both. My original repo one with the problem has the following vicfg. - -[[!format sh """ -# git-annex configuration -# -# Changes saved to this file will be recorded in the git-annex branch. -# -# Lines in this file have the format: -# setting field = value - -# Repository trust configuration -# (Valid trust levels: trusted semitrusted untrusted dead) -# (for buse [origin]) -trust bff7238e-bd92-4929-88a8-c59c1a1dcf03 = semitrusted -# (for web) -trust 00000000-0000-0000-0000-000000000001 = untrusted -# (for bittorrent) -trust 00000000-0000-0000-0000-000000000002 = untrusted -# (for ) -trust 03b19bdc-8497-4234-9ef6-c80d78e309f8 = dead -# (for ) -trust 0b1a34ce-a8e3-4002-b46a-83e96626305f = dead -# (for ) -trust 1459a238-6f60-4b43-8459-f7055b49e3c5 = dead -# (for ) -trust 14738d0f-2f50-4f93-a8e4-c29870d02ba1 = dead -# (for ) -trust 1512a830-7789-4bc8-a4a0-4c51eedd1109 = dead -# (for ) -trust 174d69cb-9b97-44df-9f15-aea00f66a61c = dead -# (for ) -trust 1ade7f29-2ad0-4ab0-a816-de55ffde389e = dead -# (for ) -trust 1ba9d14b-deae-46e6-b451-dbf0fa8aa934 = dead -# (for ) -trust 1dda84ca-4e8c-49b4-b673-35ec2b11557b = dead -# (for ) -trust 29aad234-82e6-45c9-9822-b650290c2264 = dead -# (for ) -trust 2be091a2-e721-4a86-a759-c5df7a41a61d = dead -# (for ) -trust 3540b01a-03f0-4a58-8ea1-7ca80002a22d = dead -# (for ) -trust 39b4d431-9d55-432d-a801-eaf4cf643de1 = dead -# (for ) -trust 3a443e72-e8e0-11e2-b7db-8feb865236d4 = dead -# (for ) -trust 42023cde-e95f-483c-8389-54b823aed789 = dead -# (for ) -trust 54a819c1-65a3-44e9-86c3-0eb602223ee8 = dead -# (for ) -trust 68846c04-912d-4bfc-80f3-3b8ec1e7a3c7 = dead -# (for ) -trust 69b10f7e-0214-4fd0-8138-ff4717d1f39f = dead -# (for ) -trust 7b236779-a961-4e72-abfc-56b764e53a9c = dead -# (for ) -trust 7cde3feb-3876-4c2a-a772-d4541eac8614 = dead -# (for ) -trust 8f3e7b2b-f8de-4114-bcdd-2ef3ed932c18 = dead -# (for ) -trust a3bd1546-e8df-11e2-bc54-a7edbf29f5da = dead -# (for ) -trust aa830256-4c63-44e3-9a3f-33b377de79d5 = dead -# (for ) -trust ad46e36b-df9c-4d45-9af1-58d17e798afa = dead -# (for ) -trust b5464382-b5f8-4ec3-b36d-a378b1202497 = dead -# (for ) -trust b6317827-97d3-44bd-8197-91cae0b56a19 = dead -# (for ) -trust bbb5dd98-f09d-11e2-a57b-d7185df9eef1 = dead -# (for ) -trust c6dfb856-a0cc-4e79-acbd-3600f4bce158 = dead -# (for ) -trust ccb11b54-ecc8-11e2-ad6c-af6445c8eedc = dead -# (for ) -trust cdbf33bc-17bc-49e3-b0d1-afa653a2c1f7 = dead -# (for ) -trust d8cf3fb5-4e8e-4732-b566-dab6f2d9dc4c = dead -# (for ) -trust e160a8ef-3b3d-4f0e-88eb-9ceba11b2f57 = dead -# (for ) -trust e39439a0-1486-55a0-ada3-c9785c08d650 = dead -# (for ) -trust e8bcb64b-17df-4d79-a5b6-9d444e4afa51 = dead -# (for ) -trust eae76b0e-ada9-4c5e-b9e3-db5998324e70 = dead -# (for ) -trust ec71b4bd-1b7b-408c-906f-91c4168fd89f = dead -# (for ) -trust f936015b-d62b-4899-a3f0-8d91efb385b5 = dead -# (for damla) -#trust 132503d4-dcde-4790-aabb-ee5ba539a3a0 = semitrusted -# (for ozge) -#trust 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = semitrusted -# (for mini) -#trust 7deafa14-8add-4316-984f-9b24eb713770 = semitrusted -# (for irem) -#trust aabc3536-a423-42b6-a234-5f110607296e = semitrusted -# (for yesim) -#trust ba3593c0-ddf1-4433-9916-aa25d1a52895 = semitrusted -# (for hubic) -#trust f980f309-0ebd-41c8-9303-73aff6409365 = semitrusted - -# Repository groups -# (Standard groups: client transfer backup incrementalbackup smallarchive archive source manual public unwanted) -# (Separate group names with spaces) -# (for damla) -group 132503d4-dcde-4790-aabb-ee5ba539a3a0 = PodA -# (for ozge) -group 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = PodA -# (for irem) -group aabc3536-a423-42b6-a234-5f110607296e = PodA -# (for yesim) -group ba3593c0-ddf1-4433-9916-aa25d1a52895 = PodA -# (for buse [origin]) -group bff7238e-bd92-4929-88a8-c59c1a1dcf03 = PodA -# (for hubic) -group f980f309-0ebd-41c8-9303-73aff6409365 = PodB -# (for mini) -group 7deafa14-8add-4316-984f-9b24eb713770 = manual -# (for web) -#group 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#group 00000000-0000-0000-0000-000000000002 = - -# Repository preferred contents -# (Set to "standard" to use a repository's group's preferred contents) -# (for damla) -wanted 132503d4-dcde-4790-aabb-ee5ba539a3a0 = groupwanted -# (for ozge) -wanted 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = groupwanted -# (for irem) -wanted aabc3536-a423-42b6-a234-5f110607296e = groupwanted -# (for yesim) -wanted ba3593c0-ddf1-4433-9916-aa25d1a52895 = groupwanted -# (for buse [origin]) -wanted bff7238e-bd92-4929-88a8-c59c1a1dcf03 = groupwanted -# (for hubic) -wanted f980f309-0ebd-41c8-9303-73aff6409365 = groupwanted -# (for mini) -wanted 7deafa14-8add-4316-984f-9b24eb713770 = standard -# (for web) -#wanted 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#wanted 00000000-0000-0000-0000-000000000002 = - -# Group preferred contents -# (Used by repositories with "groupwanted" in their preferred contents) -groupwanted storagePodA = -groupwanted storagePodB = -groupwanted PodA = not copies=PodA:1 -groupwanted PodB = not copies=PodB:1 -#groupwanted archive = -#groupwanted backup = -#groupwanted client = -#groupwanted incrementalbackup = -#groupwanted manual = -#groupwanted public = -#groupwanted smallarchive = -#groupwanted source = -#groupwanted transfer = -#groupwanted unwanted = - -# Standard preferred contents -# (Used by wanted or groupwanted expressions containing "standard") -# (For reference only; built-in and cannot be changed!) -# standard client = (include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1 -# standard transfer = (not (inallgroup=client and copies=client:2) and ((include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1)) or approxlackingcopies=1 -# standard backup = anything -# standard incrementalbackup = ((not copies=backup:1) and (not copies=incrementalbackup:1)) or approxlackingcopies=1 -# standard smallarchive = ((include=*/archive/* or include=archive/*) and ((not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1)) or approxlackingcopies=1 -# standard archive = (not (copies=archive:1 or copies=smallarchive:1)) or approxlackingcopies=1 -# standard source = not (copies=1) -# standard manual = present and ((include=* and ((exclude=*/archive/* and exclude=archive/*) or (not (copies=archive:1 or copies=smallarchive:1)))) or approxlackingcopies=1) -# standard public = inpreferreddir -# standard unwanted = not anything - -# Repository required contents -# (for damla) -required 132503d4-dcde-4790-aabb-ee5ba539a3a0 = -# (for ozge) -required 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = -# (for irem) -required aabc3536-a423-42b6-a234-5f110607296e = -# (for yesim) -required ba3593c0-ddf1-4433-9916-aa25d1a52895 = -# (for buse [origin]) -required bff7238e-bd92-4929-88a8-c59c1a1dcf03 = -# (for web) -#required 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#required 00000000-0000-0000-0000-000000000002 = -# (for mini) -#required 7deafa14-8add-4316-984f-9b24eb713770 = -# (for hubic) -#required f980f309-0ebd-41c8-9303-73aff6409365 = - -# Scheduled activities -# (Separate multiple activities with "; ") -# (for web) -#schedule 00000000-0000-0000-0000-000000000001 = -# (for bittorrent) -#schedule 00000000-0000-0000-0000-000000000002 = -# (for damla) -#schedule 132503d4-dcde-4790-aabb-ee5ba539a3a0 = -# (for ozge) -#schedule 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = -# (for mini) -#schedule 7deafa14-8add-4316-984f-9b24eb713770 = -# (for irem) -#schedule aabc3536-a423-42b6-a234-5f110607296e = -# (for yesim) -#schedule ba3593c0-ddf1-4433-9916-aa25d1a52895 = -# (for buse [origin]) -#schedule bff7238e-bd92-4929-88a8-c59c1a1dcf03 = -# (for hubic) -#schedule f980f309-0ebd-41c8-9303-73aff6409365 = - -"""]] - -With this settings all the repos tries get all of the files files that are present in other groups. Is there a way to debug this problem and tell why git-annex is trying to get the files? According to the settings it should not. I've also tried deleting all history this is a big (around 7 TB) old repo I thought maybe something got messed up along the way but it did not fix it. - -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -git-annex version: 5.20150825-g7826f84 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 - SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 -"""]] - -On Ubuntu 14.04. All repos are on external USB drives on the same machine except the one called "mini". - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - - -[1] https://git-annex.branchable.com/forum/git-annex_does_not_respect_preferred_content_settings/ - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Prefered_Content_not_Taken_into_Account/comment_1_70bccb282707b2e9b75c417832ed3459._comment b/doc/bugs/Prefered_Content_not_Taken_into_Account/comment_1_70bccb282707b2e9b75c417832ed3459._comment deleted file mode 100644 index ff8326d95..000000000 --- a/doc/bugs/Prefered_Content_not_Taken_into_Account/comment_1_70bccb282707b2e9b75c417832ed3459._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-15T16:04:28Z" - content=""" -I find it's not useful to split a conversation between multiple different -pages, so this bug is a bit counterproductive. - -But, you made up for that by posting the whole vicfg, which I was somehow -able to notice, amoungst all the noise, has this unusual bit: - - required 132503d4-dcde-4790-aabb-ee5ba539a3a0 = - # (for ozge) - required 1e1d0c4e-b1da-465f-9140-7128a7e3ee13 = - # (for irem) - required aabc3536-a423-42b6-a234-5f110607296e = - # (for yesim) - required ba3593c0-ddf1-4433-9916-aa25d1a52895 = - # (for buse [origin]) - required bff7238e-bd92-4929-88a8-c59c1a1dcf03 = - -So, required content has been set to "". It turns out that when this is done, -git-annex thinks that all files are preferred! This is because of a bug -when combining the required content and preferred content expressions. - -I reproduced this; `git annex get --auto` was not getting a file, -which was already known to be in another PodA repository. Then I ran `git annex required . ""` -and `git annex get --auto` started getting all files. - -You can't unset a required content setting back to being commented out. -A reasonable workaround is to set those to "groupwanted" too. Or get the -next git-annex release. -"""]] diff --git a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path.mdwn b/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path.mdwn deleted file mode 100644 index 20a92fea5..000000000 --- a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path.mdwn +++ /dev/null @@ -1,82 +0,0 @@ -### Please describe the problem. -1. git annex - command not found - found a workaround -2. git assistant broken - -### What steps will reproduce the problem? -1. fresh download of 19.5.msysgit.0 -2. fresh download of recent git-annex -### What version of git-annex are you using? On what operating system? -1. Window 7. -2. git version 1.9.5.msysgit.0 -2. git-annex version 5.20150205-g0f63eb0 - -### Please provide any additional information below. -After copying - cp cmd/git-annex bin -in the git install directory it was working. - -Adding a fresh "removeable Storage" repository delivered -git [Param "config",Param "core.fsyncobjectfiles",Param "true"] failed - -calling the command (locally) manually: - git config core.fsyncobjectfiles true -works fine, but i found no way to call it on the remote directory. -The "annex" directory on H: was created and looks like a bare git depot. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -[2015-02-07 17:09:04 Mitteleuropõische Zeit] main: starting assistant version 5.20150205-g0f63eb0 -[2015-02-07 17:09:04 Mitteleuropõische Zeit] Cronner: You should enable consistency checking to protect your data. -(scanning...) [2015-02-07 17:09:05 Mitteleuropõische Zeit] Watcher: Performing startup scan -(started...) [2015-02-07 17:09:42 Mitteleuropõische Zeit] main: starting assistant version 5.20150205-g0f63eb0 -[2015-02-07 17:09:42 Mitteleuropõische Zeit] Cronner: You should enable consistency checking to protect your data. -recv: failed (No error) -(scanning...) [2015-02-07 17:09:42 Mitteleuropõische Zeit] Watcher: Performing startup scan -(started...) [2015-02-07 17:09:51 Mitteleuropõische Zeit] main: starting assistant version 5.20150205-g0f63eb0 -[2015-02-07 17:09:52 Mitteleuropõische Zeit] Cronner: You should enable consistency checking to protect your data. -(scanning...) [2015-02-07 17:09:52 Mitteleuropõische Zeit] Watcher: Performing startup scan -(started...) [2015-02-07 17:10:18 Mitteleuropõische Zeit] Committer: Adding DSC07173.JPG DSC07174.JPG DSC07175.JPG - -add 2014-08-01-Waal\DSC07173.JPG Committer crashed: sha256sum parse error -[2015-02-07 17:10:18 Mitteleuropõische Zeit] Committer: warning Committer crashed: sha256sum parse error -recv: failed (No error) -[2015-02-07 17:10:27 Mitteleuropõische Zeit] Committer: Adding DSC07175.JPG DSC07176.JPG DSC07177.JPG DSC07178.JPG -add 2014-08-01-Waal\DSC07175.JPG Committer crashed: sha256sum parse error -[2015-02-07 17:10:27 Mitteleuropõische Zeit] Committer: warning Committer crashed: sha256sum parse error -[2015-02-07 17:10:37 Mitteleuropõische Zeit] main: starting assistant version 5.20150205-g0f63eb0 -[2015-02-07 17:10:37 Mitteleuropõische Zeit] Cronner: You should enable consistency checking to protect your data. -recv: failed (No error) -recv: failed (No error) -DaemonStatus crashed: MoveFileEx ".git\\annex\\daemon.status6720.tmp" ".git\\annex\\daemon.status": permission denied (Zugriff verweigert) -[2015-02-07 17:10:37 Mitteleuropõische Zeit] DaemonStatus: warning DaemonStatus crashed: MoveFileEx ".git\\annex\\daemon.status6720.tmp" ".git\\annex\\daemon.status": permission denied (Zugriff verweigert) -(scanning...) [2015-02-07 17:10:37 Mitteleuropõische Zeit] Watcher: Performing startup scan -(started...) [2015-02-07 17:10:38 Mitteleuropõische Zeit] Committer: Adding DSC07178.JPG DSC07177.JPG DSC07176.JPG DSC07175.JPG DSC07174.JPG DSC07173.JPG - -add .\2014-08-01-Waal\DSC07178.JPG Committer crashed: sha256sum parse error -[2015-02-07 17:10:38 Mitteleuropõische Zeit] Committer: warning Committer crashed: sha256sum parse error -[2015-02-07 17:10:40 Mitteleuropõische Zeit] main: starting assistant version 5.20150205-g0f63eb0 -WebApp crashed: MoveFileEx ".git\\annex\\webapp.html5592.tmp" ".git\\annex\\webapp.html": permission denied (Zugriff verweigert) -[2015-02-07 17:10:40 Mitteleuropõische Zeit] WebApp: warning WebApp crashed: MoveFileEx ".git\\annex\\webapp.html5592.tmp" ".git\\annex\\webapp.html": permission denied (Zugriff verweigert) -[2015-02-07 17:10:40 Mitteleuropõische Zeit] Cronner: You should enable consistency checking to protect your data. -(scanning...) [2015-02-07 17:10:41 Mitteleuropõische Zeit] Watcher: Performing startup scan -(started...) [2015-02-07 17:10:41 Mitteleuropõische Zeit] Committer: Adding DSC07178.JPG DSC07177.JPG DSC07176.JPG DSC07175.JPG DSC07174.JPG DSC07173.JPG - -add .\2014-08-01-Waal\DSC07178.JPG Committer crashed: sha256sum parse error -[2015-02-07 17:10:42 Mitteleuropõische Zeit] Committer: warning Committer crashed: sha256sum parse error -rerrrcereevcecc:vcvv :v::f : af ffiafaaliaiielilldelee dedd( d N( ((oN(NN oNooe o re eerrerrorrrrroroo)rorr -)r)) -) - - -recv: failed (No error) -recv: failed (No error) -fatal: unable to access '..\..\..\..\H:\annex/config': Invalid argument -07/Feb/2015:17:11:40 +0100 [Error#yesod-core] git [Param "config",Param "core.fsyncobjectfiles",Param "true"] failed @(yesod-core-1.2.19:Yesod.Core.Class.Yesod .\Yesod\Core\Class\Yesod.hs:503:5) - - - -# End of transcript or log. -"""]] - -> User error; [[closing|done]] --[[Joey]] diff --git a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_1_c949934a5fc8889f7cbeac9e789116f4._comment b/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_1_c949934a5fc8889f7cbeac9e789116f4._comment deleted file mode 100644 index cda18c4a4..000000000 --- a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_1_c949934a5fc8889f7cbeac9e789116f4._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-02-09T20:44:41Z" - content=""" -Are you sure you told msysgit to add itself to PATH when installing it? - -Unless something has changed in msysgit, it installs `cmd/git.exe`, and it -puts `cmd` in PATH, not `bin`. -"""]] diff --git a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_2_5087aa261b897090031ad32bdc1434f9._comment b/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_2_5087aa261b897090031ad32bdc1434f9._comment deleted file mode 100644 index 4d0ca3634..000000000 --- a/doc/bugs/Problem_with_windows_version__58___1.9.5.msysgit.0_wrong_path/comment_2_5087aa261b897090031ad32bdc1434f9._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl52i_Ao3TpmLrpYMCbRcnNiMuNiwIDr4E" - nickname="Martin" - subject="Cross check" - date="2015-02-10T22:58:01Z" - content=""" -I reinstalled the stuff, with the path \"Option\" set. No git-annex is found. -All other problems remained. -"""]] diff --git a/doc/bugs/Req__58___Upgrade_to_Yesod_1.4__63___https__58____47____47__github.com__47__NixOS__47__nixpkgs__47__pull__47__4391.mdwn b/doc/bugs/Req__58___Upgrade_to_Yesod_1.4__63___https__58____47____47__github.com__47__NixOS__47__nixpkgs__47__pull__47__4391.mdwn deleted file mode 100644 index 6e0117202..000000000 --- a/doc/bugs/Req__58___Upgrade_to_Yesod_1.4__63___https__58____47____47__github.com__47__NixOS__47__nixpkgs__47__pull__47__4391.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. - -Not a super big "problem" but I'm blocked upgrading Nix packages to Yesod 1.4 because of git-annex breakage. - -### What steps will reproduce the problem? - -Try to build with Yesod 1.4 - -### What version of git-annex are you using? On what operating system? - -Latest - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> [[fixed|done]], although I have not made a release yet. -> It's a 1 line change anyhow, just adding ViewPatterns. --[[Joey]] diff --git a/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn b/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn deleted file mode 100644 index 4e9ebcaa7..000000000 --- a/doc/bugs/SHA3__95____42___backends_missing_from_newest_official_amd64_Linux_builds.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -### Please describe the problem. - -All the new wonderful SHA3_* backends are gone from the Linux AMD64 build of 5.20150825-g7826f84. They exist in the i386 version (5.20150824-g8529cb2), though. It's probably compiled without Cryptonite support or something. - -### What steps will reproduce the problem? - -Everything involving any of the SHA3_* backends result in an "unknown backend SHA3_*" error with the amd64 build (5.20150825-g7826f84). The i386 version (5.20150824-g8529cb2) works. - - wget https://github.com/sunny256/utils/raw/master/tests/ga-fsck-size-files/annex-backends.tar.gz - tar xzf annex-backends.tar.gz - cd annex-backends - git annex fsck - -results in - - [snip] - fsck SHA384.txt (checksum...) - ok - fsck SHA384E.txt (checksum...) - ok - - skipping SHA3_224.txt (unknown backend SHA3_224) - - skipping SHA3_224E.txt (unknown backend SHA3_224E) - - skipping SHA3_256.txt (unknown backend SHA3_256) - - skipping SHA3_256E.txt (unknown backend SHA3_256E) - - skipping SHA3_384.txt (unknown backend SHA3_384) - - skipping SHA3_384E.txt (unknown backend SHA3_384E) - - skipping SHA3_512.txt (unknown backend SHA3_512) - - skipping SHA3_512E.txt (unknown backend SHA3_512E) - fsck SHA512.txt (checksum...) - ok - fsck SHA512E.txt (checksum...) - ok - [snip] - fsck WORM.txt ok - (recording state in git...) - -### What version of git-annex are you using? On what operating system? - -Newest official builds from downloads.kitenet.net . Debian GNU/Linux all the way. - -### 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) - -Oh, yes. It rules. :) One of the most important programs I use because I have all my valuable stuff in it. My files have never been safer. - -> Yeah, debian unstable got too unstable and I had to move those -> autobuilders to testing, which didh't have the necessary library. -> They're back on unstable now, so [[done]] --[[Joey]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working.mdwn b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working.mdwn deleted file mode 100644 index c221e00b5..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -### Please describe the problem. - -Cannot set S3 remote to use Infrequently accessed. - -### What steps will reproduce the problem? - -git annex enableremote <remote> storageclass=STANDARD_IA - -### What version of git-annex are you using? On what operating system? - -5.20150930 on Arch Linux - -### Please provide any additional information below. - -[[!format sh """ - -# Trying with RR -$ git annex enableremote amazon storageclass=REDUCED_REDUNDANCY -enableremote amazon (encryption update) (hybrid cipher with gpg key XXX) ok -(recording state in git...) - -$ git annex info amazon -remote: amazon -description: [amazon] -uuid: XXX -trust: semitrusted -cost: 250.0 -type: S3 -creds: embedded in git repository (gpg encrypted) -bucket: XXX -endpoint: s3.amazonaws.com -port: 80 -storage class: ReducedRedundancy -# snip - -# Trying with IA -$ git annex enableremote amazon storageclass=STANDARD_IA -enableremote amazon (encryption update) (hybrid cipher with gpg key XXX) ok -(recording state in git...) - -$ git annex info amazon -remote: amazon -description: [amazon] -uuid: XXX -trust: semitrusted -cost: 250.0 -type: S3 -creds: embedded in git repository (gpg encrypted) -bucket: XXX -endpoint: s3.amazonaws.com -port: 80 -storage class: Standard - -# End of transcript or log. -"""]] - -### 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) - -I've had great experiences using git annex normally, but the special remotes tend -to get dicey, like here. - -> The `STANDARD_IA` docuemntation now includes the necessary version of the -> aws library to support this feature. [[done]] --[[Joey]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_1_e9c097795b7b35f758a9cff782c87fc2._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_1_e9c097795b7b35f758a9cff782c87fc2._comment deleted file mode 100644 index 34b5653e1..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_1_e9c097795b7b35f758a9cff782c87fc2._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="darkfeline" - subject="comment 1" - date="2015-10-09T02:25:57Z" - content=""" -I should have [searched the forums first](https://git-annex.branchable.com/forum/Is_S3___34__Standard-Infrequent_Access__34___storage_class_supported__63__/). - -It looks like the feature has not been merged yet, despite appearing in the documentation on the S3 page. -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_2_1c153ecedc231f5cd4d6b2f081721494._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_2_1c153ecedc231f5cd4d6b2f081721494._comment deleted file mode 100644 index ca1d9a98f..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_2_1c153ecedc231f5cd4d6b2f081721494._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-10-12T17:08:06Z" - content=""" -The feature is supported in git-annex, but it needs a version of the aws -library that has not seen a stable release yet. -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_3_65edb23aa86e3166ec6d323165833699._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_3_65edb23aa86e3166ec6d323165833699._comment deleted file mode 100644 index ad54e8604..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_3_65edb23aa86e3166ec6d323165833699._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d" - subject="comment 3" - date="2015-12-08T09:44:49Z" - content=""" -It seems like aws-0.13.0 is released now. Will it be used in the next release of git-annex? I am using the prebuilt binary for 5.20151116 and STANDARD_IA does not work for me. - -Is it possible to print out the version numbers of git-annex dependencies (something like `git-annex version --verbose`)? -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_4_4b51c678f5d5cac7e9af026b486d9d9f._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_4_4b51c678f5d5cac7e9af026b486d9d9f._comment deleted file mode 100644 index 06a18dab4..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_4_4b51c678f5d5cac7e9af026b486d9d9f._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-12-10T15:23:12Z" - content=""" -I've added something to `git annex version` about this today: -"S3(storageclasses)" - -The prebuilt linux builds currently use package versions from Debian -unstable, so we have to wait for the aws package to get updated there. -(I could hand-hack it, but that would make the build break later.) - -The Windows and OSX builds have already been updated; the latter only just -now, so it'll be in the next daily build. Updating the Android build -environment is a massive pain and I try to only do that bi-anually. -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_5_ebb7cc0e1c125765611014049d403d61._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_5_ebb7cc0e1c125765611014049d403d61._comment deleted file mode 100644 index 73feda9a9..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_5_ebb7cc0e1c125765611014049d403d61._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d" - subject="comment 5" - date="2015-12-12T05:28:51Z" - content=""" -Thanks for the clarification. I was referring to the Linux build. I might have been wrong about aws 0.13 being released. It is listed in the NixOS and Hackage package repos, but I don't see a 0.13.0 tag on the project's GitHub page, so maybe those other repos are packaging the nightly build of the master branch as version 0.13.0 while the final 0.13.0 hasn't been frozen yet. I will wait for the Debian repo to get updated (I could build it by hand but I like to rely on the package manager as I will otherwise forget to update the package in the future). It looks like Debian unstable lags the git repo tags by 1-2 months. -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_6_95084c3b8b6780c16c408cd276920d4a._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_6_95084c3b8b6780c16c408cd276920d4a._comment deleted file mode 100644 index 88ccd85d4..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_6_95084c3b8b6780c16c408cd276920d4a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d" - nickname="wsha.code+ga" - subject="comment 6" - date="2016-01-16T12:20:05Z" - content=""" -I just upgraded to 6.20160114-g297a744. `git annex version` shows me `S3(multipartupload)`, and trying to set `storageclass=STANDARD_IA` still leaves the storageclass as `Standard`. Would it show `S3(multipartupload,storageclasses)` if it had `STANDARD_IA` support from `aws-0.13`? I see that `aws-0.13.0` was added to Debian unstable on 2016/01/11 -- was that too close to make the 2016/01/14 release? -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_7_3c0b266607dd7d5349f1502b877b3e3e._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_7_3c0b266607dd7d5349f1502b877b3e3e._comment deleted file mode 100644 index a4621dd8a..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_7_3c0b266607dd7d5349f1502b877b3e3e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-01-19T20:21:26Z" - content=""" -Yes, you need "(storageclasses)". - -I see it's available in autobuilds now. -"""]] diff --git a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_8_00b10af9cc50b984b32c250d939fa196._comment b/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_8_00b10af9cc50b984b32c250d939fa196._comment deleted file mode 100644 index 9268c0ed9..000000000 --- a/doc/bugs/STANDARD__95__IA_for_S3_remote_not_working/comment_8_00b10af9cc50b984b32c250d939fa196._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="wsha.code+ga@b38779424f41c5701bbe5937340be43ff1474b2d" - nickname="wsha.code+ga" - subject="comment 8" - date="2016-01-20T19:24:17Z" - content=""" -Thanks for checking. I am using Arch, and I just noticed that in the last week a new `git-annex` package was added to the official `community` repo (I guess you noticed too since I see that the [[Install]] page is already updated). Previously, I had been using a package from the AUR that repackaged the prebuilt binary, but now I have switched to the new package in `community` which is rebuilt by Arch's build service so that it includes the updated `aws` library. -"""]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn deleted file mode 100644 index 096562199..000000000 --- a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail.mdwn +++ /dev/null @@ -1,57 +0,0 @@ -### Please describe the problem. - -If a filename has a single space (and only one space), `git annex add` will fail out with the following message: - - add one two git-annex: unknown response from git cat-file ("HEAD:./one two missing",Ref "HEAD:./one two") - CallStack (from HasCallStack): - error, called at ./Git/CatFile.hs:102:28 in main:Git.CatFile - -### What steps will reproduce the problem? - -Run the following: - - git init . - git annex init - touch "one two" - # this will cause error - git annex add "one two" - touch "one two three" - # this is fine - git annex add "one two three" - -### What version of git-annex are you using? On what operating system? - -Output of `git annex version` - - git-annex version: 6.20161027 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -Operating System: Linux (NixOS 16.09.909.238c7e0 (Flounder)) - -### Please provide any additional information below. - -Maybe related to [https://git-annex.branchable.com/forum/unknown_response_from_git_cat-file/](https://git-annex.branchable.com/forum/unknown_response_from_git_cat-file/) or [https://git-annex.branchable.com/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/](https://git-annex.branchable.com/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/)? - -EDIT: Somewhat surprisingly, if I build from source using `cabal`, everything works fine. - - .cabal-sandbox/bin/git-annex version - git-annex version: 6.20161113-g1e88c12 - build flags: Assistant Webapp Pairing Testsuite WebDAV Inotify ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -Not sure whether this means that this bug is actually fixed or whether it's an artifact of how things are built in Nix. - -### 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) - -Just starting out with it as a way of archiving some of my media seems to work great apart from this. Thanks a bunch! - -> This bug was already fixed in git-annex 6.20161031. I told the Debian -> maintainer about the bug fix at the time; package has not been updated -> yet. [[done]] on git-annex side. --[[Joey]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment deleted file mode 100644 index 5f8b120e2..000000000 --- a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_1_0cf0856c6408c9c588133023a3a6ba8f._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="gfa@1e86118cd41fbfea50004af221471ad97b55af18" - nickname="gfa" - avatar="http://cdn.libravatar.org/avatar/4678da4da55c67fa668e31ea0a76b201" - subject="same on Debian" - date="2016-11-14T09:13:19Z" - content=""" -I face the same issue on Debian testing - -git-annex 6.20161012-1 -git 1:2.10.2-1 -"""]] diff --git a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment b/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment deleted file mode 100644 index bf41d40a5..000000000 --- a/doc/bugs/Single_space_in_file_name_causes_git_annex_add_to_fail/comment_2_13c242250d1509d933b8f0bcb7b67302._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~stephane-gourichon-lpad" - nickname="stephane-gourichon-lpad" - avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089" - subject="Known bug, fixed." - date="2016-11-23T18:04:27Z" - content=""" -This is a known bug introduced in 6.20161012 and fixed in 6.20161031. - -Solution is: just update your copy of git-annex. At this time most recent is 6.20161119 . - -For more details, see changelog at https://github.com/joeyh/git-annex/blob/master/CHANGELOG#L53 - - - -"""]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage.mdwn b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage.mdwn deleted file mode 100644 index 1c11e45ba..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage.mdwn +++ /dev/null @@ -1,94 +0,0 @@ -### Please describe the problem. - -The S3 remote does not support Google Cloud Storage buckets with the -Durable Reduced Availability or Nearline storage classes. These are -less-expensive alternatives to the Standard storage class, which would -otherwise be a good fit for git-annex. - -### What steps will reproduce the problem? - -1. `git annex initremote cloud type=S3 encryption=none host=storage.googleapis.com bucket=storage-class-test storageclass=NEARLINE` -2. Observe that the bucket is created with Standard storage class. - -or, - -1. Use Cloud Storage web interface to create the `storage-class-test` bucket with Nearline storage class. -2. `git annex -d initremote cloud type=S3 encryption=none host=storage.googleapis.com bucket=storage-class-test storageclass=NEARLINE` -2. Observe failure shown below. - -### What version of git-annex are you using? On what operating system? - -5.20150528, Fedora 22 - -### Please provide any additional information below. - -Google Cloud Storage applies the storage class per-bucket rather than per-object. As a result there are two separate problems: - -1. If git-annex creates the bucket, there is no way to get it to pass the `StorageClass` XML element in the PUT Bucket operation (see e.g. [here](https://cloud.google.com/storage/docs/nearline#create), the "XML API" tab). -2. If the bucket is manually created by the user, subsequent PUT Object operations explicitly pass an `x-amz-storage-class` of `STANDARD` (or `REDUCED_REDUNDANCY`). Since this is incompatible with the storage class of the bucket, Google Cloud Storage returns `InvalidArgument`. - -Example of the second problem: - -[[!format sh """ -$ git annex -d initremote cloud type=S3 encryption=none host=storage.googleapis.com bucket=storage-class-test storageclass=NEARLINE -[2015-05-31 17:38:21 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2015-05-31 17:38:21 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2015-05-31 17:38:21 EDT] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..417a5e8880eb22fa5288056f4f4e5d998e64a3e6","-n1","--pretty=%H"] -[2015-05-31 17:38:21 EDT] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -initremote cloud (checking bucket...) [2015-05-31 17:38:21 EDT] String to sign: "GET\n\n\nSun, 31 May 2015 21:38:21 GMT\n/storage-class-test/annex-uuid" -[2015-05-31 17:38:21 EDT] Host: "storage-class-test.storage.googleapis.com" -[2015-05-31 17:38:21 EDT] Path: "/annex-uuid" -[2015-05-31 17:38:21 EDT] Query string: "" -[2015-05-31 17:38:21 EDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"} -[2015-05-31 17:38:21 EDT] Response header 'Content-Type': 'application/xml; charset=UTF-8' -[2015-05-31 17:38:21 EDT] Response header 'Content-Length': '127' -[2015-05-31 17:38:21 EDT] Response header 'Date': 'Sun, 31 May 2015 21:38:21 GMT' -[2015-05-31 17:38:21 EDT] Response header 'Expires': 'Sun, 31 May 2015 21:38:21 GMT' -[2015-05-31 17:38:21 EDT] Response header 'Cache-Control': 'private, max-age=0' -[2015-05-31 17:38:21 EDT] Response header 'Server': 'UploadServer ("Built on May 21 2015 09:31:47 (1432225907)")' -[2015-05-31 17:38:21 EDT] Response header 'Alternate-Protocol': '80:quic,p=0' -[2015-05-31 17:38:21 EDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> -[2015-05-31 17:38:21 EDT] String to sign: "GET\n\n\nSun, 31 May 2015 21:38:21 GMT\n/storage-class-test/" -[2015-05-31 17:38:21 EDT] Host: "storage-class-test.storage.googleapis.com" -[2015-05-31 17:38:21 EDT] Path: "/" -[2015-05-31 17:38:21 EDT] Query string: "" -[2015-05-31 17:38:22 EDT] Response status: Status {statusCode = 200, statusMessage = "OK"} -[2015-05-31 17:38:22 EDT] Response header 'x-goog-metageneration': '1' -[2015-05-31 17:38:22 EDT] Response header 'Content-Type': 'application/xml; charset=UTF-8' -[2015-05-31 17:38:22 EDT] Response header 'Content-Length': '219' -[2015-05-31 17:38:22 EDT] Response header 'Date': 'Sun, 31 May 2015 21:38:21 GMT' -[2015-05-31 17:38:22 EDT] Response header 'Expires': 'Sun, 31 May 2015 21:38:21 GMT' -[2015-05-31 17:38:22 EDT] Response header 'Cache-Control': 'private, max-age=0' -[2015-05-31 17:38:22 EDT] Response header 'Server': 'UploadServer ("Built on May 21 2015 09:31:47 (1432225907)")' -[2015-05-31 17:38:22 EDT] Response header 'Alternate-Protocol': '80:quic,p=0' -[2015-05-31 17:38:22 EDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> -[2015-05-31 17:38:22 EDT] String to sign: "GET\n\n\nSun, 31 May 2015 21:38:22 GMT\n/storage-class-test/annex-uuid" -[2015-05-31 17:38:22 EDT] Host: "storage-class-test.storage.googleapis.com" -[2015-05-31 17:38:22 EDT] Path: "/annex-uuid" -[2015-05-31 17:38:22 EDT] Query string: "" -[2015-05-31 17:38:22 EDT] Response status: Status {statusCode = 404, statusMessage = "Not Found"} -[2015-05-31 17:38:22 EDT] Response header 'Content-Type': 'application/xml; charset=UTF-8' -[2015-05-31 17:38:22 EDT] Response header 'Content-Length': '127' -[2015-05-31 17:38:22 EDT] Response header 'Date': 'Sun, 31 May 2015 21:38:22 GMT' -[2015-05-31 17:38:22 EDT] Response header 'Expires': 'Sun, 31 May 2015 21:38:22 GMT' -[2015-05-31 17:38:22 EDT] Response header 'Cache-Control': 'private, max-age=0' -[2015-05-31 17:38:22 EDT] Response header 'Server': 'UploadServer ("Built on May 21 2015 09:31:47 (1432225907)")' -[2015-05-31 17:38:22 EDT] Response header 'Alternate-Protocol': '80:quic,p=0' -[2015-05-31 17:38:22 EDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> -[2015-05-31 17:38:22 EDT] String to sign: "PUT\n\n\nSun, 31 May 2015 21:38:22 GMT\nx-amz-storage-class:STANDARD\n/storage-class-test/annex-uuid" -[2015-05-31 17:38:22 EDT] Host: "storage-class-test.storage.googleapis.com" -[2015-05-31 17:38:22 EDT] Path: "/annex-uuid" -[2015-05-31 17:38:22 EDT] Query string: "" -[2015-05-31 17:38:22 EDT] Body: "6eb85d96-8f9b-456a-819c-1724d12d2ffd" -[2015-05-31 17:38:22 EDT] Response status: Status {statusCode = 400, statusMessage = "Bad Request"} -[2015-05-31 17:38:22 EDT] Response header 'Content-Type': 'application/xml; charset=UTF-8' -[2015-05-31 17:38:22 EDT] Response header 'Content-Length': '117' -[2015-05-31 17:38:22 EDT] Response header 'Vary': 'Origin' -[2015-05-31 17:38:22 EDT] Response header 'Date': 'Sun, 31 May 2015 21:38:22 GMT' -[2015-05-31 17:38:22 EDT] Response header 'Server': 'UploadServer ("Built on May 21 2015 09:31:47 (1432225907)")' -[2015-05-31 17:38:22 EDT] Response header 'Alternate-Protocol': '80:quic,p=0' -[2015-05-31 17:38:22 EDT] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> -git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, s3ErrorCode = "InvalidArgument", s3ErrorMessage = "Invalid argument.", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing} -"""]] - -> [[done]], see comments --[[Joey]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_1_a10aaa758daee3ca0b064c60c0382ce8._comment b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_1_a10aaa758daee3ca0b064c60c0382ce8._comment deleted file mode 100644 index bc4d5e95c..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_1_a10aaa758daee3ca0b064c60c0382ce8._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-17T21:09:24Z" - content=""" -It's now possible to use storageclass=NEARLINE, when git-annex is built -with aws-0.13.0. So, the approach of manually creating the bucket with the -desired storage class should work now. - -I'm unsure if the first method, of letting git-annex create the bucket, -will work now. Can you test? It may work now too with -storageclass=NEARLINE. While no storage class is currently specified when -creating the bucket (that's not in the S3 api at all); but once the bucket -exists, with whatever storage class is default, git-annex will specify -NEARLINE when storing objects in it. Seems a good chance this will work, -and it'd be easier than extending the aws library with google-specific -features. -"""]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_2_8a23d2743cdad0ef29265e59adcebd6f._comment b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_2_8a23d2743cdad0ef29265e59adcebd6f._comment deleted file mode 100644 index ea82fca2e..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_2_8a23d2743cdad0ef29265e59adcebd6f._comment +++ /dev/null @@ -1,84 +0,0 @@ -[[!comment format=mdwn - username="bgilbert@a0c64716cf22216de5eeb15a5ca4f009164c8fb3" - nickname="bgilbert" - subject="comment 2" - date="2015-09-27T01:00:46Z" - content=""" -It does work now with manually-created buckets. It still doesn't work when the bucket is created automatically: - - $ git annex -d initremote nearline type=S3 encryption=none host=storage.googleapis.com storageclass=NEARLINE - [2015-09-26 19:21:43.877399] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] - [2015-09-26 19:21:43.888972] process done ExitSuccess - [2015-09-26 19:21:43.889496] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] - [2015-09-26 19:21:43.894184] process done ExitSuccess - [2015-09-26 19:21:43.895521] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..113c78849a7fcb8c834e03feac3c492aaa58d8e5\",\"-n1\",\"--pretty=%H\"] - [2015-09-26 19:21:43.901039] process done ExitSuccess - [2015-09-26 19:21:43.902895] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] - initremote nearline (checking bucket...) [2015-09-26 19:21:43.912757] String to sign: \"GET\n\n\nSat, 26 Sep 2015 23:21:43 GMT\n/nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460/annex-uuid\" - [2015-09-26 19:21:43.914566] Host: \"nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460.storage.googleapis.com\" - [2015-09-26 19:21:43.916021] Path: \"/annex-uuid\" - [2015-09-26 19:21:43.916716] Query string: \"\" - [2015-09-26 19:21:44.161168] Response status: Status {statusCode = 404, statusMessage = \"Not Found\"} - [2015-09-26 19:21:44.162829] Response header 'X-GUploader-UploadID': '[...]' - [2015-09-26 19:21:44.165422] Response header 'Content-Type': 'application/xml; charset=UTF-8' - [2015-09-26 19:21:44.16679] Response header 'Content-Length': '133' - [2015-09-26 19:21:44.167806] Response header 'Date': 'Sat, 26 Sep 2015 23:21:44 GMT' - [2015-09-26 19:21:44.169038] Response header 'Expires': 'Sat, 26 Sep 2015 23:21:44 GMT' - [2015-09-26 19:21:44.170508] Response header 'Cache-Control': 'private, max-age=0' - [2015-09-26 19:21:44.171829] Response header 'Server': 'UploadServer' - [2015-09-26 19:21:44.172773] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> - [2015-09-26 19:21:44.173874] String to sign: \"GET\n\n\nSat, 26 Sep 2015 23:21:44 GMT\n/nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460/\" - [2015-09-26 19:21:44.175243] Host: \"nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460.storage.googleapis.com\" - [2015-09-26 19:21:44.176297] Path: \"/\" - [2015-09-26 19:21:44.176719] Query string: \"\" - [2015-09-26 19:21:44.316739] Response status: Status {statusCode = 404, statusMessage = \"Not Found\"} - [2015-09-26 19:21:44.318835] Response header 'X-GUploader-UploadID': '[...]' - [2015-09-26 19:21:44.322411] Response header 'Content-Type': 'application/xml; charset=UTF-8' - [2015-09-26 19:21:44.324451] Response header 'Content-Length': '133' - [2015-09-26 19:21:44.326001] Response header 'Date': 'Sat, 26 Sep 2015 23:21:44 GMT' - [2015-09-26 19:21:44.327709] Response header 'Expires': 'Sat, 26 Sep 2015 23:21:44 GMT' - [2015-09-26 19:21:44.329293] Response header 'Cache-Control': 'private, max-age=0' - [2015-09-26 19:21:44.331073] Response header 'Server': 'UploadServer' - [2015-09-26 19:21:44.332693] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> - (creating bucket in US...) [2015-09-26 19:21:44.334384] String to sign: \"PUT\n\n\nSat, 26 Sep 2015 23:21:44 GMT\n/nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460/\" - [2015-09-26 19:21:44.336832] Host: \"nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460.storage.googleapis.com\" - [2015-09-26 19:21:44.338583] Path: \"/\" - [2015-09-26 19:21:44.339326] Query string: \"\" - [2015-09-26 19:21:50.024323] Response status: Status {statusCode = 200, statusMessage = \"OK\"} - [2015-09-26 19:21:50.02519] Response header 'X-GUploader-UploadID': '[...]' - [2015-09-26 19:21:50.026329] Response header 'x-goog-metageneration': '1' - [2015-09-26 19:21:50.026902] Response header 'Vary': 'Origin' - [2015-09-26 19:21:50.027376] Response header 'Content-Length': '0' - [2015-09-26 19:21:50.027993] Response header 'Date': 'Sat, 26 Sep 2015 23:21:49 GMT' - [2015-09-26 19:21:50.028587] Response header 'Server': 'UploadServer' - [2015-09-26 19:21:50.029113] Response header 'Content-Type': 'text/html; charset=UTF-8' - [2015-09-26 19:21:50.029772] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> - [2015-09-26 19:21:50.030493] String to sign: \"GET\n\n\nSat, 26 Sep 2015 23:21:50 GMT\n/nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460/annex-uuid\" - [2015-09-26 19:21:50.031606] Host: \"nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460.storage.googleapis.com\" - [2015-09-26 19:21:50.032369] Path: \"/annex-uuid\" - [2015-09-26 19:21:50.032786] Query string: \"\" - [2015-09-26 19:21:50.280518] Response status: Status {statusCode = 404, statusMessage = \"Not Found\"} - [2015-09-26 19:21:50.280995] Response header 'X-GUploader-UploadID': '[...]' - [2015-09-26 19:21:50.281575] Response header 'Content-Type': 'application/xml; charset=UTF-8' - [2015-09-26 19:21:50.28201] Response header 'Content-Length': '127' - [2015-09-26 19:21:50.282269] Response header 'Date': 'Sat, 26 Sep 2015 23:21:50 GMT' - [2015-09-26 19:21:50.282555] Response header 'Expires': 'Sat, 26 Sep 2015 23:21:50 GMT' - [2015-09-26 19:21:50.282919] Response header 'Cache-Control': 'private, max-age=0' - [2015-09-26 19:21:50.283199] Response header 'Server': 'UploadServer' - [2015-09-26 19:21:50.283585] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> - [2015-09-26 19:21:50.283998] String to sign: \"PUT\n\n\nSat, 26 Sep 2015 23:21:50 GMT\nx-amz-storage-class:NEARLINE\n/nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460/annex-uuid\" - [2015-09-26 19:21:50.284663] Host: \"nearline-38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460.storage.googleapis.com\" - [2015-09-26 19:21:50.28504] Path: \"/annex-uuid\" - [2015-09-26 19:21:50.285233] Query string: \"\" - [2015-09-26 19:21:50.285421] Body: \"38b55d4f-fe3f-4b7a-a4b2-ad22d29ad460\" - [2015-09-26 19:21:50.431435] Response status: Status {statusCode = 400, statusMessage = \"Bad Request\"} - [2015-09-26 19:21:50.431926] Response header 'X-GUploader-UploadID': '[...]' - [2015-09-26 19:21:50.432473] Response header 'Content-Type': 'application/xml; charset=UTF-8' - [2015-09-26 19:21:50.432797] Response header 'Content-Length': '117' - [2015-09-26 19:21:50.433033] Response header 'Vary': 'Origin' - [2015-09-26 19:21:50.433301] Response header 'Date': 'Sat, 26 Sep 2015 23:21:50 GMT' - [2015-09-26 19:21:50.433581] Response header 'Server': 'UploadServer' - [2015-09-26 19:21:50.433961] Response metadata: S3: request ID=<none>, x-amz-id-2=<none> - git-annex: S3Error {s3StatusCode = Status {statusCode = 400, statusMessage = \"Bad Request\"}, s3ErrorCode = \"InvalidArgument\", s3ErrorMessage = \"Invalid argument.\", s3ErrorResource = Nothing, s3ErrorHostId = Nothing, s3ErrorAccessKeyId = Nothing, s3ErrorStringToSign = Nothing, s3ErrorBucket = Nothing, s3ErrorEndpointRaw = Nothing, s3ErrorEndpoint = Nothing} - -"""]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_3_18aeaeace47224ad1c2c86beb356ddcb._comment b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_3_18aeaeace47224ad1c2c86beb356ddcb._comment deleted file mode 100644 index 25cc4958f..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_3_18aeaeace47224ad1c2c86beb356ddcb._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-10-15T19:47:20Z" - content=""" -Your log shows it's passing x-amz-storage-class:NEARLINE in the object PUT -request, so at least that works. - -I've filed a bug on aws to get PutBucket extended to allow specifying a -StorageClass: <https://github.com/aristidb/aws/issues/182> -"""]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_4_4fe89a4e4f865acec60ac5b1e6540e60._comment b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_4_4fe89a4e4f865acec60ac5b1e6540e60._comment deleted file mode 100644 index a70042cbc..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_4_4fe89a4e4f865acec60ac5b1e6540e60._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-10-15T20:23:23Z" - content=""" -There's now support for creating buckets this way in -my fork, <https://github.com/joeyh/aws> - -I have not been able to test it, since I don't have the necessary account, -and don't want to give google my bank account/CC number on top of all the -other info they have gathered, which seems to be needed to sign up for one. - -If you check out my fork, `cabal confgure -fExamples; cabal build` -will create a test program in -`dist/build/PutBucketNearLine/PutBucketNearLine` ; it expects the usual -env vars for S3 creds, and you need to pass it the name of the bucket to -create. - -If that works, and creates a usable nearline bucket, we can probably get it -merged into mainline aws and then get support in git-annex. -"""]] diff --git a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_5_ab6cf3c57d9f93c24c19df81582f38d5._comment b/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_5_ab6cf3c57d9f93c24c19df81582f38d5._comment deleted file mode 100644 index 4e87d7a5f..000000000 --- a/doc/bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage/comment_5_ab6cf3c57d9f93c24c19df81582f38d5._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2015-11-02T14:55:54Z" - content=""" -aws-0.13.0 was released with the ncessary support. git-annex will now pass -the NEARLINE storage class when creating a bucket. - -Note that most builds of git-annex are not yet made with that version of -aws, but it will trickle out to the build systems with time. -"""]] diff --git a/doc/bugs/Unable_to_parallel_fsck.mdwn b/doc/bugs/Unable_to_parallel_fsck.mdwn deleted file mode 100644 index 487552f54..000000000 --- a/doc/bugs/Unable_to_parallel_fsck.mdwn +++ /dev/null @@ -1,88 +0,0 @@ -### Please describe the problem. - -If I run git annex fsck with the parallel jobs switch (e.g. -J2) it fails when it encounters files with non-ASCII filenames. It works fine without -this switch. - - -### What steps will reproduce the problem? - -Make a git annex repository with non-ascii filenames, add the files, and then run fsck with the parallel switch. A script to do this -is included below. - - -### What version of git-annex are you using? On what operating system? - -Arch Linux (64bit) - -git-annex version: 6.20160114-g297a744 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 - -### Please provide any additional information below. - -[[!format sh """ -#!/bin/bash -set -o errexit -o nounset - -mkdir testing-repo -cd testing-repo -git init -git annex init testing-repo - -make_fake_file() { - local filename="$1" - mkdir -p "$(dirname "$filename")" - echo "hello world" > "$filename" - git annex add "$filename" -} - -export -f make_fake_file -parallel -j1 'make_fake_file {}' <<EOF -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/folder.jpg -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/01 - 遥か彼方 - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/02 - 未来の破片 - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/03 - アンダースタンド - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/04 - 君という花 - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/05 - リライト - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/06 - 君の街まで - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/07 - ループ & ループ - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/08 - ブラックアウト - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/09 - ブルートレイン - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/10 - 或る街の群青 - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/11 - アフターダーク - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/12 - 転がる岩、君に朝が降る - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/13 - ムスタング - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/14 - 藤沢ルーザー - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/15 - 新世紀のラブソング - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/16 - ソラニン - ASIAN KUNG-FU GENERATION.flac -ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/17 - マーチングバンド - ASIAN KUNG-FU GENERATION.flac -EOF - -git commit -m 'Add testing files.' -git annex fsck -J2 -"""]] - -On my system this produces: - -[[!format sh """ -fsck ASIAN KUNG-FU GENERATION/2012 - BEST HIT AKG/flac/01 - git-annex: <stdout>: commitAndReleaseBuffer: invalid argument (invalid character) -FAIL 1 -"""]] - -(The FAIL 1 output is just my terminal printing that the exit code was 1) - -### 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) - -Plenty. In fact I've been using it for a long time - I just only recently tried to use -J2 to speed up the fsck'ing :) - - -[[!meta title="-J can crash on displaying filenames not supported by current locale"]] - -> I've worked around this by detecting the non-unicode locale and avoiding -> the fancy concurrent output which needs it. So -J will work, just not -> with concurrent progress. I think this is the best that can be done -> reasonably, so [[done]]. --[[Joey]] diff --git a/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment b/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment deleted file mode 100644 index 104d6b3c4..000000000 --- a/doc/bugs/Unable_to_parallel_fsck/comment_1_ce99be8d0ff0851840c77820ed1c0cbf._comment +++ /dev/null @@ -1,39 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-26T16:21:56Z" - content=""" -I can reproduce this with LANG=C. - -The cause seems to be that concurrent-output uses Text internally, and -Strings encoded using the filesystem encoding fail to round-trip through -Text. - -I tried changing concurrent-output from using `T.hPutStr stdout t` to -`hPutStr stdout (T.unpack t)` but that doesn't help; by the time the String -comes back out it's lost the filesystem encoding and so contains invalid -characters. - -Seems that the only way to fix this would be to change concurrent-output -not to use Text. However, it can't use ByteString because it needs to -operate on individual unicode characters when updating a region. -Which leaves only String, which I fear would slow -concurrent-output down quite significantly. - -(It might be possible to use ByteString for most of it, and fall back to -String only when calculating the display update and so avoid most of the -permformance impact. I have an incomplete conversion headed in that -direction in the use-bytestring branch in concurrent-output git repo. After -spending 2 hours on it, it's nowhere near done.) - -Since git-annex remains usable without -J, and since this only affects -systems that don't have a unicode locale configured and yet are using -unicode filenames (or systems that do use a unicode locale and have -filenames that are not valid utf-8), I'm kind of inclined not to massively -rework and likely slow down concurrent-output just to handle this case. -But I don't like it. - -Workaround: Compile git-annex with -f-ConcurrentOutput and the problem -will be avoided, although then you won't get progress displays when doing a -`git-annex get -Jn` -"""]] diff --git a/doc/bugs/Unable_to_parallel_fsck/comment_2_0735b87747e1f56f381ed0a1b25bdffa._comment b/doc/bugs/Unable_to_parallel_fsck/comment_2_0735b87747e1f56f381ed0a1b25bdffa._comment deleted file mode 100644 index 3961c9208..000000000 --- a/doc/bugs/Unable_to_parallel_fsck/comment_2_0735b87747e1f56f381ed0a1b25bdffa._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-01-29T17:05:34Z" - content=""" -I finished the use-bytestring branch, but that turns out not to work; once -the FilePath is converted to a ByteString, all the specially encoded -characters don't get decoded back properly, and so the result is a bunch of -�����. - -I think that for this to work, System.Console.Regions would need to use -String exclusively, and probably System.Console.Concurrent would too. Which -would probably slow it down and complicate it significantly. -"""]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn deleted file mode 100644 index 51894cac6..000000000 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -### Please describe the problem. - -There exist more BSD systems than FreeBSD. Thus I propose diff for Utility/libdiskfree.c. - -Based on pkgsrc patching guidelines https://www.netbsd.org/docs/pkgsrc/components.html#components.patches.guidelines -I tried to cook a diff even I'm not C developer. - - -### What steps will reproduce the problem? - -Add support for more OS for disk free check. - -### What version of git-annex are you using? On what operating system? -git-annex-5.20150930 - - -### Please provide any additional information below. - -The diff probably needs check, improvement... - -[[!format sh """ ---- libdiskfree.c.orig Sun Oct 4 15:18:07 2015 -+++ libdiskfree.c Sun Oct 4 15:23:23 2015 -@@ -7,35 +7,30 @@ - - /* Include appropriate headers for the OS, and define what will be used to - * check the free space. */ --#if defined(__APPLE__) --# define _DARWIN_FEATURE_64_BIT_INODE 1 --# include <sys/param.h> --# include <sys/mount.h> --# define STATCALL statfs --# define STATSTRUCT statfs64 --#else --#if defined (__FreeBSD__) --# include <sys/param.h> --# include <sys/mount.h> --# define STATCALL statfs /* statfs64 not yet tested on a real FreeBSD machine */ --# define STATSTRUCT statfs --#else --#if defined __ANDROID__ --# warning free space checking code not available for Android --# define UNKNOWN --#else - #if defined (__linux__) || defined (__FreeBSD_kernel__) - /* Linux or Debian kFreeBSD */ - /* This is a POSIX standard, so might also work elsewhere too. */ - # include <sys/statvfs.h> - # define STATCALL statvfs - # define STATSTRUCT statvfs --#else --# warning free space checking code not available for this OS -+#endif -+ -+#if defined __ANDROID__ -+# warning free space checking code not available for Android - # define UNKNOWN - #endif -+ -+#if defined (HAVE_SYS_PARAM_H) && defined (HAVE_SYS_MOUNT_H) -+#if defined(__APPLE__) -+# define _DARWIN_FEATURE_64_BIT_INODE 1 - #endif --#endif -+# include <sys/param.h> -+# include <sys/mount.h> -+# define STATCALL statfs /* statfs64 not yet tested on a real FreeBSD machine */ -+# define STATSTRUCT statfs64 -+#else -+# warning free space checking code not available for this OS -+# define UNKNOWN - #endif - - #include <errno.h> - -"""]] - -### 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) - -Not tested this "feature" yet, I got another issue which blocks me for now. - -> Well, this code has been removing from git-annex, and it's now using -> <http://hackage.haskell.org/package/disk-free-space>. I think that -> library is somewhat more portable. [[done]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_1_cdbf63d15795946f55aaea3da4755a22._comment b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_1_cdbf63d15795946f55aaea3da4755a22._comment deleted file mode 100644 index 2b3113561..000000000 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_1_cdbf63d15795946f55aaea3da4755a22._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jirib@503223f0610c6c66f4e6dc738a5a0b2648c290b1" - nickname="jirib" - subject="no statfs64 on OpenBSD" - date="2015-10-04T13:47:30Z" - content=""" -there's no statfs64 on OpenBSD, maybe following similar diff from conky fs part could help: - -http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/conky/patches/patch-src_fs_c?rev=1.3&content-type=text/x-cvsweb-markup -"""]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_2_54bfedf6d33bcd9d44cc3c89f3216161._comment b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_2_54bfedf6d33bcd9d44cc3c89f3216161._comment deleted file mode 100644 index b86fa0535..000000000 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_2_54bfedf6d33bcd9d44cc3c89f3216161._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-10-04T19:13:59Z" - content=""" -Happy to support all BSD varients that tested patches can be made for. - -I can't apply this patch as-is for several reasons: - -* You say you've not tested it yet. -* I recently modified the file to add support for Solaris, and your patch conflicts with that modification. -* Your patch in passing changes the FreeBSD support to use the - statfs64 structure. AFAIK that has not been tested. -* I think you also broke Android by moving it below the Linux tests. - The linux tests will probably fire on android, but the linux code - doesn't work with the android libc. - -Your patch would be better if it clearly added support for an OS -(or standard) without touching and breaking existing code that -supports other OSes. - -Thanks! -"""]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_3_9d3c44004a738987a9c374f431c0117a._comment b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_3_9d3c44004a738987a9c374f431c0117a._comment deleted file mode 100644 index e292375ab..000000000 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_3_9d3c44004a738987a9c374f431c0117a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jirib@503223f0610c6c66f4e6dc738a5a0b2648c290b1" - nickname="jirib" - subject="statfs64" - date="2015-10-05T09:58:10Z" - content=""" -Sorry, my mistake, I was checking latest release and it had statfs64 there but I see master doesn't have it. - -I'll report if it works on OpenBSD when I will pass 'xmpp' issue :) -"""]] diff --git a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_4_89fb96bbb595984e25ad434981bea7b4._comment b/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_4_89fb96bbb595984e25ad434981bea7b4._comment deleted file mode 100644 index afbfd7b64..000000000 --- a/doc/bugs/Utility__47__libdiskfree.c_more_BSD_friendly/comment_4_89fb96bbb595984e25ad434981bea7b4._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-10-06T19:22:33Z" - content=""" -It's good to not let issue A get blocked by unrelated issue B, and in this -case, easy to disentangle them! - -cabal configure -f-XMPP -"""]] diff --git a/doc/bugs/Volume_monitor_in_GNOME_3.18.mdwn b/doc/bugs/Volume_monitor_in_GNOME_3.18.mdwn deleted file mode 100644 index 4013f1b40..000000000 --- a/doc/bugs/Volume_monitor_in_GNOME_3.18.mdwn +++ /dev/null @@ -1,182 +0,0 @@ -### Please describe the problem. - -The assistant prints _"No known volume monitor available through dbus; falling back to mtab polling"_ on startup. Based on source code, it expects to find `org.gtk.Private.UDisks2VolumeMonitor` on the session bus. - -However, gvfs 1.26 (on GNOME 3.18) has renamed the service to `org.gtk.vfs.UDisks2VolumeMonitor` instead, and git-annex doesn't know about that yet. - -### What steps will reproduce the problem? - -Start the assistant on GNOME 3.18. - -### What version of git-annex are you using? On what operating system? - -Arch Linux: -git-annex 6.20160114-8 -gvfs 1.26.2-1 - -### Please provide any additional information below. - -The signals seem to have the same format: - -[[!format text """ -signal time=1453449272.593009 sender=:1.25 -> destination=(null destination) serial=2270 path=/org/gtk/Private/RemoteVolumeMonitor; interface=org.gtk.Private.RemoteVolumeMonitor; member=MountAdded - string "org.gtk.vfs.UDisks2VolumeMonitor" - string "0x1981b90" - struct { - string "0x1981b90" - string "A0D8-7268" - string ". GThemedIcon drive-harddisk-usb drive-harddisk drive" - string ". GThemedIcon drive-harddisk-usb-symbolic drive-harddisk-symbolic drive-symbolic drive-harddisk-usb drive-harddisk drive" - string "" - string "file:///run/media/grawity/A0D8-7268" - boolean true - string "0x7f396402a400" - array [ - ] - string "gvfs.time_detected_usec.1453449272586665" - array [ - ] - } -"""]] - -The DBus interface looks like this: - -[[!format text """ -$ gdbus introspect -e -d org.gtk.vfs.UDisks2VolumeMonitor -o / -r -node /org/gtk/Private/RemoteVolumeMonitor { - interface org.freedesktop.DBus.Properties { - methods: - Get(in s interface_name, - in s property_name, - out v value); - GetAll(in s interface_name, - out a{sv} properties); - Set(in s interface_name, - in s property_name, - in v value); - signals: - PropertiesChanged(s interface_name, - a{sv} changed_properties, - as invalidated_properties); - properties: - }; - interface org.freedesktop.DBus.Introspectable { - methods: - Introspect(out s xml_data); - signals: - properties: - }; - interface org.freedesktop.DBus.Peer { - methods: - Ping(); - GetMachineId(out s machine_uuid); - signals: - properties: - }; - interface org.gtk.Private.RemoteVolumeMonitor { - methods: - IsSupported(out b is_supported); - List(out a(ssssbbbbbbbbuasa{ss}sa{sv}) drives, - out a(ssssssbbssa{ss}sa{sv}) volumes, - out a(ssssssbsassa{sv}) mounts); - CancelOperation(in s cancellation_id, - out b was_cancelled); - MountUnmount(in s id, - in s cancellation_id, - in u unmount_flags, - in s mount_op_id); - VolumeMount(in s id, - in s cancellation_id, - in u mount_flags, - in s mount_op_id); - DriveEject(in s id, - in s cancellation_id, - in u unmount_flags, - in s mount_op_id); - DrivePollForMedia(in s id, - in s cancellation_id); - DriveStart(in s id, - in s cancellation_id, - in u flags, - in s mount_op_id); - DriveStop(in s id, - in s cancellation_id, - in u unmount_flags, - in s mount_op_id); - MountOpReply(in s mount_op_id, - in i result, - in s user_name, - in s domain, - in s encoded_password, - in i password_save, - in i choice, - in b anonymous); - signals: - DriveChanged(s dbus_name, - s id, - (ssssbbbbbbbbuasa{ss}sa{sv}) drive); - DriveConnected(s dbus_name, - s id, - (ssssbbbbbbbbuasa{ss}sa{sv}) drive); - DriveDisconnected(s dbus_name, - s id, - (ssssbbbbbbbbuasa{ss}sa{sv}) drive); - DriveEjectButton(s dbus_name, - s id, - (ssssbbbbbbbbuasa{ss}sa{sv}) drive); - DriveStopButton(s dbus_name, - s id, - (ssssbbbbbbbbuasa{ss}sa{sv}) drive); - VolumeChanged(s dbus_name, - s id, - (ssssssbbssa{ss}sa{sv}) volume); - VolumeAdded(s dbus_name, - s id, - (ssssssbbssa{ss}sa{sv}) volume); - VolumeRemoved(s dbus_name, - s id, - (ssssssbbssa{ss}sa{sv}) volume); - MountChanged(s dbus_name, - s id, - (ssssssbsassa{sv}) mount); - MountAdded(s dbus_name, - s id, - (ssssssbsassa{sv}) mount); - MountPreUnmount(s dbus_name, - s id, - (ssssssbsassa{sv}) mount); - MountRemoved(s dbus_name, - s id, - (ssssssbsassa{sv}) mount); - MountOpAskPassword(s dbus_name, - s id, - s message_to_show, - s default_user, - s default_domain, - u flags); - MountOpAskQuestion(s dbus_name, - s id, - s message_to_show, - as choices); - MountOpShowProcesses(s dbus_name, - s id, - s message_to_show, - ai pid, - as choices); - MountOpShowUnmountProgress(s dbus_name, - s id, - s message_to_show, - x time_left, - x bytes_left); - MountOpAborted(s dbus_name, - s id); - properties: - }; -}; -"""]] - -### 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) - -Works fine in general. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_1_e4ac26a8683a45872946eef2b54c85da._comment b/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_1_e4ac26a8683a45872946eef2b54c85da._comment deleted file mode 100644 index 22949635d..000000000 --- a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_1_e4ac26a8683a45872946eef2b54c85da._comment +++ /dev/null @@ -1,36 +0,0 @@ -[[!comment format=mdwn - username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f" - nickname="grawity" - subject="gvfs reliability" - date="2016-01-22T08:02:12Z" - content=""" -As a side note: gvfs volume monitor doesn't emit `MountAdded` for _all_ mounts – as far as I can see, it only does so for mountpoints that are meant to be _visible in the GUI_. So there's no `MountAdded` signal if I manually mount something on `/mnt`. - -Using UDisks2 directly may be more reliable (and does not require the desktop session). It is available on the system bus as `org.freedesktop.UDisks2`: - -[[!format text \"\"\" -signal time=1453449434.447244 sender=:1.8475 -> destination=(null destination) serial=1846 path=/org/freedesktop/UDisks2/block_devices/sdb1; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged - string \"org.freedesktop.UDisks2.Filesystem\" - array [ - dict entry( - string \"MountPoints\" - variant array [ - array of bytes \"/mnt\" + \0 - ] - ) - ] - array [ - ] -signal time=1453449440.453104 sender=:1.8475 -> destination=(null destination) serial=1847 path=/org/freedesktop/UDisks2/block_devices/sdb1; interface=org.freedesktop.DBus.Properties; member=PropertiesChanged - string \"org.freedesktop.UDisks2.Filesystem\" - array [ - dict entry( - string \"MountPoints\" - variant array [ - ] - ) - ] - array [ - ] -\"\"\"] -"""]] diff --git a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_2_1421ad9e2533a00ebfc76df8f0a92a6a._comment b/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_2_1421ad9e2533a00ebfc76df8f0a92a6a._comment deleted file mode 100644 index b860d4204..000000000 --- a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_2_1421ad9e2533a00ebfc76df8f0a92a6a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="grawity@2ea26be48562f66fcb9b66307da72b1e2e37453f" - nickname="grawity" - subject="comment 2" - date="2016-01-22T08:11:18Z" - content=""" -Seems like I failed at comment formatting. But another addition: UDisks2 might also be a good idea because it's already used by _both_ Gvfs (GNOME/Xfce) and KDE _and_ Enlightenment 17+ and Deepin, which might be an improvement over the current \"gvfs vs unreliable kde stuff\" code split. -"""]] diff --git a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_3_ba8748cb3113fb73dcb74bf92d7a3df5._comment b/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_3_ba8748cb3113fb73dcb74bf92d7a3df5._comment deleted file mode 100644 index 2ac4d3e60..000000000 --- a/doc/bugs/Volume_monitor_in_GNOME_3.18/comment_3_ba8748cb3113fb73dcb74bf92d7a3df5._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-01-22T20:10:01Z" - content=""" -Thanks for the info. - -I think I was having difficulty matching on the udisks2 signals before, due -to how they're structured, but I found a way now. -"""]] diff --git a/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline.mdwn b/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline.mdwn deleted file mode 100644 index d8c5ee083..000000000 --- a/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline.mdwn +++ /dev/null @@ -1,217 +0,0 @@ -### Please describe the problem. - -When following the walkthough, I'm unable to sync or copy files to/from special remote. - -### What steps will reproduce the problem? - -Follow the walkthrough: - - - Create an annex - - add a special remote (dir, rsync, etc.) - - create a file - - try to sync - - try to copy the file - - -```bash -cd && pwd # /home/vagrant -mkdir -p tmp && cd tmp -rm -rf source && rm -rf dir -git init source -# Dir for special directory remote -mkdir dir -cd source -git annex init "the source of it all" -git annex initremote dir type=directory directory=/home/vagrant/tmp/dir encryption=none -# A file to test with -echo "Whatever the heck I want" > file -# -# Testing copy -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir -# -# Maybe adding the file to git will help? -# -git add . -git commit -m "A file" -# -# Testing copy again -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir -# -# Enable it doesn't help either -# -git annex enableremote dir directory=/home/vagrant/tmp/dir -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir -``` - - -### What version of git-annex are you using? On what operating system? - - ->$ git annex version - ->git-annex version: 6.20160923-gd1dabb3 ->build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify MPP ConcurrentOutput TorrentParser MagicMime Feeds >Quvi ->key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 HA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 >SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL ->remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external ->local repository version: 5 ->supported repository versions: 5 6 ->upgrade supported from repository versions: 0 1 2 3 4 5 ->operating system: linux x86_64 - -On a vagrant box `vagrant init "ubuntu/trusty64"`. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -## Script -set -euo pipefail -IFS=$'\n\t' -set -v # verbose - command echoing - -cd && pwd # /home/vagrant -mkdir -p tmp && cd tmp -sudo rm -rf source && sudo rm -rf dir -git init source -# Dir for special directory remote -mkdir dir -cd source -git annex init "the source of it all" -git annex initremote dir type=directory directory=/home/vagrant/tmp/dir encryption=none -# A file to test with -echo "Whatever the heck I want" > file -# -# Testing copy -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir -# -# Maybe adding the file to git will help? -# -git add . -git commit -m "A file" -# -# Testing copy again -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir -# -# Enable it doesn't help either -# -git annex enableremote dir directory=/home/vagrant/tmp/dir -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -# Testing sync -git annex sync # No sync -ls -l /home/vagrant/tmp/dir # Empty dir - -###################### -# Start of transcript or log. -cd && pwd # /home/vagrant -/home/vagrant -mkdir -p tmp && cd tmp -sudo rm -rf source && sudo rm -rf dir -git init source -Initialized empty Git repository in /home/vagrant/tmp/source/.git/ -# Dir for special directory remote -mkdir dir -cd source -git annex init "the source of it all" -init the source of it all ok -(recording state in git...) -git annex initremote dir type=directory directory=/home/vagrant/tmp/dir encryption=none -initremote dir ok -(recording state in git...) -# A file to test with -echo "Whatever the heck I want" > file -# -# Testing copy -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 -# Testing sync -git annex sync # No sync -commit -On branch master - -Initial commit - -Untracked files: - file - -nothing added to commit but untracked files present -ok -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 -# -# Maybe adding the file to git will help? -# -git add . -git commit -m "A file" -[master (root-commit) 10c3ad1] A file - 1 file changed, 1 insertion(+) - create mode 100644 file -# -# Testing copy again -# -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 -# Testing sync -git annex sync # No sync -commit -On branch master -nothing to commit, working directory clean -ok -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 -# -# Enable it doesn't help either -# -git annex enableremote dir directory=/home/vagrant/tmp/dir -enableremote dir ok -(recording state in git...) -git annex copy file --to dir # Empty output -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 -# Testing sync -git annex sync # No sync -commit -On branch master -nothing to commit, working directory clean -ok -ls -l /home/vagrant/tmp/dir # Empty dir -total 0 - -# End of transcript or log. -##################### -"""]] - -### 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) - -Hey, the git-assistant works well :) I'm doing this as an exercise to get prepared for provisioning raspis running git-annex ;) - -> closing per comment [[done]] --[[Joey]] diff --git a/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment b/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment deleted file mode 100644 index 6b10f34f5..000000000 --- a/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~helpunclejackoff" - nickname="helpunclejackoff" - avatar="http://cdn.libravatar.org/avatar/5a03d3e717ff477309d5b5f5726fcd3b51bb5c6b2241e796f93bd4f340426d04" - subject="Dumb old me...." - date="2016-10-15T10:12:17Z" - content=""" -In my script I was using `git add` instead of `git annex add`... - -All is good now. - -Cheers! -"""]] diff --git a/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists.mdwn b/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists.mdwn deleted file mode 100644 index 857ca333a..000000000 --- a/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -### Please describe the problem. - -"git-annex enableremote box.com" fails with "git-annex: WebDAV test failed". The server returns error message "The resource you tried to create already exists" (see below). - -### What steps will reproduce the problem? - -1. I initialize box.com special remote in desktop. The path at box.com is at "gas/annex". - -2. I enable the box.com special remote in laptop. I got the error I described above. - -### What version of git-annex are you using? On what operating system? - - $ git annex version - git-annex version: 5.20140831-g62e6ad8 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL - remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - $ uname -a - Linux tkf-acer 3.12.9-2-ARCH #1 SMP PREEMPT Fri Jan 31 10:22:54 CET 2014 x86_64 GNU/Linux - - -### Please provide any additional information below. - -I ran the following while with appropriate environment variable WEBDAV_USERNAM and WEBDAV_PASSWORD. - - me@desktop$ git-annex initremote box type=webdav url=https://dav.box.com/dav/gas/annex chunk=50mb encryption=shared - - me@laptop$ git-annex enableremote box.com - enableremote box.com (testing WebDAV server...) - - git-annex: WebDAV test failed: StatusCodeException (Status {statusCode = 405, statusMessage = "Method Not Allowed"}) [("Server","nginx"),("Date","Sat, 27 Sep 2014 09:36:42 GMT"),("Content-Type","application/xml; charset=utf-8"),("Content-Length","247"),("Connection","keep-alive"),("Vary","Host"),("Allow","OPTIONS, GET, HEAD, DELETE, PROPFIND, PUT, PROPPATCH, COPY, MOVE, REPORT, LOCK, UNLOCK"),("X-Response-Body-Start","<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<d:error xmlns:d=\"DAV:\" xmlns:s=\"http://sabredav.org/ns\">\n <s:exception>Sabre_DAV_Exception_MethodNotAllowed</s:exception>\n <s:message>The resource you tried to create already exists</s:message>\n</d:error>\n")] (CJ {expose = []}): user error - failed - git-annex: enableremote: 1 failed - -> You are using an old version of git-annex; this bug was fixed in -> version 5.20140919. [[done]] --[[Joey]] diff --git a/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment b/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment deleted file mode 100644 index 89ab74c69..000000000 --- a/doc/bugs/WebDAV_error_when_connecting_to_box.com__58___The_resource_you_tried_to_create_already_exists/comment_1_ac40ddc26bff27dafdbc457837695a92._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawk0GR7KgDF6PAzHTkLZCCkjAvJVB7ceXTY" - nickname="Takafumi" - subject="comment 1" - date="2014-09-27T19:46:08Z" - content=""" -I updated git-annex and it works. Thank you very much. -"""]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn deleted file mode 100644 index 17fe3ac25..000000000 --- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### Please describe the problem. -Recently I've noticed that the webapp is missing CSS styles. Upon inspection it seems that the CSS and JS resources fail to load with "401 Unauthorized" responses. If I copy the "?auth=" parameter from the main URL then I can access any of them, but I guess the session cookie isn't working. - -### What steps will reproduce the problem? -1. Start the assistant with "git annex assistant start" or "git annex assistant" or "git annex assistant --autostart" -2. Open the webapp with "git annex webapp" or by opening $ANNEX_DIR/.git/annex/webapp.html -3. The web app is missing all style and javascript resources - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20161031 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: darwin x86_64 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[2016-11-10 10:35:20.214701] main: starting assistant version 6.20161031 - - -# End of transcript or log. -"""]] - -### 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) - -> [[done]], my fix worked! Don't know entirely why it was needed.. -> --[[Joey]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_1_9e21f2fe1ba4bc1c246422e158657c30._comment b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_1_9e21f2fe1ba4bc1c246422e158657c30._comment deleted file mode 100644 index 63ad5ae60..000000000 --- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_1_9e21f2fe1ba4bc1c246422e158657c30._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="christopher@5845ecd3cef9edadd4dc084df00e1fa60ce311eb" - nickname="christopher" - avatar="http://cdn.libravatar.org/avatar/4b722efb21f38d9944730c93727bc602" - subject="comment 1" - date="2016-11-10T09:50:40Z" - content=""" -Meant to answer the last question: - -I've used git annex, including the assistant and webapp, with great success for about a year and find it to be really excellent! -"""]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_2_20e774c16d6978e0a1137a1e406da244._comment b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_2_20e774c16d6978e0a1137a1e406da244._comment deleted file mode 100644 index eb630f364..000000000 --- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_2_20e774c16d6978e0a1137a1e406da244._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-11-10T17:30:57Z" - content=""" -I don't reproduce the problem here. From where did you install git-annex? - -This seems likely to have something to do with the version of yesod it was -built against. - -No session cookie is used; the auth token is not supposed to be needed when -accessing urls under `/static/`. Looking at the code, this was not done -explicitly; it seems to have relied on yesod not checking for authorization -for static site parts. I've committed a change, to explicitly skip auth for -`/static/` but without being able to reproduce the problem, can't test it. -"""]] diff --git a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment b/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment deleted file mode 100644 index cb6e9b4d2..000000000 --- a/doc/bugs/Webapp_missing_CSS_and_JS_resources___40__401_Unauthorized__41__/comment_3_54bd11140dbe794182263c1a062ad031._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="christopher@5845ecd3cef9edadd4dc084df00e1fa60ce311eb" - nickname="christopher" - avatar="http://cdn.libravatar.org/avatar/4b722efb21f38d9944730c93727bc602" - subject="comment 3" - date="2016-11-15T12:15:37Z" - content=""" -Hi Joey, - -I installed git-annex using the homebrew recipe from https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-annex.rb, OS X 10.11.6 (15G31) - -These are the dependencies reported by homebrew: - -Build: ghc ✔, cabal-install ✔, pkg-config ✔ -Required: gsasl ✔, libidn ✔, libmagic ✔, gnutls ✔, quvi ✔ - -I've re-installed using \"brew install git-annex --HEAD\" to pull in your latest commit and I can confirm that everything works as expected and the /static/ resources load correctly. - -Thanks, -Chris -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn b/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn deleted file mode 100644 index 249576b1d..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times.mdwn +++ /dev/null @@ -1,97 +0,0 @@ -### Please describe the problem. -`git annex whereis` reports the same UUID multiple times, for example for one file: - -``` -whereis file1 (20 copies) - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0dc538bf-5015-474a-965b-f59a678c2606 - 0dc538bf-5015-474a-965b-f59a678c2606 - 0dc538bf-5015-474a-965b-f59a678c2606 - 0dc538bf-5015-474a-965b-f59a678c2606 - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a -ok -``` - -For another file: - -``` -whereis file2 (44 copies) - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0866153a-19e5-4382-aeb6-30e8210706cc - 0dc538bf-5015-474a-965b-f59a678c2606 - 0dc538bf-5015-474a-965b-f59a678c2606 - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 42c9b8ae-7fe5-452c-8965-146077b567fc - 57c272a3-4146-4796-8c4d-349725e11153 - 57c272a3-4146-4796-8c4d-349725e11153 - 57c272a3-4146-4796-8c4d-349725e11153 - 57c272a3-4146-4796-8c4d-349725e11153 - 6edd8523-6321-4d60-ada1-364489093075 - 6edd8523-6321-4d60-ada1-364489093075 - 6edd8523-6321-4d60-ada1-364489093075 - 6edd8523-6321-4d60-ada1-364489093075 - 8ca47082-542f-4935-bd4d-71b3d8071f97 - 8ca47082-542f-4935-bd4d-71b3d8071f97 - 8ca47082-542f-4935-bd4d-71b3d8071f97 - 8ca47082-542f-4935-bd4d-71b3d8071f97 - 99c9cb4b-3d7d-406b-b68d-c30b62072d25 - 99c9cb4b-3d7d-406b-b68d-c30b62072d25 - 99c9cb4b-3d7d-406b-b68d-c30b62072d25 - 99c9cb4b-3d7d-406b-b68d-c30b62072d25 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 99f82d90-85a1-498e-a149-b5d21a0c4540 - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a -- repo1 - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9b4679b3-95dd-4e20-8349-7a9ed4d9ff6a - 9e5cb42d-7a5a-4a99-b176-f0980d9b7265 - 9e5cb42d-7a5a-4a99-b176-f0980d9b7265 - 9e5cb42d-7a5a-4a99-b176-f0980d9b7265 - 9e5cb42d-7a5a-4a99-b176-f0980d9b7265 - b1e180f9-3a47-4178-a360-043e731a4f5b -- local_repo [here] - b5472406-01a1-4cd8-a5b4-bb3d914264d2 - b5472406-01a1-4cd8-a5b4-bb3d914264d2 - b5472406-01a1-4cd8-a5b4-bb3d914264d2 - b5472406-01a1-4cd8-a5b4-bb3d914264d2 -ok -``` - -Furthermore as can be seen it doesn't even recognise that I have added repo1 as a remote for file1, actually several other of the repositories are available as remotes but git annex doesn't recognise them. - -I have tried deleting the repository and cloning it again on windows, but that just seemed to create even more UUID repeats. So right now I am a bit vary of trying anything out on Windows on the repository. - -I have tried running `git annex repair` on Linux and it reported no problems, even though it also shows repeated UUIDs if I run `git annex whereis`. - -### What version of git-annex are you using? On what operating system? - -I am running "git-annex version: 6.20160511-g4633f0b" on Windows, but I have been having troubles with this for some time, though only on Windows. - -### Please provide any additional information below. - -### 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 is working very nicely on all my linux computers, and right now I am mostly concerned that I might have messed up the repository by trying out Windows :-(. - -> [[fixed|done]]; repositories in this state are now handled appropriately -> by git-annex. And, I've fixed at least the places I was able to identify -> where '\r' slipped in. --[[Joey]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment deleted file mode 100644 index 61133235b..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_1_4af19e393212aa5cd5b64c3bb81e8268._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-17T17:51:11Z" - content=""" -This is quite odd. Normally, multiple instances of the same UUID can occur -but will get compacted down to 1. - -That it only lists the remote name/description for one instance of the UUID -is probably a clue to whatever the problem is. - -Can you paste the output of this command: `git show git-annex:uuid.log` - -(It would be very helpful if I could get access to a clone of the git-annex -branch of your repository.) -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment deleted file mode 100644 index 2c9b91791..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_2_148e8a83da7f9208ab7e0619b70b7093._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-05-27T14:26:18Z" - content=""" -Received a clone of this repository (in git-annex-test-repos/annex.bundle -here), and was able to reproduce the bug. - -Looking at one duplicate UUID for one file, I see: - - 1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc - 1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc - 1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc - 1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc - 1444995510.830128s 1 0866153a-19e5-4382-aeb6-30e8210706cc - -The notable thing here is not that there are multiple lines for a UUID, but -that they somehow have the *exact* same timestamp down to the -microsecond. - -I'm a) unsure how this could happen and b) afraid that the log file -compaction fails in this case, with catastrophic results. - -Regarding how this could happen, git blame shows a single commit -adding duplicate lines with the same timestamp. Commit message was -"update". The commit touched a wide swath of the repository, including even -non-location-log files like trust.log, which also got duplicate lines with -the same timestamp. - -Some of the lines were entirely new, but some existing lines also -got duplicated. - -There were some duplicate lines before this commit, so it was not an -isolated incident. - -Clearly, log compaction needs to collapse down lines that are identical except -for timestamp. The location log code also needs to throw out all but one -current item for a given uuid, since other code treats each returned location -as a copy, expecting there to not be any duplicate UUIDs. With these changes, -whatever caused these duplicate lines to occur in the first place at least -won't result in weird output or data loss. I have not verified yet if data -loss can actually occur in this case. -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment deleted file mode 100644 index 7c4b48398..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_3_96eeccef3cf2678b30b892cb264bc7e1._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-27T14:47:40Z" - content=""" -I tried reproducing this artificially by duplicating a presence log line. -That didn't work; whereis showed only 1 copy, not multiple ones. -Which makes sense, because the log reader makes a map that has the UUID as -the key. So a single UUID can't appear more than once at that point. Good! - -So, there's something else going on in the problem repository that -allows this behavior to occur. - -Aha! It's sequences of one or more `\r` at the end of the line. - - fromList [("0866153a-19e5-4382-aeb6-30e8210706cc",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc"}),("0866153a-19e5-4382-aeb6-30e8210706cc\r",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc\r"}),("0866153a-19e5-4382-aeb6-30e8210706cc\r\r",LogLine {date = 1444995329.589s, status = InfoPresent, info = "0866153a-19e5-4382-aeb6-30e8210706cc\r\r"}) ... - -So, 0866153a-19e5-4382-aeb6-30e8210706cc seems to appear multiple times, but it's really due to these `\r`'s. - -Suspect this means that this problem only impacts display. It should not lead -to data loss, because no remote will have a UUID ending in `\r', so there -should be no way for git-annex to somehow count a remote twice as containing -a copy of a file when dropping. Indeed, we can see in the whereis output that -it only matches up some instances of the "duplicate" uuid with remotes -- because -the other instances have carriage returns appended. - -Also, this suggests that the reason the duplicate lines occurred in the first -place was something to do with a windows system, which presumably added some -`\r\n` that is being stumbled over. -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment deleted file mode 100644 index 92f711ed6..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_4_d26052bc19fbb6eaa84b2d72c280f11a._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-05-27T15:02:05Z" - content=""" -In git-annex version 5.20140606, we have: - - * Windows: Fix bug introduced in last release that caused files - in the git-annex branch to have lines teminated with \r. - -There was only 1 week where git-annex had that bug AFAIK, but of -course the broken version could have kept on being used for some time. - -It's also always possible that this same problem popped up again in the -code. The fix in 1ab3d7c81049e4ce7e8e47800e2ef1fecb3a9ab4 was to -Annex.Journal and that still seems ok. The merge code is another place -this could perhaps happen. -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_5_2355fd90d4ff8dd440bf11348a8daa73._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_5_2355fd90d4ff8dd440bf11348a8daa73._comment deleted file mode 100644 index 5ae6c2b1f..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_5_2355fd90d4ff8dd440bf11348a8daa73._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-05-27T15:40:16Z" - content=""" -I've developed a patch which yields a good whereis display in this repo. - -Still remains to be seen if there's some code path that currently causes -'\r' to get added in the current version of git-annex on Windows. -"""]] diff --git a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment b/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment deleted file mode 100644 index 30951378e..000000000 --- a/doc/bugs/Whereis_reports_same_UUID_multiple_times/comment_6_d3adcfad215b3f39cc5bc3ff248e4b86._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-27T19:03:05Z" - content=""" -Union merge on windows does indeed add \r onto lines. - -Looks like hashBlob is at fault; it writes a string to a temp file, -and the IO layer does CRLF conversion at that point. - -The git-annex branch transition code also uses hashBlob so would also -do it. - -So I've reproduced the root cause of this now. Fixing.. -"""]] diff --git a/doc/bugs/Windows__58___Annex_can_not_get_files.mdwn b/doc/bugs/Windows__58___Annex_can_not_get_files.mdwn deleted file mode 100644 index f23624032..000000000 --- a/doc/bugs/Windows__58___Annex_can_not_get_files.mdwn +++ /dev/null @@ -1,162 +0,0 @@ -### Please describe the problem. -git annex on windows does not seem to be able to get files from one (local) repository to another (also local) if the remote contains a drive letter (or generally a : in the path) - -### What steps will reproduce the problem? -0. c:\> git init annex1 -0. c:\> cd annex1 -0. c:\annex1\> git annex init dir1 -0. c:\annex1\> echo "This is a git annex repository" > README.txt -0. c:\annex1\> git annex add README.txt -0. c:\annex1\> git annex sync -0. c:\annex1\> cd \ -1. c:\> git init annex2 -1. c:\> cd annex2 -1. c:\annex2\> git annex init dir2 -1. c:\annex2\> git remote add dir1 c:\annex1 -1. c:\annex2\> git annex sync dir1 -2. c:\annex2\> git annex get README.txt - -### What version of git-annex are you using? On what operating system? -C:\annex2>git version -git version 1.9.4.msysgit.0 - -C:\annex2>git annex version -git-annex version: 5.20150113-gcf247cf -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feed -s Quvi TDFA CryptoHash TorrentParser -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SH -A256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glac -ier ddar hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 2 3 4 - - -### Please provide any additional information below. - -[[!format sh """ -C:\>git init annex1 -Initialized empty Git repository in C:/annex1/.git/ - -C:\>cd annex1 - -C:\annex1>git annex init dir1 -init dir1 - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -ok -(Recording state in git...) - -C:\annex1>echo "This is a git annex repository" > README.txt - -C:\annex1>git annex add README.txt -add README.txt ok -(Recording state in git...) - -C:\annex1>git annex sync -commit ok - -C:\annex1>cd \ - -C:\>git init annex2 -Initialized empty Git repository in C:/annex2/.git/ - -C:\>cd annex2 - -C:\annex2>git annex init dir2 -init dir2 - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -ok -(Recording state in git...) - -C:\annex2>git remote add dir1 c:\annex1 - -C:\annex2>git annex sync dir1 -commit ok -pull dir1 -warning: no common commits -remote: Counting objects: 13, done. -remote: Compressing objects: 100% (9/9), done. -remote: Total 13 (delta 1), reused 0 (delta 0) -Unpacking objects: 100% (13/13), done. -From c:\annex1 - * [new branch] annex/direct/master -> dir1/annex/direct/master - * [new branch] git-annex -> dir1/git-annex - * [new branch] master -> dir1/master - * [new branch] synced/master -> dir1/synced/master - -Merge made by the 'recursive' strategy. - README.txt | 1 + - 1 file changed, 1 insertion(+) - create mode 120000 README.txt - -Already up-to-date. -ok -(merging dir1/git-annex into git-annex...) -(Recording state in git...) -push dir1 -Counting objects: 15, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (10/10), done. -Writing objects: 100% (12/12), 1.18 KiB | 0 bytes/s, done. -Total 12 (delta 4), reused 0 (delta 0) -To c:\annex1 - a7d2b83..0e86493 annex/direct/master -> synced/master - * [new branch] git-annex -> synced/git-annex -ok - -C:\annex2>git annex get README.txt -get README.txt (not available) - Try making some of these repositories available: - f005c222-3e80-46a3-81a2-72c6cae18035 -- dir1 <<<---- WTF: It's c:\annex1 -failed -git-annex: get: 1 failed - -C:\annex2>git annex list -here -|dir1 -||web -|||bittorrent -|||| -____ README.txt <<<----- WTF2: Why doesn't annex2 know that annex1 has a copy? - -C:\annex2>git annex whereis README.txt -whereis README.txt (1 copy) - f005c222-3e80-46a3-81a2-72c6cae18035 -- dir1 -ok - -C:\annex2>cd \annex1 - -C:\annex1>git annex list -(merging synced/git-annex into git-annex...) -here -|web -||bittorrent -||| -X__ README.txt <<<--- But annex1 knows where it is. - -C:\annex1>git annex sync -commit ok -merge synced/master -Updating a7d2b83..0e86493 -Fast-forward -error: duplicate parent 0e86493f9431d6df13ef49831e00b22be93e509c ignored <<<---- Could this be the problem? -ok - -C:\annex1>cd \annex2 - -"""]] - -> [[fixed|done]]; a simple path calculation bug. --[[Joey]] diff --git a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_1_0d13792a92dc4cde6db73123eeb88218._comment b/doc/bugs/Windows__58___Annex_can_not_get_files/comment_1_0d13792a92dc4cde6db73123eeb88218._comment deleted file mode 100644 index baf8bed8e..000000000 --- a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_1_0d13792a92dc4cde6db73123eeb88218._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlc-3pdibcizrdz4WmZooECL0k6AvM1cWc" - nickname="Joe" - subject="direct-mode to direct-mode perhaps?" - date="2015-03-09T17:40:59Z" - content=""" -It seems like the problem is when using a direct-mode repository on both sides of the copy. - -I can get and copy files to and from the USB stick when I'm dealing with my Linux-based (indirect mode) repository. - -Could it be that git-annex isn't properly noticing that c:\annex is in direct mode, and so it should copy from c:\annex\readme.txt instead of c:\annex\.git\annex\objects\... ? -"""]] diff --git a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_2_66aff09094d593f1c95213b9f8cbf26e._comment b/doc/bugs/Windows__58___Annex_can_not_get_files/comment_2_66aff09094d593f1c95213b9f8cbf26e._comment deleted file mode 100644 index f16e09c0d..000000000 --- a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_2_66aff09094d593f1c95213b9f8cbf26e._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlc-3pdibcizrdz4WmZooECL0k6AvM1cWc" - nickname="Joe" - subject="Ah, but I can directly overwrite the file" - date="2015-03-09T17:46:58Z" - content=""" -If I copy f:\annex\bin\s3.exe into c:\annex\bin\s3.exe, (overwriting the .git symlink record) git annex sync will properly record that the file is now in this replica. - -So I guess I have a workaround(ish) - ---Joe -"""]] diff --git a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment b/doc/bugs/Windows__58___Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment deleted file mode 100644 index f5878a2ed..000000000 --- a/doc/bugs/Windows__58___Annex_can_not_get_files/comment_3_5039702d7676b4712bb2bf586a83e591._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-04-14T17:28:11Z" - content=""" -There is quite a lot of unrelated noise in this bug report. For example, -when you run "git annex init dir1", you're telling git-annex to refer to -that repository as "dir1". It should thus be unsuprising when it does in -whereis etc messages about that repository. - -This is a duplicate of -<http://git-annex.branchable.com/bugs/Windows:_repo_located_on_different_drive_letter_unavailable/> -"""]] diff --git a/doc/bugs/Windows__58___can__39__t_clone_repository.mdwn b/doc/bugs/Windows__58___can__39__t_clone_repository.mdwn deleted file mode 100644 index 6a99f8474..000000000 --- a/doc/bugs/Windows__58___can__39__t_clone_repository.mdwn +++ /dev/null @@ -1,56 +0,0 @@ -### Please describe the problem. - -Can't clone repository on Windows 7 64bit - -### What steps will reproduce the problem? -git clone git://git-annex.branchable.com/ gitannex - -... - -error: Invalid path 'doc/walkthrough/fsck:_verifying_your_data.mdwn' - -error: Invalid path 'doc/walkthrough/fsck:_when_things_go_wrong.mdwn' - -error: Invalid path 'doc/walkthrough/quiet_please:_When_git-annex_seems_to_skip_files.mdwn' - -error: Invalid path 'doc/walkthrough/removing_files:_When_things_go_wrong.mdwn' - -error: Invalid path 'doc/walkthrough/transferring_files:_When_things_go_wrong.mdwn' - -Checking out files: 100% (7235/7235), done. - -git status shows many deleted - -git reset --hard shows same error as clone - -### What version of git-annex are you using? On what operating system? -git annex version - -git-annex version: 5.20150219-g3fc8d83 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA TorrentParser -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM - URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: unknown -supported repository version: 5 -upgrade supported from repository versions: 2 3 4 - -git --version - -git version 1.9.5.msysgit.0 - -Windows 7 64bit - - -> Here's a nickle kid, go buy yourself a real OS that supports -> colon in filenames. -> -> Windows has all kinds of stupid limitations that are enough fun -> making git-annex support, without trying to make its source/website -> repo also avoid them. -> -> The solution is cygwin; git-annex's windows autobuilder uses cygwin's -> version of git to check out its git repository, and that should work for you. -> [[done]] -> -> --[[Joey]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh.mdwn b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh.mdwn deleted file mode 100644 index d269f09ae..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. - -On windows, fails getting files with the following error : "rsync: Failed to exec ssh: No such file or directory". The server runs gitolite. I've tested from a Linux client, and it works. - - $ git annex get big\ file - get big file (from origin...) rsync: Failed to exec ssh: No such file or directory (2) - rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(84) [Receiver=3.0.9] - rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] - rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(605) [Receiver=3.0.9] - - - rsync failed -- run git annex again to resume file transfer - - Unable to access these remotes: origin - - Try making some of these repositories available: - dc8840b6-c0ec-4166-adcc-f821f3ee0216 -- olivier@myhost:~/git/whatever/testing - f8ef7445-2ccc-4871-a95a-7e4325fc763d -- gitolite3@aserver:~/repositories/testing.git [origin] - failed - git-annex: get: 1 failed - - -### What steps will reproduce the problem? - -'git clone' from a repo containing a big file, then git annex init locally, then git get for the file contained in the repo - -### What version of git-annex are you using? On what operating system? - -* Git for windows, from http://git-scm.com/downloads (referenced from https://git-annex.branchable.com/install/Windows/), i.e. Git 2.5.0 -* Git annex gotten from https://downloads.kitenet.net/git-annex/windows/current/ as of 2015-08-19 08:43 (GitAnnexDistribution {distributionUrl = "https://downloads.kitenet.net/git-annex/windows/current/git-annex-installer.exe", distributionKey = Key {keyName = "76e06059fe0146d228578a1eef42d92f94f4d89b5b00798f317083f90a73e006.exe", keyBackendName = "SHA256E", keySize = Just 24420678, keyMtime = Nothing, keyChunkSize = Nothing, keyChunkNum = Nothing}, distributionVersion = "5.20150819", distributionReleasedate = 2015-08-24 21:24:56.240184 UTC, distributionUrgentUpgrade = Nothing}) - - -### 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 :-) Only on linux so far and trying on windows now :-/ - -> [[fixed|done]] in the daily build now. --[[Joey]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment deleted file mode 100644 index 59282f6e8..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_1_f8b55d954784346f2e97d1d3ec36bedb._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="OlivierBerger" - subject="Using --debug gives this" - date="2015-08-27T14:26:54Z" - content=""" -Here's a transcript of the --debug output (edited to mask file name and servername) - -[[!format sh \"\"\" -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ git annex get big\ file --debug -[2015-08-27 16:21:36.8295694] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"big file\"] -get big file [2015-08-27 16:21:36.8495982] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"git-annex\"] -[2015-08-27 16:21:36.8796414] process done ExitSuccess -[2015-08-27 16:21:36.8796414] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2015-08-27 16:21:36.8996702] process done ExitSuccess -[2015-08-27 16:21:36.8996702] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..f98a471b32f963a0bf816800d766690d53ef150d\",\"-n1\",\"--pretty=%H\"] -[2015-08-27 16:21:36.919699] process done ExitSuccess -[2015-08-27 16:21:36.9297134] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..15e7ab1f3b70629db852f8565bf988b25af02ec6\",\"-n1\",\"--pretty=%H\"] -[2015-08-27 16:21:36.9497422] process done ExitSuccess -[2015-08-27 16:21:36.9497422] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"log\",\"refs/heads/git-annex..1e04e80b99361e5b516d3a266bbc7b1d1478dff5\",\"-n1\",\"--pretty=%H\"] -[2015-08-27 16:21:36.9897998] process done ExitSuccess -[2015-08-27 16:21:36.9897998] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"core.bare=false\",\"cat-file\",\"--batch\"] -(from origin...) [2015-08-27 16:21:37.0098286] read: rsync [\"--progress\",\"--inplace\",\"-e\",\"'ssh' '-T' 'gitolite3@server' 'git-annex-shell ''sendkey'' ''/~/testing'' ''--debug'' ''SHA256E-s264620717--23e70aae588a049d52909cd68067cf2885429ae557f52e3f2d6033260c3ad9ea.mp4'' --uuid f8ef7445-2ccc-4871-a95a-7e4325fc763d ''--'' ''remoteuuid=8fb9f88a-1105-4278-aa85-7b5c78a0e0e5'' ''direct=1'' ''associatedfile=big file'' ''--'''\",\"--\",\"dummy:\",\".git/annex/tmp/SHA256E-s264620717--23e70aae588a049d52909cd68067cf2885429ae557f52e3f2d6033260c3ad9ea.mp4\"] -rsync: Failed to exec ssh: No such file or directory (2) -rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/pipe.c(84) [Receiver=3.0.9] -rsync: writefd_unbuffered failed to write 4 bytes to socket [Receiver]: Broken pipe (32) -rsync error: error in IPC code (code 14) at /home/lapo/package/rsync-3.0.9-1/src/rsync-3.0.9/io.c(1532) [Receiver=3.0.9] -[2015-08-27 16:21:37.0799294] process done ExitFailure 14 - - -# End of transcript or log. -\"\"\"]] -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment deleted file mode 100644 index 77d28f010..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_2_fddfc4c5a7428f924ec2ebbc7175a520._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="OlivierBerger" - subject="git 2.5 for windows seems the culprit whereas mysygit 1.9 works" - date="2015-08-27T15:02:14Z" - content=""" -I've removed Git for windows 2.5, and installed the latest msysgit 1.9, and it seems that this works much better. - -However, I have to invoke git-annex from the command-line through its full path with : - \"C:\Program Files\Git\cmd\git-annex.exe\" get . - -I guess this gives hope :-) -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_3_15bccb8c66a1a2fb5e13c10902e25866._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_3_15bccb8c66a1a2fb5e13c10902e25866._comment deleted file mode 100644 index 67ab59323..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_3_15bccb8c66a1a2fb5e13c10902e25866._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-09-10T16:51:10Z" - content=""" -Nice to see there's finally an up-to-date version of git for windows. - -However, it's not too surprising, since this is an entirely different build -from the msysgit that git-annex has been made to work with, that it doesn't -quite work with git-annex. This stuff is *extremely* fiddly on windows. - -Seems that the new git for windows ships ssh in Program Files/git/usr/bin. -Since that's not in PATH, rsync can't find it. I tried a few things, but -can't find a way yet that makes rsync find it. -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_4_3d946c88a14929ffcb6f79eae6921e6c._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_4_3d946c88a14929ffcb6f79eae6921e6c._comment deleted file mode 100644 index 7da961c3e..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_4_3d946c88a14929ffcb6f79eae6921e6c._comment +++ /dev/null @@ -1,34 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-09-10T18:10:52Z" - content=""" -Here's a request that rsync be added to git for windows. It seems like it -would be pretty easy for them to add. But I don't know if they will; -the bug is currently closed wontfix. -<https://github.com/git-for-windows/git/issues/347> - -I was finally able to get rsync working with git for windows and git-annex -as follows: - -* Delete the rsync.exe that git-annex-installer.exe installs in Git/cmd -* Install <https://msys2.github.io/> -* In the msys2 shell, "pacman sync rsync" -* Copy /msys32/usr/bin/rsync.exe to /Program Files/Git/usr/bin/ - -So, I could include that rsync.exe in the git-annex for windows. However, since -there are 2 versions of rsync.exe, one which works with git for windows, -and one that works with msysgit, I might not be able to get a git-annex -build for windows that works with both of those versions of git at once. - -If I do switch to only supporting git for windows, I could also drop some -bundled programs from git-annex-installer.exe. These programs are all -bundled with git for windows too: - -* cp -* gpg -* shaNsum - -Leaving only, I think, wget and curl and rsync to be bundled with -git-annex. -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_5_5d218a565af8548a29bb6b1447d38ecd._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_5_5d218a565af8548a29bb6b1447d38ecd._comment deleted file mode 100644 index b4743b1d3..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_5_5d218a565af8548a29bb6b1447d38ecd._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-09-10T23:19:26Z" - content=""" -The *daily* build for windows is now targeting git for windows, including -the fixed rsync. Seems to work, so I'll close this bug; more testing would -be good. -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_6_709f8688e48c6d3d68730ed47e94a1e9._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_6_709f8688e48c6d3d68730ed47e94a1e9._comment deleted file mode 100644 index 41668a087..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_6_709f8688e48c6d3d68730ed47e94a1e9._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="OlivierBerger" - subject="Seems t owork now with git 2.5 for windows and daily build on windows 7" - date="2015-09-11T11:43:43Z" - content=""" -I have tested again, and this time it seems to work out of the box. Thanks alot @joeyh -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_7_d6f5ae804f2d8862c1c9b149f3626062._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_7_d6f5ae804f2d8862c1c9b149f3626062._comment deleted file mode 100644 index 2762a7702..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_7_d6f5ae804f2d8862c1c9b149f3626062._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="olivier.berger@bb28df880236e55a6bfeca92cc3de8ec424f2eba" - nickname="olivier.berger" - subject="Not completely fixed if git not installed on C:" - date="2015-09-11T15:31:25Z" - content=""" -Hi. - -I have the situation where my C: is too full, so I'm installing Git 2.5 on E: in E:\Program files\ instead of C:\Program files\ - -Then while installing git-annex, I'll install it in the same E:\Program files\git\ - -But then, the installer complains that git couldn't be found in c:, and whenever rsyncs are attempted, they fail with : -rsync failed -- run git annex again to resume file transfer - -I think there's probably some weirdness about the paths. - -I hope this is easy to reproduce and fix. - -Thanks in advance. -"""]] diff --git a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_8_d108cb76c69d5b5d1aa897607339623f._comment b/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_8_d108cb76c69d5b5d1aa897607339623f._comment deleted file mode 100644 index f7e13da8f..000000000 --- a/doc/bugs/Windows__58___git_annex_get_fails_with_rsync__58___Failed_to_exec_ssh/comment_8_d108cb76c69d5b5d1aa897607339623f._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="olivier.berger@bb28df880236e55a6bfeca92cc3de8ec424f2eba" - nickname="olivier.berger" - subject="Maybe Git 2.5 must be installed only as 32 bit ?" - date="2015-09-11T15:42:18Z" - content=""" -It seems to me the problem actually lies in that I installed the 64 bits version of Git 2.5, as I've tried to install everything on c:\ and the problem still isn't solved. But I think that the fact that the installer complains about Git not in Program Files(x86) is linked to 32/64 bits mismatch. - -Once I'm installing Git 2.5 32 bits (even if my system runs Windows 7 64 bits), things are back to normal. - -Hope this helps. -"""]] diff --git a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable.mdwn b/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable.mdwn deleted file mode 100644 index 070191a63..000000000 --- a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable.mdwn +++ /dev/null @@ -1,164 +0,0 @@ -Suppose I want to have following repositories syncronized on my windows pc: - - D:\Annex (NTFS hard drive) - R:\Annex (FAT32 usb flash drive) - -What I'm experiencing is that I simply can't do this. Everything ok if both repositories located on the same drive, for example: - - D:\Annex1 - D:\Annex2 - -I'm new to git annex, tell me if I'm doing something completely wrong. - -### System information: - -* windows 8.1 -* git 1.9.4.msysgit.0 -* git-annex 5.20150327-g22c9bbd (official build) - -### Short steps for reproduction: - -* init repo A on drive C -* commit some file -* clone repo A to repo B on drive D -* add remote to repo B, pointing to repo A -* add remote to repo A, pointing to repo B -* execute sync on repo B - -### Verbose step by step reproduction: - - C:\>mkdir Annex - - C:\>cd Annex - - C:\Annex>git init - Initialized empty Git repository in C:/Annex/.git/ - - C:\Annex>git-annex init c - init c - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. - ok - (recording state in git...) - - C:\Annex>echo "Hello" > README.txt - - C:\Annex>git-annex add README.txt - add README.txt ok - (recording state in git...) - - C:\Annex>git-annex sync - commit ok - - C:\>D: - - D:\>mkdir Annex - - D:\>cd Annex - - D:\Annex>cd .. - - D:\>git clone C:\Annex - Cloning into 'Annex'... - done. - - D:\>cd Annex - - D:\Annex>git-annex init d - init d - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - (merging origin/git-annex into git-annex...) - (recording state in git...) - - Enabling direct mode. - ok - (recording state in git...) - - D:\Annex>git remote add c C:\Annex - - D:\Annex>cd .. - - D:\>C: - - C:\>cd Annex - - C:\Annex>git remote add d D:\Annex - - C:\Annex>cd .. - - C:\>D: - - D:\>cd Annex - - D:\Annex>git-annex sync - commit ok - - D:\Annex>git-annex get README.txt - get README.txt (not available) - Try making some of these repositories available: - 98a6384c-ede4-4c97-b20d-9e1895e415cd -- c - failed - git-annex: get: 1 failed - -### Notices - -Latest sync command should inject annex-uuid to .config file, but it does not. For some reason repository on other drive is unavailable. If I do all of this on the same drive everything works ok. I've also checked case with one bare repository, result is the same. - -### Resulting .config files - -#### Repo on drive C - - [core] - repositoryformatversion = 0 - filemode = false - bare = true - logallrefupdates = true - symlinks = false - ignorecase = true - hideDotFiles = dotGitOnly - [annex] - uuid = 98a6384c-ede4-4c97-b20d-9e1895e415cd - sshcaching = false - crippledfilesystem = true - version = 5 - direct = true - [remote "d"] - url = D:\\Annex - fetch = +refs/heads/*:refs/remotes/d/* - -#### Repo on drive D - - [core] - repositoryformatversion = 0 - filemode = false - bare = true - logallrefupdates = true - symlinks = false - ignorecase = true - hideDotFiles = dotGitOnly - [remote "origin"] - url = C:\\Annex - fetch = +refs/heads/*:refs/remotes/origin/* - [branch "annex/direct/master"] - remote = origin - merge = refs/heads/annex/direct/master - [annex] - uuid = 74b81547-ef4b-4bd6-bc6c-38578029ac96 - sshcaching = false - crippledfilesystem = true - version = 5 - direct = true - [remote "c"] - url = C:\\Annex - fetch = +refs/heads/*:refs/remotes/c/* - -> [[fixed|done]]; a simple path calculation bug. --[[Joey]] diff --git a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_1_1c1a8a9171ddd10afea4d639f2aa7af7._comment b/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_1_1c1a8a9171ddd10afea4d639f2aa7af7._comment deleted file mode 100644 index 86c55006a..000000000 --- a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_1_1c1a8a9171ddd10afea4d639f2aa7af7._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlc-3pdibcizrdz4WmZooECL0k6AvM1cWc" - nickname="Joe" - subject="Same problem as another bug" - date="2015-04-02T18:16:25Z" - content=""" -This is the same thing I saw with the bug at http://git-annex.branchable.com/bugs/Windows:_Annex_can_not_get_files/ - -I tried to manually add the annex UID to the remote reference, and it would show up as available (and then it could sync the repos), but I still couldn't get it to \"git annex get\" a file. - ---Joe -"""]] diff --git a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_2_56832a2c87030b9b7a4c3946cdaf1b76._comment b/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_2_56832a2c87030b9b7a4c3946cdaf1b76._comment deleted file mode 100644 index b23824234..000000000 --- a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_2_56832a2c87030b9b7a4c3946cdaf1b76._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E" - nickname="Сергей" - subject="Workaround" - date="2015-04-03T07:32:38Z" - content=""" -As a temporary workaround windows users can create directory junction: - - MKDIR D:\Junctions - MKLINK /J D:\Junctions\R R:\ - -Then you can clone from `D:\Junctions\R\Annex.git` to any directory on drive `D:\`. Whis way repository is available and `git-annex get` works. -"""]] diff --git a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment b/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment deleted file mode 100644 index 6641bb75d..000000000 --- a/doc/bugs/Windows__58___repo_located_on_different_drive_letter_unavailable/comment_3_418a94a7257c2c5eaa7e0febe93c33ab._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-04-14T17:32:29Z" - content=""" -This is partly a bug in uuid discovery; however even after I manually fill -in the remote's annex-uuid, it cannot get the file. -"""]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed.mdwn b/doc/bugs/YouTube_-_error_in_importfeed.mdwn deleted file mode 100644 index d300c621f..000000000 --- a/doc/bugs/YouTube_-_error_in_importfeed.mdwn +++ /dev/null @@ -1,74 +0,0 @@ -### Please describe the problem. -When adding a YouTube channel via importfeed I get the error: - -``` - warning: bad feed content; no enclosures to download -``` - -### What steps will reproduce the problem? -1. `cd $(mktemp -d)` -2. `git init && git annex init` -3. `git annex importfeed https://www.youtube.com/feeds/videos.xml\?playlist_id\=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet` -4. Get sad. :-( - -(URL [https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet](https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet) looks like a feed to Firefox) - - -### What version of git-annex are you using? On what operating system? -OSX (MacOS?) - installed via homebrew - - git-annex version: 6.20161210 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -Debian Jessie - installed via apt-get (ASIDE: why is the apt-get version sooooo old?) - - git-annex version: 5.20141125 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL - remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - - -### Additional information - -Running with `--debug` (see below) seems to indicate that the feed downloads correctly, but it is the parsing that is failing. I don't know what command is being run to parse the feed though. - - -``` shell -git annex importfeed --debug https://www.youtube.com/feeds/videos.xml\?playlist_id\=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet -``` -results in: - -``` shell -(checking known urls...) [2016-12-19 12:39:36.387714] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2016-12-19 12:39:36.392367] process done ExitSuccess -[2016-12-19 12:39:36.392496] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-12-19 12:39:36.396484] process done ExitSuccess -[2016-12-19 12:39:36.406716] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--","."] -[2016-12-19 12:39:36.412674] process done ExitSuccess -importfeed https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet -[2016-12-19 12:39:36.413555] call: wget ["--clobber","-c","-O","/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249","https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet","--user-agent","git-annex/6.20161210"] ---2016-12-19 12:39:36-- https://www.youtube.com/feeds/videos.xml?playlist_id=PLoXkGkpREHNBY9KtkdqhBIfx-waIGSKet -Resolving www.youtube.com... 216.58.199.78, 2404:6800:4006:806::200e -Connecting to www.youtube.com|216.58.199.78|:443... connected. -HTTP request sent, awaiting response... 200 OK -Length: unspecified [text/xml] -Saving to: ‘/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249’ - -/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/f [ <=> ] 23.81K --.-KB/s in 0.02s - -2016-12-19 12:39:37 (1.22 MB/s) - ‘/var/folders/l0/l60294_970b9fh46062znm0r0000gn/T/feed16807282475249’ saved [24386] - -[2016-12-19 12:39:37.595869] process done ExitSuccess - - warning: bad feed content; no enclosures to download -ok -``` - -### 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, for years. I donated to fund the dev and proudly display my git-annex stickers! - -> This is now fixed in feed's git repository, and will be in the next -> release of feed after the current 0.3.11.1 release. [[done]] --[[Joey]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment b/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment deleted file mode 100644 index afdff4942..000000000 --- a/doc/bugs/YouTube_-_error_in_importfeed/comment_1_3c6a60ab9c772b95ca5205199554b914._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-19T19:55:23Z" - content=""" -It's somewhat misleading that it complains there are no enclosures in the -feed. While importfeed mostly downloads only enclosures in podcast feeds, -it also checks link tags, which this feed contains, to see if quvi supports -downloading content from them. Quvi does support the links in this feed, -so it should work despite there being no enclosures. - -I've reproduced it not working, and it seems that the problem is this is -not quite a valid Atom feed, and the feed parsing library is failing to -parse it. Perhaps that can be improved; I filed a bug here -<https://github.com/bergmark/feed/issues/18> -"""]] diff --git a/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment b/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment deleted file mode 100644 index edf4c855c..000000000 --- a/doc/bugs/YouTube_-_error_in_importfeed/comment_2_fe28e0f76dbefb1963820011fc8fc3e7._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="m8r-achx62@7323980ed426b7f78c85dfefe7358672bce44e98" - nickname="m8r-achx62" - avatar="http://cdn.libravatar.org/avatar/adaf4c4277529e10e32c467fa4ed4b9a" - subject="comment 2" - date="2016-12-19T22:33:13Z" - content=""" -Thanks for following this up Joey! -"""]] diff --git a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known.mdwn b/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known.mdwn deleted file mode 100644 index 69732a743..000000000 --- a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known.mdwn +++ /dev/null @@ -1,46 +0,0 @@ -### Please describe the problem. - - -some time ago i was using the webapp bound to a dedicated port number to get around firewall reconfig. Now after some time without using the webapp i'm using it again and when i start it with - - git-annex webapp --listen=192.168.21.12:46199 - -it never starts but just keeps waiting forever(?) - -Update:(to clarify - the following works fine but results in the "random" port "problem") - - git-annex webapp --listen=192.168.21.12 - - - - -### What steps will reproduce the problem? - - -git-annex webapp --listen=192.168.21.12:46199 - - -### What version of git-annex are you using? On what operating system? - - -version 5.20140716-g8c14ba8 on debian wheezy using your pre build static tar archive. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -the log output is the following 3 lines - -[2014-07-23 16:41:45 CEST] main: starting assistant version 5.20140716-g8c14ba8 -WebApp crashed: getAddrInfo: does not exist (Name or service not known) -[2014-07-23 16:41:45 CEST] WebApp: warning WebApp crashed: getAddrInfo: does not exist (Name or service not known) - - - -# End of transcript or log. -"""]] - -> [[done]] --[[Joey]] diff --git a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_1_4d1b96911e3e227c7433ccea543872c1._comment b/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_1_4d1b96911e3e227c7433ccea543872c1._comment deleted file mode 100644 index 5808c5644..000000000 --- a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_1_4d1b96911e3e227c7433ccea543872c1._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="24.159.78.125" - subject="comment 1" - date="2014-07-23T22:10:37Z" - content=""" -Support for --listen with a port was removed in version 5.20140306, since it was buggy. In particular, when the webapp creates a new repository, it needs to switch to a new port to serve that repository, so specifying a single port won't work. - -Instead, when annex.listen or --listen specifies the address to listen on, `git annex webapp` will print out the url to use to open it, including the port it picked. This could be used in a script, or clicked on in the terminal to open a local browser when running the webapp on a remote host. -"""]] diff --git a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_2_7be98a630e1deb655a4d1675bf622d05._comment b/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_2_7be98a630e1deb655a4d1675bf622d05._comment deleted file mode 100644 index 2dd988501..000000000 --- a/doc/bugs/_WebApp_crashed__58___getAddrInfo__58___does_not_exist___40__Name_or_service_not_known/comment_2_7be98a630e1deb655a4d1675bf622d05._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="markusk" - ip="79.243.250.79" - subject="comment 2" - date="2014-07-23T23:18:37Z" - content=""" -Thank you for the info! Will add the port grep to my auth grep script as you suggested. -"""]] diff --git a/doc/bugs/__171__uninit__187___on_direct_mode_repo_gives___171__removeLink__58___permission_denied___40__Permission_denied__41____187__.mdwn b/doc/bugs/__171__uninit__187___on_direct_mode_repo_gives___171__removeLink__58___permission_denied___40__Permission_denied__41____187__.mdwn deleted file mode 100644 index b7dcf29b7..000000000 --- a/doc/bugs/__171__uninit__187___on_direct_mode_repo_gives___171__removeLink__58___permission_denied___40__Permission_denied__41____187__.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. - -I suppose that in a direct mode repo, one might as well just «chmod -R -+w .git/annex; rm -r .git/annex», but I noticed that, when using «git -annex uninit», this will fail to remove some files in .git/annex. - -### What steps will reproduce the problem? -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ mkdir /tmp/foo -$ cd /tmp/foo -$ git init -$ git annex init -$ echo quux > file -$ git annex add file -$ git annex sync -$ git annex uninit -unannex file ok -git-annex: /tmp/foo/.git/annex/objects/zQ/MQ/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4/SHA256E-s3--98ea6e4f216f2fb4b69fff9b3a44842c38686ca685f3f55dc48c5d3fb1107be4.map: removeLink: permission denied (Permission denied) - -# End of transcript or log. -"""]] - - -### What version of git-annex are you using? On what operating system? -git-annex 5.20140709-1 - -linux 3.15.5 - -### Please provide any additional information below. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__34__fatal__58___bad_config_file__34__.mdwn b/doc/bugs/__34__fatal__58___bad_config_file__34__.mdwn deleted file mode 100644 index baaa796db..000000000 --- a/doc/bugs/__34__fatal__58___bad_config_file__34__.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -### Please describe the problem. - -When running a command like `git annex copy --not --in bucket --to bucket`, I got: - -`fatal: bad config file line 1 in /home/jim/tmp/git-annex14898.tmp` - -I caught `git-annex14898.tmp` before it was deleted and it contained an HTML error page. -I have a remote `https://git.example.com/jim/annex.git`, and it appears that git-annex -is requesting `https://git.example.com/jim/annex.git/config`. My server returns a 401 -Forbidden and an error page for that URL, but git-annex tries to use the response as a config file anyway. - -Jim - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_.mdwn b/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_.mdwn deleted file mode 100644 index 1225643f4..000000000 --- a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_.mdwn +++ /dev/null @@ -1,77 +0,0 @@ -### Please describe the problem. - -Setup: Centralized bare repository, different clones, annex v6. When files with special characters, for example german umlauts (öäü), are part of the repository, it does not work to get these files if the file is unlocked. It will be successfully downloaded from the repo (the correct file is stored in the .git/annex subfolder), but the textfile with the initial link will not be replaced. - -It seems to be related to the precompiled 6.20160126-g2336107 version, since it works fine for the version packaged for Arch Linux (pacman). - -### What steps will reproduce the problem? - - -1) Create a bare repo - - $ git init testing.git --bare --shared - -2) clone the bare repo, init - - $ git clone testing.git test1 - $ git annex init - $ git annex upgrade - -3) Add some file with umlauts - - $ echo Wäää >> test_öüä - $ git add . - $ git annex sync --content - -4) Clone bare repo again - - $ git clone testing.git test2 - -5) Init and try to get the file - - $ git annex init 'test3' - $ git annex upgrade - $ git annex get test_öüä - -After the last step the download message will be printed: - - get testäöü (from origin...) - SHA256E-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 - 0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1) - (checksum...) ok - (recording state in git...) - -.. and the file is correctly downloaded, but the file is not replaced and will still contain the file link to the annex folder. - -### What version of git-annex are you using? On what operating system? - -Failing version: - - $ git-annex version - git-annex version: 6.20160126-g2336107 - - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - - -Working version from Arch Linux: - - git-annex version: 6.20160126 - - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -I tested this on two different systems, Arch Linux and Debian Jessie. It does not work with the downloaded precompiled version on both systems. - - -### Please provide any additional information below. - - - -### 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, I've been using it for more than a year to synchronize between different PCs. Great work :-) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_1_8d6bdb32884cb80e444c7739c743c9de._comment b/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_1_8d6bdb32884cb80e444c7739c743c9de._comment deleted file mode 100644 index 067182f18..000000000 --- a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_1_8d6bdb32884cb80e444c7739c743c9de._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-14T19:19:46Z" - content=""" -Reproduced using LANG=C. - -This is a problem with the filename stored in the keys db. In the first -repo, it has: - - VALUES(1,'SHA256E-s8--d1d0c59000f7c0d71485b051c9ca3f25f7afa84f0be5fea98fe1e12f3f898f44','test_öüä'); - -However, in the clone: - - VALUES(1,'SHA256E-s8--d1d0c59000f7c0d71485b051c9ca3f25f7afa84f0be5fea98fe1e12f3f898f44','test_������'); - -So, it's lost the correct filename there. Since it doesn't -find the file with the messed up name, it doesn't replace the file content. - -The problem is not with decoding git's C-style character encoding; that -happens ok yielding `"test_\56515\56502\56515\56508\56515\56484"`. -But, that does not seem to get stored in the database correctly. - -Seems that these unicode surrigates are not handled by the sqlite layer. -The surrigates are being used because LANG=C does not support -unicode. This could also happen when in a (working) utf-8 locale, when -the filename is not utf-8 encoded. - -So, need to escape strings containing such surrigates before passing to -SQL. In a backwards-compatible way. Done. -"""]] diff --git a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_2_1c547ab07cf57cfa9eb5398629e27d56._comment b/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_2_1c547ab07cf57cfa9eb5398629e27d56._comment deleted file mode 100644 index ee1c70781..000000000 --- a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_2_1c547ab07cf57cfa9eb5398629e27d56._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-02-14T21:10:53Z" - content=""" -`git annex fsck` will now clean up repos affected by this problem. -"""]] diff --git a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_3_205784e6385bc8cdd21af4773c57a6f3._comment b/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_3_205784e6385bc8cdd21af4773c57a6f3._comment deleted file mode 100644 index c78cce50e..000000000 --- a/doc/bugs/__39__git_annex_get__39___fails_for_unlocked_files_with_special_characters___40__e.g._umlauts__41___when_using_precompiled_version_6.20160126-g2336107_/comment_3_205784e6385bc8cdd21af4773c57a6f3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="christoph.schober@b8a66d38d9dfeeb6d7cd83888079d5870014ad7a" - nickname="christoph.schober" - subject="comment 3" - date="2016-02-18T21:47:39Z" - content=""" -Perfect, thank you! -"""]] diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn deleted file mode 100644 index a5cdfd6d6..000000000 --- a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -When addurl'ing a big file with .gitattributes configured to add only some files directly into git (and 'git annex add' operating correctly), addurl adds large files straight into git. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20161018+gitgf3c366a-1~ndall+1 - - -### Please provide any additional information below. - -[[!format sh """ -$> cat .gitattributes -* annex.backend=MD5E -* annex.largefiles=(largerthan=100kb) -*.json annex.largefiles=nothing -*.txt annex.largefiles=nothing -*.tsv annex.largefiles=nothing -*.nii.gz annex.largefiles=(largerthan=0kb) -*.tgz annex.largefiles=(largerthan=0kb) -*.tar.gz annex.largefiles=(largerthan=0kb) -*.gz annex.largefiles=(largerthan=0kb) - -$> git annex addurl http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz\?versionId\=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. -addurl fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. (downloading http://fcp-indi.s3.amazonaws.com/data/Projects/HBNSSI/RawDataTars/sub-0031121_baseline.tar.gz?versionId=7FvexHgyazWF.dUo238FA7XRiK0FWQDw. ...) -/mnt/btrfs/datasets/datalad/crawl-misc/indi/ 100%[==============================================================================================>] 195.44M 21.2MB/s in 12s -(non-large file; adding content to git repository) ok -(recording state in git...) -cached/staged changes: - \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes - -$> ls -l fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. --rw------- 1 yoh datalad 204937338 Oct 25 17:30 fcp_indi.s3.amazonaws.com_data_Projects_HBNSSI_RawDataTars_sub_0031121_baseline.tar.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. -cached/staged changes: - \u2026r.gz_versionId_7FvexHgyazWF.dUo238FA7XRiK0FWQDw. | Bin 0 -> 204937338 bytes - -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment b/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment deleted file mode 100644 index e03e574f3..000000000 --- a/doc/bugs/adds_file_destined_for_annex_into_git_in___39__addurl__39__/comment_1_d598317883753baf02175a3bf866e08a._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-21T15:12:54Z" - content=""" -It's sufficient to have "* annex.largefiles=(largerthan=100kb)" -in .gitattributes. - -Even "* annex.largefiles=(largerthan=0kb)" will reproduce it. - -Ok, I see why.. It's running the largefile matcher on the destination file -before it renames the temp file to it! - -Seems to have been broken this way ever since addurl got largefiles -support. Testing didn't catch it because it only affects largefiles -expressions that need to examine the file. - -Fixed in git. Audited other checkFileMatcher calls for this problem; -the rest are ok. -"""]] diff --git a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn b/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn deleted file mode 100644 index 59dda810f..000000000 --- a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed.mdwn +++ /dev/null @@ -1,98 +0,0 @@ -### Please describe the problem. - -only happens if file doesn't exist yet and gets downloaded (interestingly, as I reported in another report, if file exists it gets re-downloaded but this bug doesn't repeat) - -[[!format sh """ - -$> chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$> mkfifo /tmp/pipe - -$> cat /tmp/pipe | git annex --debug addurl --batch --with-files -^Z -[2] + 1084 suspended cat /tmp/pipe | - 1085 suspended git annex --debug addurl --batch --with-files - -$> bg -[2] - 1084 continued cat /tmp/pipe | - 1085 continued git annex --debug addurl --batch --with-files - -$> exec 3>/tmp/pipe - -$> echo "http://www.onerussian.com/tmp/banner.png banner.png" >&3 -[2016-01-11 22:25:34.423037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2016-01-11 22:25:34.427649] process done ExitSuccess -[2016-01-11 22:25:34.428067] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-01-11 22:25:34.432199] process done ExitSuccess - -$> [2016-01-11 22:25:34.432834] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..87efc349dceb06df635c8485ef536ae11f48736c","-n1","--pretty=%H"] -[2016-01-11 22:25:34.438533] process done ExitSuccess -[2016-01-11 22:25:34.439666] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2016-01-11 22:25:34.444875] read: quvi ["--version"] -[2016-01-11 22:25:34.452158] process done ExitSuccess -[2016-01-11 22:25:34.452563] call: quvi ["--verbosity","mute","--support","http://www.onerussian.com/tmp/banner.png"] -[2016-01-11 22:25:34.468071] process done ExitFailure 65 -addurl banner.png (downloading http://www.onerussian.com/tmp/banner.png ...) -[2016-01-11 22:25:34.500939] call: wget ["-q","--show-progress","--clobber","-c","-O","/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png","http://www.onerussian.com/tmp/banner.png","--user-agent","git-annex/6.20160104+gitg0cf96be-1~ndall+1"] -/tmp/123/.git/annex/tmp/URL-s25319--http&c%%www.on 100%[==============================================================================================================>] 24.73K --.-KB/s in 0s -[2016-01-11 22:25:34.518335] process done ExitSuccess -[2016-01-11 22:25:34.519195] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"] -[2016-01-11 22:25:34.5241] read: git ["--version"] -[2016-01-11 22:25:34.527001] process done ExitSuccess -ok - -$> git status # note that file is untracked, although it is a symlink into .git/annex/objects -On branch master - -Initial commit - -Untracked files: - (use "git add <file>..." to include in what will be committed) - - banner.png - -nothing added to commit but untracked files present (use "git add" to track) - -$> # closing the pipe now -$> exec 3>&- -(recording state in git...) -[2016-01-11 22:26:02.947133] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] -$> [2016-01-11 22:26:02.95701] process done ExitSuccess -[2016-01-11 22:26:02.961588] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] -[2016-01-11 22:26:02.964507] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"] -[2016-01-11 22:26:02.971853] process done ExitSuccess -[2016-01-11 22:26:02.972524] process done ExitSuccess -[2016-01-11 22:26:02.973043] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-01-11 22:26:02.975871] process done ExitSuccess -[2016-01-11 22:26:02.977613] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"] -[2016-01-11 22:26:02.982308] process done ExitSuccess -[2016-01-11 22:26:02.982744] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","0b4d294f555bc86c17de89bca35193433408bbef","--no-gpg-sign","-p","refs/heads/git-annex"] -[2016-01-11 22:26:02.990485] process done ExitSuccess -[2016-01-11 22:26:02.990941] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","1359dc4d9296bc4f5941e7299376319899ea222c"] -[2016-01-11 22:26:02.995434] process done ExitSuccess - -[2] - 1084 done cat /tmp/pipe | - 1085 done git annex --debug addurl --batch --with-files - -$> git status -On branch master - -Initial commit - -Changes to be committed: - (use "git rm --cached <file>..." to unstage) - - new file: banner.png - -$> git annex version -git-annex version: 6.20160104+gitg0cf96be-1~ndall+1 -... - -"""]] - -[[!meta author=yoh]] - -> closing as not a bug [[done]] --[[Joey]] diff --git a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_1_79211a11eaf733da209664a31726b3ea._comment b/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_1_79211a11eaf733da209664a31726b3ea._comment deleted file mode 100644 index fbc6924d4..000000000 --- a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_1_79211a11eaf733da209664a31726b3ea._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 1" - date="2016-01-12T03:35:15Z" - content=""" -actually tried now the similar way in bash with pre-downloaded file, the same situation. I guess my test in python for this scenario didn't care to try to commit it without explicit 'git add' ;-) -"""]] diff --git a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_2_ec825d013fedbecfc7dc57dcf977cef1._comment b/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_2_ec825d013fedbecfc7dc57dcf977cef1._comment deleted file mode 100644 index 8d214a756..000000000 --- a/doc/bugs/addurl_--batch__--with-files_doesn__39__t_add_file_into_git_until_pipe_is_closed/comment_2_ec825d013fedbecfc7dc57dcf977cef1._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-01-13T18:26:40Z" - content=""" -git-annex queues up adds because `git add` can be relatively expensive -(rewriting the whole index file). - -If you don't want the queueing to happen for some reason, you can set -annex.queuesize=1 - -(Fixed a fencepost problem that made the queue flush lag by one item when -using annex.queuesize=1) -"""]] diff --git a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn b/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn deleted file mode 100644 index c135f7f32..000000000 --- a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### Please describe the problem. - -Complained elsewhere (http://git-annex.branchable.com/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output/) haven't mentioned it was marked fixed, so reiterating as independent bugreport - -With today's version -[[!format sh """ - -$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files -addurl 123 git-annex: 123 already exists and is not annexed; not overwriting - -$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files 2>/dev/null -addurl 123 % - -$> echo "http://www.onerussian.com/tmp/banner.png 123" | git annex addurl --batch --with-files --json 2>/dev/null -{"command":"addurl","file":"123"% - -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_1_fca98c9f56be6c6dfd2e66acbc86aa03._comment b/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_1_fca98c9f56be6c6dfd2e66acbc86aa03._comment deleted file mode 100644 index 4577975a2..000000000 --- a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_1_fca98c9f56be6c6dfd2e66acbc86aa03._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 1" - date="2016-01-15T16:54:32Z" - content=""" -FWIW: note that it moreover fails the entire addurl --batch process instead of just reporting failure -"""]] diff --git a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_2_8f6d5e3b2e37f741bd18044345007cfb._comment b/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_2_8f6d5e3b2e37f741bd18044345007cfb._comment deleted file mode 100644 index c0561cf77..000000000 --- a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_2_8f6d5e3b2e37f741bd18044345007cfb._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-01-15T18:24:28Z" - content=""" -Dude, you're /dev/nulling stderr, where the error is printed. - -In any case, sure, we can make addurl not throw a fatal error in this -particular case. There are of course many other error conditions where it -may still throw a fatal error. -"""]] diff --git a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_3_434882743d403e615bf7478d176caa03._comment b/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_3_434882743d403e615bf7478d176caa03._comment deleted file mode 100644 index a370797e4..000000000 --- a/doc/bugs/addurl_--batch___40__--json_or_not__41___doesn__39__t_report_failure_correctly_if_non-annexed_file_exists/comment_3_434882743d403e615bf7478d176caa03._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 3" - date="2016-01-15T21:11:24Z" - content=""" -For clarity -- I was devnulling (in 2nd example) just to show what stdout (which is what to be used for getting status) spits out. Thanks for fixing it -- I will check it out asap -"""]] diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn deleted file mode 100644 index cd2e2b5fb..000000000 --- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### What version of git-annex are you using? On what operating system? - -6.20160425+gitgffe2ea2-1~ndall+1 -(reconfirmed with 6.20160523+gitg33c00ab-1~ndall+1) - -### Please provide any additional information below. -Here is a debug output from datalad which shows the interaction - -[[!format sh """ -2016-05-23 16:41:59,955 [DEBUG ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1177) -2016-05-23 16:41:59,956 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '-c', 'annex.largefiles=exclude=Makefile and exclude=LICENSE* and exclude=ISSUES* and exclude=CHANGES* and exclude=README* and exclude=*.[mc] and exclude=dataset*.json and (exclude=*.txt or include=*/*.txt) and (exclude=*.json or include=*/*.json) and (exclude=*.tsv or include=*/*.tsv)', '--with-files', '--json', '--batch'] (annexrepo.py:1180) -2016-05-23 16:41:59,967 [Level 5] Sending u'http://openfmri.s3.amazonaws.com/tarballs/ds052_R2.0.0_metadata_derivatives.tgz?versionId=nrIMjS3lH6TMoSkA.27U.Md_k2BSva3i ds052_R2.0.0_metadata_derivatives.tgz\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=<<['-c', 'annex.largefil...>>, git_options=[], output_proc=<function>, path=<<'/mnt/btrfs/datasets/d...>>) (annexrepo.py:1234) -2016-05-23 16:41:59,968 [Level 5] Done sending. (annexrepo.py:1242) -yoh@datasets.datalad.org's password: -"""]] - -That repository indeed has a remote (ssh) setup pointing to datasets.datalad.org (which carries no load for annex, besides git-annex repository, ATM), but that remote should not be consulted IMHO for addurl operation (not to mention in the --batch mode shouldn't request any user interaction) - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment deleted file mode 100644 index 2fefd37ee..000000000 --- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_1_7206ade4d4d124aa428a4051d4592302._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-23T22:15:40Z" - content=""" -I seem to remember you filing a bug about the same thing with whereis, -although I can't find it just now. Let's not file duplicate bugs when -different git-annex commands exhibit the same bevavior, please? - -As I said before, when you set up a new git remote, you need to run some -git-annex command so that it can query the UUID of the remote. Or, set -remote.name.annex-ignore to make git-annex not use the remote. - -Why does addurl need to set up the remote objects including getting their -UUIDs? Because remotes can claim urls. - -(--batch mode can't prevent stuff from prompting for passwords.) -"""]] diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment deleted file mode 100644 index cfa46a33e..000000000 --- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_2_fbd8bb1607e308b47dca5b27fd73d67e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="what would be the "best" command to run?" - date="2016-05-24T00:10:23Z" - content=""" -Something was nagging back in my mind that issue was indeed similar to previously observed but I, as you, couldn't quickly locate it. Now that you reminded that it was about whois -- [found it](http://git-annex.branchable.com/todo/add_option_to_whereis_to_avoid_network_interactions/) . -What would be the best annex command to run to accomplish just that -- to \"register\" that given remote with annex (without bothering with sync/merge/...)? -I guess I could run 'annex info' but that might want to deal with every remote. -"""]] diff --git a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment b/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment deleted file mode 100644 index ee5ad14fb..000000000 --- a/doc/bugs/addurl_--batch_decides_to_talk_to_ssh_remotes_for_some_reason/comment_3_7f6507e71c6ed9147f01cdf6efdda48b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-24T19:59:36Z" - content=""" -Made `git annex enableremote` be able to be used to explicitly enable -git-annex to use a git remote, probing its UUID. -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__.mdwn b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__.mdwn deleted file mode 100644 index ba92a280b..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__.mdwn +++ /dev/null @@ -1,100 +0,0 @@ -### Please describe the problem. - -I am a bit unsure what is going on ;) - -### What version of git-annex are you using? On what operating system? - -6.20160118+gitgdaf852e-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -chmod: cannot access ‘/tmp/123’: No such file or directory -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex addurl --file svgtune_0.2.0.orig.tar.gz http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz -addurl svgtune_0.2.0.orig.tar.gz (downloading http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz ...) -/tmp/123/.git/annex/tmp/URL-s5121--http&c%%http.debian. 100%[===============================================================================================================================>] 5.00K --.-KB/s in 0s -ok -(recording state in git...) - -$ ls -l svgtune_0.2.0.orig.tar.gz -lrwxrwxrwx 1 yoh yoh 198 Jan 19 14:29 svgtune_0.2.0.orig.tar.gz -> .git/annex/objects/K6/j2/SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz - -$ git annex info -repository mode: indirect -trusted repositories: 0 -semitrusted repositories: 3 - 00000000-0000-0000-0000-000000000001 -- web - 00000000-0000-0000-0000-000000000002 -- bittorrent - 1087c63f-e325-41ff-9c45-bbc493aa42f1 -- yoh@hopa:/tmp/123 [here] -untrusted repositories: 0 -transfers in progress: none -available local disk space: 1 gigabyte (+1 megabyte reserved) -local annex keys: 1 -local annex size: 5.12 kilobytes -annexed files in working tree: 1 -size of annexed files in working tree: 5.12 kilobytes -bloom filter size: 32 mebibytes (0% full) -backend usage: - SHA256E: 1 - -$ git annex initremote datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -initremote datalad-archives ok -(recording state in git...) - -$ echo "dl+archive:SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/svgtune-0.2.0/README.rst README.rst" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{"command":"addurl","file":"README.rst","note":"from datalad-archives","success":true} - -$ ls -l README.rst -lrwxrwxrwx 1 yoh yoh 192 Jan 19 14:33 README.rst -> .git/annex/objects/V4/3p/SHA256E-s2126--76cea2921af6b250b9bcde3a99785d1010d657cbc6781f01cd7a7886708c441f.rst/SHA256E-s2126--76cea2921af6b250b9bcde3a99785d1010d657cbc6781f01cd7a7886708c441f.rst - -$ echo "http://www.onerussian.com/tmp/README2.rst README2.rst" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{"command":"addurl","file":"README2.rst","note":"downloading http://www.onerussian.com/tmp/README2.rst ...","note":"non-large file; adding content to git repository","success":true} - -$ ls -l README2.rst --rw------- 1 yoh yoh 13 Jan 19 14:34 README2.rst - -$ echo "dl+archive:SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/svgtune-0.2.0/Makefile Makefile" | git annex addurl --debug -c annex.largefiles=exclude=*Makefile --with-files --json --batch -{"command":"addurl","file":"Makefile","note":"from datalad-archives","note":"non-large file; adding content to git repository","success":true} - -$ echo "dl+archive:SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/svgtune-0.2.0/README.rst README-2.rst" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{"command":"addurl","file":"README-2.rst","note":"from datalad-archives","note":"non-large file; adding content to git repository","success":true} - - -"""]] - -and to re-confirm that only for the first file, I am redoing above but first asking to addurl Makefile (goes errorneously to annex) and then README.rst (goes to git as it should) - -[[!format sh """ -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex addurl --file svgtune_0.2.0.orig.tar.gz http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz -addurl svgtune_0.2.0.orig.tar.gz (downloading http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz ...) -/tmp/123/.git/annex/tmp/URL-s5121--http&c%%http.debian. 100%[===============================================================================================================================>] 5.00K --.-KB/s in 0s -ok -(recording state in git...) - -$ git annex initremote datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -initremote datalad-archives ok -(recording state in git...) - -$ echo "dl+archive:SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/svgtune-0.2.0/Makefile Makefile" | git annex addurl --debug -c annex.largefiles=exclude=*Makefile --with-files --json --batch -{"command":"addurl","file":"Makefile","note":"from datalad-archives","success":true} - -$ echo "dl+archive:SHA256E-s5121--6d8f7d10206a120a42bec2cd29bc2365d09889fdf070ac8c67d1cff0b1539f63.tar.gz/svgtune-0.2.0/README.rst README.rst" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{"command":"addurl","file":"README.rst","note":"from datalad-archives","note":"non-large file; adding content to git repository","success":true} - -"""]] - -### 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) - - -> fixed; [[done]] --[[Joey]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_1_5e9dfaa4dd781f231954c5c1cf88c418._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_1_5e9dfaa4dd781f231954c5c1cf88c418._comment deleted file mode 100644 index 389442738..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_1_5e9dfaa4dd781f231954c5c1cf88c418._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 1" - date="2016-01-19T19:48:10Z" - content=""" -not sure if of help, but I think it happens for the first 'addurl --batch' process invocation, not just for the first url (in my examples above I didn't have persistent --batch'ed process), since in the results of my batched runs (single addurl --batch process) I have not just a single file but many added to annex instead of git. (previously used a sequence of add/find/addurl which now replaced with a batched addurl) -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_2_4587641f1f2b358dfaa43ac69d4ade49._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_2_4587641f1f2b358dfaa43ac69d4ade49._comment deleted file mode 100644 index d0acd0fdd..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_2_4587641f1f2b358dfaa43ac69d4ade49._comment +++ /dev/null @@ -1,37 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-01-19T19:50:25Z" - content=""" -and actually has nothing to do with custom special remotes -- the same for regular url: - -[[!format sh \"\"\" -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex addurl --file svgtune_0.2.0.orig.tar.gz http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz -addurl svgtune_0.2.0.orig.tar.gz (downloading http://http.debian.net/debian/pool/main/s/svgtune/svgtune_0.2.0.orig.tar.gz ...) -/tmp/123/.git/annex/tmp/URL-s5121--http&c%%http.debian. 100%[===============================================================================================================================>] 5.00K --.-KB/s in 0s -ok -(recording state in git...) - -$ git annex initremote datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -initremote datalad-archives ok -(recording state in git...) - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\",\"success\":true} - -$ ls -l README2.rst -lrwxrwxrwx 1 yoh yoh 188 Jan 19 14:49 README2.rst -> .git/annex/objects/9p/28/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2_.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{\"command\":\"addurl\",\"file\":\"README2_.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\",\"note\":\"non-large file; adding content to git repository\",\"success\":true} - -$ ls -l README2_.rst --rw------- 1 yoh yoh 13 Jan 19 14:34 README2_.rst - -\"\"\"]] -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_3_18b28edd16df0a54c27a9b905fe04d8c._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_3_18b28edd16df0a54c27a9b905fe04d8c._comment deleted file mode 100644 index 954a20bb8..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_3_18b28edd16df0a54c27a9b905fe04d8c._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="actually has smth to do with remotes " - date="2016-01-19T19:53:25Z" - content=""" -since if I don't initremote -- adds to git. If I initremote -- adds to annex: - -[[!format sh \"\"\" -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\",\"note\":\"non-large file; adding content to git repository\",\"success\":true} - - - -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex initremote datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -initremote datalad-archives ok -(recording state in git...) - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\",\"success\":true} - -$ ls -l README2.rst -lrwxrwxrwx 1 yoh yoh 188 Jan 19 14:51 README2.rst -> .git/annex/objects/9p/28/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst - -\"\"\"]] -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_2172459a5100a2ee13356114c166d4e5._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_2172459a5100a2ee13356114c166d4e5._comment deleted file mode 100644 index 480d918fc..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_2172459a5100a2ee13356114c166d4e5._comment +++ /dev/null @@ -1,35 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="but works correct in direct mode" - date="2016-01-19T20:05:56Z" - content=""" -really sorry for spam ;) but here you go -- works correct in direct mode - -[[!format sh \"\"\" -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex direct -commit -On branch master - -Initial commit - -nothing to commit -ok -direct ok - -$ git annex initremote datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -initremote datalad-archives ok -(recording state in git...) - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\",\"success\":true} - -$ ls -l -total 4 --rw------- 1 yoh yoh 13 Jan 19 14:34 README2.rst -\"\"\"]] -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_511d7ec6a1c8ffb508eee17baadb6e2e._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_511d7ec6a1c8ffb508eee17baadb6e2e._comment deleted file mode 100644 index c80c83826..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_4_511d7ec6a1c8ffb508eee17baadb6e2e._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-01-19T20:35:51Z" - content=""" -I don't see how git-annex would know if it's the "first run" or not. -Nor can I see any way that direct mode could influence the behavior here. - -Is there some way to reproduce this without having the datalad special -remote? -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_6_d15a9f5ae9fad0fd0d2009c819f4e3d7._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_6_d15a9f5ae9fad0fd0d2009c819f4e3d7._comment deleted file mode 100644 index 50d79ed6d..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_6_d15a9f5ae9fad0fd0d2009c819f4e3d7._comment +++ /dev/null @@ -1,141 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 6" - date="2016-01-19T21:11:53Z" - content=""" -well -- I don't know any better other custom special remotes, so haven't tried to reproduce with any other. If you would like I could prepare for you environment on a box you could login to troubleshoot with datalad's custom remote (note that only initremote is needed to result in such a behavior... not sure what I could have done wrong to cause annex to fail). - -alternatively -- here is the --debug output, may be it would hint on smth - -[[!format sh \"\"\" -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git annex initremote --debug datalad-archives externaltype=dl+archive type=external autoenable=true encryption=none -[2016-01-19 16:09:23.911888] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] -[2016-01-19 16:09:23.914196] process done ExitSuccess -[2016-01-19 16:09:23.91428] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:23.916237] process done ExitSuccess -[2016-01-19 16:09:23.916407] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..2b377aa0e12121d5621cc6ede8bfe006890b00ed\",\"-n1\",\"--pretty=%H\"] -[2016-01-19 16:09:23.918635] process done ExitSuccess -[2016-01-19 16:09:23.919521] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] -initremote datalad-archives [2016-01-19 16:09:23.924202] chat: git-annex-remote-dl+archive [] -[2016-01-19 16:09:24.432143] git-annex-remote-dl+archive --> VERSION 1 -[2016-01-19 16:09:24.432297] git-annex-remote-dl+archive <-- INITREMOTE -[2016-01-19 16:09:24.432488] git-annex-remote-dl+archive --> INITREMOTE-SUCCESS -[2016-01-19 16:09:24.432566] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"remote.datalad-archives.annex-externaltype\",\"dl+archive\"] -[2016-01-19 16:09:24.43465] process done ExitSuccess -[2016-01-19 16:09:24.434734] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:09:24.437638] process done ExitSuccess -[2016-01-19 16:09:24.437729] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"config\",\"remote.datalad-archives.annex-uuid\",\"736e80de-16b5-41ad-aae7-c969db8a1c99\"] -[2016-01-19 16:09:24.439756] process done ExitSuccess -[2016-01-19 16:09:24.43987] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:09:24.442899] process done ExitSuccess -ok -[2016-01-19 16:09:24.446346] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"] -[2016-01-19 16:09:24.447711] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-index\",\"-z\",\"--index-info\"] -[2016-01-19 16:09:24.452416] process done ExitSuccess -[2016-01-19 16:09:24.452823] process done ExitSuccess -[2016-01-19 16:09:24.45293] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:24.456893] process done ExitSuccess -(recording state in git...) -[2016-01-19 16:09:24.458231] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"write-tree\"] -[2016-01-19 16:09:24.465603] process done ExitSuccess -[2016-01-19 16:09:24.465736] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"commit-tree\",\"217636cb51dae2dce3d442e514aa8f3f7093bd94\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:24.471505] process done ExitSuccess -[2016-01-19 16:09:24.471664] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"update-ref\",\"refs/heads/git-annex\",\"a4997677d40f7e2996480dc8e75e169a6d45ac75\"] -[2016-01-19 16:09:24.47606] process done ExitSuccess - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch --debug -[2016-01-19 16:09:37.73796] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"git-annex\"] -[2016-01-19 16:09:37.740347] process done ExitSuccess -[2016-01-19 16:09:37.740429] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:37.742464] process done ExitSuccess -[2016-01-19 16:09:37.742932] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"log\",\"refs/heads/git-annex..a4997677d40f7e2996480dc8e75e169a6d45ac75\",\"-n1\",\"--pretty=%H\"] -[2016-01-19 16:09:37.745346] process done ExitSuccess -[2016-01-19 16:09:37.746071] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"cat-file\",\"--batch\"] -[2016-01-19 16:09:37.749415] chat: git-annex-remote-dl+archive [] -[2016-01-19 16:09:38.246814] git-annex-remote-dl+archive --> VERSION 1 -[2016-01-19 16:09:38.24697] git-annex-remote-dl+archive <-- PREPARE -[2016-01-19 16:09:38.247137] git-annex-remote-dl+archive --> PREPARE-SUCCESS -[2016-01-19 16:09:38.247213] git-annex-remote-dl+archive <-- GETCOST -[2016-01-19 16:09:38.247347] git-annex-remote-dl+archive --> COST 100 -[2016-01-19 16:09:38.24746] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"config\",\"remote.datalad-archives.annex-cost\",\"100.0\"] -[2016-01-19 16:09:38.249687] process done ExitSuccess -[2016-01-19 16:09:38.249769] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:09:38.252649] process done ExitSuccess -[2016-01-19 16:09:38.25275] git-annex-remote-dl+archive <-- GETAVAILABILITY -[2016-01-19 16:09:38.252957] git-annex-remote-dl+archive --> AVAILABILITY LOCAL -[2016-01-19 16:09:38.253262] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"config\",\"remote.datalad-archives.annex-availability\",\"LocallyAvailable\"] -[2016-01-19 16:09:38.255303] process done ExitSuccess -[2016-01-19 16:09:38.255381] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:09:38.258245] process done ExitSuccess -[2016-01-19 16:09:38.258442] git-annex-remote-dl+archive <-- CLAIMURL http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:09:38.258694] git-annex-remote-dl+archive --> DEBUG Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:09:38.258774] Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:09:38.258833] git-annex-remote-dl+archive --> CLAIMURL-FAILURE -[2016-01-19 16:09:38.259102] read: quvi [\"--version\"] -[2016-01-19 16:09:38.263925] process done ExitSuccess -[2016-01-19 16:09:38.264014] call: quvi [\"--verbosity\",\"mute\",\"--support\",\"http://www.onerussian.com/tmp/README2.rst\"] -[2016-01-19 16:09:38.279913] process done ExitFailure 65 -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\"[2016-01-19 16:09:38.328203] call: wget [\"-q\",\"--clobber\",\"-c\",\"-O\",\"/tmp/123/.git/annex/tmp/URL-s13--http&c%%www.onerussian.com%tmp%README2.rst\",\"http://www.onerussian.com/tmp/README2.rst\",\"--user-agent\",\"git-annex/6.20160118+gitgdaf852e-1~ndall+1\"] -[2016-01-19 16:09:38.339006] process done ExitSuccess -[2016-01-19 16:09:38.339259] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"] -[2016-01-19 16:09:38.339566] read: git [\"--version\"] -[2016-01-19 16:09:38.341398] process done ExitSuccess -,\"success\":true} -[2016-01-19 16:09:38.348957] feed: xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"add\",\"--\"] -[2016-01-19 16:09:38.355416] process done ExitSuccess -[2016-01-19 16:09:38.357025] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"] -[2016-01-19 16:09:38.358861] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"update-index\",\"-z\",\"--index-info\"] -[2016-01-19 16:09:38.364618] process done ExitSuccess -[2016-01-19 16:09:38.365219] process done ExitSuccess -[2016-01-19 16:09:38.365522] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:38.370635] process done ExitSuccess -[2016-01-19 16:09:38.37276] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"write-tree\"] -[2016-01-19 16:09:38.377745] process done ExitSuccess -[2016-01-19 16:09:38.378004] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"commit-tree\",\"3ac987f852fb7da72238dc2f0302516d0f4b5762\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"] -[2016-01-19 16:09:38.385222] process done ExitSuccess -[2016-01-19 16:09:38.385516] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"update-ref\",\"refs/heads/git-annex\",\"f6131f0ea950dd5fca05621630ac6baa91618ec2\"] -[2016-01-19 16:09:38.390555] process done ExitSuccess -[2016-01-19 16:09:38.460596] process done ExitSuccess - -$ ls -l README2.rst -lrwxrwxrwx 1 yoh yoh 188 Jan 19 16:09 README2.rst -> .git/annex/objects/9p/28/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst - -\"\"\"]] - -and here is without initremote -[[!format sh \"\"\" -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch --debug -[2016-01-19 16:10:35.785718] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"git-annex\"] -[2016-01-19 16:10:35.788168] process done ExitSuccess -[2016-01-19 16:10:35.788263] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:10:35.790242] process done ExitSuccess -[2016-01-19 16:10:35.790642] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"log\",\"refs/heads/git-annex..16ea90665454a987f901f72bb8b8ae54d0fed8d1\",\"-n1\",\"--pretty=%H\"] -[2016-01-19 16:10:35.7929] process done ExitSuccess -[2016-01-19 16:10:35.793753] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"cat-file\",\"--batch\"] -[2016-01-19 16:10:35.79694] read: quvi [\"--version\"] -[2016-01-19 16:10:35.802032] process done ExitSuccess -[2016-01-19 16:10:35.802139] call: quvi [\"--verbosity\",\"mute\",\"--support\",\"http://www.onerussian.com/tmp/README2.rst\"] -[2016-01-19 16:10:35.822736] process done ExitFailure 65 -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\"[2016-01-19 16:10:35.885269] call: wget [\"-q\",\"--clobber\",\"-c\",\"-O\",\"/tmp/123/.git/annex/tmp/URL-s13--http&c%%www.onerussian.com%tmp%README2.rst\",\"http://www.onerussian.com/tmp/README2.rst\",\"--user-agent\",\"git-annex/6.20160118+gitgdaf852e-1~ndall+1\"] -[2016-01-19 16:10:35.896785] process done ExitSuccess -[2016-01-19 16:10:35.897041] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"] -[2016-01-19 16:10:35.897383] read: git [\"--version\"] -[2016-01-19 16:10:35.899223] process done ExitSuccess -,\"note\":\"non-large file; adding content to git repository\",\"success\":true} -[2016-01-19 16:10:35.900358] feed: xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"add\",\"--\"] -[2016-01-19 16:10:35.903945] process done ExitSuccess - -$ ls -l README2.rst --rw------- 1 yoh yoh 13 Jan 19 14:34 README2.rst -\"\"\"]] -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_7_d5493497d8f41073a44f888b596e796c._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_7_d5493497d8f41073a44f888b596e796c._comment deleted file mode 100644 index 4aeed9cb8..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_7_d5493497d8f41073a44f888b596e796c._comment +++ /dev/null @@ -1,99 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 7" - date="2016-01-19T21:14:03Z" - content=""" -and here is the first and 2nd invocations which differ in --debug output and their end result -[[!format sh \"\"\" -$ echo \"http://www.onerussian.com/tmp/README2.rst README2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch --debug -[2016-01-19 16:12:26.995558] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"git-annex\"] -[2016-01-19 16:12:26.997958] process done ExitSuccess -[2016-01-19 16:12:26.998035] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:12:27.000078] process done ExitSuccess -[2016-01-19 16:12:27.000635] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"log\",\"refs/heads/git-annex..d7ffcd26b0f991c83da0d59997a4b4d7bb6c9ff2\",\"-n1\",\"--pretty=%H\"] -[2016-01-19 16:12:27.003861] process done ExitSuccess -[2016-01-19 16:12:27.004656] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"cat-file\",\"--batch\"] -[2016-01-19 16:12:27.009211] chat: git-annex-remote-dl+archive [] -[2016-01-19 16:12:27.527475] git-annex-remote-dl+archive --> VERSION 1 -[2016-01-19 16:12:27.527623] git-annex-remote-dl+archive <-- PREPARE -[2016-01-19 16:12:27.527861] git-annex-remote-dl+archive --> PREPARE-SUCCESS -[2016-01-19 16:12:27.527931] git-annex-remote-dl+archive <-- GETCOST -[2016-01-19 16:12:27.528052] git-annex-remote-dl+archive --> COST 100 -[2016-01-19 16:12:27.528131] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"config\",\"remote.datalad-archives.annex-cost\",\"100.0\"] -[2016-01-19 16:12:27.530227] process done ExitSuccess -[2016-01-19 16:12:27.530302] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:12:27.533089] process done ExitSuccess -[2016-01-19 16:12:27.53319] git-annex-remote-dl+archive <-- GETAVAILABILITY -[2016-01-19 16:12:27.533378] git-annex-remote-dl+archive --> AVAILABILITY LOCAL -[2016-01-19 16:12:27.533669] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"config\",\"remote.datalad-archives.annex-availability\",\"LocallyAvailable\"] -[2016-01-19 16:12:27.535709] process done ExitSuccess -[2016-01-19 16:12:27.535862] read: git [\"config\",\"--null\",\"--list\"] -[2016-01-19 16:12:27.538559] process done ExitSuccess -[2016-01-19 16:12:27.538738] git-annex-remote-dl+archive <-- CLAIMURL http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:27.538935] git-annex-remote-dl+archive --> DEBUG Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:27.539007] Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:27.539081] git-annex-remote-dl+archive --> CLAIMURL-FAILURE -[2016-01-19 16:12:27.539358] read: quvi [\"--version\"] -[2016-01-19 16:12:27.544211] process done ExitSuccess -[2016-01-19 16:12:27.544298] call: quvi [\"--verbosity\",\"mute\",\"--support\",\"http://www.onerussian.com/tmp/README2.rst\"] -[2016-01-19 16:12:27.55835] process done ExitFailure 65 -{\"command\":\"addurl\",\"file\":\"README2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\"[2016-01-19 16:12:27.59644] call: wget [\"-q\",\"--clobber\",\"-c\",\"-O\",\"/tmp/123/.git/annex/tmp/URL-s13--http&c%%www.onerussian.com%tmp%README2.rst\",\"http://www.onerussian.com/tmp/README2.rst\",\"--user-agent\",\"git-annex/6.20160118+gitgdaf852e-1~ndall+1\"] -[2016-01-19 16:12:27.615658] process done ExitSuccess -[2016-01-19 16:12:27.616383] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"] -[2016-01-19 16:12:27.617697] read: git [\"--version\"] -[2016-01-19 16:12:27.62155] process done ExitSuccess -,\"success\":true} -[2016-01-19 16:12:27.633965] feed: xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"add\",\"--\"] -[2016-01-19 16:12:27.64207] process done ExitSuccess -[2016-01-19 16:12:27.643078] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"] -[2016-01-19 16:12:27.644711] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"update-index\",\"-z\",\"--index-info\"] -[2016-01-19 16:12:27.651595] process done ExitSuccess -[2016-01-19 16:12:27.651948] process done ExitSuccess -[2016-01-19 16:12:27.652117] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:12:27.655295] process done ExitSuccess -[2016-01-19 16:12:27.656512] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"write-tree\"] -[2016-01-19 16:12:27.662511] process done ExitSuccess -[2016-01-19 16:12:27.662718] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"commit-tree\",\"5051fd1b69430fa24b200817f6c724ce1269059a\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"] -[2016-01-19 16:12:27.673622] process done ExitSuccess -[2016-01-19 16:12:27.673873] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"update-ref\",\"refs/heads/git-annex\",\"bb2fd6a3391ad86b627c121c2b013f61c1936b0c\"] -[2016-01-19 16:12:27.679617] process done ExitSuccess -[2016-01-19 16:12:27.760906] process done ExitSuccess - -$ echo \"http://www.onerussian.com/tmp/README2.rst README-2.rst\" | git annex addurl -c annex.largefiles=exclude=*.rst --with-files --json --batch --debug -[2016-01-19 16:12:42.552976] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"git-annex\"] -[2016-01-19 16:12:42.556093] process done ExitSuccess -[2016-01-19 16:12:42.556174] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2016-01-19 16:12:42.558521] process done ExitSuccess -[2016-01-19 16:12:42.558658] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"log\",\"refs/heads/git-annex..bb2fd6a3391ad86b627c121c2b013f61c1936b0c\",\"-n1\",\"--pretty=%H\"] -[2016-01-19 16:12:42.561171] process done ExitSuccess -[2016-01-19 16:12:42.561883] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"cat-file\",\"--batch\"] -[2016-01-19 16:12:42.565138] chat: git-annex-remote-dl+archive [] -[2016-01-19 16:12:43.082528] git-annex-remote-dl+archive --> VERSION 1 -[2016-01-19 16:12:43.082742] git-annex-remote-dl+archive <-- PREPARE -[2016-01-19 16:12:43.083009] git-annex-remote-dl+archive --> PREPARE-SUCCESS -[2016-01-19 16:12:43.083139] git-annex-remote-dl+archive <-- CLAIMURL http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:43.083369] git-annex-remote-dl+archive --> DEBUG Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:43.083494] Not claiming url http://www.onerussian.com/tmp/README2.rst -[2016-01-19 16:12:43.083596] git-annex-remote-dl+archive --> CLAIMURL-FAILURE -[2016-01-19 16:12:43.083766] read: quvi [\"--version\"] -[2016-01-19 16:12:43.089921] process done ExitSuccess -[2016-01-19 16:12:43.090047] call: quvi [\"--verbosity\",\"mute\",\"--support\",\"http://www.onerussian.com/tmp/README2.rst\"] -[2016-01-19 16:12:43.106383] process done ExitFailure 65 -{\"command\":\"addurl\",\"file\":\"README-2.rst\",\"note\":\"downloading http://www.onerussian.com/tmp/README2.rst ...\"[2016-01-19 16:12:43.167357] call: wget [\"-q\",\"--clobber\",\"-c\",\"-O\",\"/tmp/123/.git/annex/tmp/URL-s13--http&c%%www.onerussian.com%tmp%README2.rst\",\"http://www.onerussian.com/tmp/README2.rst\",\"--user-agent\",\"git-annex/6.20160118+gitgdaf852e-1~ndall+1\"] -[2016-01-19 16:12:43.184513] process done ExitSuccess -[2016-01-19 16:12:43.184842] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"check-attr\",\"-z\",\"--stdin\",\"annex.backend\",\"annex.numcopies\",\"--\"] -[2016-01-19 16:12:43.185231] read: git [\"--version\"] -[2016-01-19 16:12:43.189767] process done ExitSuccess -,\"note\":\"non-large file; adding content to git repository\",\"success\":true} -[2016-01-19 16:12:43.193754] feed: xargs [\"-0\",\"git\",\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.largefiles=exclude=*.rst\",\"add\",\"--\"] -[2016-01-19 16:12:43.199038] process done ExitSuccess -[2016-01-19 16:12:43.256073] process done ExitSuccess - -$ ls -l -total 8 --rw------- 1 yoh yoh 13 Jan 19 14:34 README-2.rst -lrwxrwxrwx 1 yoh yoh 188 Jan 19 16:12 README2.rst -> .git/annex/objects/9p/28/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst/SHA256E-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01.rst - - -\"\"\"]] -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_8_e52ad311ed01f652fb73fbc8340e30aa._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_8_e52ad311ed01f652fb73fbc8340e30aa._comment deleted file mode 100644 index 33c61fa2e..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_8_e52ad311ed01f652fb73fbc8340e30aa._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2016-01-20T18:30:18Z" - content=""" -I don't know how the datalad remote could be causing this, but I can't -reproduce this under as similar circumstances as I can set up here. - -(I also can't find any code paths through addurl where it doesn't check -annex.largefiles, except of course for code paths where it doesn't download -the content of the file.) -"""]] diff --git a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_9_d898fe3f91673ac40014d01f35bc5138._comment b/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_9_d898fe3f91673ac40014d01f35bc5138._comment deleted file mode 100644 index 9040dc10a..000000000 --- a/doc/bugs/addurl_--batch_from_url_from_a_custom_special_remote_adds_to_annex_disregarding_largefiles___40__on_first_run__41__/comment_9_d898fe3f91673ac40014d01f35bc5138._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2016-01-22T17:43:01Z" - content=""" -This is caused by git-annex needing to change the git config for the -special remote, so it then re-loads it, and thus loses the value passed -via -c. - -Workaround is to pass the -c as a parameter to git, not annex. - -And fixed now. -"""]] diff --git a/doc/bugs/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn b/doc/bugs/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn deleted file mode 100644 index c3645b6fa..000000000 --- a/doc/bugs/addurl_--file__causes_file_redownload_even_if_it_already_present.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. - -IMHO annex shouldn't redownload the file (not yet under annex/git control) entirely if pointed by --file=FILE FILE exists. - -[[!format sh """ - -$> chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok - -$> wget -q http://www.onerussian.com/tmp/banner.png - -$> ls -l -total 28 --rw------- 1 yoh yoh 25319 Sep 17 13:49 banner.png - -$> git annex addurl --file=banner.png http://www.onerussian.com/tmp/banner.png -addurl banner.png (downloading http://www.onerussian.com/tmp/banner.png ...) -/tmp/123/.git/annex/tmp/URL-s25319--http&c%%w 100%[=================================================================================================>] 24.73K --.-KB/s in 0.003s -ok - -$> git annex version -git-annex version: 6.20160104+gitg0cf96be-1~ndall+1 - -"""] - -[[!meta author=yoh]] - -> I don't think that the re-download is the bug. The actual problem -> is that the file is present and not an annexed file, so git-annex addurl -> should avoid overwriting it, whatever its content. [[fixed|done]] -> --[[Joey]] diff --git a/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds.mdwn b/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds.mdwn deleted file mode 100644 index 3383dd52a..000000000 --- a/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds.mdwn +++ /dev/null @@ -1,197 +0,0 @@ -### Please describe the problem. - -"git annex --pathdepth=3 addurl URL" displays this error message and reports "failed", even though the operation succeeds when using --fast: - - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - -### What steps will reproduce the problem? - -I have lots of downloaded files I'd like to add an URL to, so I'm doing this: - - $ ga addurl --fast --pathdepth=3 $(for f in *.mp3; do echo http://traffic.libsyn.com/geologicpodcast/$f; done) - addurl - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - failed - addurl - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - failed - addurl - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - [... Delete 166 lines ...] - addurl - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - failed - addurl - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/2325: rename: does not exist (No such file or directory) - failed - (Recording state in git...) - git-annex: addurl: 60 failed - $ - -This "ga" command is a wrapper around git-annex to make it work everywhere with the .tar.gz version: - - #!/bin/bash - - #======================================================================= - # ga - # File ID: e89047ce-29d1-11e2-bb6f-00c0a8deee11 - #======================================================================= - - if test "$1" = "sync"; then - stat_output="$(git status --porcelain | grep -v '^??')" - test -n "$stat_output" && { echo ga: Repo has modifications, will not git-annex sync >&2; exit 1; } - fi - /opt/git-annex/runshell /opt/git-annex/git-annex "$@" - -$PATH is also set up to include /opt/git-annex/bin/ , and all other operations work nicely. In my ~/bin/ directory I've also symlinked this script to "git-annex". - -When dropping "--fast", this happens: - - $ ga addurl --pathdepth=3 $(for f in *.mp3; do echo http://traffic.libsyn.com/geologicpodcast/$f; done | tail -20 | head -1) - addurl (downloading http://traffic.libsyn.com/geologicpodcast/GeologicPodcast302-Feb28-13.mp3 ...) --2013-07-04 14:08:01-- http://traffic.libsyn.com/geologicpodcast/GeologicPodcast302-Feb28-13.mp3 - Resolving traffic.libsyn.com (traffic.libsyn.com)... 204.16.245.39 - Connecting to traffic.libsyn.com (traffic.libsyn.com)|204.16.245.39|:80... connected. - HTTP request sent, awaiting response... 302 Found - Location: http://ec.libsyn.com/p/6/9/b/69b9837556ed5238/GeologicPodcast302-Feb28-13.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf853ed5cd5c0f85&c_id=5440885 [following] - --2013-07-04 14:08:02-- http://ec.libsyn.com/p/6/9/b/69b9837556ed5238/GeologicPodcast302-Feb28-13.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf853ed5cd5c0f85&c_id=5440885 - Resolving ec.libsyn.com (ec.libsyn.com)... 68.232.34.133 - Connecting to ec.libsyn.com (ec.libsyn.com)|68.232.34.133|:80... connected. - HTTP request sent, awaiting response... 200 OK - Length: 53173384 (51M) [audio/mpeg] - Saving to: `/media/usb32g-1/annex/musikk/.git/annex/tmp/URL--http&c%%traffic.libsyn.com%geologicpodcast%GeologicPodcast302-Feb28-13.mp3' - - 100%[==================================================================================================================================================================>] 53,173,384 3.50M/s in 45s - - 2013-07-04 14:08:47 (1.13 MB/s) - `/media/usb32g-1/annex/musikk/.git/annex/tmp/URL--http&c%%traffic.libsyn.com%geologicpodcast%GeologicPodcast302-Feb28-13.mp3' saved [53173384/53173384] - - (checksum...) - git-annex: /media/usb32g-1/annex/musikk/.git/annex/tmp/3970: rename: does not exist (No such file or directory) - failed - (Recording state in git...) - git-annex: addurl: 1 failed - $ - -git-annex now believes that the file is stored locally, but an fsck shows how things really are: - - $ ga fsck - fsck GeologicPodcast02-Feb21-07.mp3 ok - fsck GeologicPodcast03-Feb28-07.mp3 ok - [... Delete 35 lines ...] - fsck GeologicPodcast301-Feb22-13.mp3 ok - fsck GeologicPodcast302-Feb28-13.mp3 (fixing location log) - ** Based on the location log, GeologicPodcast302-Feb28-13.mp3 - ** was expected to be present, but its content is missing. - failed - fsck GeologicPodcast303-Mar07-13.mp3 ok - fsck GeologicPodcast303.1_Fancast6-Mar09-13.mp3 ok - [... Delete 16 lines ...] - fsck GeologicPodcast72-Jul03-08.mp3 ok - (Recording state in git...) - git-annex: fsck: 3 failed - $ - -After this fsck, everything is OK again; the location log is correct and "get" from this URL works. - -The file data didn't exist locally (it's stored on another disk) when doing this, but I also experimented what would happen if the file data did exist: - - $ rm GeologicPodcast297-Jan24-13.mp3 - $ wget http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 - --2013-07-04 14:35:15-- http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 - Resolving traffic.libsyn.com (traffic.libsyn.com)... 204.16.245.39 - Connecting to traffic.libsyn.com (traffic.libsyn.com)|204.16.245.39|:80... connected. - HTTP request sent, awaiting response... 302 Found - Location: http://hwcdn.libsyn.com/p/9/d/f/9df13b1a6d622c46/GeologicPodcast297-Jan24-13.mp3?c_id=5341445&expiration=1372945406&hwt=476d03abba40d71119011bf7cb51f68a [following] - --2013-07-04 14:35:16-- http://hwcdn.libsyn.com/p/9/d/f/9df13b1a6d622c46/GeologicPodcast297-Jan24-13.mp3?c_id=5341445&expiration=1372945406&hwt=476d03abba40d71119011bf7cb51f68a - Resolving hwcdn.libsyn.com (hwcdn.libsyn.com)... 69.16.175.42, 69.16.175.10 - Connecting to hwcdn.libsyn.com (hwcdn.libsyn.com)|69.16.175.42|:80... connected. - HTTP request sent, awaiting response... 200 OK - Length: 49299974 (47M) [audio/mpeg] - Saving to: ‘GeologicPodcast297-Jan24-13.mp3’ - - 100%[===========================================================================================================================================>] 49,299,974 5.88MB/s in 30s - - $ ga add - add GeologicPodcast297-Jan24-13.mp3 (checksum...) ok - (Recording state in git...) - $ ga addurl --pathdepth=3 http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 - -At this stage, the data for this .mp3 file exist locally, but git-annex is either unaware of it, or it insists on verifying the data. Anyhow, it downloads the file: - - $ ga addurl --pathdepth=3 http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 - addurl (downloading http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 ...) --2013-07-04 14:42:40-- http://traffic.libsyn.com/geologicpodcast/GeologicPodcast297-Jan24-13.mp3 - Resolving traffic.libsyn.com (traffic.libsyn.com)... 204.16.245.39 - Connecting to traffic.libsyn.com (traffic.libsyn.com)|204.16.245.39|:80... connected. - HTTP request sent, awaiting response... 302 Found - Location: http://ec.libsyn.com/p/9/d/f/9df13b1a6d622c46/GeologicPodcast297-Jan24-13.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf853ed5cc54b707&c_id=5341445 [following] - --2013-07-04 14:42:41-- http://ec.libsyn.com/p/9/d/f/9df13b1a6d622c46/GeologicPodcast297-Jan24-13.mp3?d13a76d516d9dec20c3d276ce028ed5089ab1ce3dae902ea1d01cf853ed5cc54b707&c_id=5341445 - Resolving ec.libsyn.com (ec.libsyn.com)... 68.232.34.133 - Connecting to ec.libsyn.com (ec.libsyn.com)|68.232.34.133|:80... connected. - HTTP request sent, awaiting response... 206 Partial Content - Length: 49299974 (47M), 48727654 (46M) remaining [audio/mpeg] - Saving to: `/media/usb32g-1/annex/musikk/.git/annex/tmp/URL--http&c%%traffic.libsyn.com%geologicpodcast%GeologicPodcast297-Jan24-13.mp3' - - 100%[====================================================================================================================================================================>] 49,299,974 2.07M/s in 88s - - 2013-07-04 14:44:10 (538 KB/s) - `/media/usb32g-1/annex/musikk/.git/annex/tmp/URL--http&c%%traffic.libsyn.com%geologicpodcast%GeologicPodcast297-Jan24-13.mp3' saved [49299974/49299974] - - (checksum...) - git-annex: /media/usb32g-1/annex/musikk/.git/annex/objects/gp/7Z/SHA256-s49299974--ff6758202d7168a0548b004d0c6e79a095b7738f442aa14d2603665914bee7e0/SHA256-s49299974--ff6758202d7168a0548b004d0c6e79a095b7738f442aa14d2603665914bee7e0: rename: does not exist (No such file or directory) - failed - (Recording state in git...) - git-annex: addurl: 1 failed - 2013-07-04 14:44:11 sunny@dg-vbox:/media/usb32g-1/annex/musikk/podcast/Geologic Podcast (master) - $ - -The error message appears again, but because the data did exist from before, git-annex fsck has nothing to complain about: - - $ ga fsck - [...] - fsck GeologicPodcast297-Jan24-13.mp3 (checksum...) ok - [...] - 2013-07-04 14:44:33 sunny@dg-vbox:/media/usb32g-1/annex/musikk/podcast/Geologic Podcast (master) - $ - -### What version of git-annex are you using? On what operating system? - -v4.20130627 Linux i386 and AMD64. Both versions behave the same way. Tested on two computers: - -Computer #1 (AMD64 version): - - $ uname -a - Linux dg-vbox 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux - $ lsb_release -a - No LSB modules are available. - Distributor ID: LinuxMint - Description: Linux Mint 15 Olivia - Release: 15 - Codename: olivia - -Computer #2 (i386 version): - - $ uname -a - Linux linode 2.6.39.1-linode34 #1 SMP Tue Jun 21 10:29:24 EDT 2011 i686 GNU/Linux - $ lsb_release -a - Distributor ID: Ubuntu - Description: Ubuntu 10.04.4 LTS - Release: 10.04 - Codename: lucid - No LSB modules are available. - -Also tested with v4.20130601, same thing happens. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -All interesting transcripts are posted above with cruft removed. - -# End of transcript or log. -"""]] - -> The cause of this bug is using --pathdepth=3 when the url -> only has two components in its path. So, kinda GIGO, but -> let's fix this anyway. ;) -> -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds/comment_1_1f5e0bc93631baf0f8c1bec2e68493c5._comment b/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds/comment_1_1f5e0bc93631baf0f8c1bec2e68493c5._comment deleted file mode 100644 index 6ea844f2e..000000000 --- a/doc/bugs/addurl__58_____34__rename__58___does_not_exist__34___and_reports_fail__44___but_succeeds/comment_1_1f5e0bc93631baf0f8c1bec2e68493c5._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="http://sunny256.sunbase.org/" - nickname="sunny256" - subject="comment 1" - date="2013-07-08T19:56:58Z" - content=""" -Aha, in other words, some kind of PEBCAC put in a polite way. :) I thought this should be correct, as the man page says - -> For example, --pathdepth=1 will use \"dir/subdir/bigfile\", while --pathdepth=3 will use \"bigfile\". - -This is how I thought it worked: - -* 0 = hostname, path, filename -* 1 = path, filename -* 2 = filename - -After reading your answer I first thought it was a typo in the documentation, but of course the number specify the level of subdirectories to use in the file name. D'oh! - -Thanks for the fix and information. -"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading.mdwn b/doc/bugs/addurl_pathdepth_description_misleading.mdwn deleted file mode 100644 index 7bb9d582a..000000000 --- a/doc/bugs/addurl_pathdepth_description_misleading.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -The description for the *pathdepth* option for *addurl* doesn't match its behaviour (emphasis mine). - -> Rather than basing the **filename** on the whole url, this causes a **path** to be constructed, starting at the specified depth within the path of the url. -> -> For example, adding the url http://www.example.com/dir/subdir/bigfile with --pathdepth=1 will use "**dir/subdir/bigfile**", while --pathdepth=3 will use "bigfile". - -This isn't how it behaves. It would be more accurate as (emphasis on changes): - -> Rather than basing the filename on the whole url, this causes a **filename** to be constructed, starting at the specified depth within the path of the url. -> -> For example, adding the url http://www.example.com/dir/subdir/bigfile with --pathdepth=1 will use "**dir_subdir_bigfile**", while --pathdepth=3 will use "bigfile". - -For what I am doing (adding a directory tree with addurl and file:// URLs), I'd actually like the behaviour described (to recreate the tree), but I'm not sure which one was the *intended* behaviour.. - -> [[done]]; bug report didn't show what was wrong; I can see nothing wrong; -> bug reporter cannot seem to remember what was wrong. Probably user error. -> --[[Joey]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_1_e4e0a6e27ba5d7d95468e017ec07fa77._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_1_e4e0a6e27ba5d7d95468e017ec07fa77._comment deleted file mode 100644 index 59a62f387..000000000 --- a/doc/bugs/addurl_pathdepth_description_misleading/comment_1_e4e0a6e27ba5d7d95468e017ec07fa77._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 1" - date="2016-11-02T10:03:46Z" - content=""" -Sorry, you can ignore this for now. I just noticed I'm using 6.20160613.. the Arch Linux version (in community) is really out of date. - -I'll update and confirm if this is actually an issue. -"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_2_888bc4ffd264fbd8d07f07c017dec278._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_2_888bc4ffd264fbd8d07f07c017dec278._comment deleted file mode 100644 index 1c37fb29e..000000000 --- a/doc/bugs/addurl_pathdepth_description_misleading/comment_2_888bc4ffd264fbd8d07f07c017dec278._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 2" - date="2016-11-02T10:37:48Z" - content=""" -Tested on 6.20161102-g330c68b and the description/behaviour mismatch still exists. -"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment deleted file mode 100644 index 45be25186..000000000 --- a/doc/bugs/addurl_pathdepth_description_misleading/comment_3_2744e42db662486b46e203a72c3e56c7._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-11-16T19:04:37Z" - content=""" -Seems to work as described here: - - joey@darkstar:~/tmp/r>rm localhost__joey_blog_index.html - joey@darkstar:~/tmp/r>git annex addurl --pathdepth 2 http://localhost/~joey/blog/index.html - addurl blog/index.html (downloading http://localhost/~joey/blog/index.html ...) - /home/joey/tmp/r/ 100%[===========>] 40.70K --.-KB/s in 0s - ok - (recording state in git...) - joey@darkstar:~/tmp/r>ls - blog/ - joey@darkstar:~/tmp/r>ls blog - index.html - -It would probably help if you can provide a test case where it does not work -as described. -"""]] diff --git a/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment b/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment deleted file mode 100644 index 0cafc2a4d..000000000 --- a/doc/bugs/addurl_pathdepth_description_misleading/comment_4_2a9eb14a8c6d06747bb5dda7ff179ec7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="CandyAngel" - avatar="http://cdn.libravatar.org/avatar/15c0aade8bec5bf004f939dd73cf9ed8" - subject="comment 4" - date="2016-11-25T20:27:07Z" - content=""" -I really don't know what to say. I can't even figure out which computer I updated git-annex on to test if it was still happening.. let alone reproduce it anymore. It does work fine. - -I'm so sorry to bother you with this, I've done something stupid! This is exactly why you ask for a transcript of bugs occurring. (Feel free to use this as an example for why you ask for them, so some good can come of it at least..). -"""]] diff --git a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn b/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn deleted file mode 100644 index 863667e31..000000000 --- a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -### Please describe the problem. - -I'm testing whether I can use git-annex to sync binary files to a windows vm (used for development) with v6 adjusted branches. - -For testing I use git-annex precompiled binaries for windows, together with git from [msys2](https://sourceforge.net/projects/msys2/), an environment similar to cygwin (it does the usual hacks with path translation, etc). - -It seems to more or less work for syncing content from my linux box to the vm, apart from some unexplained clean/smudge errors, which I'll investigate later. - -However, when I commit to the adjusted branch in the windows vm, and afterwards do a `git annex sync` to propagate changes to the unadjusted `master`, a broken link for the annexed file `A/B` ends up at the root of the repository in the unadjusted branch. - - -### What steps will reproduce the problem? - -On windows under msys2 do the following: - -* Create a v6 annex repo with an adjusted branch. -* Annex a file in a subdirectory, for example `A/B`. -* Commit to the adjusted branch. -* Propagate changes to the original branch. - -A file `B` appears in the non-adjusted branch, instead of `A/B`, with broken link (as if it still were in A/B). - -### What version of git-annex are you using? On what operating system? - -git annex 6.20160418 windows precompiled binaries on windows 10 under msys2. msys2 git is 2.8.1. I haven't tested with other windows git distributions. - - -### Please provide any additional information below. - -Here is a shell transcript while reproducing this - -[[!format sh """ -$ mkdir test; cd test -$ git init -$ git annex init --version=6 -# it automatically puts you in an adjusted master, because of crippled filesystem... -$ git branch -* adjusted/master(unlocked) - git-annex - master - -$ mkdir A -$ echo "b" > A/B -$ git annex add A/B -$ git commit -m 'annexed A/B' -$ git ls-tree -r --name-only 'adjusted/master(unlocked)' -A/B -$ git ls-tree -r --name-only 'master' - -$ git annex sync -commit -On branch adjusted/master(unlocked) -nothing to commit, working directory clean -ok - -$ git ls-files -r --name-only 'adjusted/master(unlocked)' -A/B -$ git ls-files -r --name-only 'master' -B -"""]] - -### 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) - -Well, git-annex is wonderful! - -I use it to sync binary files across linux boxes, I use it for binary distro packages I compile for myself, for my calibre books, pictures, movies... and I'm very happy with it on linux. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_1_af48a796954033474019b5eb09f54948._comment b/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_1_af48a796954033474019b5eb09f54948._comment deleted file mode 100644 index ed621d1c6..000000000 --- a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_1_af48a796954033474019b5eb09f54948._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-04T17:03:57Z" - content=""" -There were several places in the adjusted branch code that made unix -filename assumptions. I think I've fixed them all now; it seems to work -well on windows in my testing now. - -You should be able to grab an updated windows build from the windows -autobuilder within the hour. -"""]] diff --git a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_2_7ee505eaab4c59a340e1171794660b88._comment b/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_2_7ee505eaab4c59a340e1171794660b88._comment deleted file mode 100644 index 7c46df3f8..000000000 --- a/doc/bugs/adjusted_branches_on_windows__58___file_paths_get_messed_up_when_commiting_to_an_adjusted_branch/comment_2_7ee505eaab4c59a340e1171794660b88._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="abdo.roig@4afedf09b5d9a0a6a9f44fc16a778e10cc3e89dc" - nickname="abdo.roig" - subject="Problem fixed" - date="2016-05-05T08:32:37Z" - content=""" -The reported problem is fixed for me. Thanks a lot! -"""]] diff --git a/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat.mdwn b/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat.mdwn deleted file mode 100644 index fbc05c2c6..000000000 --- a/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. -When assistant sync with some remote, it will call git that will call ssh without annex-sync - -### What steps will reproduce the problem? -I've remote that have: - - [remote "shukrat"] - [...] - annex-ignore = true - annex-ssh-options = -i /home/moi/.ssh/git-annex/some-key - -When I run `git annex sync shukrat` in the repository, it will sync it using the key, but when I ask the assistant to sync it, it will use some otherkey and so it will ask for my passphrase. - - -### What version of git-annex are you using? On what operating system? - - % git annex version - git-annex version: 5.20150916-1 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - -on debian/sid - -### Please provide any additional information below. - -when the assistant is syncing, I've: - - $ pstree -p | grep ssh-ask - |-git(27589)---ssh(27590)---ssh-askpass(27617) - $ ps -f -p 275900 - UID PID PPID C STIME TTY TIME CMD - moi 27590 27589 0 14:10 ? 00:00:00 ssh user-data@shukrat git-receive-pack '/home/user-data/git-repos/Images.git/ - -log from .git/annex/daemon.log: - - [2015-09-27 14:09:55.844597] main: Syncing with shukrat - Pass a valid window to KWallet::Wallet::openWallet(). - Pass a valid window to KWallet::Wallet::openWallet(). - Everything up-to-date - - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat/comment_1_ee684ab3e96a1c1317562d8228d41463._comment b/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat/comment_1_ee684ab3e96a1c1317562d8228d41463._comment deleted file mode 100644 index 3a6e32bab..000000000 --- a/doc/bugs/annex-ssh-options_seem_to_be_ignored_in_some_occasion_by_the_assistnat/comment_1_ee684ab3e96a1c1317562d8228d41463._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-10T19:56:03Z" - content=""" -Ok, I was able to reproduce it, when using the assistant it seems the -option is not passed when pushing and fetching there. -"""]] diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn b/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn deleted file mode 100644 index 67ebb88d6..000000000 --- a/doc/bugs/annex.gnupg-options_not_used_by_assistant.mdwn +++ /dev/null @@ -1,85 +0,0 @@ -### Please describe the problem. - -I am using annex with a gcrypt encrypted repository but I am not able to sync content to the remote share via Webapp. If I sync via command line everything is working as expected but via Webapp I receive several error messages complaining about tty not available. - -As I workaround I changed two things: - -1. /usr/local/bin/git-remote-gcrypt: As $GPG_AGENT_INFO was not set I needed to include "--no-tty" on line 377 -2. Add a line in ~/.gnupg/gpg.conf with option "no-tty" - -As this breaks gpg2 for use on command line I wanted to provide the --no-tty via option **annex.gnupg-options** as mentioned in the manual. Not sure what I am doing wrong but the Webapp does not pick up these options. - -``` -[annex] - gnupg-options = --no-tty -``` - - -### What steps will reproduce the problem? - -Create repository via - -```sh -git annex initremote hidrive type=gcrypt gitrepo=rsync.hidrive.strato.com:/users/xxxxxx/hidrive.git chunk=5MiB keyid=XXXXXXXX -``` -Launch Webapp - -```sh -git annex webapp -``` - -Copy files to local annex directory - -### What version of git-annex are you using? On what operating system? - -OSX 10.11.4 - -gpg (GnuPG) 2.0.30 -libgcrypt 1.7.0 -Copyright (C) 2015 Free Software Foundation, Inc. -License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> -This is free software: you are free to change and redistribute it. -There is NO WARRANTY, to the extent permitted by law. - -Home: ~/.gnupg -Supported algorithms: -Pubkey: RSA, RSA, RSA, ELG, DSA -Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, - CAMELLIA128, CAMELLIA192, CAMELLIA256 -Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 -Compression: Uncompressed, ZIP, ZLIB, BZIP2 - - -git-annex version: 6.20160418 -build flags: Assistant Webapp Pairing Testsuite WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 - - -### Please provide any additional information below. - -[[!format sh """ - -[2016-05-05 15:04:31.059236] Pusher: Syncing with hidrive -(recording state in git...) -gcrypt: Development version -- Repository format MAY CHANGE -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) - -"""]] - -### 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) - - -> added annex.gnupg-decrypt-options; done --[[Joey]] - ->> Reopening, see comment. --[[Joey]] - ->>> Fixed again, [[done]] --[[Joey]] diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_1_724e68d2980fd28fa39707692bf22520._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_1_724e68d2980fd28fa39707692bf22520._comment deleted file mode 100644 index 31a1897f6..000000000 --- a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_1_724e68d2980fd28fa39707692bf22520._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-10T16:30:04Z" - content=""" -annex.gnupg-options is only used when encrypting content, not when -decrypting. And it has to decrypt the shared encryption key first, -so that's why the error shows it was running gpg with --decrypt. - -Probable, even if you were able to make it always run gpg with ---no-tty, it wouldn't help, because gpg needs to prompt for a passphrase. - -There should be a way to get gnupg to use gpg-agent, which would let it -prompt for your password with a dialog box, rather than trying to prompt on -the terminal. That would work better with the webapp. - -I do think there ought to be a config setting that allows passing options -to gpg when it's decrypting things, and so I'll add something. -"""]] 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 deleted file mode 100644 index d37bb993d..000000000 --- a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_2_e5bc3c7cbe4af61868ac8163cd39c11a._comment +++ /dev/null @@ -1,40 +0,0 @@ -[[!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? - - -"""]] diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment deleted file mode 100644 index 13684cb8c..000000000 --- a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_3_4bb4bed22dc8dcc0308a557d3dae76e4._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-23T18:21:16Z" - content=""" -The gpg calls in that log are being done by git-annex, not by -git-remote-gcrypt. - -I think this is decryptCipher, which can run gpg --decrypt and didn't -get annex.gnupg-decrypt-options wired up to it. Although normally the -creds would be cached when the special remote is set up or the first time -it's used and should not need to be decrypted again. - -Threading gnupg-decrypt-options through to decryptCipher looks likely to -involve nearly a full day's work. -"""]] diff --git a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment b/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment deleted file mode 100644 index e5ae7500b..000000000 --- a/doc/bugs/annex.gnupg-options_not_used_by_assistant/comment_4_60246ce3751486ed0f3b761fa8ac5ce8._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-05-23T21:06:53Z" - content=""" -Yeah, that was 2 thousand lines of fun patch.. - -I'm nearly 100% sure that every place git-annex calls gpg will pass the -configured options now. -"""]] diff --git a/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn b/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn deleted file mode 100644 index 5da5bce6c..000000000 --- a/doc/bugs/annex.hardlink_no_longer_set_on_init_of_shared_repo.mdwn +++ /dev/null @@ -1,27 +0,0 @@ -### Please describe the problem. - -In an earlier git-annex version (5.20141125, at least on debian), `git clone --shared` followed by `git annex init` used to set annex.hardlink to true and mark the repository as untrusted. It no longer does that. - -### What steps will reproduce the problem? - -(Assuming "foo" is a pre-existing repo with an annex) - - git clone --shared foo foo.shared - cd foo.shared - git annex init - git config annex.hardlink - -### What version of git-annex are you using? On what operating system? - -5.20150824, Debian Jessie. Tried both the debian unstable package and direct cabal build. - -### Please provide any additional information below. - -I haven't really debugged this, but it seems that `git annex init` nowadays does some syncing (i.e. commits, i.e. objects) that it didn't used to. The hard link check tests that the current repository has alternates, but doesn't have local objects. It might be that the newly created local objects prevent the hard link check from passing. Perhaps the hard link test should only check the presence of alternates? - -### 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) - -Sure, it's a great tool! - -> Seems that bit rotted at some point. I've fixed it, and put in a test -> case. [[done]] --[[Joey]] diff --git a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn b/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn deleted file mode 100644 index 5db40f4dd..000000000 --- a/doc/bugs/annex_add_ignores_.-prefixed_directories.mdwn +++ /dev/null @@ -1,78 +0,0 @@ -### Please describe the problem. - -annex add seems to ignore content under directories having . prefix. - -We thought to unify (across direct/indirect/v6) adding files to annex repository by using 'git annex add' with corresponding setting for largefiles for any addition, but it seems to ignore content under .-prefixed directories, unlike git - -### What version of git-annex are you using? On what operating system? - -6.20161122+gitg9f179ae-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ -hopa:/tmp/datalad_temp_test_annex_add_no_dotfilesqMXck8 -$> git status -On branch master - -Initial commit - -nothing to commit (create/copy files and use "git add" to track) - -$> mkdir .dir dir; echo 123 > .dir/123; echo 124 > dir/124 - -$> git status -On branch master - -Initial commit - -Untracked files: - (use "git add <file>..." to include in what will be committed) - - .dir/ - dir/ - -nothing added to commit but untracked files present (use "git add" to track) - -$> git annex add -c 'annex.largefiles=nothing' . -add dir/124 (non-large file; adding content to git repository) ok -(recording state in git...) - -$> git status -On branch master - -Initial commit - -Changes to be committed: - (use "git rm --cached <file>..." to unstage) - - new file: dir/124 - -Untracked files: - (use "git add <file>..." to include in what will be committed) - - .dir/ - - -# and with regular git -$> git -c 'annex.largefiles=nothing' add . - -$> git status -On branch master - -Initial commit - -Changes to be committed: - (use "git rm --cached <file>..." to unstage) - - new file: .dir/123 - new file: dir/124 - - -"""]] - -Ref: https://github.com/datalad/datalad/issues/1027 - -[[!meta author=yoh]] - -[[done]]; oh -- it is RTFM: --include-dotfiles --[[yoh]] diff --git a/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn b/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn deleted file mode 100644 index 9ecab381f..000000000 --- a/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp.mdwn +++ /dev/null @@ -1,131 +0,0 @@ -### Please describe the problem. - -Need to annex some files from a http link which forwards to ftp. addurl works out fine (besides not carrying about redirected filename), but drop fails to verify presence of the file - - -### What version of git-annex are you using? On what operating system? - -6.20160706+gitgc4229be-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ -smaug:/tmp -$> mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) -1 10080.....................................:Tue 12 Jul 2016 02:18:46 PM EDT:. -(git)smaug:/tmp/123[master] -$> git annex addurl --debug --pathdepth=-1 http://www.nitrc.org/frs/downloadlink.php/1637 -[2016-07-12 14:18:54.8195] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2016-07-12 14:18:54.83021] process done ExitSuccess -[2016-07-12 14:18:54.830357] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-07-12 14:18:54.841375] process done ExitSuccess -[2016-07-12 14:18:54.841694] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..787586641a9027e772b91989eb649cb9303cd975","--pretty=%H","-n1"] -[2016-07-12 14:18:54.851263] process done ExitSuccess -[2016-07-12 14:18:54.852043] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2016-07-12 14:18:54.862122] read: quvi ["--version"] -[2016-07-12 14:18:54.869939] process done ExitSuccess -[2016-07-12 14:18:54.870062] call: quvi ["--verbosity","mute","--support","http://www.nitrc.org/frs/downloadlink.php/1637"] -[2016-07-12 14:18:54.891339] process done ExitFailure 65 -addurl 1637 (downloading http://www.nitrc.org/frs/downloadlink.php/1637 ...) -[2016-07-12 14:18:55.830611] call: wget ["-q","--show-progress","--clobber","-c","-O","/tmp/123/.git/annex/tmp/URL--http&c%%www.nitrc.org%frs%downloadlink.php%1637","http://www.nitrc.org/frs/downloadlink.php/1637","--user-agent","git-annex/6.20160706+gitgc4229be-1~ndall+1"] -1637 100%[===========================================================================================>] 268.32M 12.9MB/s in 27s -[2016-07-12 14:19:31.32811] process done ExitSuccess -[2016-07-12 14:19:31.328909] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","annex.largefiles","--"] -[2016-07-12 14:19:31.329444] read: git ["--version"] -[2016-07-12 14:19:31.338195] process done ExitSuccess -[2016-07-12 14:19:31.338947] read: sha256sum [".git/annex/tmp/URL--http&c%%www.nitrc.org%frs%downloadlink.php%1637"] -[2016-07-12 14:19:32.860187] process done ExitSuccess -ok -(recording state in git...) -[2016-07-12 14:19:32.872749] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] -[2016-07-12 14:19:32.890096] process done ExitSuccess -[2016-07-12 14:19:32.890573] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] -[2016-07-12 14:19:32.891376] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"] -[2016-07-12 14:19:32.901206] process done ExitSuccess -[2016-07-12 14:19:32.901288] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-07-12 14:19:32.909396] process done ExitSuccess -[2016-07-12 14:19:32.909691] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"] -[2016-07-12 14:19:32.91827] process done ExitSuccess -[2016-07-12 14:19:32.918324] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","6c1ce1871151c12f6930733e7693eac2fd862677","--no-gpg-sign","-p","refs/heads/git-annex"] -[2016-07-12 14:19:32.927217] process done ExitSuccess -[2016-07-12 14:19:32.927281] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","2453a1c23977e4f17ac5fd9668cdc7bdb93e34e8"] -[2016-07-12 14:19:32.936074] process done ExitSuccess -cached/staged changes: - 1637 | 1 + -1 10081.....................................:Tue 12 Jul 2016 02:19:32 PM EDT:. -(git)smaug:/tmp/123[master] -$> git commit -m 'added' -[master (root-commit) b212851] added - 1 file changed, 1 insertion(+) - create mode 120000 1637 -1 10082.....................................:Tue 12 Jul 2016 02:19:38 PM EDT:. -(git)smaug:/tmp/123[master]git -$> git annex drop 1637 -drop 1637 (checking http://www.nitrc.org/frs/downloadlink.php/1637...) (unsafe) - Could only verify the existence of 0 out of 1 necessary copies - - Rather than dropping this file, try using: git annex move - - (Use --force to override this check, or adjust numcopies.) -failed -git-annex: drop: 1 failed -1 10083 ->1.....................................:Tue 12 Jul 2016 02:19:48 PM EDT:. -(git)smaug:/tmp/123[master]git -$> wget -S http://www.nitrc.org/frs/downloadlink.php/1637 ---2016-07-12 14:19:54-- http://www.nitrc.org/frs/downloadlink.php/1637 -Resolving www.nitrc.org (www.nitrc.org)... 132.239.16.23 -Connecting to www.nitrc.org (www.nitrc.org)|132.239.16.23|:80... connected. -HTTP request sent, awaiting response... - HTTP/1.1 302 Found - Date: Tue, 12 Jul 2016 18:19:54 GMT - Server: Apache/2.2.15 (CentOS) - X-Powered-By: PHP/5.3.3 - Set-Cookie: PHPSESSID=vhcpo1fmi205cfv0h4jgbnn9a0; path=/ - Expires: Thu, 19 Nov 1981 08:52:00 GMT - Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 - Pragma: no-cache - Location: ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar - Content-Length: 0 - Keep-Alive: timeout=2, max=100 - Connection: Keep-Alive - Content-Type: text/html; charset=UTF-8 -Location: ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar [following] ---2016-07-12 14:19:55-- ftp://www.nitrc.org/fcon_1000/htdocs/Ontario.tar - => ‘Ontario.tar’ -Connecting to www.nitrc.org (www.nitrc.org)|132.239.16.23|:21... connected. -Logging in as anonymous ... -220 (vsFTPd 2.2.2) ---> USER anonymous - -331 Please specify the password. ---> PASS Turtle Power! - -230 Login successful. ---> SYST - -215 UNIX Type: L8 ---> PWD - -257 "/" ---> TYPE I - -200 Switching to Binary mode. ---> CWD /fcon_1000/htdocs - -250 Directory successfully changed. ---> SIZE Ontario.tar - -213 281354240 ---> PASV - -227 Entering Passive Mode (132,239,16,23,106,251). ---> RETR Ontario.tar - -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp/comment_1_b16b58ac5180be6c7f61a1cf8de55663._comment b/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp/comment_1_b16b58ac5180be6c7f61a1cf8de55663._comment deleted file mode 100644 index 54a670b99..000000000 --- a/doc/bugs/annex_drop_fails_to_determine_availability_on_a_http_url_redirecting_to_ftp/comment_1_b16b58ac5180be6c7f61a1cf8de55663._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-12T20:00:49Z" - content=""" -This only affects http to ftp redirects, because there's a special hack -in place to use curl to check if a ftp url exists. - -Seems that http-conduit throws a StatusCodeException with statusCode = 302 -when it is redirected to a protocol that it does not support, such as ftp. - -So, it can catch that exception and fall back to curl. -"""]] diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn deleted file mode 100644 index 2ce7c1899..000000000 --- a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed.mdwn +++ /dev/null @@ -1,66 +0,0 @@ -### Please describe the problem. - -Usecase (you might suggest a better way) is to 'annex' the content of files (via addurl) without actually committing symlinks to git (git-annex branch obviously should progress forward). So the sequence is akin 'annex addurl', 'annex drop' both ran with annex.alwayscommit=false . The issue is that it seems that if addurl is --batched, then symlink is not 'git add'ed until batched process finishes, and thus subsequent to 'addurl' 'drop' does nothing, leaving key behind not dropped. - -Related recent TODO wishlist is [[http://git-annex.branchable.com/todo/drop_--batch/]] - -### What steps will reproduce the problem? - -FWIW below is a somewhat noisy output from datalad's unittest (which addurl into the archive's content, so custom special remote is involved). At the end of the run content is not dropped, symlink is not dangling. - -### What version of git-annex are you using? On what operating system? - -originally was a version from March but tried also with fresh 6.20160425+gitgffe2ea2-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -2016-04-26 14:13:05,545 [DEBUG ] Initiating a new process for BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1145) -2016-04-26 14:13:05,545 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'addurl', '--with-files', '--json', '--batch'] (annexrepo.py:1148) -2016-04-26 14:13:05,548 [Level 5] Sending 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 .dataladMCsP4y/file.txt\n' to batched annex BatchedAnnex(annex_cmd='addurl', annex_options=['--with-files', '--json'], git_options=[], output_proc=<function>, path=<<'/home/yoh/.tmp/datala...>>) (annexrepo.py:1202) -2016-04-26 14:13:05,548 [Level 5] Done sending. (annexrepo.py:1210) -2016-04-26 14:13:05,869 [DEBUG] Importing the rest of datalad.__init__ (__init__.py:15) -2016-04-26 14:13:05,870 [DEBUG] Reading files: ['/etc/datalad/datalad.cfg', '/etc/xdg/datalad/config', '/home/yoh/.config/datalad/datalad.cfg', '.datalad/config'] (configparserinc.py:144) -2016-04-26 14:13:05,959 [DEBUG] UI set to ConsoleLog(out=<file>) (__init__.py:48) -2016-04-26 14:13:05,960 [DEBUG] UI set to UnderAnnexUI(out=<file>) (__init__.py:48) -2016-04-26 14:13:05,962 [DEBUG] Not initiating existing cache for the archives under /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives (archives.py:262) -2016-04-26 14:13:05,962 [Level 4] Sending 'VERSION 1' (base.py:312) -2016-04-26 14:13:05,962 [Level 4] Received ['PREPARE'] (base.py:312) -2016-04-26 14:13:05,962 [Level 4] Sending 'PREPARE-SUCCESS' (base.py:312) -2016-04-26 14:13:05,962 [Level 4] Received ['CLAIMURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312) -2016-04-26 14:13:05,963 [DEBUG] Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4' (base.py:316) -2016-04-26 14:13:05,963 [Level 4] Sending "DEBUG Claiming url 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'" (base.py:312) -2016-04-26 14:13:05,963 [Level 4] Sending 'CLAIMURL-SUCCESS' (base.py:312) -2016-04-26 14:13:05,963 [Level 4] Received ['CHECKURL', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312) -2016-04-26 14:13:05,964 [DEBUG] Current directory: /tmp/datalad_temp_tree_setupmRy8cc, url: dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4 (archives.py:163) -2016-04-26 14:13:05,964 [DEBUG] Initiating a new process for BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1145) -2016-04-26 14:13:05,964 [Level 5] Command: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', 'annex', 'contentlocation', '--batch'] (annexrepo.py:1148) -2016-04-26 14:13:05,967 [Level 5] Sending 'SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar\n' to batched annex BatchedAnnex(annex_cmd='contentlocation', annex_options=[], git_options=[], output_proc=<function>, path=<<'/tmp/datalad_temp_tre...>>) (annexrepo.py:1202) -2016-04-26 14:13:05,967 [Level 5] Done sending. (annexrepo.py:1210) -2016-04-26 14:13:06,007 [Level 5] Received output: '.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar' (annexrepo.py:1220) -2016-04-26 14:13:06,008 [Level 4] Sending 'CHECKURL-CONTENTS 4' (base.py:312) -2016-04-26 14:13:06,009 [Level 4] Received ['TRANSFER', 'RETRIEVE', 'URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61', '.git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61'] (base.py:312) -2016-04-26 14:13:06,009 [INFO] RETRIEVE key URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 into/from .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (base.py:429) -2016-04-26 14:13:06,009 [Level 4] Sending 'GETURLS URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 dl+archive:' (base.py:312) -2016-04-26 14:13:06,011 [Level 4] Received ['VALUE', 'dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312) -2016-04-26 14:13:06,011 [Level 4] Received ['VALUE'] (base.py:312) -2016-04-26 14:13:06,011 [Level 4] Received URLS: ['dl+archive:SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/1/file.txt#size=4'] (base.py:312) -2016-04-26 14:13:06,011 [DEBUG] Getting file 1/file.txt from /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar while PWD=/tmp/datalad_temp_tree_setupmRy8cc (archives.py:299) -2016-04-26 14:13:06,011 [DEBUG] Requested file 1/file.txt from archive /tmp/datalad_temp_tree_setupmRy8cc/.git/annex/objects/7p/mj/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar/SHA256E-s10240--0d52ce580b5ea9324dfc2ac7c714130f02499439e6b990282adb6580a97fe1d0.tar (archives.py:454) -2016-04-26 14:13:06,012 [Level 2] Verifying that /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt exists (archives.py:462) -2016-04-26 14:13:06,012 [DEBUG] Hardlinking /tmp/datalad_temp_tree_setupmRy8cc/.git/datalad/tmp/archives/60e44d2ccc/1/file.txt under .git/annex/tmp/URL-s4--dl,43archive&cSHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61 (cmd.py:372) -2016-04-26 14:13:06,012 [Level 2] Hardlinking finished (cmd.py:382) -2016-04-26 14:13:06,012 [Level 4] Sending 'TRANSFER-SUCCESS RETRIEVE URL-s4--dl,43archive:SHA256E-s10240--0d-d5401228f11172416c78bab2f3f31f61' (base.py:312) -2016-04-26 14:13:06,022 [Level 5] Received output: {u'note': u'from datalad-archives', u'success': True, u'command': u'addurl', u'key': u'SHA256E-s4--0cf67fc72b3c86c7a454f6d86b43ed245a8e491d0e5288d4da8c7ff43a7bcdb0.txt', u'file': u'.dataladMCsP4y/file.txt'} (annexrepo.py:1220) -2016-04-26 14:13:06,023 [DEBUG ] Running: ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] (cmd.py:351) -2016-04-26 14:13:06,075 [ERROR ] stderr| [2016-04-26 14:13:06.069266] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--cached","-z","--",".dataladMCsP4y/file.txt"] (cmd.py:351) -2016-04-26 14:13:06,075 [Level 8] Finished running ['git', '-c', 'receive.autogc=0', '-c', 'gc.auto=0', '-c', 'annex.alwayscommit=false', 'annex', 'drop', '--debug', '.dataladMCsP4y/file.txt'] with status 0 (cmd.py:351) -t sh - -"""]] - - -[[!meta author=yoh]] - -> [[done]] per comments --[[Joey]] diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment deleted file mode 100644 index 038363365..000000000 --- a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_1_925a6333ed6d19e4446c02829dae3aa2._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-27T17:22:03Z" - content=""" -git-annex commands only operate on files that are checked into the git -repsitory, which is why drop skips this file that has not been staged yet. -I do not think it makes sense to change that. - -git-annex addurl batches changes to the index, which can speed up its -performance significantly when adding a lot of files. So until it's done -you can't operate on the files it adds. That speedup is really the only -reason to use addurl --batch, so it doesn't make sense to change it to not -have that optiomisation, otherwise you could just use it in non-batch mode -and drop after it's done. - -So, if you want to drop files as soon as addurl adds them, you need to -either not batch addurl, or you need to drop not by the name of the file -that has not need checked into git yet, but by the key. - -So, I think it would make sense for you to use dropkey in this case. -`git annex addurl --json --batch` already includes the key, -so you can just pass that along to `git annex dropkey --batch` - -(Do note though that dropkey doesn't verify that other copies exist..) -"""]] diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment deleted file mode 100644 index 30bdec48e..000000000 --- a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_2_c6fa80900ca1683a78b5dbdf4affcc80._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-04-29T13:21:04Z" - content=""" -ok, so it is non-fixable reality due to having separate 'annex COMMAND --batch' processes (instead of a single annex --batch process which could accept/carry different COMMANDs with their parameters... I think we had discussion somewhere before). -Ok -- I will workaround (actually for now I have worked around by collecting all files to be dropped and doing that after annex addurl process finishes, but dropkey --batch sounds better for this usecase) -"""]] diff --git a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_3_e644ef3be185a88f9471584428b32653._comment b/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_3_e644ef3be185a88f9471584428b32653._comment deleted file mode 100644 index a19a249ed..000000000 --- a/doc/bugs/annex_drop_is_not___34__in_effect__34___for_load_which_was___34__addurl_--batch__34__ed_but_not_yet_committed/comment_3_e644ef3be185a88f9471584428b32653._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-03T17:45:39Z" - content=""" -Having a unified batch process wouldn't actually help at all, -unless it forced flushing the caches when switching between -eg, addurl and drop commands. Which would get right back to it being -unnecessary slow, and so negate the benefits of batching. - -So, I agree, this can't really be improved. -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn b/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn deleted file mode 100644 index c6d0710d1..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### Please describe the problem. - -annex get does not work from read-only file systems... - -### What steps will reproduce the problem? - - $ git annex get --from=... - error: could not lock config file /.../Annex/.git/config: Read-only file system - get ... (from ...) error: could not lock config file .../Annex/.git/config: Read-only file system - git [Param "config",Param "annex.version",Param "5"] failed - failed - -### What version of git-annex are you using? On what operating system? - -annex.version = 3 in the remote - - $ git annex version - git-annex version: 5.20140927 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL - remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - -[[!tag confirmed]] -[[!meta title="read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote"]] - -> [[done]]; Fixed for V3 mode and rejected trying to support all old -> versions without a repo-changing upgrade process. --[[Joey]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment deleted file mode 100644 index 9fadf817f..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_1_d8ab07429195c06ec4fae199ca9e0764._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.54" - subject="comment 1" - date="2014-10-06T15:11:18Z" - content=""" -There might be a general problem with using git-annex against a read-only filesystem, but the specific case here is a read-only filesystem containing a repository in an old format which git-annex needs to upgrade to the current format to use. So it's pretty reasonable that the (automatic) upgrade fails, since it's not being allowed to write to the repository to upgrade it. - -Now, if that repository is a indirect mode repo, there is really no change between version 3 and version 5, so it might do to let git-annex ignore the failure to write out the config, and treat that repo as if it's a v5 repo. It seems easier in most cases to mount the media read-write for git-annex to do the upgrade though. -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment deleted file mode 100644 index 4bd0bce59..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_2_03c16df9d6c14e1529c5dc8b5fc49691._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://id.koumbit.net/anarcat" - ip="72.0.72.144" - subject="comment 2" - date="2014-10-06T15:18:20Z" - content=""" -i've seen problems like this not related to upgrades at all, in [[todo/read-only removable drives]]. furthermore, it seems to me that failure to upgrade a repository shouldn't be fatal and we should be able to recover and get files anyways, in the spirit of [[backwards compatibility|future_proofing]]. --[[anarcat]] -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment deleted file mode 100644 index 3fd24eb67..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_3_c505a9df0ef63bb7cac28af9502a953d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.54" - subject="comment 3" - date="2014-10-06T15:59:10Z" - content=""" -From a code complication POV, it's useful for git-annex to only support one version of repository at a time. - -As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex. It still supports upgrading v0 repos which probably only I ever used! -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment deleted file mode 100644 index 8543aaad7..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_4_2491fabe2eb7a14bfef0e388b4b9c4c7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - ip="70.83.139.100" - subject="comment 4" - date="2014-10-30T15:22:32Z" - content=""" -the problem here is that it upgrading the repo will not work on a readonly filesystem, so we can't upgrade, we can't get files, so we can't sync. - -we should be able to sync anyways - can't we try our best shot at getting files even without upgrading the metadata? i mean i'm looking for something in .git/annex/objects/, maybe i don't care about tracking so much - i just want to recover some files... -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment deleted file mode 100644 index 24b7dd118..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_5_07f612d7059a9b561c48d63e471d5ed7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://jaen.saul.ee/id/" - nickname="Jaen" - subject="Re: why this happened" - date="2014-10-30T19:04:56Z" - content=""" -I agree that at least read-only support should be there. This error was from an filesystem type that is impossible to mount read-write. - -Now that I am looking at it again with fresh eyes, I suppose it's possible to get around this by mounting an union filesystem with a read-write temp layer on top of the read-only one (not that a regular user would ever figure that out...) -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment deleted file mode 100644 index fac28c24d..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_6_c469f1fe8ae6981a038be7f8723a07b1._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2014-10-31T16:55:47Z" - content=""" -An upgrade could move the annexed objects around. -"""]] diff --git a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment b/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment deleted file mode 100644 index 25464816e..000000000 --- a/doc/bugs/annex_get_fails_from_read-only_filesystem/comment_7_864d4b5c207dce19d017b3e7608531f8._comment +++ /dev/null @@ -1,52 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-10-05T20:29:56Z" - content=""" -I've made V3 repositories be supported to use without an upgrade, so -that fixes the specific case this bug report was filed about. - ----- - -I do not, however, want to commit to git-annex supporting use of all past -repo versions without an upgrade process. The point of the upgrade process -is to keep code complication down. - -All the code that knows about V1 is in Upgrade.V1, and the rest of -git-annex does not need to check the repo version when doing things -with annex objects in order to support the different V1 location. -Supporting accessing content from V1 repositories without an upgrade would -lose this clean separation and complicate an unknown number of places in -git-annex. And any of those places that would have to include a check to -handle V1 would be liable to break as the code was changed, without anyone -except the rare V1 user likely to notice. - -V1 was the last upgrade to change the locations of annexed objects, and -there's now the tuning interface that might be used for such future -location changes, but that's not the only kind of change that an upgrade -might deal with, and making a commitment that all future versions of -git-annex will support getting annexed objects from V5 (and V6 and V3) -would really narrow down the kinds of changes that could ever be made to -the git annex repository format, and I don't want to do that. - -Supporting upgrades from all past versions is sufficient for future -proofing. It doesn't guarantee super easy use of an old repo from some old -version of git-annex. - -... You might have to copy it from its original rusty -media to some tiny corner of a far-future storage crystal, in order for -git-annex to be able to write to the repository when it upgrades to V7 -without disturbing the original rusty media. - -.. And git-annex may need to do arbitrary amounts of work, since V7 turned -out to also entail a switch from the broken-in-2100 SHA2 to a new -quantum-computer-safe hash. - -.. And git may also need to do similar work to upgrade the old repository -from the (broken-in-2010) SHA1 to its new hash. (Hopefully git will support -upgrading from old repo versions at least as well as git-annex does!) - -The important thing is to have a upgrade path that is guaranteed to -be supported all the way into the future, and I've made the best choices I -can to ensure that. -"""]] diff --git a/doc/bugs/annex_symlinks_too.mdwn b/doc/bugs/annex_symlinks_too.mdwn deleted file mode 100644 index ade91650b..000000000 --- a/doc/bugs/annex_symlinks_too.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -Hi, - -Because git annex doesn't annex symlinks, it is not possible to copy files from the a repository with a simple cp/rsync dereferencing each files. If we do this as of today, we would lose the original symlink information. -Would it be possible to change this behavior in the future, at least with an option? - -Thanks - -> Not going to happen, sorry. [[done]] --[[Joey]] diff --git a/doc/bugs/annex_symlinks_too/comment_1_d2a7a011f8c584b37ff4df62ff7e5a41._comment b/doc/bugs/annex_symlinks_too/comment_1_d2a7a011f8c584b37ff4df62ff7e5a41._comment deleted file mode 100644 index c7583eb06..000000000 --- a/doc/bugs/annex_symlinks_too/comment_1_d2a7a011f8c584b37ff4df62ff7e5a41._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-14T19:14:28Z" - content=""" -Since git natively supports symlinks, adding a whole separate -implementation of them in git-annex would be a needless complication. - -You could instead use a direct mode repository, or unlocked files in a v6 -repository. Either avoids the symlinks so you don't need to dereference -your cp. -"""]] diff --git a/doc/bugs/annex_symlinks_too/comment_2_20ccc26b97a064075a4d0256f2287be6._comment b/doc/bugs/annex_symlinks_too/comment_2_20ccc26b97a064075a4d0256f2287be6._comment deleted file mode 100644 index a44894f1c..000000000 --- a/doc/bugs/annex_symlinks_too/comment_2_20ccc26b97a064075a4d0256f2287be6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="jody.frankowski@46af27a91b08450190f627a8fba772a61e22719f" - nickname="jody.frankowski" - subject="comment 2" - date="2016-02-14T20:31:49Z" - content=""" -Both direct mode and unlocking are costly. Enabling annexing of symlinks is a very useful optimisation imho, and very important mechanism going forward with v6 repos. -"""]] diff --git a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__.mdwn b/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__.mdwn deleted file mode 100644 index c7668a21e..000000000 --- a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. - -Might be just my ignorance in how the world spins ;) But if I enclose the largefiles config option passed to annex within e.g. "" within cmdline while having additional '' in the value (e.g. -c "annex.largefiles='exclude=*.txt'" ) annex fails (see below). I thought that those surrounding "s are stripped off by the shell while passing those into the actual command call (and my little python script somewhat confirms it, tried also with bash), but somehow it does affect annex, leading it to Parse failure: near "'exclude=*.txt'". It resolves if surrounding 's are removed. - -Could someone lead me out of this wilderness?? - -### What steps will reproduce the problem? - -see transcript below - -### What version of git-annex are you using? On what operating system? - -5.20150916+gitg79661ef-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -$> cat /tmp/1.py -#!/usr/bin/python - -import sys - - -for arg in sys.argv: - print "arg: %r" % arg -(git)/home/yoh/datalad/crawl/openfmri/ds000005:[master] - - -$> /tmp/1.py 'git-annex' 'add' '-c' "annex.largefiles='exclude=*.txt'" 'license3.txt' -arg: '/tmp/1.py' -arg: 'git-annex' -arg: 'add' -arg: '-c' -arg: "annex.largefiles='exclude=*.txt'" -arg: 'license3.txt' - -*$> 'git-annex' 'add' '-c' "annex.largefiles='exclude=*.txt'" 'license3.txt' -git-annex: bad annex.largefiles configuration: Parse failure: near "'exclude=*.txt'" - -*$> 'git-annex' 'add' '-c' annex.largefiles='exclude=*.txt' 'license3.txt' -add license3.txt (non-large file; adding content to git repository) ok -(recording state in git...) - -"""]] - - - - -> [[done]] per comment --[[Joey]] diff --git a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_1_7ab34ddaef82c3037cea96b6552f0da4._comment b/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_1_7ab34ddaef82c3037cea96b6552f0da4._comment deleted file mode 100644 index b2343be70..000000000 --- a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_1_7ab34ddaef82c3037cea96b6552f0da4._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-03T16:14:03Z" - content=""" -You have successfully passed the literal value `'exclude=*.txt'` to -git-annex as the annex.largefiles setting. - -Now, git-annex has to parse that value to understand what files you intend -it to treat as large. - -Since its preferred content expression parser for the value has no -concept of quoting characters, it fails as shown. - -There's no magic here, just you providing a value to git-annex that it does -not understand. - -Were you trying to accomplish anything in particular with `'exclude=*.txt'` -that is different from the behavior with `exclude=*.txt`? - -(Eg, perhaps you're really trying to exclude a filename with a space in it, -like `*.brain scan` and that seems to call for some form of quoting. Adding -quoting support into git-annex's preferred content expressions would -complicate the parser a lot though. So, in that case, I'd suggest the -workaround of using `*.brain?scan`) -"""]] diff --git a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_2_530eee55ac4f4dfda0d44148249022ed._comment b/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_2_530eee55ac4f4dfda0d44148249022ed._comment deleted file mode 100644 index be38556b0..000000000 --- a/doc/bugs/any___34__magical__34___cmdline_args_parsing_done_by_annex_leading_to_the_failure_of_parsing_options__63__/comment_2_530eee55ac4f4dfda0d44148249022ed._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-11-03T16:34:39Z" - content=""" -Thank you Joey. I guess my ignorance was in the fact that shell removes those 's if the argument itself is not wrapped: - - - $> /tmp/1.py git annex add -c annex.largefiles='exclude=*.txt' README2.txt - arg: '/tmp/1.py' - arg: 'git' - arg: 'annex' - arg: 'add' - arg: '-c' - arg: 'annex.largefiles=exclude=*.txt' - arg: 'README2.txt' - -Consider it resolve for nowbeing ;) Cheers -"""]] diff --git a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1.mdwn b/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1.mdwn deleted file mode 100644 index dd544d7c7..000000000 --- a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -### Please describe the problem. -missing libselinux.so.1 ? - -### What steps will reproduce the problem? -[[!format sh """ -./runshell -cd ~ -$ git clone ssh://greg@host/path/to/annex/of/Photos Photos -Cloning into 'Photos'... -ssh: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. -"""]] - -same command (copy/paste) works on my laptop running 4.20131106 - -### What version of git-annex are you using? On what operating system? -[[!format sh """ -$ git annex version -git-annex version: 5.20131216-g604e6b8 -build flags: Assistant Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web glacier hook -"""]] - -arm build (downloaded from [[install/Linux_standalone]]) - -> ssh was not shimmed. [[fixed|done]]; build will update in a few hours -> --[[Joey]] diff --git a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_1_ccc2c90d05862edda9ce1ac92efab516._comment b/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_1_ccc2c90d05862edda9ce1ac92efab516._comment deleted file mode 100644 index 3691b8a8a..000000000 --- a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_1_ccc2c90d05862edda9ce1ac92efab516._comment +++ /dev/null @@ -1,44 +0,0 @@ -[[!comment format=mdwn - username="http://grossmeier.net/" - nickname="greg" - subject="comment 1" - date="2013-12-19T19:05:04Z" - content=""" -Just tried again (redownloaded the build at ~11:50am Pacific on Dec 19th), same behavior: - -[[!format sh \"\"\" -$ git-annex version -git-annex version: 5.20131218-gc5767e2 -build flags: Assistant Pairing S3 Inotify DBus XMPP Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web glacier hook -$ git clone greg@host:/path/to/Photos Photos -Cloning into 'Photos'... -ssh: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. -$ which ssh -/volume1/downloads/git-annex.linux/bin/ssh -$ ldd /volume1/downloads/git-annex.linux/bin/ssh -/volume1/downloads/git-annex.linux/bin/ssh: /lib/libc.so.6: version `GLIBC_2.15' not found (required by /volume1/downloads/git-annex.linux/bin/ssh) -/volume1/downloads/git-annex.linux/bin/ssh: /lib/libc.so.6: version `GLIBC_2.8' not found (required by /volume1/downloads/git-annex.linux/bin/ssh) -/volume1/downloads/git-annex.linux/bin/ssh: /lib/libc.so.6: version `GLIBC_2.17' not found (required by /volume1/downloads/git-annex.linux/bin/ssh) -/volume1/downloads/git-annex.linux/bin/ssh: /lib/libcrypto.so.1.0.0: no version information available (required by /volume1/downloads/git-annex.linux/bin/ssh) -/volume1/downloads/git-annex.linux/bin/ssh: /lib/libcrypto.so.1.0.0: no version information available (required by /volume1/downloads/git-annex.linux/bin/ssh) - libselinux.so.1 => not found - libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x40026000) - libdl.so.2 => /lib/libdl.so.2 (0x401ba000) - libz.so.1 => /lib/libz.so.1 (0x401c5000) - libresolv.so.2 => /lib/libresolv.so.2 (0x401e2000) - libgssapi_krb5.so.2 => /lib/libgssapi_krb5.so.2 (0x401fc000) - libc.so.6 => /lib/libc.so.6 (0x40235000) - /lib/ld-linux.so.3 (0x40000000) - libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40364000) - libkrb5.so.3 => /lib/libkrb5.so.3 (0x40378000) - libk5crypto.so.3 => /lib/libk5crypto.so.3 (0x40426000) - libcom_err.so.3 => /lib/libcom_err.so.3 (0x40458000) - libkrb5support.so.0 => /lib/libkrb5support.so.0 (0x40462000) -\"\"\"]] -"""]] diff --git a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_2_1cdf6de88c7f121c604177593915e626._comment b/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_2_1cdf6de88c7f121c604177593915e626._comment deleted file mode 100644 index 55e48f0e7..000000000 --- a/doc/bugs/arm_build__58___ssh__58___error_while_loading_shared_libraries__58___libselinux.so.1/comment_2_1cdf6de88c7f121c604177593915e626._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.87" - subject="comment 2" - date="2013-12-19T19:55:33Z" - content=""" -Build took longer than I thought, but should finally be done in an hour or two. -"""]] diff --git a/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed.mdwn b/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed.mdwn deleted file mode 100644 index 317b9fcda..000000000 --- a/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -### Please describe the problem. -When syncing from server A (real server) to server B (a synology NAS) it fails on git-upload-pack and -receive-pack - -### What steps will reproduce the problem? -git-annex sync - - -### What version of git-annex are you using? On what operating system? -on server A: 3.20121017 (yeah, I should update) -on server B: 5.20131220-g73492b2 - -### Please provide any additional information below. - -On server B, after running ./runshell -[[!format sh """ -$ git-upload-pack -/volume1/downloads/git-annex.linux/shimmed/sh/sh: 19: git-upload-pack: not found -$ git-receive-pack -/volume1/downloads/git-annex.linux/shimmed/sh/sh: 20: git-receive-pack: not found -"""]] - -> [[fixed|done]]; added git, git-upload-pack, and git-receive-pack wrappers -> to git-annex.linux/. Also to equivilant place in OSX app. --[[Joey]] diff --git a/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed/comment_1_403f1058c3eab5c95fefab5a96aa3f51._comment b/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed/comment_1_403f1058c3eab5c95fefab5a96aa3f51._comment deleted file mode 100644 index 65d8d0667..000000000 --- a/doc/bugs/armel_standalone__58___git-upload-pack_and_-receive-pack_not_shimmed/comment_1_403f1058c3eab5c95fefab5a96aa3f51._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 1" - date="2013-12-24T20:20:07Z" - content=""" -This has nothing to do with shimming at all AFACS. - -runshell does nothing to make git-upload-pack or git-receive-pack be in your PATH. They do not need to be, for `git upload-pack` and `git receive-pack` to work. At least `git-annex-shell`, and probably also `git-shell` both use the latter, rather than the former. - -But in the case that a git remote's ssh key is not set up to use git-annex-shell (ie, a git remote not configured using the assistant, or configured using the asistant but with a pre-existing passwordless ssh key), and git-annex was installed on the remote using the git-annex standalone bundle, and there is no other git installation, then yes, git will try to ssh to there and run `git-upload-pack` etc. -"""]] diff --git a/doc/bugs/assistant_-_GTalk_collision.mdwn b/doc/bugs/assistant_-_GTalk_collision.mdwn deleted file mode 100644 index a950dcdbc..000000000 --- a/doc/bugs/assistant_-_GTalk_collision.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -##What steps will reproduce the problem? - -Follow the [share with a friend walkthrough](http://git-annex.branchable.com/assistant/share_with_a_friend_walkthrough/). I use my Google Talk account to pair with myself. With the assistant running, log in to Google Talk on the web interface and set your status 'Invisible'. - -##What is the expected output? What do you see instead? - -I expect to remain invisible, but I get the following warning: "Oops! You are not invisible because you're logged into Google Talk from another client, device or location that doesn't support invisibility." - -##What version of git-annex are you using? On what operating system? - -4.20130314 on Linux. - -##Please provide any additional information below. - -Syncing between the repositories works ok. - -[[!tag /design/assistant]] - -> [[done]]; xmpp support has been removed. --[[Joey]] diff --git a/doc/bugs/assistant_-_GTalk_collision/comment_1_ab2c1f36113d40f27e1893d32f214296._comment b/doc/bugs/assistant_-_GTalk_collision/comment_1_ab2c1f36113d40f27e1893d32f214296._comment deleted file mode 100644 index 4e66052cf..000000000 --- a/doc/bugs/assistant_-_GTalk_collision/comment_1_ab2c1f36113d40f27e1893d32f214296._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://smcv.pseudorandom.co.uk/" - nickname="smcv" - subject="GTalk wants you to implement its "shared status" protocol" - date="2013-03-16T11:59:22Z" - content=""" -For invisibility to work, GTalk demands that every connected resource implements its \"shared status\" extension. Given that git-annex sets negative priority, this seems like a GTalk bug - it should ignore negative-priority resources when deciding whether it can be invisible - but it seems unlikely to be fixed. - -We implement shared status in telepathy-gabble (mostly in src/conn-presence.c, tests in tests/twisted/presence/shared-status.py) if it's any help. - -<http://code.google.com/apis/talk/jep_extensions/shared_status.html> -"""]] diff --git a/doc/bugs/assistant_-_GTalk_collision/comment_2_91dff34c629a3b3a97a2313ff077e4ae._comment b/doc/bugs/assistant_-_GTalk_collision/comment_2_91dff34c629a3b3a97a2313ff077e4ae._comment deleted file mode 100644 index 1fbbadb05..000000000 --- a/doc/bugs/assistant_-_GTalk_collision/comment_2_91dff34c629a3b3a97a2313ff077e4ae._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 2" - date="2013-03-16T15:39:14Z" - content=""" -Thanks for the link, that perhaps explains the continuing oddities I've seen with google talk and presence information sometimes not being sent. - -It's not clear to me if git-annex could use this extension at all. It seems to say that if I use it, my regular presence messages won't be sent. Which is a problem, since git-annex uses extended content in presence messages to indicate that they're coming from a git-annex client, which is important to make xmpp pairing work. (It's also used to send push notifications, but that's not essential.) - -Also, of course, I'm reluctant to implement a non-standard extension that may change at any time, especially when it's attached to a service that currently has the FSF unhappy <http://www.fsf.org/blogs/sysadmin/google-backslides-on-federated-instant-messaging-on-purpose>. - -Perhaps the real solution is to make the assistant encourage use of some other XMPP server. -"""]] diff --git a/doc/bugs/assistant_-_GTalk_collision/comment_3_fefb73f6e570f96b4d82779d6622f690._comment b/doc/bugs/assistant_-_GTalk_collision/comment_3_fefb73f6e570f96b4d82779d6622f690._comment deleted file mode 100644 index 35f76bc5f..000000000 --- a/doc/bugs/assistant_-_GTalk_collision/comment_3_fefb73f6e570f96b4d82779d6622f690._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - nickname="joey" - subject="comment 3" - date="2013-03-16T20:48:42Z" - content=""" -I don't know if it will help, but XA support was turned off in hope that it would alleviate the random presence message loss I keep seeing with Google Talk, and since it didn't seem to help solve that problem, I've turned it back on. -"""]] diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn deleted file mode 100644 index 6b4334728..000000000 --- a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -The bash-completion.bash was gone in the 6.20160527 tarball on hackage. It used to be inside the tarball in <= 6.20160511 versions. - -> not a bug; [[done]] --[[Joey]] diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment deleted file mode 100644 index d4964bfc3..000000000 --- a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_1_e8ed6b5705bf5fc7c3c85cee354b5bfd._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-31T15:56:20Z" - content=""" -The tarball on hackage is only there to make `cabal install git-annex` / -`stack install git-annex` -work, and that does not currently install the bash completion script. -So, it's omitted. - -If you're using the tarball for some other purpose, it's never been a -complete clone of git-annex, and it's rather less of one now, as documented -in the CHANGELOG for this release. I recommend cloning from git to get -the full source tree. -"""]] diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_2_98d3ddab5c384c8f49cdcbedbbd91d19._comment b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_2_98d3ddab5c384c8f49cdcbedbbd91d19._comment deleted file mode 100644 index 71132e1a7..000000000 --- a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_2_98d3ddab5c384c8f49cdcbedbbd91d19._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="felixonmars@643c7c1f0bf9bace16d293d69b51419f012234d1" - nickname="felixonmars" - subject="comment 2" - date="2016-05-31T16:36:05Z" - content=""" -I see, thanks. I was using the tarball to build packages for Arch. Now I have switched to a git clone. -"""]] diff --git a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_3_d6702813e04cd78c9ac04c5d0fbca187._comment b/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_3_d6702813e04cd78c9ac04c5d0fbca187._comment deleted file mode 100644 index f911a5dac..000000000 --- a/doc/bugs/bash_completion_file_is_missing_in_the_6.20160527_tarball_on_hackage/comment_3_d6702813e04cd78c9ac04c5d0fbca187._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-31T17:18:09Z" - content=""" -It could be that I made the wrong decision, but the tarball was being built -with hacks to include all those files before, and was still not complete -due to limits in what's allowed in tarballs on hackage. - -The Makefile will be removed from the tarball in the next release, -which should I think make it clearer that the tarball is not intended for a -`make install` situation. -"""]] diff --git a/doc/bugs/binary_package_not_working_on_macOS_Sierra.mdwn b/doc/bugs/binary_package_not_working_on_macOS_Sierra.mdwn deleted file mode 100644 index 3145720d4..000000000 --- a/doc/bugs/binary_package_not_working_on_macOS_Sierra.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. -I downloaded the 10.11_El_Capitan dmg package ( 2016-11-01 ) but it did not install on macOS Sierra. When I try to run it from command line I got this error: - - -/Volumes/git-annex/git-annex.app/Contents/MacOS/$ ./git-annex - -dyld: malformed mach-o: load commands size (35008) > 32768 - -Abort trap: 6 - - -I googled around and it seems to be a known issue with Haskell platform on the newer OS: -http://stackoverflow.com/a/39648502 - -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - - -> [[done]] (also, I updated the OSX build for the last release with this -> fix) --[[Joey]] diff --git a/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_1_d6142fd505af8e0522ef5667761b3f80._comment b/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_1_d6142fd505af8e0522ef5667761b3f80._comment deleted file mode 100644 index 51a354059..000000000 --- a/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_1_d6142fd505af8e0522ef5667761b3f80._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-07T17:59:14Z" - content=""" -`otool -l git-annex` shows hundreds of unnecessary RPATHs, removing -them should fix this. - -One way would be to use `install_name_tool -delete_rpath` for each -of them. - -It would be better to upgrade to a fixed ghc, -if it has fixed this RPATH mess. ghc 8.0.2 may fix it. -But the OSX autobuilder is using stack, and no stackage LTS or nightly -includes ghc 8.0.2 yet. - -Ok, I've put in the `install_name_tool -delete_rpath` workaround -for the dmg build. - -Bug reporter: Please see if -<https://downloads.kitenet.net/git-annex/autobuild/x86_64-apple-yosemite/git-annex.dmg> -has fixed the problem for you. -"""]] diff --git a/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_2_83f8bf6083abe19132f773e1c3c63cde._comment b/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_2_83f8bf6083abe19132f773e1c3c63cde._comment deleted file mode 100644 index e2f922070..000000000 --- a/doc/bugs/binary_package_not_working_on_macOS_Sierra/comment_2_83f8bf6083abe19132f773e1c3c63cde._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="public@881708f3cb16d1f967ca9f517a310dd211474013" - nickname="public" - avatar="http://cdn.libravatar.org/avatar/e60c5356a8001ac2a78b489d6ac3731c" - subject="joey's test build fixes issue" - date="2016-11-08T14:53:48Z" - content=""" -I was having the same issue on macOS Sierra (10.12.1). I downloaded your test build and that seems to have resolved the issue. - -Andrew -"""]] diff --git a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__.mdwn b/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__.mdwn deleted file mode 100644 index c25e6c57b..000000000 --- a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -I'm a user of git-annex for many years now (since the first stable releases) and I've always used it before on debian-like systems. I have now a gentoo OS where I have compiled git-annex. - - git-annex version: 6.20160419 - build flags: Assistant Webapp Pairing S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime EKG Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -I don't know if you exactly can solve my problem, as it may be related to haskell stuff, and not directly coming from git-annex code, so I barely hope some hints about the possible source of the problem. When I perform any git annex action (here a git annex sync), I get the following message in the cli: - - commit - Error on startup: - bind: resource busy (Address already in use) - git-annex: bind: resource busy (Address already in use) - ok - pull <ANNEX> - <etc...> - -Of course, the webapp has also troubles with this. My understanding of the phenomena is that only one git annex action can be performed at the time, so the rest of them crash or fail. Is my understanding correct, do you think? I can consequently, perform git annex actions, but only one at the time, and the whole thing feels unreliable. I suspect that the problem comes from the haskell compiler or platform, but I have no knowledge of haskell and I am consequently not really able to aim at what could be the problem. If you have an idea or some hints, I would be glad to hear from you, as that bug really comes in my way. I use git-annex for every bits of my computer life and that's really a handicap for me :-(. - -### Extract of .git/annex/daemon.log -[[!format sh """ - -[2016-06-19 17:41:57.98439] main: starting assistant version 6.20160419 -[2016-06-19 17:42:04.663738] TransferScanner: Syncing with hunbaut - - No known network monitor available through dbus; falling back to polling - - No known volume monitor available through dbus; falling back to mtab polling -(scanning...) [2016-06-19 17:42:04.833047] Watcher: Performing startup scan -Error on startup: -bind: resource busy (Address already in use) -git-annex: bind: resource busy (Address already in use) -RemoteControl crashed: user error (nice ["ionice","-c3","/usr/bin/git-annex","remotedaemon"] exited 1) -[2016-06-19 17:42:04.945745] RemoteControl: warning RemoteControl crashed: user error (nice ["ionice","-c3","/usr/bin/git-annex","remotedaemon"] exited 1) - - -"""]] - -### 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) - -Yeah, for years! Thank you so much for it :-) - -> [[done]] --[[Joey]] diff --git a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_1_3ab5f88ad72d57eb5bf0a8a85f2a3922._comment b/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_1_3ab5f88ad72d57eb5bf0a8a85f2a3922._comment deleted file mode 100644 index 3b45af3ba..000000000 --- a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_1_3ab5f88ad72d57eb5bf0a8a85f2a3922._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="jbc@de7e798914f9401f6187a9e3dce237ee4203fc22" - nickname="jbc" - subject="Any idea?" - date="2016-07-01T12:43:18Z" - content=""" -Anyone on this topic? -I'm still stuck with this issue with no clue about how to solve the problem :'-( -"""]] diff --git a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_2_69ae22ef702c1904124fe840cb531b47._comment b/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_2_69ae22ef702c1904124fe840cb531b47._comment deleted file mode 100644 index 65edc3508..000000000 --- a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_2_69ae22ef702c1904124fe840cb531b47._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-07-06T18:58:47Z" - content=""" -This looks suspiciously like git-annex has been built with the EKG flag -enabled. That is disabled by default and only useful for debugging -performace problems. When enabled, git-annex includes a EKG web server, -so only one git-annex program can be run at once. - -Please file a bug on the gentoo package to get EKG turned off, if it is in -fact enabled. - -You can check if it is by going to http://localhost:4242/ -while a git-annex command is running. Or, look at "git annex version" -and see if EKG is included in the list of flags. -"""]] diff --git a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_3_65488c9eacd5c007151e35504aab92c9._comment b/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_3_65488c9eacd5c007151e35504aab92c9._comment deleted file mode 100644 index 51181ad3f..000000000 --- a/doc/bugs/bind__58___resource_busy___40__Address_already_in_use__41__/comment_3_65488c9eacd5c007151e35504aab92c9._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-07-06T19:08:10Z" - content=""" -Good greif, gentoo really does enable the ekg build flag. - -Well, I removed the flag, I guess I need to be careful with exposing build -flags that are not for production use if there are distributions that -enable every possible flag willy-nilly. -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing.mdwn b/doc/bugs/box.com_never_stops_syncing.mdwn deleted file mode 100644 index d8e5391b5..000000000 --- a/doc/bugs/box.com_never_stops_syncing.mdwn +++ /dev/null @@ -1,74 +0,0 @@ -### Please describe the problem. -Git-annex will constantly sync most(if not all) my files to box.com - -### What steps will reproduce the problem? -1 - Use git-annex instead of Dropbox at work -2 - Boot computer. -3 - Watch it sync everything to box.com (even files i believe it has transferred each and every day for the last few months) - -### What version of git-annex are you using? On what operating system? -git-annex version: 4.20130827 - -But i have never seen it work satisfactory in any version. - -Also, i have seen this is 10+ different clean git-annexes. So it isn't annex specific. - -### Please provide any additional information below. - -I am going to add more debug to this bug constantly. (I intend to do a full 'git annex copy --to box.com --not --in box.com' daily, and see if the same files are transfered again and again) - - -For now, i see a few different issues already: - - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -tou@DSK1049:~/work-annex$ git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run1.log -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","git-annex"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","show-ref","--hash","refs/heads/git-annex"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..dbe8b1cfa5f84126c45a39fdc7c7f26e272c71cc","--oneline","-n1"] -[2013-09-11 09:24:53 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..45e279375897a2cd7f5b893402e0ec25c1b23436","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..c4921be4434f751493fce1c932ac759214abacd4","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","log","refs/heads/git-annex..d591398dc1cac824a5fc5bdacdcb82301a9b15a3","--oneline","-n1"] -[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] -[2013-09-11 09:24:54 CEST] read: git ["config","--null","--list"] -[2013-09-11 09:24:54 CEST] read: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","ls-files","--cached","-z","--"] -[2013-09-11 09:24:54 CEST] chat: git ["--git-dir=/home/tou/work-annex/.git","--work-tree=/home/tou/work-annex","cat-file","--batch"] -copy Documents/Gamle catillo overførsler/Rapport b-bm.odt (gpg) (checking box.com...) ok -copy Documents/Gamle catillo overførsler/Rapport brandt skorstensfejeren.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/4a5/18e/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1/GPGHMACSHA1--5f8660edac93899cf9adc5fadcc480ddc2992bb1.chunkcount) failed -copy Documents/Gamle catillo overførsler/Rapport teamkoege.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/98d/ae7/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44/GPGHMACSHA1--5253241407527aa6c980f1174fdbc32713c54c44.chunkcount) failed -copy Documents/Gamle catillo overførsler/Rapport vikarborsen.odt (checking box.com...) ok -copy Documents/Gamle catillo overførsler/Rapport-terrariemesteren.odt (checking box.com...) ok -copy Documents/Gamle catillo overførsler/catillo-efhandel.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/9d9/aea/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52/GPGHMACSHA1--1516eac1ec7b4ceaa840faebabde1f50f5db0a52.chunkcount) failed -copy Documents/Nøgeordsanalyse catillo104.xlsx (checking box.com...) (ResponseTimeout) failed -copy Documents/Søgeordsliste.txt (checking box.com...) ok -copy Documents/catillo guide.odt (checking box.com...) ok -copy Documents/guide bruger oprettelse.odt (checking box.com...) (failed to read https://www.box.com/dav/work-annex/49e/175/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c/GPGHMACSHA1--2b47737f8de7faac7704eaa322785edad63a921c.chunkcount) failed -copy Documents/guide skift backup bånd.odt (checking box.com...) ok -copy Documents/lilletest.csv (checking box.com...) (failed to read https://www.box.com/dav/work-annex/915/373/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33/GPGHMACSHA1--49ba3d5f63c012ae2cd2c0fc3e729178b1023c33.chunkcount) failed -copy Dropbox/adams-scraper/CommonFunctions.py (checking box.com...) (ResponseTimeout) failed -copy Dropbox/adams-scraper/__pycache__/CommonFunctions.cpython-33.pyc (checking box.com...) (to box.com...) [2013-09-11 09:28:30 CEST] chat: gpg ["--batch","--no-tty","--use-agent","--quiet","--trust-model","always","--batch","--passphrase-fd","14","--symmetric","--force-mdc"] - -100% 0.0 B/s 0sResponseTimeout -ResponseTimeout -failed - - -# End of transcript or log. -"""]] - -More to come(full log) - -> This is [[fixed|done]] in git; when built with a new enough -> version of the haskell DAV library, git-annex disables the default 5 -> second timeout. -> -> It'll still be present in the Debian stable backports, which are -> built with an old version of DAV. Not much I can do about that; -> backporting DAV would be difficult. -> -> The daily builds are updated to use the new version. -> --[[Joey]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment b/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment deleted file mode 100644 index ee1c88cc7..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_1_124a5edcd89cc6b61e1a41f5b4d640d7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 1" - date="2013-09-12T20:29:14Z" - content=""" -It seems you are getting a lot of timeouts from box.com, both when checking if content is present there and when uploading content that it does not have. - -I have heard some grumbles about box.com not being very reliable right now. -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment b/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment deleted file mode 100644 index 5a0cde548..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_2_42574181aa721319ba54eadf0a15ddff._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 2" - date="2013-09-12T20:54:33Z" - content=""" -The problem being. I've used box.com with one of my own hooks(owncloud), where it is completely stable! - -The instability is not a the box.com end. - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment b/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment deleted file mode 100644 index 5eab58b3f..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_3_2ad727849070cfd52d6c719478e9cce3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 3" - date="2013-09-12T20:56:44Z" - content=""" -git-annex is using box.com's WebDAV interface. Is owncloud? -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment b/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment deleted file mode 100644 index eb9dc5134..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_4_83ce23e45f5a5845d4f04519ee14ec65._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 4" - date="2013-09-12T21:33:29Z" - content=""" -It uses the following url https://www.box.com/dav - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment b/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment deleted file mode 100644 index 9d9c1329b..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_5_ef1c9d87b04db5047ab72167d3269687._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.4.51" - subject="comment 5" - date="2013-09-12T21:44:32Z" - content=""" -It may be that there is a timeout in the http library that I am using for webdav that is too low. See <https://github.com/snoyberg/http-conduit/issues/137> -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment b/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment deleted file mode 100644 index 5eaf4f4bb..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_6_c9cb39eba941678035f9b2888da1085c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="comment 6" - date="2013-09-12T21:49:05Z" - content=""" -That would probably do it. With other implementations(fuse mount) i've seen stalls and other bad behaviour with that DAV server. - -The owncloud hook doesn't have a timeout set. It probably should have one to prevent a total stall. -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment b/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment deleted file mode 100644 index 2ac3f360e..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_7_4b0632a4e37c96959a8e6434e9fd86fb._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmkBwMWvNKZZCge_YqobCSILPMeK6xbFw8" - nickname="develop" - subject="Logs" - date="2013-09-13T11:43:22Z" - content=""" -So have two days of logs now, and it doesn't look like it is retrying old files. - -http://paste.ubuntu.com/6101255/ <- day 1 - -http://paste.ubuntu.com/6101256/ <- day 2 - -Setting the computer to do the following loop over the weekend, lets see if everything is done come monday. - -for i in `seq 3 2000`; do git annex copy --to box.com --not --in box.com 2>&1 | tee ../work-annex-copy-to-box.com-not-in-box.com-run$i.log; done - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment b/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment deleted file mode 100644 index 8dfbd6944..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_8_d9d318b8c958de6031ae323da20af625._comment +++ /dev/null @@ -1,55 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA" - nickname="Tobias" - subject="Update" - date="2013-09-18T11:17:33Z" - content=""" -Only just got back to work now. The script has done 10 iteration. This is the status: - - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run1.log |grep \" ok\"| wc -l -137 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run2.log |grep \" ok\"| wc -l -77 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run3.log |grep \" ok\"| wc -l -116 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run4.log |grep \" ok\"| wc -l -70 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run5.log |grep \" ok\"| wc -l -26 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run6.log |grep \" ok\"| wc -l -6 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run7.log |grep \" ok\"| wc -l -6 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run8.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run9.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run10.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run11.log |grep \" ok\"| wc -l -0 - -tou@DSK1049:~$ cat work-annex-copy-to-box.com-not-in-box.com-run12.log |grep \" ok\"| wc -l -0 - -I have all the log files of course. - -tou@DSK1049:~/work-annex$ git annex find --not --in box.com| wc -l -1639 - -So, of the last 5 iteration 0 files of 1639 missing were transfered. Most of these files are <10kbyte - -http://paste.ubuntu.com/6123459/ <- pastebin of work-annex-copy-to-box.com-not-in-box.com-run11.log if it is of any use. - -"""]] diff --git a/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment b/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment deleted file mode 100644 index 99a0eb9ae..000000000 --- a/doc/bugs/box.com_never_stops_syncing/comment_9_689ac6a4a305197cf5566f98dab47b4b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.153.8.80" - subject="comment 9" - date="2013-09-28T19:34:42Z" - content=""" -Filed a bug on the DAV library about this: <http://bugs.debian.org/724856> -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie.mdwn b/doc/bugs/build_fails_on_debian_jessie.mdwn deleted file mode 100644 index 5727a845f..000000000 --- a/doc/bugs/build_fails_on_debian_jessie.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -### Please describe the problem. - -Can't build on debian jessie using "make" - "apt-get build-dep git-annex" misses various dependencies, and disk-space-free is not actually in jessie. I have built it with "stack", but that only produces something usable by me (links to stuff in my home dir). - -### 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) - -The stack build works very nicely, thanks. - -> The `debian-jessie-backport` branch should build. [[done]] --[[Joey]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_1_779a75e72292afdfdad1b4ff134e926e._comment b/doc/bugs/build_fails_on_debian_jessie/comment_1_779a75e72292afdfdad1b4ff134e926e._comment deleted file mode 100644 index bfb80a9d7..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_1_779a75e72292afdfdad1b4ff134e926e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-30T16:15:57Z" - content=""" -The disk-free-space and mountpoints dependencies will need to be backported -to Debian jessie before git-annex's backport can be updated. Both packages -are available in testing, so should be fairly easy to backport. -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_2_36edcd5a3eaba6382ada92b07ede728f._comment b/doc/bugs/build_fails_on_debian_jessie/comment_2_36edcd5a3eaba6382ada92b07ede728f._comment deleted file mode 100644 index 9a7abb47d..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_2_36edcd5a3eaba6382ada92b07ede728f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jk@3f2b4ce16bbac41470815333505aa47b91b7a9a6" - nickname="jk" - subject="comment 2" - date="2016-09-12T19:57:03Z" - content=""" -Got round to this eventually - build disk-space-free and mountpoints easily enough but then got into dependency hell over the shakespeare package: debian build process wants a later version than present in jessie, but won't build the stretch version against the jessie haskell packages. - -I haven't got much experience of haskell, especially under debian build: is there a way out of this? -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_3_3f6e35e7b618bf1762e37611b13e26bb._comment b/doc/bugs/build_fails_on_debian_jessie/comment_3_3f6e35e7b618bf1762e37611b13e26bb._comment deleted file mode 100644 index 5ab817b32..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_3_3f6e35e7b618bf1762e37611b13e26bb._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="jk@3f2b4ce16bbac41470815333505aa47b91b7a9a6" - nickname="jk" - subject="comment 3" - date="2016-09-13T07:05:48Z" - content=""" -A bit more detail: the version of git-annex in jessie-backports has shakespeare 2 as a dependency, but jessie-backports does not contain a package of that; also my attempts to build shakespeare 2 in a jessie{,-backports} enviroment fails with a long list of failed dependencies. -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_4_667a58e3bef3ef908038d13e9ed8200e._comment b/doc/bugs/build_fails_on_debian_jessie/comment_4_667a58e3bef3ef908038d13e9ed8200e._comment deleted file mode 100644 index a277fcd11..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_4_667a58e3bef3ef908038d13e9ed8200e._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-09-14T16:20:25Z" - content=""" -Re shakespeare, IIRC the dependency on version 2.0 was only needed -in order to remove a dependency on hamlet, which got removed upstream. -So if you add back the dependency on hamlet, it should -build with the older version of shakespeare. - -See git commit 2989cdfe3ed7524c00d16b21e8af9773c37497ff. -Basically, you want to revert that commit. - -Sorry about this farce; I tragically can't see a way to express -the actual dependency situation in git-annex.cabal and debian/control .. -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_5_c78b52b19ba1ab0f75ec0207539c652f._comment b/doc/bugs/build_fails_on_debian_jessie/comment_5_c78b52b19ba1ab0f75ec0207539c652f._comment deleted file mode 100644 index 8bbdda08d..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_5_c78b52b19ba1ab0f75ec0207539c652f._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-09-21T17:04:40Z" - content=""" -RichiH already has a debian-jessie-backport branch in the git-annex git -repo, so I added a commit onto it that fixes up the shakespeare dependency. - -I don't know what the holdup is on getting that backport actually uploaded -to Debian. -"""]] diff --git a/doc/bugs/build_fails_on_debian_jessie/comment_6_71a4acd7443abd7ab0b3c0b343892988._comment b/doc/bugs/build_fails_on_debian_jessie/comment_6_71a4acd7443abd7ab0b3c0b343892988._comment deleted file mode 100644 index 0196c3c9f..000000000 --- a/doc/bugs/build_fails_on_debian_jessie/comment_6_71a4acd7443abd7ab0b3c0b343892988._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="jk@3f2b4ce16bbac41470815333505aa47b91b7a9a6" - nickname="jk" - subject="comment 6" - date="2016-10-06T10:42:52Z" - content=""" -Justg a quick note to add that `git-annex-standalone` from NeuroDebian is working fine for me on jessie. -"""]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto.mdwn b/doc/bugs/cabal_constraints_for_aws_and_esqueleto.mdwn deleted file mode 100644 index 4b4780326..000000000 --- a/doc/bugs/cabal_constraints_for_aws_and_esqueleto.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -See https://github.com/joeyh/git-annex/pull/55. - -### Please describe the problem. -Solver needs some help when building with +S3 and +Webapp for Homebrew. - -### What steps will reproduce the problem? -Build git-annex with GHC 8.0.1 and cabal install 1.24.0.0 with --flags=s3\ webapp - -### What version of git-annex are you using? On what operating system? -6.20160719 -macOS 10.11.5 - -### Please provide any additional information below. -git-annex.cabal needs a couple of tweaks to reflect the following known issues: - - -1. -aws 0.14.0 is incompatible with http-conduit 2.2.0 -https://github.com/aristidb/aws/issues/206 - -2. -esqueleto 2.4.3 is incompatible with persistent 2.5 -https://github.com/prowdsponsor/esqueleto/issues/137 -https://github.com/prowdsponsor/esqueleto/pull/141 -https://github.com/prowdsponsor/esqueleto/pull/139 - -> I assume this will be sorted out upstream, but I don't mind temporarily -> adding the constraints. [[done]] --[[Joey]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment deleted file mode 100644 index 327b63469..000000000 --- a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_1_d91e44573ef4a0ec6e7098cb4cd360f5._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="https://launchpad.net/~felixonmars" - nickname="felixonmars" - avatar="http://cdn.libravatar.org/avatar/17284a3bb2e4ad9d3be8fab31f49865be9c1dc22143c728de731fe800a335d38" - subject="comment 1" - date="2016-11-28T04:17:12Z" - content=""" -aws has merged a PR to support http-conduit 2.2, but git-annex itself doesn't build with the new component yet: - -``` -[ 95 of 544] Compiling Utility.Url ( Utility/Url.hs, dist/build/git-annex/git-annex-tmp/Utility/Url.o ) - -Utility/Url.hs:354:34: error: - * The constructor `StatusCodeException' should have 2 arguments, but has been given 3 - * In the pattern: StatusCodeException s _ _ - In an equation for `matchStatusCodeException': - matchStatusCodeException want e@(StatusCodeException s _ _) - | want s = Just e - | otherwise = Nothing - -Utility/Url.hs:354:34: error: - * Couldn't match expected type `HttpException' - with actual type `HttpExceptionContent' - * In the pattern: StatusCodeException s _ _ - In an equation for `matchStatusCodeException': - matchStatusCodeException want e@(StatusCodeException s _ _) - | want s = Just e - | otherwise = Nothing -``` -"""]] diff --git a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment b/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment deleted file mode 100644 index ada283d8b..000000000 --- a/doc/bugs/cabal_constraints_for_aws_and_esqueleto/comment_2_32c45cc852a17e837f72dd8769a25781._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-12-13T15:58:25Z" - content=""" -This got fixed in the meantime. Note that posting comments to a bug that -has already been closed is a good way to get new problems not to be -noticed.. -"""]] diff --git a/doc/bugs/cabal_install_fails__58___Could_not_find_module___8216__Network.URI__8217__.mdwn b/doc/bugs/cabal_install_fails__58___Could_not_find_module___8216__Network.URI__8217__.mdwn deleted file mode 100644 index 2f9b5de3e..000000000 --- a/doc/bugs/cabal_install_fails__58___Could_not_find_module___8216__Network.URI__8217__.mdwn +++ /dev/null @@ -1,216 +0,0 @@ -### Please describe the problem. - -Can't install git-annex from current git master. cabal install also fails. Both fail with the same error. - -### What steps will reproduce the problem? - -cabal install git-annex --bindir=$HOME/bin - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -$ uname -a -Linux arch 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux - -$ cabal --version -cabal-install version 1.20.0.3 -using version 1.20.0.0 of the Cabal library -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ cabal install git-annex --bindir=$HOME/bin -Resolving dependencies... -Configuring DAV-1.0.2... -Configuring gnuidn-0.2.1... -Configuring gsasl-0.3.5... -Configuring hS3-0.5.8... -Failed to install gsasl-0.3.5 -Build log ( /home/dirk/.cabal/logs/gsasl-0.3.5.log ): -Configuring gsasl-0.3.5... -setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The pkg-config package -libgsasl version >=1.1 is required but it could not be found. -Failed to install gnuidn-0.2.1 -Build log ( /home/dirk/.cabal/logs/gnuidn-0.2.1.log ): -Configuring gnuidn-0.2.1... -setup-Simple-Cabal-1.18.1.3-x86_64-linux-ghc-7.8.3: The program c2hs is -required but it could not be found. -Building hS3-0.5.8... -Building DAV-1.0.2... -Failed to install hS3-0.5.8 -Build log ( /home/dirk/.cabal/logs/hS3-0.5.8.log ): -Configuring hS3-0.5.8... -Building hS3-0.5.8... -Preprocessing library hS3-0.5.8... - -Network/AWS/S3Object.hs:26:8: - Could not find module ‘Network.URI’ - It is a member of the hidden package ‘network-uri-2.6.0.1’. - Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file. - Use -v to see a list of the files searched for. -Failed to install DAV-1.0.2 -Build log ( /home/dirk/.cabal/logs/DAV-1.0.2.log ): -Configuring DAV-1.0.2... -Building DAV-1.0.2... -Preprocessing library DAV-1.0.2... -[1 of 2] Compiling Network.Protocol.HTTP.DAV.TH ( Network/Protocol/HTTP/DAV/TH.hs, dist/build/Network/Protocol/HTTP/DAV/TH.o ) -Loading package ghc-prim ... linking ... done. -Loading package integer-gmp ... linking ... done. -Loading package base ... linking ... done. -Loading package array-0.5.0.0 ... linking ... done. -Loading package deepseq-1.3.0.2 ... linking ... done. -Loading package containers-0.5.5.1 ... linking ... done. -Loading package bytestring-0.10.4.0 ... linking ... done. -Loading package transformers-0.3.0.0 ... linking ... done. -Loading package mtl-2.1.3.1 ... linking ... done. -Loading package text-1.2.0.0 ... linking ... done. -Loading package parsec-3.1.6 ... linking ... done. -Loading package hashable-1.2.2.0 ... linking ... done. -Loading package scientific-0.3.3.1 ... linking ... done. -Loading package attoparsec-0.12.1.2 ... linking ... done. -Loading package dlist-0.7.1 ... linking ... done. -Loading package old-locale-1.0.0.6 ... linking ... done. -Loading package syb-0.4.2 ... linking ... done. -Loading package pretty-1.1.1.1 ... linking ... done. -Loading package template-haskell ... linking ... done. -Loading package time-1.4.2 ... linking ... done. -Loading package unordered-containers-0.2.5.0 ... linking ... done. -Loading package primitive-0.5.3.0 ... linking ... done. -Loading package vector-0.10.11.0 ... linking ... done. -Loading package aeson-0.8.0.0 ... linking ... done. -Loading package blaze-builder-0.3.3.4 ... linking ... done. -Loading package blaze-markup-0.6.1.1 ... linking ... done. -Loading package blaze-html-0.7.0.3 ... linking ... done. -Loading package filepath-1.3.0.2 ... linking ... done. -Loading package unix-2.7.0.1 ... linking ... done. -Loading package directory-1.2.1.0 ... linking ... done. -Loading package exceptions-0.6.1 ... linking ... done. -Loading package process-1.2.0.0 ... linking ... done. -Loading package system-filepath-0.4.12 ... linking ... done. -Loading package system-fileio-0.3.14 ... linking ... done. -Loading package shakespeare-2.0.1.1 ... linking ... done. -Loading package stm-2.4.3 ... linking ... done. -Loading package transformers-base-0.4.3 ... linking ... done. -Loading package monad-control-0.3.3.0 ... linking ... done. -Loading package lifted-base-0.2.3.0 ... linking ... done. -Loading package mmorph-1.0.4 ... linking ... done. -Loading package resourcet-1.1.2.3 ... linking ... done. -Loading package nats-0.2 ... linking ... done. -Loading package semigroups-0.15.3 ... linking ... done. -Loading package void-0.6.1 ... linking ... done. -Loading package conduit-1.2.0.2 ... linking ... done. -Loading package attoparsec-conduit-1.1.0 ... linking ... done. -Loading package blaze-builder-conduit-1.1.0 ... linking ... done. -Loading package network-2.6.0.2 ... linking ... done. -Loading package random-1.1 ... linking ... done. -Loading package zlib-0.5.4.1 ... linking ... done. -Loading package streaming-commons-0.1.5 ... linking ... done. -Loading package conduit-extra-1.1.3.4 ... linking ... done. -Loading package data-default-class-0.0.1 ... linking ... done. -Loading package data-default-instances-base-0.0.1 ... linking ... done. -Loading package data-default-instances-containers-0.0.1 ... linking ... done. -Loading package data-default-instances-dlist-0.0.1 ... linking ... done. -Loading package data-default-instances-old-locale-0.0.1 ... linking ... done. -Loading package data-default-0.5.3 ... linking ... done. -Loading package xml-types-0.3.4 ... linking ... done. -Loading package xml-conduit-1.2.2 ... linking ... done. -Loading package xml-hamlet-0.4.0.9 ... linking ... done. -Loading package transformers-compat-0.3.3.4 ... linking ... done. -Loading package contravariant-1.2 ... linking ... done. -Loading package tagged-0.7.2 ... linking ... done. -Loading package distributive-0.4.4 ... linking ... done. -Loading package comonad-4.2.2 ... linking ... done. -Loading package semigroupoids-4.2 ... linking ... done. -Loading package bifunctors-4.1.1.1 ... linking ... done. -Loading package prelude-extras-0.4 ... linking ... done. -Loading package profunctors-4.2.0.1 ... linking ... done. -Loading package free-4.9 ... linking ... done. -Loading package parallel-3.2.0.4 ... linking ... done. -Loading package reflection-1.5.1 ... linking ... done. -Loading package split-0.2.2 ... linking ... done. -Loading package lens-4.4.0.2 ... linking ... done. -Loading package byteable-0.1.1 ... linking ... done. -Loading package securemem-0.1.3 ... linking ... done. -Loading package crypto-cipher-types-0.0.9 ... linking ... done. -Loading package cipher-aes-0.2.8 ... linking ... done. -Loading package crypto-random-0.0.8 ... linking ... done. -Loading package cprng-aes-0.5.2 ... linking ... done. -Loading package cereal-0.4.0.1 ... linking ... done. -Loading package socks-0.5.4 ... linking ... done. -Loading package asn1-types-0.2.3 ... linking ... done. -Loading package asn1-encoding-0.8.1.3 ... linking ... done. -Loading package cipher-des-0.0.6 ... linking ... done. -Loading package cipher-rc4-0.1.4 ... linking ... done. -Loading package crypto-numbers-0.2.3 ... linking ... done. -Loading package crypto-pubkey-types-0.4.2.2 ... linking ... done. -Loading package cryptohash-0.11.6 ... linking ... done. -Loading package crypto-pubkey-0.2.4 ... linking ... done. -Loading package asn1-parse-0.8.1 ... linking ... done. -Loading package base64-bytestring-1.0.0.1 ... linking ... done. -Loading package pem-0.2.2 ... linking ... done. -Loading package x509-1.4.12 ... linking ... done. -Loading package x509-store-1.4.4 ... linking ... done. -Loading package x509-validation-1.5.0 ... linking ... done. -Loading package tls-1.2.9 ... linking ... done. -Loading package x509-system-1.4.5 ... linking ... done. -Loading package connection-0.2.3 ... linking ... done. -Loading package case-insensitive-1.2.0.1 ... linking ... done. -Loading package cookie-0.4.1.3 ... linking ... done. -Loading package http-types-0.8.5 ... linking ... done. -Loading package mime-types-0.1.0.4 ... linking ... done. -Loading package network-uri-2.6.0.1 ... linking ... done. -Loading package utf8-string-0.3.8 ... linking ... done. -Loading package publicsuffixlist-0.1 ... linking ... done. -Loading package http-client-0.4.0 ... linking ... done. -Loading package http-client-tls-0.2.2 ... linking ... done. -Loading package MonadRandom-0.3 ... linking ... done. -Loading package either-4.3.1 ... linking ... done. -Loading package safe-0.3.8 ... linking ... done. -Loading package errors-1.4.7 ... linking ... done. -[2 of 2] Compiling Network.Protocol.HTTP.DAV ( Network/Protocol/HTTP/DAV.hs, dist/build/Network/Protocol/HTTP/DAV.o ) - -Network/Protocol/HTTP/DAV.hs:80:1: Warning: - The import of ‘unauthorized401’ - from module ‘Network.HTTP.Types’ is redundant - -Network/Protocol/HTTP/DAV.hs:92:95: Warning: - ‘DAVT’ is an instance of MonadPlus but not Alternative - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. - -Network/Protocol/HTTP/DAV.hs:213:1: Warning: - Defined but not used: ‘supportsCalDAV’ - -Network/Protocol/HTTP/DAV.hs:88:10: Warning: - Orphan instance: instance Default DAVContext - -Network/Protocol/HTTP/DAV.hs:95:10: Warning: - Orphan instance: instance MonadMask m => MonadMask (EitherT e m) -In-place registering DAV-1.0.2... -Preprocessing executable 'hdav' for DAV-1.0.2... - -hdav.hs:33:8: - Could not find module ‘Network.URI’ - It is a member of the hidden package ‘network-uri-2.6.0.1’. - Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file. - Use -v to see a list of the files searched for. -cabal: Error: some packages failed to install: -DAV-1.0.2 failed during the building phase. The exception was: -ExitFailure 1 -git-annex-5.20140919 depends on DAV-1.0.2 which failed to install. -gnuidn-0.2.1 failed during the configure step. The exception was: -ExitFailure 1 -gsasl-0.3.5 failed during the configure step. The exception was: -ExitFailure 1 -hS3-0.5.8 failed during the building phase. The exception was: -ExitFailure 1 -network-protocol-xmpp-0.4.6 depends on gnuidn-0.2.1 which failed to install. - -# End of transcript or log. -"""]] - -> This is a bug in hS3, not in git-annex. hS3 needs to be updated -> per the example at <http://hackage.haskell.org/package/network>. -> Email sent to hS3 author; [[done]]. --[[Joey]] diff --git a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn b/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn deleted file mode 100644 index 32643a612..000000000 --- a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. - -Cannot even extract the standalone linux tarball for deployment on our processing server: - -[[!format sh """ -[mvdoc@rolando bin] > tar -xzf git-annex-standalone-amd64.tar.gz -tar: git-annex.linux/shimmed/git-fsck/git-fsck: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link -tar: git-annex.linux/shimmed/git-cat-file/git-cat-file: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link -tar: git-annex.linux/shimmed/git-init/git-init: Cannot hard link to `git-annex.linux/shimmed/git-help/git-help': Invalid cross-device link -... -tar: Exiting with failure status due to previous errors - -[mvdoc@rolando bin] > ls -l git-annex.linux/shimmed/git-pack-redundant/git-pack-redundant git-annex.linux/shimmed/git-help/git-help -ls: cannot access git-annex.linux/shimmed/git-pack-redundant/git-pack-redundant: No such file or directory --rwxr-xr-x 1 mvdoc users 2023056 Oct 29 22:44 git-annex.linux/shimmed/git-help/git-help -[mvdoc@rolando bin] > - - -# End of transcript or log. -"""]] - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_1_944d132c834b81bb4cac22af4bef2a3b._comment b/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_1_944d132c834b81bb4cac22af4bef2a3b._comment deleted file mode 100644 index 7c3379262..000000000 --- a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_1_944d132c834b81bb4cac22af4bef2a3b._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-08T18:54:50Z" - content=""" -Here's a nickle kid, go buy a POSIX filesystem. At least one that supports -hard links? - -(Or tar --hard-dereference I suppose.) -"""]] diff --git a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_2_d9d437a414d38f87bea59d24d14986b5._comment b/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_2_d9d437a414d38f87bea59d24d14986b5._comment deleted file mode 100644 index 973249fa7..000000000 --- a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_2_d9d437a414d38f87bea59d24d14986b5._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da" - subject="comment 2" - date="2016-11-08T19:18:40Z" - content=""" ---hard-dereference would be something to use on your end while creating a tarball ;-P (seems to be not applicable while extracting) - -would symlinks work there instead? (more FSs would support those than hard links I guess) -"""]] diff --git a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_3_c200ccb58cf3e53dd162884e0568429e._comment b/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_3_c200ccb58cf3e53dd162884e0568429e._comment deleted file mode 100644 index 0a53ac4d6..000000000 --- a/doc/bugs/cannot___34__install__34___standalone_git_annex_within_afs_mount/comment_3_c200ccb58cf3e53dd162884e0568429e._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-11-10T18:21:35Z" - content=""" -Bloating the tarball with duplicates of all the hard linked stuff would -increase its size by a large amount. - -The current machinery for building the standlone tarball only works when -using hard links. - -Ok.. Complicated it by making it use symlinks. -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn deleted file mode 100644 index 6be8bd6e6..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. - -All git annex commands run successfully but are prefixed by an annoying error message: - -"/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)" - - -### What steps will reproduce the problem? - -`git annex init` or just about any git annex command. - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20150710-g8fd7052 on arch linux 4.0.7-2. - -### Please provide any additional information below. - -# locale -a -C -en_US -en_US.iso88591 -en_US.utf8 -hebrew -he_IL -he_IL.iso88598 -he_IL.utf8 -POSIX - -> I've made LOCPATH not be set except when git-annex is built with ghc -> older than 7.10, since the problem was fixed in ghc 7.10. -> -> Also, I loved the LOCPATH setting into the linker shim script, rather -> than in runshell, so it will only affect the programs bundled with -> git-annex (itself and git and a few other things). Which are not -> localized anyway in the bundle. So, even in builds where it's still set -> (the linux ancient build in particular), things done in the runshell -> environment won't be affected. -> -> I do wonder if there could be problems with incompatabilities between the -> bundled glibc and the system locale files, which might be for a -> newer/older libc version. Not so much random `.mo` files, which seem -> quite portable across glibc versions, but the more core locale files. -> If that turns out to be a problem, LOCPATH might have to be turned back -> on. -> -> For now, [[done]] --[[Joey]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment deleted file mode 100644 index fa17f6e6b..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_1_d8d8e8f672ad7a95f6565d15ccd11e45._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-07-17T15:34:21Z" - content=""" -This suggests that your system has misconfigured locales. Perhaps it has -the locale set to en_US.UTF-8 but does not have that locale configured. - -Doesn't seem likely to be a bug in git-annex. - -The same message is reported in -<http://git-annex.branchable.com/bugs/view_fails_with___34__invalid_character__34__/>. -Arch linux was also being used there. Surely the Arch wiki has something -about fixing your locale setting? :) -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_2_6715d6e7bbc7ca8760ab561b1d124ce9._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_2_6715d6e7bbc7ca8760ab561b1d124ce9._comment deleted file mode 100644 index 81234be5c..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_2_6715d6e7bbc7ca8760ab561b1d124ce9._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="stoile@3a237e0cf1bb7ab671df438ff759e0448189419d" - nickname="stoile" - subject="This might still be a git-annex bug" - date="2015-09-21T15:09:08Z" - content=""" -I get this problem when running the pre-built linux binaries of git annex. So this might still be a git annex bug: My local environment provides the LC:ALL setting and git-annex sh does not have the locale. -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_3_b5a78d805e2e1628de299115a0a96e8d._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_3_b5a78d805e2e1628de299115a0a96e8d._comment deleted file mode 100644 index 59bf4d067..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_3_b5a78d805e2e1628de299115a0a96e8d._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-09-21T16:02:24Z" - content=""" -So, I actually see something a little similar when using runshell -in the standalone bundle: - - joey@darkstar:~/tmp/a/git-annex.linux>./runshell - $ bash - locale: Cannot set LC_CTYPE to default locale: No such file or directory - locale: Cannot set LC_MESSAGES to default locale: No such file or directory - -This is due to it setting LOCPATH=/dev/null, -so it won't even try to use the system's locale files. -(Whether they would be compatable with the libc in the bundle is another question.) - -So, `unset LOCPATH` may work around the problem. If you don't run into -the bug that is set to prevent, <https://ghc.haskell.org/trac/ghc/ticket/7695>. - -This setting could be revisited once the standalone builds are built using -ghc 7.10, which fixed that bug. -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_4_f2b302f343b6615ea63feb9ee32892c5._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_4_f2b302f343b6615ea63feb9ee32892c5._comment deleted file mode 100644 index 7e5ef986b..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_4_f2b302f343b6615ea63feb9ee32892c5._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="http://svario.it/gioele" - nickname="gioele" - subject="comment 4" - date="2016-04-16T12:53:13Z" - content=""" -This problem is still present in `6.20160412-gdcf8d3b`. Programs run inside `runshell` will complain that - - locale: Cannot set LC_CTYPE to default locale: No such file or directory - locale: Cannot set LC_MESSAGES to default locale: No such file or directory - locale: Cannot set LC_ALL to default locale: No such file or directory - -Is it possible to remove the `LOCPATH=/dev/null` workaround now that GHC 7.10 is used to build the standalone bundles? - -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment deleted file mode 100644 index 9cf3695f5..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_5_eca31aeb974571c9cca7a399e00984a5._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="http://svario.it/gioele" - nickname="Gioele" - avatar="http://cdn.libravatar.org/avatar/af2f2ba0dafe4650011d20f2168d43cff773aba97f55ae5b252bb873f391c1e2" - subject="compiled with GHC 8, but LOCPATH is still set" - date="2016-12-21T21:51:09Z" - content=""" -This bug does not want to die. - -The current standalone build (`6.20161211-gc3ab3c668`) has been compiled with GHC 8 but when I launch `runshell`, I still see that `LOCPATH` is set and the character encoding is messed up. - -I deduced the version of GHC used to compile git-annex with `strings ./shimmed/git-annex/git-annex | grep 'GHC [0-9]'`. -"""]] diff --git a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment b/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment deleted file mode 100644 index 1942a6f52..000000000 --- a/doc/bugs/cannot_change_locale___40__en__95__US.UTF-8__41__/comment_6_0cada5a6154438c674f01d449378ffe9._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-12-24T16:57:45Z" - content=""" -This is an old closed bug report. The recent comments are about a -completely unrelated issue, which I suspect was fixed by -[[!commit 95c8b37544c383983712c5c368dd803c51bf8eeb]]. - -Please file new bug reports if you have an issue, if the old bug report was -closed years ago. -"""]] diff --git a/doc/bugs/check_version.mdwn b/doc/bugs/check_version.mdwn deleted file mode 100644 index f1b88a8b1..000000000 --- a/doc/bugs/check_version.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -I'd like to be able to check the git annex version with `git annex --version`, to know if it's 5 or 6. - -> [[done]], as noted `git annex version` already exists. --[[Joey]] diff --git a/doc/bugs/check_version/comment_1_857177c710cd0d09fa2ae0a99862a4fa._comment b/doc/bugs/check_version/comment_1_857177c710cd0d09fa2ae0a99862a4fa._comment deleted file mode 100644 index 5fdef56b5..000000000 --- a/doc/bugs/check_version/comment_1_857177c710cd0d09fa2ae0a99862a4fa._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - subject="comment 1" - date="2016-08-15T01:54:58Z" - content=""" -it's - -git annex version - -not - -git annex --version -"""]] diff --git a/doc/bugs/checksum_loads_whole_file_into_memory.mdwn b/doc/bugs/checksum_loads_whole_file_into_memory.mdwn deleted file mode 100644 index ece328105..000000000 --- a/doc/bugs/checksum_loads_whole_file_into_memory.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -Using eg, fsck with the MD5 backend loads whole files into memory. - -May only happen for very large files (40 gb) or in other specific -circumstances, including ghc version used for buildd etc. - -Observed with 6.20160217-g95bbdb8, linux standalone amd64. - -Not observed with 5.20151218-g5008846. - -Commit 7482853ddddc21f2696dcfbc82d737f03032134a may be relevant, -but I don't understand how yet. A small test program using the same -code doesn't exhibit the problem, even when built in the identical build -environment as the 6.20160217-g95bbdb8 that has the problem. - -> Update: Reverted 7482853ddddc21f2696dcfbc82d737f03032134a and indeed the -> problem got fixed. But, reverting that commit breaks the test suite on -> windows and has a FD leak, so is not desirable. This needs more -> investigation. --[[Joey]] - ->> I see it now, the checksum is a String and it was only forced to WHNF, ->> so the hashing didn't fully complete and the file got buffered. ->> Probably only occurred when fscking, and not when adding a file, ->> due to differing use patterns of the checksum. ->> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/commenting_on_patches_fails.mdwn b/doc/bugs/commenting_on_patches_fails.mdwn deleted file mode 100644 index 9b4cff777..000000000 --- a/doc/bugs/commenting_on_patches_fails.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -### Please describe the problem. - -I was attempting to comment on this patch: - -<https://git-annex.branchable.com/todo/PATCH__58___drop_url_parameters_from_extension.hs/> - -but adding the comment fails with: - -`Error: failed to create directory /home/b-git-annex/source/doc/todo/PATCH__58___drop_url_parameters_from_extension.hs/: File exists` - -(this appears to be repeatable.) At a guess there's actually a file there for the patch... which is why it can't make a directory. - -### What steps will reproduce the problem? - -1. Go to <https://git-annex.branchable.com/todo/PATCH__58___drop_url_parameters_from_extension.hs/> - -2. Log in - -3. Click "Add comment" - -4. Enter comment with subject/body - -5. Try to save the comment - - -### What version of git-annex are you using? On what operating system? - -N.A. - - -### Please provide any additional information below. - -FTR, the original comment I was trying to make was basically "yes, please add this patch" -- but more verbosely: - -"""This would be very useful. **libsyn** seem to have changed their podcast URLs over the last couple of weeks to *always* add a `?dest_id=...` suffix (and changed the historical URL of every single podcast on any feed on their service, the next time it is rebuilt, which has led to a few large sets of duplicate downloads and a bunch of manual cleanup to avoid large duplicate downloads on the ones I noticed in time). For now I've been doing manual "git mv" as I notice new ones coming in (a few every week), but I'd really prefer it happened automatically.""" - - - -### 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) - -Lots of luck with git-annex. It's extremely useful as both a distributed content store, and also as a podcatcher. Thanks for writing it :-) - -Ewen - -> In this particular case, a .hs file got added to the wiki, -> presumably by picking that extension when editing the file. -> In any case, if there's a bug here, it's a bug in ikiwiki not git-annex -> so this is not the place to track it. [[done]] --[[Joey]] diff --git a/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__.mdwn b/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__.mdwn deleted file mode 100644 index 027d22431..000000000 --- a/doc/bugs/commitBuffer__58___invalid_argument___40__invalid_character__41__.mdwn +++ /dev/null @@ -1,228 +0,0 @@ -What steps will reproduce the problem? - - $ git init a.git - Initialized empty Git repository in /var/tmp/git-annex-bug/a.git/.git/ - $ cd a.git - $ git annex init a - init a ok - (Recording state in git...) - $ touch Ren$'\351' - $ git annex add Ren$'\351' - add René (checksum...) ok - (Recording state in git...) - $ git ci -m "Added Rene'." - [master (root-commit) a61b796] Added Rene'. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 "Ren\351" - $ cd .. - $ git clone -o a a.git b.git - Cloning into b.git... - remote: Counting objects: 13, done. - remote: Compressing objects: 100% (9/9), done. - remote: Total 13 (delta 1), reused 0 (delta 0) - Receiving objects: 100% (13/13), done. - Resolving deltas: 100% (1/1), done. - $ cd b.git - $ git annex copy --from=a --fast -v - (merging a/git-annex into git-annex...) - copy René - git-annex: /var/tmp/git-annex-bug/b.git/.git/annex/transfer/download/7c5ee764-e8c6-11e1-b0c5-67c6ec1236d6/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: commitBuffer: invalid argument (invalid character) - failed - (Recording state in git...) - git-annex: copy: 1 failed - -What is the expected output? What do you see instead? - -Expect that files will be copied, but they are not. - -What version of git-annex are you using? On what operating system? - - $ echo $LANG - en_US.UTF-8 - $ lsb_release -a - No LSB modules are available. - Distributor ID: Ubuntu - Description: Ubuntu 11.10 - Release: 11.10 - Codename: oneiric - $ uname -a - Linux pdx-desktop 3.0.0-23-generic #39-Ubuntu SMP Thu Jul 19 19:18:53 UTC 2012 i686 i686 i386 GNU/Linux - $ bash --version - GNU bash, version 4.2.10(1)-release (i686-pc-linux-gnu) - Copyright (C) 2011 Free Software Foundation, Inc. - License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> - - This is free software; you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - $ ghc --version - The Glorious Glasgow Haskell Compilation System, version 7.4.2 - $ git annex version - git-annex version: 3.20120807 - local repository version: 3 - default repository version: 3 - supported repository versions: 3 - upgrade supported from repository versions: 0 1 2 - -Please provide any additional information below. - -The problem is related to weird characters in file names. In the -above example, the "weird character" is an accented 'e' (entered with -$'\351' in bash and zsh). I am able to add the files with weird -characters in their name to one annex, but I cannot copy them to other -annexes using `git annex copy`. - -The above example is a simplification of a real problem I am -experiencing. In my real scenario, the file is not empty. See the -attachment for some variations, including with non-empty -files. UPDATE: I'm not allowed to add attachments. See below. - -May be related to these (long-ago fixed) bugs: -http://git-annex.branchable.com/todo/support-non-utf8-locales/ - - -"Attachment": Here are my notes, including more examples: - - Programs I'm using: - - $ echo $LANG - en_US.UTF-8 - $ lsb_release -a - No LSB modules are available. - Distributor ID: Ubuntu - Description: Ubuntu 11.10 - Release: 11.10 - Codename: oneiric - $ uname -a - Linux pdx-desktop 3.0.0-23-generic #39-Ubuntu SMP Thu Jul 19 19:18:53 UTC 2012 i686 i686 i386 GNU/Linux - $ bash --version - GNU bash, version 4.2.10(1)-release (i686-pc-linux-gnu) - Copyright (C) 2011 Free Software Foundation, Inc. - License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> - - This is free software; you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - $ ghc --version - The Glorious Glasgow Haskell Compilation System, version 7.4.2 - $ git annex version - git-annex version: 3.20120807 - local repository version: 3 - default repository version: 3 - supported repository versions: 3 - upgrade supported from repository versions: 0 1 2 - - - Simplest way to see problem: one empty file with weird character - (accented e: $'\351') in name: - - $ git init a.git - Initialized empty Git repository in /var/tmp/git-annex-bug/a.git/.git/ - $ cd a.git - $ git annex init a - init a ok - (Recording state in git...) - $ touch Ren$'\351' - $ git annex add Ren$'\351' - add René (checksum...) ok - (Recording state in git...) - $ git ci -m "Added Rene'." - [master (root-commit) a61b796] Added Rene'. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 "Ren\351" - $ cd .. - $ git clone -o a a.git b.git - Cloning into b.git... - remote: Counting objects: 13, done. - remote: Compressing objects: 100% (9/9), done. - remote: Total 13 (delta 1), reused 0 (delta 0) - Receiving objects: 100% (13/13), done. - Resolving deltas: 100% (1/1), done. - $ cd b.git - $ git annex copy --from=a --fast -v - (merging a/git-annex into git-annex...) - copy René - git-annex: /var/tmp/git-annex-bug/b.git/.git/annex/transfer/download/7c5ee764-e8c6-11e1-b0c5-67c6ec1236d6/SHA256-s0--e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855: commitBuffer: invalid argument (invalid character) - failed - (Recording state in git...) - git-annex: copy: 1 failed - - - Problem disappears with two empty files: - - $ cd .. - $ git init a2.git - Initialized empty Git repository in /var/tmp/git-annex-bug/a2.git/.git/ - $ cd a2.git - $ git annex init a2 - init a2 ok - (Recording state in git...) - $ touch Ren$'\351' - $ git annex add Ren$'\351' - add René (checksum...) ok - (Recording state in git...) - $ git ci -m "Add Ren$'\351'." - [master (root-commit) 62ac1c8] Add Ren$'\351'. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 "Ren\351" - $ touch Rene - $ git annex add Rene - add Rene (checksum...) ok - (Recording state in git...) - $ git ci -m "Add Rene." - [master c455523] Add Rene. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 Rene - $ cd .. - $ git clone -o a2 a2.git b2.git - Cloning into b2.git... - done. - $ cd b2.git - $ git annex copy --from=a2 --fast -v - (merging a2/git-annex into git-annex...) - copy Rene (from a2...) ok - (Recording state in git...) - - - Problem returns with two non-empty files: - - $ cd .. - $ git init a4.git - Initialized empty Git repository in /var/tmp/git-annex-bug/a4.git/.git/ - $ cd a4.git - $ git annex init a4 - init a4 ok - (Recording state in git...) - $ touch Ren$'\351' - $ rm Ren$'\351' - $ ls - $ echo "some content" > Ren$'\351' - $ git annex add Ren$'\351' - add René (checksum...) ok - (Recording state in git...) - $ git ci -m "Add Ren$'\351'." - [master (root-commit) f090d90] Add Ren$'\351'. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 "Ren\351" - $ echo "some other content" > Rene - $ git annex add Rene - add Rene (checksum...) ok - (Recording state in git...) - $ git ci -m "Add Rene." - [master 97c20cd] Add Rene. - 1 files changed, 1 insertions(+), 0 deletions(-) - create mode 120000 Rene - $ cd .. - $ git clone -o a4 a4.git b4.git - Cloning into b4.git... - done. - $ cd b4.git - $ git annex copy --from=a4 --fast -v - (merging a4/git-annex into git-annex...) - copy Rene (from a4...) ok - copy René - git-annex: /var/tmp/git-annex-bug/b4.git/.git/annex/transfer/download/a5fcd0d4-e8c8-11e1-bb41-43ce1cb9a9f1/SHA256-s13--1c87b6727f523662df714f06a94ea27fa4d9050c38f4f7712bd4663ffbfdfa01: commitBuffer: invalid argument (invalid character) - failed - (Recording state in git...) - git-annex: copy: 1 failed - -> [[Fixed|done]]. Sorry this took so long, I was at a very busy point when -> you filed this and am only just getting caught up. --[[Joey]] diff --git a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__.mdwn b/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__.mdwn deleted file mode 100644 index d6200b65b..000000000 --- a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -After unlocking a large file and editing it, the attempt to commit the change fails like so: - -git-annex: fd:16: hGetBuf: invalid argument (Invalid argument) - -### What steps will reproduce the problem? - -(it needs to be over 2G in size to reproduce the problem) - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20160923 on macOS 10.12 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ dd if=/dev/zero of=largefile.txt bs=1048576 count=2048 -$ git annex add largefile.txt -$ git commit -m 'added large file' -$ git annex unlock largefile.txt -$ echo foobar >> largefile.txt -$ git commit -a -m 'edited large file' -git-annex: fd:16: hGetBuf: invalid argument (Invalid argument) - -# End of transcript or log. -"""]] - -### 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) - -> reproduced; and confirmed that the fix below really did fix it on OSX. -> [[done]] --[[Joey]] diff --git a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_1_e2bc83fc04641c3547aeb1830da0d947._comment b/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_1_e2bc83fc04641c3547aeb1830da0d947._comment deleted file mode 100644 index 4046ad7bb..000000000 --- a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_1_e2bc83fc04641c3547aeb1830da0d947._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-10-05T17:02:12Z" - content=""" -By using git commit -a to commit changes to a large annexed file, you -are causing git to first add the file to the git repository, and then -git-annex has to go fix up and convert it back to an annexed file. - -So, you probably don't want to be doing that, irrespective of this bug. -Storing the file content in the git repository will waste disk space until -git gc gets around to cleaning it up. - -Instead, use `git annex add` on the file after editing it, and then commit -the result. As well as not cluttering up git with large unused objects, -that will be generally faster, and will probably avoid this bug. - ----- - -I've reproduced on linux a behavior that probably has the same root cause. -It looks like git-annex pre-commit is reading the whole content of the -large file from git cat-file, and buffering it in memory. Of course -this uses a lot of memory and will fail for some size files, and it -should definitely not be doing this. - -Suspect this is a reversion caused by the changes to support v6 mode. -"""]] diff --git a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_2_b436936c502a40c01f82e64d97f1875e._comment b/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_2_b436936c502a40c01f82e64d97f1875e._comment deleted file mode 100644 index 8fe955913..000000000 --- a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_2_b436936c502a40c01f82e64d97f1875e._comment +++ /dev/null @@ -1,42 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-10-05T18:04:21Z" - content=""" -Nothing to do with v6 actually. -[[!commit 412dcb8017d9d42bc1fb2b5a7ae5418410cde539]] and a subsequent -commit caused this behavior. - -In order to tell if a file is unlocked, the type needs to have changed -from a symlink to a regular file, and the symlink needs to have been -an annexed link (and not some other symlink). That commit made it check -catKeyFileHEAD, which necessarily reads the whole content of the last -committed version of the file from git cat-file. - -A later commit added a check to catKeyFile, which reads the version of the -file that is staged. Due to the git commit -a, the whole file content has -been staged, and so that is where the large file content is read from git -cat-file in git annex pre-commit. - -For pre-commit's purposes, the catKeyFile check is never going to find an -annexed link, since the whole file content has been staged by git commit. - -But, rather than such a specific fix, I think that the core problem to fix -is that catKey reads the whole content of a large object from git. That's -just too expensive for git repos that contain large objects, for whatever -reason. - -For example, grepping for catKey, I quickly found another place where -a large file is read from git cat-file, in the adjusted branch code. - -So, let's make catKey check the object size before reading it; if it's -> 8192 bytes it's certianly not a symlink. This wil need a separate -`git cat-file --batch-check` process, and a little extra work. It which will -probably not be very expensive due to disk caching, but if it does cause -a slowdown, the main thing will be to handling of unlocked files in v6 -mode, which needs to use catKey. - -I've done this, and it fixes the problem I saw. I am not 100% sure if -that's the same problem that occurred on OSX. (Which I was also able to -reproduce). Probably is. Need to verify. Update: Verified fix. -"""]] diff --git a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_3_f7630c2ede7f4a42e9ccf06025c5f18a._comment b/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_3_f7630c2ede7f4a42e9ccf06025c5f18a._comment deleted file mode 100644 index 673d0f335..000000000 --- a/doc/bugs/committing_an_edited_file_fails_with___34__hGetBuf__58___Invalid_argument__34__/comment_3_f7630c2ede7f4a42e9ccf06025c5f18a._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="ddenis" - subject="comment 3" - date="2016-10-06T16:59:03Z" - content=""" -Ah I didn't think that \"git commit -a\" would add it to git's index. I should've used \"git annex add\" indeed. But thank you for looking into this issue and fixing it so quickly! -"""]] diff --git a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn b/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn deleted file mode 100644 index cb3d34055..000000000 --- a/doc/bugs/concurrent_drop--from_presence_checking_failures.mdwn +++ /dev/null @@ -1,398 +0,0 @@ -Concurrent dropping of a file has problems when drop --from is -used. (Also when the assistant or sync --content decided to drop from a -remote.) - -> Now [[fixed|done]] --[[Joey]] - -[[!toc]] - -# refresher - -First, let's remember how it works in the case where we're just dropping -from 2 repos concurrently. git-annex uses locking to detect and prevent -data loss: - -<pre> -Two repos, each with a file: - -A (has) -B (has) - -A wants from drop from A B wants to drop from B -A locks it B locks it -A checks if B has it B checks if A has it - (does, but locked, so fails) (does, but locked, so fails) -A fails to drop it B fails to drop it - -The two processes are racing, so there are other orderings to -consider, for example: - -A wants from drop from A B wants to drop from B -A locks it -A checks if B has it (succeeds) -A drops it from A B locks it - B checks if A has it (fails) - B fails to drop it - -Which is also ok. - -A wants from drop from A B wants to drop from B -A locks it -A checks if B has it (succeeds) - B locks it - B checks if A has it - (does, but locked, so fails) -A drops it B fails to drop it - -Yay, still ok. -</pre> - -Locking works in those cases to prevent concurrent dropping of a file. - -# the bug - -But, when drop --from is used, the locking doesn't work: - -<pre> -Two repos, each with a file: - -A (has) -B (has) - -A wants to drop from B B wants to drop from A -A checks to see if A has it (succeeds) B checks to see if B has it (succeeds) -A tells B to drop it B tells A to drop it -B locks it, drops it A locks it, drops it - -No more copies remain! -</pre> - -Verified this one in the wild (adding an appropriate sleep to force the -race). - -Best fix here seems to be for A to lock the content on A -as part of its check of numcopies, and keep it locked -while it's asking B to drop it. Then when B tells A to drop it, -it'll be locked and that'll fail (and vice-versa). - -> Done, and verified the fix works in this situation. - -# the bug part 2 - -<pre> -Three repos; C might be a special remote, so w/o its own locking: - -A C (has) -B (has) - -A wants to drop from C B wants to drop from B - B locks it -A checks if B has it B checks if C has it (does) - (does, but locked, so fails) B drops it - -Copy remains in C. But, what if the race goes the other way? - -A wants to drop from C B wants to drop from B -A checks if B has it (succeeds) -A drops it from C B locks it - B checks if C has it (does not) - -So ok, but then: - -A wants to drop from C B wants to drop from B -A checks if B has it (succeeds) - B locks it - B checks if C has it (does) -A drops it from C B drops it from B - -No more copies remain! -</pre> - -To fix this, seems that A should not just check if B has it, but lock -the content on B and keep it locked while A is dropping from C. -This would prevent B dropping the content from itself while A is in the -process of dropping from C. - -That would mean replacing the call to `git-annex-shell inannex` -with a new command that locks the content. - -Note that this is analgous to the fix above; in both cases -the change is from checking if content is in a location, to locking it in -that location while performing a drop from another location. - -> Done, and verified the fix works in this situation. - -# the bug part 3 (where it gets really nasty) - -<pre> -4 repos; C and D might be special remotes, so w/o their own locking: - -A C (has) -B D (has) - -B wants to drop from C A wants to drop from D -B checks if D has it (does) A checks if C has it (does) -B drops from C A drops from D - -No more copies remain! -</pre> - -How do we get locking in this case? - -Adding locking to C and D is not a general option, because special remotes -are dumb key/value stores; they may have no locking operations. - -## a solution: remote locking - -What could be done is, change from checking if the remote has content, to -trying to lock it there. If the remote doesn't support locking, it can't -be guaranteed to have a copy. Require N locked copies for a drop to -succeed. - -So, drop --from would no longer be supported in these configurations. -To drop the content from C, B would have to --force the drop, or move the -content from C to B, and then drop it from B. - -### impact when using assistant/sync --content - -Need to consider whether this might cause currently working topologies -with the assistant/sync --content to no longer work. Eg, might content -pile up in a transfer remote? - -> The assistant checks after any transfer of an object if it should drop -> it from anywhere. So, it gets/puts, and later drops. -> Similarly, for sync --content, it first gets, then puts, and finally drops. - -> When dropping an object from remotes(s) + local, in `handleDropsFrom`, -> it drops from local first. So, this would cause content pile-up unless -> changed. -> -> Also, when numcopies > 1, a toplogy like -> `A(transfer) -- B(client) -- specials(backup)` would never be able to drop -> the file from A, because the specials don't support locking and it can't -> guarantee the content will remain on them. -> -> One solution might be to make sync --content/the assistant generate -> move operations, which can then ignore numcopies (like `move` does). -> So, move from A to B and then copy to the specials. -> -> Using moves does lead to a decrease in robustness. For example, in -> the topology `A(transfer) -- B(client) -- C (backup)`, with numcopies=2, -> and C intermittently connected, the current -> behavior with sync --content/assistant is for an object to reach B -> and then later C, and only then be removed from A. -> If moves were used, the object moves from A to B, and so there's only -> 1 copy instead of the 2 as before, in the interim until C gets connected. - -## a solution: minimal remote locking - -This avoids needing to special case moves, and has 2 parts. - -### to drop from remote - -Instead of requiring N locked copies of content when dropping, -require only 1 locked copy (either the local copy, or a git remote that -can be locked remotely). Check that content is on the other N-1 -remotes w/o requiring locking (but use it if the remote supports locking). - -Unlike using moves, this does not decrease robustness, most of the time; -barring the kind of race this bug is about, numcopies behaves as desired. -When there is a race, some of the non-locked copies might be removed, -dipping below numcopies, but the 1 locked copy remains, so the data is -never entirely lost. - -Dipping below desired numcopies in an unusual race condition, and then -doing extra work later to recover may be good enough. - -> Implemented, and I've now verified this solves the case above. -> Indeed, neither drop succeeds, because no copy can be locked. - -### to drop from local repo - -When dropping an object from the local repo, lock it for drop, -and then verify that N remotes have a copy -(without requiring locking on special remotes). - -So, this is done exactly as git-annex already does it. - -Like dropping from a remote, this can dip below numcopies in a race -condition involving special remotes. - -But, it's crucial that, despite the lack of locking of -content on special remotes, which may be the last copy, -the last copy never be removed in a race. Is this the case? - -We can prove that the last copy is never removed -by considering shapes of networks. - -1. Networks only connected by single special - remotes, and not by git-git repo connections. Such networks are - essentially a collection of disconnected smaller networks, each - of the form `R--S` -2. Like 1, but with more special remotes. `S1--R--S2` etc. -3. More complicated (and less unusal) are networks with git-git - repo connections, and no cycles. - These can have arbitrary special remotes connected in too. -4. Finally, there can be a cycle of git-git connections. - -The overall network may be larger and more complicated, but we need only -concern ourselves with the subset that has a particular object -or is directly connected to that subset; the rest is not relevant. - -So, if we can prove local repo dropping is safe in each of these cases, -it follows it's safe for arbitrarily complicated networks. - -Case 1: - -<pre> -2 essentially disconnected networks, R1--S and R2--S - -R1 (has) S (has) -R1 - -R1 wants to drop its local copy R2 wants to move from S -R1 locks its copy for drop R2 copies from S -R1 checks that S has a copy R2 locks its copy -R1 drops its local copy R2 drops from S - -R1 expected S to have the copy, and due to a race with R2, -S no longer had the copy it expected. But, this is not actually -a problem, because the copy moved to R2 and so still exists. - -So, this is ok! -</pre> - -Case 2: - -<pre> -2 essentially disconnected networks, S1--R1--S2 and S1--R2--S2 - -R1(has) S1 (has) -R2(has) S2 (has) - -R1 wants to move from S1 to S2 R2 wants to move from S2 to S1 -R1 locks its copy R2 locks its copy -R1 checks that S2 has a copy R2 checks that S1 has a copy -R1 drops from S1 R2 drops from S2 - -R1 and R2 end up each with a copy still, so this is ok, -despite S1 and S2 lacking a copy. - -If R1/R2 had not had a local copy, they could not have done a remote drop. -</pre> - -(Adding more special remotes shouldn't change how this works.) - -Case 3: - -<pre> -3 repos; B has A and C as remotes; A has C as remote; C is special remote. - -A (has) C (has) -B - -B wants to drop from C A wants to drop from A -B locks it on A -B drops from C A locks it on A for drop - (fails; locked by B) -B drops from C A keeps its copy - -ok! - -or, racing the other way - -B wants to drop from C A wants to drop from A - A locks it on A for drop -B locks it on A - (fails; locked by A) -C keeps its copy A drops its copy - -ok! -</pre> - -Case 4: - -But, what if we have a cycle? The above case 3 also works if B and A are in a -cycle, but what about a larger cycle? - -Well, a cycle necessarily involves only git repos, not special remotes. -Any special remote can't be part of a cycle, because a special remote -does not have remotes itself. - -As the remotes in the cycle are not special remotes, locking is done -of content on remotes when dropping it from local or another remote. -This locking ensures that even with a cycle, we're ok. For example: - -<pre> -4 repos; D is special remote w/o its own locking, and the rest are git -repos. A has remotes B,D; B has remotes C,D; C has remotes A,D - -A (has) D -B (has) -C (has) - -A wants to drop from A B wants to drop from B C wants to drop from C -A locks it on A for drop B locks it on B for drop C locks it on C for drop -A locks it on B B locks it on C C locks it on A - (fails; locked by B) (fails; locked by C) (fails; locked by A) - -Which is fine! But, check races.. - -A wants to drop from A B wants to drop from B C wants to drop from C -A locks it on A for drop C locks it on C for drop -A locks it on B (succeeds) C locks it on A - B locks it on B for drop (fails; locked by A) - (fails; locked by A) -A drops B keeps C keeps - -It can race other ways, but they all work out the same way essentially, -due to the locking. -</pre> - -# the bug, with moves - -`git annex move --from remote` is the same as a copy followed by drop --from, -so the same bug can occur then. - -But, the implementation differs from Command.Drop, so will also -need some changes. - -Command.Move.toPerform already locks local content for removal before -removing it, of course. So, that will interoperate fine with -concurrent drops/moves. Seems fine as-is. - -Command.Move.fromPerform simply needs to lock the local content -in place before dropping it from the remote. This satisfies the need -for 1 locked copy when dropping from a remote, and so is sufficent to -fix the bug. - -> done - -# drop ordering - -Consider the network: `T -- C --- (B1,B2)` - -When numcopies is 2, a file could start on T, get copied to C, and then on -the B1 and B2. At which point, it can be dropped from C and T (if -unwanted). - -Currently, the assistant and sync --content drop from the local repo 1st, -and then from remotes. Before the changes to fix this bug, that worked; -the content got removed from T and then from C, using the copies on B1 and -B2 as evidence. Now though, if B1 and B2 are special remotes, once the copy -is dropped from C, there is no locked copy available on (B1,B2), so the -subsequent drop from T fails. - -Changing the drop order lets C lock its own copy in order to -drop from T. then the local drop from C proceeds successfully without locking, -as local drops don't need locking. - -Course, there is a behavior change here.. Before, if B2 didn't exist, -the content would reach B2 and then be dropped from C, and then with only 2 -copies, it could not also be dropped from T. If the drop order changes, the -content is instead dropped from T and left on C. - -The new behavior seems better when T is a transfer remote, but perhaps not in -other cases. - -> implemented diff --git a/doc/bugs/content_not_present__58___cannot_lock.mdwn b/doc/bugs/content_not_present__58___cannot_lock.mdwn deleted file mode 100644 index 89bf04395..000000000 --- a/doc/bugs/content_not_present__58___cannot_lock.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. -Cannot lock files which are not present. This prevents converting v6 files from flat files to symlinks when they are missing. -If a file is not present, locking it should either replace it with a broken symlink, or continue on to the next file with a warning. - -### What steps will reproduce the problem? -I think this happened from unlocking a file in one v6 repo and syncing with a different v6 repo, perhaps via a v5 repo in the middle. In repo #2, the file became unlocked but missing for me. - -### What version of git-annex are you using? On what operating system? -6.20160528-g191d2ba on linux - -### Please provide any additional information below. - -[[!format sh """ - -# I am trying to lock all files in my repo to downgrade from v6 back to v5, for stability - -$ git annex lock -lock git/bup.git/bupindex.hlink git-annex: content not present; cannot lock - -# but I cannot -"""]] - -### 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) - -> Well, that was simply not implemented, but I've done so now. (unlocking -> too). [[done]] --[[Joey]] diff --git a/doc/bugs/content_not_present__58___cannot_lock/comment_1_9a9a53d85660531cc3843dc9f339f187._comment b/doc/bugs/content_not_present__58___cannot_lock/comment_1_9a9a53d85660531cc3843dc9f339f187._comment deleted file mode 100644 index d09bc9ed2..000000000 --- a/doc/bugs/content_not_present__58___cannot_lock/comment_1_9a9a53d85660531cc3843dc9f339f187._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="xloem" - subject="comment 1" - date="2016-06-05T02:57:42Z" - content=""" -comment to get replies emailed -"""]] diff --git a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found.mdwn b/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found.mdwn deleted file mode 100644 index 984d79a99..000000000 --- a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found.mdwn +++ /dev/null @@ -1,68 +0,0 @@ -### Please describe the problem. - -Adding BUILDER=stack support in 441573a9 breaks building debian based packages. - -### What steps will reproduce the problem? - -[[!format sh """ -$ debian/rules clean -dh clean - dh_testdir - dh_auto_clean - make -j1 clean -make[1]: Entering directory '/home/jtgeibel/repos/launchpad.net/git-annex' -debian/cabal-wrapper clean -debian/cabal-wrapper: 14: debian/cabal-wrapper: cabal: not found -Makefile:101: recipe for target 'clean' failed -make[1]: *** [clean] Error 127 -make[1]: Leaving directory '/home/jtgeibel/repos/launchpad.net/git-annex' -dh_auto_clean: make -j1 clean returned exit code 2 -debian/rules:12: recipe for target 'clean' failed -make: *** [clean] Error 2 -"""]] - -### What version of git-annex are you using? On what operating system? - -6.20160114 (Ubuntu wily & trusty) - -### Please provide any additional information below. - -I've patched this locally as follows. In the Makefile I've assumed that both cabal and stack support a clean command. - -[[!format patch """ -diff --git a/Makefile b/Makefile -index 342152c..977855a 100644 ---- a/Makefile -+++ b/Makefile -@@ -98,7 +98,7 @@ docs: mans - --exclude='users/*' --exclude='devblog/*' --exclude='thanks' - - clean: -- $(BUILDER) clean -+ if [ "$(BUILDER)" != ./Setup ]; then $(BUILDER) clean; fi - rm -rf tmp dist git-annex $(mans) configure *.tix .hpc \ - doc/.ikiwiki html dist tags Build/SysConfig.hs \ - Setup Build/InstallDesktopFile Build/EvilSplicer \ -diff --git a/debian/rules b/debian/rules -index e6ee592..3345fee 100755 ---- a/debian/rules -+++ b/debian/rules -@@ -1,6 +1,6 @@ - #!/usr/bin/make -f - --export BUILDER=debian/cabal-wrapper -+export BUILDER=./Setup - - STANDALONE_BUILD=$(shell grep -qe '^Package: git-annex-standalone' debian/control \ - && echo 1 || echo 0) -"""]] - - -### 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) - -git-annex has been a great way for me to explore both Haskell and software packaging. - -I enjoyed the interview on LWN. - -> I don't think this is a bug, I think build dependencies were not -> installed when building the package. [[done]] --[[Joey]] diff --git a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_1_a90cc2f0cc2b843a48866198ce6c3416._comment b/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_1_a90cc2f0cc2b843a48866198ce6c3416._comment deleted file mode 100644 index 2d788993e..000000000 --- a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_1_a90cc2f0cc2b843a48866198ce6c3416._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-20T18:36:57Z" - content=""" -"cabal: not found" - -Since cabal-install is a build-dependency of the package, why is cabal not -available? - -The debian package builds just fine here. I diagnose that the problem is on -your build system. - -All your patch is doing is modifying it to not build the package using -cabal. But, debian/cabal-wrapper's comments explain why we need to use -cabal. -"""]] diff --git a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_2_75106c66c846708dc798e28024710177._comment b/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_2_75106c66c846708dc798e28024710177._comment deleted file mode 100644 index 88d5b8860..000000000 --- a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_2_75106c66c846708dc798e28024710177._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="jtgeibel@4ad445b2ef940dedb1b6d9b19e3888e56b33541b" - nickname="jtgeibel" - subject="source-only build" - date="2016-01-21T05:09:52Z" - content=""" -Yeah, my patch is definitely incorrect. - -Until now, I've been able to build a source-only package on a local machine which does not have ghc, cabal, or any haskell libraries installed. The binary packages are then built in a PPA which includes backports of all the build-deps. I'd like to avoid adding that PPA and all those dependencies to my local machine. - -The top level command I'm using to build the source package is `gbp buildpackage --git-debian-branch=wily --git-sign-tags --git-tag -S -sa` and this adds `-d` when calling `dpkg-buildpackage` which does not check build dependencies and conflicts. - -For now I've installed the dependencies and have my v6 builds! Maybe `debian/cabal-wrapper` can detect the condition where cabal is not installed and the subcommand is \"clean\" and return success, since if cabal is not installed there won't be anything to clean. -"""]] diff --git a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_3_0e944b73b3bfe2edc310710f17807985._comment b/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_3_0e944b73b3bfe2edc310710f17807985._comment deleted file mode 100644 index 69bf69aa3..000000000 --- a/doc/bugs/debian__47__rules_clean_fails_with_with_cabal_not_found/comment_3_0e944b73b3bfe2edc310710f17807985._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-01-22T15:49:19Z" - content=""" -That's a reasonable thing to want to do. It might be that passing -nc to -dpkg-buildpackage would be the best thing to do. In any case, -I've adjusted the Makefile. -"""]] diff --git a/doc/bugs/detox___34__destroys__34___annex.mdwn b/doc/bugs/detox___34__destroys__34___annex.mdwn deleted file mode 100644 index 203858f9d..000000000 --- a/doc/bugs/detox___34__destroys__34___annex.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. - -I accidentally (entirely my fault!) ran detox (batch file renamer to eliminate spaces etc.) on a git-annex dir. -Alas detox substitutes every "--" with "-", thus "destroying" the annex. -Of course the objects are still there, just renamed so that the symlinks become broken. - -I solved it by copying the objects back from my backup (I have many rsynced backups) since I was too lazy to write a script to rename all the files... - -A good solution would be to provide a general script (or there is one already?) to try to recover situations like this one, maybe using shatag to identify data objects. - -### What steps will reproduce the problem? - -Just run detox -vr (verbose, recursive) on an annex - -### What version of git-annex are you using? On what operating system? - -5.20150819+g - -Linux - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - - -I currently have about a dozen annexes, local and remote (nfs, git), no other big problem apart from lack of speed when syncing - -> Closing since I don't see how any changes to git-annex can prevent this -> kind of problem. [[done]] --[[Joey]] diff --git a/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment b/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment deleted file mode 100644 index 73a041150..000000000 --- a/doc/bugs/detox___34__destroys__34___annex/comment_1_be530543f32133a96640e3e82a1bc241._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-13T17:36:29Z" - content=""" -git-annex tries to prevent this kind of thing by removing the write bit -from the the object storage directories. But I suppose that doesn't prevent -those directories from being renamed themselves (or from it turning on the -write bit to rename files inside them, if it goes so far). - -In the end, git-annex just can't help you if you feed your drive into a -indiscriminate shredder. Except helping you have a copy of the data in a -repository elsewhere. So I don't see how this is a bug in git-annex. - -But surely it's a massive bug in detox if it does anything inside .git or any -VCS directory? - -Anyway, the result after running this thing is similar to fsck having put -all your annexed objects in lost+found with useless names. I'd recover the -same way, by moving the annexed objects from .git/annex/objects into the -repository, and running git-annex add on them, so it will pick the same -hashes as before and will move the objects back into place. -See [[tips/recover_data_from_lost+found]]. -"""]] diff --git a/doc/bugs/detox___34__destroys__34___annex/comment_2_94831c9199e07c2eaef42b404277637b._comment b/doc/bugs/detox___34__destroys__34___annex/comment_2_94831c9199e07c2eaef42b404277637b._comment deleted file mode 100644 index f4f432bcd..000000000 --- a/doc/bugs/detox___34__destroys__34___annex/comment_2_94831c9199e07c2eaef42b404277637b._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="atrent" - subject="comment 2" - date="2015-11-16T07:50:29Z" - content=""" -I know it's not a git-annex bug, I'm not blaming, just noting that there may be chances of random renaming... As you say it's more of a detox bug (also rdfind messes hidden dirs). Thanks for pinpointing to \"recover data...\", it's the \"script\" I was searching for. -"""]] diff --git a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos.mdwn b/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos.mdwn deleted file mode 100644 index 7380b1b82..000000000 --- a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos.mdwn +++ /dev/null @@ -1,299 +0,0 @@ -### Please describe the problem. - -I am trying to setup a repo on my external music player, a Nokia N900 -device. It appears as a `vfat` filesystem from the outside, so -git-annex see it as a "crippled filesystem" and sets up direct mode -appropriately. - -The problem is that for some weird reason, the checkout somewhat fails -and i'm left with a basically emptied repo. The next `sync` commits -the removal of all files, and happily pushes that to the other repos, -pretty much irreversibly, unless i start fiddling with the git -history. - -What's going on? - -It seems the problem is because i setup my remote repo from scratch, -because doing a checkout fails, because the crippled filesystem -doesn't support files with: - -* colons (`:`) -* question marks (`?`) -* backslashes (`\`) -* double quotes (`"`) -* stars (`*`) -* irregular encoding (i.e. non-UTF8) - -I have found the following tools to be useful to cleanup the filesystem: - -* [convmv](http://tracker.debian.org/convmv) can massively re-encode filenames and may also be able to fix all the issues above, but i didn't test that -* [rename](http://tracker.debian.org/rename) can massively rename files according to certain patterns, I have used: - - rename 's/\?//' * - rename 's/://' * - rename 's/\\//' * - rename 's/"//' * - rename 's/*//' * - git add -A . - -Similar issues: - -* windows bugs: - * [[bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/]] - * [[bugs/Windows:_can__39__t_clone_repository/]] -* more general feature request: - [[forum/Wishlist:_rename_files__47__dirs_w__47___special_characters_if_filesystem_is_FAT/]] - -The above issue specifically request that files with "special" characters be supported in vFAT or even Windows, but here is a different issue: I am worried about potential data loss and lack of anti-foot-shooting device in case a user adds an external hard drive or USB key that are widely formatted as vFAT and then triggers destruction of all files (after garbage collection). - -### What steps will reproduce the problem? - -<pre> -git init nokia-n900/repo -cd nokia-n900/repo -git annex init -git remote add /srv/mp3 -git annex sync # sets up a synced/master branch with no files on the remote repo -cd /srv/mp3 -git annex sync # commits the removal of all files -</pre> - -I didn't expect that to fail: a test run here doesn't delete files on /srv/mp3... - -### What version of git-annex are you using? On what operating system? - -5.20141125, debian jessie. - -### Please provide any additional information below. - -Complete trace: - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[986]anarcat@marcos:~130$ cd /media/anarcat/Nokia\ N900/.sounds/ - -[1026]anarcat@marcos:.sounds130$ git init mp3-test -Dépôt Git vide initialisé dans /media/anarcat/Nokia N900/.sounds/mp3-test/.git/ -[1027]anarcat@marcos:.sounds$ cd mp3-test -[1028]anarcat@marcos:mp3-test$ git annex init -init - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -ok -(Recording state in git...) -[1029]anarcat@marcos:mp3-test$ git remote add origin /srv/mp3 -[1030]anarcat@marcos:mp3-test$ git annex sync -commit ok -pull origin -warning: no common commits -remote: Décompte des objets: 721895, fait. -remote: Compression des objets: 100% (194286/194286), fait. -remote: Total 721895 (delta 565247), reused 660087 (delta 526635) -Réception d'objets: 100% (721895/721895), 53.76 MiB | 5.45 MiB/s, fait. -Résolution des deltas: 100% (565247/565247), fait. -Depuis /srv/mp3 - * [nouvelle branche] git-annex -> origin/git-annex - * [nouvelle branche] master -> origin/master - * [nouvelle branche] synced/git-annex -> origin/synced/git-annex - * [nouvelle branche] synced/master -> origin/synced/master - -error: unable to create file Dri/Dirty Rotten LP/04 - Why?.mp3 (Argument invalide) -error: unable to create file Dri/Dirty Rotten LP/07 - Who Am I?.mp3 (Argument invalide) -error: unable to create file Dysrhythmia/Barriers and Passages/10 - Will the Spirit Prevail?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 06 - How Long Has This Been Going On?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 10 - What Is There to Say?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 19 - Baby, What Else Can I Do?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/The Best of The Song Books/Ella Fitzgerald - The Best of The Song Books - 14 - Why Was I Born? (Jan 6, 1963 in L.A.).ogg (Argument invalide) -error: unable to create file Fantomas/Fantomas/01 - Book 1: Page 1.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/02 - Book 1: Page 2.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/03 - Book 1: Page 3.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/04 - Book 1: Page 4.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/05 - Book 1: Page 5.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/06 - Book 1: Page 6.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/07 - Book 1: Page 7.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/08 - Book 1: Page 8.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/09 - Book 1: Page 9.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/10 - Book 1: Page 10.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/11 - Book 1: Page 11.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/12 - Book 1: Page 12.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/13 - Book 1: Page 13.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/14 - Book 1: Page 14.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/15 - Book 1: Page 15.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/16 - Book 1: Page 16.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/17 - Book 1: Page 17.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/18 - Book 1: Page 18.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/19 - Book 1: Page 19.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/20 - Book 1: Page 20.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/21 - Book 1: Page 21.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/22 - Book 1: Page 22.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/23 - Book 1: Page 23.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/24 - Book 1: Page 24.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/25 - Book 1: Page 25.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/26 - Book 1: Page 26.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/27 - Book 1: Page 27.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/28 - Book 1: Page 28.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/29 - Book 1: Page 29.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/30 - Book 1: Page 30.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/11 - Henry: Portrait Of A Serial Ki.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/15 - Twin Peaks: Fire Walk With Me.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/Fant�mas - The Director's Cut.m3u (Argument invalide) -error: unable to create file Francois Perusse/Parodie "La Fureur".mp3 (Argument invalide) -error: unable to create file Frank zappa/Fillmore East, June 1971/Frank Zappa & The Mothers Of Invention - Fillmore East, June 1971 - 03 - What Kind Of Girl Do You Think We Are?.ogg (Argument invalide) -error: unable to create file Frank zappa/Fillmore East, June 1971/Frank Zappa & The Mothers Of Invention - Fillmore East, June 1971 - 07 - Do You Like My New Car?.ogg (Argument invalide) -fatal: cannot create directory at 'Frank zappa/Joe's Garage: Acts I, II & III': Argument invalide -failed -(merging origin/git-annex into git-annex...) -(Recording state in git...) -push origin -Décompte des objets: 6, fait. -Delta compression using up to 2 threads. -Compression des objets: 100% (5/5), fait. -Écriture des objets: 100% (6/6), 700 bytes | 0 bytes/s, fait. -Total 6 (delta 2), reused 1 (delta 0) -To /srv/mp3 - 26fc58f..63cfaf8 git-annex -> synced/git-annex - 76ec411..8458b14 annex/direct/master -> synced/master -ok -git-annex: sync: 1 failed -[1052]anarcat@marcos:annex$ git annex sync -commit ok -pull origin -ok -push origin -Everything up-to-date -ok -# End of transcript or log. -"""]] - -Now on the remote repo, it destroys everything: - -<pre> -$ cd /srv/mp3 -$ git annex sync -[ backlog lost, because of the sheer number of files deleted ] -$ git diff --stat 91fda32 | tail -1 - 21923 files changed, 21923 deletions(-) -$ # 91fda32 is the last known good commit on the master branch there -</pre> - -Boom! Doing the following restores some sanity: - -<pre> -$ git reset --hard 91fda32 -$ git branch -D synced/master -$ git annex sync -</pre> - -On the direct repo, now sync doesn't destroy anything, but then again, -there are no files either. Eventually, after enough `sync` commands, -the destruction will return... - -A clone also fails similarly, which is why i was trying with the -"clean init" approach: - -<pre> -[1032]anarcat@marcos:.sounds$ git clone /srv/mp3 mp3-clone -Clonage dans 'mp3-clone'... -fait. -error: unable to create file Dri/Dirty Rotten LP/04 - Why?.mp3 (Argument invalide) -error: unable to create file Dri/Dirty Rotten LP/07 - Who Am I?.mp3 (Argument invalide) -error: unable to create file Dysrhythmia/Barriers and Passages/10 - Will the Spirit Prevail?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 06 - How Long Has This Been Going On?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 10 - What Is There to Say?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 19 - Baby, What Else Can I Do?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/The Best of The Song Books/Ella Fitzgerald - The Best of The Song Books - 14 - Why Was I Born? (Jan 6, 1963 in L.A.).ogg (Argument invalide) -Extraction des fichiers: 24% (5433/21923) -[...] -[1036]anarcat@marcos:.sounds130$ git clone /srv/mp3 mp3-clone -Clonage dans 'mp3-clone'... -fait. -error: unable to create file Dri/Dirty Rotten LP/04 - Why?.mp3 (Argument invalide) -error: unable to create file Dri/Dirty Rotten LP/07 - Who Am I?.mp3 (Argument invalide) -error: unable to create file Dysrhythmia/Barriers and Passages/10 - Will the Spirit Prevail?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 06 - How Long Has This Been Going On?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 10 - What Is There to Say?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/Pure Ella/Ella Fitzgerald - Pure Ella - 19 - Baby, What Else Can I Do?.ogg (Argument invalide) -error: unable to create file Ella Fitzgerald/The Best of The Song Books/Ella Fitzgerald - The Best of The Song Books - 14 - Why Was I Born? (Jan 6, 1963 in L.A.).ogg (Argument invalide) -error: unable to create file Fantomas/Fantomas/01 - Book 1: Page 1.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/02 - Book 1: Page 2.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/03 - Book 1: Page 3.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/04 - Book 1: Page 4.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/05 - Book 1: Page 5.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/06 - Book 1: Page 6.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/07 - Book 1: Page 7.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/08 - Book 1: Page 8.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/09 - Book 1: Page 9.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/10 - Book 1: Page 10.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/11 - Book 1: Page 11.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/12 - Book 1: Page 12.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/13 - Book 1: Page 13.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/14 - Book 1: Page 14.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/15 - Book 1: Page 15.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/16 - Book 1: Page 16.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/17 - Book 1: Page 17.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/18 - Book 1: Page 18.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/19 - Book 1: Page 19.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/20 - Book 1: Page 20.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/21 - Book 1: Page 21.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/22 - Book 1: Page 22.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/23 - Book 1: Page 23.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/24 - Book 1: Page 24.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/25 - Book 1: Page 25.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/26 - Book 1: Page 26.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/27 - Book 1: Page 27.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/28 - Book 1: Page 28.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/29 - Book 1: Page 29.mp3 (Argument invalide) -error: unable to create file Fantomas/Fantomas/30 - Book 1: Page 30.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/11 - Henry: Portrait Of A Serial Ki.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/15 - Twin Peaks: Fire Walk With Me.mp3 (Argument invalide) -error: unable to create file Fantomas/The Director's Cut/Fant�mas - The Director's Cut.m3u (Argument invalide) -error: unable to create file Francois Perusse/Parodie "La Fureur".mp3 (Argument invalide) -error: unable to create file Frank zappa/Fillmore East, June 1971/Frank Zappa & The Mothers Of Invention - Fillmore East, June 1971 - 03 - What Kind Of Girl Do You Think We Are?.ogg (Argument invalide) -error: unable to create file Frank zappa/Fillmore East, June 1971/Frank Zappa & The Mothers Of Invention - Fillmore East, June 1971 - 07 - Do You Like My New Car?.ogg (Argument invalide) -fatal: cannot create directory at 'Frank zappa/Joe's Garage: Acts I, II & III': Argument invalide -warning: Le clone a réussi, mais l'extraction a échoué. -Vous pouvez inspecter ce qui a été extrait avec 'git status' -et réessayer l'extraction avec 'git checkout -f HEAD' -</pre> - -Besides, `clone` creates actually seems to create and transfer all the files and setup direct mode (!?), which takes up too much space on this external drive... - -Interestingly, i have managed to clone the repo by cleaning up a lot of space and fixing the above errors. Interestingly, the git clone is only 2GB while the original repo is closer to 110GB. There's nevertheless a bunch of files checked out, and obviously, enabling git-annex on the repo gives the predictable: - -<pre> -$ git annex sync - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. - - Detected a crippled filesystem. - - Enabling direct mode. -git-annex: /media/anarcat/Nokia N900/.sounds/mp3-clone/.git/annex/objects/cec/e45/SHA256E-s3547512--6d0b48b144ba58cf649134c7b4d6597f4e0c5f319302f1c109d0967f22af607a.mp3: createDirectory: resource exhausted (No space left on device) -</pre> - -... and leaves the repo in an inconsistent state again. Also note that the above took over 2 hours of wall clock time before failing. - -### 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) - -Git-annex has been my bread and butter for a few months in the past -year. I absolutely love it and it generally makes my life much easier -when dealing with large files. Direct mode sometimes drives me nuts, -but it certainly is more the fault to the damn crippled filesystems -than git-annex's fault for sure. :) - -Arguably, the above problems are partly due to me assuming that -git-annex will work well on crippled filesystems, regardless of my -dataset, which maybe an inaccurate assumption. - -Thanks for all your hard work! --[[anarcat]] - -> [[fixed|done]] diff --git a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_1_8b2f7e960cf0ed043c5ad070d6fc08e2._comment b/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_1_8b2f7e960cf0ed043c5ad070d6fc08e2._comment deleted file mode 100644 index a3eace0d5..000000000 --- a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_1_8b2f7e960cf0ed043c5ad070d6fc08e2._comment +++ /dev/null @@ -1,38 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""analysis""" - date="2015-10-15T17:30:12Z" - content=""" -git merge fails because it cannot write to these filenames. - -git-annex assumes that, if git merge failed, there was a merge conflict, so -the automatic merge conflict resolution code is run. There are probably no -unmerged files in this case. So, the automatic merge conflict resolution -finds nothing to do, probably. - -However, since the automatic merge conflict resolution code ran, it now -assumes the merge has been dealt with, and proceeds to clean up, including -making a merge commit. - -The merge commit is where the file "removal" happens. It should bail out -before that point. - -The best fix would be to detect that git merge has crashed early and skip -all the merge conflict resolution etc. How? git merge uses the same -exit status for this kind of crash as it does for an unresolved merge -conflict. - -It could notice that there are no merge conflicts to be found, and so know -the merge failed for some other reason. However, what if there are both -merge conflicts and illegal filenames? Testing that situation, git merge -seems to always crash on creating the illegal files, before it updates -git state to reflect any merge conflicts. So, this approach seems to work. - -(It could also look for .git/MERGE_HEAD, which is written after a -conflicted merge.) - ----- - -Note that mentions of repo size etc later in this bug report don't seem to -be related to this problem. -"""]] diff --git a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_2_c29094478fc0f1b9e5475f27bd681ec8._comment b/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_2_c29094478fc0f1b9e5475f27bd681ec8._comment deleted file mode 100644 index e8ad87b38..000000000 --- a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_2_c29094478fc0f1b9e5475f27bd681ec8._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - subject="amazing" - date="2015-10-17T02:17:13Z" - content=""" -thanks so much for the fast response time! :) and yes, the comments about the file size are unrelated ranting on my part, sorry about that. :) - -i wonder if [[bugs/direct_command_leaves_repository_inconsistent_if_interrupted/]] may not be related to this / fixed by the change... - -thanks again, great job. :) -"""]] diff --git a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_3_b2a029fc9f4765633ef5393fe091016e._comment b/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_3_b2a029fc9f4765633ef5393fe091016e._comment deleted file mode 100644 index 36555e30d..000000000 --- a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_3_b2a029fc9f4765633ef5393fe091016e._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="Kalle" - subject="Had what I believe to be the same issue" - date="2016-03-31T21:22:21Z" - content=""" -[[Podcast_filename_encoding_breaks_Android_client/]] - -The problem for me was that the podcatcher setup would automatically download new dangerous files and wipe all repos... My workaround in the end was to use ``--template`` to create date only filenames for podcasts. A solution I still use but it's rather inconvenient as more descriptive filenames are useful. - -This is quite a dangerous bug as all you need is a direct mode repo and an unusual filename for your whole annex cluster to empty itself. It can be saved by git surgery but unless being very careful you just end up syncing the bad filename back from a repo or another. - - -"""]] diff --git a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_4_587db5d4a9007a60a63f8fdf5cf01208._comment b/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_4_587db5d4a9007a60a63f8fdf5cf01208._comment deleted file mode 100644 index cf25fe1cd..000000000 --- a/doc/bugs/direct_cripple_mode_crippled_my_other_non-crippled_repos/comment_4_587db5d4a9007a60a63f8fdf5cf01208._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-04-04T18:55:50Z" - content=""" -@Kalle but this bug was fixed in October 2015 as far as we know. - -If you experienced the bug with a version of git-annex newer than -5.20151019, then this bug ought to be re-opened. But I'm pretty sure I -reproduced the bug back then, fixed it, and tested the fix. -"""]] diff --git a/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn b/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn deleted file mode 100644 index dbaceb9ea..000000000 --- a/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -### Please describe the problem. - -spotted that in my script I have "incorrectly" passed both -c and its value within the same single argument ('-c annex....'). But surprisingly annex neither treated it correctly, nor complained that something was incorrectly passed in. Shouldn't it fail if option is not '-c' but '-c smthelse' or correctly treat the value in such as case? - -### What version of git-annex are you using? On what operating system? - -5.20151104+gitge9cdce6-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ -$> ls -ld svgtune-0.2.0/README.rst --rw------- 1 yoh yoh 9 Nov 12 12:03 svgtune-0.2.0/README.rst - -$> git-annex add --debug '-c annex.largefiles=exclude=*.rst' svgtune-0.2.0/README.rst -add svgtune-0.2.0/README.rst ok -(recording state in git...) - -$> ls -ld svgtune-0.2.0/README.rst -lrwxrwxrwx 1 yoh yoh 189 Nov 12 12:03 svgtune-0.2.0/README.rst -> ../.git/annex/objects/32/vx/SHA256E-s9--246c960678ee9a80aa6d2eff2f1df1debd590cb73aa5fed6cb4b13b8018599f5.rst/SHA256E-s9--246c960678ee9a80aa6d2eff2f1df1debd590cb73aa5fed6cb4b13b8018599f5.rst -"""]] - -[[!meta author=yoh]] - -> I guess it could be considered [[done]] --[[yoh]] - diff --git a/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c/comment_1_e4a67f2feaf7060ce56c37d6a82b5003._comment b/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c/comment_1_e4a67f2feaf7060ce56c37d6a82b5003._comment deleted file mode 100644 index b0158daa7..000000000 --- a/doc/bugs/does_not_complain__47__fail_if_by_mistake_option_value_passed_within_arg_for__-c/comment_1_e4a67f2feaf7060ce56c37d6a82b5003._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-16T18:11:02Z" - content=""" -I think what's going on here is that -cfoo=bar is the same as -c foo=bar, -and in this case the "foo" happens to contain a space. Since a -c config -can be passed through to git to override any git config, git-annex doesn't -try to validate them. -"""]] diff --git a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn deleted file mode 100644 index 8dcf3b6fc..000000000 --- a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -just want to check if that is "by design"... --force was demanded seem operation is dangerous, but I expected that it would still report success false if key was not actually dropped, at least if a key is a completely wrong key - -so is that "by design" and I shouldn't care to check success field...? - -### What version of git-annex are you using? On what operating system? -6.20160425+gitgffe2ea2-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force -{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true} - -$> ls -l -total 0 -0 lrwxrwxrwx 1 yoh yoh 110 Apr 29 09:21 124 -> .git/annex/objects/MV/Jw/MD5E-s11--74d80f7d99b835e5189948c8d4297efd/MD5E-s11--74d80f7d99b835e5189948c8d4297efd - -$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force -{"command":"dropkey","key":"MD5E-s11--74d80f7d99b835e5189948c8d4297efd","success":true} - -$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd | git annex dropkey --batch --json --force -{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efd","success":true} - -$> echo MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf | git annex dropkey --batch --json --force -{"command":"dropkey","key":"MD5E-s11--74d80f7dsd99b835e5189948c8d4297efdsdfsdf","success":true} - - -"""]] - -[[!meta author=yoh]] - -> [[notabug|done]] --[[Joey]] diff --git a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_1_b913175c341d39e6b9d354213677248c._comment b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_1_b913175c341d39e6b9d354213677248c._comment deleted file mode 100644 index 4e22e90ce..000000000 --- a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_1_b913175c341d39e6b9d354213677248c._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-03T17:03:25Z" - content=""" -Note that dropkey does *not* check if other copies exist, so the --force is -unncessary; eg it's always forced by default. - -Anyway, dropkey will indicate a failure if it's actually unable to drop the -content for some reason, eg a permissions problem or the content is locked -to prevent it being dropped right now, or other unanticipated error. -But, if the content of the key is not present, it's successfully -gotten the repo into the requested state. - -Similarly, git-annex transferkey will return success if the key it was -supposed to download is already present. - -I don't consider this a bug, although am willing to be convinced -otherwise.. -"""]] diff --git a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_2_ed5dfbc812e20efa4650a7a4684faa6d._comment b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_2_ed5dfbc812e20efa4650a7a4684faa6d._comment deleted file mode 100644 index 6c95675ca..000000000 --- a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_2_ed5dfbc812e20efa4650a7a4684faa6d._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-05-03T17:53:41Z" - content=""" -gotcha -- so it is a feature, so you could mark this one \"done\" - -But note, that although --force is indeed not necessary it is required atm - -[[!format sh \"\"\" -$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json -git-annex: dropkey can cause data loss; use --force if you're sure you want to do this - -$> echo MD5E-s11--74d80f7d99b835e5189948c8d4297efd | git annex dropkey --batch --json --force -{\"command\":\"dropkey\",\"key\":\"MD5E-s11--74d80f7d99b835e5189948c8d4297efd\",\"success\":true} - -$> git annex version -git-annex version: 6.20160425+gitgffe2ea2-1~ndall+1 - -\"\"\"]] -"""]] diff --git a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_3_d2957afd7fd689ce9d28258d2bbd375e._comment b/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_3_d2957afd7fd689ce9d28258d2bbd375e._comment deleted file mode 100644 index 8d14f0247..000000000 --- a/doc/bugs/dropkey_--batch_--json_--force_is_always_succesfull/comment_3_d2957afd7fd689ce9d28258d2bbd375e._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-05-03T18:08:11Z" - content=""" -Oh, I had forgotten about it requiring --force. - -That's actually good; it means I could make dropkey without --force -check that other copies of the content exist, and refuse to drop in that -case. -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__.mdwn b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__.mdwn deleted file mode 100644 index 21e1d4446..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!format sh """ -$> git annex version -git-annex version: 6.20160213+gitg9597a21-1~ndall+1 -... -$> git annex get -J 5 . -get docs/freesurfer.groupanalysis.ppt (from origin...) (checksum...) ok -get docs/freesurfer.future_directions.2007.ppt (from origin...) (checksum...) ok -get docs/freesurfer.groupanalysis.short.ppt (from origin...) (checksum...) ok -get distribution/trctrain/trctraindata.tar.gz (from origin...) -47% 80.2MB/s 3s -47% 80.2MB/s 3s -get docs/freesurfer.inferring_architectonics.ppt (from origin...) -33% 8.1MB/s 4s -33% 8.1MB/s 4s -get docs/freesurfer.intro.2011.ppt (from origin...) -64% 7.3MB/s 1s -64% 7.3MB/s 1s -get docs/freesurfer.intro.mmclass.ppt (from origin...) -# End of transcript or log. -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_1_396b436e5fec8fc492d9595afa5f6a85._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_1_396b436e5fec8fc492d9595afa5f6a85._comment deleted file mode 100644 index 567c494ad..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_1_396b436e5fec8fc492d9595afa5f6a85._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-14T20:40:45Z" - content=""" -Is this git-annex built with the ConcurrentOutput flag? - -It kind of looks like it; if so the only thing that looks wrong -is there are for some reason two copies of each progress line for each -file. - -I don't see this in my testing.. -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_2_1c348653d630e40e2ff87b7f6c159b35._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_2_1c348653d630e40e2ff87b7f6c159b35._comment deleted file mode 100644 index 6e326e59e..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_2_1c348653d630e40e2ff87b7f6c159b35._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-03-14T21:05:06Z" - content=""" -FWIW it was \"stock\" debian/neurodebian build so whatever default or flags you impose in debian/rules -- they were it ;) - -[[!format sh \"\"\" -neurodebian@smaug ..annex/6.20160213+gitg9597a21-1~ndall+1 % grep Concur git-annex_6.20160213+gitg9597a21-1~ndall+1_amd64.build -[178 of 534] Compiling Messages.Concurrent ( Messages/Concurrent.hs, dist/build/git-annex/git-annex-tmp/Messages/Concurrent.o ) -[239 of 534] Compiling Annex.Concurrent ( Annex/Concurrent.hs, dist/build/git-annex/git-annex-tmp/Annex/Concurrent.o ) -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi - -\"\"\"]] -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_3_4600a48aa4c00102b2974c1ae18f6db7._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_3_4600a48aa4c00102b2974c1ae18f6db7._comment deleted file mode 100644 index 4acf1465b..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_3_4600a48aa4c00102b2974c1ae18f6db7._comment +++ /dev/null @@ -1,52 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 3" - date="2016-03-14T21:10:56Z" - content=""" -just rechecked with freshier version: - -[[!format sh \"\"\" -% git clone https://surfer.nmr.mgh.harvard.edu/pub/dist/freesurfer/repo/freesurfer.git -Cloning into 'freesurfer'... -Checking connectivity... done. -% cd freesurfer -% git annex get -J 5 . -(merging origin/git-annex origin/synced/git-annex into git-annex...) -get BrainstemSS/AtlasDump.mgz (from origin...) (checksum...) ok -get BrainstemSS/AtlasMesh.gz (from origin...) -get GEMS/data/CurrentMeshCollection30.gz - not enough free space, need 2.94 MB more (use --force to override this check or adjust annex.diskreserve) - - Unable to access these remotes: origin - - Try making some of these repositories available: - 14311777-6106-4ba8-8356-2bfb0d198b64 -- zkaufman@sand:/autofs/space/sand_001/users/zkaufman/temp/stable.sync/dev.git - 58892d74-dae0-4bd1-a160-011e82d201f2 -- sand trunk - 6d0bc2d9-c184-445c-82d0-b5c56c5bf5d9 -- zkaufman@gust.nmr.mgh.harvard.edu:/autofs/space/sand_001/users/zkaufman/freesurfer_lion/trunk/dev - 739a31b2-febf-43ee-be59-713bdaa01a06 -- sand-sync - 9240fb38-adbe-4bfe-847a-bdd98d570f75 -- [origin] - ba0b9401-2821-41d2-b9fc-f3319dc053e3 -- sand stable6 - d018cb1b-c841-48b8-ba50-11b686a5c6ad -failed -get BrainstemSS/mac_osx/segmentSubject.app/Contents/Resources/membrane.icns (from origin...) (checksum...) ok -get BrainstemSS/AtlasMesh.gz (from origin...) -.... -get BrainstemSS/AtlasMesh.gz (from origin...) -19% 336.0KB/s 4s -19% 336.0KB/s 4s -get BrainstemSS/linux_x86_64/SegmentSubject.bin (from origin...) -10% 640.0KB/s 9s -10% 640.0KB/s 9s -get BrainstemSS/mac_osx/segmentSubject.app/Contents/MacOS/segmentSubject (from origin...) -18% 864.0KB/s 4s -18% 864.0KB/s 4s -get distribution/average/Buckner_JNeurophysiol11_MNI152/Buckner2011_7Networks_MNI152_FreeSurferConformed1mm_LooseMask.nii.gz (from origin -...) -get distribution/average/Buckner_JNeurophysiol11_MNI152/Buckner2011_7Networks_MNI152_FreeSurferConformed1mm_TightMask.nii.gz (from origin -...) -^C -% git annex version -git-annex version: 6.20160307+gitgb095561-1~ndall+1 -... -\"\"\"]] -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_4_2d9188d4cf91bf47ee2b4e7bc1a1ca3e._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_4_2d9188d4cf91bf47ee2b4e7bc1a1ca3e._comment deleted file mode 100644 index f520ce726..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_4_2d9188d4cf91bf47ee2b4e7bc1a1ca3e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-04-19T15:33:22Z" - content=""" -Is this using datalad's special remotes that use git-annex to download -nested objects? -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_098b35e01bef2105cac5ee2c70729f90._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_098b35e01bef2105cac5ee2c70729f90._comment deleted file mode 100644 index fdb460d63..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_098b35e01bef2105cac5ee2c70729f90._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 5" - date="2016-04-19T16:24:50Z" - content=""" -nope - this is a straight annex repo, nothing to do with datalad (for now at least ;) ), no special remotes were listed above either -"""]] diff --git a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_7b0048871f939b566b5c65d0bf7ab968._comment b/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_7b0048871f939b566b5c65d0bf7ab968._comment deleted file mode 100644 index dfe2e9b07..000000000 --- a/doc/bugs/duplicate_progress_reports_in_parallel___39__get__39__/comment_5_7b0048871f939b566b5c65d0bf7ab968._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-04-19T16:50:02Z" - content=""" -Reproduced it. The crucial thing is that this is a download from a git -remote over http. Seems that in that case, the same progress info ends up -getting fed into two separate progress meters. -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build.mdwn b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build.mdwn deleted file mode 100644 index f21bb2664..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build.mdwn +++ /dev/null @@ -1,123 +0,0 @@ -### Please describe the problem. - -datalad tests started to fail whenever I upgraded to todays fresh snapshot build. But the reason is somewhat bizzar since addurl works (with the same output in --debug for curl invocation) if I downgrade to the snapshot build from few days back. And I don't see any obviously related changes in the git log since prev snapshot :-/ - -### What version of git-annex are you using? On what operating system? - -5.20150826+gitg87972f5-1~ndall+1 custom standalone build on (neuro)debian - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$> git-annex addurl --file=test-annex.dat --debug 'file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat' -[2015-08-26 10:45:06.289638] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2015-08-26 10:45:06.291676] process done ExitSuccess -[2015-08-26 10:45:06.291908] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2015-08-26 10:45:06.293961] process done ExitSuccess -[2015-08-26 10:45:06.294297] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8a3167950d25c6626db5c31c334b024f43d132d8","-n1","--pretty=%H"] -[2015-08-26 10:45:06.296672] process done ExitSuccess -[2015-08-26 10:45:06.297441] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2015-08-26 10:45:06.300078] read: quvi ["--version"] -[2015-08-26 10:45:06.303888] process done ExitSuccess -[2015-08-26 10:45:06.304279] call: quvi ["--verbosity","mute","--support","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat"] -[2015-08-26 10:45:06.31382] process done ExitFailure 65 -addurl test-annex.dat (downloading file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat ...) -[2015-08-26 10:45:06.314824] call: curl ["-f","-L","-C","-","-#","-o","/tmp/datalad_temp_testrepo_NKOjKp/.git/annex/tmp/URL-s4--file&c%%%tmp%datalad_temp_testrepo_NKOjKp%test.dat","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat","--user-agent","git-annex/5.20150826+gitg87972f5-1~ndall+1"] -[2015-08-26 10:45:06.319563] process done ExitFailure (-11) -failed -git-annex: addurl: 1 failed - - -$> acpolicy git-annex-standalone -git-annex-standalone: - Installed: 5.20150826+gitg87972f5-1~ndall+1 - Candidate: 5.20150826+gitg87972f5-1~ndall+1 - Version table: - *** 5.20150826+gitg87972f5-1~ndall+1 0 - 100 /var/lib/dpkg/status - 5.20150819+gitgc587698-1~ndall+1 0 - 500 http://neuro.debian.net/debian/ stretch/main amd64 Packages - -# downgrading to previous snapshot - -$> sudo apt-get install git-annex-standalone=5.20150819+gitgc587698-1~ndall+1 -[sudo] password for yoh: -Reading package lists... Done -Building dependency tree -Reading state information... Done -The following packages were automatically installed and are no longer required: - gir1.2-gtop-2.0 gir1.2-vte-2.90 gstreamer0.10-plugins-ugly icu-devtools libb-hooks-endofscope-perl libbit-vector-perl libcamel-1.2-49 libcarp-clan-perl libcmis-0.4-4 - libconstantine-java libdate-calc-perl libdate-calc-xs-perl libdirac-encoder0 libdvbpsi9 libebackend-1.2-7 libebook-1.2-14 libebook-contacts-1.2-0 libecal-1.2-16 - libedata-book-1.2-20 libedata-cal-1.2-23 libedataserver-1.2-18 libegl1-mesa-drivers libelfg0 libgdata19 libgdict-1.0-6 libghc-adjunctions-dev libghc-base-unicode-symbols-dev - libghc-errors-dev libghc-failure-dev libghc-idna-dev libghc-kan-extensions-dev libghc-keys-dev libghc-pointed-dev libghc-publicsuffixlist-dev libghc-punycode-dev - libghc-ranges-dev libghc-stringprep-dev libghc-text-icu-dev libgit2-21 libglew1.11 libglew1.9 libgnutls26 libgphoto2-port10 libgsoap5 libgtkhtml-4.0-0 libgtkhtml-4.0-common - libgtkhtml-editor-4.0-0 libgtop2-7 libicu-dev libinput5 libisl10 libjaffl-java libjim0.75 libkscreen1 libmediaart-1.0-0 libmodello-java libnamespace-clean-perl libopenobex1 - libopenvg1-mesa liborcus-0.8-0 libplexus-digest-java libplist2 libqcustomplot1.2 libqscintilla2-11 librhythmbox-core8 librygel-core-2.4-2 librygel-renderer-2.4-2 - librygel-renderer-gst-2.4-2 librygel-server-2.4-2 libssh-4 libsub-identify-perl libvariable-magic-perl libvncclient0 libvncserver0 libvpx1 libwps-0.3-3 libx264-142 libx265-43 - obex-data-server publicsuffix -Use 'apt-get autoremove' to remove them. -Suggested packages: - bup tahoe-lafs -The following packages will be DOWNGRADED: - git-annex-standalone -0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 888 not upgraded. -Need to get 0 B/23.9 MB of archives. -After this operation, 13.3 kB disk space will be freed. -Do you want to continue? [Y/n] -dpkg: warning: downgrading git-annex-standalone from 5.20150826+gitg87972f5-1~ndall+1 to 5.20150819+gitgc587698-1~ndall+1 -(Reading database ... 513649 files and directories currently installed.) -Preparing to unpack .../git-annex-standalone_5.20150819+gitgc587698-1~ndall+1_amd64.deb ... -Unpacking git-annex-standalone (5.20150819+gitgc587698-1~ndall+1) over (5.20150826+gitg87972f5-1~ndall+1) ... -Processing triggers for man-db (2.7.0.2-5) ... -Setting up git-annex-standalone (5.20150819+gitgc587698-1~ndall+1) ... -Processing triggers for libc-bin (2.19-18) ... - - -hopa:/tmp/datalad_temp_testrepo_NKOjKp -$> git-annex addurl --file=test-annex.dat --debug 'file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat' -[2015-08-26 10:45:43.856957] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"] -[2015-08-26 10:45:43.859253] process done ExitSuccess -[2015-08-26 10:45:43.859507] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2015-08-26 10:45:43.861503] process done ExitSuccess -[2015-08-26 10:45:43.861842] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..8a3167950d25c6626db5c31c334b024f43d132d8","-n1","--pretty=%H"] -[2015-08-26 10:45:43.864027] process done ExitSuccess -[2015-08-26 10:45:43.864822] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"] -[2015-08-26 10:45:43.867559] read: quvi ["--version"] -[2015-08-26 10:45:43.871844] process done ExitSuccess -[2015-08-26 10:45:43.872416] call: quvi ["--verbosity","mute","--support","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat"] -[2015-08-26 10:45:43.88296] process done ExitFailure 65 -addurl test-annex.dat (downloading file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat ...) -[2015-08-26 10:45:43.883939] call: curl ["-f","-L","-C","-","-#","-o","/tmp/datalad_temp_testrepo_NKOjKp/.git/annex/tmp/URL-s4--file&c%%%tmp%datalad_temp_testrepo_NKOjKp%test.dat","file:///tmp/datalad_temp_testrepo_NKOjKp/test.dat","--user-agent","git-annex/5.20150819+gitgc587698-1~ndall+1"] -######################################################################## 100.0% -[2015-08-26 10:45:43.889054] process done ExitSuccess -[2015-08-26 10:45:43.889446] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","check-attr","-z","--stdin","annex.backend","annex.numcopies","--"] -[2015-08-26 10:45:43.89022] read: git ["--version"] -[2015-08-26 10:45:43.891664] process done ExitSuccess -ok -(recording state in git...) -[2015-08-26 10:45:43.896364] feed: xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","add","--"] -[2015-08-26 10:45:43.899267] process done ExitSuccess -[2015-08-26 10:45:43.899949] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","hash-object","-w","--stdin-paths","--no-filters"] -[2015-08-26 10:45:43.901383] feed: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-index","-z","--index-info"] -[2015-08-26 10:45:43.905978] process done ExitSuccess -[2015-08-26 10:45:43.906404] process done ExitSuccess -[2015-08-26 10:45:43.906633] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2015-08-26 10:45:43.908796] process done ExitSuccess -[2015-08-26 10:45:43.909363] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","write-tree"] -[2015-08-26 10:45:43.912179] process done ExitSuccess -[2015-08-26 10:45:43.912423] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","commit-tree","0ece4d39e673b48c886ccfded0bb4c588596e6d6","--no-gpg-sign","-p","refs/heads/git-annex"] -[2015-08-26 10:45:43.915128] process done ExitSuccess -[2015-08-26 10:45:43.915362] call: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","update-ref","refs/heads/git-annex","0f17facd87dbca08de5bc4d9c29bc7004557d4cf"] -[2015-08-26 10:45:43.9179] process done ExitSuccess - - - -# End of transcript or log. -"""]] - -### 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) - - -> I see that #796899 is fixed in debian unstable, so [[done]] --[[Joey]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_1_557c9147078e04f7b62a873bf94f7b6a._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_1_557c9147078e04f7b62a873bf94f7b6a._comment deleted file mode 100644 index 7a6d6831e..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_1_557c9147078e04f7b62a873bf94f7b6a._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T16:25:05Z" - content=""" -The -11 exit status is pretty unusual. Being negative suggests that curl -died of a signal (and so the high bit was set to indicate that). - -I guess that signal would probably be a SIGSEGV. - -Perhaps this is an intermittent memory problem and git-annex version is not -relevant. I also see no changes in how git-annex calls curl. -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_3750368dfb19c90724670345c1b58f13._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_3750368dfb19c90724670345c1b58f13._comment deleted file mode 100644 index 2e9081f9e..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_3750368dfb19c90724670345c1b58f13._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-09-09T22:18:28Z" - content=""" -Well, I've verified that `ExitFailure -11` does mean the called program -segfaulted. I don't see how git-annex could cause curl to segfault. - -How would you quantify the experimental error of your upgrade/downgrade experiment? ;) -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_44e295cb49cbce486577129d90ee6bb9._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_44e295cb49cbce486577129d90ee6bb9._comment deleted file mode 100644 index 82b5ce17a..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_2_44e295cb49cbce486577129d90ee6bb9._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-09-09T22:14:22Z" - content=""" -Those effects were 100% reproducible by down/up-grading annex so not really intermittent. I did indeed check annex dev history and saw nothing obvious -- that is why decided to ask. I guess I will build even freshier snapshot now and see how that one copes -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_4_367447b316e08d833f38349b9c86fd49._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_4_367447b316e08d833f38349b9c86fd49._comment deleted file mode 100644 index a22a49999..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_4_367447b316e08d833f38349b9c86fd49._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 4" - date="2015-09-09T22:44:47Z" - content=""" -I thought I have earned some trust ;) I did quite a few up/down upgrades, so it was from about 3-4 trials and thus 100% replicable among them... even though no changes to curl calls, may be bundled curl was different (bundled builds) etc, or some changes to annex environment. dunno (might be handy if git annex version reported versions of bundled stuff... wouldn't it? ;)) -unfortunately for that very reason I didn't upload 0826 version to neurodebian so can't very easily replicate atm. Thus I will build a new one and will confirm or disconfirm eventually -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_5_cdd169574e50951bbb9d8fdd310f8bcc._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_5_cdd169574e50951bbb9d8fdd310f8bcc._comment deleted file mode 100644 index f90c685a7..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_5_cdd169574e50951bbb9d8fdd310f8bcc._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="problems with bundling???" - date="2015-09-10T03:50:45Z" - content=""" -built yet another one, locally (not a clean sid but rather a cocktail env) with curl being capable of fetching (see below) using file:/// but annex failing and me not clear on how to invoke bundled curl correctly (or as demonstrated may be it behaving incorrectly?)... then downgraded again and bundled curl succeeded. So it seems that there is an issue with how things are bundled -- was there any change in that may be? - -[[!format sh \"\"\" -$> rm -f test-annex.dat; git-annex addurl --file=test-annex.dat --debug file:///tmp/rsa_corr_replications.ipynb -[2015-09-09 23:32:19.809948] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"git-annex\"] -[2015-09-09 23:32:19.812163] process done ExitSuccess -[2015-09-09 23:32:19.812421] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"] -[2015-09-09 23:32:19.814543] process done ExitSuccess -[2015-09-09 23:32:19.815095] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"log\",\"refs/heads/git-annex..c9fb15c861335973c224ff734f998ce6535f3bcd\",\"-n1\",\"--pretty=%H\"] -[2015-09-09 23:32:19.817959] process done ExitSuccess -[2015-09-09 23:32:19.818955] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"cat-file\",\"--batch\"] -[2015-09-09 23:32:19.822038] read: quvi [\"--version\"] -[2015-09-09 23:32:19.826119] process done ExitSuccess -[2015-09-09 23:32:19.826358] call: quvi [\"--verbosity\",\"mute\",\"--support\",\"file:///tmp/rsa_corr_replications.ipynb\"] -[2015-09-09 23:32:19.836989] process done ExitFailure 65 -addurl test-annex.dat (downloading file:///tmp/rsa_corr_replications.ipynb ...) -[2015-09-09 23:32:19.83797] call: curl [\"-f\",\"-L\",\"-C\",\"-\",\"-#\",\"-o\",\"/tmp/xxx/.git/annex/tmp/URL-s31741--file&c%%%tmp%rsa_corr_replications.ipynb\",\"file:///tmp/rsa_corr_replications.ipynb\",\"--user-agent\",\"git-annex/5.20150910+gitg3c17756-1~ndall+1\"] -[2015-09-09 23:32:19.843001] process done ExitFailure (-11) -failed -git-annex: addurl: 1 failed - -$> curl \"-f\" \"-L\" \"-C\" \"-\" \"-#\" \"-o\" \"/tmp/xxx/.git/annex/tmp/URL-s31741--file&c%%%tmp%rsa_corr_replications.ipynb\" \"file:///tmp/rsa_corr_replications.ipynb\" \"--user-agent\" \"git-annex/5.20150910+gitg3c17756-1~ndall+1\" -######################################################################## 100.0% - -$> rm \"/tmp/xxx/.git/annex/tmp/URL-s31741--file&c%%%tmp%rsa_corr_replications.ipynb\" - - -$> GIT_ANNEX_LD_LIBRARY_PATH=/usr/lib/git-annex.linux/lib/x86_64-linux-gnu/ GIT_ANNEX_DIR=/usr/lib/git-annex.linux/ /usr/lib/git-annex.linux/bin/curl \"-f\" \"-L\" \"-C\" \"-\" \"-#\" \"-o\" \"/tmp/xxx/.git/annex/tmp/URL-s31741--file&c%%%tmp%rsa_corr_replications.ipynb\" \"file:///tmp/rsa_corr_replications.ipynb\" \"--user-agent\" \"git-annex/5.20150910+gitg3c17756-1~ndall+1\" -[1] 23559 segmentation fault GIT_ANNEX_LD_LIBRARY_PATH=/usr/lib/git-annex.linux/lib/x86_64-linux-gnu/ = -\"\"\"]] - -exit code in the last calls was 139 ... and after downgrading back to 5.20150819+gitgc587698-1~ndall+1 curl is happily running in the last form: - -[[!format sh \"\"\" - -$> GIT_ANNEX_LD_LIBRARY_PATH=/usr/lib/git-annex.linux/lib/x86_64-linux-gnu/ GIT_ANNEX_DIR=/usr/lib/git-annex.linux/ /usr/lib/git-annex.linux/bin/curl \"-f\" \"-L\" \"-C\" \"-\" \"-#\" \"-o\" \"/tmp/xxx/.git/annex/tmp/URL-s31741--file&c%%%tmp%rsa_corr_replications.ipynb\" \"file:///tmp/rsa_corr_replications.ipynb\" \"--user-agent\" \"git-annex/5.20150910+gitg3c17756-1~ndall+1\" -################################################################# 100.0% -\"\"\"]] - -here is the built package if you care to try yourself: [http://www.onerussian.com/tmp/git-annex-standalone_5.20150910+gitg3c17756-1~ndall+1_amd64.deb] with signed changes [http://www.onerussian.com/tmp/git-annex_5.20150910+gitg3c17756-1~ndall+1_amd64.changes] -"""]] diff --git a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_6_76a5e57d178ed85e5e075a22ac521eca._comment b/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_6_76a5e57d178ed85e5e075a22ac521eca._comment deleted file mode 100644 index f5807c2e7..000000000 --- a/doc/bugs/fails_to_addurl_to_file__58____47____47____47___in_the_most_recent_snapshot_build/comment_6_76a5e57d178ed85e5e075a22ac521eca._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2015-09-10T16:29:57Z" - content=""" -Ok, I remember this now, it's <http://bugs.debian.org/796899> -"""]] diff --git a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47.mdwn b/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47.mdwn deleted file mode 100644 index dae654d13..000000000 --- a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -### What steps will reproduce the problem? -[[!format sh """ -C:\Users\Bruno>mkdir annex - -C:\Users\Bruno>cd annex - -C:\Users\Bruno\annex>git init -Initialized empty Git repository in C:/Users/Bruno/annex/.git/ - -C:\Users\Bruno\annex>git annex init -init - Detected a crippled filesystem. - - Enabling direct mode. - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. -ok -(Recording state in git...) - -C:\Users\Bruno\annex>echo test > test - -C:\Users\Bruno\annex>git annex add . -add test (checksum...) ok -(Recording state in git...) - -C:\Users\Bruno\annex>git commit -a -m added -[master (root-commit) 2eea610] added - 1 file changed, 1 insertion(+) - create mode 120000 test - -C:\Users\Bruno\annex>git annex sync -(Recording state in git...) -fatal: unable to access '../../../../C:\Users\Bruno\annex\.git/config': Invalid argument - -git-annex: user error (xargs ["-0","git","--git-dir=C:\\Users\\Bruno\\annex\\.git","--work-tree=C:\\Users\\Bruno\\annex","add","-f"] exited 123) -failed -git-annex: sync: 1 failed -"""]] - -### What version of git-annex are you using? On what operating system? -Windows 8 (64 bits) - -git version 1.8.4.msysgit.0 - -[[!format sh """ -git-annex version: 4.20131008-ge115441 -build flags: Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav glacier hook -local repository version: 4 -default repository version: 3 -supported repository versions: 3 4 -upgrade supported from repository versions: 2 -"""]] - -### Please provide any additional information below. -C:\Users\Bruno\annex\.git\config exists - -> xargs was one problem; also msysgit seems to just not -> accept DOS style paths anymore in --git-dir or --git-work-tree. -> megaweird. [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_1_e6f39b2ef55b0daa491f4b6329a906bc._comment b/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_1_e6f39b2ef55b0daa491f4b6329a906bc._comment deleted file mode 100644 index cc616aae9..000000000 --- a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_1_e6f39b2ef55b0daa491f4b6329a906bc._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="64.134.31.139" - subject="comment 1" - date="2013-10-16T20:42:07Z" - content=""" -I don't know what to make of this bug report. You say that \"C:\Users\Bruno\annex.git\config\" exists, but you show the creation of a \"C:\Users\Bruno\annex\", and not the other repository. I cannot reproduce it, even if I first \"git init --bare annex.git\". -"""]] diff --git a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_2_b47d6d188f38a8e4ca5ef5f70afadf6a._comment b/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_2_b47d6d188f38a8e4ca5ef5f70afadf6a._comment deleted file mode 100644 index a40e9cbe5..000000000 --- a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_2_b47d6d188f38a8e4ca5ef5f70afadf6a._comment +++ /dev/null @@ -1,48 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkGCmVc5qIJaQQgG82Hc5zzBdAVdhe2JEM" - nickname="Bruno" - subject="comment 2" - date="2013-10-16T22:47:46Z" - content=""" -There's no other repo yet. I have the same problem when I try to sync between two repos but I simplified the instructions to reproduce the bug easily. - -Here's the instructions on Debian : -[[!format sh \"\"\" -bruno@debian:~$ mkdir annex -bruno@debian:~$ cd annex -bruno@debian:~/annex$ git init -Initialized empty Dépôt git dans /home/bruno/annex/.git/ -bruno@debian:~/annex$ git annex init -init ok -(Recording state in git...) -bruno@debian:~/annex$ echo test > test -bruno@debian:~/annex$ git annex add . -add test (checksum...) ok -(Recording state in git...) -bruno@debian:~/annex$ git commit -a -m added -[master (root-commit) 631049d] added - 1 file changed, 1 insertion(+) - create mode 120000 test -bruno@debian:~/annex$ git annex sync -commit -ok -bruno@debian:~/annex$\"\"\"]] - -It seems --git-dir wants 'c:/...' instead of 'c:\\...'. - -[[!format sh \"\"\" -C:\Users\Bruno\annex>git --git-dir=C:\\Users\\Bruno\\annex\\.git --work-tree=C:\\Users\\Bruno\\annex add -f test -fatal: unable to access '../../../../C:\\Users\\Bruno\\annex\\.git/config': Invalid argument - -C:\Users\Bruno\annex>git --git-dir=C:/Users/Bruno/annex/.git --work-tree=C:\\Users\\Bruno\\annex add -f test - -C:\Users\Bruno\annex>\"\"\"]] - -It's weird that I don't have any problem with the following command: -[[!format sh \"\"\"C:\Users\Bruno\annex>git --git-dir=C:\\Users\\Bruno\\annex\\.git --work-tree=C:\\Users\\Bruno\\annex config -l -core.symlinks=false -core.autocrlf=true -[...]\"\"\"]] - -Maybe there's a problem with `git version 1.8.4.msysgit.0`. -"""]] diff --git a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_4_b533b1de535a057b7ebf99afc92691ed._comment b/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_4_b533b1de535a057b7ebf99afc92691ed._comment deleted file mode 100644 index ac4a9e91a..000000000 --- a/doc/bugs/fatal__58___unable_to_access___39__..__47__..__47__..__47/comment_4_b533b1de535a057b7ebf99afc92691ed._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 4" - date="2013-10-17T21:49:10Z" - content=""" -So this is a problem with msysgit 1.8.4. I have been able to reproduce it with that version. 1.8.3 did not have the problem. - -Seems to perhaps be due to the cygwin xargs flipping git into cygwin path mode somehow. (How all this works is massively complex and confusing to me.) -All the other calls to git with identical parameters work fine. I can also reproduce the problem using some old git 1.7.x in the cygwin terminal. - -BTW, I noticed in your example that you ran \"git commit -a\". You should **never** do that in a [[direct mode]] repository. Read the direct mode documentation to understand why. -"""]] diff --git a/doc/bugs/filename_with___34____63____34___causes_unknown_response.mdwn b/doc/bugs/filename_with___34____63____34___causes_unknown_response.mdwn deleted file mode 100644 index e859ddeae..000000000 --- a/doc/bugs/filename_with___34____63____34___causes_unknown_response.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -### Please describe the problem. -When I do git annex add on a directory with a filename that include a "?" -I get an error: -git-annex: unknown response from git cat-file ("HEAD:./Home/wc/Icon missing","HEAD:./Home/wc/Icon\r") -CallStack (from HasCallStack): - error, called at ./Git/CatFile.hs:86:48 in main:Git.CatFile - -where the file here was called "Icon?" - -### What steps will reproduce the problem? -mkdir test - -cd test - -git init - -git annex init "test" - -cp ~/Desktop/Icon? . - -ls - -Icon? - -git annex add . - - git-annex: unknown response from git cat-file ("HEAD:./Icon missing","HEAD:./Icon\r") -CallStack (from HasCallStack): - error, called at ./Git/CatFile.hs:86:48 in main:Git.CatFile - -### What version of git-annex are you using? On what operating system? -git-annex-6.20160619 - -OSX El Capitan using brew install git-annex - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -> closing as this is a duplicate report of the bug [[done]] --[[Joey]] diff --git a/doc/bugs/filename_with___34____63____34___causes_unknown_response/comment_1_e5f727ca42cb341c1c8fd7feae184948._comment b/doc/bugs/filename_with___34____63____34___causes_unknown_response/comment_1_e5f727ca42cb341c1c8fd7feae184948._comment deleted file mode 100644 index e9669a3da..000000000 --- a/doc/bugs/filename_with___34____63____34___causes_unknown_response/comment_1_e5f727ca42cb341c1c8fd7feae184948._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd" - nickname="Anthony DeRobertis" - subject="comment 1" - date="2016-08-24T10:53:05Z" - content=""" -Pretty sure that's not a file with a question mark (`0x3f`) in it, that's a file with a carriage return (`0x0d`) in it. In which case see also [git annex import fails on filenames with newlines in them](https://git-annex.branchable.com/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/). -"""]] diff --git a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented.mdwn b/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented.mdwn deleted file mode 100644 index 25cad4586..000000000 --- a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented.mdwn +++ /dev/null @@ -1,73 +0,0 @@ -### Please describe the problem. -git annex fsck with --incremental-schedule restarts all the time. According to the man page: - - Maybe you'd like to run a fsck for 5 hours at night, pick- - ing up each night where it left off. You'd like this to - continue until all files have been fscked. And once it's - done, you'd like a new fsck pass to start, but no more - often than once a month. Then put this in a nightly cron - job: - - git annex fsck --incremental-schedule 30d --time-limit 5h - -If I run that command (with a time limit of 10 minutes) it starts over instead of continuing where it finished off. - -### What version of git-annex are you using? On what operating system? - -Debian testing version on linux - - time_machine_carl@pi:/media/backup_hdd/carl/annex$ git annex version - git-annex version: 5.20150731-1 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - time_machine_carl@pi:/media/backup_hdd/carl/annex$ uname -a - Linux pi 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux - -and latest version built from homebrew on OS X - - Carls-MacBook-Air:CurveDe carlmod$ git annex version - git-annex version: 5.20150824 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV FsEvents XMPP DNS Feeds Quvi TDFA TorrentParser Database - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: unknown - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - Carls-MacBook-Air:CurveDe carlmod$ uname -a - Darwin Carls-MacBook-Air.local 14.5.0 Darwin Kernel Version 14.5.0: Wed Jul 29 02:26:53 PDT 2015; root:xnu-2782.40.9~1/RELEASE_X86_64 x86_64 - - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -time_machine_carl@pi:/media/backup_hdd/carl/annex$ git annex fsck --incremental-schedule 30d --time-limit 10m -fsck 15 minutes/2014-12-15_Chorkonzert_ Gesungene Vorfreude auf das Christkind - Nachrichten Augsburg-Land, Gersthofen, Neusäß - Augsburger Allgemeine.pdf (checksum...) -ok -fsck 15 minutes/2014_midnattsloppet.pdf (checksum...) -ok -<Snip lots of files> -fsck Deklaration/archive/2014/SE/Bilagor/2013-12-31_SEB Årsbesked.pdf (checksum...) -ok - - Time limit (10m) reached! -time_machine_carl@pi:/media/backup_hdd/carl/annex$ git annex fsck --incremental-schedule 30d --time-limit 10m -fsck 15 minutes/2014-12-15_Chorkonzert_ Gesungene Vorfreude auf das Christkind - Nachrichten Augsburg-Land, Gersthofen, Neusäß - Augsburger Allgemeine.pdf (checksum...) -ok -fsck 15 minutes/2014_midnattsloppet.pdf (checksum...) -ok - -# End of transcript or log. -"""]] - -### 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) - -I manage all my important personal documents since about two or three years, spreading them out over home servers, cloud providers and off site usb-drives in foreign countries, making sure that there are always at least 4 copies available. (if my flat burns the same day that box.com goes bankrupt ...) - -> [[done]] per comments --[[Joey]] diff --git a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_1_f0c7e97cc7697172afa87b372d4d9277._comment b/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_1_f0c7e97cc7697172afa87b372d4d9277._comment deleted file mode 100644 index 9e2985563..000000000 --- a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_1_f0c7e97cc7697172afa87b372d4d9277._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T17:58:09Z" - content=""" -Until version 5.201508125, --time-limit didn't cause a clean shutdown, -and so the fsck database didn't get updated with the last files it checked. -This could result in up to 1000 files being checked over again the next -time the incremental fsck was run. - -I can't reproduce the problem you describe with the current version. -And your transcript seems to be showing the old version, which was known to -have this problem. Only reason I'm not closing this bug immediately -is you seem to have a new enough version on your mac to avoid the problem.. -but it's not clear to me if you're experiencing the problem on the mac. -"""]] diff --git a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_2_fc1d755b34f29e065e536be2acfe1ee1._comment b/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_2_fc1d755b34f29e065e536be2acfe1ee1._comment deleted file mode 100644 index a230ddf5d..000000000 --- a/doc/bugs/fsck_--incremental-schedule_does_not_work_as_documented/comment_2_fc1d755b34f29e065e536be2acfe1ee1._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnmF_9CAtfqdZkC4e-_dCX-rK5bqh4RWkw" - nickname="Carl" - subject="comment 2" - date="2015-09-10T16:04:32Z" - content=""" -I think you are right. I did try it out on the mac and Thought that I could see the same problems there. Today I tried to reproduce it, but it seems to be working correctly. (I have only tested it properly on a special remote, with --from, and not on the repo itself, since I by misstake did start a job that fsck-ed all files with a new due date in 30 days. - -Please close the bug. -"""]] diff --git a/doc/bugs/fsck__44___no_known_copies.mdwn b/doc/bugs/fsck__44___no_known_copies.mdwn deleted file mode 100644 index 589910167..000000000 --- a/doc/bugs/fsck__44___no_known_copies.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -### Please describe the problem. - -Sometimes I end up having files whose contents _do_ exist in this repo, but the location log says otherwise. - -For indirect repos, I can just run `annex fsck` on the directory, it says "(fixing location log)", and everything is fine. - -But when I try to do the same in a _direct_ repo, it refuses to admit that it just found a copy: - -[[!format text """ -┌ frost ~/Attic/Anime (annex) -┘ annex fsck Foo/ -fsck Foo/[HorribleSubs] Foobar - 01 [720p].mkv (checksum...) - ** No known copies exist of Foo/[HorribleSubs] Foobar - 01 [720p].mkv -failed -fsck Foo/[HorribleSubs] Foobar - 02 [720p].mkv (checksum...) - ** No known copies exist of Foo/[HorribleSubs] Foobar - 02 [720p].mkv -failed -...and so on. -"""]] - -(A copy _does_ exist; after all, `annex` just spent 30 seconds checksumming it.) - -I work around this bug by switching to indirect mode temporarily, which allows fsck to fix the log. - -### What steps will reproduce the problem? - -For the fsck bug, I think you just need a file that physically exists in the repo, but not marked as such in the location log. - -As for how such files happen in the first place, I've no idea myself. (For what it's worth, the log seems fine.) - -### What version of git-annex are you using? On what operating system? - -Arch's community/git-annex 6.20160511 - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/fsck__44___no_known_copies/comment_1_e13b4e3b9f1c836fe4ca69bcac2b8afb._comment b/doc/bugs/fsck__44___no_known_copies/comment_1_e13b4e3b9f1c836fe4ca69bcac2b8afb._comment deleted file mode 100644 index 012c70637..000000000 --- a/doc/bugs/fsck__44___no_known_copies/comment_1_e13b4e3b9f1c836fe4ca69bcac2b8afb._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-12T17:29:55Z" - content=""" -Bug sumitter, it would be good if you could find a way to reproduce -the location log getting out of sync with reality. While `git annex fsck` -is there to fix such a diverenge, it should not happen in the first place -in normal operation. - -Reproduced by using `setpresentkey` to make the log not think -the file content is locally available. The file was available, and had -the right content, but fsck complains as shown. - -Ok, found the bug, it was treating the file as an unlocked file, -but that meant it looked for the object file. That's the wrong -thing to do in direct mode. This reversion was introduced in -[[!commit e7183d83d367bb52f502266b11b5b6dff683279e]], so versions -before 5.20151208 were ok. Fixing.. -"""]] diff --git a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes.mdwn b/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes.mdwn deleted file mode 100644 index 32ddb1de5..000000000 --- a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. -fsck doesn't not update the inventory for external special remotes - -This is perhaps the same behavior on all special remotes, but I have not verified it. - -### What steps will reproduce the problem? -Run fsck or fsck -F on a special remote on which the file has been deleted outside of git-annex's knowledge. The file will fail the existence check, but not update the inventory (i.e. git-annex-whereis/git-annex-list still thinks the file might reside on that remote). - -### What version of git-annex are you using? On what operating system? -[[!format sh """ -$ git annex version -git-annex version: 5.20151208-1build1 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA TorrentParser Database -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 -$ dpkg -l | grep git-annex -ii git-annex 5.20151208-1build1 amd64 manage files with git, without checking their contents into git -$ lsb_release -d -Description: Ubuntu 16.04.1 LTS -"""]] - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -myuser:/var/data/my_photos$ git annex fsck --from fabric 2010/wedding_photos/00017.jpg -fsck 2010/wedding_video/00017.jpg (<error message from special remote>) failed -(recording state in git...) -myuser:/var/data/my_photos$ git annex list 2010/wedding_photos/00017.jpg -here (untrusted) -|web -||bittorrent -|||fabric (untrusted) -|||| -x__x 2010/wedding_photos/00017.jpg - -# End of transcript or log. -"""]] - -### Why I care about this problem -Some files in my external special remote got removed outside of git-annex's knowledge. I would like to copy back in the files that are missing, but I am having a hard time doing so. git-annex-copy also notices that the file fails the existence check, but doesn't bother trying to re-upload the file. - -### 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) -git-annex is fantastic! It is the only program that I trust to store my most precious files. If there is another way to get git-annex to update its inventory for files removed in special remotes I will gladly try it! Keep up the good work! - -> [[done]] notabug --[[Joey]] diff --git a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_1_345f71917c053b4903cdf640ddcdf682._comment b/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_1_345f71917c053b4903cdf640ddcdf682._comment deleted file mode 100644 index 327da7fd9..000000000 --- a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_1_345f71917c053b4903cdf640ddcdf682._comment +++ /dev/null @@ -1,37 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-05T18:14:24Z" - content=""" -I do not reproduce this bug with the current version of git-annex. - -Using a directory special remote: - - joey@darkstar:~/tmp/me>git annex copy foo --to d - copy foo (to d...) - ok - joey@darkstar:~/tmp/me>sudo rm ../d/e70/8a4/SHA256E-s30--8f6ec07ba3543f8ae5da1d85602a389e36b15f291c2d1e02bc1920565c1a1f25/SHA256E-s30--8f6ec07ba3543f8ae5da1d85602a389e36b15f291c2d1e02bc1920565c1a1f25 - fsck foo (fixing location log) - ** Based on the location log, foo - ** was expected to be present, but its content is missing. - failed - (recording state in git...) - git-annex: fsck: 1 failed - joey@darkstar:~/tmp/me>git annex whereis - whereis foo (1 copy) - e32ee842-ff63-4c23-b239-53cd887d79b1 -- joey@darkstar:~/tmp/me [here] - ok - -But, you omitted the "error message from special remote" for some reason. -That information you omitted is almost certianly *crucial* information to understanding -your bug report. - -If git-annex thinks it was not able to talk to the special remote at all, -it won't record it as not having the file, because more likely the special -remote is temporarily not accessible. - -At the moment, I see no indication of a bug. I'll leave this open for a little while marked moreinfo. - -(I'm also curious how you managed to report this bug without giving any -title at all. I had to rename ".mdwn" to a more reasonable filename.) -"""]] diff --git a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_2_d35bd65021b80399f2cdefede4f0713f._comment b/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_2_d35bd65021b80399f2cdefede4f0713f._comment deleted file mode 100644 index b0c8ba21c..000000000 --- a/doc/bugs/fsck_does_not_update_the_inventory_for_external_special_remotes/comment_2_d35bd65021b80399f2cdefede4f0713f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="onionjake" - subject="comment 2" - date="2016-09-06T19:45:06Z" - content=""" -This is indeed not a bug, my external remote is returning a CHECKPRESENT-UNKNOWN, which as designed does not update the location. I have verified that returning a CHECKPRESENT-FAILURE does indeed update the location. - -As for creating a bug without a title, I simply just clicked \"edit\" then \"save\". I tried it again with another bug and it worked. -"""]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn deleted file mode 100644 index 332748123..000000000 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -### What steps will reproduce the problem? - -1. Create a fresh annex repo. Create a dummy test file and add it to the annex. -2. `git init --bare` in an empty directory on a remote machine. -3. `git initremote testremote type=gcrypt encryption=hybrid gitrepo=ssh://machine/the/remote/machine/dir keyid=my_key_id` -4. `git annex sync testremote --content` -5. Unplug network/switch off WiFi. -6. `git annex sync testremote --content`, which fails due to the broken network. -7. Reconnect network, check that can ssh to remote host. -8. `git annex sync testremote --content` - -gcrypt issues warning `gcrypt: WARNING: Remote ID has changed!` - -### What version of git-annex are you using? On what operating system? - -git-annex 5.20141125 on Debian Wheezy 32-bit. - -### Please provide any additional information below. - -This is essentially a gcrypt bug, so I don't know if you want to fix it, and I know that the gcrypt author is inactive. - -My diagnosis is that when running `git annex sync testremote --content` when the network is disconnected, git can't SSH to the remote and gcrypt makes the mistake of regenerating the remote ID and setting up a new remote. So when the network comes back online, the local record of the remote's gcrypt ID is just wrong. gcrypt ought not to "set up a new repository" when there is a network failure. - - gcrypt: Development version -- Repository format MAY CHANGE - gcrypt: Repository not found: ssh://url-here - gcrypt: Setting up new repository - gcrypt: Remote ID is :id:agVyn7wBG/JGwN9LW5Qn - Counting objects: 22, done. - Compressing objects: 100% (17/17), done. - Total 22 (delta 4), reused 0 (delta 0) - gcrypt: Encrypting to: -r my_key_id_here - gcrypt: Requesting manifest signature - ssh: Could not resolve hostname my_remote_host_here: No such file or directory - fatal: Could not read from remote repository. - - Please make sure you have the correct access rights - and the repository exists. - error: failed to push some refs to 'gcrypt::ssh://url-here - - Pushing to testremote failed. - - (non-fast-forward problems can be solved by setting receive.denyNonFastforwards to false in the remote's git config) - failed - -> fowarded, so [[closing|done]] --[[Joey]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment deleted file mode 100644 index 597c017de..000000000 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_1_aa4bf99c99b285ceb135fd7690257565._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-21T17:09:16Z" - content=""" -Analysis seems to make sense. Note that this happens only when gcrypt is -doing a push, not a pull, so there needs to be a local change made for the -sync to try to push out for the bug to occur. Reproduced by adding a file -and then syncing. - -It seems that gcrypt recovers fairly well; after setting the local -remote.foo.gcrypt-id to a new value, when the network comes back, it -re-sets it back to the real value next time a pull is made. Does this -bug result in any problem other than noise in the log? - -Anyway, it's certianly a gcrypt bug, and I don't see what git-annex can do -about it. Opened a bug there: <https://github.com/bluss/git-remote-gcrypt/issues/20> - -Doesn't seem that this would be too hard to fix in gcrypt.. -"""]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_a6c8200184dab2ff3658843d412e5e1b._comment b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_a6c8200184dab2ff3658843d412e5e1b._comment deleted file mode 100644 index f2d7196ef..000000000 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_a6c8200184dab2ff3658843d412e5e1b._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="spwhitton" - subject="comment 2" - date="2015-09-21T21:22:22Z" - content=""" -I am not aware of any problems other than the noise, but I think it's significant noise because it's marked with 'WARNING' in block capitals and this makes the user worry that something might have gone wrong with their precious git-annex data, and there's no indication it can be automatically recovered from. - -Would you accept a patch to your fork of git-remote-gcrypt, since the original author is inactive? -"""]] diff --git a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_c021d9ad7f31daab7ac3455554e1cc42._comment b/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_c021d9ad7f31daab7ac3455554e1cc42._comment deleted file mode 100644 index 43ef22629..000000000 --- a/doc/bugs/gcrypt_gives_false___34__remote_ID_has_changed__34___warning_after_a_sync_fails_because_network_is_down/comment_2_c021d9ad7f31daab7ac3455554e1cc42._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-09-22T15:58:18Z" - content=""" -Yes, I'll take reasonable patches, that's why I have that fork of -git-remote.gcrypt. -"""]] diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn b/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn deleted file mode 100644 index 6433f53dc..000000000 --- a/doc/bugs/gcrypt_special_remote_not_being_encrypted.mdwn +++ /dev/null @@ -1,75 +0,0 @@ -### Please describe the problem. -I'm trying to setup a ssh special remote with gcrypt as an always-on sync point for 2 other machines. However, when syncing, only the first machine that was setup seems to do the encryption properly, the other machine that clones from the gcrypt remote sync the file content without encryption. I followed the instruction on https://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/ - -### What steps will reproduce the problem? - -On the first machine: - -``` -cd MyStuffs -git init -git annex init "Macbook" -echo "First file" > first.txt -git annex add . -git commit -a -m added -git annex initremote personal-server type=gcrypt gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs keyid=XXXXXXXXX -git annex sync -git annex sync--content -``` - -On second machine - -``` -git clone gcrypt::ssh://user@foo.bar.com/home/user/MyStuffs test -git annex enableremote personal-server gitrepo=ssh://user@foo.bar.com/home/user/MyStuffs -cd test -echo "BananaTest" > test -git annex add . -git commit -a -m added -git annex sync --content -``` - -On the remote server - -``` -cd ~/MyStuffs -grep -r "First" . #There is no result, which is good -grep -r "Banana" . #On the other hand, this has a result -> ./annex/objects/ee1/042/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org/SHA256E-s5--11861eaa2e70e8ac73d9d20cd172b6a5396cb0116fed5bfe432ca075144b2d48.org:BananaTest - -``` -If the first machine do `git annex sync --content`, it can get and view the new file normally, trying to add new file afterward from the first machine works fine as well. Adding file from the 2nd machine results in the same behaviour (unencrypted file content). - -When using gcrypt special remote on local machine , it does not seem to be an issue. Additionally, on machine 2 if I clone from the first machine then enableremote to the gcrypt server, it is also not a problem. Seems like the issue only happens when cloning the bare repo. On inspection of the annex/objects folder, the issue seems to be that beside the "GPGHMACSHA1*" files (which I assume is encrypted data), a bunch of "SHA256E*" files are also added which contains the raw unencrypted data. - -### What version of git-annex are you using? On what operating system? - -The first and second machine was in fact the same machine ,running OS X El Capitan - -``` -git-annex version: 6.20160511 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 -operating system: darwin x86_64 -``` - -The remote server that use ssh is Debian Jessie, without git-annex installed (I tried it with git-annex installed on the server, it has the same behaviour) -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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, everything works very nicely except this issue. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_1_ec3cf082ed27b7cb3ce4ba42f8e1dc10._comment b/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_1_ec3cf082ed27b7cb3ce4ba42f8e1dc10._comment deleted file mode 100644 index e89861730..000000000 --- a/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_1_ec3cf082ed27b7cb3ce4ba42f8e1dc10._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-06-02T17:10:48Z" - content=""" -What's going on here is, you have cloned a gcrypt repository so have it as -the origin remote. git-annex is storing files in that remote as if it were -a regular git remote. It's not being used as a special remote at all. - -This is surely a bug; git-annex should notice that remote has a gcrypt-id -and treat it as a gcrypt remote, or refuse to use it since it's not set up -as a special remote. - -It also seems that only git annex sync --content behaves this way; -git annex copy "cannot determine uuid for origin". -"""]] diff --git a/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_2_d4e46b73fa82ba84b123bc4f2d372ea9._comment b/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_2_d4e46b73fa82ba84b123bc4f2d372ea9._comment deleted file mode 100644 index 39b3bc58b..000000000 --- a/doc/bugs/gcrypt_special_remote_not_being_encrypted/comment_2_d4e46b73fa82ba84b123bc4f2d372ea9._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-06-02T17:32:24Z" - content=""" -The bug is limited to `git annex sync --content` because it -didn't check if the git remote had no git-annex UUID before -sending files to it. Commands like `git annex copy` always check that the -remote has a UUID. - -I've made `git annex sync --content` also check for a UUID. So, it won't -send any file contents to the origin remote in this configuration. I don't -think it makes sense to have git-annex auto-promote the origin remote to a -gcrypt special remote; you can just enableremote the special remote to make -git-annex send the files to it, properly encrypted. - -When this bug occurs, git-annex actually doesn't remember that it's sent -the un-encrypted files to the remote. I suggest that you just delete all -files in the remote's annex/ directory of the gcrypt repository -whose names do not start with "GPGHMACSHA1", in order to clean up from this -bug. - ----- - -The deeper problem is git-annex is able to transfer objects to a remote -that does not have a UUID at all. I've put in a guard at a deeper level to -prevent this whole class of problems. -"""]] diff --git a/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn b/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn deleted file mode 100644 index 75a546159..000000000 --- a/doc/bugs/getFileSize_conflict_between_Utility.Directory_and_Utility.FileSize.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### Please describe the problem. -directory 1.3.0.0 causes a conflict for "getFileSize" - -### What steps will reproduce the problem? -Build git-annex with directory 1.3.0.0 (first need to bump max directory version on concurrent-output (and aws if building with s3)) - -### What version of git-annex are you using? On what operating system? -6.20161210 on macOS 10.11 El Capitan - - -### Please provide any additional information below. - -[[!format sh """ -[23 of 34] Compiling Common ( Common.hs, dist/setup/Common.o ) - -Common.hs:3:16: error: - Conflicting exports for ‘getFileSize’: - ‘module X’ exports ‘X.getFileSize’ - imported from ‘Utility.Directory’ at Common.hs:28:1-29 - (and originally defined in ‘System.Directory’) - ‘module X’ exports ‘X.getFileSize’ - imported from ‘Utility.FileSize’ at Common.hs:34:1-28 - (and originally defined at Utility/FileSize.hs:26:1-11) -"""]] - -A fix, though possibly not best, is to make this change in Common.hs: -[[!format sh """ -import Utility.Directory as X hiding (getFileSize) -"""]] - -### 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 :) - -> [[fixed|done]]; thanks for reporting! diff --git a/doc/bugs/ghc_8.0.1_build_fixes.mdwn b/doc/bugs/ghc_8.0.1_build_fixes.mdwn deleted file mode 100644 index f9c8768df..000000000 --- a/doc/bugs/ghc_8.0.1_build_fixes.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -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 -"""]] - -> [[fixed|done]], I hope. Have not tested the build myself but everything -> applied. --[[Joey]] diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment deleted file mode 100644 index 01657fe1f..000000000 --- a/doc/bugs/ghc_8.0.1_build_fixes/comment_1_bc5e868448fb0d45f2586d4ac24437fb._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-23T14:50:25Z" - content=""" -How does GHC complain about "runner"? Would --XNoMonomorphismRestriction fix it? I don't like the suggested change -because seeing that code, I'd naturally want to refactor it back to -something like how it's currently written.. (Still, I've applied the patch -for now.) - -I've relaxed the bounds on base. AFAICS there are no bounds on time and -transformers, so what were you suggesting I change there? - -I've applied your change to Setup-Depends. Oddly, I seem to remember -trying the Setup-Depends with the new cabal and thought it was working.. -"""]] diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment deleted file mode 100644 index 1a2bb5076..000000000 --- a/doc/bugs/ghc_8.0.1_build_fixes/comment_2_4b2c8620824dc625b3aecee9838a04c3._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - subject="comment 2" - date="2016-05-23T16:26:35Z" - content=""" -> How does GHC complain about \"runner\"? - -[[!format text \"\"\" -Remote/Bup.hs:137:30: error: - • Couldn't match expected type ‘t’ - with actual type ‘Utility.Process.CreateProcessRunner - -> CreateProcess -> (Handle -> IO a0) -> IO a0’ - ‘t’ is a rigid type variable bound by - the inferred type of runner :: t at Remote/Bup.hs:136:13 - • In the expression: feedWithQuietOutput - In the expression: - if quiet then feedWithQuietOutput else withHandle StdinHandle - In an equation for ‘runner’: - runner - = if quiet then feedWithQuietOutput else withHandle StdinHandle - • Relevant bindings include - runner :: t (bound at Remote/Bup.hs:136:13) -\"\"\"]] - ->I've applied your change to Setup-Depends. Oddly, I seem to remember trying the Setup-Depends with the new cabal and thought it was working.. - - -It is working, until I run \"cabal configure\". Then it breaks unless I add those additional dependencies. - -I'll check on your other questions in a bit. - - -"""]] diff --git a/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment b/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment deleted file mode 100644 index 18d1727cc..000000000 --- a/doc/bugs/ghc_8.0.1_build_fixes/comment_3_010ee40d55d345f4a4d7d5bc310adfc2._comment +++ /dev/null @@ -1,60 +0,0 @@ -[[!comment format=mdwn - username="ilovezfs" - subject="comment 3" - date="2016-05-24T09:32:31Z" - content=""" -> I've relaxed the bounds on base. AFAICS there are no bounds on time and transformers, so what were you suggesting I change there? - -The following assumes passing --flags=\"webapp s3\" and --max-backjumps=-1. - -Adding allow-newer for just base hangs. - -Adding allow-newer for just base and transformers leads to solver failure due to -\"rejecting: aws-0.13.0 (conflict: unix => time==1.6.0.1/installed-1.6..., aws => time>=1.1.4 && <1.6)\" -This has already been fixed by aws https://github.com/aristidb/aws/commit/512d4f7aa908b4fd2a2b72be79733d865d36652e but that commit is not in the released version of aws yet, so one option would be to patch aws directly with that commit. The other option is to set allow-newer for time. - -Adding allow-newer for just base and time leads to a failed build due to a transformers-0.4.3.0 issue, which doesn't affect newer versions of transformers. However, the current aws restricts transformers to <0.5, and the last version before 0.5 is 0.4.3.0. The error message is - -[[!format text \"\"\" -[11 of 27] Compiling Control.Monad.Trans.Error ( Control/Monad/Trans/Error.hs, dist/dist-sandbox-81571458/build/Control/Monad/Trans/Error.o ) - -Control/Monad/Trans/Error.hs:69:10: error: - Duplicate instance declarations: - instance MonadPlus IO - -- Defined at Control/Monad/Trans/Error.hs:69:10 - instance MonadPlus IO -- Defined in ‘GHC.Base’ - -Control/Monad/Trans/Error.hs:73:10: error: - Duplicate instance declarations: - instance Alternative IO - -- Defined at Control/Monad/Trans/Error.hs:73:10 - instance Alternative IO -- Defined in ‘GHC.Base’ -\"\"\"]] - - ->Would -XNoMonomorphismRestriction fix it? - -Setting that option leads to -[[!format text \"\"\" -[ 89 of 538] Compiling Utility.Url ( Utility/Url.hs, dist/dist-sandbox-516bc87d/build/git-annex/git-annex-tmp/Utility/Url.o ) - -Utility/Url.hs:160:85: error: - • Ambiguous type variable ‘a0’ arising from a use of ‘len’ - prevents the constraint ‘(Read a0)’ from being solved. - Probable fix: use a type annotation to specify what ‘a0’ should be. - These potential instances exist: - instance Read a => Read (ZipList a) - -- Defined in ‘Control.Applicative’ - instance (Read a, Read b) => Read (Either a b) - -- Defined in ‘Data.Either’ - instance forall k a (b :: k). Read a => Read (Const a b) - -- Defined in ‘Data.Functor.Const’ - ...plus 47 others - ...plus 177 instances involving out-of-scope types - (use -fprint-potential-instances to see them all) - • In the first argument of ‘isJust’, namely ‘len’ - In the second argument of ‘(&&)’, namely ‘isJust len’ - In the expression: \"ftp\" `isInfixOf` uriScheme u && isJust len -\"\"\"]] - -"""]] diff --git a/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn b/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn deleted file mode 100644 index 80193cd54..000000000 --- a/doc/bugs/git-annex-fsck___34__-all__34___flag_doesn__39__t_work_for_special_remote.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -### Please describe the problem. -I tried to use `git-annex-fsck --all --from remote` to check files on a special remote, but git-annex did a scan of the local repo instead. If I don't use the `--all` flag, it correctly checks the files on the remote (but just the files in the current checked out branch). - -### What steps will reproduce the problem? - mkdir repo - mkdir special - cd repo - git init - git annex init - git annex initremote special type=directory directory=../special encryption=none - touch testfile - git annex add testfile - git annex copy testfile --to special - chmod -R +w ../special/* - rm -r ../special/* - git annex fsck --all --from special # should check special remote but checks local repo instead - git diff git-annex^ git-annex # activity log shows that it checked special remote - git annex fsck --from special # correctly checks special remote, identifies missing file - - -### What version of git-annex are you using? On what operating system? -6.20161012 on Ubuntu 16.10 - -### Have you had any luck using git-annex before? -Yes, it's been very helpful for managing large files between laptops, desktops, external storage, and remote storage. - -> Thanks for an excellent test case and a clear bug report. I've fixed this -> bug. [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox.mdwn b/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox.mdwn deleted file mode 100644 index 8a2142347..000000000 --- a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox.mdwn +++ /dev/null @@ -1,129 +0,0 @@ -### Please describe the problem. - -I am trying to make an SSH key restricted to use git-annex and only git-annex, and only readonly on a specific repository (or many repositories, ideally, but let's start with that0> - -I am following [[forum/Restricting_git-annex-shell_to_a_specific_repository/]] and searched this wiki for similar problems, but couldn't figure out a solution. - -### What steps will reproduce the problem? - -1. install git-annex on an android machine (not sure it needs to be on android, but here it is) -2. create passwordless SSH keys with `ssh-keygen` on the git-annex terminal there -3. add the public part of that key to `~/.ssh/authorized_keys` on the git-annex server (note: without any command restriction for now) -4. git clone the repository on the android device -5. change the `authorized_keys` for this: - - command="git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB[...] - -Expected result: I can operate on the git-annex repository without problem. - -Actual result: I get `git-annex-shell: bad parameters` whatever I do. - -I have tried variations of the above `authorized_keys` line: - -* `command="git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB[...]` -* `command="/usr/bin/git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB[...]` -* `command="~/.ssh/git-annex-shell",no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB[...]` - -.. where `~/.ssh/git-annex-shell` is as described in [[forum/Restricting_git-annex-shell_to_a_specific_repository/]]: - -[[!format sh """ -#!/bin/sh -set -e - -if [ "x$SSH_ORIGINAL_COMMAND" != "x" ]; then -exec /usr/bin/git-annex-shell -c "$SSH_ORIGINAL_COMMAND" -else -exec /usr/bin/git-annex-shell -c "$@" -fi -"""]] - -### What version of git-annex are you using? On what operating system? - -The "client" side is: - -[[!format sh """ -# git annex version -WARNING: linker: git-annex has text relocations. This is wasting memory and prevents security hardening. Please fix. -git-annex version: 6.20160317-g204dbf5 -build flags: Assistant Webapp Testsuite S3(multipartupload) WebDAV Inotify XMPP TorrentParser Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 -"""]] - -On cyanogenmod 12.1. - -The server side is my usual 5.20151208-1~bpo8+1 from backports on Debian jessie. - -### Please provide any additional information below. - -Example of a failed transfer: - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -# git annex get John\ Coltrane/Coltrane/02.\ John\ Coltrane\ -\ Soul\ eyes.mp3 --debug -WARNING: linker: git-annex has text relocations. This is wasting memory and prevents security hardening. Please fix. -[2016-04-04 10:38:18.710817] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","ls-files","--cached","-z","--","John Coltrane/Coltrane/02. John Coltrane - Soul eyes.mp3"] -get John Coltrane/Coltrane/02. John Coltrane - Soul eyes.mp3 [2016-04-04 10:38:19.067234] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","git-annex"] -[2016-04-04 10:38:19.226703] process done ExitSuccess -[2016-04-04 10:38:19.24413] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","show-ref","--hash","refs/heads/git-annex"] -[2016-04-04 10:38:19.291315] process done ExitSuccess -[2016-04-04 10:38:19.297724] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","log","refs/heads/git-annex..1bb927d3ff7ee7a15623c8798fa20d3ee180d8d6","-n1","--pretty=%H"] -[2016-04-04 10:38:19.395572] process done ExitSuccess -[2016-04-04 10:38:19.396091] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","log","refs/heads/git-annex..b7ab5e62053e838f15e38fc8e4e523da9591f89b","-n1","--pretty=%H"] -[2016-04-04 10:38:19.443764] process done ExitSuccess -[2016-04-04 10:38:19.444283] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","log","refs/heads/git-annex..ee9e429a3b847010adf65665e4dfe0194c46b819","-n1","--pretty=%H"] -[2016-04-04 10:38:19.487988] process done ExitSuccess -[2016-04-04 10:38:19.496808] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","core.bare=false","cat-file","--batch"] -(from origin...) -[2016-04-04 10:38:19.62301] read: rsync ["--progress","--inplace","-e","'ssh' '-S' '/data/data/ga.androidterm/tmp/ssh/anarcat@anarc.at' '-o' 'ControlMaster=auto' '-o' 'ControlPersist=yes' '-T' 'anarcat@anarc.at' 'git-annex-shell ''sendkey'' ''/srv/mp3'' ''--debug'' ''SHA256E-s7413367--bdbba13f0631704bcc96220e3b5f2dfd93b186eaf79ef4c8dcf1f6b3dd9b1397.mp3'' --uuid b7802161-c984-4c9f-8d05-787a29c41cfe ''--'' ''remoteuuid=6f812272-18c8-4346-b68a-f57ae50f657e'' ''unlocked='' ''direct='' ''associatedfile=John Coltrane/Coltrane/02. John Coltrane - Soul eyes.mp3'' ''--'''","--","dummy:",".git/annex/tmp/SHA256E-s7413367--bdbba13f0631704bcc96220e3b5f2dfd93b186eaf79ef4c8dcf1f6b3dd9b1397.mp3"] -git-annex-shell: bad parameters - -Usage: git-annex-shell [-c] command [parameters ...] [option ...] - -Plumbing commands: - -commit DIRECTORY commits any staged changes to the git-annex branch -configlist DIRECTORY outputs relevant git configuration -dropkey DIRECTORY KEY ... drops annexed content for specified keys -gcryptsetup DIRECTORY VALUE sets up gcrypt repository -inannex DIRECTORY KEY ... checks if keys are present in the annex -lockcontent DIRECTORY KEY locks key's content in the annex, preventing it being dropped -notifychanges DIRECTORY sends notification when git refs are changed -recvkey DIRECTORY KEY runs rsync in server mode to receive content -sendkey DIRECTORY KEY runs rsync in server mode to send content -transferinfo DIRECTORY KEY updates sender on number of bytes of content received - -[2016-04-04 10:38:19.805156] process done ExitFailure 12 - - rsync failed -- run git annex again to resume file transfer - - Unable to access these remotes: origin -rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] -rsync error: error in rsync protocol data stream (code 12) at io.c(224) [Receiver=3.1.0dev] - - Try making some of these repositories available: - 0f9185ea-8462-4230-8cae-462a1ad0df36 -- anarcat@angela:~/mp3 - 22921df6-ff75-491c-b5d9-5a2aab33a689 -- anarcat@marcos:/media/anarcat/79884590-6445-4a6f-ae12-050b9a7c1912/mp3 - 3f6d8082-6f4b-4faa-a3d9-bd5db1891077 -- anarcat@lab-sc.no-ip.org:mp3 - 4249a4ea-343a-43a8-9bba-457d2ff87c7d -- rachel@topcrapn:~/Musique/MUSIC/anarcat - 487dda55-d164-4bf1-9d85-66caaa9c0743 -- 300GB hard drive labeled VHS - b7802161-c984-4c9f-8d05-787a29c41cfe -- anarcat@marcos:/srv/mp3 [origin] - c2ca4a13-9a5f-461b-a44b-53255ed3e2f9 -- anarcat@desktop008:/srv/musique/anarcat/mp3 - f867da6f-78cb-49be-a0db-d1c8e5f53664 -- n900 - f8818d12-9882-4ca5-bc0f-04e987888a8d -- anarcat@marcos:/media/anarcat/green_crypt/mp3/ -failed -git-annex: get: 1 failed - -# End of transcript or log. -"""]] - -### 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) - -I seem to recall I had that working in the past, and I feel I am probably doing something stupidly wrong, but here I am. Sorry about that, I'll be sure to fix the documentation more clearly (esp. in the [[git-annex-shell]] manpage when I figure it out! --[[anarcat]] - -Well, it looks like this PEBKAC here - could have sworn I had tested the wrapper, but it seems I didn't do it properly. I'll fixup the documentation for things to be clearer, but this is basically fixed now, with a proper ~/.ssh/git-annex. I don't understand why the wrapper is necessary, but thanks for the feedback! [[done]] diff --git a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_1_cc9a52e1eab1092848cd53a6497a2f2a._comment b/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_1_cc9a52e1eab1092848cd53a6497a2f2a._comment deleted file mode 100644 index 97b7a5ff3..000000000 --- a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_1_cc9a52e1eab1092848cd53a6497a2f2a._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-04T19:05:22Z" - content=""" -Locking down git-annex-shell should be the same process as locking down -git-shell. It intentionally copies git-shell's behavior to make this as -easy as possible, and to make git-annex-shell a drop-in replacement for -git-shell in things like gitolite. - -I double-checked with this in my `authorized_keys`: - -command="~/.ssh/git-annex-shell" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICfFntnesZcYz2B2T41ay45igfckXRSh5uVffkuCQkLv joey@darkstar - -Which is using the standard git-annex-shell wrapper script. It works. - -I guess you've either made some mistake in your setup, or possibly -`SSH_ORIGINAL_COMMAND` isn't getting set. I don't know why that would -happen, but it should be easy enough to modify your script to test. -Just make it `set -x` .. -"""]] diff --git a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_2_92ec7f5f70b6b9e1dda085135aec9ca6._comment b/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_2_92ec7f5f70b6b9e1dda085135aec9ca6._comment deleted file mode 100644 index f4f4ed23a..000000000 --- a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_2_92ec7f5f70b6b9e1dda085135aec9ca6._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-04-04T20:12:12Z" - content=""" -The wrapper program is not strictly necessary; this will work too: - - command="git-annex-shell -c \"$SSH_ORIGINAL_COMMAND\"" - -It might be nice if git-shell knew about `SSH_ORIGINAL_COMMAND` -(and if it did, I'd make git-annex-shell mirror that), -but then that could be seen as making git depend on the transport -unncessarily. -"""]] diff --git a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_3_ad9c8630afa3358d438e41953dd8acac._comment b/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_3_ad9c8630afa3358d438e41953dd8acac._comment deleted file mode 100644 index 4fd37bee9..000000000 --- a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_3_ad9c8630afa3358d438e41953dd8acac._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="anarcat" - subject="""fixed up""" - date="2016-04-04T20:30:22Z" - content=""" - -Why doesn't the assistant use git-annex -c instead of setting up a -wrapper that can potentially break? Seems like one moving parts too -many... - -I have removed the wrapper from the manpage, as it seems a little -annoying to setup manually for no real advantage that I can see. Note -that the double-quotes need to be quoted otherwise the public key is -completely ignored. -"""]] diff --git a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_4_b594345358810075676de2acc80ab7e0._comment b/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_4_b594345358810075676de2acc80ab7e0._comment deleted file mode 100644 index 090f618dc..000000000 --- a/doc/bugs/git-annex-shell__58___bad_parameters_when_trying_to_configure_a_shell_sandbox/comment_4_b594345358810075676de2acc80ab7e0._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-04-04T21:00:06Z" - content=""" -Well, the assistant has other reasons to use a wrapper script to run -git-annex-shell. In particular, this lets it vary the script depending on -where git-annex-shell ends up being installed, which may not be in PATH. -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied.mdwn b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied.mdwn deleted file mode 100644 index 260ab9981..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -### Please describe the problem. -I followed the tip on [fully encrypted git repositories with gcrypt](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/) to create encrypted git-annex repository on a ssh server. When I try to checkout the repository, things break as follows: - -`git clone gcrypt::ssh://my.server/home/me/encryptedrepo myrepo` - -works as expected but when in the myrepo directory, - -`git annex enableremote encryptedrepo gitrepo=ssh://my.server/home/me/encryptedrepo` - -issues the following text (among normal messages): - -`git-annex-shell: gcryptsetup permission denied` - -Then while the links are there, - -`git annex get --from encryptedrepo` - -does nothing (in the sense that the content is not retrieved). - -This seems to have everything to do with git-annex-shell as the exact same manipulations but with a local repository work perfectly. Unfortunately, I don't know haskell so [this code](https://github.com/joeyh/git-annex/blob/master/Command/GCryptSetup.hs) is cryptic to me. I can guess there is a problem getting the uuid of the repository, but as far as I can tell the bare distant repo looks fine. - -### What steps will reproduce the problem? - -Create a standard git annex local repository and then follow the [fully encrypted git repositories with gcrypt tip](http://git-annex.branchable.com/tips/fully_encrypted_git_repositories_with_gcrypt/) to create an encrypted git-annex repository on a ssh server. Then follow the instructions in the same tip to clone the remote repository. - -### What version of git-annex are you using? On what operating system? -Both computers run ubuntu 12.04 with all updates and the latest git annex from the ppa, that is: - -git-annex version: 4.20131024 - -build flags: Assistant Webapp Pairing Testsuite S3 WebDAV 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 webdav glacier hook - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment deleted file mode 100644 index 6312a58a5..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_1_f4584158b35b80ece1060308883e2dc4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 1" - date="2013-11-02T19:46:28Z" - content=""" -It seems to me that the `git-annex-shell` on the remote system must be too old a version to support the gcryptsetup command. You can check this by running `git-annex-shell` there and seeing if it lists gcryptsetup in its usage message. -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment deleted file mode 100644 index f2fb4f14f..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_2_a4d7aae848340771a9b8e2c87abeea42._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" - nickname="Fabrice" - subject="comment 2" - date="2013-11-02T21:53:37Z" - content=""" -The git-annex version on the remote server is the same as the one on the client, the latest one available from the ppa (4.20131024). When I run git-annex-shell on both computers, I obtain: -[[!format sh \"\"\" -git-annex-shell: bad parameters - -Usage: git-annex-shell [-c] command [parameters ...] [option ...] - -Plumbing commands: - -commit DIRECTORY commits any staged changes to the git-annex branch -configlist DIRECTORY outputs relevant git configuration -dropkey DIRECTORY KEY ... drops annexed content for specified keys -gcryptsetup DIRECTORY VALUE sets up gcrypt repository -inannex DIRECTORY KEY ... checks if keys are present in the annex -recvkey DIRECTORY KEY runs rsync in server mode to receive content -sendkey DIRECTORY KEY runs rsync in server mode to send content -transferinfo DIRECTORY KEY updates sender on number of bytes of content received -\"\"\"]] - -Both sides seem to understand the gcryptsetup action. Actually, the message gcryptsetup permission denied comes from git-annex-shell, as far as I understand (and from the haskell source linked in the report). -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment deleted file mode 100644 index 863f401ce..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_3_06bda101ad584b4b882de8b2e202d679._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 3" - date="2013-11-02T23:51:13Z" - content=""" -I should have looked at that error message more closely. The gcryptsetup command will print a permission denied if the repository it's being run in already has a annex.uuid or already has a gcrypt id. Probably that latter needs to be relaxed for enableremote to work. -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment deleted file mode 100644 index e1049ce60..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_4_4fc6b25401b645cabc04b510bdfa6863._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 4" - date="2013-11-03T00:15:30Z" - content=""" -While I've fixed this bug, in my testing the bug only caused git-annex to fall back to accessing the remote repository using rsync, rather than using git-annex-shell to talk to it, and so `git annex get --from encryptedrepo` was able to retrieve files that were stored in that remote despite the bug. That may have failed for you for some other reason. - -You can set git.encryptedrepo.annex-gcrypt to to \"true\" to make it use the degraded rsync mode, or to \"shell\" to make it use git-annex-shell. Setting it to shell should be all that you need to do to recover from (or indeed, work around this bug). -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment deleted file mode 100644 index 137638aa5..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_5_4e193306801680bba433e75eb4dcba05._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" - nickname="Fabrice" - subject="comment 5" - date="2013-11-03T11:24:28Z" - content=""" -There is something very strange that I did not notice in my first report. When I try `git annex get --from encryptedrepo` nothing happens in the sense that git annex is not even trying to connect to the remote (no ssh connection attempt) while git.encryptedrepo.annex-gcrypt is set to true. When I set it to shell, nothing happens either. - -Another thing I did not report is that I tried the exact same manipulations with another server on which git annex is not installed. The `gcryptsetup permission denied` message was replaced by a `git-annex-shell not found` (or something similar), as expected. But the rest of the behavior was the same: no way to get the actual content with `git annex get --from`. Again, all of this is with 4.20131024, not with the ongoing version. - -I'll try got do more test with the new version. -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment deleted file mode 100644 index 0ad9768f6..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_6_76ccdf0542e76e4dbd61f3b3228d40ba._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 6" - date="2013-11-04T17:12:05Z" - content=""" -It's entirely normal for `git annex get --from remote` to skip files that it does not think are present on the remote. - -What does `git annex whereis` say? -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment deleted file mode 100644 index 3a24f4349..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_7_cd964d0a375c5cba299bf2bbbbb86acb._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkbpbjP5j8MqWt_K4NASwv0WvB8T4rQ-pM" - nickname="Fabrice" - subject="comment 7" - date="2013-11-04T18:54:54Z" - content=""" -`git annex whereis` says the files are not on the remote git, while they are because of the copy. If I do _exactly_ what's on the tip, that is if I clone the encrypted git just after having done `git annex copy --to encryptedbackup`, the remotes seems to ignore that it has the data. To have it working, I had to call `git annex sync` (push will do, I guess) in the original remote after doing the `git annex copy`. Then I can `git pull` and `git annex whereis` knows where the files are (or I can clone the encrypted remote after doing the sync/pull). - -It seems a bit strange that the copy command does not record the propagation of the file to the encrypted git. I guess this is because gcrypt is the only special remote that stores also the git part, right? Would that be a good idea (and possible) to handle it in a special way? - -Thanks Joey for everything, by the way, both the software and the amazing support via email and the website. -"""]] diff --git a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment b/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment deleted file mode 100644 index da2fef585..000000000 --- a/doc/bugs/git-annex-shell__58___gcryptsetup_permission_denied/comment_8_9bac87c85deb5bb15795df28533d0cde._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 8" - date="2013-11-04T19:14:04Z" - content=""" -Right -- Normally a special remote doesn't include a git repository. And when using a regular git remote, `git-annex-shell` is used to receive files into the repository and it records immediately that the repo has the file so there's no need to sync in that case. So gcrypt is special in this way. - -For now, I have fixed the tip to show syncing after sending files to gcrypt. It might be the case that it would make sense to do a push of the git-annex branch automatically in that case, will have to think about that and see if people get tripped up on this. -"""]] diff --git a/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t.mdwn b/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t.mdwn deleted file mode 100644 index 82afb6135..000000000 --- a/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -### Please describe the problem. - -``git annex unlock myfolder`` will unlock all files inside (`find myfolder -type l' returns nothing). - -Yet, ``git annex whereis myfolder`` shows those files are *not* in current repo. - -Meanwhile, those files also reside in a remote. git-annex-whereis does show there is a copy in that remote. - -Note that dropping files in current repo (``git annex drop``) and re-getting (``git annex get``) does download the files from that remote. However, a subsequent ``git annext whereis`` again shows 1 copy --- at that remote only. - -> Because you have 2 repositories with the same annex.uuid, which is not -> allowed. Fix your misconfigured repo to not have the same annex.uuid and -> that won't happen. [[done]] --[[Joey]] - -### What steps will reproduce the problem? - -Same as described above. - - -### What version of git-annex are you using? On what operating system? - -Lubuntu 15.10 -git annex 5.20151019 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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, git annex is wonderful. diff --git a/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t/comment_1_f68c5d45bc2ecc95c3c770faa9e22acb._comment b/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t/comment_1_f68c5d45bc2ecc95c3c770faa9e22acb._comment deleted file mode 100644 index 344ecfe23..000000000 --- a/doc/bugs/git-annex-unlock_shows_files___34__here__34____44___git-annex-whereis_doesn__39__t/comment_1_f68c5d45bc2ecc95c3c770faa9e22acb._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-30T19:55:05Z" - content=""" -Well, you also filed the bug report -[[Unable_to_take_transfer_lock]], where you said something about having -copied the repository over SMB using `cp` and some kind of OSX copy and -paste. - -So, if you did that, it seems likely that you have 2 git repositories with -the same annex.uuid setting. In fact this is confirmed by [another bug -report](http://git-annex.branchable.com/bugs/remote_repo_marked_as___34__here__34__/) -you filed. - -Since git-annex expects each repository to have a unique annex.uuid, this -is going to confuse it badly. Don't do that. Use `git clone` to make a clone -of a git repository. -"""]] diff --git a/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1.mdwn b/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1.mdwn deleted file mode 100644 index acfc25436..000000000 --- a/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. -Cf. https://github.com/joeyh/git-annex/pull/56 -patch url: https://github.com/joeyh/git-annex/pull/56.patch - -Goes together with Homebrew PR https://github.com/Homebrew/homebrew-core/pull/3724 - -Homebrew Jenkins CI timed out after two hours with Solver -still trying to find a solution. - -### What steps will reproduce the problem? -Using --flags=s3\ webapp and --max-backjumps=10000 - -### What version of git-annex are you using? On what operating system? -6.20160808 macOS 10.9, 10.10, 10.11 - -### Please provide any additional information below. -This is a follow-up to https://github.com/joeyh/git-annex/commit/18e458db, -since there's been a regression in the situation between 6.20160619 and -6.20160808, probably simply because Hackage is a moving target. - -Proposed solution is to set persistent (==2.2.4.1) instead of -persistent (<2.5) in git-annex.cabal - -> [[done]] diff --git a/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1/comment_1_62d1c8450430a6124d676598c28a8683._comment b/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1/comment_1_62d1c8450430a6124d676598c28a8683._comment deleted file mode 100644 index 37981cf46..000000000 --- a/doc/bugs/git-annex.cabal__58___persistent___61____61__2.2.4.1/comment_1_62d1c8450430a6124d676598c28a8683._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-05T20:00:33Z" - content=""" -You have presented cabal with some dependency situation that causes its -solver to blow up. But AFAICS this is only the case in your own particular -environment; it's not the case in my envionment, or Debian's -environment, etc. - -If homebrew needs particular dependency versions, you could specify them -locally in a local cabal.config file. Or you could use stack which -should always find a consistent set of dependencies. - -I don't think it makes sense for git-annex to pin down versions like -this just because one build environment is having trouble. So I don't -plan to apply this patch. - ----- - -Update: Seems the unstated goal was to make it work with ghc 8 which is -still in a state of generally unhappy dependencies. So applied for that -reason. -"""]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__.mdwn b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__.mdwn deleted file mode 100644 index 279ca3a3b..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. -git-annex crashes with "git-annex: createSession: permission denied (Operation not permitted)" when creating the first repository. Trying to start git-annex webapp after that crashes again. - -### What steps will reproduce the problem? -* Download standalone tarball -* Unpack -* Go to new folder, call "git-annex webapp" -* Click Make repository - -### What version of git-annex are you using? On what operating system? -git-annex version: 5.20140606-g48793b6 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - -Ubuntu 14.04 LTS - -Linux eee 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:02:19 UTC 2014 i686 i686 i686 GNU/Linux - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ git-annex webapp -Launching web browser on file:///tmp/webapp3414.html -git-annex: createSession: permission denied (Operation not permitted) -WebApp crashed: createSession: permission denied (Operation not permitted) -$ -# End of transcript or log. -"""]] - -> provisionally fixed; [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_1_b7a327b668e2ca053713bec1dc4e6314._comment b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_1_b7a327b668e2ca053713bec1dc4e6314._comment deleted file mode 100644 index abd79e0f7..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_1_b7a327b668e2ca053713bec1dc4e6314._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 1" - date="2014-06-09T18:46:01Z" - content=""" -createSession just calls the unix `setsid` system call. - -I have not been able to reproduce this problem using git-annex here. I suspect setsid is probably failing because git-annex is already a process group leader due to the way it was run. In this case, it should just ignore the setsid failure, which I've made it do. - -This change will be available in the standalone tarball within an hour if you want to test it. - - -"""]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_2_8864149bd87f7956143109ab591afe4f._comment b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_2_8864149bd87f7956143109ab591afe4f._comment deleted file mode 100644 index a4cdf367f..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_2_8864149bd87f7956143109ab591afe4f._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo" - nickname="Dirk" - subject="comment 2" - date="2014-06-09T21:16:36Z" - content=""" -Thanks for the fix. The new tarball does not show the issue anymore. - -Regarding \"due to the way it is run\": - -* I use Konsole as my terminal under xfce, inside of that is bash -* I made sure that I removed old stuff beforehand \"rm -rf .config/git-annex/ Desktop/annex/ .ssh/git-annex-*\" -* I went to the directory in the tarball \"git-annex.linux\" and called \"./git-annex webapp\" -* Browser used is firefox - -I guess I should setup the PATH properly. This was just meant as a test for the tarball given that there is no up to date package for ubuntu available anymore. - -Not sure if there is other information that would help you determine if I run this in a special way. -"""]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment deleted file mode 100644 index 08e5d21e7..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_3_1229d5ea8799f0a744b3f03f620df1ec._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawk9SYh6N-JUMkYkW4aOk55zC3Vr9KonDV4" - nickname="Florian" - subject="comment 3" - date="2014-06-11T18:29:38Z" - content=""" -I'm having the exact same issue on Arch. - -You said this fix was in the tarballs in one hour, which was almost two days ago. Are you refering to these downloads: http://downloads.kitenet.net/git-annex/linux/current/ I just wonder, because these show mtime of 5 days ago. - -Thx! -"""]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_4_975d2631faa17d257a6fce40e24a6e3b._comment b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_4_975d2631faa17d257a6fce40e24a6e3b._comment deleted file mode 100644 index 5048cad9b..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_4_975d2631faa17d257a6fce40e24a6e3b._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawk7iPiqWr3BVPLWEDvJhSSvcOqheLEbLNo" - nickname="Dirk" - subject="comment 4" - date="2014-06-11T19:47:35Z" - content=""" -For me the autobuilt tarball works. Go to this page: http://git-annex.branchable.com/install/Linux_standalone/. Right before the comments start is a list of the different autobuilt tar balls. - -I assume that this fix will appear in the regular tarballs with the next release. - -Dirk - - -"""]] diff --git a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_5_013be36151fc710ec30756b0f68f43dc._comment b/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_5_013be36151fc710ec30756b0f68f43dc._comment deleted file mode 100644 index 358a820bf..000000000 --- a/doc/bugs/git-annex__58___createSession__58___permission_denied___40__Operation_not_permitted__41__/comment_5_013be36151fc710ec30756b0f68f43dc._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao" - nickname="maurizio" - subject="package in debian backports shows the same error mesage" - date="2014-07-08T19:25:19Z" - content=""" -I upgraded recently (on wheezy) to package 5.20140529~bpo70+2 and when I to access the webapp I get: - - mezzo:~$ git-annex webapp - git-annex: createSession: permission denied (Operation not permitted) - -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content.mdwn b/doc/bugs/git-annex__58___failed_to_lock_content.mdwn deleted file mode 100644 index f036f1353..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content.mdwn +++ /dev/null @@ -1,107 +0,0 @@ -### Please describe the problem. - -Cannot drop unused files on a USB drive, failing with the error message "git-annex: failed to lock content". - -### What steps will reproduce the problem? - -1. Installed stand-alone verison of git-annex on Ubuntu sometime last month -2. Created a repository on my main HD, upgraded to v6 -3. Added files to it -4. Created a USB (vfat) repo using the webapp without encryption; stopped the webapp, and ran `git annex get` on the USB repo. -5. Saw that I had added some files to the repo by mistake, and used `git annex unannex $FILES` on the main HD, then `git annex unused`, then `git annex dropunused 1-101` -6. Re-synced both repos -7. In the USB repo, `git annex unused` showed the same list as on the HD. -8. `git annex dropunused 1-101` then fails -9. Installed the latest stand-alone version (6.20160229-gbe4820c) -10. tried dropping again, didn't work; reboot the computer; tried dropping again, didn't work. -11. ran `git annex upgrade` on USB repo, tried dropping agian, no success - -### What version of git-annex are you using? On what operating system? - -* git annex version 6.20160229-gbe4820c -* Ubuntu 15.10 - -### Please provide any additional information below. - -[[!format sh """ -/media/ellis/USB04/repo/taiji-lib -% cat annex/unused -2 SHA256E-s562039928--04903c0b7d4e16062b3dc0bf17a84ce7943545d9437b80947ff98a3d3483e66e.AVI 1457129072.853555s -101 SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav 1457129072.853555s -... -44 SHA256E-s561941624--fdf6f89d9403464d4c494eac67fc1525aa6b9b0adc96be99f7d42e7f5472e44c.avi 1457129072.853555s - -/media/ellis/USB04/repo/taiji-lib -% git annex dropunused 101 --debug 13:09:28 -[2016-03-05 13:09:28.675403] read: git ["--git-dir=.","--literal-pathspecs","show-ref","git-annex"] -[2016-03-05 13:09:28.677635] process done ExitSuccess -[2016-03-05 13:09:28.67773] read: git ["--git-dir=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"] -[2016-03-05 13:09:28.679775] process done ExitSuccess -[2016-03-05 13:09:28.680234] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..aee0b39b5232c369721c08eb782a7143ba2f8901","-n1","--pretty=%H"] -[2016-03-05 13:09:28.685879] process done ExitSuccess -[2016-03-05 13:09:28.686006] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..2b2b2747a6533f115867cc7a70a426764fc90286","-n1","--pretty=%H"] -[2016-03-05 13:09:28.688135] process done ExitSuccess -[2016-03-05 13:09:28.688227] read: git ["--git-dir=.","--literal-pathspecs","log","refs/heads/git-annex..4f4acf1555539a7bcb520e4befbeab803f220f67","-n1","--pretty=%H"] -[2016-03-05 13:09:28.690357] process done ExitSuccess -[2016-03-05 13:09:28.691327] chat: git ["--git-dir=.","--literal-pathspecs","cat-file","--batch"] -dropunused 101 git-annex: failed to lock content: ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav: openFd: permission denied (Permission denied) - -/media/ellis/USB04/repo/taiji-lib -% ls -l ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav --r--r--r-- 1 ellis ellis 38464078 Mar 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - -/media/ellis/USB04/repo/taiji-lib -% strace -e file -f git annex dropunused 101 --debug -... -[pid 4646] openat(AT_FDCWD, "./objects/pack", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 -[pid 4646] access("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.keep", F_OK) = -1 ENOENT (No such file or directory) -[pid 4646] stat("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.pack", {st_mode=S_IFREG|0644, st_size=828068, ...}) = 0 -[pid 4646] access("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.keep", F_OK <unfinished ...> -[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=1, si_value=0} --- -[pid 4646] <... access resumed> ) = -1 ENOENT (No such file or directory) -[pid 4646] stat("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.pack", {st_mode=S_IFREG|0644, st_size=55237, ...}) = 0 -[pid 4646] access("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.keep", F_OK) = -1 ENOENT (No such file or directory) -[pid 4646] stat("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.pack", {st_mode=S_IFREG|0644, st_size=116702, ...}) = 0 -[pid 4646] access("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.keep", F_OK) = -1 ENOENT (No such file or directory) -[pid 4646] stat("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.pack", {st_mode=S_IFREG|0644, st_size=116197, ...}) = 0 -[pid 4646] getcwd("/media/ellis/USB04/repo/taiji-lib", 129) = 34 -[pid 4646] open("./objects/info/alternates", O_RDONLY|O_NOATIME) = -1 ENOENT (No such file or directory) -[pid 4646] open("./objects/pack/pack-f6711fe647796d2143d12b6f915686d373f4e69b.idx", O_RDONLY|O_NOATIME) = 3 -[pid 4646] open("./objects/pack/pack-31185be34b1a30abb4b6e427c1ec924cfee300af.idx", O_RDONLY|O_NOATIME) = 3 -[pid 4646] open("./objects/pack/pack-80b045ea51312a9d40fdefd0c76ef54d494cd5c1.idx", O_RDONLY|O_NOATIME) = 3 -[pid 4646] open("./objects/pack/pack-69caefc604cfbcb2f374ab0b4266f444fec4930f.idx", O_RDONLY|O_NOATIME) = 3 -[pid 4646] open("./objects/ae/e0b39b5232c369721c08eb782a7143ba2f8901", O_RDONLY|O_NOATIME) = 3 -[pid 4646] open("./objects/1d/ca126189c826e37b03897754fab7e8a8687683", O_RDONLY|O_NOATIME) = 3 -[pid 4636] stat("./annex/unused", {st_mode=S_IFREG|0644, st_size=11160, ...}) = 0 -[pid 4636] open("./annex/unused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 -[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- -[pid 4636] stat("./annex/badunused", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 -[pid 4636] open("./annex/badunused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 -[pid 4636] stat("./annex/tmpunused", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 -[pid 4636] open("./annex/tmpunused", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 11 -dropunused 101 [pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 -[pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 -[pid 4636] stat("./annex", {st_mode=S_IFDIR|0755, st_size=32768, ...}) = 0 -[pid 4636] open("./annex/keys.lck", O_RDWR|O_CREAT, 0666) = 11 -[pid 4636] stat("./annex/keys/db", 0x7f2247d0ceb0) = -1 ENOENT (No such file or directory) -[pid 4636] --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=9, si_value=0} --- -[pid 4636] stat("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", {st_mode=S_IFREG|0444, st_size=38464078, ...}) = 0 -[pid 4636] open("./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav", O_RDWR) = -1 EACCES (Permission denied) -git-annex: failed to lock content: ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav: openFd: permission denied (Permission denied) -[pid 4638] +++ exited with 0 +++ -[pid 4639] +++ exited with 0 +++ -[pid 4637] +++ exited with 0 +++ -[pid 4636] +++ exited with 1 +++ -[pid 4623] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4636, si_status=1, si_utime=1, si_stime=4} --- -[pid 4623] +++ exited with 1 +++ -+++ exited with 0 +++ - -"""]] - -Could the problem have something to do with the file having permission 0444 and trying to opening it O_RDWR? - -### 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) - -Been using it since your kickstarter campaign! - -> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment deleted file mode 100644 index a6fef26b2..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_1_cf9f4221695d620dfa768b0216171690._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-07T16:58:35Z" - content=""" -I replicated this as best I could, and the dropunused succeeded. But my -strace has an extra chmod: - - stat("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", {st_mode=S_IFREG|0444, st_size=30, ...}) = 0 - stat("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", {st_mode=S_IFREG|0444, st_size=30, ...}) = 0 - chmod("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", 0100644) = 0 - open("./annex/objects/02e/a64/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133/SHA256E-s30--b6eac296ebeab4b5593387489571654cd5019d8bb3bc3bc08ac8a41e22bad133", O_RDWR) = 16 - -So, it kind of looks like it checked the permissions and decided 0444 was good -enough and didn't chmod it to allow write (in order to lock it for removal). - -The only way I can see how that could perhaps happen is if git-anenx thinks -it's in a crippled filesystem that doesn't support chmod. But then the file -shouldn't be locked down like that. I was, though, able to reproduce -that behavior after running `git config annex.crippledfilesystem true` - -So, I need more information: What filesystem is the USB drive formatted with, -and can you run `git config --list` in the git repository on the drive and -paste the output please. -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment deleted file mode 100644 index b71f04a55..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_2_a22011e4b68005c87c4bf9167c22a13f._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="ellis@9dd4c3615b5ff78a457c5832488610886fd6b255" - nickname="ellis" - subject="comment 2" - date="2016-03-08T19:26:03Z" - content=""" -Thanks Joey, here's the output from `git config --list`: - - color.diff=auto - color.status=auto - color.branch=auto - push.default=simple - core.precomposeunicode=true - credential.helper=/usr/share/doc/git/contrib/credential/gnome-keyring/git-credential-gnome-keyring - core.repositoryformatversion=0 - core.filemode=false - core.bare=true - core.symlinks=false - core.ignorecase=true - core.fsyncobjectfiles=true - annex.uuid=a8ed0f4a-47c9-4289-947d-2f4650e9ede6 - annex.sshcaching=false - annex.crippledfilesystem=true - annex.version=6 - remote.lorax.url=../../../../../mnt/taiji07/taiji-lib - remote.lorax.fetch=+refs/heads/*:refs/remotes/lorax/* - remote.lorax.annex-uuid=9ea9a021-e3c6-4d55-a118-f3f55387ef40 - filter.annex.smudge=git-annex smudge %f - filter.annex.clean=git-annex smudge --clean %f - -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment deleted file mode 100644 index fd50fb028..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_3_4d58bfb2ba40e280cf9bcb8a054757f6._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="ellis" - subject="comment 3" - date="2016-03-08T19:52:21Z" - content=""" -And the file system is VFAT: - - /dev/sde1 on /media/ellis/USB04 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment deleted file mode 100644 index 4c29c33e2..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_4_431885c1487035415acbad59b021a548._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-03-08T20:38:25Z" - content=""" -Thanks, that's consistent with my analysis. - -The only thing I don't understand is how a file on a vfat filesystem can -have mode 444. When I make a vfat filesystem and mount it on linux, -chmod doesn't change the mode of files at all; they're hardcoded at 755. - -Is your drive mounted with any interesting mount options? Paste the output -from `mount` for the drive. - -Can you chmod the file to have some mode other than 444? -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment deleted file mode 100644 index 2f3e560fa..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_5_d8c8077e4dc1e0660d082482012b6594._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="ellis" - subject="comment 5" - date="2016-03-09T10:04:14Z" - content=""" -1) I'm afraid I don't have any real knowledge of VFAT -- always avoided it, but this is a shared drive, so it seemed best to just leave it with the factory formatting. - -2) The output from `mount` is shown at the bottom of comment 3. The drive gets automounted when I plug it in. - -3) \"Can you chmod the file to have some mode other than 444?\" - -Yes. Here's a console transcript. After running `chmod 644`, git annex was able to drop the file. - - - % cd /media/ellis/USB04/repo/taiji-lib - - % ls -l ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - -r--r--r-- 1 ellis ellis 38464078 Mär 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - - % chmod 644 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - - % ls -l ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - -rw-r--r-- 1 ellis ellis 38464078 Mär 4 18:32 ./annex/objects/97e/78c/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav/SHA256E-s38464078--0db38599ed526d248857015c7b8e1b177af646939f8e0c8004b17a931ce2e101.wav - - % git annex dropunused 101 --force - dropunused 101 ok - (recording state in git...) -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment deleted file mode 100644 index cebc1f0c1..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_6_ced3c56607762562c1d21fd821d7c779._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-03-09T17:31:18Z" - content=""" -Ok, I managed to get a vfat that honors file perms with those mount -options. - -I'm going to make git-annex always try to chmod the file, even if it's on a -crippled filesystem. That should solve it. -"""]] diff --git a/doc/bugs/git-annex__58___failed_to_lock_content/comment_7_505d70bad4ebe33fedd9066bc96fa92d._comment b/doc/bugs/git-annex__58___failed_to_lock_content/comment_7_505d70bad4ebe33fedd9066bc96fa92d._comment deleted file mode 100644 index b90c1a624..000000000 --- a/doc/bugs/git-annex__58___failed_to_lock_content/comment_7_505d70bad4ebe33fedd9066bc96fa92d._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="ellis" - subject="comment 7" - date="2016-03-09T19:15:10Z" - content=""" -Thanks, Joey, much appreciated! -"""]] diff --git a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__.mdwn b/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__.mdwn deleted file mode 100644 index 976109c79..000000000 --- a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -What steps will reproduce the problem? - Start "./git-annex-webapp" - -What is the expected output? What do you see instead? - The webapp should start, but I get the error "git-annex: getUserEntryForID: failed (Success)" - -What version of git-annex are you using? On what operating system? - 3.20121017 on "Ubuntu 10.04.4 LTS" 32-Bit - -Please provide any additional information below. - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_1_11a1615962325327466895d03e3d2379._comment b/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_1_11a1615962325327466895d03e3d2379._comment deleted file mode 100644 index ef8800c21..000000000 --- a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_1_11a1615962325327466895d03e3d2379._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.118" - subject="comment 1" - date="2012-10-25T18:52:52Z" - content=""" -This means it has been unable to look up your home directory in /etc/passwd. I wonder, are you using NIS or a similar thing that keeps your user entry out of /etc/passwd? -"""]] diff --git a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_2_eac51c3299e9fc04025675360969d537._comment b/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_2_eac51c3299e9fc04025675360969d537._comment deleted file mode 100644 index dde7c0814..000000000 --- a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_2_eac51c3299e9fc04025675360969d537._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo" - nickname="Tobias" - subject="comment 2" - date="2012-10-25T21:29:05Z" - content=""" -Yes, the system is using LDAP as user backend... Any idea how I can use git-annex with LDAP as user backend? -"""]] diff --git a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_3_c23dc02c7487d63b0905f1b7f3ca59f5._comment b/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_3_c23dc02c7487d63b0905f1b7f3ca59f5._comment deleted file mode 100644 index 3b358b7ea..000000000 --- a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_3_c23dc02c7487d63b0905f1b7f3ca59f5._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.118" - subject="comment 3" - date="2012-10-25T22:18:55Z" - content=""" -Well, git-annex needs to know the user name, and the home directory. I've made it use -USER, and HOME, when set, and only fall back to getpwent otherwise. -"""]] diff --git a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_4_0e8b28de5c173bc60ecc0126fb2209ca._comment b/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_4_0e8b28de5c173bc60ecc0126fb2209ca._comment deleted file mode 100644 index 63c3b474a..000000000 --- a/doc/bugs/git-annex__58___getUserEntryForID__58___failed___40__Success__41__/comment_4_0e8b28de5c173bc60ecc0126fb2209ca._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawniayrgSdVLUc3c6bf93VbO-_HT4hzxmyo" - nickname="Tobias" - subject="comment 4" - date="2012-10-26T05:49:47Z" - content=""" -I think you mean the environment variables with \"use USER, and HOME\"? So I checked them I they are correct. -Reading man(3) getpwent says \"from the password database (e.g., the local password file /etc/passwd, NIS, and LDAP)\", so it should be no problem with the LDAP backend I'm using to log-in... -One other special thing: The home directory is on a NFS share. -"""]] diff --git a/doc/bugs/git-annex_chokes_on_filenames_including_spaces.mdwn b/doc/bugs/git-annex_chokes_on_filenames_including_spaces.mdwn deleted file mode 100644 index 1412d6b36..000000000 --- a/doc/bugs/git-annex_chokes_on_filenames_including_spaces.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -git-annex throws an error message (see below) when trying to add a file whose name includes a space. - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20161012 -build flags: ConcurrentOutput Feeds Quvi -uname -srm: Linux 4.7.10-hardened x86_64 - - -### Please provide any additional information below. - -[[!format sh """ -aranea@gentp ~/t/annex-test $ git init . -Initialized empty Git repository in /home/aranea/tmp/annex-test/.git/ -aranea@gentp ~/t/annex-test master $ git annex init -init ok -(recording state in git...) -aranea@gentp ~/t/annex-test master $ touch 'foo bar' -aranea@gentp ~/t/annex-test master $ git annex add -add foo bar git-annex: unknown response from git cat-file ("HEAD:./foo bar missing",Ref "HEAD:./foo bar") -CallStack (from HasCallStack): - error, called at ./Git/CatFile.hs:102:28 in main:Git.CatFile -"""]] - -> What an embarrasing reversion. [[fixed|done]] and I'll push a release for -> it right away. --[[Joey]] diff --git a/doc/bugs/git-annex_chokes_on_filenames_including_spaces/comment_1_4cc38b8629a636bc607ce029d6d15dcf._comment b/doc/bugs/git-annex_chokes_on_filenames_including_spaces/comment_1_4cc38b8629a636bc607ce029d6d15dcf._comment deleted file mode 100644 index 89a847846..000000000 --- a/doc/bugs/git-annex_chokes_on_filenames_including_spaces/comment_1_4cc38b8629a636bc607ce029d6d15dcf._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="aranea@650e41fad422f2a4d6f36ca1f20d41b7c0f18ab7" - nickname="aranea" - avatar="http://cdn.libravatar.org/avatar/8574023ce00757ca95b1708b7306602a" - subject="comment 1" - date="2016-10-31T22:31:44Z" - content=""" -According to git bisect, this bug has been introduced a month ago by commit 34530e59. -"""]] diff --git a/doc/bugs/git-annex_creates_many_zombies.mdwn b/doc/bugs/git-annex_creates_many_zombies.mdwn deleted file mode 100644 index d0f55dc71..000000000 --- a/doc/bugs/git-annex_creates_many_zombies.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -### Please describe the problem. - -In a debian unstable docker container, I run `git-annex assistant --auto` on a few repositories. - -After a few days, I have many (> 10000 right now) zombie processes: - - % ps x | grep "git-annex.*defunct" | wc -l - 10325 - -### What steps will reproduce the problem? - -Keep `git-annex assistant` running. - -### What version of git-annex are you using? On what operating system? - -Binary version 5.20151116-gbe86081 on Debian Linux unstable (up-to-date from a few days ago when my docker container started) - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -I couldn't live without git-annex to synchronize my documents over multiple hosts and archives :-) - -> [[done]]; this is a docker bug if anything, and I really don't see any -> way git-annex can solve it. --[[Joey]] diff --git a/doc/bugs/git-annex_creates_many_zombies/comment_1_8390ade0c0a768d440bc71b20578ccbe._comment b/doc/bugs/git-annex_creates_many_zombies/comment_1_8390ade0c0a768d440bc71b20578ccbe._comment deleted file mode 100644 index 5985af21e..000000000 --- a/doc/bugs/git-annex_creates_many_zombies/comment_1_8390ade0c0a768d440bc71b20578ccbe._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-12-02T16:34:03Z" - content=""" -This seems to be the same problem discussed here in the context of -git-annex <https://github.com/datalad/datalad/issues/132> and here in the -general context of docker being broken -<blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/>. - -So, it's a docker problem; since docker containers lack -any proper init, nothing waits on orphaned processes. While git-annex -normally waits on all child processes it starts, if a git-annex process -itself exits for some reason (eg an error) while a child process is -running, this results in an orphaned process. - -It is the responsibility of init to wait on such orphaned processes. So, eg -systemd-nspawn containers don't have this problem (in addition to their -many, many other benefits over docker). And if you're stuck running docker -all it takes to solve the problem is to make the top-level process in the -container do a `wait()` loop. As is done by eg -<http://github.com/phusion/baseimage-docker>. - -It might be possible for git-annex to have a top-level exception -handler that waits on any child processes that might be running. However, -this seems difficult to arrange; when git-annex was talking to a child -process over a handle, the child process may keep running as long as that -handle remains open, so the exception handler would block waiting for the -child process to exit. This kind of difficulty is probably why unix -delegates this job to init in the first place. -"""]] diff --git a/doc/bugs/git-annex_creates_many_zombies/comment_2_4f08b8a1bf230d090848cc2f7c2d82f7._comment b/doc/bugs/git-annex_creates_many_zombies/comment_2_4f08b8a1bf230d090848cc2f7c2d82f7._comment deleted file mode 100644 index 1b81252e1..000000000 --- a/doc/bugs/git-annex_creates_many_zombies/comment_2_4f08b8a1bf230d090848cc2f7c2d82f7._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="SamuelTardieu" - subject="comment 2" - date="2015-12-17T11:15:55Z" - content=""" -Indeed. - -I've migrated the Gentoo server from OpenRC to systemd so that I can use systemd-nspawn instead of docker for git-annex. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__.mdwn b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__.mdwn deleted file mode 100644 index 39cfb6b93..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -### Please describe the problem. - -Attempt to add files to annex leads to - - git-annex: waitToSetLock: unsupported operation (Function not implemented) - -Here is the log from git annex test : <http://www.onerussian.com/tmp/git_annex_test_lustre.txt> - -### What version of git-annex are you using? On what operating system? - -5.20150731-g41f79f2 OS probably CentOS (I am just channeling the report -- don't shoot the messanger) - -> [[done]] --[[Joey]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_10_cdbd35ab0ba9c9157fd6530bebbc4650._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_10_cdbd35ab0ba9c9157fd6530bebbc4650._comment deleted file mode 100644 index 0b91fe818..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_10_cdbd35ab0ba9c9157fd6530bebbc4650._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 10""" - date="2015-11-10T18:47:36Z" - content=""" -I think what yoh meant above was that -o lock (not `sync`) has a heavy -performance impact. Or at least a perceived one. And thus, lustre clusters -are not using it even though the feature is available and would probably be -find for git-annex's use if enabled. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_11_9425cfd2739eca4a21c27d490192c31a._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_11_9425cfd2739eca4a21c27d490192c31a._comment deleted file mode 100644 index 5608afa30..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_11_9425cfd2739eca4a21c27d490192c31a._comment +++ /dev/null @@ -1,37 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""design""" - date="2015-11-11T17:54:24Z" - content=""" -* annex.pidlock config setting -* init can test if regular locks work and if not set annex.pidlock -* Use .git/annex/lock as the lock file; create with `O_EXCL` and write pid - and program name to it. (Should be able to check for stale pid and break - old lock.) -* Adapt Utility.LockPool to use that lock file and lock method when - annex.pidlock is set. (How? It's a generic library..) -* Note that for sanity, whenever Utility.LockPool would create a - fine-grained lock file, that should still happen when using - annex.pidlock. Just avoid locking it and use the - global lock. This prevents any bugs along the lines of some code - depending on the fine-grained lock file having been created - (in order to delete it etc). -* (We could possibly assume that, if a lock file is being created, - it could be used as a pid lock file, and so use that instead of the - single top-level lock file. This assumption might hold, but I don't - really want to risk it. If some other code path uses the same lock file - but does not allow it to be created, it would not be able to write the - pid to it (because it might be eg an annex object file), then the two - code paths would end up using different lock files for the same lock, - which would be bad.) - -This will always be an exclusive lock, and a single lock at that, unlike -git-annex's usual fine-grained, often shared locks. But, the LockPool -builds all that stuff at the thread level using STM anyway, so multiple -threads of the same process can still cooperate with shared locks etc. - -Commands that don't need to take any lock (eg, query commands) will -interoperate as before. But, many commands that can normally run -concurrently won't be able to when using annex.pidlock, and will -have to either loop-wait on the lock file, or error out. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_12_93e7e29ebcbffe8913a0dc216636ae47._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_12_93e7e29ebcbffe8913a0dc216636ae47._comment deleted file mode 100644 index 930f99d3c..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_12_93e7e29ebcbffe8913a0dc216636ae47._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 12" - date="2015-11-11T19:28:41Z" - content=""" -sounds good to me ;) - -\"write pid and program name to it\" -- may be also a hostname so this could be safe in shared/networked environments... I believe emacs does similar, e.g. for 1.txt it creates a symlink - -.#1.txt -> yoh\@head1.hydra.dartmouth.edu.28757:1441910040 - - -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_13_5a1191042b32a85b4299cff3004d29de._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_13_5a1191042b32a85b4299cff3004d29de._comment deleted file mode 100644 index ae9691cf9..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_13_5a1191042b32a85b4299cff3004d29de._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 13""" - date="2015-11-13T18:23:37Z" - content=""" -While testing a git-annex that used pid locks, on the Lustre -system I've been given access to, I observed something most -strange: - - link(".git/annex/locktmp12011", ".git/annex/pidlock") = 0 - lstat64(".git/annex/locktmp12011", {st_mode=S_IFREG|0444, st_size=70, ...}) = 0 - lstat64(".git/annex/pidlock", {st_mode=S_IFREG|0444, st_size=70, ...}) = 0 - ... - unlink(".git/annex/pidlock") = 0 - -Seeing that strace, it would make sense that the pidlock file didn't exist, -since a hard link was successfully made by that name, and link() never, -ever overwrites an existing file. The stats of the 2 files are of course -identical since they're hard links. And, since the pidlock is unlinked at -the end, we'd expect the file to be gone then. - -But, none of that has anything to do with the reality. Which was: -The pidlock file already existed, with size=72, and had existed for some -hours at the point the strace begins. The link didn't replace it -at all, and the unlink didn't delete it. When the program exited, -the pidlock file still existed, with contents unaltered. - -All I can guess is happening is that different processes on a Lustre -filesystem, running on the same host, somehow see inconsistent realities. - -I do think that, despite this being completely insane, the locking will -actually work ok, when all git-annex processes in a given repo on Lustre -are running *on the same computer*. That because git-annex actually will -drop a proper lock into a proper filesystem (/dev/shm), and so avoid all -this Lustre nonsense. - -But in general, I can make no warantee express or implied as to the -suitability of Lustre as a platform to use git-annex. If it's this -inconsistent, and modifications made to files are somehow silently rolled -back, anything could happen. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_14_4dea6eac389bbf5235a3d5d3378e6d04._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_14_4dea6eac389bbf5235a3d5d3378e6d04._comment deleted file mode 100644 index bb58cbeeb..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_14_4dea6eac389bbf5235a3d5d3378e6d04._comment +++ /dev/null @@ -1,38 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 14""" - date="2015-11-13T20:00:48Z" - content=""" -Adding to the crazy Lustre fun, check this out: - - $ ls -l .git/annex/ - total 56 - -rw-rw-r-- 1 hess root 18387 Nov 13 14:35 index - -rw-rw-r-- 1 hess root 41 Nov 13 14:35 index.lck - drwxrwsr-x 2 hess root 12288 Nov 13 14:35 journal - -rw-rw-r-- 1 hess root 0 Nov 13 11:48 journal.lck - drwxrwsr-x 2 hess root 4096 Nov 13 14:35 misctmp - drwxrwsr-x 88 hess root 4096 Nov 13 14:35 objects - -r--r--r-- 1 hess root 70 Nov 13 14:35 pidlock - -r--r--r-- 1 hess root 70 Nov 13 14:35 pidlock - -rw-rw-r-- 1 hess root 0 Nov 13 11:48 sentinal - -rw-rw-r-- 1 hess root 23 Nov 13 11:48 sentinal.cache - -There are 2 pidlock files in that directory listing. 2 files with the same name. -I deleted one of them, and with no other changes, ls shows only 1 now. - - -r--r--r-- 1 hess root 74 Nov 13 14:35 pidlock - -Notice that the file stat has changed too. - -So, Lustre has clearly thrown POSIX out the window, and then defrenstrated -sanity for good measure. - -On the plus side, this may show how I can detect when rename() fails to -preserve POSIX semantics.. - -Update: Indeed, I was able to get git-annex to detect the doubled file -and so know that it can't take the lock. - -I can't guarantee anything, but this is enough to close this bug. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_1_5dc6b520381a7b26563c641fcc284b31._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_1_5dc6b520381a7b26563c641fcc284b31._comment deleted file mode 100644 index d5031602a..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_1_5dc6b520381a7b26563c641fcc284b31._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="FWIW: possibly useful" - date="2015-09-04T13:26:19Z" - content=""" -https://github.com/marcindulak/vagrant-lustre-tutorial -to get env with lustre deployment. yet to figure out user management(see [https://github.com/marcindulak/vagrant-lustre-tutorial/issues/2]) since issue didn't replicate under root, so I guess it is a question of some permissions -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_2_8c8d7ad99de78d282d202c541323a299._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_2_8c8d7ad99de78d282d202c541323a299._comment deleted file mode 100644 index 71da557b1..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_2_8c8d7ad99de78d282d202c541323a299._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-09-09T16:19:06Z" - content=""" -This is a POSIX fcntl lock failing on that filesystem. - -git-annex really needs these locks for safe concurrency, including guarding -against situations where data could be lost. - -I wonder if flock locks would be more portable? -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_3_08d950812832acd5aa54287a54fed207._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_3_08d950812832acd5aa54287a54fed207._comment deleted file mode 100644 index b984c6788..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_3_08d950812832acd5aa54287a54fed207._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 3" - date="2015-09-10T18:44:25Z" - content=""" -so far I have failed to replicate this issue on a luster under virtualbox following aforementioned instructions (if you would like, there is a screen available under datalad@smaug to which I believe you should have access to). I guess I will wait for issues associated with standalone builds to get resolved (ref: http://git-annex.branchable.com/bugs/fails_to_addurl_to_file:__47____47____47___in_the_most_recent_snapshot_build/#comment-424388b7369d9f4889afaa56381e4e38) before attempting more tests there. Meanwhile I will seek more information on the problematic lustre setup (versions etc) -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_4_b8c8fac1dc7bd72cfa8a01495c4a5096._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_4_b8c8fac1dc7bd72cfa8a01495c4a5096._comment deleted file mode 100644 index 0b766149f..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_4_b8c8fac1dc7bd72cfa8a01495c4a5096._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 4" - date="2015-09-24T20:33:51Z" - content=""" -please let me know if you would need an access on the lustre box to troubleshoot this issue (I have failed to replicate in virtualbox) -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_5_e873c82ebc62e0af5051cf36ca084e0a._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_5_e873c82ebc62e0af5051cf36ca084e0a._comment deleted file mode 100644 index c8ec76575..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_5_e873c82ebc62e0af5051cf36ca084e0a._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2015-09-29T16:38:17Z" - content=""" -AFAICS, you have not managed to reproduce the problem. If there's a way to -get access to a box that does have the problem, my ssh key is `ssh-rsa -AAAAB3NzaC1yc2EAAAADAQABAAABAQC1YoyHxZwG5Eg0yiMTJLSWJ/+dMM6zZkZiR4JJ0iUfP+tT2bm/lxYompbSqBeiCq+PYcSC67mALxp1vfmdOV//LWlbXfotpxtyxbdTcQbHhdz4num9rJQz1tjsOsxTEheX5jKirFNC5OiKhqwIuNydKWDS9qHGqsKcZQ8p+n1g9Lr3nJVGY7eRRXzw/HopTpwmGmAmb9IXY6DC2k91KReRZAlOrk0287LaK3eCe1z0bu7LYzqqS+w99iXZ/Qs0m9OqAPnHZjWQQ0fN4xn5JQpZSJ7sqO38TBAimM+IHPmy2FTNVVn9zGM+vN1O2xr3l796QmaUG1+XLL0shfR/OZbb` - -- or, there are some simple things could be run on that box to check if - eg, fcntl locks work at all. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_6_f439c7d9491036035d95a4c0abc99123._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_6_f439c7d9491036035d95a4c0abc99123._comment deleted file mode 100644 index 032c7245b..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_6_f439c7d9491036035d95a4c0abc99123._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="account information was emailed" - date="2015-10-05T23:13:29Z" - content=""" -please let me know if you didn't get it -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment deleted file mode 100644 index 4d2916712..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_7_1c0352c37ff07a8478d13c12aa72b484._comment +++ /dev/null @@ -1,65 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2015-10-06T16:34:18Z" - content=""" -I have an account on the system now. - -As expected, it's an fcntl lock failing: - - fcntl64(7, 0xe /* F_??? */, 0xf7680510) = -1 ENOSYS (Function not implemented) - -git-annex init also uses such a lock, so also fails. A standalone C program -that I built on the system used fcntl(), rather than fcntl64() for locking, -and also failed. - - fcntl(3, F_SETLKW, {type=F_WRLCK, whence=SEEK_SET, start=0, len=10}) = -1 ENOSYS (Function not implemented) - -flock() locking also fails on this filesystem as does lockf(), -all with ENOSYS. So, I think there's no usable file locking at all. - -I notice this system has an old kernel (2.6.32), and lustre 1.8.9. - -<http://comments.gmane.org/gmane.comp.file-systems.lustre.user/3429> -This thread says that fnctl locking works back to lustre 1.2 or earlier, -but is not enabled by default and needs a -o flock mount option. - -So, I think that would be the first thing to try! - -(Some thoughts on other options below.) - ----- - -The only option on the git-annex side would be to add an option to totally -disable use of locks, which would make it rather unsafe to use. -Or to use only dotlocks (file existence level locks). - -Dotlocks are problematic. Some of the uses git-annex makes of locking, -like using both shared and exclusive locks on a file to let multiple -concurrent readers, would be very hard to emulate with dotlocks. Also, -dotlocks go stale when processes die, and git-annex uses lots of different -locks in different places, which would be problematic to clean up in such -a situation. - -I think that it might make sense, if git-annex has to fall back to dotlocks, -to keep the use down to a single top-level dotlock, and only let one git-annex -process run at a time. Instead of trying to replicate the full suite of -fcntl lock file uses with dotlocks. - -(Note that this approach would not allow using the assistant, as it -execs helper git-annex processes to transfer files etc. Otherwise, git-annex -should basically work. Even git annex get -JN would work ok, since git-annex -uses inter-thread locking which will work fine here.) - ----- - -Of course, this assumes that a distributed filesystem, like lustre, -is consistent enough to support the atomic operations needed to use -even simple dotlocks. It might be that git-annex on 2 nodes could -race and both think they successfully took the dotlock, and there -are situations where git-annex could then lose data. - -According to <https://en.wikipedia.org/wiki/Lustre_%28file_system%29#Locking>, -"Access and modification of a Lustre file is completely cache coherent among all of the clients", -so I guess it'd work well enough. -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_8_7bdcfb72d5b9998402317ae6c9fd6046._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_8_7bdcfb72d5b9998402317ae6c9fd6046._comment deleted file mode 100644 index 82012ec6a..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_8_7bdcfb72d5b9998402317ae6c9fd6046._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="FWIW" - date="2015-10-30T17:51:09Z" - content=""" -found another user of lustre who wouldn't be able to use annex there -- 'sync' is not an option for them since it has heavy performance hit. - -What does git do? -"""]] diff --git a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_9_9f6b04e9f155d289e8330b444585444f._comment b/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_9_9f6b04e9f155d289e8330b444585444f._comment deleted file mode 100644 index d7c331bee..000000000 --- a/doc/bugs/git-annex_doesn__39__t_work_on_lustre__58___waitToSetLock__58___unsupported_operation___40__Function_not_implemented__41__/comment_9_9f6b04e9f155d289e8330b444585444f._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2015-11-10T15:25:58Z" - content=""" -git uses dot-locks (.git/index.lck). - -I need to understand why multiple Lustre users seem to have it configured -in a way that doesn't allow using the locking capabilities that are built -into it. Maybe there's a good reason they do that; but adding ugly top-level -dot locking to git-annex without a good reason could be a bad mistake. -"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn deleted file mode 100644 index e544015a6..000000000 --- a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -### Please describe the problem. - -I'm sending a stream of keys and filenames to git-annex fromkey on stdin, and it errors out with "git-annex: <stdin>: hGetContents: invalid argument (invalid byte sequence)". On the other hand yipdw tried to reproduce this and it worked fine for him, so I must be doing something wrong. - -I have LANG=en_US.UTF-8 set in my environment, if that matters. - -### What steps will reproduce the problem? - -[[!format sh """ -echo "MD5-s3263532--0b4d070eff7baa8ef314ca330aecb71f é" | git-annex fromkey -"""]] - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -git-annex version: 6.20161118-g0a34f08 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -"""]] - -### Please provide any additional information below. - -Note that this is indeed valid utf-8: - -[[!format sh """ - db48x ~ projects IA.BAK-server echo "é" | hexdump -C -00000000 c3 a9 0a |...| -00000003 -"""]] - -> Despite my strange inability to reproduce these, there's really only one -> thing that can fix it, namely using fileEncoding. Now done for all batch -> and stdin reading stuff. [[fixed|done]] I suppose. --[[Joey]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment deleted file mode 100644 index a0409e281..000000000 --- a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_1_aa6fe46ee76dd8bfa9a56cbd5131cb8b._comment +++ /dev/null @@ -1,55 +0,0 @@ -[[!comment format=mdwn - username="alpernebbi" - avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" - subject="UTF-8 problems in some other commands" - date="2016-12-05T20:46:07Z" - content=""" -Running the command above gives me the same error on Xubuntu 16.04, using `git-annex-standalone` package from NeuroDebian repositories. - - git-annex version: 6.20161122+gitg9f179ae-1~ndall+1 - build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository versions: 3 5 6 - upgrade supported from repository versions: 0 1 2 3 4 5 - operating system: linux x86_64 - -I encountered other commands that fail as well: - - $ touch u.txt ü.txt - $ git annex add - - $ git-annex calckey ü.txt - # prints key - - $ git-annex calckey --batch - ü.txt - # dies - - $ git-annex lookupkey ü.txt - # prints key - - $ git-annex lookupkey --batch - ü.txt - # dies - - $ git-annex metadata --batch --json - {\"file\":\"ü.txt\"} - # dies - - $ git-annex metadata --batch --json - {\"file\":\"u.txt\",\"fields\":{\"ü\":[\"b\"]}} - # dies - - $ git-annex metadata --batch --json - {\"file\":\"u.txt\",\"fields\":{\"a\":[\"ü\"]}} - # dies - -All those die without output, all $? are 0. -No values were recorded to metadata. -Also: - - $ git-annex-metadata --json - # entry for \"ü.txt\" has \"file\":\"��.txt\" -"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment deleted file mode 100644 index 0b2cabdf9..000000000 --- a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_2_37643180ecbc6c6bb0504b3acb18d1e7._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-12-08T21:03:14Z" - content=""" -I'm not able to reproduce the original reported problem; it works even when -using the C locale. However, it may be that this patch would fix it: - -<pre> -diff --git a/Command/FromKey.hs b/Command/FromKey.hs -index dca63aa..6a81c1f 100644 ---- a/Command/FromKey.hs -+++ b/Command/FromKey.hs -@@ -45,7 +45,9 @@ startMass = do - next massAdd - - massAdd :: CommandPerform --massAdd = go True =<< map (separate (== ' ')) . lines <$> liftIO getContents -+massAdd = do -+ liftIO $ fileEncoding stdin -+ go True =<< map (separate (== ' ')) . lines <$> liftIO getContents - where - go status [] = next $ return status - go status ((keyname,f):rest) | not (null keyname) && not (null f) = do -</pre> - -(The NeuroDebian git-annex-standalone may well have had its locale -installation broken by [[!commit c07981122672f6cc87ca08efb57d8a7b1e2f5725]], -which assumes that the git-annex.linux is writable by the user. -I doubt that is related to the original bug report.) -"""]] diff --git a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment b/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment deleted file mode 100644 index 5011aa1fa..000000000 --- a/doc/bugs/git-annex_fromkey_barfs_on_utf-8_input/comment_3_7342e29b0d2225abc5800638e3b377ed._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="alpernebbi" - avatar="http://cdn.libravatar.org/avatar/daf2abb14f39e28ad75d5f9a03fcd106" - subject="comment 3" - date="2016-12-10T07:36:04Z" - content=""" -I experienced all these with the [linux standalone](https://git-annex.branchable.com/install/Linux_standalone/) from this site as well. - -However, I couldn't reproduce them in a Debian unstable chroot where I installed the `git-annex` package from their repos. -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__.mdwn b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__.mdwn deleted file mode 100644 index f790de552..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -### Please describe the problem. - -When cloning/syncing a repository (and probably doing some nono's in the process), -git annex will happily delete files. -This cost me several files, which just by coincidence were not totally important, still its *very* unsettling. - -### What steps will reproduce the problem? - -I did not try to exactly reproduce it yet (sorry, no time right now), but here is vaguley what I did (sorry its been a process spread over -several hours and i was doing lots of other things in parallel so I'm fuzzy about details): - - * have a repository in direct mode on your local harddrive, say ~/myannex - * git clone ~/myannex to /usbhd/myannex, git annex init. - The usbhd is a FAT, git annex recognizes it as "crippled filessytem". - * Git annex get all from ~/myannex. So far, so good. - * create several files on ~/myannex, git annex add them - * do a git annex add on them, abort it (realizing SHA256E takes forever, so changing to WORM), repeat add - (not sure wheter i did a git annex sync here) - * create several files on /usbhd/myannex, git annex add them - (not sure wheter i did a git annex sync here again) - -All repos are in direct mode. - -From here on i don't remember the exact order of events, one definite -- probably important -- nono i did, -was: -I executed a git annex sync/get on the usbhd in a sub-directory (i.e. not in the git base dir), say /usbhd/myannex/foo/bar/, -so it went on creating /usbhd/myannex/foo/bar/foo, which of course was not intended. -However /usbhd/myannex/foo/bar/foo contained FAT-crippled-symlinks to the new files in ~/myannex (good). - -In order to avoid a potential messy situation i just renamed /usbhd/myannex/foo to /usbhd/myannex/foo_bak -(which I just realize while writing this, saved me the hash values of my files, yay :)) - -However when I tried to repeat the procedure, it seems that the new files would not appear on the usbhd (for a reason i totally don't get, maybe I synced back before realizing my sub-foo mistake). -When I synced usbhd -> ~/myannex again, git-annex happily deleted my new files there which obviously quite upset me. - -Again, sorry for this horribly chaotic description, -I'll try and deliver a more reproducible description, but for the next 2 weeks at least I'm too busy for that. - - - -### What version of git-annex are you using? On what operating system? - -Archlinux, -3.9.2-1-ARCH #1 SMP PREEMPT Sat May 11 20:31:08 CEST 2013 x86_64 GNU/Linux - -aur/git-annex-bin 4.20131002-1 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -[[!tag moreinfo]] - -> [[done]]; never heard back with any useful information, and -> there was a bug that could have caused this that got fixed soon after it -> was reported. --[[Joey]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_1_5dd4d1cec069c13184f5dd9efca6721b._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_1_5dd4d1cec069c13184f5dd9efca6721b._comment deleted file mode 100644 index a8994ba9a..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_1_5dd4d1cec069c13184f5dd9efca6721b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://droggl.myopenid.com/" - ip="92.76.150.86" - subject="comment 1" - date="2013-10-08T07:46:35Z" - content=""" -Just in case you wonder: the most important (in the sense of not backupped elswhere) files where some scripts which i did hash with SHA256E and not with WORM. -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_2_d9b65fe4cb4bfd58f37e7da5350c6401._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_2_d9b65fe4cb4bfd58f37e7da5350c6401._comment deleted file mode 100644 index 8574d974b..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_2_d9b65fe4cb4bfd58f37e7da5350c6401._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://cstork.org/" - nickname="Chris Stork" - subject="git annex get/sync don't delete files" - date="2013-10-10T11:43:29Z" - content=""" -AFAIU it's impossible for the 'get' subcommand to delete anything because it only copies files to .git/annex/objects. - -'sync' should also never delete files because it only adds files to the annex (i.e. checksums them and sets up the links and directories in .git/annex), commits things to git and pulls/pushes the git-annex specific branches to/from other repos. - -So I think some other 'nono' must have messed up your files. - -If you ever used (maybe unintentionally) used indirect mode there seem to be a rather high chance that some of your otherwise lost content is still in .git/annex/objects. Did you check if there's are any files in .git/annex/objects ? -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_3_1027187b203addd65af8cf1faf28727d._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_3_1027187b203addd65af8cf1faf28727d._comment deleted file mode 100644 index d5c08fb4f..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_3_1027187b203addd65af8cf1faf28727d._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="64.134.31.139" - subject="comment 3" - date="2013-10-16T20:45:25Z" - content=""" -At least part of this sounds like [[direct_mode_assistant_in_subdir_confusion]]. The report is too confused for me to tell if that's the whole of the problem. - -Note that git-annex stores files in git, so if it did something wrong, you can switch to indirect mode, and use regular git commands to check out a tree from before the problem occurred. -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment deleted file mode 100644 index be972fa9a..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_4_ac65028203ff0cbdb978200235fb4e9c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.47" - subject="comment 4" - date="2013-10-26T19:26:22Z" - content=""" -I have moreinfoed this bug, until I hear back with a better problem description. - -Using `git log --stat` to investigate any commits where files were removed would probably be a useful way to get a handle on what happened. -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment deleted file mode 100644 index d5d2c35d2..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_5_fe2ba9550fc9dc2dc877965b436fe823._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkW9u-8uqR62QBZjeTNCXsL7Ds55dAMGbA" - nickname="Horea" - subject="comment 5" - date="2015-04-17T22:15:07Z" - content=""" -I am experiencing the same thing (and have experienced it 1.5 years ago as well, right before deciding to never again use git-annex). Enough info or not is it simply unacceptable for your software to do this and you should look into it as best you can. Try to repeat the steps which he described. I for one, am getting much the same results. -"""]] diff --git a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_6_f36c0ab40bac68445fa0f205661c9f51._comment b/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_6_f36c0ab40bac68445fa0f205661c9f51._comment deleted file mode 100644 index d794c23f9..000000000 --- a/doc/bugs/git-annex_happily_deleted_most_of_my_files___36____35____38____33__/comment_6_f36c0ab40bac68445fa0f205661c9f51._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2015-04-18T18:52:20Z" - content=""" -It's approximately 1000 times easier for someone who is experiencing a -problem to paste a tracript into this bug report than it is for me to guess -what someone might be doing and reproduce their bug (or problem, or mistake -or oops, or whatever) from basically no information. - -This is why I ask for bugs to be filed with either transcripts, or the -steps that can be used to reproduce them. - -I think you'll find that if you post enough information for a bug to be -reproduced, it'll get fixed quite fast. -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config.mdwn b/doc/bugs/git-annex_rewrites_.ssh__47__config.mdwn deleted file mode 100644 index 325a4c351..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -### Please describe the problem. -Running git annex assistant, my .ssh/config file is rewritten. First, it is a symlink, but then git-annex makes it into an actual file. Second, it adds a trailing whitespace to a generic host block: - - Host - ForwardAgent no - ... - -### What steps will reproduce the problem? -For the symlink, just make .ssh/config a symlink to the real thing. Have a generic host block will add trailing whitespace. Starting git annex assistant will rewrite .ssh/config. - -### What version of git-annex are you using? On what operating system? -git-annex-5.20140717-8.fc24.x86_64 - -### 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) -Has worked wonders for syncing keepass files between devices; just now setting up assistant to do things automatically though :) . - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_1_030209c8c309e976761825c6c51a602d._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_1_030209c8c309e976761825c6c51a602d._comment deleted file mode 100644 index 26df1211a..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_1_030209c8c309e976761825c6c51a602d._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-21T16:14:03Z" - content=""" -The assistant does not normally do this when you merely start it up. It does it -when you configure a ssh remote, when it needs to modify that file. -It might also modify the file on startup if it detects a configuration that -an old version of the assistant put in that needs to be fixed up. - -Is the trailing whitespace you speak of just a newline added after the -existing host block, or something else? Your "..." is not very clear. - -Fixed symlink issue in git. -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_2_827d2239cb0e9206e40f6dc26e37f140._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_2_827d2239cb0e9206e40f6dc26e37f140._comment deleted file mode 100644 index a47e96f7c..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_2_827d2239cb0e9206e40f6dc26e37f140._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://mathstuf.id.fedoraproject.org/" - nickname="mathstuf" - subject="comment 2" - date="2015-09-21T18:27:07Z" - content=""" -Ah, should have been more specific, sorry. It adds a space to the end of the \"Host\" line (the following are just global settings like turning off ssh-agent forwarding, and disabling insecure ciphers and such). -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_3_52ca93aa55270ec4817bb8ec7fba5920._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_3_52ca93aa55270ec4817bb8ec7fba5920._comment deleted file mode 100644 index 48fffe1af..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_3_52ca93aa55270ec4817bb8ec7fba5920._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-09-21T20:48:00Z" - content=""" -Hmm, I think I see, your line was "Host\n" and becomes "Host \n". - -That's because the parser expects lines of the form "Key Value". -But, what does this Host line w/o any host specified do? -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_4_e457acce4d9f56ad4682c6746a1c4cdb._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_4_e457acce4d9f56ad4682c6746a1c4cdb._comment deleted file mode 100644 index 660db6505..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_4_e457acce4d9f56ad4682c6746a1c4cdb._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://mathstuf.id.fedoraproject.org/" - nickname="mathstuf" - subject="comment 4" - date="2015-09-21T21:24:26Z" - content=""" -Ah, indeed. ssh_config(5) basically says that \"*\" should be used to have the meaning I intended. Looking at the history of the file in my dotfiles repo has it coming from almost 4 years ago. I either copied some bogus stanza from online or misread the docs at that time. Feel free to close :) . -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_5_4316aff6470006183e91004946387141._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_5_4316aff6470006183e91004946387141._comment deleted file mode 100644 index 726397fcb..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_5_4316aff6470006183e91004946387141._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2015-09-22T16:03:42Z" - content=""" -Well, it does seem legal to do that -- man page says a pattern can be 0 or -more characters, and you have 0. - -I've put in a fix in the generator to avoid adding whitespace in this -case. -"""]] diff --git a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_6_316889f4c822828550c8378dec1eae4d._comment b/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_6_316889f4c822828550c8378dec1eae4d._comment deleted file mode 100644 index 85d644575..000000000 --- a/doc/bugs/git-annex_rewrites_.ssh__47__config/comment_6_316889f4c822828550c8378dec1eae4d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://mathstuf.id.fedoraproject.org/" - nickname="mathstuf" - subject="comment 6" - date="2015-09-25T05:42:22Z" - content=""" -Interesting. It certainly wasn't having any effect with no tokens at least, but I guess it also wasn't choking on the syntax either. Anyways, now that I have \"*\" in there properly, SSH'ing to /old/ hosts fails. And by old, I mean a Debian Etch VM :) . -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add.mdwn b/doc/bugs/git-annex_smudge_fails_on_git_add.mdwn deleted file mode 100644 index 5b91e1ed3..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add.mdwn +++ /dev/null @@ -1,59 +0,0 @@ -### Please describe the problem. - -I want to be able to use "normal" git commands so I'm trying a v6 repo. -I have attempted to set up `.gitattributes` to only annex non-text mime types. When I attempt to add something that would go into the annex, the `git-annex smudge` command fails. - - - -### What steps will reproduce the problem? - -See transcript below - - -### What version of git-annex are you using? On what operating system? - -debian jessie; built from github using stack;installed to ~/.local/bin - -[[!format sh """ -git-annex version: 6.20160308-ge51f555 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotif -y XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_51 -2 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 6 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 -"""]] - -### Please provide any additional information below. - -.gitattributes is: -[[!format sh """ -* annex.largefiles=(not(mimetype=text/*)) -"""]] - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -renn:/tmp/gat$ git init && git annex init --version=6 -Initialized empty Git repository in /tmp/gat/.git/ -init ok -(recording state in git...) -renn:/tmp/gat$ cp ../tga/.gitattributes . -renn:/tmp/gat$ git add .gitattributes -renn:/tmp/gat$ cp ../tga/pkdconvweb.mov . -renn:/tmp/gat$ git add pkdconvweb.mov -error: cannot feed the input to external filter git-annex smudge --clean %f -error: external filter git-annex smudge --clean %f failed - - -# End of transcript or log. -"""]] - -### 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) - -No, I'm a first-time user. Thanks for this neat piece of software. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_1_000d614d4dde9f2d8776155a3f7c94f2._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_1_000d614d4dde9f2d8776155a3f7c94f2._comment deleted file mode 100644 index 50976d1ff..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_1_000d614d4dde9f2d8776155a3f7c94f2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="j_k_234@b2b1aa189bf195cefd815fc0fe70e0ebbe2b8077" - nickname="j_k_234" - subject="comment 1" - date="2016-04-10T13:47:30Z" - content=""" -Tried this on a debian stretch machine and it works fine, so it's to do with the local build on the jessie machine. I tried outtng the binary into `/usr/bin` but that didn't help. -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_2_9e9d4ff9dd5fc083d8a86595912e1191._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_2_9e9d4ff9dd5fc083d8a86595912e1191._comment deleted file mode 100644 index fb6042a89..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_2_9e9d4ff9dd5fc083d8a86595912e1191._comment +++ /dev/null @@ -1,26 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-04-12T17:07:13Z" - content=""" -Since you're trying to use the mimetype feature, have you checked that -your git-annex is built with support for it? Run `git annex version` and -check for "MagicMime" in the build flags. - -Indeed, I'm possitive that's the problem with your build, since the stack -build disables this feature by default. Because it needs libmagic to be -installed, and stack can't install such C libraries and to get a stack -build that works everywhere, it has to be disabled by default. - -So the solution for you is to tell stack to build with the MagicMime build -flag. - -Remaining question is, why is git-annex not displaying an error in this -situation? I tried to replicate it, and it seems to display a nice -error message here: - - joey@darkstar:~/tmp/tt>git add bash - git-annex: bad annex.largefiles configuration: Parse failure: "mimetype" not supported; not built with MagicMime support - error: external filter git-annex smudge --clean %f failed 1 - error: external filter git-annex smudge --clean %f failed -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_bb9c927b758fa64f999d20ac34558c63._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_bb9c927b758fa64f999d20ac34558c63._comment deleted file mode 100644 index 58540a707..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_bb9c927b758fa64f999d20ac34558c63._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="j_k_234@b2b1aa189bf195cefd815fc0fe70e0ebbe2b8077" - nickname="j_k_234" - subject="comment 3" - date="2016-04-13T10:15:03Z" - content=""" -Thanks for the reply. - -I'm pretty sure that I did build with MagicMime support - see the version output on original bug report. - -These are the commands I used to build it: - -```sh - renn:~/git-annex$ git checkout debian/6.20160229-1 - renn:~/git-annex$ sudo aptitude install libmagic-dev - renn:~/git-annex$ stack install --flag git-annex:XMPP --flag git-annex:DBUS --flag git-annex:MagicMime -``` -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_f1c87d7132b0a335a4761098de8afa6d._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_f1c87d7132b0a335a4761098de8afa6d._comment deleted file mode 100644 index a639672b8..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_3_f1c87d7132b0a335a4761098de8afa6d._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-04-13T16:54:01Z" - content=""" -Hmm, so it is enabled. - -So, I guess that the attempt to use the magic database is somehow failing. -Apparently in a way that doesn't cause git-annex to display a useful error -message. - -Can you check what is the behavior if you run: - - git-annex smudge --clean file < file - -That is supposed to output something on stdout, and exit successfuly. -I guess it's probably exiting nonzero, and any output would be helpful to -know. - -It may also be helpful to strace that command. -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment deleted file mode 100644 index c0a9d062d..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_5_44f947f5b1174cf37f4b7f18971d97ca._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="j_k_234@b2b1aa189bf195cefd815fc0fe70e0ebbe2b8077" - nickname="j_k_234" - subject="comment 5" - date="2016-04-21T09:00:49Z" - content=""" -Running the smudge command manually works. Incidentally, just noticed that running the add command a second time seems to work... - -I ran the command under strace -f and all subprocesses seem to exit with RC=0, but I can see the error message being output. Would you like me to send you the strace output (200k gzipped)? -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment deleted file mode 100644 index be806e80f..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_6_237f8b3d8a8d2821a600aae5f5e05bef._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-04-22T20:02:27Z" - content=""" -Sure, email to id@joeyh.name or post a link to the file here. -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_7_dfcc8af09fb7c7658613bd7bb94a7723._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_7_dfcc8af09fb7c7658613bd7bb94a7723._comment deleted file mode 100644 index bf5e62256..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_7_dfcc8af09fb7c7658613bd7bb94a7723._comment +++ /dev/null @@ -1,48 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-05-02T14:19:43Z" - content=""" -Relevant parts of the strace: - - [pid 21392] read(0, <unfinished ...> - [pid 21393] <... futex resumed> ) = 0 - [pid 21392] <... read resumed> "\0\0009\214moov\0\0\0lmvhd\0\0\0\0\300\\\26\256\300\\\26\267\0\0\2X"..., 32752) = 32752 - [pid 21392] write(1, "/annex/objects/SHA256E-s2589913-"..., 102 <unfinished...> - [pid 21389] <... read resumed> "/annex/objects/SHA256E-s2589913-"..., 2589913) = 102 - -21392 is git-annex smudge, and 21389 is apparently a thread belonging to git. -This shows git feeding 32752 bytes of content to git-annex smudge on stdin, and -git-annex smudge responding with the annex object. - -Notice that git-annex calculates the actual file size to be 2589913 bytes, more -than git has sent it at the time it replies. It can tell this because it stats -and hashes the actual file. - - [pid 21392] +++ exited with 0 +++ - [pid 21390] write(9, "ml\3\23<\270\315\321s\322\306\341\301e\261\312[<\2\n\17\315\16a\v\245\215(q\207\314\23"..., 2495705) = -1 EPIPE (Broken pipe) - [pid 21390] --- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=21389, si_uid=2001} --- - [pid 21390] close(9) = 0 - [pid 21390] write(2, "error: cannot feed the input to "..., 76error: cannot feed the input to external filter git-annex smudge --clean %f - -Now git-annex exits, and then git, tries to feed it another 2495705 bytes -of data after it's exited. - -So, it seems that the problem is git-annex is somehow doing a short read of its -stdin, and not waiting for git to feed it the full content. - -And, I see this bug now in the code: - - b <- liftIO $ B.hGetContents stdin - if isJust (parseLinkOrPointer b) - -`parseLinkOrPointer` is careful to *not* look at the whole file content, -so nothing forces the lazy bytestring read to consume all of stdin. -So, if git's writes are broken up as happened in this strace, git-annex -will exit without consuming the whole stdin. - -I've committed a fix along with this comment, so since you're building -from source, and able to reproduce this problem (which I have not -so far been able to reproduce myself) -you should be able to update and rebuild and verify the fix. -"""]] diff --git a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_8_b1f8142039ebf1f55afe80205bc68804._comment b/doc/bugs/git-annex_smudge_fails_on_git_add/comment_8_b1f8142039ebf1f55afe80205bc68804._comment deleted file mode 100644 index ad2d32830..000000000 --- a/doc/bugs/git-annex_smudge_fails_on_git_add/comment_8_b1f8142039ebf1f55afe80205bc68804._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="j_k_234@b2b1aa189bf195cefd815fc0fe70e0ebbe2b8077" - nickname="j_k_234" - subject="comment 8" - date="2016-05-03T07:22:52Z" - content=""" -Thanks very much, that fixes it! - -I did have to use the stack `explicit-setup-deps` tweak to rebuild. -"""]] diff --git a/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__.mdwn b/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__.mdwn deleted file mode 100644 index 55f37663b..000000000 --- a/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__.mdwn +++ /dev/null @@ -1,72 +0,0 @@ -### Please describe the problem. - -When trying to add certain Youtube downloads to my annex, git annex addurl fails with - -[[!format sh """ -$ git annex addurl https://www.youtube.com/watch?v=WZQ4-jXqfSk -git-annex: quvi failed -"""]] - -quvi get https://www.youtube.com/watch?v=WZQ4-jXqfSk on the other hand works just fine, though. - -I have run git annex with --debug and see that the last command executed is - -[[!format sh """ -quvi dump -p enum --verbosity verbose https://www.youtube.com/watch?v=WZQ4-jXqfSk -"""]] - -Looking at its results (and the code), it looks like it parses QUVI_MEDIA_PROPERTY_TITLE. Failures with downloading occur for other URLs which have non-ASCII chars (here: „, “), too, so I assume that's where the bug could be hidden: - -[[!format sh """ -quvi dump -p enum --verbosity verbose https://www.youtube.com/watch?v=WZQ4-jXqfSk -QUVI_MEDIA_PROPERTY_THUMBNAIL_URL=https://i.ytimg.com/vi/WZQ4-jXqfSk/default.jpg -QUVI_MEDIA_PROPERTY_TITLE=Ganze Folge 1533 „Autsch!“ vom 07.06. -QUVI_MEDIA_PROPERTY_ID=WZQ4-jXqfSk -QUVI_MEDIA_PROPERTY_START_TIME_MS=0 -QUVI_MEDIA_PROPERTY_DURATION_MS=1741000 -QUVI_MEDIA_STREAM_PROPERTY_VIDEO_ENCODING=avc1.64001F -QUVI_MEDIA_STREAM_PROPERTY_AUDIO_ENCODING=mp4a.40.2 -QUVI_MEDIA_STREAM_PROPERTY_CONTAINER=mp4 -QUVI_MEDIA_STREAM_PROPERTY_URL=https://r3---sn-j5caxh5n-hpql.googlevideo.com/videoplayback?expire=1446623026&fexp=9407193,9408211,9408710,9414764,9415983,9416126,9417707,9418868,9420718,9421148,9421166,9421292,9422555,9422596,9423343,9423421,9423663,9423793&mime=video/mp4&key=yt6&sparams=dur,id,initcwndbps,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,pcm2cms,pl,ratebypass,requiressl,source,upn,expire&lmt=1433927172625764&dur=1740.776&ratebypass=yes&itag=22&ip=187.253.190.149&sver=3&requiressl=yes&ipbits=0&upn=sO29PXrC-rY&pcm2cms=yes&pl=21&mt=1446601281&mv=m&ms=au&source=youtube&signature=D7D98F6C56BEEC231123BB6E676776BE45E9EE7E.7BF9E36C03D7282B955426734E9019BBC8375A03&initcwndbps=570000&mm=31&mn=sn-j5caxh5n-hpql&id=o-APEamB7usIId7MUeY4uUhLxvqYCet4vB9iVfFj2ZyqNI -QUVI_MEDIA_STREAM_PROPERTY_ID=hd720_mp4_i22_720p -QUVI_MEDIA_STREAM_PROPERTY_VIDEO_BITRATE_KBIT_S=0 -QUVI_MEDIA_STREAM_PROPERTY_AUDIO_BITRATE_KBIT_S=0 -QUVI_MEDIA_STREAM_PROPERTY_VIDEO_HEIGHT=720 -QUVI_MEDIA_STREAM_PROPERTY_VIDEO_WIDTH=1280 -"""]] - -### What steps will reproduce the problem? - -See above. - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -$ git annex version -git-annex version: 5.20150916+gitg79661ef-1~ndall+1 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 -"""]] - -on Linux. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -I love it. It has motivated me enough to start organizing my files spread on different machines, disks etc. at least a little :-) - -> [[fixed|done]]; quvi output is now parsed in a locale-independant manner. -> --[[Joey]] diff --git a/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__/comment_1_2b71126bc2e4f3d1e863a2c0c0181efe._comment b/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__/comment_1_2b71126bc2e4f3d1e863a2c0c0181efe._comment deleted file mode 100644 index d4025e024..000000000 --- a/doc/bugs/git_annex_addurl_fails_on_some_Youtube_URLs___40__possibly_UTF-8_chars_in_title__41__/comment_1_2b71126bc2e4f3d1e863a2c0c0181efe._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-09T15:45:35Z" - content=""" -This works fine when LANG is set to a utf-8 capable locale. I reproduced it -with LANG=C. quvi outputs utf-8 in that configuration, and git-annex, -following the locale settings, did not know what to do with that. - -Easily fixed, but you'll have better luck in general if you get into a -utf-8 capable locale. -"""]] diff --git a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn b/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn deleted file mode 100644 index 8cb93952a..000000000 --- a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -### Please describe the problem. - -Interestingly, on my first attempt I had two files which migrated from MD5 to MD5E backend, but may be I have done some steps differently which provoked also also utils/test/test_data.tar.gz to get to the same destiny (actually later replicated on a fresh clone). -I am also a bit confused why git diff reports change in the symlink if file is already a real file (I guess all the smudging magic) - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -(git)smaug:~exppsy/freesurfer-upstream2[master]git -$> git status -On branch master -Your branch is up-to-date with 'origin/master'. -nothing to commit, working directory clean - -$> git annex adjust --unlock -adjust -Checking out files: 100% (468/468), done. -Switched to branch 'adjusted/master(unlocked)' -ok -git annex adjust --unlock 23.70s user 35.25s system 32% cpu 2:59.41 total -changes on filesystem: - vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +- - -$> git status -On branch adjusted/master(unlocked) -Changes not staged for commit: - (use "git add <file>..." to update what will be committed) - (use "git checkout -- <file>..." to discard changes in working directory) - - modified: vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh - -no changes added to commit (use "git add" and/or "git commit -a") -changes on filesystem: - vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +- - -$> git diff -diff --git a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh -index 9ea90d3..7bc0177 100644 ---- a/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh -+++ b/vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh -@@ -1 +1 @@ --/annex/objects/SHA256-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949 -+/annex/objects/SHA256E-s655672--85f9b50e8fb8a72a8783152c7ad098c0600222256a7244ccd595cbe67b9ea949.mgh -changes on filesystem: - vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh | 2 +- - -$> ls -ld vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh --rw------- 1 yoh yoh 655672 Jun 1 23:28 vtkutils/vtkKWRGBATransferFunctionEditorTester-scalars.mgh - -$> git annex version -git-annex version: 6.20160523+gitg33c00ab-1~ndall+1 - -"""]] - - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_1_7f87080ab44d7ff538e764c4444368e7._comment b/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_1_7f87080ab44d7ff538e764c4444368e7._comment deleted file mode 100644 index bba19d297..000000000 --- a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_1_7f87080ab44d7ff538e764c4444368e7._comment +++ /dev/null @@ -1,41 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-06-09T18:48:45Z" - content=""" -`git annex adjust` preserves the current backend. - -However, when a file in a v6 repository is unlocked, the clean filter will -use whatever backend git-annex is configured to -use by git config annex.backends or annex.backend in .gitattributes. -That defaults to SHA256E. It does not look at the current backend used by -the file. - -So, you can get the same behavior by adding a file using a nonstandard -backend, and then unlocking it. - - joey@darkstar:~/tmp/rr>date > file - joey@darkstar:~/tmp/rr>git annex add file --backend=WORM - add file ok - (recording state in git...) - joey@darkstar:~/tmp/rr>git annex unlock file - unlock file ok - (recording state in git...) - joey@darkstar:~/tmp/rr>git diff file - diff --git a/file b/file - index 94ad1f9..bc7928f 100644 - --- a/file - +++ b/file - @@ -1 +1 @@ - -/annex/objects/WORM-s30-m1465498400--file - +/annex/objects/SHA256E-s30--2917d57a7009b0c2ce14669bf588f6ade6128bc52a8e3bf124d0d30b1fbfdb95 - -To avoid this, the clean filter would need to look at what's checked -into git for the file and reuse the same backend as was used before. - -.. I guess it's ok to do that. It slows the clean filter down slightly, -but the clean filter has to hash the whole file content anyway. And, -it means that when a file gets modified, the same backend that it -was using gets used for the new key. Which is a behavior change, but -one that makes sense. -"""]] diff --git a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_2_e55f1748bb3973ab9acb3313f10e79f5._comment b/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_2_e55f1748bb3973ab9acb3313f10e79f5._comment deleted file mode 100644 index 6638603ed..000000000 --- a/doc/bugs/git_annex_adjust_--unlock_seems_to_cause_migration_of_a_file_to_another_backend/comment_2_e55f1748bb3973ab9acb3313f10e79f5._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-06-09T20:49:53Z" - content=""" -Thanks for the details! Indeed, IMHO it would be nice to preserve backend for a file, since otherwise I am afraid many 'heterogeneous' annex'es where different files were added manually with different backends (intentionally) would start migrating -- might lead to unpleasant surprises. -"""]] diff --git a/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__.mdwn b/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__.mdwn deleted file mode 100644 index 2d60551f2..000000000 --- a/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -### Please describe the problem. - -When the assistant decides to sync the content of a file, it launches rsync. Windows shows an Application Error popup which says this: - - The application was unable to start correctly (0xc000007b). - -Presumably it's crashing. - -### What version of git-annex are you using? On what operating system? - - git-annex version: 5.20151019-gcc50c00 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV DNS Feeds Quvi TDFA TorrentParser Database - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -### 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) - -Not on windows so far :) - -> The page doesn't suggest getting the 32 bit version, it just says to get -> it. Implication should be that's the version that works. I've noted that -> this is an important requirement now. [[done]] --[[Joey]] diff --git a/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__/comment_1_a102f64373ceb142f6a06bde0f97a315._comment b/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__/comment_1_a102f64373ceb142f6a06bde0f97a315._comment deleted file mode 100644 index 3335400b7..000000000 --- a/doc/bugs/git_annex_assistant_cannot_run_rsync___40__windows__41__/comment_1_a102f64373ceb142f6a06bde0f97a315._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="db48x" - subject="oops" - date="2015-10-21T20:11:31Z" - content=""" -After some experimentation, I've discovered that this is because I had installed the 64-bit version of Git for Windows. The install page does suggest getting the 32-bit version, but not why; perhaps it should state that the 64-bit version won't work. -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist.mdwn b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist.mdwn deleted file mode 100644 index 2e2000c61..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -### Please describe the problem. - -git annex direct displays warnings(?) -### What steps will reproduce the problem? - mkdir test - cd test - git init - git annex init - touch foobar.txt - git annex add - git annex direct - - -### What version of git-annex are you using? On what operating system? -5.20140717 (ubuntu 14.10) - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> [[done]]; cannot reproduce with current version of git-annex AFAICS. -> --[[Joey]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_1_b4ad8561eab9b5c3a6eaa2f275aececc._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_1_b4ad8561eab9b5c3a6eaa2f275aececc._comment deleted file mode 100644 index 8e080776c..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_1_b4ad8561eab9b5c3a6eaa2f275aececc._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-01-15T19:00:35Z" - content=""" -That works fine with version 5.20150113. - -Either you need to upgrade to a newer version, or perhaps you left -out some step or configuration needed to reproduce your problem. -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_2_f995b3212c8140b386e4d1785994d29a._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_2_f995b3212c8140b386e4d1785994d29a._comment deleted file mode 100644 index 1e971dd57..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_2_f995b3212c8140b386e4d1785994d29a._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4" - nickname="Andreas" - subject="comment 2" - date="2015-01-19T11:49:32Z" - content=""" -Just double checked and the steps shown expose the error/warning for me. - -Unfortunately, I cannot seem to find a more recent package to check whether the bug has really been fixed meanwhile. -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_3_4c914d08f473490f2077d76664a7d6dd._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_3_4c914d08f473490f2077d76664a7d6dd._comment deleted file mode 100644 index 600115bfe..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_3_4c914d08f473490f2077d76664a7d6dd._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-01-20T17:05:12Z" - content=""" -If you can reproduce the error message, perhaps you can paste it into this -bug report. At the moment, I have absolutely nothing to go on. - -You can download a build of a current version of git-annex from -[[install/Linux_standalone]] for testing. -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_4_3c7a7a0983d3a75a04395141aaf16dbb._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_4_3c7a7a0983d3a75a04395141aaf16dbb._comment deleted file mode 100644 index fb1c5641d..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_4_3c7a7a0983d3a75a04395141aaf16dbb._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4" - nickname="Andreas" - subject="comment 4" - date="2015-01-21T07:30:51Z" - content=""" -This is what I see: - - ➜ ~ mkdir test - ➜ ~ cd test - ➜ test git init - Initialized empty Git repository in /home/deas/test/.git/ - ➜ test git:(master) - ➜ test git:(master) git annex init - init ok - (Recording state in git...) - ➜ test git:(master) touch foobar.txt - ➜ test git:(master) ✗ git annex add - add foobar.txt ok - (Recording state in git...) - ➜ test git:(master) ✗ git annex direct - commit - [master (root-commit) a6e3d83] commit before switching to direct mode - 1 file changed, 1 insertion(+) - create mode 120000 foobar.txt - ok - direct foobar.txt - /home/deas/test/.git/annex/misctmp/tmp6895: rename: does not exist (No such file or directory) - - leaving this file as-is; correct this problem and run git annex fsck on it - direct ok - ➜ test git:(annex/direct/master) -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_5_64000cfe5ef2cdf4260c3342f032e916._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_5_64000cfe5ef2cdf4260c3342f032e916._comment deleted file mode 100644 index 3de74e295..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_5_64000cfe5ef2cdf4260c3342f032e916._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""more info needed""" - date="2015-02-09T17:20:23Z" - content=""" -What version of git-annex was used to get the latest transcript above? - -The sequence of commands you gave works fine for me, no error. - -(Based on the filename in the error message, it seems likely that `replaceFile` -is what's failing (called by `toDirectGen`), but that always creates the misctemp -directory if it doesn't exist. Also, the example given doesn't actually -trigger any code path that calls `replaceFile`. This makes me doubt that -a current version of git-annex is being used..) -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_6_da1b3ee6948afc81273aafe44c7604ba._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_6_da1b3ee6948afc81273aafe44c7604ba._comment deleted file mode 100644 index 2286cb478..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_6_da1b3ee6948afc81273aafe44c7604ba._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4" - nickname="Andreas" - subject="comment 6" - date="2015-02-10T07:38:01Z" - content=""" -5.20140717 (ubuntu 14.10) - -There is no easy way (ready made binary package to download) to get a more recent version, right? - -BTW: I am also seeing issues with 5.20141024-g613f396 on ARM with a glacier remote. Maybe I am asking for too much there. ;) -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_7_4712f638717c68ed3529dd2a078f1746._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_7_4712f638717c68ed3529dd2a078f1746._comment deleted file mode 100644 index 20333d235..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_7_4712f638717c68ed3529dd2a078f1746._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2015-02-10T16:54:54Z" - content=""" -You can download a current build of git-annex from -<http://git-annex.branchable.com/install/Linux_standalone> - -I've already linked to that once before in this very thread! - -I am going to close this bug. Please followup if you anage to a) get a -current git-annex build installed and b) can then provide instructions to -reproduce this bug using it. -"""]] diff --git a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_8_e8890ec39415140d9d9448e5dd67a7ff._comment b/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_8_e8890ec39415140d9d9448e5dd67a7ff._comment deleted file mode 100644 index 7539e9b1f..000000000 --- a/doc/bugs/git_annex_direct_-__62___rename__58___does_not_exist/comment_8_e8890ec39415140d9d9448e5dd67a7ff._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnwNDA50ZupMvOgpgDqzDRyu5B-mYlVwa4" - nickname="Andreas" - subject="comment 8" - date="2015-02-16T17:32:32Z" - content=""" -Sorry, missed the link. The recent version from the tarball fixes the issue for me. -"""]] diff --git a/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn b/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn deleted file mode 100644 index 5440467f1..000000000 --- a/doc/bugs/git_annex_get_fails_from_read-only_repository.mdwn +++ /dev/null @@ -1,48 +0,0 @@ -### Please describe the problem. - -Getting a file from a read-only remote fails with the following error: - -[[!format sh """ -$ git annex get somefile.avi -get somefile.avi (from some.repo...) -git-annex: ../../../home/annex/repo/.git/annex/transfer/upload/9bxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxb4/lck.SHA256E-sxxxxxxx52--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8c.avi: openFd: does not exist (No su -ch file oprotocol version mismatch -- is your shell clean? -(see the rsync man page for an explanation) -rsync error: protocol incompatibility (code 2) at compat.c(176) [Receiver=3.1.1] -r directory) -git-annex-shell: sendkey: 1 failed - - rsync failed -- run git annex again to resume file transfer - - Unable to access these remotes: some.repo - - Try making some of these repositories available: - xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx -- [some.repo] -failed -git-annex: get: 1 failed -"""]] - -### What version of git-annex are you using? On what operating system? - -Locally git-annex 5.20141125 on debian/jessie, remotely 5.20150727 on FreeBSD. - -### Please provide any additional information below. - -Using `ps` I got the command executed on the remote side. Running it directly gives: - -[[!format sh """ -$ git-annex-shell sendkey /home/annex/repo SHA256E-sxxxxxxx52--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8c.avi --uuid 9axxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxde -- remoteuuid=9bxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxb4 direct= associatedfile=somefile.avi -- dummy rsync --server --sender -pe.Lsfx --inplace . . -git-annex: ../../../home/annex/repo/.git/annex/transfer/upload/9bxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxb4/lck.SHA256E-sxxxxxxx52--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx8c.avi: openFd: does not exist (No such file or directory) -failed -git-annex-shell: sendkey: 1 failed -"""]] - -The remote repository is marked as read-only. The user on the remote has only read-only access to the git-annex repository. - -### 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! :-) Despite this, everything works like a charm with several repos on different OSs with lots of data. Thanks for this great tool! - -> [[fixed|done]] --[[Joey]] - -If others are in the same situation as me here, note that you only need to upgrade the server side of things to resolve this. The backports from neurodebian work it, you need something at least 6.201602XX. --[[anarcat]] diff --git a/doc/bugs/git_annex_import__58___ignored_names_fatal.mdwn b/doc/bugs/git_annex_import__58___ignored_names_fatal.mdwn deleted file mode 100644 index 8981cadd8..000000000 --- a/doc/bugs/git_annex_import__58___ignored_names_fatal.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -When I import files that include ignored files, it seems to confuse git-annex (see below). - -This chunk repeats over and over, it looks like import gets stuck until I delete the ignored files. - -Can't the ignored files just be ignored? - -### What steps will reproduce the problem? - -`git annex import ../some-tree-with-ignored-files` - -### What version of git-annex are you using? On what operating system? - - $ git annex version - git-annex version: 5.20140412ubuntu1 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL - remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - - -### Please provide any additional information below. - -[[!format sh """ - - git-annex: user error (xargs ["-0","git","--git-dir=/media/jean/Elements/annex/.git","--work-tree=/media/jean/Elements/annex","add","--"] exited 123) - failed - (Recording state in git...) - The following paths are ignored by one of your .gitignore files: - work/performancemanagement/performancemanagement.zuml1156079052355.tmp - Use -f if you really want to add them. - fatal: no files added - -# End of transcript or log. -"""]] - -> Made git-annex import check for gitignored files before -> moving them into the work tree. [[done]] --[[Joey]] diff --git a/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_1_f7fac12d354408480f48a719331c2d82._comment b/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_1_f7fac12d354408480f48a719331c2d82._comment deleted file mode 100644 index bf27b863d..000000000 --- a/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_1_f7fac12d354408480f48a719331c2d82._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc" - nickname="Jean" - subject="Not only ignored names" - date="2015-03-29T15:24:03Z" - content=""" -During a large import, I observed the above repeatedly, not only on ignored names. When I ctrl-c and restart import, it picks up again apparently without issues. -"""]] diff --git a/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_2_99f575f424ec2f0d739fa7296f0d0086._comment b/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_2_99f575f424ec2f0d739fa7296f0d0086._comment deleted file mode 100644 index 0806cdef0..000000000 --- a/doc/bugs/git_annex_import__58___ignored_names_fatal/comment_2_99f575f424ec2f0d739fa7296f0d0086._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-04-29T17:35:22Z" - content=""" -I cannot reproduce it repeating; the file is actually moved out of the -import location, so importing again won't do anything with it. You can -`git annex add --force` the file to bypass the .gitignore. - -`git annex import --force` also bypasses the problem entirely. -"""]] diff --git a/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string.mdwn b/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string.mdwn deleted file mode 100644 index 5ef39d525..000000000 --- a/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -`git annex info --json --fast 2>/dev/null` returns lines like `(merging origin/synced/git-annex into git-annex...)` befor the actual JSON string if updates where received with eg. `git pull` and `git annex sync` was not run yet. - -I would expect that the additional verbose output is suppressed if the --json switch is used (or maybe send to stderr?). - -However, it's easy to work around by piping the output through `grep -v -E '^\(.*\)$'`. - -I came across this when using `git annex info` to determine the description of the current repo: - -``` -git annex info --json --fast 2>/dev/null | grep -v -E '^\(.*\)$' | jq '."trusted repositories"+."semitrusted repositories"+."untrusted repositories" | [.[] | select(.here == true)] | .[length-1] | .description' | sed 's/^"\(.*\)"$/\1/' -``` - -which is used in some mr scripts that automatically set the repo description after cloning a git annex repo, based on the machine it us run on. - -### What steps will reproduce the problem? - -* clone a repo with git annex branches -* run `git annex info --json --fast 2>/dev/null` - -### What version of git-annex are you using? On what operating system? - -git-annex version: 6.20160511-1~eugenesan~xenial1 - -### Please provide any additional information below. - -[[!format sh """ -$ git annex info --json --fast 2>/dev/null -(merging origin/synced/git-annex into git-annex...) -(recording state in git...) -{"command":"info","repository mode":"indirect","trusted repositories":[],"semitrusted repositories":[...} -"""]] - -### 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) - -I really like git annex and its concepts and I'm currently in the process of adding all my bigger files that don't fit into git repos to git annex repos which are managed on my machines using mr (another great tool!) and some mr scripts that automate working with git annex repos. -So far it works very well and it seems like I finally found a scalable and convenient solution to protect all my files and make them accessible from everywhere. - - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string/comment_1_fa80da021e6a1d1ab5e138199d83f1d2._comment b/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string/comment_1_fa80da021e6a1d1ab5e138199d83f1d2._comment deleted file mode 100644 index 841ce613d..000000000 --- a/doc/bugs/git_annex_info_--json_--fast_outputs_text_in_addition_to_the_json_string/comment_1_fa80da021e6a1d1ab5e138199d83f1d2._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-05T18:44:00Z" - content=""" -Hmm, seems that the output happens before it gets around to parsing the ---json, which will disable such outputs. - -Probably a reversion introduced with the switch to optparse-applicative. -"""]] diff --git a/doc/bugs/git_annex_info_is_reporting_file_as_not_annexed_in_direct_mode.mdwn b/doc/bugs/git_annex_info_is_reporting_file_as_not_annexed_in_direct_mode.mdwn deleted file mode 100644 index d60b760f9..000000000 --- a/doc/bugs/git_annex_info_is_reporting_file_as_not_annexed_in_direct_mode.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -### Please describe the problem. - -I was thinking to answer Emanuele's question in forum (http://git-annex.branchable.com/forum/test_whether_a_file_is_already_annexed/) but realized that 'info' is not the way :-/ (whereis could be used I guess) - -### What version of git-annex are you using? On what operating system? - -5.20150826+gitg87972f5-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -$> git annex indirect -commit ok -indirect 1.dat ok -indirect ok -ok - -$> git annex info 1.dat -file: 1.dat -size: 4 bytes -key: SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat - -$> git annex direct -commit -On branch master -nothing to commit, working directory clean -ok -direct 1.dat ok -direct ok - -$> git annex info 1.dat -git-annex: 1.dat is not a directory or an annexed file or a remote or a uuid - - -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn deleted file mode 100644 index f4339bff7..000000000 --- a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -### Please describe the problem. -The git annex init command is failed. -Following this command the created file content in .git/annex/ssh.config contains these lines - -Include ~/.ssh/config -Include /etc/ssh/ssh_config -ServerAliveInterval 60 - -The two first Include directive seems to be invalid for openssh, then it seems the ssh command is failed and it is analysed as the remote does not git-annex-shell installed. -Commenting these first 2 lines seems to fix the issue and then regular git-annex commands can then be issued. - -### What steps will reproduce the problem? -git annex init - - -### What version of git-annex are you using? On what operating system? -Here is the output of git annex version - -[[!format sh """ -git-annex version: 6.20161031-g0a58e94 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV FsEvents XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 3 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: darwin x86_64 - -"""]] - -It is run on os X el capitan - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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 sure, it's a great software ! -Basically commenting the first 2 lines seems to fix the issue. -I would just like to be sure nothing else is hidden. - - - - -> [[fixed|done]] by adding "IgnoreUnknown Include" -> to the top of `.git/annex/ssh_config`. Thus supporting the old ssh -> version without needing to probe for its version number. -> -> IgnoreUnknown itself was added back in ssh 6.4, in 2013, so -> using git-annex with such an old ssh will still not work, but -> such an old ssh probably has security holes anyway. (Debian oldstable has -> such an old version of ssh, but Debian stable has 6.5.) -> -> I decided not to update existing `.git/annex/ssh_config` -> since a) the user may have edited it and b) it would slow down every call -> git-annex makes to ssh and c) as noted this problem makes git-annex mark -> remotes as annex-ignore, and the user will need to manually edit -> .git/config to remove that in order to recover from the problem, so might -> as well remove `.git/annex/ssh_config` too. -> --[[Joey]] - ->> Fixed more by stopping using `.git/annex/ssh_config` at all. --[[Joey]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_1_89222cd91f529408fd797b087f584b60._comment b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_1_89222cd91f529408fd797b087f584b60._comment deleted file mode 100644 index 888904bbf..000000000 --- a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_1_89222cd91f529408fd797b087f584b60._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-07T14:10:29Z" - content=""" -You forgot to show the error message from `git annex init` or whatever it -was that failed. A second of paste will save hours of guesswork. - -Looking at `man ssh_config` on OSX, it seems ssh 6.9 does not support -the Include directive. - -I guess that the detail you left out is that you ran `git annex init` in a -repository that was cloned from another repository over ssh. That makes it -use ssh to probe the remote, and that probing will fail if ssh is too old -to support Include -"""]] diff --git a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment b/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment deleted file mode 100644 index 42550d51f..000000000 --- a/doc/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/comment_2_32e142afd9fe65843d53883ba2ae48cb._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="scottgorlin@a32946b2aad278883c1690a0753241583a9855b9" - nickname="scottgorlin" - avatar="http://cdn.libravatar.org/avatar/2dd1fc8add62bbf4ffefac081b322563" - subject="IgnoreUnknown Include considered harmful?" - date="2016-11-23T20:07:45Z" - content=""" -As noted, include appears to not work on a mac at the moment. This means git-annex silently ignores the included configs, which may be required to ssh to the remotes of interest. This is happening to me. - -My understanding is that ssh aliases are the recommended way of juggling multiple private keys amongst multiple hosts, so it is a required part of many git workflows. In this particular case, I have set up git annex on a NAS which does not allow multiple ssh users (QNAP) and the authentication is done only via key identity, not username. Thus, host aliases are necessary. - -If one config can't include another, I would prefer an early failure indicating a problem with the config file, or better, a solution where git-annex doesn't require a config. In this scenario, git fetch remote_name and git annex copy --to remotename do not resolve to the same alias definitions (the latter is missing because of the ignored config!). - -I got my setup to work only by finding and manually editing <repo>/.git/annex/ssh_config, which to my knowledge is undocumented (ie when is it written? do any commands change it?); manual mucking around inside .git to me is not a good practice, and for now I have two different alias's defined (in repo and in ~/.ssh/config) - - -"""]] diff --git a/doc/bugs/git_annex_preferred_content_strange_behavior.mdwn b/doc/bugs/git_annex_preferred_content_strange_behavior.mdwn deleted file mode 100644 index 4ee0d5194..000000000 --- a/doc/bugs/git_annex_preferred_content_strange_behavior.mdwn +++ /dev/null @@ -1,53 +0,0 @@ -### Please describe the problem. - -With a version above 5.20141125, git annex wants all remotes to get all files -when one remote wants standard. - -### What steps will reproduce the problem? - -- Create repo "a" and "b" -- Add "b" as a remote of "a" -- Add a file in "a" -- In "a", try git annex copy --to b. Nothing happens: this is the excepted behaviour -- In "a", run git annex wanted here standard -- In "a", try git annex copy --to b. Now, it wants to copy the file to "b" without any obvious (to me) reason - -It may be useful to emphasis the fact that git-annex wanted to copy a file to "b" while we did not change the preferred content of "b". - -I tried with the version 5.20141125 and the problem does not occur. It occurs -though with the versions, 5.20150731-1, 5.20150916-1 and 5.20150930-g40fdbe9. - -### What version of git-annex are you using? On what operating system? - - $ git annex version - git-annex version: 5.20150930-g40fdbe9 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - -### Please provide any additional information below. - -[[!format sh """ -mkdir a -cd a -git init -git annex init -echo a > a -git annex add -git commit -m "first commit" -git clone . ../b -git remote add b file://$(pwd)/../b -git annex sync b -git annex copy --to b --auto # nothing happens, this is normal -git annex wanted here standard -git annex copy --to b --auto # now, it copies the file to b. Why ?? -"""]] - -### 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) - -Definitely! git-annex is a wonderful tool that I have been using every day to manage all my files for 2 years now. Thank you for this excellent software. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_1_2deb194225410b4b5e80b66ab064dd28._comment b/doc/bugs/git_annex_preferred_content_strange_behavior/comment_1_2deb194225410b4b5e80b66ab064dd28._comment deleted file mode 100644 index b773d2a23..000000000 --- a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_1_2deb194225410b4b5e80b66ab064dd28._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-10-06T20:30:39Z" - content=""" -Interesting, I reproduce this. - -I'd actually have expected the first copy to also -succeed; since B has no preferred content set it should want everything by -default. - -I'm guessing that the weirdness of changing the behavior -comes from git-annex switching from the state where there -is no preferred content log to the state where there is one. - -Seems it follows that it's using different defaults when there is -a preferred content log vs when there's not. - -Will need to dig into this. -"""]] diff --git a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_2_1f326f65c70c71f9323393c60228b4e7._comment b/doc/bugs/git_annex_preferred_content_strange_behavior/comment_2_1f326f65c70c71f9323393c60228b4e7._comment deleted file mode 100644 index 858d93557..000000000 --- a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_2_1f326f65c70c71f9323393c60228b4e7._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-10-06T21:01:35Z" - content=""" -On closer thoughtk the behavior with no preferred content set, -of copy --auto not copying anything is actually the desired behavior. -Since --auto also checks numcopies, when no preferred content is set -it should only want to copy files if needed to satisfy numcopies. - -So, the wrong behavior is when it suddently starts copying everything, -indeed. -"""]] diff --git a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_3_51849db15fdd2b79a82f6eba86479134._comment b/doc/bugs/git_annex_preferred_content_strange_behavior/comment_3_51849db15fdd2b79a82f6eba86479134._comment deleted file mode 100644 index 680429841..000000000 --- a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_3_51849db15fdd2b79a82f6eba86479134._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-10-06T21:10:44Z" - content=""" -Intriguingly, debugging shows it's checking the preferred content of -the repo it's in, rather than of the repo it's copying to! - -And indeed, git-annex sync --content doesn't copy the file to B. -So, this bug is in `git-annex copy --to --auto`, and not in preferred -content handling in general. -"""]] diff --git a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_4_6e0f6ec54098f6e8fde80f733dd9c124._comment b/doc/bugs/git_annex_preferred_content_strange_behavior/comment_4_6e0f6ec54098f6e8fde80f733dd9c124._comment deleted file mode 100644 index 78cde3616..000000000 --- a/doc/bugs/git_annex_preferred_content_strange_behavior/comment_4_6e0f6ec54098f6e8fde80f733dd9c124._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-10-06T21:28:43Z" - content=""" -Indeed, the logic got switched to opposite it should during the -optparse-applicative transition. -"""]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn deleted file mode 100644 index e61d44883..000000000 --- a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -### Please describe the problem. -git annex repair fails to repair the repo and reports this error: - - git-annex: /tmp/tmprepo.2/.git/gc.pid: removeLink: does not exist (No such file or directory) - failed - git-annex: repair: 1 failed - - -### What steps will reproduce the problem? - - -### What version of git-annex are you using? On what operating system? -git-annex-5.20140717 on gentoo with use flags: assistant cryptohash dbus desktop-notify dns feed inotify pairing production quvi s3 tahoe tdfa testsuite webapp webapp-secure webdav xmpp - -### Please provide any additional information below. - -[[!format sh """ -~/annex $ git annex repair -Running git fsck ... -Unpacking all pack files. -Unpacking objects: 100% (630/630), done. -Unpacking objects: 100% (630/630), done. -Unpacking objects: 100% (638/638), done. -Initialized empty Git repository in /tmp/tmprepo.2/.git/ -Trying to recover missing objects from remote 192.168.1.246_annex. -Unpacking all pack files. -Unpacking objects: 100% (210608/210608), done. -Trying to recover missing objects from remote 192.168.1.246_annex. -Auto packing the repository in background for optimum performance. -See "git help gc" for manual housekeeping. - -git-annex: /tmp/tmprepo.2/.git/gc.pid: removeLink: does not exist (No such file or directory) -failed -git-annex: repair: 1 failed - - -# End of transcript or log. -"""]] - -> Provisionally [[done]]; see comment. --[[Joey]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment deleted file mode 100644 index cc9f7a9e8..000000000 --- a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_183c3740a108b5f09baf1c401dcfa7f9._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 1" - date="2014-08-15T17:46:15Z" - content=""" -It seems that this has something to do with an auto `git gc` run being trigged somehow during the repair. Puzzlingly, I cannot find any code that would delete the .git/gc.pid file, unless it somehow shows up as a branch ref or something like that. - -Can you run the command with --debug so we can see which particular git command triggered the git gc? -"""]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment deleted file mode 100644 index 6f5570e25..000000000 --- a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_2_b8ee68b445c6a8d27121d90a2eeba0c7._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="jg123h12jh3y12g3y" - ip="86.62.100.131" - subject="Log with --debug" - date="2014-08-20T05:49:02Z" - content=""" -https://mega.co.nz/#!HYZmwSIb!gCd9jvVIyYye_bpsUq_vuEed4g7NTlEl2xDRheE1Lx4 - -This is the log of git annex repair --debug. -"""]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_3_7502f88ae1c46e070e7fdbd9b9c1b54d._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_3_7502f88ae1c46e070e7fdbd9b9c1b54d._comment deleted file mode 100644 index db40450d0..000000000 --- a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_3_7502f88ae1c46e070e7fdbd9b9c1b54d._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.54" - subject="relevant excerpt " - date="2014-10-12T18:08:55Z" - content=""" -<pre> -[2014-08-20 09:05:45 MSK] call: git [\"--git-dir=/tmp/tmprepo.0/.git\",\"--work-tree=/tmp/tmprepo.0\",\"fetch\",\"ssh://crabman@git-annex-192.168.1.246-crabman_annex/~/annex/\",\"--force\",\"--update-head-ok\",\"--quiet\",\"+*:*\"] -Auto packing the repository in background for optimum performance. -See \"git help gc\" for manual housekeeping. -[2014-08-20 09:05:50 MSK] call: rsync [\"-qr\",\"/tmp/tmprepo.0/.git/objects/\",\"/home/crabman/annex/.git/objects/\"] -[2014-08-20 09:14:58 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"584a7836d05e6733224a53e5882547eeb87d43db\"] -[2014-08-20 09:14:59 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"62fee7cc3ec6ea4c56ba42015ab9bf8f0f808dee\"] -[2014-08-20 09:14:59 MSK] read: git [\"--git-dir=/home/crabman/annex/.git\",\"--work-tree=/home/crabman/annex\",\"-c\",\"core.bare=false\",\"show\",\"c7a698397328c71a33bbc2852fda8d09d52c4f38\"] -Running git fsck ... -Trying to recover missing objects from remote 192.168.1.246_annex. -Unpacking all pack files. -Trying to recover missing objects from remote 192.168.1.246_annex. - -git-annex: /tmp/tmprepo.0/.git/gc.pid: removeLink: does not exist (No such file or directory) -</pre> -"""]] diff --git a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_4_9f67b14c9ac81f159439c5dff7354b8f._comment b/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_4_9f67b14c9ac81f159439c5dff7354b8f._comment deleted file mode 100644 index 8d15f5c57..000000000 --- a/doc/bugs/git_annex_repair_fails_-___47__tmp__47__tmprepo.1__47__.git__47__gc.pid__58___removeLink__58___does_not_exist___40__No_such_file_or_directory__41__/comment_4_9f67b14c9ac81f159439c5dff7354b8f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.54" - subject="comment 4" - date="2014-10-12T18:27:39Z" - content=""" -So the auto gc was triggered by git fetch. I have made the repair code prevent that from happening. I expect that will solve the problem, so I am marking this bug as closed. - -However, I don't understand really what could have caused it to try to remove the gc.pid file. I tried creating such a pid file manually after the fetch, and it didn't try to remove it. -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn deleted file mode 100644 index 619e8e5b8..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -### Please describe the problem. - -I plugged in a usb drive, did git annex sync and it git fast-forward and deleted about 600 files that I had added on my laptop. - -### What steps will reproduce the problem? - -Obviously, I'm not sure really because I don't plug this usb drive every day to sync so I don't remember what I did last time. But I suppose I just finished with git annex sync and unplugged it. When the accident occured: - - 1. The usb drive was in direct mode whereas the laptop was in indirect mode at the time. - 2. I git annex sync the usb drive - 3. I git annex sync the laptop - -Anyway, the big mistake I did was syncing the laptop as well, naively thinking it would correct the usb drive; but instead it also deleted the files on the laptop. I had a back up of most of it so it was okay. - ---- - -So now I git reset --hard to a commit before I synced, so I still have my files. But how can I fix this situation? - -### What version of git-annex are you using? On what operating system? - -Arch Linux - -git-annex version: 5.20140128 -build flags: S3 DBus TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web glacier hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> [[closing|done]], not a bug based on the limited description. --[[Joey]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_1_e25451863622eefed664f6a210cbe67d._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_1_e25451863622eefed664f6a210cbe67d._comment deleted file mode 100644 index f0abd4507..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_1_e25451863622eefed664f6a210cbe67d._comment +++ /dev/null @@ -1,72 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawno-jcsScu4CK6k2QLZqxMros1PQHf1NQY" - nickname="Hugo" - subject="Sync messed up" - date="2014-03-09T12:16:32Z" - content=""" -So, I have now reseted to a previous commit all the branches: git-annex, master, synced/git-annex and synced/master in other usb drives. i can git pull and git push, etc. But every time I try a git annex sync, it's deleting files again. - -For instance: - -``````````````` -(merging laptop/git-annex laptop/synced/git-annex into git-annex...) -(Recording state in git...) -commit ok -pull wdrouge -Depuis /run/media/hrd/WD-rouge/annex/hrd - * [nouvelle branche] git-annex -> wdrouge/git-annex - e5894a1..f5af709 master -> wdrouge/master - * [nouvelle branche] synced/git-annex -> wdrouge/synced/git-annex - * [nouvelle branche] synced/master -> wdrouge/synced/master -ok -pull origin -Depuis /home/hrd - + 93d883b...f5af709 git-annex -> origin/git-annex (mise à jour forcée) - e5894a1..f5af709 master -> origin/master - + c8c2481...f5af709 synced/git-annex -> origin/synced/git-annex (mise à jour forcée) - 1d2a028..ac708e3 synced/master -> origin/synced/master - * [nouvelle étiquette] should-be-fine-here -> should-be-fine-here - -Mise à jour f5af709..ac708e3 -Fast-forward - -→ a bunch of files - 621 files changed, 22 insertions(+), 599 deletions(-) - delete mode 120000 → the bunch of files…………… - … - delete mode 120000 org/gtd.org_archive -ok -pull laptop -Depuis /home/hrd - + 93d883b...f5af709 git-annex -> laptop/git-annex (mise à jour forcée) - + c8c2481...f5af709 synced/git-annex -> laptop/synced/git-annex (mise à jour forcée) - 1d2a028..ac708e3 synced/master -> laptop/synced/master - -Already up-to-date. -ok -push wdrouge -Counting objects: 6609, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (3057/3057), done. -Writing objects: 100% (3331/3331), 511.27 KiB | 0 bytes/s, done. -Total 3331 (delta 2091), reused 0 (delta 0) -To /run/media/hrd/WD-rouge/annex/hrd - f5af709..16f17bf git-annex -> synced/git-annex - f5af709..ac708e3 master -> synced/master -ok -push origin -Counting objects: 6569, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (3056/3056), done. -Writing objects: 100% (3330/3330), 511.05 KiB | 0 bytes/s, done. -Total 3330 (delta 2091), reused 0 (delta 0) -To /home/hrd/ - f5af709..16f17bf git-annex -> synced/git-annex -ok -push laptop -Everything up-to-date -ok -git annex sync 14.33s user 1.87s system 74% cpu 21.696 total -`````````````````` - -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_2_f49e6f4016b3a6f918961a2412902e03._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_2_f49e6f4016b3a6f918961a2412902e03._comment deleted file mode 100644 index 277a72b63..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_2_f49e6f4016b3a6f918961a2412902e03._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 2" - date="2014-03-10T17:11:41Z" - content=""" -Your laptop is in indirect mode, so we know that the only way files can be deleted by a merge is if a commit was made to git that deletes the files. - -My conclusion is that some repository, perhaps the usb drive, made a commit that deleted those files. You should be able to find this commit with `git log --stat`, and can just `git revert` it if you want to. - -So far, I don't see evidence of a bug. For all I know, you actually did delete the files on the usb drive, and that change got committed.. -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_3_a234e4f58d2cc3b0110e4e65aceeb2c3._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_3_a234e4f58d2cc3b0110e4e65aceeb2c3._comment deleted file mode 100644 index edf2b26a8..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_3_a234e4f58d2cc3b0110e4e65aceeb2c3._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawno-jcsScu4CK6k2QLZqxMros1PQHf1NQY" - nickname="Hugo" - subject="comment 3" - date="2014-03-13T14:36:20Z" - content=""" -> My conclusion is that some repository, perhaps the usb drive, made a commit that deleted those files. You should be able to find this commit with git log --stat, and can just git revert it if you want to. - -It would be surprising if I did that. - -Anyway, I was not able to find which commit deleted the ~600 files. I just decided to re-start completely with git annex :-/ - -The good thing is that I did not lose any file, so in that regard git annex is great ;^) - -However, one thing that is quite confusing to me is the way git annex [sync] works. Am I supposed to run git annex sync in every repository? Because if I just run it once in 1 repo, then I usually don't get all the syncing done. Maybe I just don't understand something. - -Thanks for replying, - -[sync]: http://git-annex.branchable.com/sync/ -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_4_a01a867500fd94e6b317e74a0b0b1401._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_4_a01a867500fd94e6b317e74a0b0b1401._comment deleted file mode 100644 index 6c519e632..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_4_a01a867500fd94e6b317e74a0b0b1401._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 4" - date="2014-03-13T15:54:28Z" - content=""" -Did you run `git log --stat` and look for a commit that deleted a lot of files? -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_5_b5d7fcd0dd707cd2b62d8b9eb2cae3f0._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_5_b5d7fcd0dd707cd2b62d8b9eb2cae3f0._comment deleted file mode 100644 index bffe9debd..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_5_b5d7fcd0dd707cd2b62d8b9eb2cae3f0._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="edward" - subject="Same problem, git revert worked, sort of" - date="2015-08-13T11:18:42Z" - content=""" -I had a similar problem. I ran `git annex sync` twice, once on the laptop, then on the external drive, lots of git annex symlinks disappeared from the laptop, the symlinks are still present on external drive checkout directory, but git says they were deleted, when I run `git status` it lists them as untracked files. I followed the advice and ran `git log --stat` to find the commit that removed the files. The commit message is \"git-annex in big portable USB drive\". I'm pretty sure that this is a commit from `git annex sync`. - -Running `git revert` worked on the laptop, but it fails external drive, it says \"error: The following untracked working tree files would be overwritten by merge\" and starts listing the missing symlinks. - -Both annex checkouts are set to indirect mode. The laptop preferred content is manual, the external drive is backup. I've run the assistant in the past, but not recently. I'm running Debian git-annex 5.20150727-2. Let me know if you need any more information. -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment deleted file mode 100644 index bed21aedb..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_6_ccfa7150ee87a5ce5bc9189e3a0dcb86._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="edward" - subject="I've ended up with lots of staged deletes" - date="2015-08-27T08:29:55Z" - content=""" -I have the same problem with another annex. I ran the webapp using `git annex webapp` in the annex on my laptop hard drive. It seemed to update and sync with the annex on my external USB drive, but now when I run `git status` in the annex directory on the drive it has staged lots of deletes. I don't understand what is going on here. Both annexes are in indirect mode. - - On branch master - Your branch is behind 'origin/master' by 61 commits, and can be fast-forwarded. - (use \"git pull\" to update your local branch) - Changes to be committed: - (use \"git reset HEAD <file>...\" to unstage) - - deleted: 4angle_tech_ltd/032-570247_20150312-074413_30313.pdf - deleted: 4angle_tech_ltd/032-570247_20150312_09486613.pdf - deleted: android/RUU_PRIMO_U_ICS_40A_HTC_Europe_2.22.401.1_Radio_20.76.30.0835U_3831.19.00.120_release_273801_signed.exe - deleted: article/Fukuyama-End-of-history-article.pdf - deleted: article/The Selling of the Avocado - Health - The Atlantic.html - -The symlinks and the data are still on the disk, as is the data that the symlinks point to. - - $ ls 4angle_tech_ltd -l - total 8 - lrwxrwxrwx 1 edward edward 197 Mar 15 08:39 032-570247_20150312-074413_30313.pdf -> ../.git/annex/objects/qM/mj/SHA256E-s21598--efb39974c5253d8059f0fe991c1b76aba8455d8439eefd6cd8943503f85109c0.pdf/SHA256E-s21598--efb39974c5253d8059f0fe991c1b76aba8455d8439eefd6cd8943503f85109c0.pdf - lrwxrwxrwx 1 edward edward 197 Mar 15 08:39 032-570247_20150312_09486613.pdf -> ../.git/annex/objects/JX/XP/SHA256E-s93692--8e88ca5071bc2155acfe16a41c9c6b756fecc6515cfb7907105dd1a83e73f57a.pdf/SHA256E-s93692--8e88ca5071bc2155acfe16a41c9c6b756fecc6515cfb7907105dd1a83e73f57a.pdf - $ -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_7_4616d3b3d7c5bc0ca76379185bb34d10._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_7_4616d3b3d7c5bc0ca76379185bb34d10._comment deleted file mode 100644 index e6d6ace9d..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_7_4616d3b3d7c5bc0ca76379185bb34d10._comment +++ /dev/null @@ -1,50 +0,0 @@ -[[!comment format=mdwn - username="yminus" - subject="comment 7" - date="2015-12-10T22:25:26Z" - content=""" -I have the same problem as the initial reporter. - -USB drive is FAT32 in direct mode - -laptop is ext4 in indirect mode - -nas is ext4 in indirect mode - -Syncing nas with laptop and vice versa works with no problems. - -But as soon as I sync with USB drive it behaves like all commits on laptop and nas that happened since the last sync are reverted. - -I can recover the files on laptop and nas by ```git reset --hard origin/master``` and ```git reset --hard origin/synced/master``` on laptop or nas. - -However, I cannot reset master and synced/master on the USB drive (error is \"fatal: This operation must be run in a work tree\"). - -This is the tree as seen from the on laptop after syncing and resetting as described above: - - * 9bdc037 (n900/synced/master, n900/master) merge refs/heads/synced/master ### <--- THIS IS THE STATE WHEN SYNCING WITH USB DRIVE all added files are deleted - |\ - | * 1236008 (HEAD -> master, origin/synced/master, origin/master, nas/synced/master, nas/master, synced/master) ADDED FILES ### <--- THIS IS THE LAST GOOD STATE - | * 17c4f54 ADDED FILES - | * 364d525 Merge remote-tracking branch 'refs/remotes/origin/master' - | |\ - | | * c18f170 ADDED FILES - | | * 9dd5668 ADDED FILES - | * | c3280fc ADDED FILES - | * | 2babe80 ADDED FILES - | * | b964e29 ADDED FILES - | * | 03f3bd1 ADDED FILES - | * | 010a469 ADDED FILES - | * | 8acf199 ADDED FILES - | * | f2477bc Merge remote-tracking branch 'refs/remotes/origin/master' - | |\ \ - | | |/ - | | * 121ffd1 ADDED FILES - * | | dc88b8a (n900/annex/direct/master) git-annex in lars@lars-laptop:/run/media/lars/Nokia N900/.sounds/Musik ### <--- THIS IS THE CURRENT STATE ON THE USB DRIVE - |/ / - * - -n900 is the USB drive -nas and origin are both the same - -How can I sync my USB drive without loosing my last commits? -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_8_7b89c224ab6f79d406785fe751c241b6._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_8_7b89c224ab6f79d406785fe751c241b6._comment deleted file mode 100644 index 943b9718e..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_8_7b89c224ab6f79d406785fe751c241b6._comment +++ /dev/null @@ -1,77 +0,0 @@ -[[!comment format=mdwn - username="yminus" - subject="comment 8" - date="2015-12-13T22:55:15Z" - content=""" -I think the problem in my case is that I had special characters in some file names which fat does not support. - -I tried to recover the git annex repo in direct mode using these steps: -<pre> -git push --force n900 master -git checkout synced/master -git push --force n900 synced/master -git checkout master -git annex unlock flac/Type_O_Negative/2003_Life_Is_Killing_Me/ -mv flac/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero_\(\<0\).flac flac/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero.flac -git annex add flac/ -git commit -m \"Work around broken file systems\" -git push --force n900 master -git checkout synced/master -git push --force n900 synced/master -git checkout master -git annex sync n900 -</pre> - -But now the last git annex sync creates a merge commit which only contains \"variants\" of the renamed files: - -<pre> - Merge remote-tracking branch 'refs/remotes/origin/synced/master' into annex/direct/master - - # Conflicts: - # flac/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero.flac - # mp3/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero.mp3 - - flac/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero.variant-6467.flac -index 0000000,c33ca87..c33ca87 -mode 000000,120000..120000 - - mp3/Type_O_Negative/2003_Life_Is_Killing_Me/03.Less_Than_Zero.variant-562b.mp3 -index 0000000,a247fc6..a247fc6 -mode 000000,120000..120000 -</pre> - -So the repo on n900 still does not contain all the files added since the last sync (git annex get fails for those files). At least now the sync does not delete files in my laptop repo any more. - -This is the current state: - -<pre> -* 44dd9a8 (n900/annex/direct/master) Merge remote-tracking branch 'refs/remotes/origin/synced/master' into annex/direct/master -|\ -| * 21df034 (HEAD -> master, tag: before_syncing_n900, nas/synced/master, n900/synced/master, n900/master, synced/master) Merge remote-tracking branch 'refs/remotes/nas/master' -| |\ -| | * 4f61c44 (nas/master) Work around broken file systems -| | * 85ab30f ADDED FILES -| * | 92bc06e Work around broken file systmes (mp3) -| |/ -* | a945a24 merge refs/heads/synced/master -|\ \ -| |/ -| * 1236008 (origin/synced/master, origin/master) ADDED FILES -| * 17c4f54 ADDED FILES -| * 364d525 Merge remote-tracking branch 'refs/remotes/origin/master' -| |\ -| | * c18f170 ADDED FILES -| | * 9dd5668 ADDED FILES -| * | c3280fc ADDED FILES -| * | 2babe80 ADDED FILES -| * | b964e29 ADDED FILES -| * | 03f3bd1 ADDED FILES -| * | 010a469 ADDED FILES -| * | 8acf199 ADDED FILES -| * | f2477bc Merge remote-tracking branch 'refs/remotes/origin/master' -| |\ \ -| | |/ -| | * 121ffd1 ADDED FILES -* | | dc88b8a git-annex in lars@lars-laptop:/run/media/lars/Nokia N900/.sounds/Musik -</pre> -"""]] diff --git a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_9_6328cbc42f5938a766ff5adda3da03b7._comment b/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_9_6328cbc42f5938a766ff5adda3da03b7._comment deleted file mode 100644 index e301c63b6..000000000 --- a/doc/bugs/git_annex_sync_deleted_a_bunch_of_files___40__not_expected__41__/comment_9_6328cbc42f5938a766ff5adda3da03b7._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="spwhitton" - subject="comment 9" - date="2016-05-02T19:26:47Z" - content=""" -I appreciate that Joey has closed this as insufficiently detailed, and I'm not able to reliably reproduce the issue either, but I have experienced a similar issue today where a sync wants to delete all of the files in my repository and I have no reason to believe that I actually deleted them all. The common factor here is that we're all trying to sync to FAT devices. Git is very slow on FAT flash drives, and perhaps at some point it thinks the files aren't there during a sync. I'm going to stop using git annex with FAT flash drives. -"""]] diff --git a/doc/bugs/git_annex_vicfg_fail_with_Buffer__58___invalid_argument___40__invalid_character__41__.mdwn b/doc/bugs/git_annex_vicfg_fail_with_Buffer__58___invalid_argument___40__invalid_character__41__.mdwn deleted file mode 100644 index b74528bda..000000000 --- a/doc/bugs/git_annex_vicfg_fail_with_Buffer__58___invalid_argument___40__invalid_character__41__.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### Please describe the problem. -On one repos, I cannot run vicfg because git annex complain that - - git-annex: /home/moi/Bibliothèque calibre/.git/annex/config.tmp: commitBuffer: invalid argument (invalid character) failed - git-annex: vicfg: 1 failed - -Note that the assistant and the webapp seem to be working as it should, giving me the possibility to make most of the configuration I want. - -The problem does exit on all the clone of the repos. - - -### What steps will reproduce the problem? - -I don't know if the "è" in the directory name is linked to this. It seem -also that the description of one of the repository has been incorrect -(something like "toubib: ~/Biblioth⯁⯁⯁que calibre/" where the three ⯁ -replace one incorrectly encoded char that was, since then, changed. - - -### What version of git-annex are you using? On what operating system? -I'm using the more uptodate version that are in Debian sid: - - $ git --version - git version 2.1.4 - $ git annex version - git-annex version: 5.20141125 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL - remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external - local repository version: 5 - supported repository version: 5 - upgrade supported from repository versions: 0 1 2 4 - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server.mdwn b/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server.mdwn deleted file mode 100644 index f40fabd74..000000000 --- a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. - -webapp needs to be killed and restarted to finish setting up a new repository - -### What steps will reproduce the problem? - -I run on a remote linux server - -git annex webapp --listen=10.222.0.1:4000 - -I get a url printed - -click the url, it opens in my browser -click make a repository, and it doesn't finish loading the web page -if I ctrl-c git on the remote server and start it up again, click -the url again, i can continue to set up the new repository - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 4.20130709 -build flags: Assistant Webapp Pairing Testsuite S3 WebDAV Inotify DBus XMPP - -debian wheezy with git-annex pinned from sid - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -[2013-07-19 08:09:54 EST] main: starting assistant version 4.20130709 -WebApp crashed: unable to bind to local socket -[2013-07-19 08:09:54 EST] WebApp: warning WebApp crashed: unable to bind to local socket - - dbus failed; falling back to mtab polling (ClientError {clientErrorMessage = "runClient: unable to determine DBUS address", clientErrorFatal = True}) - - No known network monitor available through dbus; falling back to polling -(scanning...) [2013-07-19 08:09:54 EST] Watcher: Performing startup scan -(started...) Merge made by the 'recursive' strategy. - ...book.azw | 1 + - 1 file changed, 1 insertion(+) - create mode 120000 Books/book.azw -[2013-07-19 08:13:03 EST] Committer: Committing changes to git - - -# End of transcript or log. -"""]] - -> Duplicate; [[closed|done]]. --[[Joey]] diff --git a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_1_db99c00830d3f15ebe790c4dc8b60bd7._comment b/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_1_db99c00830d3f15ebe790c4dc8b60bd7._comment deleted file mode 100644 index 11c4c181b..000000000 --- a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_1_db99c00830d3f15ebe790c4dc8b60bd7._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.140" - subject="comment 1" - date="2013-07-20T19:57:05Z" - content=""" -This is a known problem with using --listen with a forced port number. See [[Hangs_on_creating_repository_when_using_--listen]] -"""]] diff --git a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_2_1b407b4368cd05150563a3f09d43cada._comment b/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_2_1b407b4368cd05150563a3f09d43cada._comment deleted file mode 100644 index 0acd56806..000000000 --- a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_2_1b407b4368cd05150563a3f09d43cada._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="git-annex.branchable.com@69b3f2da2837a3d9de8eab0b93771008294b7d69" - nickname="git-annex.branchable.com" - subject="comment 2" - date="2016-01-10T12:06:52Z" - content=""" -Has this issue been fixed, if so when? There's no reference to the bug and am running into something which could be the same thing. -"""]] diff --git a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_3_2fd8f144db99b0f9978cf8d463df382b._comment b/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_3_2fd8f144db99b0f9978cf8d463df382b._comment deleted file mode 100644 index 03942b382..000000000 --- a/doc/bugs/git_annex_webapp_--listen_on_a_remote_linux_server/comment_3_2fd8f144db99b0f9978cf8d463df382b._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-01-11T16:19:45Z" - content=""" -This is a closed bug from 2013. - -IIRC, the issue was that specifying a port couldn't work as the webapp -needs to use two different ports in the repository creation process. Since ---listen has been changed to not allow a port to be specified, this bug is -no longer relevant. -"""]] diff --git a/doc/bugs/git_security_fix.mdwn b/doc/bugs/git_security_fix.mdwn deleted file mode 100644 index 43b3f505f..000000000 --- a/doc/bugs/git_security_fix.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -git had some remotely exploitable security holes announced recently -(CVE-2016-2324, CVE-2016-2315) - -git-annex builds that bundle git need to be updated. - -status of autobuilds: - -* Linux is fixed (all builds) -* OSX is fixed -* Windows does not bundle git -* Android is fixed (git build is untested) - -status of released builds: - -* Linux is fixed (all builds) -* OSX is fixed (yosemite only; old builds vulnerable so removed) -* Windows does not bundle git -* Android is fixed (git build is untested) - -[[done]] --[[Joey]] diff --git a/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error.mdwn b/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error.mdwn deleted file mode 100644 index cf779ab3d..000000000 --- a/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!meta title="git annex uninit causes SqlLite3 error"]] - -### Please describe the problem. -I am basically having issues with `git annex uninit` - -### What steps will reproduce the problem? - $ git init localrepo - Initialized empty Git repository in /Users/w/work/temp/test/localrepo/.git/ - $ cd localrepo - $ git annex init - init ok - (recording state in git...) - $ git annex uninit - fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree. - Use '--' to separate paths from revisions, like this: - 'git <command> [<revision>...] -- [<file>...]' - Deleted branch git-annex (was 98f3795). -********************* -Now if I add a local file I get a different error - - $ git init localrepo - Initialized empty Git repository in /Users/w/work/temp/test/localrepo/.git/ - $ cd localrepo - $ git annex init - init ok - (recording state in git...) - $ date > secret_file - $ git annex add secret_file - add secret_file ok - (recording state in git...) - $ git commit -am "added" - [master (root-commit) a2e1882] added - 1 file changed, 1 insertion(+) - create mode 120000 secret_file - $ git annex sync - commit - On branch master - nothing to commit, working directory clean - ok - $ git annex uninit - unannex secret_file ok - Deleted branch git-annex (was 6a727da). - git-annex: failed to commit changes to sqlite database: Just SQLite3 returned ErrorCan'tOpen while attempting to perform open ".git/annex/keys/db". - CallStack (from HasCallStack): - error, called at ./Database/Handle.hs:111:26 in main:Database.Handle - - -### What version of git-annex are you using? On what operating system? - - $ brew info git-annex - git-annex: stable 6.20160527 (bottled), HEAD - Manage files with git without checking in file contents - https://git-annex.branchable.com/ - /usr/local/Cellar/git-annex/6.20160527 (104 files, 87.0M) * - Poured from bottle on 2016-06-06 at 15:36:47 - From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/git-annex.rb - ==> Dependencies - Build: ghc ✘, cabal-install ✘, pkg-config ✔ - Required: gsasl ✔, libidn ✔, libmagic ✔, gnutls ✘, quvi ✔ - ==> Options - --with-git-union-merge - Build the git-union-merge tool - --HEAD - Install HEAD version - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -I am super excited about what I can do with git-annex. I hope to setup and maintain encrypted repo(s) of some of my files, and access them by cloning a local copy of the encrypted repo and getting the files I want, using them, and then deleting the local copy. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error/comment_1_be3aaa58fd3adfa5eeb893c205aa871c._comment b/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error/comment_1_be3aaa58fd3adfa5eeb893c205aa871c._comment deleted file mode 100644 index fed1699ac..000000000 --- a/doc/bugs/git_uninit_on_OS_X_causes_SqlLite3_error/comment_1_be3aaa58fd3adfa5eeb893c205aa871c._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-12T17:48:50Z" - content=""" -Not OSX specific; reproduced on Linux. - -Instrumentation shows that removeInodeCaches is being called, when it -unannexes the annexed file. This is why a file has to have been added to -the repo to get the crash. - -It's actually not necessary for removeInodeCaches to be called in a v5 -repo, only in v6. If the code checked for v6 mode before writing to the -database, such problems would be avoided except for in v6 mode. - -But, the actual fix is to make uninit close this and all other sqlite -db's before deleting the .git/annex directory. -"""]] diff --git a/doc/bugs/gitlab_configuration_out_of_date.mdwn b/doc/bugs/gitlab_configuration_out_of_date.mdwn deleted file mode 100644 index 7fb02b5b7..000000000 --- a/doc/bugs/gitlab_configuration_out_of_date.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -### Please describe the problem. -The webapp configuration for enabling a new gitlab remote is out of date and no longer functions. - -### What steps will reproduce the problem? -Attempt to use the webapp to create a new gitlab remote. -- The url linked to add a public key is invalid -- Pressing the confirmation button reloads the same page. The remote is never enabled. - -### What version of git-annex are you using? On what operating system? -6.20160229-g37a89cc on linux x86 fedora 18 - -### Please provide any additional information below. - -### 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) - -Git-annex is a miracle to find. I intend to stick with it, migrate my life to it, and perhaps learn haskell some day to contribute. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/gitlab_configuration_out_of_date/comment_1_39c4a952e79fc711700bd5eff8fb9c13._comment b/doc/bugs/gitlab_configuration_out_of_date/comment_1_39c4a952e79fc711700bd5eff8fb9c13._comment deleted file mode 100644 index f64b5da91..000000000 --- a/doc/bugs/gitlab_configuration_out_of_date/comment_1_39c4a952e79fc711700bd5eff8fb9c13._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-13T18:47:57Z" - content=""" -Seems the url has changed to https://gitlab.com/profile/keys - -Using this new url to add a key, I was able to successfully add a gitlab -repository. -"""]] diff --git a/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn b/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn deleted file mode 100644 index 16acb005e..000000000 --- a/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -### Please describe the problem. - -When using `--incremental` together with `git annex fsck`, the error -message "hPutChar: invalid argument (invalid character)" appears in the -"Only X of Y trustworthy copies exist" message when the filename -contains an UTF-8 character above U+007F. The only locale in which this -doesn't happen is "C.UTF-8". - -### What steps will reproduce the problem? - -- Create and add a file with an UTF-8 character in the file name above U+007F to git-annex -- Set `numcopies` high enough so `git annex fsck` will produce a warning about missing copies -- Execute `git annex fsck --incremental` - -I've created two test scripts on -<https://gist.github.com/sunny256/ebf4d055f5500b257ed8> that demonstrate -this error: - -- `git clone https://gist.github.com/ebf4d055f5500b257ed8.git` -- `cd ebf4d055f5500b257ed8` -- `./runme` - -You can specify a locale to `runme` as `$1` to experiment with different -locales. - -There's also a `test-all-locales` script that executes `./runme` with -all defined locales on the computer. Both scripts return 1 if the error -message appears, if it's gone, 0 is returned. - -### What version of git-annex are you using? On what operating system? - -Newest git-annex amd64 (5.20150812) from `downloads.kitenet.net`. - -### Please provide any additional information below. - -The `runme` script contains more information about this issue. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -Here are two excerpts of the test output using the "C" and -"C.UTF-8" locale: - -$ ./runme C -[snip] -================== git annex --incremental fsck ================== -fsck U00D8_Ø.txt (checksum...) - - Only 1 of 2 trustworthy copies exist of U00D8_ -git-annex: <stderr>: hPutChar: invalid argument (invalid character) -failed -fsck ascii_only.txt (checksum...) - - Only 1 of 2 trustworthy copies exist of ascii_only.txt - Back it up with git-annex copy. -failed -(recording state in git...) -git-annex: fsck: 2 failed - -$ ./runme C.UTF-8 -[snip] -================== git annex --incremental fsck ================== -fsck U00D8_Ø.txt (checksum...) - - Only 1 of 2 trustworthy copies exist of U00D8_Ø.txt - Back it up with git-annex copy. -failed -fsck ascii_only.txt (checksum...) - - Only 1 of 2 trustworthy copies exist of ascii_only.txt - Back it up with git-annex copy. -failed -(recording state in git...) -git-annex: fsck: 2 failed - -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames/comment_1_bb9cd3e753431b1f5dd8b94a1be4e4a3._comment b/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames/comment_1_bb9cd3e753431b1f5dd8b94a1be4e4a3._comment deleted file mode 100644 index 373c1e4e7..000000000 --- a/doc/bugs/hPutChar_error_message_with_UTF-8_chars_above_7F_in_filenames/comment_1_bb9cd3e753431b1f5dd8b94a1be4e4a3._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T20:14:01Z" - content=""" -It only fails with --incremental, and the only difference -is that the fsck database is opened and written that way. - -Somehow, opening the database causes the encoding of the stderr handle to get -reset from the fileEncoding git-annex normally applies at startup to -the defaut, which crashes on filenames that don't use the locale's -encoding. - -What a strange side effect especially to find in haskell code! -It's some kind of bug in persistent that this happens. -I've filed a bug: <https://github.com/yesodweb/persistent/issues/474> - -I put in a workaround; I have it reset the encoding of the file handles -after opening the db. -"""]] diff --git a/doc/bugs/hash_changed.mdwn b/doc/bugs/hash_changed.mdwn deleted file mode 100644 index 44f2d2eba..000000000 --- a/doc/bugs/hash_changed.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -### Please describe the problem. - -I ran `git annex fsck` on some files, and the fsck reported that hashes were incorrect and the files were moved. - -### What steps will reproduce the problem? - -I don't know. - -### What version of git-annex are you using? On what operating system? - -``` -git-annex version: 6.20160229 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -``` - -on NixOS linux 64 bit - unstable channel - -### Please provide any additional information below. - -The problem was on several disks, different manufacturer, different disk size, etc. The fsck always transformed hashA -> hashB, so the hashes were equal before and after the fsck run on all disks, though the link to the "old" file was not fixed to point to the "new" file. - -### 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) - -I use annex for years now, never had a problem with it. It is one of the most awesome pieces of software I've seen in the last 10 years, though I only use a really small part of it. Sometimes it bugs me a little that it consumes quite a lot of memory on large repositories, though most of the time this is not an issue for me. - -> I think this was not a bug in hashing, just a corrupted file that -> spread to several repositories. More recent git-annex versions checksum -> files after transfer so detect the problem. -> -> Since it was resolved to reporter's satisfaction, [[done]] --[[Joey]] diff --git a/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment b/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment deleted file mode 100644 index 87cbdedfc..000000000 --- a/doc/bugs/hash_changed/comment_1_7ec190a665b50eefadff59949a576bbb._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="mail@f1d77c48f528d8c7b885900281887e045ad5114e" - nickname="mail" - subject="Solution" - date="2016-03-09T16:03:35Z" - content=""" -The solution proposed by \"joeyh\" on irc was to remove the symlink (`git rm` it) and then move the actual file from .git/annex/bad back to the file and `git annex add` it again. - -Worked beautifully. -"""]] diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn deleted file mode 100644 index 74a3c6c22..000000000 --- a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -### Please describe the problem. - -`git-annex importfeed` fails to import some feed with the error `createSymbolicLink: invalid argument (File name too long)` in a case in which `ln -s` works. The item of the feed is not added, and the importing aborts at this entry. - -This is a regression: some entries that trigger the problem where imported just fine three months ago. - -This looks suspiciously like [this bug](../20151116_tests_fail_on_OS_X). - - -### What steps will reproduce the problem? - -In a freshly `git init`-ed and `git-annex init`-ed repo: - -[[!format sh """ -$ git-annex importfeed --relaxed http://www.rtve.es/api/programas/1938/audios.rss -(checking known urls...) importfeed http://www.rtve.es/api/programas/1938/audios.rss -/tmp/feed1907 100%[================================================================>] 91,96K 31,4KB/s en 2,9s -addurl Documentos_RNE/Documentos_RNE___La_guerra__un_recorrido_por_la_historia_de_la_peor_lacra_de_la_Humanidad___05_1215.mp3 ok -addurl Documentos_RNE/Documentos_RNE___El_proceso_de_Burgos._El_juicio_contra_ETA_que_arrinconó_al_Franquismo___28_11_15.mp3 ok -addurl Documentos_RNE/Documentos_RNE___Carmen_Martín_Gaite__la_escritura__como_afición_y_refugio___21_11_15.mp3 ok -addurl Documentos_RNE/Documentos_RNE___El_crimen_del_Expreso_de_Andalucía___14_11_15.mp3 ok -addurl Documentos_RNE/Documentos_RNE___La_Belle_Époque._La_Europa_que_bailaba_al_borde_del_abismo___07_11_15.mp3 ok -addurl Documentos_RNE/Documentos_RNE___Cruz_Roja_Española._Siglo_y_medio_de_labor_humanitaria__de_los_heridos_de_guerra_a_los_excluidos_de_la_crisis___31_10_15.mp3 -git-annex: ../.git/annex/objects/F7/x3/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42: createSymbolicLink: invalid argument (File name too long) -failed -(recording state in git...) -git-annex: importfeed: 1 failed -"""]] - -Just to make sure, I checked that the link can be created: - -[[!format sh """ -$ ln -s '../.git/annex/objects/F7/x3/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42/URL--http&c%%mvod.lvlt.rtve.es%resour-cb7157debded21ea4ab1c330aaa54b42' Documentos_RNE/Documentos_RNE___Cruz_Roja_Española._Siglo_y_medio_de_labor_humanitaria__de_los_heridos_de_guerra_a_los_excluidos_de_la_crisis___31_10_15.mp3 -"""]] - -I also checked in ghci that System.Posix.Files.createSymbolicLink succeeds in creating the same link. -(But I didn’t compile git-annex myself, so I’m not sure that the version of the lib used in the debian package is the same as the one I checked; and I’m not sure whether git-annex uses exactly that function or another with the same name, by the way). - - -### What version of git-annex are you using? On what operating system? - -Debian amd64 unstable package 5.20151116-1. -(I also tried version i386, with the same result). - - -### 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) - -That’s just a little hiccup in, up to now, various months of merry use! ;-) - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment b/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment deleted file mode 100644 index b60e0f308..000000000 --- a/doc/bugs/importfeed_fails_on_createSymbolicLink___40__but_ln_-s_works__41__/comment_1_c831256a081b181a121910aca3151e45._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-12-06T19:50:59Z" - content=""" -I can reproduce this. - - symlink("../.git/annex/objects/fK/9M/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4/URL--http&c%%mvod.lvlt.rtve.es%resour-39e58395b01e2385d46bade56127cfc4", ".git/annex/misctmp/Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3.0Documentos_RNE___Coss\303\255o_y_la_Casona_de_Tudanca__refugio_de_la_cultura_espa\303\261ola_entre_las_monta\303\261as_de_Cantabria___28_08_15.mp3") = -1 ENAMETOOLONG (File name too long) - -The problem is not the length of the link target, which is only 170 -characters and will work on any OS. The basename of the symlink -being created is pretty long, 294 characters, and that's the -cause of the failure. - - joey@darkstar:~>ln -s /dev/null $(perl -e 'print ("a" x 294)') - ln: failed to create symbolic link ‘aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’ -> ‘/dev/null’: File name too long - -The limit is 255 characters in a single path component (`pathconf _PC_NAME_MAX`). - -So, the issue is caused by the rss feed having a long title for this -item. - -And this used to work; it's a recent reversion. Fixing. -"""]] diff --git a/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn b/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn deleted file mode 100644 index 6601e9ba5..000000000 --- a/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -### Please describe the problem. - -if using addurl in --batch mode, there is no --json formatting and text output is somewhat inconsistent. It might include "downloading ..." with 'ok' on a separate line, possibly with a msg on recording state in git, or within the same line report 'ok', or 'failed' in upcoming lines. This complicates parsing of such output to verify correct operation for a given addurl pair - -[[!format sh """ - -$> echo 'http://127.0.0.1:33369/about.txt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null -addurl about.txt (downloading http://127.0.0.1:33369/about.txt ...) -ok -(recording state in git...) - -$> echo 'http://127.0.0.1:33369/about.txt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null -addurl about.txt ok - -$> echo 'http://127.0.0.1:33369/about.stxt about.txt' | git -c receive.autogc=false annex addurl --with-files --batch --debug 2>/dev/null -addurl about.txt -failed - -"""]] - -[[!meta author=yoh]] - -> I've made --json work for addurl; I feel that's the way to go for parsing -> its output. [[done]] --[[Joey]] diff --git a/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output/comment_1_2d51b295dcb51fd6efdfd364255b15e6._comment b/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output/comment_1_2d51b295dcb51fd6efdfd364255b15e6._comment deleted file mode 100644 index 98aa8067f..000000000 --- a/doc/bugs/inconsistent_output_upon_addurl_--batch_complicates_if_not_forbids_reliable_parsing_of_output/comment_1_2d51b295dcb51fd6efdfd364255b15e6._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="new effect in list of "fixed" behavior to fail addurl if non-annex file exists" - date="2016-01-15T04:45:07Z" - content=""" -[[format sh \"\"\" -$> echo \"http://www.onerussian.com/tmp/banner.png 123\" | git annex addurl --batch --with-files 2>/dev/null -addurl 123 % -\"\"\"]] - -so no indication of addurl failing for that existing (123) file. Should at least say \"failed\" I guess -"""]] diff --git a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn b/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn deleted file mode 100644 index b84ab32e6..000000000 --- a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### What version of git-annex are you using? On what operating system? - -5.20151116+gitg5416a1a-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - "backend usage": [ - [ - "MD5E", - 2 - ], - [ - "SHA256E", - 2 - ] - ], -"""]] - -instead of more logical - -[[!format sh """ - - "backend usage": { - "MD5E": 2, - "SHA256E": 2 - } -"""]] - -also it seems it just doubles them since I have only 2 files, 1 for each backend (as reported also by info "local annex keys": 2). - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_1_5db5f19d9bdc81839d984b7e302e49ed._comment b/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_1_5db5f19d9bdc81839d984b7e302e49ed._comment deleted file mode 100644 index 81a999e20..000000000 --- a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_1_5db5f19d9bdc81839d984b7e302e49ed._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-01T20:27:27Z" - content=""" -It was indeed a bug that it counted both keys referenced in the work tree -and keys whose content was present. Fixed. - -It's not hard to fix the json format, but then what happens to anything -that may be parsing the existing format? I could use a different field -for the better formatted version and keep the old version in the current -field, but if the goal is to make the json better, that doesn't really -work. - -Since the old output is so funky, it seems likely to me you're the first -one to try to consume it since anyone reasonable would file a but report -about it and you're the first who did. - -So.. I guess I'll change the json format and see if anyone complains. - -I have to say that this business of not having any specification other -than what it currently is, is what annoys me about JSON as a consumer of it. -"""]] diff --git a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_2_79d19463006920af16d067421f417ab5._comment b/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_2_79d19463006920af16d067421f417ab5._comment deleted file mode 100644 index 4e78144c6..000000000 --- a/doc/bugs/info_--json_lists_backend_usage_stats_as_a_list_of_lists/comment_2_79d19463006920af16d067421f417ab5._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-01-02T01:57:45Z" - content=""" -well -- it is possible to define schemas for json and validate conformance to them... saw in slybot using https://github.com/Julian/jsonschema for that (if of any help). -May be worth adding \"git annex schema version\" information within the output? -"""]] diff --git a/doc/bugs/internal_server_error__58___hGetContents__58___invalid_argument___40__invalid_byte_sequence__41__.mdwn b/doc/bugs/internal_server_error__58___hGetContents__58___invalid_argument___40__invalid_byte_sequence__41__.mdwn deleted file mode 100644 index 8c9703ed2..000000000 --- a/doc/bugs/internal_server_error__58___hGetContents__58___invalid_argument___40__invalid_byte_sequence__41__.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -Some logs fail to be displayed, and instead of displaying parts of the log, no logs at all are displayed in the webapp. - -The problem character is, I believe, a latin-1 encoded filename (as opposed to UTF-8). --[[anarcat]] - -### What steps will reproduce the problem? - -1. download [this logfile](http://paste.anarc.at/daemon.log.1) -2. install it in .git/annex/daemon.log -3. load the webapp -4. visit the logs page - -### What version of git-annex are you using? On what operating system? - -4.20131105-g8efdc1a - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -Internal Server Error -/srv/video/.git/annex/daemon.log.1: hGetContents: invalid argument (invalid byte sequence) -git-annex version 4.20131105-g8efdc1a -# End of transcript or log. -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__.mdwn b/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__.mdwn deleted file mode 100644 index 149ae3a37..000000000 --- a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -### Please describe the problem. - -I can't create an IPFS external remote. - -### What steps will reproduce the problem? - -Start IPFS with `ipfs daemon`, run `git annex initremote ipfs type=external externaltype=ipfs encryption=none` (as per https://git-annex.branchable.com/special_remotes/ipfs/) - -### What version of git-annex are you using? On what operating system? - -[[!format sh """ -fiatjaf@lachmann ~/D/adv-annex> git annex version -git-annex version: 5.20140412ubuntu1 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 - -fiatjaf@lachmann ~/D/adv-annex> ipfs version -ipfs version 0.3.8-dev -"""]] - -### Please provide any additional information below. - -[[!format sh """ -fiatjaf@lachmann ~/D/adv-annex> ipfs swarm peers -/ip4/104.131.131.82/tcp/4001/ipfs/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ -/ip4/104.236.151.122/tcp/4001/ipfs/QmSoLju6m7xTh3DuokvT3886QRYqxAzb1kShaanJgW36yx -/ip4/128.199.219.111/tcp/4001/ipfs/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu -/ip4/167.114.2.68/tcp/4001/ipfs/QmfY24aJDGyPyUJVyzL1QHPoegmFKuuScoCKrBk9asoTFG -/ip4/178.62.61.185/tcp/4001/ipfs/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3 -/ip4/188.40.42.143/tcp/4001/ipfs/QmRg7T93TRuPT2wzyXNiYwin9ukWaNocdgKbRmmtsaxUa1 -/ip4/200.73.112.159/tcp/4001/ipfs/QmUxHvhvQtvdUoGHd83YTJoG7VLL1yWCrcXK7sy62ZEn65 -/ip4/37.252.125.190/tcp/4001/ipfs/QmQvQVoWostg7k1mnxtx787eVDmFPsEfkpUgQx1Ad2ibjc -/ip4/66.172.11.145/tcp/4001/ipfs/QmSjEaDoVnSQsfieWaX91aTC8ei3kPZE4JfPLLLefYqQRt -/ip4/92.243.15.110/tcp/4001/ipfs/QmcU5ZFRjkpZjTMwnYeUaG8CFNA1ueX79aayv2VqK1zakR -fiatjaf@lachmann ~/D/adv-annex> ls * .git/ -final5.mp4 - -.git/: -annex/ COMMIT_EDITMSG description hooks/ info/ objects/ -branches/ config HEAD index logs/ refs/ -fiatjaf@lachmann ~/D/adv-annex> -git annex initremote ipfs type=external externaltype=ipfs encryption=none -initremote ipfs git-annex: external special remote protocol error, unexpectedly received "" (unable to parse command) -fiatjaf@lachmann ~/D/adv-annex> -"""]] - -### 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, git-annex works for everything and I use lots of special remotes and normal remotes in different computers. - -> [[done]] diff --git a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_1_f1da699581e72aad0c3433d8fc02ce9c._comment b/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_1_f1da699581e72aad0c3433d8fc02ce9c._comment deleted file mode 100644 index c8b248fdc..000000000 --- a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_1_f1da699581e72aad0c3433d8fc02ce9c._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-18T16:09:03Z" - content=""" -It works here, no problem. And, the ipfs special remote does not actually -use ipfs at all when initremote is run, so there's no possibility of some -change in ipfs versions having broken it. - -My best guess is something in your shell or environment is making the -git-annex-remote-ipfs script not work right, and apparently output an extra -newline. I can reproduce that error message from git-annex if I modify -git-annex-remote-ipfs to echo a blank link on startup. I can't see any -way that shell script could output an extra newline normally however. - -Passing --debug will cause the protocol output to be dumped, which could -help debug this. All I'd expect to see in the protocol dump is -git-annex sending "INITREMOTE" and git-annex-remote-ipfs responding -with "INITREMOTE-SUCCESS". So another way to see what's going wrong with -the script's output is this: - - # echo INITREMOTE | git-annex-remote-ipfs - VERSION 1 - INITREMOTE-SUCCESS - # - -And if that outputs an extra newline as I hypothesize, this should help -pinpoint what line of the script is doing that: - - # echo INITREMOTE | sh -x $(which git-annex-remote-ipfs) -"""]] diff --git a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_2_6e21c7d729d07be2264c7a477e5b8227._comment b/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_2_6e21c7d729d07be2264c7a477e5b8227._comment deleted file mode 100644 index 6d973191a..000000000 --- a/doc/bugs/ipfs_initremote_failing_with___34__unable_to_parse_command__34__/comment_2_6e21c7d729d07be2264c7a477e5b8227._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="fiatjaf" - subject="I'm sorry" - date="2015-11-18T16:42:04Z" - content=""" -I'm very sorry for wasting your time. -I completely forgot to install https://git-annex.branchable.com/special_remotes/external/git-annex-remote-ipfs and just noticed it when trying to run `echo INITREMOTE | git-annex-remote-ipfs`. -This is a shame. - -Installing it made everything work. -"""]] diff --git a/doc/bugs/largefiles_not_working_when_set_in_.gitattributes.mdwn b/doc/bugs/largefiles_not_working_when_set_in_.gitattributes.mdwn deleted file mode 100644 index 7eb1332a2..000000000 --- a/doc/bugs/largefiles_not_working_when_set_in_.gitattributes.mdwn +++ /dev/null @@ -1,77 +0,0 @@ -### Please describe the problem. -annex.largefiles saved in .gitattributes does not work when running 'git annex add' from a subdirectory - -I set annex.largefiles to include any files larger than 50k or any files that are executable. This works if I'm adding a files from top level directory. But if I'm adding files from a sub-directory it does not work. - -### What steps will reproduce the problem? -see log below - -### What version of git-annex are you using? On what operating system? -ubuntu 15.10 - -git-annex version: 6.20160318-gd594fc0 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -vagrant@u240:/tmp/annex/$ git init -Initialized empty Git repository in /tmp/annex/.git/ -vagrant@u240:/tmp/annex/$ git annex init -init ok -(recording state in git...) -vagrant@u240:/tmp/annex/$ mkdir sub-dir -vagrant@u240:/tmp/annex/$ cp /bin/tempfile . -‘/bin/tempfile’ -> ‘./tempfile’ -vagrant@u240:/tmp/annex/$ cp /bin/tempfile sub-dir/ -‘/bin/tempfile’ -> ‘sub-dir/tempfile’ -vagrant@u240:/tmp/annex/$ file --mime-type tempfile -tempfile: application/x-executable -vagrant@u240:/tmp/annex/$ cat .gitattributes -* annex.largefiles=((largerthan=50kb)or(mimetype=application/x-executable)) -vagrant@u240:/tmp/annex/$ ls -l tempfile --rwxr-xr-x 1 vagrant vagrant 10352 Apr 6 15:19 tempfile -# the file is 10k in size and I can annex it from top level directory -vagrant@u240:/tmp/annex/$ git annex add tempfile sub-dir/tempfile -add tempfile ok -add sub-dir/tempfile ok -(recording state in git...) -vagrant@u240:/tmp/annex/$ cp /bin/tempfile tempfile2 -‘/bin/tempfile’ -> ‘tempfile2’ -vagrant@u240:/tmp/annex/$ cp /bin/tempfile sub-dir/tempfile2 -‘/bin/tempfile’ -> ‘sub-dir/tempfile2’ -vagrant@u240:/tmp/annex/$ cd sub-dir/ -# same file but I can not annex it if running from a sub-directory -vagrant@u240:/tmp/annex/sub-dir/$ git annex add ../tempfile2 tempfile2 -add ../tempfile2 ok -add tempfile2 (non-large file; adding content to git repository) ok -(recording state in git...) -vagrant@u240:/tmp/annex/sub-dir/$ cd .. -vagrant@u240:/tmp/annex/$ ls -lR -.: -total 12 -drwxrwxr-x 2 vagrant vagrant 4096 Apr 6 15:21 sub-dir/ -lrwxrwxrwx 1 vagrant vagrant 186 Apr 6 15:19 tempfile -> .git/annex/objects/xj/kJ/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5 -lrwxrwxrwx 1 vagrant vagrant 186 Apr 6 15:20 tempfile2 -> .git/annex/objects/xj/kJ/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5 - -./sub-dir: -total 16 -lrwxrwxrwx 1 vagrant vagrant 189 Apr 6 15:20 tempfile -> ../.git/annex/objects/xj/kJ/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5/SHA256E-s10352--93a1f74ec1714ef2107989076140b4eaae220f7b2cde834c16a7ad654d12b0f5 --rwxr-xr-x 1 vagrant vagrant 10352 Apr 6 15:21 tempfile2 - - -# End of transcript or log. -"""]] - -### 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) - - -> Thanks for reporting. This was a dumb bug; it used the wrong path to the -> file for mimetype=, which was relative to the top of the repository. -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn b/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn deleted file mode 100644 index 265005c9e..000000000 --- a/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -### Please describe the problem. - -with previous snapshot (6.20160119+gitgb2a2f5d-1~ndall+1) you just get a clean output - -[[!format sh """ -hopa:~/.tmp -$> git clone /home/yoh/.tmp/datalad_temp_clone_url_RmXPyt 123 -Cloning into '123'... -done. - -$> cd 123 -INFO.txt test-annex.dat@ test.dat - -$> git annex lookupkey test-annex.dat -SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat - -"""]] - -with new one (6.20160126+gitg65f4442-1~ndall+1) you get it polluted in such a freshly cloned repo with - -[[!format sh """ -$> git annex lookupkey test-annex.dat -(merging origin/git-annex into git-annex...) -(recording state in git...) -SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat -"""]] - -and since I am a "dude" who likes "devnulling" things for some reason (I hope reason is clear here ;)): - -[[!format sh """ -$> git annex lookupkey test-annex.dat 2>/dev/null -(merging origin/git-annex into git-annex...) -(recording state in git...) -SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat -"""]] - -I guess I will just skip all lines starting with ( for now but thought to let you know about such changed behavior which might complicate pipelining etc - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_740035f35d149f453e66c3ed03d525b5._comment b/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_740035f35d149f453e66c3ed03d525b5._comment deleted file mode 100644 index 054c6919c..000000000 --- a/doc/bugs/lookupkey_started_to_spit_out___34__debug__34___messages_to_stdout/comment_1_740035f35d149f453e66c3ed03d525b5._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-29T17:16:57Z" - content=""" -Argh, that was a dumb mistake. I've fixed this in git. - -A better workaround would be to use --quiet which will silence all messages -except the main command output. -"""]] diff --git a/doc/bugs/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn b/doc/bugs/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn deleted file mode 100644 index b5077f910..000000000 --- a/doc/bugs/man_page_for_command_misses_actual_command_in_the_synopsis_for_git-annex-checkpresentkey.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -[[!format sh """ -$> git annex version -git-annex version: 6.20160126+gitg65f4442-1~ndall+1 -... -$> man git-annex-checkpresentkey | head -git-annex-checkpresentkey(1) General Commands Manual git-annex-checkpresentkey(1) - -NAME - git-annex-checkpresentkey - check if key is present in remote - -SYNOPSIS - git annex key remote - -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/may_be_annex_should_be_more_attentive_to_non-annex_repos_and_not_annexify_them__63__.mdwn b/doc/bugs/may_be_annex_should_be_more_attentive_to_non-annex_repos_and_not_annexify_them__63__.mdwn deleted file mode 100644 index cff4dcaf8..000000000 --- a/doc/bugs/may_be_annex_should_be_more_attentive_to_non-annex_repos_and_not_annexify_them__63__.mdwn +++ /dev/null @@ -1,87 +0,0 @@ -### Please describe the problem. - -git annex info (and may be other commands) would "initiate" git-annex branch (and may be smth else?) even if a given repository has nothing to do with annex (well -- tested in git-annex code repo itself, which is not annexed). Even if I specify file pointing to somewhere else. For that actually annex also would initiate git-annex branch even though underlying git call would fail due to outside repo. - -I expect e.g. 'annex info' to fail and return some non-0 code since ran within non-annexed repo (no remote git-annex branch, nothing). - -### What steps will reproduce the problem? - -run git annex info in non-annexed repo - -### What version of git-annex are you using? On what operating system? - -5.20150819+gitgc587698-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ - -% git branch - bf-standalone-correct-changelog - bf-standalone-for-style - debian-jessie - debian-standalone - enh-me-mailmap - fixups -* master - neurodebian-custom - tuneups - -% pwd -/home/yoh/proj/git-annex - -% git annex version -git-annex version: 5.20150819+gitgc587698-1~ndall+1 -build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: unknown -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 - -% git branch | grep git-annex - -% git annex info -repository mode: indirect -trusted repositories: 0 -semitrusted repositories: 2 - 00000000-0000-0000-0000-000000000001 -- web - 00000000-0000-0000-0000-000000000002 -- bittorrent -untrusted repositories: 0 -transfers in progress: none -available local disk space: 225.96 gigabytes (+1 megabyte reserved) -local annex keys: 0 -local annex size: 0 bytes -annexed files in working tree: 0 -size of annexed files in working tree: 0 bytes -bloom filter size: 32 mebibytes (0% full) -backend usage: - -% git branch | grep git-annex - git-annex - -% git branch -D git-annex -Deleted branch git-annex (was e9424d2). - -% git annex info /home/yoh/.tmp/datalad_temp_clone_url_EbPVvm/ -fatal: /home/yoh/.tmp/datalad_temp_clone_url_EbPVvm/: '/home/yoh/.tmp/datalad_temp_clone_url_EbPVvm/' is outside repository -directory: /home/yoh/.tmp/datalad_temp_clone_url_EbPVvm/ -local annex keys: 0 -local annex size: 0 bytes -annexed files in working tree: 0 -size of annexed files in working tree: 0 bytes -numcopies stats: -repositories containing these files: 0 - -% git branch | grep git-annex - git-annex -"""]] - -### 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 -- with every day it grows on/in me! ;) - -> Oddly, I noticed this earlier today, and fixed it. Only git annex info -> was affected; for some reason it was marked to let it run outside a -> git-annex repo. [[done]] --[[Joey]] diff --git a/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn b/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn deleted file mode 100644 index 70034ac4d..000000000 --- a/doc/bugs/mode_changes_for_sharedRepository_lead_to_permissionDenied_in_fsck.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -### Please describe the problem. - -When a repository created shared pre 5.20151208 is fsck'd, it spews error messages a la `setFileMode: permission denied (Operation not permitted)` and fails the fsck. - -This seems to be due to the change in file permissions introduced in [[news/5.20151208]] ("When core.sharedRepository is set, annex object files are not made mode 444, since that prevents a user other than the file owner from locking them. Instead, a mode such as 664 is used in this case."). The error message is unclear to a user, though, and does IMO not constitute an error to fail over. - -IMO, failure to set the mode due to ownership issues should be ignored in fsck, and when a user other than the original owner tries to lock a file, they should be presented with an error message a la "Please run `git annex fsck --fast` as <user> to fix the file's permissions". As an alternative or additionally, fsck could show a warning (maybe even an error) that running an additional fsck as all of the other users (explicit list would be nice) to fix all file permissions. - -### Workarounds - -The issue can be resolved for a repository by - -### What version of git-annex are you using? On what operating system? - -This was observed on a git-annex remote pushed to via ssh on debian sid, with pushes from various git-annex versions over the past years. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn b/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn deleted file mode 100644 index 8dca631ba..000000000 --- a/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### Please describe the problem. -When I try to start the webapp, it fails, complaining about a nautilus script. - - -### What version of git-annex are you using? On what operating system? -Mythbuntu 12.04 (which is based on XFCE and doesn't have nautilus) -$ git-annex version -git-annex version: 5.20140402 -build flags: Assistant Webapp Webapp-secure Pairing S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ git-annex webapp - -git-annex: /home/mythbuntu/.local/share/nautilus/scripts/git-annex get: openFile: does not exist (No such file or directory) -failed -git-annex: webapp: 1 failed - -# End of transcript or log. -"""]] - -[[fixed|done]] --[[Joey]] diff --git a/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_9fdeaa51ccc7c71dcfeea3ea783d3b50._comment b/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_9fdeaa51ccc7c71dcfeea3ea783d3b50._comment deleted file mode 100644 index d25188658..000000000 --- a/doc/bugs/nautilus__47__scripts__47__git-annex_get__58___openFile__58___does_not_exist___40__No_such_file_or_directory__41__/comment_1_9fdeaa51ccc7c71dcfeea3ea783d3b50._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc" - nickname="Sören" - subject="comment 1" - date="2014-04-06T11:34:37Z" - content=""" -The problem has been reported [here](http://git-annex.branchable.com/bugs/git-annex_fails_to_start_when_nautilus_script_directory_is_missing/) as well and is already fixed in the latest [release](http://git-annex.branchable.com/news/version_5.20140405/). - -"""]] diff --git a/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn b/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn deleted file mode 100644 index bd860e9e4..000000000 --- a/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them.mdwn +++ /dev/null @@ -1,93 +0,0 @@ -### Please describe the problem. - -With upgrade to 6.20160114+gitg6be9ee0-1~ndall+1 our (datalad) tests started to fail since apparently format of whereis --json has changed. It changed probably for the best since now no need to parse out urls from the generic 'note' field. BUT it seems that it has lost 1. ability to associate urls with remotes 2. doesn't list web remote urls if another remote provides urls as well - -### Please provide any additional information below. - -[[!format sh """ -$> git annex whereis sub001/BOLD/task001_run001/bold.nii.gz -whereis sub001/BOLD/task001_run001/bold.nii.gz (3 copies) - 00000000-0000-0000-0000-000000000001 -- web - 70d0c2f3-0d57-485c-8802-f6e829503516 -- [datalad-archives] - bb907499-dbea-4713-977f-0ccd209de415 -- yoh@hopa:~/datalad/crawl/openfmri/ds000005 [here] - - web: http://www.onerussian.com/tmp/banner.png - web: http://www.onerussian.com/tmp/bold.nii.gz - - datalad-archives: dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz - datalad-archives: dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz - datalad-archives: dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz - datalad-archives: dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz -ok - -$> git annex whereis --json sub001/BOLD/task001_run001/bold.nii.gz | python -m json.tool -{ - "command": "whereis", - "file": "sub001/BOLD/task001_run001/bold.nii.gz", - "note": "\t00000000-0000-0000-0000-000000000001 -- web\n \t70d0c2f3-0d57-485c-8802-f6e829503516 -- [datalad-archives]\n \tbb907499-dbea-4713-977f-0ccd209de415 -- yoh@hopa:~/datalad/crawl/openfmri/ds000005 [here]\n", - "success": true, - "untrusted": [], - "urls": [ - "dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz" - ], - "whereis": [ - { - "description": "web", - "here": false, - "uuid": "00000000-0000-0000-0000-000000000001" - }, - { - "description": "[datalad-archives]", - "here": false, - "uuid": "70d0c2f3-0d57-485c-8802-f6e829503516" - }, - { - "description": "yoh@hopa:~/datalad/crawl/openfmri/ds000005", - "here": true, - "uuid": "bb907499-dbea-4713-977f-0ccd209de415" - } - ] -} - -"""]] - -as you can see -- only --json format is missing on web remote URLs. I guess, ideally, "urls" should also be an associative array with keys corresponding to remote names and listing them under. OR why not to list them within the remote record under 'whereis'? Sounds like the most logical place for them to be at, e.g. - -[[!format sh """ - - "whereis": [ - { - "description": "web", - "here": false, - "uuid": "00000000-0000-0000-0000-000000000001", - "urls": [ "http://www.onerussian.com/tmp/bold.nii.gz"] - }, - { - "description": "[datalad-archives]", - "here": false, - "uuid": "70d0c2f3-0d57-485c-8802-f6e829503516" - "urls": [ - "dl+archive:SHA256E-s110760--5c9a3b565944b84c7df381481b597d716061881cbfc85493317452e85ea9b391.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s111649--63c9168b53e033c29d188b97d4950e267fa93a4d991fc92f42a3bb9488013863.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s112069--f1afedb105994006cbf37c03e2a05b538397283701c5a9bee483287ca912d690.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz", - "dl+archive:SHA256E-s154612--8adda02a8bc1a88f864f2cff31766f5ad4fcefbb42afd7230f95edfb5e0dfcb1.tgz/ds005/sub001/BOLD/task001_run001/bold.nii.gz" - ], - - - }, - { - "description": "yoh@hopa:~/datalad/crawl/openfmri/ds000005", - "here": true, - "uuid": "bb907499-dbea-4713-977f-0ccd209de415" - } - ] -"""]] - -what is the purpose of note in current output anyways since it just duplicates information in 'whereis' field? - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them/comment_1_c53cf9bbcef391f9072b6d3618d8be12._comment b/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them/comment_1_c53cf9bbcef391f9072b6d3618d8be12._comment deleted file mode 100644 index 8cf26b724..000000000 --- a/doc/bugs/new_whereis_--json_lost_information_about_web_urls_if_other_special_remotes_provide_them/comment_1_c53cf9bbcef391f9072b6d3618d8be12._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-15T18:10:26Z" - content=""" -The web urls were included in the json output, but it seems some json -parsers, including the one you're using, only show the last value of an -attribute when multiple values are repeated, as happened when there were -both web and other remotes with urls. - -Anyway, I've updated the json output to include the url list inside the -remote's record. - -(The "note" just collects any output that is not explicitly formatted as -json.) -"""]] diff --git a/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__.mdwn b/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__.mdwn deleted file mode 100644 index 5a1b48031..000000000 --- a/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__.mdwn +++ /dev/null @@ -1,330 +0,0 @@ -### Please describe the problem. - -Building git-annex-5.20150930 on OpenBSD 5.8 snapshot/amd64 (2015-09-30) fails, ghc is 7.10.2: - -[[!format sh """ -*** C pre-processor: -/usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Configurators/AWS.hs -o /tmp/ghc9832_0/ghc_101.hscpp - -Assistant/WebApp/Configurators/AWS.hs:79:0: - error: missing binary operator before token "(" -*** Deleting temp files: -Deleting: /tmp/ghc9832_0/ghc_101.hscpp /tmp/ghc9832_0/ghc_100.hscpp /tmp/ghc9832_0/ghc_99.hscpp /tmp/ghc9832_0/ghc_98.hscpp /tmp/ghc9832_0/ghc_97.hscpp /tmp/ghc9832_0/ghc_96.hscpp /tmp/ghc9832_0/ghc_95.hscpp /tmp/ghc9832_0/ghc_94.hscpp /tmp/ghc9832_0/ghc_93.hscpp /tmp/ghc9832_0/ghc_92.hscpp /tmp/ghc9832_0/ghc_91.hscpp /tmp/ghc9832_0/ghc_90.hscpp /tmp/ghc9832_0/ghc_89.hscpp /tmp/ghc9832_0/ghc_88.hscpp /tmp/ghc9832_0/ghc_87.hscpp /tmp/ghc9832_0/ghc_86.hscpp /tmp/ghc9832_0/ghc_85.hscpp /tmp/ghc9832_0/ghc_84.hscpp /tmp/ghc9832_0/ghc_83.hscpp /tmp/ghc9832_0/ghc_82.hscpp /tmp/ghc9832_0/ghc_81.hscpp /tmp/ghc9832_0/ghc_80.hscpp /tmp/ghc9832_0/ghc_79.hscpp /tmp/ghc9832_0/ghc_78.hscpp /tmp/ghc9832_0/ghc_77.hscpp /tmp/ghc9832_0/ghc_76.hscpp /tmp/ghc9832_0/ghc_75.hscpp /tmp/ghc9832_0/ghc_74.hscpp /tmp/ghc9832_0/ghc_73.hscpp /tmp/ghc9832_0/ghc_72.hscpp /tmp/ghc9832_0/ghc_71.hscpp /tmp/ghc9832_0/ghc_70.hscpp /tmp/ghc9832_0/ghc_69.hscpp /tmp/ghc9832_0/ghc_68.hscpp /tmp/ghc9832_0/ghc_67.hscpp /tmp/ghc9832_0/ghc_66.hscpp /tmp/ghc9832_0/ghc_65.hscpp /tmp/ghc9832_0/ghc_64.hscpp /tmp/ghc9832_0/ghc_63.hscpp /tmp/ghc9832_0/ghc_62.hscpp /tmp/ghc9832_0/ghc_61.hscpp /tmp/ghc9832_0/ghc_60.hscpp /tmp/ghc9832_0/ghc_59.hscpp /tmp/ghc9832_0/ghc_58.hscpp /tmp/ghc9832_0/ghc_57.hscpp /tmp/ghc9832_0/ghc_56.hscpp /tmp/ghc9832_0/ghc_55.hscpp /tmp/ghc9832_0/ghc_54.hscpp /tmp/ghc9832_0/ghc_53.hscpp /tmp/ghc9832_0/ghc_52.hscpp /tmp/ghc9832_0/ghc_51.hscpp /tmp/ghc9832_0/ghc_50.hscpp /tmp/ghc9832_0/ghc_49.hscpp /tmp/ghc9832_0/ghc_48.hscpp /tmp/ghc9832_0/ghc_47.hscpp /tmp/ghc9832_0/ghc_46.hscpp /tmp/ghc9832_0/ghc_45.hscpp /tmp/ghc9832_0/ghc_44.hscpp /tmp/ghc9832_0/ghc_43.hscpp /tmp/ghc9832_0/ghc_42.hscpp /tmp/ghc9832_0/ghc_41.hscpp /tmp/ghc9832_0/ghc_40.hscpp /tmp/ghc9832_0/ghc_39.hscpp /tmp/ghc9832_0/ghc_38.hscpp /tmp/ghc9832_0/ghc_37.hscpp /tmp/ghc9832_0/ghc_36.hscpp /tmp/ghc9832_0/ghc_35.hscpp /tmp/ghc9832_0/ghc_34.hscpp /tmp/ghc9832_0/ghc_33.hscpp /tmp/ghc9832_0/ghc_32.hscpp /tmp/ghc9832_0/ghc_31.hscpp /tmp/ghc9832_0/ghc_30.hscpp /tmp/ghc9832_0/ghc_29.hscpp /tmp/ghc9832_0/ghc_28.hscpp /tmp/ghc9832_0/ghc_27.hscpp /tmp/ghc9832_0/ghc_26.hscpp /tmp/ghc9832_0/ghc_25.hscpp /tmp/ghc9832_0/ghc_24.hscpp /tmp/ghc9832_0/ghc_23.hscpp /tmp/ghc9832_0/ghc_22.hscpp /tmp/ghc9832_0/ghc_21.hscpp /tmp/ghc9832_0/ghc_20.hscpp /tmp/ghc9832_0/ghc_19.hscpp /tmp/ghc9832_0/ghc_18.hscpp /tmp/ghc9832_0/ghc_17.hscpp /tmp/ghc9832_0/ghc_16.hscpp /tmp/ghc9832_0/ghc_15.hscpp /tmp/ghc9832_0/ghc_14.hscpp /tmp/ghc9832_0/ghc_13.hscpp /tmp/ghc9832_0/ghc_12.hscpp /tmp/ghc9832_0/ghc_11.hscpp /tmp/ghc9832_0/ghc_10.hscpp /tmp/ghc9832_0/ghc_9.hscpp /tmp/ghc9832_0/ghc_8.hscpp /tmp/ghc9832_0/ghc_7.hscpp /tmp/ghc9832_0/ghc_6.hscpp /tmp/ghc9832_0/ghc_5.hscpp /tmp/ghc9832_0/ghc_4.hscpp /tmp/ghc9832_0/ghc_3.hscpp /tmp/ghc9832_0/ghc_2.hscpp /tmp/ghc9832_0/ghc_1.hscpp -Warning: deleting non-existent /tmp/ghc9832_0/ghc_101.hscpp -*** Deleting temp dirs: -Deleting: /tmp/ghc9832_0 -/usr/local/bin/ghc returned ExitFailure 1 - -$ ghc -V -The Glorious Glasgow Haskell Compilation System, version 7.10.2 -"""]] - -### What steps will reproduce the problem? - -1. have OpenBSD 5.8 snapshot for amd64 (64bit x86 platform) -2. install haskell-platform package (pkg_add haskell-platform) -3. cabal update ; cabal get git-annex -4. cd git-annex* ; cabal sandbox init --sandbox=. -5. use following flags: - $ awk '/^Flag/ && !/Webapp|Assistant/ { print "-"$2 }' git-annex.cabal | xargs --S3 -WebDAV -Inotify -Dbus -Pairing -XMPP -DNS -Production -Android -AndroidSplice -TestSuite -TDFA -Feed -Quvi -Tahoe -DesktopNotify -TorrentParser -AsciiProgress -EKG -network-uri -Database -Cryptonite -6. cabal install -v3 -j -f"$( awk '/^Flag/ && !/Webapp|Assistant/ { print "-"$2 }' git-annex.cabal | xargs )" --only-dependencies - (fyi: there's a bug in warp so check this diff https://github.com/awpr/wai/commit/831b944c5ddb5f9e71b8c5c3d4c185d0000562b1) -7. cabal configure -v3 -f"$( awk '/^Flag/ && !/Webapp|Assistant/ { print "-"$2 }' git-annex.cabal | xargs )" -8. cabal build -v3 -j - -### What version of git-annex are you using? On what operating system? - -git-annex-5.20150930 - -### Please provide any additional information below. - -[[!format sh """ - - $ cabal build -v3 -j - Using a sandbox located at - /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930 - Reading available packages... - Reading installed packages... - ("/usr/local/bin/ghc-pkg",["dump","--package-db=/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/x86_64-openbsd-ghc-7.10.2-packages.conf.d","-v0"]) - ("/usr/local/bin/ghc",["--print-libdir"]) - Found no modified add-source deps. - Using external setup method with build-type Custom - creating dist/setup - Using Cabal library version 1.22.4.0 - ./dist/setup/setup build --verbose=3 --builddir=dist --jobs=2 - Component build order: executable 'git-annex' - creating dist/build - creating dist/build/autogen - Building git-annex-5.20150930... - Environment: [("AWT_TOOLKIT","XToolkit"),("DBUS_SESSION_BUS_ADDRESS","unix:path=/tmp/dbus-Wm90QFfaar,guid=2309f6d0604ee5fc552c89af560d9e17"),("DISPLAY",":0"),("ENV","/home/jirib/.kshrc"),("GDK_USE_XFT","0"),("HISTFILE",".sh_history"),("HOME","/home/jirib"),("LANG","en_US.UTF-8"),("LOGNAME","jirib"),("PATH","/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/bin:/home/jirib/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.:/home/jirib/.cabal/bin:/home/jirib/.cabal/bin"),("PKG_PATH","http://mirror.steadynet.cz/pub/OpenBSD/snapshots/packages/amd64/"),("PS1","\\n$USER:$PWD\\n$ "),("PWD","/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930"),("SHELL","/bin/ksh"),("SSH_AGENT_PID","17201"),("SSH_AUTH_SOCK","/tmp/ssh-aPlKN3hf8LJV/agent.24785"),("TERM","screen"),("TMUX","/tmp/tmux-1000/default,20957,0"),("TMUX_PANE","%5"),("USER","jirib"),("WINDOWID","18874381"),("WINDOWPATH","5"),("XTERM_LOCALE","en_US.UTF-8"),("XTERM_SHELL","/bin/ksh"),("XTERM_VERSION","XTerm/OpenBSD(320)"),("_","/usr/local/bin/cabal")] - ("/usr/local/bin/ghc-pkg",["init","dist/package.conf.inplace","-v2"]) - writing cache dist/package.conf.inplace/package.cache - Preprocessing executable 'git-annex' for git-annex-5.20150930... - Building executable git-annex... - creating dist/build/git-annex - creating dist/build/git-annex/git-annex-tmp - Environment: [("AWT_TOOLKIT","XToolkit"),("DBUS_SESSION_BUS_ADDRESS","unix:path=/tmp/dbus-Wm90QFfaar,guid=2309f6d0604ee5fc552c89af560d9e17"),("DISPLAY",":0"),("ENV","/home/jirib/.kshrc"),("GDK_USE_XFT","0"),("HISTFILE",".sh_history"),("HOME","/home/jirib"),("LANG","en_US.UTF-8"),("LOGNAME","jirib"),("PATH","/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/bin:/home/jirib/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin:/usr/games:.:/home/jirib/.cabal/bin:/home/jirib/.cabal/bin"),("PKG_PATH","http://mirror.steadynet.cz/pub/OpenBSD/snapshots/packages/amd64/"),("PS1","\\n$USER:$PWD\\n$ "),("PWD","/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930"),("SHELL","/bin/ksh"),("SSH_AGENT_PID","17201"),("SSH_AUTH_SOCK","/tmp/ssh-aPlKN3hf8LJV/agent.24785"),("TERM","screen"),("TMUX","/tmp/tmux-1000/default,20957,0"),("TMUX_PANE","%5"),("USER","jirib"),("WINDOWID","18874381"),("WINDOWPATH","5"),("XTERM_LOCALE","en_US.UTF-8"),("XTERM_SHELL","/bin/ksh"),("XTERM_VERSION","XTerm/OpenBSD(320)"),("_","/usr/local/bin/cabal")] - ("/usr/local/bin/ghc",["--make","-no-link","-v","-fbuilding-cabal-package","-O","-j2","-static","-outputdir","dist/build/git-annex/git-annex-tmp","-odir","dist/build/git-annex/git-annex-tmp","-hidir","dist/build/git-annex/git-annex-tmp","-stubdir","dist/build/git-annex/git-annex-tmp","-i","-idist/build/git-annex/git-annex-tmp","-i.","-idist/build/autogen","-Idist/build/autogen","-Idist/build/git-annex/git-annex-tmp","-IUtility","-optP-DWITH_CLIBS","-optP-DWITH_ASSISTANT","-optP-DWITH_KQUEUE","-optP-DWITH_WEBAPP","-optP-DWITH_WEBAPP_SECURE","-optP-include","-optPdist/build/autogen/cabal_macros.h","-hide-all-packages","-no-user-package-db","-package-db","/home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/x86_64-openbsd-ghc-7.10.2-packages.conf.d","-package-db","dist/package.conf.inplace","-package-id","IfElse-0.85-8c1db1f839f44c5529d401df338fe317","-package-id","MissingH-1.3.0.1-e54b797a34e6cb205f6f390e10450316","-package-id","QuickCheck-2.8.1-205c25b58070768870086b4df430493a","-package-id","SafeSemaphore-0.10.1-4f3138e0a22eaafa634797b1a6a487f9","-package-id","aeson-0.10.0.0-17203400b8ef32da113b969a5bf6b421","-package-id","async-2.0.2-7323ce9f8a31649b3f9f961e623ae0eb","-package-id","base-4.8.1.0-e9d679e3d378e2518aed01b8b69ce058","-package-id","blaze-builder-0.4.0.1-9588a3a15a2f3414e775fe4d569b21d4","-package-id","bloomfilter-2.0.1.0-a9c6b1194fe5c0015321f0a4e7f3913e","-package-id","byteable-0.1.1-48ca2c3fb39c0c4b6558110ffad0d275","-package-id","bytestring-0.10.6.0-b589eded7797edbdfe3d6e68c53a58dc","-package-id","case-insensitive-1.2.0.4-19d14e9206f0c06c6d26299b5df858f2","-package-id","clientsession-0.9.1.1-fdef70f936d7254b2ce9be7a7c88a429","-package-id","containers-0.5.6.2-7a88df79ef535718d24bcf01924e95ea","-package-id","crypto-api-0.13.2-fe6624016dbd84f79370a229db9c50b4","-package-id","cryptohash-0.11.6-8ee3be9b04a6ed91e6a933e4ab55b446","-package-id","data-default-0.5.3-a2ece8050e447d921b001e26e14476f2","-package-id","directory-1.2.2.0-9604452531b12502e0c0f53fe36bac14","-package-id","dlist-0.7.1.2-2ee7ccabb5af73780c27d45186b61b2a","-package-id","edit-distance-0.2.2.1-1e17962d7db38ea1b8ddcbcc82c36e3f","-package-id","exceptions-0.8.0.2-b08bd0de7dff383d124cad3f4c34eddd","-package-id","filepath-1.4.0.0-8fee9c13b5e42926cc01f6aa7c403c4b","-package-id","hslogger-1.2.9-f91beb37c8c482a9164b1fb2d65e9f7b","-package-id","http-conduit-2.1.8-3f9571a312ab569cd16979e8110b42e6","-package-id","http-types-0.8.6-90cda10008eb9ec48d623edd4222138c","-package-id","json-0.9.1-071cea633efbeb26f404205b6c92d2db","-package-id","monad-control-1.0.0.4-9b806c409db033e571fac7650e2dbb97","-package-id","monad-logger-0.3.14-6e4135d482645151586ba6f524d5a2c8","-package-id","mtl-2.2.1-5cf332b11edb88a6040af20fd6a58acb","-package-id","network-2.5.0.0-79b288edc2a1f492b0299230b7135bcf","-package-id","old-locale-1.0.0.7-2f3f4311e12e7847c2af472c26151237","-package-id","optparse-applicative-0.12.0.0-c035e6891921a870a8333e89c5b23759","-package-id","path-pieces-0.2.0-37a89ca1eb723024775a5dcb7dfe5a20","-package-id","process-1.2.3.0-f7cbb3835532fa6fa4fb3a1aa1f4bbe6","-package-id","random-1.1-9de9e9be919ec1d4e6119bd8961a507f","-package-id","regex-compat-0.95.1-e50502312ccfb1a89bd22db9d575dc4f","-package-id","resourcet-1.1.6-55de3aba5b250abebd371fa9d81977ea","-package-id","sandi-0.3.5-42eaac6c05b00fa1bf8ad214fe4954e8","-package-id","securemem-0.1.9-3d837514dd9f117b6559e5f233e357c1","-package-id","shakespeare-2.0.6-1183ef430c3a759068fcad22bd67f303","-package-id","stm-2.4.4-2526ff89874f899372b2e4f544bb03cd","-package-id","template-haskell-2.10.0.0-29e9ee689e414aeb467de728072e34e5","-package-id","text-1.2.1.3-5e120dece51b43c1c5a0c17e670cd819","-package-id","time-1.5.0.1-962ac4f6f4ca6114bbde156fc38752bb","-package-id","transformers-0.4.2.0-21dcbf13c43f5d8cf6a1f54dee6c5bff","-package-id","unix-2.7.1.0-4cd6bc0b569ae71215412d51dbf6ccdf","-package-id","unix-compat-0.4.1.4-c8aec8b150e56d876bc64b4916c558fe","-package-id","utf8-string-1.0.1.1-34502b713602e8a4940574a71c55ec33","-package-id","uuid-1.3.11-34749cfad2e988cf92ab92e73cd29a03","-package-id","wai-3.0.4.0-8690ec1047c082bdd30249fe1b407cfe","-package-id","wai-extra-3.0.10-d641ebcb8710634a497aa33b280d9f49","-package-id","warp-3.1.4-f1363cb38f0c1dc746cfc023d01605eb","-package-id","warp-tls-3.1.3-fe6c1b8e2d97f41cb3473de79302319c","-package-id","yesod-1.4.2-1c9d038617ae025cab86404afd836946","-package-id","yesod-core-1.4.15-02a732ed0c74e9e43891dfcf293a6b2a","-package-id","yesod-default-1.2.0-8f2416af7a2ee3c9cd620cc714b1aad9","-package-id","yesod-form-1.4.4.1-778084a0b51f18464b1286fe6edee826","-package-id","yesod-static-1.5.0.3-9fda499d45f58aff893578e4dd15e8ca","-XHaskell98","-XPackageImports","./git-annex.hs","-Wall","-fno-warn-tabs","-threaded"]) - Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.8.3.20150914 - Using binary package database: /usr/local/lib/ghc/package.conf.d/package.cache - Using binary package database: /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/x86_64-openbsd-ghc-7.10.2-packages.conf.d/package.cache - Using binary package database: dist/package.conf.inplace/package.cache - wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 - wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 - wired-in package base mapped to base-4.8.1.0-e9d679e3d378e2518aed01b8b69ce058 - wired-in package rts mapped to builtin_rts - wired-in package template-haskell mapped to template-haskell-2.10.0.0-29e9ee689e414aeb467de728072e34e5 - wired-in package ghc mapped to ghc-7.10.2-35b59c7ea6591394d1cf3df1da8b38d0 - wired-in package dph-seq not found. - wired-in package dph-par not found. - Hsc static flags: - wired-in package ghc-prim mapped to ghc-prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 - wired-in package integer-gmp mapped to integer-gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 - wired-in package base mapped to base-4.8.1.0-e9d679e3d378e2518aed01b8b69ce058 - wired-in package rts mapped to builtin_rts - wired-in package template-haskell mapped to template-haskell-2.10.0.0-29e9ee689e414aeb467de728072e34e5 - wired-in package ghc mapped to ghc-7.10.2-35b59c7ea6591394d1cf3df1da8b38d0 - wired-in package dph-seq not found. - wired-in package dph-par not found. - *** Chasing dependencies: - Chasing modules from: *git-annex.hs - Created temporary directory: /tmp/ghc9832_0 - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp git-annex.hs -o /tmp/ghc9832_0/ghc_1.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Test.hs -o /tmp/ghc9832_0/ghc_2.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git.hs -o /tmp/ghc9832_0/ghc_3.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/FileMode.hs -o /tmp/ghc9832_0/ghc_4.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/PosixFiles.hs -o /tmp/ghc9832_0/ghc_5.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/URI.hs -o /tmp/ghc9832_0/ghc_6.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Process.hs -o /tmp/ghc9832_0/ghc_7.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Misc.hs -o /tmp/ghc9832_0/ghc_8.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/FileSystemEncoding.hs -o /tmp/ghc9832_0/ghc_9.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Common.hs -o /tmp/ghc9832_0/ghc_10.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/FileSize.hs -o /tmp/ghc9832_0/ghc_11.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Directory.hs -o /tmp/ghc9832_0/ghc_12.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Tmp.hs -o /tmp/ghc9832_0/ghc_13.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Path.hs -o /tmp/ghc9832_0/ghc_14.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/UserInfo.hs -o /tmp/ghc9832_0/ghc_15.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Env.hs -o /tmp/ghc9832_0/ghc_16.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Gpg.hs -o /tmp/ghc9832_0/ghc_17.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Logs/Transfer.hs -o /tmp/ghc9832_0/ghc_18.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Logs/TimeStamp.hs -o /tmp/ghc9832_0/ghc_19.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/LockPool.hs -o /tmp/ghc9832_0/ghc_20.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/LockPool/LockHandle.hs -o /tmp/ghc9832_0/ghc_21.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/PID.hs -o /tmp/ghc9832_0/ghc_22.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Bloom.hs -o /tmp/ghc9832_0/ghc_23.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex.hs -o /tmp/ghc9832_0/ghc_24.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Url.hs -o /tmp/ghc9832_0/ghc_25.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/InodeCache.hs -o /tmp/ghc9832_0/ghc_26.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Hash.hs -o /tmp/ghc9832_0/ghc_27.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Glob.hs -o /tmp/ghc9832_0/ghc_28.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Command.hs -o /tmp/ghc9832_0/ghc_29.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/CoProcess.hs -o /tmp/ghc9832_0/ghc_30.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Construct.hs -o /tmp/ghc9832_0/ghc_31.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/FilePath.hs -o /tmp/ghc9832_0/ghc_32.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Remote.hs -o /tmp/ghc9832_0/ghc_33.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Queue.hs -o /tmp/ghc9832_0/ghc_34.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/UpdateIndex.hs -o /tmp/ghc9832_0/ghc_35.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Hook.hs -o /tmp/ghc9832_0/ghc_36.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Logs/MapLog.hs -o /tmp/ghc9832_0/ghc_37.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Shell.hs -o /tmp/ghc9832_0/ghc_38.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/FileMode.hs -o /tmp/ghc9832_0/ghc_39.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Index.hs -o /tmp/ghc9832_0/ghc_40.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Journal.hs -o /tmp/ghc9832_0/ghc_41.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/LockFile.hs -o /tmp/ghc9832_0/ghc_42.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Rsync.hs -o /tmp/ghc9832_0/ghc_43.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Directory.hs -o /tmp/ghc9832_0/ghc_44.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Content.hs -o /tmp/ghc9832_0/ghc_45.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Messages/Progress.hs -o /tmp/ghc9832_0/ghc_46.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Content/Direct.hs -o /tmp/ghc9832_0/ghc_47.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/CopyFile.hs -o /tmp/ghc9832_0/ghc_48.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/DiskFree.hs -o /tmp/ghc9832_0/ghc_49.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Backend/Hash.hs -o /tmp/ghc9832_0/ghc_50.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Rsync.hs -o /tmp/ghc9832_0/ghc_51.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Rsync/RsyncUrl.hs -o /tmp/ghc9832_0/ghc_52.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Ssh.hs -o /tmp/ghc9832_0/ghc_53.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Path.hs -o /tmp/ghc9832_0/ghc_54.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Logs/Unused.hs -o /tmp/ghc9832_0/ghc_55.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/List.hs -o /tmp/ghc9832_0/ghc_56.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/BitTorrent.hs -o /tmp/ghc9832_0/ghc_57.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Web.hs -o /tmp/ghc9832_0/ghc_58.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Git.hs -o /tmp/ghc9832_0/ghc_59.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Batch.hs -o /tmp/ghc9832_0/ghc_60.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Init.hs -o /tmp/ghc9832_0/ghc_61.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Upgrade.hs -o /tmp/ghc9832_0/ghc_62.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Version.hs -o /tmp/ghc9832_0/ghc_63.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Environment.hs -o /tmp/ghc9832_0/ghc_64.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Transfer.hs -o /tmp/ghc9832_0/ghc_65.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Notification.hs -o /tmp/ghc9832_0/ghc_66.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Remote/Helper/Hooks.hs -o /tmp/ghc9832_0/ghc_67.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Annex/Action.hs -o /tmp/ghc9832_0/ghc_68.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Daemon.hs -o /tmp/ghc9832_0/ghc_69.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/LogFile.hs -o /tmp/ghc9832_0/ghc_70.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/DirWatcher.hs -o /tmp/ghc9832_0/ghc_71.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./CmdLine/GitAnnex.hs -o /tmp/ghc9832_0/ghc_72.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Types/Test.hs -o /tmp/ghc9832_0/ghc_73.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/ThreadScheduler.hs -o /tmp/ghc9832_0/ghc_74.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Command/WebApp.hs -o /tmp/ghc9832_0/ghc_75.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/WebApp.hs -o /tmp/ghc9832_0/ghc_76.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Install.hs -o /tmp/ghc9832_0/ghc_77.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Install/Menu.hs -o /tmp/ghc9832_0/ghc_78.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Install/AutoStart.hs -o /tmp/ghc9832_0/ghc_79.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Pairing.hs -o /tmp/ghc9832_0/ghc_80.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Types/Buddies.hs -o /tmp/ghc9832_0/ghc_81.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Yesod.hs -o /tmp/ghc9832_0/ghc_82.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Threads/WebApp.hs -o /tmp/ghc9832_0/ghc_83.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Repair.hs -o /tmp/ghc9832_0/ghc_84.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Utility/Lsof.hs -o /tmp/ghc9832_0/ghc_85.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Types/UrlRenderer.hs -o /tmp/ghc9832_0/ghc_86.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Alert.hs -o /tmp/ghc9832_0/ghc_87.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/TransferSlots.hs -o /tmp/ghc9832_0/ghc_88.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Threads/Watcher.hs -o /tmp/ghc9832_0/ghc_89.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/NamedThread.hs -o /tmp/ghc9832_0/ghc_90.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/RepoList.hs -o /tmp/ghc9832_0/ghc_91.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Page.hs -o /tmp/ghc9832_0/ghc_92.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Restart.hs -o /tmp/ghc9832_0/ghc_93.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./BuildFlags.hs -o /tmp/ghc9832_0/ghc_94.hscpp - - BuildFlags.hs:31:0: - warning: #warning Building without local pairing. - - BuildFlags.hs:36:0: - warning: #warning Building without the testsuite. - - BuildFlags.hs:41:0: warning: #warning Building without S3. - - BuildFlags.hs:46:0: warning: #warning Building without WebDAV. - - BuildFlags.hs:66:0: warning: #warning Building without XMPP. - - BuildFlags.hs:74:0: warning: #warning Building without Feeds. - - BuildFlags.hs:79:0: warning: #warning Building without quvi. - - BuildFlags.hs:90:0: - warning: #warning Building without Database support - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Configurators/Upgrade.hs -o /tmp/ghc9832_0/ghc_95.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/Upgrade.hs -o /tmp/ghc9832_0/ghc_96.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/DeleteRemote.hs -o /tmp/ghc9832_0/ghc_97.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Git/Remote/Remove.hs -o /tmp/ghc9832_0/ghc_98.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Configurators/Edit.hs -o /tmp/ghc9832_0/ghc_99.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Configurators/IA.hs -o /tmp/ghc9832_0/ghc_100.hscpp - *** C pre-processor: - /usr/bin/gcc -E -undef -traditional -DWITH_CLIBS -DWITH_ASSISTANT -DWITH_KQUEUE -DWITH_WEBAPP -DWITH_WEBAPP_SECURE -include dist/build/autogen/cabal_macros.h -I dist/build/git-annex/git-annex-tmp -I dist/build/git-annex/git-annex-tmp -I dist/build/autogen -I dist/build/git-annex/git-annex-tmp -I Utility -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/unix-compat-0.4.1.4-DeAF5HEzYMu4CPLnbGbHUz/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/bloomfilter-2.0.1.0-F2y5dJFu1WQLGpoWigZrGn/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/vector-0.11.0.0-A9qWf1eecPQGJD12EBZIxF/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/primitive-0.6.1.0-5Jnw7oEuYtM9dmKXelGXVb/include -I /usr/local/lib/ghc/old-time-1.1.0.3/include -I /usr/local/lib/ghc/proce_FLTz0SLwyG6LJUpZ52HjkU/include -I /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/lib/x86_64-openbsd-ghc-7.10.2/network-2.5.0.0-1vMzFxK9QUUCF53bUPP2fd/include -I /usr/local/lib/ghc/direc_KowvXytSqazBcvN7MGpFtg/include -I /usr/local/lib/ghc/unix_A3WgcI5QiHK4PDo4jSYdwQ/include -I /usr/local/lib/ghc/bytes_6elQVSg5cWdFrvRnfxTUrH/include -I /usr/local/lib/ghc/time_AXTdBF9VRQoBOqJT6qtmVH/include -I /usr/local/include -I /usr/local/lib/ghc/base_GDytRqRVSUX7zckgKqJjgw/include -I /usr/local/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I /usr/local/lib/ghc/include '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc/include/ghcversion.h '-Dopenbsd_BUILD_OS=1' '-Dx86_64_BUILD_ARCH=1' '-Dopenbsd_HOST_OS=1' '-Dx86_64_HOST_ARCH=1' '-D__GLASGOW_HASKELL_TH__=YES' -U__PIC__ -D__PIC__ '-D__SSE__=1' '-D__SSE2__=1' -x assembler-with-cpp ./Assistant/WebApp/Configurators/AWS.hs -o /tmp/ghc9832_0/ghc_101.hscpp - - Assistant/WebApp/Configurators/AWS.hs:79:0: - error: missing binary operator before token "(" - *** Deleting temp files: - Deleting: /tmp/ghc9832_0/ghc_101.hscpp /tmp/ghc9832_0/ghc_100.hscpp /tmp/ghc9832_0/ghc_99.hscpp /tmp/ghc9832_0/ghc_98.hscpp /tmp/ghc9832_0/ghc_97.hscpp /tmp/ghc9832_0/ghc_96.hscpp /tmp/ghc9832_0/ghc_95.hscpp /tmp/ghc9832_0/ghc_94.hscpp /tmp/ghc9832_0/ghc_93.hscpp /tmp/ghc9832_0/ghc_92.hscpp /tmp/ghc9832_0/ghc_91.hscpp /tmp/ghc9832_0/ghc_90.hscpp /tmp/ghc9832_0/ghc_89.hscpp /tmp/ghc9832_0/ghc_88.hscpp /tmp/ghc9832_0/ghc_87.hscpp /tmp/ghc9832_0/ghc_86.hscpp /tmp/ghc9832_0/ghc_85.hscpp /tmp/ghc9832_0/ghc_84.hscpp /tmp/ghc9832_0/ghc_83.hscpp /tmp/ghc9832_0/ghc_82.hscpp /tmp/ghc9832_0/ghc_81.hscpp /tmp/ghc9832_0/ghc_80.hscpp /tmp/ghc9832_0/ghc_79.hscpp /tmp/ghc9832_0/ghc_78.hscpp /tmp/ghc9832_0/ghc_77.hscpp /tmp/ghc9832_0/ghc_76.hscpp /tmp/ghc9832_0/ghc_75.hscpp /tmp/ghc9832_0/ghc_74.hscpp /tmp/ghc9832_0/ghc_73.hscpp /tmp/ghc9832_0/ghc_72.hscpp /tmp/ghc9832_0/ghc_71.hscpp /tmp/ghc9832_0/ghc_70.hscpp /tmp/ghc9832_0/ghc_69.hscpp /tmp/ghc9832_0/ghc_68.hscpp /tmp/ghc9832_0/ghc_67.hscpp /tmp/ghc9832_0/ghc_66.hscpp /tmp/ghc9832_0/ghc_65.hscpp /tmp/ghc9832_0/ghc_64.hscpp /tmp/ghc9832_0/ghc_63.hscpp /tmp/ghc9832_0/ghc_62.hscpp /tmp/ghc9832_0/ghc_61.hscpp /tmp/ghc9832_0/ghc_60.hscpp /tmp/ghc9832_0/ghc_59.hscpp /tmp/ghc9832_0/ghc_58.hscpp /tmp/ghc9832_0/ghc_57.hscpp /tmp/ghc9832_0/ghc_56.hscpp /tmp/ghc9832_0/ghc_55.hscpp /tmp/ghc9832_0/ghc_54.hscpp /tmp/ghc9832_0/ghc_53.hscpp /tmp/ghc9832_0/ghc_52.hscpp /tmp/ghc9832_0/ghc_51.hscpp /tmp/ghc9832_0/ghc_50.hscpp /tmp/ghc9832_0/ghc_49.hscpp /tmp/ghc9832_0/ghc_48.hscpp /tmp/ghc9832_0/ghc_47.hscpp /tmp/ghc9832_0/ghc_46.hscpp /tmp/ghc9832_0/ghc_45.hscpp /tmp/ghc9832_0/ghc_44.hscpp /tmp/ghc9832_0/ghc_43.hscpp /tmp/ghc9832_0/ghc_42.hscpp /tmp/ghc9832_0/ghc_41.hscpp /tmp/ghc9832_0/ghc_40.hscpp /tmp/ghc9832_0/ghc_39.hscpp /tmp/ghc9832_0/ghc_38.hscpp /tmp/ghc9832_0/ghc_37.hscpp /tmp/ghc9832_0/ghc_36.hscpp /tmp/ghc9832_0/ghc_35.hscpp /tmp/ghc9832_0/ghc_34.hscpp /tmp/ghc9832_0/ghc_33.hscpp /tmp/ghc9832_0/ghc_32.hscpp /tmp/ghc9832_0/ghc_31.hscpp /tmp/ghc9832_0/ghc_30.hscpp /tmp/ghc9832_0/ghc_29.hscpp /tmp/ghc9832_0/ghc_28.hscpp /tmp/ghc9832_0/ghc_27.hscpp /tmp/ghc9832_0/ghc_26.hscpp /tmp/ghc9832_0/ghc_25.hscpp /tmp/ghc9832_0/ghc_24.hscpp /tmp/ghc9832_0/ghc_23.hscpp /tmp/ghc9832_0/ghc_22.hscpp /tmp/ghc9832_0/ghc_21.hscpp /tmp/ghc9832_0/ghc_20.hscpp /tmp/ghc9832_0/ghc_19.hscpp /tmp/ghc9832_0/ghc_18.hscpp /tmp/ghc9832_0/ghc_17.hscpp /tmp/ghc9832_0/ghc_16.hscpp /tmp/ghc9832_0/ghc_15.hscpp /tmp/ghc9832_0/ghc_14.hscpp /tmp/ghc9832_0/ghc_13.hscpp /tmp/ghc9832_0/ghc_12.hscpp /tmp/ghc9832_0/ghc_11.hscpp /tmp/ghc9832_0/ghc_10.hscpp /tmp/ghc9832_0/ghc_9.hscpp /tmp/ghc9832_0/ghc_8.hscpp /tmp/ghc9832_0/ghc_7.hscpp /tmp/ghc9832_0/ghc_6.hscpp /tmp/ghc9832_0/ghc_5.hscpp /tmp/ghc9832_0/ghc_4.hscpp /tmp/ghc9832_0/ghc_3.hscpp /tmp/ghc9832_0/ghc_2.hscpp /tmp/ghc9832_0/ghc_1.hscpp - Warning: deleting non-existent /tmp/ghc9832_0/ghc_101.hscpp - *** Deleting temp dirs: - Deleting: /tmp/ghc9832_0 - /usr/local/bin/ghc returned ExitFailure 1 - -"""]] - -### 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) - -Building without Assistant and Webapps flags work. - -> Fixed building without S3. [[done]] --[[Joey]] diff --git a/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__/comment_1_9ff4036e726bf5eda8150ee167b1228b._comment b/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__/comment_1_9ff4036e726bf5eda8150ee167b1228b._comment deleted file mode 100644 index 6c2cbb417..000000000 --- a/doc/bugs/openbsd_-_Assistant__47__WebApp__47__Configurators__47__AWS.hs__58__79__58__0__58___-_error__58___missing_binary_operator_before_token___34____40____34__/comment_1_9ff4036e726bf5eda8150ee167b1228b._comment +++ /dev/null @@ -1,25 +0,0 @@ -[[!comment format=mdwn - username="jirib@503223f0610c6c66f4e6dc738a5a0b2648c290b1" - nickname="jirib" - subject="iiuc assistant depends on s3" - date="2015-10-02T11:11:13Z" - content=""" -iiuc assistant depends on s3 ?? - - -[[!format sh \"\"\" ---- /home/jirib/tmp/sandbox/haskell/git-annex-5.20150930/git-annex.cabal Fri Oct 2 00:53:38 2015 -+++ /tmp/git-annex.cabal Fri Oct 2 12:58:15 2015 -@@ -186,7 +186,8 @@ Executable git-annex - CPP-Options: -DWITH_WEBDAV - - if flag(Assistant) && ! os(solaris) -- CPP-Options: -DWITH_ASSISTANT -+ Build-Depends: conduit, conduit-extra, aws (>= 0.9.2), http-client -+ CPP-Options: -DWITH_ASSISTANT -DWITH_S3 - - if flag(Assistant) - if os(linux) && flag(Inotify) - -\"\"\"]] -"""]] diff --git a/doc/bugs/pathspec_magic_not_supported_by_this_command__58_____39__literal__39__.mdwn b/doc/bugs/pathspec_magic_not_supported_by_this_command__58_____39__literal__39__.mdwn deleted file mode 100644 index d0de521a0..000000000 --- a/doc/bugs/pathspec_magic_not_supported_by_this_command__58_____39__literal__39__.mdwn +++ /dev/null @@ -1,104 +0,0 @@ -### Please describe the problem. - -I have some paths containing swedish characters (åäö ÅÄÖ). -Some paths also contains the character "@". -I use git annex assistant in autostart mode on my Documents folder. - -I get the following errors in the log file: - -[[!format sh """ -fd:37: commitBuffer: invalid argument (invalid character) -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr������nsytem������te/MMD_Config/SITE/LegacyNT/mmd/config/Dataintag/Fil-intag/OLDIB/SurfaceWaterTemperature.ini: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal' -fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'' -"""]] - -I also notice a lot of zombie git processes in the ps list. - -### What steps will reproduce the problem? - -Upgrade to Version: 5.20150406-gb2814bc -Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA - -Pre compiled tar.gz - -### What version of git-annex are you using? On what operating system? - -Version: 5.20150406-gb2814bc - -Arch linux - -[daniel@wintermute Documents]$ uname -a -Linux wintermute 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux - - -### Please provide any additional information below. - -If I downgrade to a previous version ie. git-annex.linux.5.20150317 the described problem is gone. - -I tried to remove the character "@" from my paths, but it didn't help. - -Looking at the log file below, it doesn't seem to have anything to do with my swedish characters. - - -[[!format sh """ -[2015-04-07 22:24:14 CEST] main: starting assistant version 5.20150406-gb2814bc -[2015-04-07 22:24:14 CEST] TransferScanner: Syncing with xxxxxxx.xxxxxxx.xxx_wintermute_Documents -p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory -(scanning...) [2015-04-07 22:24:15 CEST] Watcher: Performing startup scan -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal' - -git cat-file EOF: user error -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' -fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal' - -"""]] - -> I've fixed the pathspec magic problem. [[done]] -> -> Seems like you could possibly have a separate problem WRT the "commitBuffer: -> invalid argument". When using the older version of git-annex, did you -> get that in the log at all? -> -> OTOH, the -> "@Projects/archive/20140515_METOCC_Gr������nsytem������te" -> weirdness in the log could be where the problem chars are coming from -> too, in which case it was somehow caused by the pathspec magic problem. -> -> I was able to reproduce the pathspec magic problem, but not the encoding -> looking problem, even when using swedish chars in filenames. -> -> --[[Joey]] - ->> I tried an older version of git-annex on the same repository, and could not find any "commitBuffer: ->> invalid argument" in the log. ->> ->> I would like to take the chance to thank you for the incredible work you are doing with this software/tool! It's an amazing effort! ->> ->> -Daniel - diff --git a/doc/bugs/preferred_content_and_deduplication.mdwn b/doc/bugs/preferred_content_and_deduplication.mdwn deleted file mode 100644 index fbd4aad7a..000000000 --- a/doc/bugs/preferred_content_and_deduplication.mdwn +++ /dev/null @@ -1,103 +0,0 @@ -### Please describe the problem. - -When having separate links to the same content, one wanted and one unwanted by the preferred content expression, git annex behaves suboptimally. - -### What steps will reproduce the problem? - -* Set up an annex repo with two identical files "f1" and "f2" -* Clone this repo to an other location. -* In the main repo set "git annex wanted . anything" -* In the second repo set "git annex wanted . 'include=f1 and exclude=f2' -* Try "git annex sync --content" in the second repo. - -``` -$ git annex sync --content -commit -On branch master -nothing to commit, working tree clean -ok -pull origin -ok -get f1 (from origin...) (checksum...) ok -drop f2 ok -pull origin -ok -(recording state in git...) -push origin -Counting objects: 10, done. -Delta compression using up to 2 threads. -Compressing objects: 100% (8/8), done. -Writing objects: 100% (10/10), 892 bytes | 0 bytes/s, done. -Total 10 (delta 3), reused 0 (delta 0) -To /home/lenard/Documents/annex/test/r1 - 98340af..ebb8a8b git-annex -> synced/git-annex -ok -``` - -So it gets f1 just to drop it again (as f2) in the same command. It could be a real issue if it would mean downloading large files. - -In direct mode something entirely different happens: - -``` -$ git annex sync --content -commit ok -pull origin -ok -get f1 (from origin...) (checksum...) ok -pull origin -ok -(recording state in git...) -push origin -Counting objects: 5, done. -Delta compression using up to 2 threads. -Compressing objects: 100% (4/4), done. -Writing objects: 100% (5/5), 450 bytes | 0 bytes/s, done. -Total 5 (delta 2), reused 0 (delta 0) -To /home/lenard/Documents/annex/test/r1 - 3666d0f..698c683 git-annex -> synced/git-annex -ok -$ ls -l -total 0 --rw-r--r-- 1 lenard lenard 0 Sep 6 10:44 f1 --rw-r--r-- 1 lenard lenard 0 Sep 6 10:44 f2 -``` - -Both files are here, even though f2 is not preferred. Strangely only f1 gets downloaded, it's at least better than downloading the file twice. - -### Expected behavior - -* No unnecessary downloads just for dropping the same content -* Consistent behavior between direct and indirect modes (but direct mode being deprecated maybe this is a non-issue?) -* The order of 'get --auto' and 'drop --auto' should be insignificant. - -As for what content would be actually preserved for deduplicated content? Preferred content expressions should be evaluated for keys and not for file paths. This would change the semantics somewhat, so 'include' would mean 'available at' and exclude would mean 'not available at'. So the expression 'include=f1 and exclude=f2' would semantically mean that '(key of f1 and f2) is available at f1 and not available at f2' and it would evaluate as false, so the content would not be wanted. - -### Workaround - -Don't use 'include' and 'exclude' in preferred content expressions (and 'standard' in many cases). Use metadata instead, metadata are bound to keys and not file paths (except location fields?). - -### What version of git-annex are you using? On what operating system? - -``` -git-annex version: 6.20160808 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 3 4 5 -operating system: linux x86_64 -$ uname -a -Linux lenard-hp 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64 GNU/Linux -``` - - -### 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) - -I'm just trying out git-annex and I like it so far. I'm using it to keep my personal photos on my home server. - -> There's already a bug report open about this: -> [[bugs/indeterminite_preferred_content_state_for_duplicated_file]]. -> -> Closing as a duplicate, but thanks for a well-researched bug report. -> [[done]] --[[Joey]] diff --git a/doc/bugs/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn b/doc/bugs/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn deleted file mode 100644 index 41e573dda..000000000 --- a/doc/bugs/prematurely___40__can__39__t_check_offline__41___marks_remote_as_annex-ignore.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -I have cloned via http and then went offline... decided to get a file, annex immediately tried to fetch it from origin which it couldn't have access to atm and marked it as annex-ignore. IMHO it is a bit premature action, and annex should mark a remote as ignore only if it managed to reach the remote location and discovered that it has no annex there, not on a mere connectivity fluke - - -### What version of git-annex are you using? On what operating system? - -6.20160425+gitgffe2ea2-1~ndall+1 - -### Please provide any additional information below. - -[[!format sh """ -$> git annex get cond001.txt -(merging origin/git-annex into git-annex...) -(recording state in git...) -get cond001.txt - Remote origin not usable by git-annex; setting annex-ignore -(not available) - Try making some of these repositories available: - 899f0347-0888-48ef-91b6-bac213ca8cef -- datalad-archives - c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001 -failed -(recording state in git...) -git-annex: get: 1 failed -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/problems_with_android_and_xmpp.mdwn b/doc/bugs/problems_with_android_and_xmpp.mdwn deleted file mode 100644 index 73ceab7b3..000000000 --- a/doc/bugs/problems_with_android_and_xmpp.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -### Please describe the problem. -When trying to sync my android phone with my linux laptop using the git annex assistant and XMPP no files are transferred. - -### What steps will reproduce the problem? -1) setup git annex via webapp on laptop: - -* local annex - -* remote annex via ssh with shared encryption (tried two different servers, one with and one without git-annex installed) - -* share with my devices using jabber.me account - -2) setup git annex via webapp on android: - -* local annex in /sdcard/annex (fuse filesystem without symlink support) - -* share with my devices using jabber.me account - -* ssh remote is automatically added via XMPP - -3) add files to annex on linux, they get uploaded to the ssh remote - -4) wait forever for any files from linux to download to phone - -5) add files to annex on phone, they get uploaded to the ssh remote - -4) wait forever for any files from phone to download to linux - -### What version of git-annex are you using? On what operating system? -Ubunut Linux 12.04 with git-annex version: - -* 5.20140127.1 (from PPA) - -Android 4.2 (rooted) tried with git-annex versions: - -* 5.20140209 (from http://downloads.kitenet.net/git-annex/android/current/4.0/) - -* 5.20140211-g556cfeb (from autobuilds) - -### Please provide any additional information below. -full logs: - -(these do not show the uploads to the ssh remote, because I restarted to get clean and short logs, but the files are on the server and can be dropped and restored on the linux side manually) - -* linux: <http://pastebin.ca/2639948> - -* android: <http://pastebin.ca/2639952> - -most interesting parts: -[[!format sh """ -# -# linux: -# - -[2014-02-13 13:11:27 CET] XMPPClient: Pairing with dorian in progress -[2014-02-13 13:11:28 CET] XMPPSendPack: Syncing with dorian -To xmpp::dorian@jabber.me - * [new branch] git-annex -> refs/synced/4ce7576f-6f02-4657-bab5-2f4c4a564ee7/ZG9yaWFuQGphYmJlci5tZQ==/git-annex - * [new branch] annex/direct/master -> refs/synced/4ce7576f-6f02-4657-bab5-2f4c4a564ee7/ZG9yaWFuQGphYmJlci5tZQ==/annex/direct/master -[2014-02-13 13:11:29 CET] XMPPSendPack: Syncing with dorian -Everything up-to-date -[2014-02-13 13:12:21 CET] XMPPSendPack: Syncing with dorian -Everything up-to-date -[2014-02-13 13:12:21 CET] XMPPSendPack: Syncing with dorian -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. - -# -# android: -# -[2014-02-13 13:16:25 CET] XMPPClient: sending: Pushing "d29" (ReceivePackOutput 2 "<elided>") -[2014-02-13 13:16:25 CET] XMPPClient: to client: d6/tigase-14134 -[2014-02-13 13:18:22 CET] XMPPClient: received: ["Unknown message"] -[2014-02-13 13:18:25 CET] XMPPReceivePack: timeout waiting for git send-pack output via XMPP -fatal: The remote end hung up unexpectedly -[2014-02-13 13:18:25 CET] XMPPReceivePack: finished running push Pushing "d29" (StartingPush (UUID "4ce7576f-6f02-4657-bab5-2f4c4a564ee7")) True -[2014-02-13 13:18:25 CET] XMPPClient: sending: Pushing "d29" (ReceivePackDone (ExitFailure 128)) -[2014-02-13 13:18:25 CET] XMPPClient: to client: d6/tigase-14134 - -"""]] - -> [[done]]; xmpp support has been removed --[[Joey]] diff --git a/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment b/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment deleted file mode 100644 index 945a59021..000000000 --- a/doc/bugs/problems_with_android_and_xmpp/comment_1_dd56eb74660a606c7db54861ec745cc6._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk" - nickname="Dorian" - subject="further information" - date="2014-02-13T13:33:49Z" - content=""" -I just tried moving the annex on the android phone to a different location, because I wasn't sure how git annex handles the /sdcard's fuse file system without symlinks... -So with the annex on the /data mount using ext I got a little further (and discovered a different problem <https://git-annex.branchable.com/bugs/problems_with_android_and_gpg/>). - - -"""]] diff --git a/doc/bugs/problems_with_android_and_xmpp/comment_2_ae4554fadfc3ea1913a36aa535815cfb._comment b/doc/bugs/problems_with_android_and_xmpp/comment_2_ae4554fadfc3ea1913a36aa535815cfb._comment deleted file mode 100644 index 48f945d85..000000000 --- a/doc/bugs/problems_with_android_and_xmpp/comment_2_ae4554fadfc3ea1913a36aa535815cfb._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.146" - subject="comment 2" - date="2014-02-26T18:52:17Z" - content=""" -I don't see any indications that this problem is specific to Android. - -Relying on git push over XMPP is known to be somewhat fragile, and some XMPP servers are known to do things with the XMPP protcol that make it impossible to reliably do git push over it. [[design/assistant/xmpp]] discusses these problems. Since this seems a basically intractable problem to solve, git-annex will be moving away from XMPP as soon as something better is available. (eg [[design/assistant/telehash]]) - -The best way to use XMPP currently is as a simple signaling mechanism to tell when a push has been made to a git repository. Your ssh server seems to have an encrypted rsync repository on it, so no git repository. If you can put up a git repository someplace both the android and linux machine can access, I think that you'll find it greatly improves the reliability of the syncing. -"""]] diff --git a/doc/bugs/problems_with_android_and_xmpp/comment_3_128702a7974bd00337c3304e49a74f0b._comment b/doc/bugs/problems_with_android_and_xmpp/comment_3_128702a7974bd00337c3304e49a74f0b._comment deleted file mode 100644 index 29839cd50..000000000 --- a/doc/bugs/problems_with_android_and_xmpp/comment_3_128702a7974bd00337c3304e49a74f0b._comment +++ /dev/null @@ -1,23 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm78jq1Uo-ZbyOPG3diJUWVvEiM0kyAcvk" - nickname="Dorian" - subject="comment 3" - date="2014-03-03T14:01:10Z" - content=""" -You're right, with an unencrypted git repo in between it works. -I was hoping to be able to avoid that, though. - -My very first try was actually to switch XMPP servers, because I thought they might be the problem. But after trying both servers you mentioned in the assistant and on the instruction pages (Google and jabber.me) I figured it should at least work with one of them... - -So if XMPP can actually only be used as a simple signaling mechanism, this should be mentioned explicitly in the \"remote sharing\" and \"share with a friend\" walkthroughs. -After reading/watching them I was under the impression, that after setting up XMPP, you can use any cloud storage to exchange files. -But if I now understand correctly this cloud storage needs to have a full git repo, not only the encrypted files. -And for Android you cannot use a gcrypt remote, so only unencrypted git repos are possible, making any public cloud service unfeasible. - -Is my conclusion correct, that this leaves only one option when sharing with Android? -1) unencrypted git repo on trusted/private special remote - -Or am I missing something? - -Thanks again for this! -"""]] diff --git a/doc/bugs/put_gpg_last_in_OSX_dmg_PATH.mdwn b/doc/bugs/put_gpg_last_in_OSX_dmg_PATH.mdwn deleted file mode 100644 index dfaec26f1..000000000 --- a/doc/bugs/put_gpg_last_in_OSX_dmg_PATH.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -git-annex bundles gpg on OSX, but this bundled one is not integrated with -gpg-agent. So, if gpg is installed system-wide, it's probably better to use -that one (barring any versioning issues). - -A solution might be to move the gpg binary to a different directory and put -it at the end of PATH, not the front. So system one is used if available. - -This should also be considered for the linux standalone builds. - -> [[done]] for both OSX and linux. --[[Joey]] diff --git a/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__.mdwn b/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__.mdwn deleted file mode 100644 index 6f91ddbf5..000000000 --- a/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!metatitle="testremote of external special remote fails with 'Cannot run git-annex-remote-!dne!'"]] - -### Please describe the problem. - -When git-annex has not recently used a remote, there appears to be a race condition where sometimes it will fail with "git-annex: Cannot run git-annex-remote-!dne! -- Make sure it's in your PATH and is executable." - -### What steps will reproduce the problem? - -This test script will trigger it: https://gitlab.com/DanielDent/git-annex-remote-rclone/blob/demo-race-condition/.gitlab-ci.yml -Output: https://gitlab.com/DanielDent/git-annex-remote-rclone/builds/2167279 - -This test script works: https://gitlab.com/DanielDent/git-annex-remote-rclone/blob/demo-race-condition-2/.gitlab-ci.yml - -But the reason it works is because it's using "git-annex testremote GA-rclone-CI --fast || git-annex testremote GA-rclone-CI --fast" - it fails the first time, and then works the second time. -Output: https://gitlab.com/DanielDent/git-annex-remote-rclone/builds/2167316 - -This test script doesn't trigger it: https://gitlab.com/DanielDent/git-annex-remote-rclone/blob/master/.gitlab-ci.yml -Output: https://gitlab.com/DanielDent/git-annex-remote-rclone/builds/2166902 - -The 'git-annex copy test --to GA-rclone-CI' line prior to the 'testremote' invocation seems to warm caches and avoids having the bug trigger. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__/comment_1_2960102ff86d8b0304d6fd8b83e34ba1._comment b/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__/comment_1_2960102ff86d8b0304d6fd8b83e34ba1._comment deleted file mode 100644 index 8b714e851..000000000 --- a/doc/bugs/race_condition_with___39____39__git-annex__58___Cannot_run_git-annex-remote-__33__dne__33___--_Make_sure_it__39__s_in_your_PATH_and_is_executable.__34__/comment_1_2960102ff86d8b0304d6fd8b83e34ba1._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-05T19:58:41Z" - content=""" -AFAICS this can only affect `git annex testremote` and not other commands; -to test behavior when the remote is not accessible, it uses -mkUnavailable which substitutes "!dne!" for various values. - -In the case of an external special remote, this causes it to run -git-annex-remote-!dne! which is intentially not in the PATH. So, -testremote is testing the behavior when the external special remote -program is missing. - -The bug is that in the remote warmup process it tries to run -git-annex-remote-!dne! in order to query it for GETCOST, and this fails. - -It's not a race condition; it just fails the first time, and works -the second time (since it has gotten the cost cached then). -"""]] diff --git a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist.mdwn b/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist.mdwn deleted file mode 100644 index 9421dc66d..000000000 --- a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist.mdwn +++ /dev/null @@ -1,103 +0,0 @@ -### Please describe the problem. - -When adding a list of files, where some exist and some don't, annex claims to add some of the files until it encounters the first missing file. Then it bails out, leaving files hashed but not added. - -### What steps will reproduce the problem? - -Create a file, ask annex to add the file and a non-existant file - -Expected and historic behavior: annex adds the file - -Actual behavior: annex hashes but does not add the file - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20150420-gb0ebb23 -standalone linux amd64 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$ git annex version -git-annex version: 5.20150420-gb0ebb23 -[ . . . ] - -$ git init asdf -Initialized empty Git repository in /tmp/asdf/.git/ - -$ cd asdf - -$ git annex init -init ok -(recording state in git...) - -$ touch asdf - -$ git add asdf qwer -fatal: pathspec 'qwer' did not match any files - -$ git annex add asdf qwer -add asdf ok -git-annex: qwer not found - -$ file * | sed -e 's/`.*//' -asdf: symbolic link to - -$ git status -On branch master - -Initial commit - -Untracked files: - (use "git add <file>..." to include in what will be committed) - - asdf - -nothing added to commit but untracked files present (use "git add" to track) - - -# End of transcript or log. -"""]] - -Older version of git-annex: - -[[!format sh """ - -$ git annex version -git-annex version: 5.20140412ubuntu1 -[ . . . ] - -$ git init asdf -Initialized empty Git repository in /tmp/asdf/.git/ - -$ cd asdf - -$ git annex init asdf -init asdf ok -(Recording state in git...) - -$ touch asdf - -$ git annex add asdf qwer -add asdf ok -git-annex: qwer not found -(Recording state in git...) - -$ file * | sed -e 's/`.*//' -asdf: symbolic link to - -$ git status -On branch master - -Initial commit - -Changes to be committed: - (use "git rm --cached <file>..." to unstage) - - new file: asdf -"""]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_1_3e444d500071779bcbfbc781b4756daf._comment b/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_1_3e444d500071779bcbfbc781b4756daf._comment deleted file mode 100644 index 6fc7f84db..000000000 --- a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_1_3e444d500071779bcbfbc781b4756daf._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="clacke" - subject="Inconsistent between batches of files" - date="2015-04-22T12:56:42Z" - content=""" -If you add enough files, annex gets past the first `(Recording state in git...)` and then breaks on only the last portion, so some files are added and some are only hashed: - -[[!format sh \"\"\" -$ touch {10000..20240} 20242 - -$ git annex add {10000..20242} -[ . . . ] -add 20240 ok -(recording state in git...) -add 20242 ok -git-annex: 20241 not found - -$ file 20240 20242 | sed -e 's/`.*//' -20240: symbolic link to -20242: symbolic link to - -$ git status | tail -n 7 - new file: 20240 - -Untracked files: - (use \"git add <file>...\" to include in what will be committed) - - 20242 -\"\"\"]] -"""]] diff --git a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_2_4e2bd0704377c9bdc9fdb06a078fbc62._comment b/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_2_4e2bd0704377c9bdc9fdb06a078fbc62._comment deleted file mode 100644 index 3e77d3a39..000000000 --- a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_2_4e2bd0704377c9bdc9fdb06a078fbc62._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-04-22T20:27:29Z" - content=""" -This behavior could stand to be improved, but it's easy to deal with: Just -git annex add the files again, listing only the ones that actually exist, -and it will proceed where it was interrupted by the error. -"""]] diff --git a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_3_9ea62129cc568b07994b7e3d517a100c._comment b/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_3_9ea62129cc568b07994b7e3d517a100c._comment deleted file mode 100644 index 20de644e9..000000000 --- a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_3_9ea62129cc568b07994b7e3d517a100c._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-04-29T18:03:17Z" - content=""" -Also, I'm not so sure it's a regression, at least back at version -5.20141125 it behaved the same way. -"""]] diff --git a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_4_42481bb2f6f625a9891e59ec97574164._comment b/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_4_42481bb2f6f625a9891e59ec97574164._comment deleted file mode 100644 index 4755498c1..000000000 --- a/doc/bugs/regression__58___behavior_when_files_to_add_do_not_exist/comment_4_42481bb2f6f625a9891e59ec97574164._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-04-30T18:56:31Z" - content=""" -Regression or not, it would be useful if git-annex continued past such -not-existing files to process the rest of the specified files, and only -set the error flag. -"""]] diff --git a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature.mdwn b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature.mdwn deleted file mode 100644 index 206b92410..000000000 --- a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -The latest released version of git-annex (6.20161031) breaks on all platforms that do not have ssh 7.3 installed as it relies on "Include" ssh_config(5) configuration flag that appeared in 7.3p1. The broken platforms include macOS Sierra and Ubuntu 16.04 Xenial (LTS) both include ssh 7.2 - - # Ubuntu 16.04 - $ ssh -V - OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 Mar 2016 - - # macOS - $ ssh -V - OpenSSH_7.2p2, LibreSSL 2.4.1 - -Here is what it looks like: - - $ git annex move --to vir - move Foobar.mkv (checking vir...) .git/annex/ssh.config: line 1: Bad configuration option: include - .git/annex/ssh.config: line 2: Bad configuration option: include - .git/annex/ssh.config: terminating, 2 bad configuration options - (unable to check vir - CallStack (from HasCallStack): - error, called at ./Remote/Helper/Messages.hs:32:15 in main:Remote.Helper.Messages) failed - - - $ cat .git/annex/ssh.config - Include ~/.ssh/config - Include /etc/ssh/ssh_config - ServerAliveInterval 60 - -> This is already fixed in git. [[done]] --[[Joey]] diff --git a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment b/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment deleted file mode 100644 index 566926a32..000000000 --- a/doc/bugs/regression_due_to_usage_of_ssh_7.3___34__include__34___feature/comment_1_45003ab569c4649ca29c07877a83af29._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="palday@91f366b5178879146d2b6e1e53bfa21389ee89a8" - nickname="palday" - avatar="http://cdn.libravatar.org/avatar/077a63af75ddba159980fbf88690f401" - subject="Temporary workaround until the brew formula is updated" - date="2016-11-29T02:17:52Z" - content=""" -The homebrew formula doesn't yet this fix, but you can get around the problem in the meantime by getting a newer SSH via homebrew: - -``` -brew install homebrew/dupes/openssh -``` - -You can then choose to keep that or get rid of it when the formula for git annex is later updated. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior.mdwn b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior.mdwn deleted file mode 100644 index 4c1f0971d..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior.mdwn +++ /dev/null @@ -1,113 +0,0 @@ -### Please describe the problem. -In latest git-annex version for windows (4.2130723), after a fresh clone, git annex sync considers dummy symlinks as recently modified files and commits the content. - -Alternatively, to try and avoid this problem, I tried manually merging branches (git-annex and master) but if I do that, I can't retrieve files anymore. That is, `git annex get .` downloads files but doesn't replace the dummy symlinks (I am guessing the same as `http://git-annex.branchable.com/bugs/windows_port_-_can__39__t_directly_access_files/`. Tell me if this is a different bug, I'll file a new bug report) - - -### What steps will reproduce the problem? -Create a new repository (on windows or on linux), create a file and commit it. - -Clone this repository (on windows), then `git annex init` it. The file is here, containing the path to the real file (like a symlink but the crippled filesystem's version). - -At this point, if you perform `git annex sync`, git-annex thinks the dummy symlink is the new content of the file and commits it. - - -### What version of git-annex are you using? On what operating system? -This problem occurs on git-annex for windows version 4.20130723 (the latest version as of now) although it worked well in version 4.20130709. - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$ mkdir test1 - -$ cd test1 - -$ git init -Initialized empty Git repository in c:/Users/raz/test1/.git/ - -$ git annex init test1 -init test1 - Detected a crippled filesystem. - - Enabling direct mode. - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. -ok -(Recording state in git...) - -$ echo "This is the content of the file" > file.txt - -$ git annex add -add file.txt (checksum...) ok -(Recording state in git...) - -$ git annex sync -commit -ok -git-annex: no branch is checked out - -$ cat file.txt -This is the content of the file - -$ cd .. - -$ git clone test1 test2 -Cloning into 'test2'... -done. - -$ cd test2 - -$ git annex init test2 -init test2 - Detected a crippled filesystem. - - Enabling direct mode. - - Detected a filesystem without fifo support. - - Disabling ssh connection caching. -ok -(Recording state in git...) - -$ cat file.txt # File is only a dummy file, it contains the path to the real file (which doesn't yet exist here, this is expected behavior) -.git/annex/objects/33/43/SHA256E-s32--a50017c6136930a142cfca6ee34b700d96dcf0ba59cf7007c27c2924f80dfa7a.txt/SHA256E-s32--a50017c6136930a142cfca6ee34b700d96dcf0ba59cf7007c27c2924f80dfa7a.txt - -$ git annex sync -(merging origin/git-annex into git-annex...) -(Recording state in git...) -add file.txt (checksum...) ok # ??? The dummy file is added to the index -> shouldn't happen -(Recording state in git...) -commit -(Recording state in git...) -ok -pull origin -ok -push origin -Counting objects: 26, done. -Delta compression using up to 4 threads. -Compressing objects: 100% (14/14), done. -Writing objects: 100% (19/19), 1.78 KiB | 0 bytes/s, done. -Total 19 (delta 2), reused 0 (delta 0) -To c:/Users/Renaud Casenave-Pere/test1 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -ok - -$ git annex whereis # File should be in origin repository, not here -whereis file.txt (1 copy) - e6e1c558-7127-4ffa-a79b-2161b44ec44b -- here (test2) -ok - -$ cat file.txt # The committed content, discarding the real content -.git/annex/objects/33/43/SHA256E-s32--a50017c6136930a142cfca6ee34b700d96dcf0ba59cf7007c27c2924f80dfa7a.txt/SHA256E-s32--a50017c6136930a142cfca6ee34b700d96dcf0ba59cf7007c27c2924f80dfa7a.txt - -# End of transcript or log. -"""]] - -Tell me if you need further information. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_1_1a0b964f93c753838d6ccbdc8f79b39e._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_1_1a0b964f93c753838d6ccbdc8f79b39e._comment deleted file mode 100644 index f3e8ec690..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_1_1a0b964f93c753838d6ccbdc8f79b39e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="re: workaround" - date="2013-07-30T19:17:11Z" - content=""" -The problem with manually merging the branches and not using sync is that the file mappings get out of date. You should be able to correct them by running `git annex fsck` -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_2_d22dcd7f95c5dc1c381c3c746781efce._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_2_d22dcd7f95c5dc1c381c3c746781efce._comment deleted file mode 100644 index 6af5a06a6..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_2_d22dcd7f95c5dc1c381c3c746781efce._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="comment 2" - date="2013-07-30T19:55:04Z" - content=""" -This reversion affects direct mode on FAT, not just on Windows! It was probably caused by commit ecdfa40cbea1ae213ab84913d8f011027967a610 or commit ae341c1a37eecc1724517e3e025d144badb5abfe. Investigating. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_3_a25140eb90f6b24c1a3ca39c901694e2._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_3_a25140eb90f6b24c1a3ca39c901694e2._comment deleted file mode 100644 index b608efdbe..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_3_a25140eb90f6b24c1a3ca39c901694e2._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="comment 3" - date="2013-07-30T20:07:09Z" - content=""" -Yeah, I inverted some logic. This also affects, for example, git-annex on Android. Sigh. Sorry about this. - -I suppose that, if you run into this bug, the best way to fix up after it is to `git-revert -n` the bad commit that sync made. Then run `git annex sync` with the fixed git-annex to commit the reversion. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_4_825e15183008ff7d97a81cacc3f55fb4._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_4_825e15183008ff7d97a81cacc3f55fb4._comment deleted file mode 100644 index 7b503ac9a..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_4_825e15183008ff7d97a81cacc3f55fb4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="fixed" - date="2013-07-30T20:11:19Z" - content=""" -Seems like the test suite should have caught this on Windows. Unfortunately, the part of the test suite that tests sync is commented out due to it not working at all from within the test suite for reasons I don't understand. Pity. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_5_e858fc7c729cd39740354fb12627d556._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_5_e858fc7c729cd39740354fb12627d556._comment deleted file mode 100644 index 9b3aa7c17..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_5_e858fc7c729cd39740354fb12627d556._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.21" - subject="comment 5" - date="2013-07-30T21:12:54Z" - content=""" -All Windows and Android builds have been updated with the bug fixed. - -Test suite fixed to test `git annex sync` on Windows.. although the test suite is still failing for unknown reasons in the autobuilder environment and so does not stop the build. I have added a recommendation to the Windows install page that users run `git annex test` themselves to make sure they have a good build that works on their Windows system. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment deleted file mode 100644 index f1509b395..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_6_9881b0f2dfb0907a60c0da296bc3da3f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawknruiCHUcOh2mmpkh7OFJ4iNfAOOamRVs" - nickname="Renaud" - subject="comment 6" - date="2013-07-31T05:34:33Z" - content=""" -Great, thank you very much! - -I successfully ran the test suite and it's now working fine. -"""]] diff --git a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment b/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment deleted file mode 100644 index 48173bff9..000000000 --- a/doc/bugs/regression_in_direct_mode_on_windows___58___weird___96__git_annex_sync__96___behavior/comment_7_ca017b9d3bafea4cb31448c802f3834e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Remy" - ip="82.94.186.146" - subject="comment 7" - date="2013-07-31T13:55:07Z" - content=""" -I got the same problem with the dummy symlinks while syncing to an annex on an EncFS mount on Ubuntu so I hope the fix doesn't just apply to Windows and Android. -"""]] diff --git a/doc/bugs/remote_repo_marked_as___34__here__34__.mdwn b/doc/bugs/remote_repo_marked_as___34__here__34__.mdwn deleted file mode 100644 index bb5da1954..000000000 --- a/doc/bugs/remote_repo_marked_as___34__here__34__.mdwn +++ /dev/null @@ -1,38 +0,0 @@ -### Please describe the problem. - -``git annex info`` shows a local repo as "not here" (withou the ``[here]`` tag), and shows a remote repo with the ``[here]`` tag. - -I had to manually edit `.git/config` to set my local repo's UUID to the correct one. - -> Well, git-annex can only display information that you've told it. -> In this case you seem to have done something wrong with UUIDs, and so it -> displayed [here] next to the UUID of the local repo, as it's supposed to. -> There's no bug here I think. [[done]] --[[Joey]] - -### What steps will reproduce the problem? - -I just ``git annex dead`` an old repo, and ``git annex semitrust`` a new repo by the same name as the old repo. - - -### What version of git-annex are you using? On what operating system? - -5.20150731-1build1 - -Lubuntu 15.10 - - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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, lots of luck (need more skill). - -git-annex may need more error catches to prevent a wrong order of commands from corrupting a repo. But still, git annex works great. diff --git a/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn b/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn deleted file mode 100644 index 57a174455..000000000 --- a/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn +++ /dev/null @@ -1,47 +0,0 @@ -### Please describe the problem. - -Originally spotted/reported: https://github.com/datalad/datalad/issues/1020 - -If that is mandatory, then I guess there should be some error message. - -### What steps will reproduce the problem? - -create a remote repo without specifying version, i.e. of version 5 and copy data into it - -### What version of git-annex are you using? On what operating system? - -6.20160923+gitgd1dabb3-1~ndall+1 - -### Please provide any additional information below. - -Output from running http://www.onerussian.com/tmp/v6-push.sh with argument which specifies annex version within remote - -[[!format sh """ - -$> ./v6-push.sh 5 2>&1 | grep '>>>' ->>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat ->>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat - -$> ./v6-push.sh 6 2>&1 | grep '>>>' ->>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat ->>> 123 - -"""]] - - -[[!meta author=yoh]] - -> The data loss bugs are fixed in [[!commit ee309d694161d0f416420db6c4efb834c813351e]]. -> -> I am not sure yet why the keys database lacked an entry for the file; -> perhaps something to do with it being a v6 unlocked file in a v5 -> repository. -> -> Ok.. Seems that cloning to a v5 repository, and then copying/getting -> objects into it, and then upgrading to v6 reproduces the problem with the -> keys database. The inode cache does not get populated for unlocked files -> on upgrade. Also, unlocked files stay as pointer files even when their -> content is present in annex/objects. Fixed the upgrade process to handle -> this case. -> -> [[fixed|done]]] --[[Joey]] diff --git a/doc/bugs/removeDirectoryRecursive.mdwn b/doc/bugs/removeDirectoryRecursive.mdwn deleted file mode 100644 index b1b3630d1..000000000 --- a/doc/bugs/removeDirectoryRecursive.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### Please describe the problem. -Can't remove repositories - -### What steps will reproduce the problem? -In repo view, click Actions and select Delete. Then enter "Yes, please do as I say!" in text field and click Delete this repo. Error! Internal Server Error: git [Param "config",Param "annex.autocommit",Param "false"] failed - -### What version of git-annex are you using? On what operating system? -6.20160114-g6be9ee0 - -Mac OS X - -### Please provide any additional information below. - -I can't enable logging. When I do, I receive a similar error message - -"git [Param "config",Param "annex.diskreserve",Param "1 megabyte"] failed" - -I just downloaded and installed Git Annex. This problem was there from day 1. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) - -> Fixed it to properly delete the repo. [[done]] --[[Joey]] diff --git a/doc/bugs/removeDirectoryRecursive/comment_1_dc8d7f4072833b013e17935b657a9cdd._comment b/doc/bugs/removeDirectoryRecursive/comment_1_dc8d7f4072833b013e17935b657a9cdd._comment deleted file mode 100644 index db96cf35b..000000000 --- a/doc/bugs/removeDirectoryRecursive/comment_1_dc8d7f4072833b013e17935b657a9cdd._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-29T17:59:18Z" - content=""" -Reproduced this. The repository deletion seems to work, except it falls on -the last hurdle, of removing the actual repository itself. This also -prevents the webapp from shutting down properly. - -So, to get out of this state, kill git-annex and delete the directory -yourself. -"""]] diff --git a/doc/bugs/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn b/doc/bugs/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn deleted file mode 100644 index 1fbd3bdaa..000000000 --- a/doc/bugs/reports_success_when_addurl_--batch__a_file_which_is_.gitignore__39__d.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -### Please describe the problem. - -Reports success although file is not added to git, since ignored due to .gitignore - -Although not sure yet if that is annex could actually take care about since probably annex stages those for 'add' command to git so wouldn't know right when addurl is called for a specific file? - -### What steps will reproduce the problem? - -see below - -### What version of git-annex are you using? On what operating system? - -6.20160728+gitg9a2fe62-1~ndall+1 - - -[[!format sh """ - -$> rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; echo "*exclude*" >| .git/info/exclude; git annex init; { echo "http://www.onerussian.com/tmp/1exclude.txt 1exclude.txt"; echo "2nd one" >&2; echo "http://www.onerussian.com/tmp/2.txt 2.txt"\; } | git annex addurl -c annex.largefiles=exclude=*.txt --batch --json --with-files -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) -2nd one -{"command":"addurl","key":null,"file":"1exclude.txt","note":"downloading http://www.onerussian.com/tmp/1exclude.txt ...","note":"non-large file; adding content to git repository","success":true} -{"command":"addurl","key":null,"file":"2.txt;","note":"downloading http://www.onerussian.com/tmp/2.txt ...","key":"SHA256E-s2--53c234e5e8472b6ac51c1ae1cab3fe06fad053beb8ebfd8977b010655bfdd3c3.txt","success":true} -The following paths are ignored by one of your .gitignore files: -1exclude.txt -Use -f if you really want to add them. -git-annex: user error (xargs ["-0","git","--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.largefiles=exclude=*.txt","add","--"] exited 123) -"""]] - -[[!meta author=yoh]] - -> And it leaves the unstaged symlink behind too. -> -> [[fixed|done]] to check ignore status before creating the file. -> --[[Joey]] diff --git a/doc/bugs/rsync_transport__58___username_not_respected.mdwn b/doc/bugs/rsync_transport__58___username_not_respected.mdwn deleted file mode 100644 index 467e67643..000000000 --- a/doc/bugs/rsync_transport__58___username_not_respected.mdwn +++ /dev/null @@ -1,43 +0,0 @@ -### Please describe the problem. - -I created an encrypted rsync remote with a username (user@host). The rsync command issued by git-annex doesn't contain the username. I solved the problem using .ssh/config. - -### What steps will reproduce the problem? - - -[[!format sh """ -# Add remote like that -git-annex initremote encrsync type=rsync rsyncurl=user@xxx.rsync.net:rsync/X keyid=0xXXX -# Sync it -git-annex sync --content - - -# You'll see -$> ps ax | grep rsync -30652 pts/3 S+ 0:00 /home/ganwell/bin/git-annex.linux//lib64/ld-linux-x86-64.so.2 --library-path /home/ganwell/bin/git-annex.linux//etc/ld.so.conf.d:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu/gconv:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu/libc:/home/ganwell/bin/git-annex.linux//usr/lib:/home/ganwell/bin/git-annex.linux//usr/lib/x86_64-linux-gnu:/home/ganwell/bin/git-annex.linux//lib64:/home/ganwell/bin/git-annex.linux//lib/x86_64-linux-gnu: /home/ganwell/bin/git-annex.linux/shimmed/rsync/rsync xxx.rsync.net:rsync/X/9fa/634/'GPGHMACSHA1--X/GPGHMACSHA1--X -"""]] - - - -### What version of git-annex are you using? On what operating system? - -OS: Linux - -Ver: git-annex version: 5.20140210-g1e0a3ad - -Type: prebuilt - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Argh! How did that break? I know it used to work. -> I have fixed it, unfortunately the fix was too late for today's release, -> but it will be available in autobuilds shortly. -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/slash_in_metadata_breaks_field__61____42___view.mdwn b/doc/bugs/slash_in_metadata_breaks_field__61____42___view.mdwn deleted file mode 100644 index e52e2e5f7..000000000 --- a/doc/bugs/slash_in_metadata_breaks_field__61____42___view.mdwn +++ /dev/null @@ -1,42 +0,0 @@ -### Please describe the problem. - -When using the metadata driven view fields values that contain a slash break the view field=* functionality - -### What steps will reproduce the problem? - - $ git annex metadata --set test=a/b file.tex - $ git annex view test=* - view (searching...) - git-annex: fd:13: commitBuffer: invalid argument (invalid character) - failed - git-annex: view: 1 failed - - - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20151218-g5008846 on ArchLinux - - -### Please provide any additional information below. - -To me it seems like this is only occuring during a field=* view. -Everywhere else the field value behaves normally, For example its possible to directly address the field value in a view without issue. - - $ git annex view test=a/b - view (searching...) - Switched to branch 'views/(test=a/b)' - ok - - -I dont have any issues with non latin characters so this doesnt seem related to the locale issues in [https://git-annex.branchable.com/bugs/view_fails_with___34__invalid_character__34__/](https://git-annex.branchable.com/bugs/view_fails_with___34__invalid_character__34__/) - -I was trying out the metadata extraction via libextractor and for the mimetype there often are slashes involved. - - -### 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) - -Apart from this git-annex is working very well for me. I mostly use it as an archive, distributing numerous copies on various hard drives and cloud providers and keeping track of what is where.Its an amazing tool for that. - - -> [[done]] --[[Joey]] diff --git a/doc/bugs/slash_in_metadata_breaks_field__61____42___view/comment_1_249d786ce15ab0c91191987c0bab76ef._comment b/doc/bugs/slash_in_metadata_breaks_field__61____42___view/comment_1_249d786ce15ab0c91191987c0bab76ef._comment deleted file mode 100644 index f6fb82b51..000000000 --- a/doc/bugs/slash_in_metadata_breaks_field__61____42___view/comment_1_249d786ce15ab0c91191987c0bab76ef._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-08T15:52:22Z" - content=""" -I was able to reproduce this problem, but only with LANG=C. It works in a -unicode locale. - -What's torpedoing this is a hack that it uses to handle "/" in a view. - - pseudoSlash :: Char - pseudoSlash = '\8725' -- '∕' /= '/' - -It's necessary that in a view, each viewed metadata component yield exactly one -level of directory hierarchy. Otherwise, it would be impossible to reverse -"a/b/c/file" when viewing on 2 metadata components -- -is that "a/b" and "c" or "a" and "b/c"? - -Which is why I used this cutsey hack, but yeah, it requires working -unicode support. - -Sigh, 2016 and still can't have nice things.. Suppose it'll have to use an -ugly encoding for them instead. - -Update: Can have nice things, just have to encode the characters using the -FileSystemEncoding! -"""]] diff --git a/doc/bugs/ssh__58___unprotected_private_key_file.mdwn b/doc/bugs/ssh__58___unprotected_private_key_file.mdwn deleted file mode 100644 index 207ef76d1..000000000 --- a/doc/bugs/ssh__58___unprotected_private_key_file.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -### Please describe the problem. - -When pairing two machines with git-annex assistant, the assistant kept asking for the ssh password. Checking the git-annex daemon logs, I saw that ssh was refusing to use the key the assistant had created because it was group readable (see below for the log extract). - -### What steps will reproduce the problem? - -The assistant was installed from the ubuntu precise ppa backport on an up-to-date copy of ubuntu precise. -It was started using "git-annex webapp --listen=XYZ". -This was done on two machines on the same network. -Created a repository using the web-app, the same on both machines. -Did a pair request. This initially worked fine, until it got to the point of using ssh, when it started asking for the password many many times. - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20140306 -build flags: Assistant Webapp Pairing S3 WebDAV Inotify DBus XMPP Feeds Quvi TDFA CryptoHash -key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL -remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external -local repository version: 5 -supported repository version: 5 -upgrade supported from repository versions: 0 1 2 4 - -Ubuntu 12.04.4 LTS - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -(started...) Generating public/private rsa key pair. -Your identification has been saved in /tmp/git-annex-keygen.0/key. -Your public key has been saved in /tmp/git-annex-keygen.0/key.pub. -The key fingerprint is: -2b:f4:28:35:72:2c:9e:5b:d3:1d:d1:a1:b7:c7:a5:34 ABC@XYZ -The key's randomart image is: -+--[ RSA 2048]----+ -| . | -| o . | -| o o E .| -| . o + + | -| o * S . . + | -| . B = o . . | -| + = + . | -| + o | -| . | -+-----------------+ -[2014-03-14 13:35:45 GMT] main: Pairing in progress -@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -@ WARNING: UNPROTECTED PRIVATE KEY FILE! @ -@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ -Permissions 0620 for 'ABC/.ssh/git-annex/key.git-annex-XYZ_annex' are too open. -It is required that your private key files are NOT accessible by others. -This private key will be ignored. -bad permissions: ignore key: ABC/.ssh/git-annex/key.git-annex-XYZ_annex -(merging XYZ_annex/git-annex into git-annex...) - -# End of transcript or log. -"""]] - -> [[Fixed|done]]; the code made sure the file did not have any group or -> world read bits, but did not clear write bits. --[[Joey]] 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 deleted file mode 100644 index 20878cb21..000000000 --- a/doc/bugs/ssh___34__Include__34___breaks_user-specified_IgnoreUnknown.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -### 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. - -> How annoying, ssh seems to make it impossible to set this in a way that -> doesn't break some configurations. Oh well, gave up on setting it -> and removed the code to do so. [[done]] --[[Joey]] diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn b/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn deleted file mode 100644 index ca5b86c87..000000000 --- a/doc/bugs/ssh___34__Include__34___feature_broke_Android.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -### Please describe the problem. -https://git-annex.branchable.com/bugs/git_annex_init_failed_due_to_unsupported_ssh_option/ deal with Include not being supported by pre 7.3 by using the 6.4+ IgnoreUnknown directive. - -Unfortunately, the Android apk (which I got from https://downloads.kitenet.net/git-annex/android/current/5.0/git-annex.apk) has (according to ssh -v) OpenSSH_6.0p1. - -I had to edit .git/annex/ssh.config to comment out the three offending lines and then append the contents of ~/.ssh/config to get git-annex working again. - -(This is on a Nexus 10 running stock, though I doubt it matters) - -> Reverted use of this feature for now.[[done]] --[[Joey]] diff --git a/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment b/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment deleted file mode 100644 index 0cf33b8b3..000000000 --- a/doc/bugs/ssh___34__Include__34___feature_broke_Android/comment_1_14818629616e3daeb8293b710298ce31._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-08T21:11:31Z" - content=""" -Indeed, the ssh bundled in the apk is shockingly old by now, and needs to -get updated. -"""]] diff --git a/doc/bugs/stack_build_Setup.hs_dependencies.mdwn b/doc/bugs/stack_build_Setup.hs_dependencies.mdwn deleted file mode 100644 index 8911cef45..000000000 --- a/doc/bugs/stack_build_Setup.hs_dependencies.mdwn +++ /dev/null @@ -1,78 +0,0 @@ -### Please describe the problem. - -`stack build` on a fresh clone of git-annex at e029eb8b fails with - - git-annex-6.20160229: configure - - Utility/FileSystemEncoding.hs:30:18: - Could not find module ‘Data.Hash.MD5’ - Use -v to see a list of the files searched for. - - Utility/FileSystemEncoding.hs:32:8: - Could not find module ‘Data.Bits.Utils’ - Perhaps you meant - Data.BitUtil - Data.Bits.Lens (from lens-4.13@lens_IUJoiaRWYAQ6ieqgqTJZ5D) - Use -v to see a list of the files searched for. - - Utility/FileSystemEncoding.hs:34:8: - Could not find module ‘Data.List.Utils’ - Perhaps you meant - Data.BitUtil - Data.List.Lens (from lens-4.13@lens_IUJoiaRWYAQ6ieqgqTJZ5D) - Data.List.Split (from split-0.2.3@split_CDzOynTh4l8Ahg1HaWUL4Z) - Use -v to see a list of the files searched for. - - Utility/Process.hs:53:8: - Could not find module ‘System.Log.Logger’ - Perhaps you meant - System.Log.FastLogger (from fast-logger-2.4.1@fastl_1adi3bwIxvVE3Gyx2Jy1k0) - Use -v to see a list of the files searched for. - - Utility/SafeCommand.hs:14:8: - Could not find module ‘Data.String.Utils’ - Perhaps you meant - Data.String.UTF8 (from utf8-string-1.0.1.1@utf8s_L8eKHa7Iv9q7FVKUYW6u4b) - Use -v to see a list of the files searched for. - -### What steps will reproduce the problem? - -`stack build` - -### What version of git-annex are you using? On what operating system? - -e029eb8b, OS X 10.10.5. - -### Please provide any additional information below. - -These are apparently dependencies of `Setup.hs`. Adding - - explicit-setup-deps: - "*": true - -to `stack.yaml` [(as described here)](https://github.com/commercialhaskell/stack/blob/a59997d5db963bba403119843340688ee25e2c6f/doc/yaml_configuration.md#explicit-setup-deps) -fixes the error and builds git-annex successfully. - -### 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) - -> I tried enabling this, and it broke build on my i386ancient autobuilder, -> which uses stack 1.0.4.2. Strange build failure -> both building git-annex and also its dependencies (eg, process): - - /usr/bin/ld: cannot find -ltinfo - -> Which seems to be libtinfo, part of the ncurses library. Which is weird, -> AFAIK git-annex does not use ncurses at all. -> -> I tried weakening the setting from `*` to `git-annex: true`, which -> lets the build deps get built, but building git-annex still fails with -> above error. -> -> --[[Joey]] - -> > I've filed a bug on stack about this, -> > <https://github.com/commercialhaskell/stack/issues/2093> --[[Joey]] - -> > > Gone ahead and added it to stack.yaml, despite it causing some build -> > > failures, as it's certianly needed on many systems. [[done]] -> > > --[[Joey]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn deleted file mode 100644 index 58c7d71fc..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -### Please describe the problem. - -Currently if I using standalone annex builds mere 'annex init' immediately rushes to generate .ssh/git-annex-{shell,wrapper} helpers. I would really prefer to keep ~/.ssh untouched by any magic from the tools which presumably unrelated to ssh. Moreover it leads to failures such as - -/usr/lib/git-annex.linux/runshell: 67: /usr/lib/git-annex.linux/runshell: cannot create /.ssh/git-annex-wrapper: Directory nonexistent - -happen if HOME was overridden (e.g. for testing etc) and I have no intent to use annex as an assistant etc. - -Originally described in http://git-annex.branchable.com/devblog/day_155__missing_bits/ as a solution to overcome problems with assistant's server operation from standalone builds. Why those couldn't be installed alongside with git-annex wrapper? (actually there is also git-annex-shell at least in the Debian standalone packages) - - -### What version of git-annex are you using? On what operating system? - -5.20150916+gitg79661ef-1~ndall+1 - -[[!meta author=yoh]] - -Since packaged version suggestively (I think I did check) resolved the issue, marking it as [[done]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_1_a7d3889eb6d3c011e8d9bfa0fa171054._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_1_a7d3889eb6d3c011e8d9bfa0fa171054._comment deleted file mode 100644 index f105f0c9d..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_1_a7d3889eb6d3c011e8d9bfa0fa171054._comment +++ /dev/null @@ -1,48 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-10T15:36:15Z" - content=""" -Well, it's definitely an oversight that it still fails like that when -~/.ssh can't be created. I fixed that earlier for the ~/.ssh/git-annex-shell -creation but missed doing the same for the ~/.ssh/git-annex-wrapper -creation. Now fixed. - ----- - -It might have been better to put these files someplace else like -~/.config/git-annex (although that's only a standard location on Linux and -this is also done on OSX) or ~/.ssh/git-annex/ (which the assistant puts -keys in so I think would be a better choice). Transitioning to a new -location now would require writing them to both locations long enough for -all current git-annex assistant users to upgrade. I don't know how long -that would be. The utility in moving the files down 1 directory level does -not seem worth the disruption. - -I also sympathize with not wanting those when not using the assistant. -But, this is intended for users who are using the standalone builds to get -git-annex installed on a server to use with the assistant. People have no -end of difficulty getting git-annex-shell into PATH (bash actively makes -this exceedingly difficult by refusing to read any config files for -noninteractive shells), and so these files avoid a particularly newbie -class of users struggling with that problem. - -So, the idea is they unpack the tarball somewhere, and run runshell, and -can see git-annex working on the server, and then the assistant magically -can talk to that git-annex server without them needing to worry about how. -This is why runshell is standing in for an installation process. - -Adding another, more explicit installation step for this class of users -is just going to reduce the number who get git-annex installed on servers, -I fear. - ---- - -But, /usr/lib/git-annex.linux/ .. this is the git-annex-standalone.deb -isn't it? Since debs are a much better way to get things into PATH -and get dependencies installed etc, there's certianly no reason for the -runshell in the standalone deb to do this installation. -So, I've fixed that.. - -Enough to close bug? -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_2_05c675213f38fb6762aa26458193ee7d._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_2_05c675213f38fb6762aa26458193ee7d._comment deleted file mode 100644 index 6c692ace8..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_2_05c675213f38fb6762aa26458193ee7d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-11-10T17:24:28Z" - content=""" -great (as for .deb)... but wouldn't it make sense for any other linux (and Debian not from .deb) then to install them under e.g. /usr/local/bin if permissions allow? - -I will leave it up to you to finalize the decision of completeness and close this report ;) (ab)using ~/.ssh indeed sounds like a quick way out but imho somewhat too dirty. Imho some canonical location as per XDG or some other common standard (e.g. ~/.var/git-annex/bin ?) where annex could look for its wrappers would imho be better -- or am I missing some picture of ssh looking for scripts under ~/.ssh? -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_3_031ed90b19c53616797de0ea55546ecf._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_3_031ed90b19c53616797de0ea55546ecf._comment deleted file mode 100644 index c2100a28f..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_3_031ed90b19c53616797de0ea55546ecf._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-11-10T17:44:35Z" - content=""" -I don't think that implicit installation to /usr/local/bin just because -runshell was run as root makes sense, no. If root wants to install -git-annex system-wide they have plenty of good options, but the standalone -tarball is not really one of them. - -Another reason to keep the git-annex-shell wrapper in ~/.ssh is because the -~/.ssh/authorized_keys file that the assistant installs will refer to that -wrapper. So it makes sense to keep all that related stuff together IMHO. -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment deleted file mode 100644 index d14d8c13d..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_4_1b0fcf589429f6b36bf405bf9b1610b5._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 4" - date="2016-04-25T17:21:26Z" - content=""" -ok -- getting back to this issue. What about at least the debian standalone package patching (or option?) annex so it installs them under /usr/bin/ by the package? -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment deleted file mode 100644 index c95d18715..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_5_f427a3ac3e553c73a9ff3c8894d8f6fb._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 5""" - date="2016-04-27T17:14:49Z" - content=""" -There's no reason for git-annex-standalone.deb's git-annex to -set up any of these wrappers, anywhere. That deb installs git-annex onto -the system PATH, so none of these workarounds for it not being installed on -the system path are needed. - -The `GIT_ANNEX_PACKAGE_INSTALL` variable is supposed to prevent that. It's -set by debian/rules, since 5.20151116. -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment deleted file mode 100644 index 6861932e8..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_6_5f897708dd936fc739f714691d4d2aa2._comment +++ /dev/null @@ -1,21 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 6" - date="2016-04-27T17:41:01Z" - content=""" -then I guess it is not fully effective... I have removed the copies I had, and when I started 'git annex webapp' 6.20160425+gitgffe2ea2-1~ndall+1 version recreated them - -[[!format sh \"\"\" - -$> which git-annex -/usr/bin/git-annex - -$> git annex version -git-annex version: 6.20160425+gitgffe2ea2-1~ndall+1 -... - -$> ls -l .ssh/git-annex-* --rwx------ 1 yoh yoh 215 Apr 27 13:38 .ssh/git-annex-shell* --rwx------ 1 yoh yoh 61 Apr 27 13:38 .ssh/git-annex-wrapper* -\"\"\"]] -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment deleted file mode 100644 index 4fe93ee8f..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_7_a9a125d4b494b5e25d7c524b49a696c5._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 7" - date="2016-04-27T17:42:24Z" - content=""" -indeed though seems to not happen merely on 'git annex init' -"""]] diff --git a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment b/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment deleted file mode 100644 index df9201744..000000000 --- a/doc/bugs/standalone_builds_shouldn__39__t_pollute___126____47__.ssh_with_helpers_merely_upon_annex_init/comment_8_f1081a8683286bdf3ccd2d5e47a786f9._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 8""" - date="2016-04-27T17:57:49Z" - content=""" -Yeah, the assistant has a separate code path that writes those wrappers. - -I've made it also honor the GIT_ANNEX_PACKAGE_INSTALL setting. -"""]] diff --git a/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn b/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn deleted file mode 100644 index e0785b30b..000000000 --- a/doc/bugs/strips___95___from_extensions_in_E_backends__63__.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -in my obscure case filename is ds001_R1.1.0_raw.tgz and resultant extension annex takes for the E backend is .0raw.tgz which is formed from .0_raw.tgz with _ removed. IMHO if _ is not expected in the extensions, the target extension then should have been just .tgz. If it does expect/allow for _ in extension -- should have been .0_raw.tgz - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log -$> f=ds001_R1.1.0_raw.tgz; rm -rf /tmp/repo1; mkdir /tmp/repo1; cd /tmp/repo1; git init; git annex init ; echo 123>$f; git annex add --backend MD5E $f; ls -ld $f -Initialized empty Git repository in /tmp/repo1/.git/ -init ok -(recording state in git...) -add ds001_R1.1.0_raw.tgz ok -(recording state in git...) -lrwxrwxrwx 1 yoh yoh 126 May 25 14:27 ds001_R1.1.0_raw.tgz -> .git/annex/objects/g5/jW/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz/MD5E-s4--ba1f2511fc30423bdbb183fe33f3dd0f.0raw.tgz -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment b/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment deleted file mode 100644 index 069dc7fca..000000000 --- a/doc/bugs/strips___95___from_extensions_in_E_backends__63__/comment_1_9a3d0866b5c54f6f5dca59c39960e28f._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-27T17:06:41Z" - content=""" -Non-alphanumerics are stripped. - -This also results in a file "foo.ba________________________r" having -".bar" picked as its extension. - -I think the fix is to filter out over-long "extensions" before stripping -the non-alphanumerics. -"""]] diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2.mdwn b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2.mdwn deleted file mode 100644 index a33550bb3..000000000 --- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2.mdwn +++ /dev/null @@ -1,94 +0,0 @@ -### Please describe the problem. - -subject + what was described in https://git-annex.branchable.com/forum/some_symlinks_left_in_direct_mode/ some time ago I guess - -### What steps will reproduce the problem? - -clone git annex repo, switch immediately to direct mode and observe files being left as dangling symlinks, get some content -- they get into normal files, drop them -- broken symlinks again. I thought (and I believe that it was like that) that in direct mode -- no symlinks to .git/annex regardless of the state (present/absent). - -full example /transcript is below - -### What version of git-annex are you using? On what operating system? - -Debian sid 5.20150710-2 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -$> git clone git://github.com/datalad/testrepo--basic--r1 -Cloning into 'testrepo--basic--r1'... -remote: Counting objects: 23, done. -remote: Total 23 (delta 0), reused 0 (delta 0), pack-reused 23 -Receiving objects: 100% (23/23), done. -Resolving deltas: 100% (3/3), done. -Checking connectivity... done. -2 22606.....................................:Tue 28 Jul 2015 04:11:23 PM EDT:. -hopa:/tmp -$> cd testrepo--basic--r1 -INFO.txt test-annex.dat@ test.dat -2 22607.....................................:Tue 28 Jul 2015 04:11:30 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> ls -l -total 12 --rw------- 1 yoh yoh 53 Jul 28 16:11 INFO.txt -lrwxrwxrwx 1 yoh yoh 186 Jul 28 16:11 test-annex.dat -> .git/annex/objects/zk/71/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat --rw------- 1 yoh yoh 4 Jul 28 16:11 test.dat -2 22608.....................................:Tue 28 Jul 2015 04:11:31 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> git annex direct -(merging origin/git-annex into git-annex...) -(recording state in git...) -commit -(recording state in git...) -On branch master -Your branch is up-to-date with 'origin/master'. -nothing to commit, working directory clean -ok -direct ok -2 22609.....................................:Tue 28 Jul 2015 04:11:36 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> ls -l -total 12 --rw------- 1 yoh yoh 53 Jul 28 16:11 INFO.txt -lrwxrwxrwx 1 yoh yoh 186 Jul 28 16:11 test-annex.dat -> .git/annex/objects/zk/71/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat --rw------- 1 yoh yoh 4 Jul 28 16:11 test.dat -2 22610.....................................:Tue 28 Jul 2015 04:11:38 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> git annex get test-annex.dat -get test-annex.dat (from web...) -/tmp/testrepo--basic--r1/.git/annex/tmp/SHA256E-s4--1 100%[===========================================================================================================================>] 4 --.-KB/s in 0s -ok -(recording state in git...) -2 22611.....................................:Tue 28 Jul 2015 04:11:45 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> ls -lta -total 12 -drwxrwxrwt 126 root root 4020 Jul 28 16:11 ../ -drwx------ 3 yoh yoh 120 Jul 28 16:11 ./ --rw------- 1 yoh yoh 4 Jul 28 16:11 test-annex.dat -drwx------ 9 yoh yoh 300 Jul 28 16:11 .git/ --rw------- 1 yoh yoh 53 Jul 28 16:11 INFO.txt --rw------- 1 yoh yoh 4 Jul 28 16:11 test.dat -2 22612.....................................:Tue 28 Jul 2015 04:11:49 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> git annex drop test-annex.dat -drop test-annex.dat (checking https://raw.githubusercontent.com/datalad/testrepo--basic--r1/master/test.dat...) ok -(recording state in git...) -2 22613.....................................:Tue 28 Jul 2015 04:11:57 PM EDT:. -(git)hopa:/tmp/testrepo--basic--r1[master] -$> ls -l -total 12 --rw------- 1 yoh yoh 53 Jul 28 16:11 INFO.txt -lrwxrwxrwx 1 yoh yoh 186 Jul 28 16:11 test-annex.dat -> .git/annex/objects/zk/71/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat --rw------- 1 yoh yoh 4 Jul 28 16:11 test.dat - - -# End of transcript or log. -"""]] - -> Closing as I think we're in agreement this is the right behavior. -> But, see <http://git-annex.branchable.com/todo/hide_missing_files/>. -> [[done]] --[[Joey]] diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_1_3b6e4bd5ff1d6b35d6a894174e67835b._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_1_3b6e4bd5ff1d6b35d6a894174e67835b._comment deleted file mode 100644 index 3ae4a4d04..000000000 --- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_1_3b6e4bd5ff1d6b35d6a894174e67835b._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 1" - date="2015-07-28T20:20:04Z" - content=""" -d'oh -- I did file this one before! search on subject line wasn't productive though -- still can't find it. But you said that \"This is behaving as it's intended to.\" ... need to run -- will whine a bit more later in detail ;) -"""]] diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_2_29b9762ef3ad0c9e7abf8bf0d4eb6c42._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_2_29b9762ef3ad0c9e7abf8bf0d4eb6c42._comment deleted file mode 100644 index 9c7b25013..000000000 --- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_2_29b9762ef3ad0c9e7abf8bf0d4eb6c42._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="3 modes (at user level of visibility) -> 2 modes" - date="2015-07-28T20:51:02Z" - content=""" -I am now not quite sure why I thought that in direct mode, regardless of OS we had somewhat consistent user experience across OSes: files either had content fetched by annex (thus not empty) or empty files, such as it is now on crippled filesystems. But really we have 3 modes now, depending on underlying files system (and not even user's decision) in direct mode we might have broken symlinks or empty files. Why bother with broken symlinks? just for performance reasons of not needing to rewrite them as empty files? -"""]] diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment deleted file mode 100644 index 3c81b70b5..000000000 --- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_3_9b76d5f67a858ea0170e816b35190aef._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-08-13T20:45:36Z" - content=""" -Broken symlinks are really much preferable to files that don't have the -content the user expects. Anyway, git-annex is just inheriting how git -deals with symlinks on filesystems that don't support them. - -Previous discussion: -<http://git-annex.branchable.com/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode/> -"""]] diff --git a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment b/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment deleted file mode 100644 index d39513e32..000000000 --- a/doc/bugs/symlinks_to_absent_files_remain_upon_switching_to_direct_mode2/comment_4_d40ed7385eb46aa0a9940198e4591c0e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 4" - date="2015-08-19T20:50:08Z" - content=""" -gotcha -- thanks. Sticking to git behavior is indeed preferable. -Cheers! -"""]] diff --git a/doc/bugs/sync_in_adjusted_branch_deleted_recently_added_files.mdwn b/doc/bugs/sync_in_adjusted_branch_deleted_recently_added_files.mdwn deleted file mode 100644 index 6c82fcf82..000000000 --- a/doc/bugs/sync_in_adjusted_branch_deleted_recently_added_files.mdwn +++ /dev/null @@ -1,90 +0,0 @@ -In my `big/git-annex-test-repos/20160830-annex-adjusted.tar.xz.gpg`, -I have a .git/ directory for a repo where `git annex sync` after `git annex add` -apparently committed the files and then fast-forward merged a branch -over top which did not contain the just-added files. - -According to the bug reporter: - -> As mentioned on IRC I switched to master, back to the adjusted -> branch and then did `git add "2016/H* T* und R*"` in the -> meantime after restoring the files from backup, but I have not -> synced/commited the latter yet. I also did `git gc` in the hope -> that it would reduce the size a bit, but to no real success :) -> -> My git-annex is 6.20160720-g9f0428e (standalone build) and git is -> 2.1.4-2.1+deb8u2 from jessie. - -`git reflog` showed: - - 24a8128 HEAD@{3}: merge 24a81287ef63cd064977165b82de56e050c4a576: Fast-forward - 9cdbd4f HEAD@{4}: commit: git-annex in orcus direct - 9cdbd4f Adds the files, 24a8128 deletes them. - -Where 9cdbd4f added the files, but then 24a8128 lost them. - -The way 24a8128 appears in the reflog there is not what I usually see when -running `git annex sync` on an adjusted branch. Possible smoking gun? - -Initial plan: Try to reset the adjusted branch and master back to before 9cdbd4f, -and re-run to try to reproduce this happening. ---[[Joey]] - ----- - -Update: Was able to reproduce bug as follows: - -1. Untar tarball -2. git reset --hard 961bbbf -3. git cherry-pick 9cdbd4f -4. git annex sync - -Output of step #4 is: - - On branch adjusted/master(unlocked) - nothing to commit, working tree clean - ok - merge synced/master (Merging into master...) Already up-to-date. - (Merging into adjusted branch...) - Updating 61bf677..46e18b7 - Fast-forward - (diffstat shows 1 file added, and all files added by commit 9cdbd4f deleted) - -Making changes other than that cherry-pick, like adding or renaming -a file, don't seem to trigger the bug. - -I think that the bug is in Git.Tree.adjustTree, when the -addtreeitems are in a deep subdirectory, it seems to not be adding them -into the tree. This happens in simpler test cases, so something about -this particular tree is breaking the code. - ----- - -Ok, think I found the bug. In Git.Tree.adjustTree, it grafts in the new -tree items, but it can forget that it needed to modify the tree, which -prevents the change from propigating up from the subtree to the root, and -so it gets left out of the reverse adjusted commit. - -I'm committing a fix. - -With the fix, when I git annex sync in felix's tree, the files that -were getting wrongly deleted are added. The commit summary shows -that git thinks those files were renamed: - - rename 2016/xxx xxx und yyy/{ => 2016/xxx xxx und yyy}/zzz/P1230949.JPG (100%) - -This seems wrong. I think this is a separate bug that was hidden -by the other one, it's grafting in files using their whole path, -to a subtree that is itself part way down that path. - ---- - -A simpler case of the both bugs is to have a file like a/b/c/d already -committed and make a commit that adds a/b/x/y, without otherwise modifying -that tree. On an adjusted branch, `git annex sync` makes a commit of a tree -that does not include the new file. It may made a commit on top of it for -the adjusted branch that adds the file back, but the file doesn't reach -the master branch in this scenario. - ---[[Joey]] - -Both bugs fixed now. [[done]] --[[Joey]] diff --git a/doc/bugs/sync_uses_conflicting_names_for_deep_branches.mdwn b/doc/bugs/sync_uses_conflicting_names_for_deep_branches.mdwn deleted file mode 100644 index 439bd55e1..000000000 --- a/doc/bugs/sync_uses_conflicting_names_for_deep_branches.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -`git annex sync` uses a branch named "synced/foo" to sync -changes to branch named "foo", but that same name is used to sync -changes to a branch named "bar/foo". - -Also, the adjusted branch code uses "adjusted/foo(unlocked)" for -both "foo" and "bar/foo". And it fails to push changes back from there to -"bar/foo", instead creating a "foo" branch. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck.mdwn b/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck.mdwn deleted file mode 100644 index 49156e366..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -### Please describe the problem. -I try to fsck my movies repo, but run in to a failure message. Running the same command on another repo on the same computer works (both being run with sudo and the same user.) - -### What steps will reproduce the problem? - $ sudo -u time_machine_carl git annex fsck --incremental-schedule 182d --time-limit 1h - - sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from fscked limit 1": unable to open database file - git-annex: thread blocked indefinitely in an MVar operation - -I guess I might just have created a fsck database using another user and this db is somehow locked? - -### What version of git-annex are you using? On what operating system? - - $ git annex version - git-annex version: 5.20150731-1 - build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA Database - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -It runs on Raspbian Testing - $ uname -a - Linux pi 4.1.6+ #810 PREEMPT Tue Aug 18 15:19:58 BST 2015 armv6l GNU/Linux -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### 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) -Of course, The movie archive seems to be filling up nicely I just have some problems automating the checks. - -> [[done]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck/comment_1_34df6b7f9b96351130e60a5952816cc7._comment b/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck/comment_1_34df6b7f9b96351130e60a5952816cc7._comment deleted file mode 100644 index 7c9c7640a..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_MVar_operation_durin_fsck/comment_1_34df6b7f9b96351130e60a5952816cc7._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-10-12T16:49:11Z" - content=""" -Seems your guess is right: - - joey@darkstar:~/tmp/b4/b>sudo chown root.root -R .git/annex/fsck/4625a6de-d8f5-4036-83a5-6e202ad346da/ - joey@darkstar:~/tmp/b4/b>git annex fsck --incremental-schedule 182d - - sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from fscked limit 1": unable to open database file - git-annex: thread blocked indefinitely in an MVar operation - -So, fix the owner/permissions (or delete .git/annex/fsck) and you should be good to go. - -Cleaned up the error message about the MVar, which is something of a red herring. - -BTW, I double-checked, and core.sharedRepository is honored to set the mode -of the fsck database file, so can be used to share a repo amoung multiple users. -"""]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn b/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn deleted file mode 100644 index eaf79a862..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -relates to having pidlock true - -[[!format sh """ -$> mkdir 123; cd 123; git init; git annex init; git config annex.pidlock true && echo "123" > 123.dat; git annex add 123.dat; git commit -m 'added'; -W: git-annex repositories not (yet) supported in the prompt -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) -add 123.dat ok -(recording state in git...) -[master (root-commit) 9449f1b] added - 1 file changed, 1 insertion(+) - create mode 120000 123.dat - -$> git clone . ../123-clone && git remote add clone ../123-clone && git fetch clone && cd ../123-clone && git config annex.pidlock true && cd - && git annex move --to=clone . -Cloning into '../123-clone'... -done. -From ../123-clone - * [new branch] master -> clone/master -move 123.dat git-annex: thread blocked indefinitely in an STM transaction - -$> echo $? -1 - -$> git annex version -git-annex version: 6.20160226+gitg01f1de0-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput TorrentParser MagicMime Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 - -"""]] - -and it works ok without pidlock enabled - -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_1_0cb6b5d69cc47bfbab8fb5e87e6e2bad._comment b/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_1_0cb6b5d69cc47bfbab8fb5e87e6e2bad._comment deleted file mode 100644 index 7afc0eb30..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_1_0cb6b5d69cc47bfbab8fb5e87e6e2bad._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-01T15:40:12Z" - content=""" -I can reproduce this. But, when I change the origin remote to use ssh, it -works around the problem. -"""]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_2_aa8c82f27965df44e69fd06b34be0ece._comment b/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_2_aa8c82f27965df44e69fd06b34be0ece._comment deleted file mode 100644 index 2c06811d8..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_2_aa8c82f27965df44e69fd06b34be0ece._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-03-01T16:11:37Z" - content=""" -A worse problem with annex.pidlock is that it completly broke checking -whether a key is present in the repository. That could lead to data loss -when eg, moving --to a repo with annex.pidlock set. - -I've fixed that related bug. -"""]] diff --git a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_3_7e6b3ab0beaca49d7d68c9e610c1d147._comment b/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_3_7e6b3ab0beaca49d7d68c9e610c1d147._comment deleted file mode 100644 index becf5a1b3..000000000 --- a/doc/bugs/thread_blocked_indefinitely_in_an_STM_transaction__while_moving_within__a_local_clone/comment_3_7e6b3ab0beaca49d7d68c9e610c1d147._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-03-01T16:21:31Z" - content=""" -Analysis: What's crashing is Utility.LockPool.PidLock.waitLock after a call -to Utility.LockPool.PidLock.tryLock. The former takes an exclusive STM lock -of the pid lock file; the latter takes a shared STM lock. - -Since the pid lock stands in for multiple more fine-grained locks, waitLock -will be called while a lock from tryLock (or a previous waitLock perhaps) -is still open. - -The fix seems as simple as making waitLock take a shared STM lock of the -pid lock file, leaving the exclusive lock for the later, more fine-grained -STM lock checking that's done after taking the pid lock. -"""]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn deleted file mode 100644 index a77ee211d..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -### Please describe the problem. - -As described [elsewhere](http://git-annex.branchable.com/todo/make_addurl_respect_annex.largefiles_option/#comment-817c4d5c215ddc0ec7bc5c4c05dff091) but since that one is closed -- making a dedicated one - -unfortunately addurl doesn't care about large files if --fast (or --relaxed, although that one I guess I can understand ): - -[[!format sh """ - -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git -c annex.largefiles=exclude=*.txt annex addurl --file=test.txt --fast \"http://www.onerussian.com/tmp/banner.png\" -addurl test.txt ok -(recording state in git...) - -$ ls -l test.txt -lrwxrwxrwx 1 yoh yoh 132 Jan 13 18:44 test.txt -> .git/annex/objects/KW/kj/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png - -"""]] - -it does consider largefiles for if addurl without --fast, or --relaxed - -[[!meta author=yoh]] - -> [[done]]; this can't really be done, but I added `git annex -> matchexpression` to allow scripting that checks expressions such as -> annex.largefiles. --[[Joey]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_1_7afce3be7091e7fc27fa0a060456ada2._comment b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_1_7afce3be7091e7fc27fa0a060456ada2._comment deleted file mode 100644 index 9f6bfde49..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_1_7afce3be7091e7fc27fa0a060456ada2._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-15T18:38:53Z" - content=""" -Obviously --relaxed doesn't know the size of the file at all, so it -wouldn't know what to do for "largerthan". - ---fast often knows the file size, but not always. When quvi is used, the -size is not included in the key. When a special remote claims an url, the -size may or may not be known. - -So, annex.largefiles could be supported for --fast but not for --relaxed, -and only for urls not using quvi or some special remotes. -This seems so complicated to document that it's probably not a good idea. -Such complexity makes me start to wonder if I made a mistake by adding this -feature to addurl. - -Also, adding support for this would complicate any later annex.largefiles -settings, like mime type matching, that need to look at the content of the -file. -"""]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_2_3be07637fd8c42a8392b497fe8cdc347._comment b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_2_3be07637fd8c42a8392b497fe8cdc347._comment deleted file mode 100644 index 7dc8abc7f..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_2_3be07637fd8c42a8392b497fe8cdc347._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-01-15T21:27:55Z" - content=""" -would it be possible to get something like - -[[!format sh \"\"\" -git annex evaluate-expression [--size X] [--filename Y] [--mime Z] [--file F] [--repository A and so on] ... EXPRESSION -\"\"\"]] - -which, given the EXPRESSION (as the one for largefiles) would use provided information and if necessary (e.g. size is not provided but needed) consult --file value, and return 0 if condition satisfied, 1 if unsatisfied, 2 if no sufficient information provided (e.g. --file was needed since --size was not provided but used by the condition)? ;-) - -I understand that you are aiming for the most flexible and generic solution. in my case I am aiming for a less generic use-case, e.g. when I still use largefiles for a repository which in general links to the content using --fast (or --relaxed) but where I need to add some files (e.g. *.txt) straight into git. I thought to resort to largefiles handling within git-annex for that instead of creating my own specifications (which files to add to git or to annex based on name and/or size) -"""]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_3_81d6113064962c9770cc3b961326341f._comment b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_3_81d6113064962c9770cc3b961326341f._comment deleted file mode 100644 index af56ba29a..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_3_81d6113064962c9770cc3b961326341f._comment +++ /dev/null @@ -1,34 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-01-25T17:51:25Z" - content=""" -Wait, you can't add a file to git that's not present, so even if addurl did -support largefiles for --fast and --relaxed, all it could do if the file -was not large was error out, because it wouldn't have downloaded the -content to add to git in the first place! - -Now, as to some plumbing to check if an expression matches -some data, it's a good idea. Implementing it without adding a lot of -complexity may be tricky though. In particular something like `limitSize` -can't currently error out, which is important so that matching preferred -content never crashes git-annex.. but it needs to if the size is not provided -in this other use case. - -What I think I could do is add a new data type to MatchInfo, something -like: - - MatchingInfo (Maybe FilePath) (Maybe FileSize) (Maybe Key) - -And then in terminals like `limitSize`, when a MatchingInfo is provided, -have it error out if size is not provided. - -The command-line interface for this would be sufficiently complicated -that it might be best to go with a full json input for batch mode. -User needs to provide the expression, and any/all of filepath, filesize, -key, and in the future perhaps other info (mime type etc). - -Maybe batch mode wouldn't be needed though; the command should not need -to spin up any git helper processes at all to check such an expression and so -should run pretty fast. -"""]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_4_00dfd040f4d8b9f1ed765ee38dbc67b9._comment b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_4_00dfd040f4d8b9f1ed765ee38dbc67b9._comment deleted file mode 100644 index 465da0707..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_4_00dfd040f4d8b9f1ed765ee38dbc67b9._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-01-25T20:15:05Z" - content=""" -Implemented the matchexpression command. - - time for x in $(seq 1 100); do git annex matchexpression "include=*.png and largerthan=100mb" --file=foo.png --size=10mb --debug; done - - real 0m5.167s - user 0m2.688s - sys 0m1.860s - -Don't know if that's fast enough or if it will need further optimisation -or a --batch option.. -"""]] diff --git a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_5_fee83d2df645740841d6662cf543878b._comment b/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_5_fee83d2df645740841d6662cf543878b._comment deleted file mode 100644 index 45051c20c..000000000 --- a/doc/bugs/treatment_of_largefiles_is_not_working_for_addurl_--fast___40__or_--relaxed__41__/comment_5_fee83d2df645740841d6662cf543878b._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 5" - date="2016-01-25T20:23:22Z" - content=""" -Sounds like reasonably fast to me. Let me try adopting it, and then if it would become a bottleneck I would whine ;) -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn deleted file mode 100644 index 6cd90264c..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -### Please describe the problem. -Recent builds of git-annex spew out many lines such as: - - git-annex: unable to decommit memory: Invalid argument - git-annex: unable to decommit memory: Invalid argument - git-annex: unable to decommit memory: Invalid argument - git-annex: unable to decommit memory: Invalid argument - git-annex: unable to decommit memory: Invalid argument - -### What steps will reproduce the problem? -This happens to me syncing any large repository now. - -### What version of git-annex are you using? On what operating system? -git-annex version: 6.20161118-g0a34f08 - -uname -r: 4.4.14-11.pvops.qubes.x86_64 - -/etc/system-release: Fedora release 23 (Twenty Three) - -### Please provide any additional information below. - -I found this: https://ghc.haskell.org/trac/ghc/ticket/12495 - -It looks like this is a problem that occurs only on kernels < 4.5, when ghc is built with a newer glibc, I think. - -### 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) - -Git annex rocks! - -> [[fixed|done]]; fix is confirmed, all linux standalone builds are updated -> (and I pinged Yoh to update the neurodebian standalone build). --[[Joey]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment deleted file mode 100644 index 15dde50f8..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_10_b21a337256c58953e1440317c0c1db80._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 10""" - date="2016-12-19T19:53:11Z" - content=""" -The only way the files could be in lost+found is if the system crashed or -there was a disk error etc. Can't be due to this bug. So, it may be that -this bug did not actually cause any data loss. The screwed up symlinks could -have been caused by a disk error. -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment deleted file mode 100644 index 3fe7af8dd..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_1_b76704adf6b6aa441a35bf9458d3950d._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" - nickname="0xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="Corrupt Links Produced, Significant Data Loss" - date="2016-12-10T12:31:31Z" - content=""" -Additionally, I added a mess of files with this release of git-annex, and of the 200 files added, three of the links produced were corrupt. I'm still searching for where these files have gone to recover the data. - -The files look like this in `ls -l`, they were bup files: - - lrwxrwxrwx 1 user user 338 Jun 17 22:36 bup.git/objects/pack/pack-47b493a3bbbd22200d2b390c277e49ce713243cc.pack -> *??:?;J????????? - lrwxrwxrwx 1 user user 336 Jun 17 21:41 bup.git/objects/pack/pack-4d202b3929b187d4acaf1602526e7344eef1edc8.pack -> ?p???GWj??????ܥ??{b?#???>C??%??????~à???/hjT;?p??d?8??oyE?K?)6?uL+??h??&???SB}?'s??֫{?>^i?&?f??^{ш??aD??t4?C?sBTk>d6H???5h3?ڋ6fAa??=?r????j?????a8K??????????B?~????I͕?T7?Y??=???b?7C???鋤??8???\"?????#???M?????}z?A??9?C>?-?GD??7?ј;'P?H??ɑ??Zr?/U???W?G??3@\"??Ȧ?z?h???U??Ԇ???R??u??I????62??>@??@?a??x???}?????)d?G;(???m_?^3?????T - lrwxrwxrwx 1 user user 332 Jul 20 07:32 bup.git/objects/pack/pack-5328381f3b023c1356581c22d1e74d4eda0b46a3.idx -> c??'w??????????m?q#?ٱCO??o????ʃ?Ʃڌ??[???Ѐ??*?;.?c?N?0?????D$ o?r????8BGn?96gY?B?Z1?=???{??z?71????!aG?>?u)???i\?G[???:?Kk??%??.mu???n???K??ǚ????q&Z-?E???]??/?6???} -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment deleted file mode 100644 index 52932cd5e..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_2_3469bfd3ba5e7935f3350f0bd78a0c94._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-12-10T15:13:44Z" - content=""" -I think that the "x86-32, for ancient kernels" build should avoid this -problem. <http://git-annex.branchable.com/install/Linux_standalone/> - -It's very surprising if this lead to symlinks being created that apparently -contain garbage in their link targets. Perhaps glibc is failing in a way -with the old kernel that leads to memory corruption? I have asked the GHC -developers if that could be the case in -<https://ghc.haskell.org/trac/ghc/ticket/12865> - -I hope that the content of your files is in fact somewhere under -`.git/annex/objects/` -- look around, and with some luck, you may find it. -Unfortunately, the information about, which object file goes with which -working tree has apparently been lost. (Also, you might check if these -symlinks have been staged in git; it's possible though unlikely that the -correct link target got staged in git.) - -I have filed a bug on Debian's ghc to get them to fast-track getting the -patch into ghc. <https://bugs.debian.org/847677> -"""]] 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 deleted file mode 100644 index b5316c0de..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_886756620cdbb6ab838269fe2f00db4e._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!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. -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment deleted file mode 100644 index 7aea3d6af..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_3_a4499b5506c0624f01d436e14ccce909._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-12-11T19:35:21Z" - content=""" -All Linux standalone builds have been updated with a version of ghc that -has that bug fixed. Can you please upgrade and verify it's fixed? -"""]] 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 deleted file mode 100644 index 801f70223..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_4_2440227de9b6bc77ae1c73b69a36f7a5._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!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. -"""]] 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 deleted file mode 100644 index 9dec23b00..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_5_c5e3dc25acf0cfb98d7068fe7f83e63a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!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. -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment deleted file mode 100644 index 08e3364ca..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_7_e31ee8f49bf5f73620209c524f1edb3d._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-12-12T17:30:03Z" - content=""" -Can you please check if the current builds still have the "unable to -decommit memory" problem or not? - -(What it does after that error is probably nondeterministic, fixing that -error is the crucial thing.) -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment deleted file mode 100644 index 6d8994155..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_8_038a8e39ec0e91cb04af738eaf9095e1._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" - nickname="0xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="comment 8" - date="2016-12-13T15:52:34Z" - content=""" -It looks like the errors are gone. Thank you so much. -"""]] diff --git a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment b/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment deleted file mode 100644 index 42a14f12a..000000000 --- a/doc/bugs/unable_to_decommit_memory__58___Invalid_argument/comment_9_6c3f4d165bca7a27683df286363bc19b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="Coda" - date="2016-12-18T14:56:17Z" - content=""" -The missing files turned up in 'lost+found' the next time I ran fsck =) -"""]] diff --git a/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant.mdwn b/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant.mdwn deleted file mode 100644 index fd9f08ae4..000000000 --- a/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -### Please describe the problem. -When using “git annex unlock”, the assistant is clever enough not to immediately re-add the corresponding files. When using “git annex unannex”, however, the assistant goes on to re-add the files right away. It would be convenient if this case were also handled likewise. - -git-annex 5.20150508 - -> [[done]]; cannot be implemented. --[[Joey]] diff --git a/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant/comment_1_c9e7a23ae3d3a33944b083cbf9fcbc17._comment b/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant/comment_1_c9e7a23ae3d3a33944b083cbf9fcbc17._comment deleted file mode 100644 index 6248d3983..000000000 --- a/doc/bugs/unannexed_files_are_immediately_re-annexed_by_assistant/comment_1_c9e7a23ae3d3a33944b083cbf9fcbc17._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-22T16:08:29Z" - content=""" -There's no difference between an unannexed file and a new file, -other than some old versions of the unannexed file in past revs of the git -history. - -So, this cannot be implemented. If it were, deleting an annexed -file and then putting a new file in its place with the same filename -(and perhaps content) would appear identical to the assistant as unannexing -a file, and it would not add it. But we absolutely want to add the -file back in that case. - -Suggest that, if you want the assistant to not add files for a while, -you temporarily stop it. -"""]] diff --git a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn b/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn deleted file mode 100644 index 43295e7a8..000000000 --- a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -### Please describe the problem. - -Created a temp repository with a submodule under 3rd/visloc referring to another annex via ssh - -[[!format sh """ - -# I have removed some output/wrong cmd calls, hopefully without side-effects - -hopa:/tmp/test -$> cat 3rd/visloc/.git -gitdir: ../../.git/modules/3rd/visloc - -$> git commit -m 'RF: ...' -a -[master (root-commit) fc37b4f] RF: ... - 2 files changed, 4 insertions(+) - create mode 100644 .gitmodules - create mode 160000 3rd/visloc - -$> ls -l 3rd/visloc/.git --rw------- 1 yoh yoh 38 Feb 8 10:26 3rd/visloc/.git - -$> cat 3rd/visloc/.git -gitdir: ../../.git/modules/3rd/visloc - -$> cd 3rd/visloc/sub-01/rois - -$> git annex get * -fatal: Not a git repository: '../../.git' -git-annex: First run: git-annex init - -$> cd - -/tmp/test - -$> ls -l 3rd/visloc/.git -lrwxrwxrwx 1 yoh yoh 41 Feb 8 10:43 3rd/visloc/.git -> ../../../../../../.git/modules/3rd/visloc - -$> git annex version -git-annex version: 6.20160126+gitg65f4442-1~ndall+1 -build flags: Assistant Webapp Pairing Testsuite S3(multipartupload) WebDAV Inotify DBus DesktopNotify XMPP ConcurrentOutput DNS TDFA TorrentParser Feeds Quvi -key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external -local repository version: 5 -supported repository versions: 5 6 -upgrade supported from repository versions: 0 1 2 4 5 -"""]] - -[[!meta author=yoh]] - -> [[fixed|done]] diff --git a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_1_e47dcdec6657083c5df914482c01b595._comment b/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_1_e47dcdec6657083c5df914482c01b595._comment deleted file mode 100644 index e8f59b5d6..000000000 --- a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_1_e47dcdec6657083c5df914482c01b595._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="submodules of the submodules" - date="2016-02-08T16:05:18Z" - content=""" -replacing broken link seems to work but then for submodules within those submodules I run into similar problems. While looking into it, could you please check that it works within submodules of the submodules (and so on)? ;) -"""]] diff --git a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_2_744b2910a2786c090fe8f53de3a2b91c._comment b/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_2_744b2910a2786c090fe8f53de3a2b91c._comment deleted file mode 100644 index ffc368301..000000000 --- a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_2_744b2910a2786c090fe8f53de3a2b91c._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-02-08T16:21:57Z" - content=""" -the initial issue seems to relate to invoking initial git annex command within a subdirectory of a submodule, so it sticks then too many ../.. into the path of .git. I was being able to successfully acquire content within submodule and submodule of submodule whenever initial annex command was within the top dir of the submodule (now just need to resolve accumulated chaos in an existing repository) ;-) -"""]] diff --git a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_3_7781f13c070a3c79f5b63d3172b0280a._comment b/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_3_7781f13c070a3c79f5b63d3172b0280a._comment deleted file mode 100644 index 4d519264b..000000000 --- a/doc/bugs/use_of_annex_in_submodule_replaces_.git_with_incorrect_symlink/comment_3_7781f13c070a3c79f5b63d3172b0280a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-02-08T18:27:32Z" - content=""" -Yeah, it was running git annex init in the subdir of the submodule that -triggered the bug. Easy fix, also fixes init in submodules of submodules. -"""]] diff --git a/doc/bugs/using_regular_magic_file__warning_pollutes_stderr.mdwn b/doc/bugs/using_regular_magic_file__warning_pollutes_stderr.mdwn deleted file mode 100644 index c94a56247..000000000 --- a/doc/bugs/using_regular_magic_file__warning_pollutes_stderr.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -Although probably not an annex issue but thought to let you know since you might see -a quick resolution on your end - -Here is the log from datalad: - -[[!format sh """ -2016-02-25 22:53:32,886 [DEBUG] Running: ['git', '-c', 'receive.autogc=false', '-c', 'annex.alwayscommit=false', 'annex', 'add', '--debug', '--json', '-c', 'annex.largefiles=exclude=CHANGES* and exclude=README* and exclude=*.[mc] and exclude=dataset*.json and (exclude=*.txt or include=*/*.txt) and (exclude=*.json or include=*/*.json) and (exclude=*.tsv or include=*/*.tsv)', 'README.txt'] (cmd.py:351) -2016-02-25 22:53:32,979 [ERROR] stderr| /etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' (cmd.py:351) - - -or outside (file is already under annex) - -$> git annex --debug add -c 'annex.largefiles=exclude=CHANGES* and exclude=README*' README.txt -/etc/magic, 4: Warning: using regular magic file `/usr/share/misc/magic' - -"""]] - -annex is up to date: 6.20160225+gitg229db26-1~ndall+1 - -edit1: that is happening on jessie with file 1:5.22+15-2+deb8u1 if that is relevant -[[!meta author=yoh]] - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/using_regular_magic_file__warning_pollutes_stderr/comment_1_407787292dd6e6d1aff7193634f8a7bf._comment b/doc/bugs/using_regular_magic_file__warning_pollutes_stderr/comment_1_407787292dd6e6d1aff7193634f8a7bf._comment deleted file mode 100644 index a0f7e03c8..000000000 --- a/doc/bugs/using_regular_magic_file__warning_pollutes_stderr/comment_1_407787292dd6e6d1aff7193634f8a7bf._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-26T15:52:43Z" - content=""" -Reproduced in a clean chroot using the linux standalone tarball. - -I think it does this when it can't find any magic file. - -Fixing by including the magic database in the bundle. This will also let me -re-enable magicmime on OSX. -"""]] diff --git a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission.mdwn b/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission.mdwn deleted file mode 100644 index e089b1591..000000000 --- a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission.mdwn +++ /dev/null @@ -1,93 +0,0 @@ -### Please describe the problem. -If a file is executable, the content of the file remains to be an SHA hash in a newly cloned repository. Neither 'git annex sync --content' or 'git annex get' can bring the file back. -The only way to bring the file back is to remove the file and do a 'git checkout' or 'git reset HEAD --hard' - -If the file is not an executable (a tarball for example), it works as expected. - -If I did not clone the repo but created a new repo and then manually added a remote it also worked as expected. - -### What steps will reproduce the problem? -See log below. - -### What version of git-annex are you using? On what operating system? -6.20160318-gd594fc0 on Ubuntu 15.10 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - -vagrant@vm:/tmp/$ cd annex/ -vagrant@vm:/tmp/annex/$ mkdir repo1 -vagrant@vm:/tmp/annex/$ cd repo1/ -vagrant@vm:/tmp/annex/repo1/$ git init -Initialized empty Git repository in /tmp/annex/repo1/.git/ -vagrant@vm:/tmp/annex/repo1/$ git annex init --version=6 -init ok -(recording state in git...) -vagrant@vm:/tmp/annex/repo1/$ cp /bin/ls . -‘/bin/ls’ -> ‘./ls’ -vagrant@vm:/tmp/annex/repo1/$ git add ls -vagrant@vm:/tmp/annex/repo1/$ git ci -am 'added ls binary' -(recording state in git...) -[master (root-commit) 7889519] added ls binary - 1 file changed, 1 insertion(+) - create mode 100755 ls -vagrant@vm:/tmp/annex/repo1/$ ls -l -total 116 --rwxr-xr-x 1 vagrant vagrant 118272 Apr 1 12:56 ls -vagrant@vm:/tmp/annex/repo1/$ cd .. -vagrant@vm:/tmp/annex/$ git clone repo1 repo2 -Cloning into 'repo2'... -done. -vagrant@vm:/tmp/annex/$ cd repo2 -vagrant@vm:/tmp/annex/repo2/$ git annex init --version=6 -init (merging origin/git-annex into git-annex...) -(recording state in git...) -(scanning for unlocked files...) -ok -(recording state in git...) -vagrant@vm:/tmp/annex/repo2/$ ls -l -total 4 --rwxrwxr-x 1 vagrant vagrant 97 Apr 1 12:57 ls -vagrant@vm:/tmp/annex/repo2/$ git annex sync --content -commit ok -pull origin -ok -get ls (from origin...) (checksum...) ok -pull origin -ok -(recording state in git...) -push origin -Counting objects: 11, done. -Delta compression using up to 8 threads. -Compressing objects: 100% (9/9), done. -Writing objects: 100% (11/11), 1.10 KiB | 0 bytes/s, done. -Total 11 (delta 1), reused 0 (delta 0) -To /tmp/annex/repo1 - * [new branch] git-annex -> synced/git-annex - * [new branch] master -> synced/master -ok -vagrant@vm:/tmp/annex/repo2/$ ls -l -total 4 --rwxrwxr-x 1 vagrant vagrant 97 Apr 1 12:57 ls -vagrant@vm:/tmp/annex/repo2/$ cat ls -/annex/objects/SHA256E-s118272--0b786b336b0391b56dabb7b078a23ec4295115628cfd4b635f4d8ae5ae0cfafc -vagrant@vm:/tmp/annex/repo2/$ git annex get ls -vagrant@vm:/tmp/annex/repo2/$ cat ls -/annex/objects/SHA256E-s118272--0b786b336b0391b56dabb7b078a23ec4295115628cfd4b635f4d8ae5ae0cfafc -vagrant@vm:/tmp/annex/repo2/$ rm ls -vagrant@vm:/tmp/annex/repo2/$ git checkout ls -vagrant@vm:/tmp/annex/repo2/$ ls -l -total 116 --rwxrwxr-x 1 vagrant vagrant 118272 Apr 1 12:59 ls - - -# End of transcript or log. -"""]] - -### 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) - - -> [[fixed|done]] diff --git a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_1_054ed86d3787ed0f7bc393e7a17d8b6b._comment b/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_1_054ed86d3787ed0f7bc393e7a17d8b6b._comment deleted file mode 100644 index 8fd5532a7..000000000 --- a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_1_054ed86d3787ed0f7bc393e7a17d8b6b._comment +++ /dev/null @@ -1,31 +0,0 @@ -[[!comment format=mdwn - username="ExGen" - subject="Same" - date="2016-04-03T13:47:26Z" - content=""" -I have this problem on windows v6 too: - - $ git annex get test - get test (from laptop...) - SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0 - 14,488,367 100% 63.24MB/s 0:00:00 (xfr#1, to-chk=0/1) - (checksum...) - git-annex: DeleteFile \".\\test\": permission denied (The process cannot access the file because it is being used by another process.) - failed - git-annex: get: 1 failed - -I can see only a pointer: - - $ cat test - /annex/objects/SHA256E-s14488367--4391729b982439764813156e1bfc12e9626ae89452ab812f5180c376fbd57fc0 - -`git annex unlock` will do nothing, and: - - $ git annex lock - lock test git-annex: content not present; cannot lock - -I'll make another bug report. - - - -"""]] diff --git a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_2_3670842c476af9b48ef37adab74a0a9d._comment b/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_2_3670842c476af9b48ef37adab74a0a9d._comment deleted file mode 100644 index 6676a4f6c..000000000 --- a/doc/bugs/v6_repo_can_not_restore_files_with_executable_permission/comment_2_3670842c476af9b48ef37adab74a0a9d._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-04-14T16:59:40Z" - content=""" -I've fixed this bug. After upgrading to git-annex 6.20160414 or newer, -if you have such files in your repository, you will need to force git-annex -to update its list of unlocked files, by running: - - git annex init --version=6 - -You may also need to run `git annex fsck` on the files to properly populate -them with their content. Do it after the above command. - -(There were also some bugs that lost the execute bit; fixed those too.) - -(The comment about windows is not about this bug at all, but an entirely -different, and already fixed bug.) -"""]] diff --git a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn deleted file mode 100644 index 470b50722..000000000 --- a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -### Please describe the problem. - -The 'present' flag in the wanted files flag for a repository is ignored when doing a `git annex sync --content`, which causes git annex to (try to) drop all files. E.g. the line - - wanted $repoid = lackingcopies=1 or present - -in `git annex vicfg` tries to drop all files if enough copies are available. `git annex drop --auto` works as expected and doesn't try to drop files. - -### What steps will reproduce the problem? -Use 'present' in the 'wanted' option of a repo and do a `git annex sync --content`. `wanted $repouuid = present` was enough to trigger that behaviour. - -### What version of git-annex are you using? On what operating system? -git-annex version 6.20160114 on Arch Linux. - - -### 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) - -This behaviour is relatively recent. Until some time ago everything worked as expected with the expression above. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment b/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment deleted file mode 100644 index dc4b3dc65..000000000 --- a/doc/bugs/wanted___61___present_gets_ignored_in___39__git_annex_sync_--content__39__/comment_1_410adea7a16e77756579556a2270a458._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-01-26T18:22:48Z" - content=""" -I think it's worse than that, it lost track of the filename, so -preferred content expressions with include= or exclude= will also do the -wrong thing. - -Going to have to rush out a release fixing this.. -"""]] diff --git a/doc/bugs/webapp_missing_in_20150522_release.mdwn b/doc/bugs/webapp_missing_in_20150522_release.mdwn deleted file mode 100644 index 77371e050..000000000 --- a/doc/bugs/webapp_missing_in_20150522_release.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. - -Using the prebuilt linux tarball, version 20150522 fails to start the webapp. - -Doing it manually from the console, just gives me the help text. - -Trying out an older version shows me the webapp option below "watch" in the help, but this is missing in 20150522 version. - -git-annex version gives me: - - git-annex version: 5.20150522-gb199d65 - build flags: Assistant Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA - key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E MD5E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 MD5 WORM URL - remote types: git gcrypt S3 bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - -### What steps will reproduce the problem? - -Use 20150522 version of git annex - -### What version of git-annex are you using? On what operating system? - -linux tarball, version 20150522 - -Arch linux - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -> Unfortunate I didn't notice this. I've fixed it in git and will make a -> release tomorrow. [[done]] --[[Joey]] diff --git a/doc/bugs/webapp_missing_in_20150522_release/comment_1_087ea0e3712869b440d31714e0fb068a._comment b/doc/bugs/webapp_missing_in_20150522_release/comment_1_087ea0e3712869b440d31714e0fb068a._comment deleted file mode 100644 index 6de0ae6f9..000000000 --- a/doc/bugs/webapp_missing_in_20150522_release/comment_1_087ea0e3712869b440d31714e0fb068a._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="git-annex@8c58bb43191e0443be5d100448ba874284c5a778" - nickname="git-annex" - subject="OSX Homebrew Has Same Failure" - date="2016-01-13T00:09:13Z" - content=""" -Unfortunately this issues also exists in the OSX Homebrew release of version 5.20151218 - -> build flags: Assistant Pairing Testsuite WebDAV FsEvents XMPP ConcurrentOutput DNS Feeds Quvi TDFA TorrentParser Database -> key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL -> remote types: git gcrypt bup directory rsync web bittorrent webdav tahoe glacier ddar hook external - - -"""]] diff --git a/doc/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing.mdwn b/doc/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing.mdwn deleted file mode 100644 index 985024974..000000000 --- a/doc/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -When deleting a remote via the webapp, if syncing is disabled -the content will never get removed from the remote. So, the starting to -delete a remote should probably enable syncing to it, or warn if syncing is -disabled. --[[Joey]] - -> [[done]] via Farhan Kathawala's patch to simply grey out the menu item. -> --[[Joey]] diff --git a/doc/bugs/webapp_usability__58___fails_mysteriously_on_newer_repo_layouts.mdwn b/doc/bugs/webapp_usability__58___fails_mysteriously_on_newer_repo_layouts.mdwn deleted file mode 100644 index 73908f40b..000000000 --- a/doc/bugs/webapp_usability__58___fails_mysteriously_on_newer_repo_layouts.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -### Please describe the problem. - -Starting the webapp on a repository that was hastily created by copying an existing one with an older version yields an undecipherable error. - -Rather minor. - -### What steps will reproduce the problem? - -1. Install git-annex from git -2. make a repo -3. copy it over to an external hard drive -4. connect that drive to a wheezy box running git-annex from backports -5. add the external hard drive to the webapp as a new repo -6. boom - -I expected git-annex to tell me: - - git-annex: Repository version 5 is not supported. Upgrade git-annex. - -Instead, it popped a red box saying a scary "Internal server error". I couldn't read the daemon logs either. - -### What version of git-annex are you using? On what operating system? - -original version is: - - git-annex version: 5.20131109-gf2cb5b9 - -the failing version is running the one from wheezy backports. - -### Please provide any additional information below. - -screenshot coming up. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/wget_always_shows_progress_bar.mdwn b/doc/bugs/wget_always_shows_progress_bar.mdwn deleted file mode 100644 index 708db8906..000000000 --- a/doc/bugs/wget_always_shows_progress_bar.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -git annex addurl or importfeed operations were quiet on git-annex versions older than 5.20141219, if -annex.web-options was set to "--quiet". But now the --show-progress option is always passed to wget. - -In some use cases this might be nice, but I'm using GNU Parallel to update multiple podcast feeds -concurrently, and it causes wget to output the ugly "dot" indicator for every feed, which is totally -useless since parallel buffers and groups the output. Adding "--no-show-progress" to web-options -does not help (it does not override --show-progress), nor does redirecting stdout to /dev/null. -Redirecting stderr would hide possible errors. - -### What steps will reproduce the problem? - -parallel git annex importfeed --relaxed --quiet ::: http://feeds.feedburner.com/freakonomicsradio - -### What version of git-annex are you using? On what operating system? - -5.20151208-1~bpo8+1 on Debian. - -### 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) - -I love git annex and use it daily. - - -> [[done]] --[[Joey]] diff --git a/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment b/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment deleted file mode 100644 index c2e6eb53f..000000000 --- a/doc/bugs/wget_always_shows_progress_bar/comment_1_d40883c9f9aade47112a0479ad56ed06._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-12-13T15:49:20Z" - content=""" -Since 2014, git-annex has used wget -q --show-progress to get a -progress bar without the several other lines of output it would normally -display. Whether a given git-annex build does this depends on what -version of wget it saw at configure time. - -Running git-annex with --quiet will disable the wget progress bar (and -other git-annex output). This seems like the thing to do if you're running -git-annex concurrently. (Of course, git-annex also has its own built-in -concurrency with -J which can display multiple download progress bars in a -nice way.) - -Still, might as well make the web-options come after the default options so -they can be overridden. Doing so. -"""]] diff --git a/doc/bugs/wget_invocation_should_get_timeout_options.mdwn b/doc/bugs/wget_invocation_should_get_timeout_options.mdwn deleted file mode 100644 index c74566c2a..000000000 --- a/doc/bugs/wget_invocation_should_get_timeout_options.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -### Please describe the problem. - -Currently if download stalls the whole 'annex get' stalls -- I have been watching the terminal with 0% for an hour now ;) - -You could test that on http://github.com/datalad/mlbooks annex, just get -G.James_D.Witten_T.Hastie_R.Tibshirani-An_Introduction_to_Statistical_Learning_with_Applications_in_R.pdf - -original url for the file is http://www-bcf.usc.edu/~gareth/ISL/ISLR%20Fourth%20Printing.pdf -and wgetting works for me on some boxes but not on the other, forgot why so - -### What version of git-annex are you using? On what operating system? - -5.20150706+gitgefc3bcd-1~ndall+1 and tried in clean debian sid docker with 5.20150812-2 - -> [[done]] per my comment and no followup --[[Joey]] diff --git a/doc/bugs/wget_invocation_should_get_timeout_options/comment_1_a1126fe3f8ab74d623204f98c30dd052._comment b/doc/bugs/wget_invocation_should_get_timeout_options/comment_1_a1126fe3f8ab74d623204f98c30dd052._comment deleted file mode 100644 index 147051498..000000000 --- a/doc/bugs/wget_invocation_should_get_timeout_options/comment_1_a1126fe3f8ab74d623204f98c30dd052._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-09T18:03:27Z" - content=""" -Well, if any operation that gets a file stalls for some reason, then yes, -everything stalls. - -wget has various options like --read-timeout, but I don't see how git-annex -could guess at sane defaults to use for those. If there are sane defaults -for those options, wget probably already implements them. Indeed, -it seems it already defaults --read-timeout to 900 seconds. - -You can of course pass such options if you want to. - -So, I'm not clear what's being asked for here, or how it's a bug in -git-annex at all. -"""]] diff --git a/doc/bugs/windows_installer_seems_have_been_broken.mdwn b/doc/bugs/windows_installer_seems_have_been_broken.mdwn deleted file mode 100644 index 23959be08..000000000 --- a/doc/bugs/windows_installer_seems_have_been_broken.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -### Please describe the problem. - -decided to upgrade git-annex in our test virtualbox windows... upon upgrade (just running installer again with the default location for git), annex is not longer available: http://www.onerussian.com/tmp/gkrellShoot_09-17-15_105547.png -Replicated on another similar instance - -### What steps will reproduce the problem? - -download exe from https://downloads.kitenet.net/git-annex/windows/current/ (btw I think I noted it reduced in size noteably) - -> [[done]] per my comment --[[Joey]] diff --git a/doc/bugs/windows_installer_seems_have_been_broken/comment_1_df8267a58cfa4685728e32115bbde81b._comment b/doc/bugs/windows_installer_seems_have_been_broken/comment_1_df8267a58cfa4685728e32115bbde81b._comment deleted file mode 100644 index fc2e41932..000000000 --- a/doc/bugs/windows_installer_seems_have_been_broken/comment_1_df8267a58cfa4685728e32115bbde81b._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-09-18T16:25:34Z" - content=""" -Git for Windows is now needed; support for msysgit has been dropped -as both can't be supported in the same package. This is documented -in the changelog and the install/Windows page. -"""]] diff --git a/doc/bugs/windows_ssh_webapp_password_entry_broken.mdwn b/doc/bugs/windows_ssh_webapp_password_entry_broken.mdwn deleted file mode 100644 index 1b6f41e2c..000000000 --- a/doc/bugs/windows_ssh_webapp_password_entry_broken.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -Recent changes to ssh on Windows have broken the webapps's support for -entering a password when adding a ssh remote. - -Using ssh on windows with an existing remote does work. So as a workaround, -set up a passwordless ssh key that can log into the ssh server. --[[Joey]] - -> I have a `winprocfix` branch that uses process-1.3 which has been -> enhanced to allow fixing this. Merging is currently blocked on -> <https://github.com/pcapriotti/optparse-applicative/issues/153> --[[Joey]] -> -> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment deleted file mode 100644 index 8941daa35..000000000 --- a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_1_efe3225766e0ef010534e77f1d073541._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-05-26T20:28:42Z" - content=""" -Had a closer look at this, and I'm stumped. The ssh.exe from msysgit seems -to be built with `SSH_ASKPASS` support, based on strings. But, I cannot seem -to get it to use it. - -OTOH, the ssh from cygwin did support this. Just had other problems so it's -not being used any longer. - -At a guess, from reading ssh's code, I might need to find a way to defeat -ssh's isatty check on windows. - -<http://stackoverflow.com/questions/10960269/git-ssh-askpass-on-windows> -hints that there might be a way to start the process "with CreateProcess() -dwCreationFlags DETACHED_PROCESS" to make it work. -"""]] diff --git a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment b/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment deleted file mode 100644 index 558a388d9..000000000 --- a/doc/bugs/windows_ssh_webapp_password_entry_broken/comment_2_c0020f6bfb1690ae14560bc5ac791695._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-05-26T23:24:41Z" - content=""" -I hacked `process` to set both `DETACHED_PROCESS` and `CREATE_NO_WINDOW`, -and this solved it! - -However, this will need changes to `process` (or a lot of code duplication). - -Filed feature request: <https://github.com/haskell/process/issues/32> -"""]] diff --git a/doc/todo/--batch_for_add.mdwn b/doc/todo/--batch_for_add.mdwn deleted file mode 100644 index c0450c11f..000000000 --- a/doc/todo/--batch_for_add.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -should be extremely helpful when adding many files one at a time ;) - -[[!meta author=yoh]] - -> Implemented; made it not recurse into directories and output a blank line -> if it doesn't add the file, so there's aways 1 line of output for each -> input. [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_find.mdwn b/doc/todo/--batch_for_find.mdwn deleted file mode 100644 index 825ca560f..000000000 --- a/doc/todo/--batch_for_find.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I am using `annex find filename` after running 'annex add` to figure out if file was added to annex or to git. - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_info.mdwn b/doc/todo/--batch_for_info.mdwn deleted file mode 100644 index 8f7fba456..000000000 --- a/doc/todo/--batch_for_info.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I guess as other commands which take separate files/keys as its argument(s), having --batch for info command would be of benefit - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/--batch_for_whereis.mdwn b/doc/todo/--batch_for_whereis.mdwn deleted file mode 100644 index 11cd3e8f8..000000000 --- a/doc/todo/--batch_for_whereis.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -subject. IMHO yet another useful command to be batched - -> [[done]] --[[Joey]] diff --git a/doc/todo/Compile_error_with_GHC_prerelease.mdwn b/doc/todo/Compile_error_with_GHC_prerelease.mdwn deleted file mode 100644 index 5f024d5dd..000000000 --- a/doc/todo/Compile_error_with_GHC_prerelease.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -For various reasons we cannot use v8.0 (prereleases) yet, -but GHC v7.11.20150407 - -There was a compilation hiccup with polymorphic types. I corrected it in - -https://github.com/ggreif/git-annex/tree/patch-1 - -The commit is - -https://github.com/ggreif/git-annex/commit/a0ddad8d395b5eb61d1e7e6fdcbfa766c05de3d4 - -Cheers, - - Gabor - -> Applied, thanks. [[done]] --[[Joey]] diff --git a/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn b/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn deleted file mode 100644 index 4a57ac5e4..000000000 --- a/doc/todo/Improve_direct_mode_using_copy_on_write.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -Direct mode is great because it removes symlinks. A must-have for directories like `~/Documents`. Unfortunately, it removes the possibility to use `git` commands other than `git-annex`. Also, it doen't preserve history of files. - -I would be great to have a mode where: - -- files are available in plain, not as sylinks -- the repository could still be trusted to hold version of some files from other repositories -- from a user point of view, the history of a file before the checkout would be preserved. - -In feature rich file systems that have copy on write feature, it could be implemented by having the files in both places at the same time: - -- the current version of a file would be in the working copy -- the file in the working copy would be a copy-on-write of the file in the annex repository -- when the file in the working copy changes, `git-annex` notices it and copy the file in the annex repository using copy-on-write semantic - -If the file system do not support copy-on-write, it could be an option (do you want secure direct mode that takes twice the disk space or light direct mode that don't preserve the history of your files?) - -This would make direct more much more robust. - -copy on write is available using `cp --reflink=always`. It correspond to the following code ([coreutils src/copy.c line 224](http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/copy.c#n224)): - - /* Perform the O(1) btrfs clone operation, if possible. - Upon success, return 0. Otherwise, return -1 and set errno. */ - static inline int - clone_file (int dest_fd, int src_fd) - { - #ifdef __linux__ - # undef BTRFS_IOCTL_MAGIC - # define BTRFS_IOCTL_MAGIC 0x94 - # undef BTRFS_IOC_CLONE - # define BTRFS_IOC_CLONE _IOW (BTRFS_IOCTL_MAGIC, 9, int) - return ioctl (dest_fd, BTRFS_IOC_CLONE, src_fd); - #else - (void) dest_fd; - (void) src_fd; - errno = ENOTSUP; - return -1; - #endif - } - -Looking at the code it would be preferable to exec directly to `cp`, see [copy_range() on LWN](http://lwn.net/Articles/550621/) and this [more recent article about splice() on LWN](http://lwn.net/Articles/567086/) - -Also, `cp --reflink` fall back to copy when copy-on-write is not available while `cp --reflink=always` do not. - -> The new v6 repository mode works this way. [[done]] --[[Joey]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn deleted file mode 100644 index b13bceccf..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It would be great to have something to call in post-update-annex which would give a list of all new and lost files given in the update. - -This could be `git annex log --all --max-count=1` or somesuch. - -This capability could alternatively be provided with a new post-transfer hook, called for every file. - -> [[done]] --[[Joey]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment deleted file mode 100644 index c03673f06..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_1_1b1439d08fd064314e28f94caaa850be._comment +++ /dev/null @@ -1,28 +0,0 @@ -[[!comment format=mdwn - username="baffo32" - subject="Use-case expansion" - date="2016-06-17T23:55:52Z" - content=""" -My use-case is to store the absolute disk offsets for files, to aid recovery in case of accidental loss. - -I'd like to run a script for every key added to the repo in which the script resides. The script calls filefrag to determine the physical location of the key on the disk and adds it as metadata. - -If interested, my pre-commit-annex snippet is: - - # requires recent e2fsprogs - if [ -x /usr/sbin/filefrag ] - then - field=\"$(git config annex.uuid)\"-extents - LC_ALL=C /usr/sbin/filefrag -ev \"$f\" | sed -n \ - -e 's/.*([0-9]* blocks* of \([0-9]*\) bytes).*/!bs \1/p'\ - -e 's/^ *[0-9]*: *\([0-9]*\)\.\. *[0-9]*: *\([0-9]*\)\.\. *[0-9]*: *\([0-9]*\): *.*/\1 \2 \3/p' | - while read value - do - # !bs 4096 means values are in multiples of 4096 bytes (blocksize) - # 0 5287839 5 means 5 blocks starting at block 0 of the file start at block 5287839 of the disk - # extents which are not listed are from sparse files and contain all zeros - equal='+=' addmeta \"$f\" \"$field\" \"$value\" - done - fi - -"""]] diff --git a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment b/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment deleted file mode 100644 index b22b9ed1b..000000000 --- a/doc/todo/Log_function_to_enumerate_all_recent_git-annex_changes/comment_2_18d1c7d8f4f0214c4d89119e9efb9b4a._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2016-07-17T19:09:41Z" - content=""" -Implelemented `git annex log --all`. It turned out to fit really well -to add the functionality there. - -You can use --max-count, or even --since to limit the log -that's displayed. - -The output streams, so you could just remember the first line you saw when -running it before, and close the pipe when the subsequent run outputs that -line. (Although this method may skip over changes that got merged in from -another repository.) -"""]] diff --git a/doc/todo/Nearline_support.mdwn b/doc/todo/Nearline_support.mdwn deleted file mode 100644 index f21af64cf..000000000 --- a/doc/todo/Nearline_support.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -This has been described as Google's [[special_remotes/glacier]]. - -* [Announcement](http://googlecloudplatform.blogspot.in/2015/03/introducing-Google-Cloud-Storage-Nearline-near-online-data-at-an-offline-price.html) -* <https://cloud.google.com/storage/docs/nearline-storage> - -> This is a dup of -> [[bugs/Support_non-default_storage_classes_with_Google_Cloud_Storage]], -> which has more useful info, so [[closing|done]]. -> -> However, that about using its S3 compatability API. There's an external -> special remote just for nearline, which may be a better choice due to -> using the native API, and already works. --[[Joey]] diff --git a/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment b/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment deleted file mode 100644 index ec6bfc54d..000000000 --- a/doc/todo/Nearline_support/comment_1_185e4cce55ac26756e74c668d0fe2a8c._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-03-16T17:47:18Z" - content=""" -I have not read anything about this yet, but there is another post -which seems to indicate that the S3 interface could be used with git-annex, -if it were possible to set storageclass=NEARLINE, which it is currently -not due to a limitation with the aws library git-annex is using. -""]] diff --git a/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment b/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment deleted file mode 100644 index fe095f5ca..000000000 --- a/doc/todo/Nearline_support/comment_3_2d320d2c636c36c3006d91469b8c5ca9._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmUJBh1lYmvfCCiGr3yrdx-QhuLCSRnU5c" - nickname="Justin" - subject="comment 3" - date="2015-03-18T04:43:22Z" - content=""" -To be clear, I'm not sure that using storageclass=NEARLINE would work. Perhaps we need to omit storageclass entirely, or perhaps the storageclass=STANDARD isn't actually the problem. I'm just guessing at this point. -"""]] diff --git a/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment b/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment deleted file mode 100644 index d01955fce..000000000 --- a/doc/todo/Nearline_support/comment_4_ae360f07fb87d63f09725b43b85cb210._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-03-26T16:04:01Z" - content=""" -This is waiting on support in the AWS library git-annex uses. - -<https://github.com/aristidb/aws/issues/155> -"""]] diff --git a/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment b/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment deleted file mode 100644 index 2c0c50bd1..000000000 --- a/doc/todo/Nearline_support/comment_4_cb30f90ad3f2c22b3067527298dec849._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmSedKB9mVUCUcxmY5snWkfFVvTSnmiNKo" - nickname="Jeffery" - subject="comment 4" - date="2015-03-18T12:14:55Z" - content=""" -According to the documentation for nearline: \"You can access data in a Nearline bucket in the same way you access data in a Standard bucket.\" and that you just use \"Nearline\" as the storage class... so this might work? -"""]] diff --git a/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment b/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment deleted file mode 100644 index a661dc17d..000000000 --- a/doc/todo/Nearline_support/comment_5_81b487864dbe7f4934f354839273fb69._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91" - nickname="justin.lebar" - avatar="http://cdn.libravatar.org/avatar/9fca4b61a1ab555f231851e7543f9a3e" - subject="comment 5" - date="2016-11-01T04:11:20Z" - content=""" -BTW I've been using this for the past few weeks, and it works great! Thank you for helping get this working. - -(Of course, there's now coldine to make work. But I don't have so much data that this makes a big difference to me. :) -"""]] diff --git a/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn b/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn deleted file mode 100644 index 9a7ce26a7..000000000 --- a/doc/todo/PATCH__58___Fixes_bug_where_webapp_allows_user_to_attempt_deleting_an_unsynced_repo.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I made an attempt to tackle the following bug: - -[webapp should notice when remote deletion cannot complete due to not syncing](https://git-annex.branchable.com/bugs/webapp_should_notice_when_remote_deletion_cannot_complete_due_to_not_syncing/) - -My changes are in the following git repository - -[https://github.com/kathawala/git-annex.git](https://github.com/kathawala/git-annex.git) - -And the specific commit which fixes the bug is in a branch titled "unsync-nodelete". I have tested the change, it greys out and disables the "Delete" option in the "Actions" dropdown menu of the webapp for any repo in the "Repolist" view which has its syncing disabled. There is also some hover text which explains why the option is greyed out. Hope it is satisfactory! Thanks for your great work!! - -> I merged this patch, thank you! [[done]] --[[Joey]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn b/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn deleted file mode 100644 index 9e1c30a94..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -Like many, I'm an experienced coder in procedural and object-oriented languages only. - -Could you recommend a route to learning Haskell I could work on a little bit every month, such that I might eventually become familiar enough to hack on git-annex? - -[[done]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment b/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment deleted file mode 100644 index f5b13dadc..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_1_69bab2e1ab6382ba1149298e08ba659f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-11-02T15:01:52Z" - content=""" -I'm taking this as an indication that [[/contribute]] needed some pointers -for learning haskell, so have made some changes there that might answer -your question, as well as others who see that page. -"""]] diff --git a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment b/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment deleted file mode 100644 index 92fa3bb44..000000000 --- a/doc/todo/Recommended_route_to_learning_Haskell__63__/comment_2_857fffd7db3921718d2578944cfbaa09._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" - nickname="0xloem" - avatar="http://cdn.libravatar.org/avatar/b8c087f7c5e6a9358748f0727c077f3b" - subject="comment 2" - date="2016-11-06T11:42:48Z" - content=""" -thanks ! -"""]] diff --git a/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn b/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn deleted file mode 100644 index d159ce535..000000000 --- a/doc/todo/Remove___39__superfluous_constraints__39___warnings.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Please pull branch `patch-1` from repo - -https://github.com/ggreif/git-annex.git - -It contains some cleanups from warnings that appear with GHC 7.11 (and probably 8.0 too). - -> Merged and thank you! [[done]] --[[Joey]] diff --git a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn b/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn deleted file mode 100644 index c4a1acaf5..000000000 --- a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -If I understand it correctly, the original formulation is in fact incorrect. - -Please see https://github.com/joeyh/git-annex/pull/52/commits/e5bb450f44c6dfd01d7b2c84b3fa40c25867a47e for the patch. - -> [[done]] --[[Joey]] diff --git a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment b/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment deleted file mode 100644 index 78d712f64..000000000 --- a/doc/todo/_Correct_formulation_in__doc__47__git-annex-matching-options.mdwn_/comment_1_411b3c1256a8f192707b0302e0fb5701._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-06T16:31:03Z" - content=""" -No, it was correct as written. But, I think that was a confusing example -since it essentially contained a double negative, and so I changed it a -while ago to a --include example. -"""]] diff --git a/doc/todo/__34__copy_--failed__34__.mdwn b/doc/todo/__34__copy_--failed__34__.mdwn deleted file mode 100644 index fa3b071d7..000000000 --- a/doc/todo/__34__copy_--failed__34__.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -I often "copy --to remote" many files at once, and inevitably the transfer fails for some files (few out of hundreds). It would be great to subsequently be able to "copy --failed --to remote" to re-try only the transfers for failed files (similarly to how one can use "--unused"). - -Related: <https://git-annex.branchable.com/todo/make_copy_--fast__faster/> - -git-annex is awesome btw. Thanks! - -> [[done]] --[[Joey]] diff --git a/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment b/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment deleted file mode 100644 index b17372714..000000000 --- a/doc/todo/__34__copy_--failed__34__/comment_1_ff81023df39f9faac5935f6417ad2b38._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-08-03T15:07:43Z" - content=""" -Nice idea, and there's already an implementation of a log of recent failed -transfers that the assistant uses, that can be reused for this. -"""]] diff --git a/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment b/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment deleted file mode 100644 index 57ae3727e..000000000 --- a/doc/todo/__34__copy_--failed__34__/comment_2_9044c9b76f25114914f68afe0c7c0506._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="eslgastal" - subject="comment 2" - date="2016-08-04T00:56:30Z" - content=""" -That was fast! Thanks again Joey. -"""]] diff --git a/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn b/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn deleted file mode 100644 index 5e0598816..000000000 --- a/doc/todo/__39__info_filename__39___to_provide_information_either_content_is_locally_present.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -ATM in DataLad we rely on 'git annex find' to determine either files have content locally. Even though it could be used in a batch mode, I wondered if we could may be just use 'annex info' to obtain information either a file (or a key) has content locally? Another benefit would be is that within single command output we could determine also if a file under annex or not (instead of first doing e.g. 'info' to figure out if under annex and then 'find' again to figure out if content is present locally) - - -[[!meta author=yoh]] - -> sure, [[done]] --[[Joey]] diff --git a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn b/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn deleted file mode 100644 index 9a4e925b2..000000000 --- a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -This commit is also available in the "log-raw-missing-dash" branch at <https://github.com/sunny256/git-annex.git>. - -[[!format hs """ -From 5e00265dae057e1846d5a256f450c8a1e1803c97 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Wed, 24 Jun 2015 17:07:37 +0200 -Subject: [PATCH] Log.hs: Add missing dash to --raw option - -After commit eb33569f ("remove Params constructor from -Utility.SafeCommand", 2015-06-01), git-annex aborted with the error -message "fatal: unrecognized argument: -raw" when executing "git annex -log". ---- - Command/Log.hs | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Command/Log.hs b/Command/Log.hs -index 9ee7f85..495c43c 100644 ---- a/Command/Log.hs -+++ b/Command/Log.hs -@@ -151,7 +151,7 @@ getLog key os = do - [ Param "log" - , Param "-z" - , Param "--pretty=format:%ct" -- , Param "-raw" -+ , Param "--raw" - , Param "--abbrev=40" - , Param "--remove-empty" - ] ++ os ++ --- -2.4.4.408.g16da57c - -"""]] - -> Thanks for the patch! Someone else reported a bug about it and I already -> patched it when I noticed this, so you missed getting in the commit log.. -> this time! ;) [[done]] --[[Joey]] diff --git a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment b/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment deleted file mode 100644 index 9feb93633..000000000 --- a/doc/todo/__91__PATCH__93___Log.hs__58___Add_missing_dash_to_--raw_option/comment_1_f56776e10b58547c3e8d3e55599a3fa9._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="sunny256" - subject="comment 1" - date="2015-07-06T22:33:48Z" - content=""" -Hehe, yep. ;) But it was quite low-hanging fruit anyway, and I'm glad it's fixed. Thanks. Hope you had a nice holiday, though. You deserve it. — Øyvind -"""]] diff --git a/doc/todo/ability_to_set_metadata_from_json.mdwn b/doc/todo/ability_to_set_metadata_from_json.mdwn deleted file mode 100644 index 1129650a0..000000000 --- a/doc/todo/ability_to_set_metadata_from_json.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -I can export metadata to JSON format, which is nice as this can now be read -into any other tool and manipulated. But I cannot find a way to set the -metadata from JSON and so I am left to figure out what changes need to be -made via the g-a interface to get to the desired state, and that is hard to -get right. - -Maybe g-a metadata could grow an import-json function which would set -(overwrite) the metadata for the given file(s) from JSON input. - -Thanks, --m - -> [[done]] via `git annex metadata --batch --json` --[[Joey]] diff --git a/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn b/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn deleted file mode 100644 index ef69869ba..000000000 --- a/doc/todo/add_magicmime_support_to_OSX_dmg.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -The OSX .dmg is built without the MagicMime build flag. Turning it on will -take some work to ship a copy of the magic database inside the dmg. - -> [[done]] ---[[Joey]] diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn b/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn deleted file mode 100644 index c322660df..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -I thought that whereis command would report only based on the knowledge annex has locally in git-annex branch, but apparently it is trying to query for information even in --fast mode: - -[[!format sh """ -$> git annex whereis --fast bold.nii.gz -yoh@dat.... -Permission denied (publickey,password). -fatal: Could not read from remote repository. - -Please make sure you have the correct access rights -and the repository exists. -whereis bold.nii.gz -(2 copies) - 899f0347-0888-48ef-91b6-bac213ca8cef -- [datalad-archives] - c8bd3d05-33d4-4b59-9d53-ca7efbdcdd13 -- yoh@smaug:/mnt/btrfs/datasets/datalad/crawl/openfmri/ds000001 [here] - - datalad-archives: dl+archive:MD5E-s2527262329--bd3ea399057c529b37b09dcecec1ca60.0raw.tgz/ds001_R1.1.0/sub001/BOLD/task001_run001/bold.nii.gz#size=47241449 - -"""]] - -[[!meta author=yoh]] -Was [[done]] by [[Joey]] as of 6.20160524+gitg2b7b2c4-1~ndall+1 diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment deleted file mode 100644 index 1066455ed..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_1_19442ed153aafb025065ede3a8fe94c6._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-25T17:44:59Z" - content=""" -This is not specific to whereis at all. You have added a new git remote and -git-annex does not know what the uuid of it is. Until it can find out, it -won't be able to use that remote (including referring to it in whereis -output). So, git-annex always tries to get the uuid for such remotes -at startup time. - -If you don't want git-annex to use this remote, you can set -remote.name.annex-ignore. -"""]] diff --git a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment b/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment deleted file mode 100644 index 041b59028..000000000 --- a/doc/todo/add_option_to_whereis_to_avoid_network_interactions/comment_2_a11a283ca2f3b37502bece27a84ab71b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-04-25T18:28:14Z" - content=""" -gotcha... indeed, after allowing annex to fetch uuid for it and adjust .git/config it doesn't go over ssh during whereis. -I don't have a strong use case yet to further support --no-network or alike for whereis ATM so feel free to close, but I am afraid it might bite me again later whenever I wouldn't expect any demand from annex/ssh for interactive prompts while running some command which doesn't usually require interaction (e.g. whereis) due to querying remote locations. -"""]] diff --git a/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn b/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn deleted file mode 100644 index d79c13f92..000000000 --- a/doc/todo/annex.hardlink_should_also_affect_copy_to_origin.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -When a repo has annex.hardlink set, objects are hard-linked into the -repository when eg `git annex copy --from origin`. This should also -be done when copying files --to origin (or other remotes on the same -filesystem). This way, a quick shared clone can be used to add/modify -files, and cheaply send the changes back to the parent repo. --[[Joey]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes.mdwn b/doc/todo/autoenable__61__true_for_special_remotes.mdwn deleted file mode 100644 index 7e93ded0d..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459 - -joey: I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes. - -> [[done]], I made both `git init` and `git annex reinit` auto-enable -> such special remotes. For now, the assistant does not (could change). -> -> There was also the question of what to do when git-annex auto-inits -> in a clone of a repository. It wouldn't do for a command like -> `git annex find`'s output to include any messages that might be shown while -> auto-enabling special remotes as a result of an auto-init. -> Since I can't guarantee enabling special remotes will be quiet, I've not -> tried to auto-enable special remotes in this case. -> -> I think I'd have to -> exec a git-annex init process with stdout sent to stderr to implement -> this in a safe way, and due to calls to ensureInitialized in Remote.Git, -> which can auto-init a local remote, that gets particularly tricky. Best, I -> feel, to wait and see if anyone needs that. ---[[Joey]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment deleted file mode 100644 index b04a8c245..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - subject="comment 1" - date="2015-08-25T18:25:44Z" - content=""" -There are going to be many configurations where auto-enable of a special remote fails. Ie, when creds are needed. While some of these could be detected and skipped, I sort of like the simplicity of having it try to enable everything. - -Maybe a command is also needed to autoenable remotes after the first git-annex init? Since it's actually ok to re-run git-annex init in an initalized repo, I suppose it could just be run again. -"""]] diff --git a/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment b/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment deleted file mode 100644 index 7cf9225ec..000000000 --- a/doc/todo/autoenable__61__true_for_special_remotes/comment_2_e099d623a471c42bb9d14d0e965d6ba0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - avatar="http://cdn.libravatar.org/avatar/8122123b4c2bc77187e32d7e025f7d445d7a08de1ba532237876a31159ac01da" - subject="should annex merge autoenable newly added autoenable'ed special remotes" - date="2016-11-04T12:43:55Z" - content=""" -relevant case: https://github.com/datalad/datalad/issues/1093 -"""]] diff --git a/doc/todo/batch_get__47__drop__47__etc.mdwn b/doc/todo/batch_get__47__drop__47__etc.mdwn deleted file mode 100644 index 154d4aca6..000000000 --- a/doc/todo/batch_get__47__drop__47__etc.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -in the spirit of [[todo/--batch_for_add/]], [[todo/--batch_for_info/]], [[todo/--batch_for_find/]] and [[todo/--batch_for_whereis/]], why not add `--batch` to get/drop/import operations? - -I am writing a script to get a bunch of arbitrary files and i want to avoid the overhead of running git-annex multiple times. I know i can use `annex.alwayscommit=false` but that is rather counter-intuitive as well. --[[anarcat]] - -> [[done]] for add and drop. (Not for import, but if someone requests it -> with a use case we'll see.) --[[Joey]] diff --git a/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment b/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment deleted file mode 100644 index 69b5d03a6..000000000 --- a/doc/todo/batch_get__47__drop__47__etc/comment_1_c912c829dbb77d2072e0150fcb47932e._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-04-20T18:30:23Z" - content=""" -I prefer keeping --batch on things that act in terms of keys and have a -simpler interface. - -So, could add --batch to `git annex transferkey`. This would presumably -need to disable any process displays in order for success/failure to be -communicated in a machine-parsable way. (Actually, `git annex transferkeys` -already implements such a batch interface, but one that is currently -not documented due to only being built for the assistant to use it.) - -There is already `git annex dropkey --batch`, although it does not -verify that other copies exist. -"""]] diff --git a/doc/todo/checkpresentkey_without_explicit_remote.mdwn b/doc/todo/checkpresentkey_without_explicit_remote.mdwn deleted file mode 100644 index 7ad667f28..000000000 --- a/doc/todo/checkpresentkey_without_explicit_remote.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -While being asked to check if file is available from "[datalad-archives]" remote I need to check if the archive's key available. Ideally I wish I could ask through the ongoing interaction protocol, but if not, I could use smth like 'git annex checkpresentkey' but that one demands specification also of a remote which to check. In my case I just want to know if that key is available from any remote, so I could confirm that the file is still present in our archives remote, i.e. that it could be retrieved later on - -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment b/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment deleted file mode 100644 index 600cae51b..000000000 --- a/doc/todo/checkpresentkey_without_explicit_remote/comment_1_eab7b9d6d026675328d0e743a385ba8a._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-12T20:07:30Z" - content=""" -Makes sense, and also I will add a --batch mode to it. - -Done. -"""]] diff --git a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn deleted file mode 100644 index 3b1b929ea..000000000 --- a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -Since in datalad we are invoking git and git-annex quite frequently, and on debian systems atm relying on git-annex-standalone pkg, I wondered, if there is a possibility to get all 'shimmed' binaries prelinked against shipped core libs to avoid a current bunch of unsucesfull searches for libraries.... I thought it might provide a notable benefit. - -just an idea - -[[!meta author=yoh]] - -> [[fixed|done]], but without prelinking. --[[Joey]] diff --git a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment b/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment deleted file mode 100644 index 7ec438147..000000000 --- a/doc/todo/could_standalone___39__fixed__39___git-annex_binaries_be_prelinked__63__/comment_1_1bdc41c22f472d1d6adac563952fe354._comment +++ /dev/null @@ -1,59 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-06T15:59:34Z" - content=""" -Startup time is also particulary important when git-annex is being used as -a smudge/clean filter in v6 mode, since it's run once per file git operates -on. - ---- - -What I'd look at before prelinking is, does your git-annex executable -dynamically link haskell libraries? - -That was the case for a while in the standalone builds, until I noticed it -caused too much linker time and put it back to static linking of the -haskell libs. Leaving only 34 or so C shared libs. - ---- - -Did some preliminary benchmarking here of `git-annex version --raw` - -* deb package build: 0.04 seconds min -* deb package build prelinked: ~0.03 seconds min -* standalone build: 0.05 seconds min -* git-annex modified to print "hi" and exit immediately: 0.02 seconds min - -So, the overhead of the wrapper scripts for the standalone build is around -0.01 seconds. - -And, prelinking does help a little bit (although probably closer to 0.005 -seconds than 0.01; my measurements are too coarse to get a good number). - -Meanwhile, 0.02 seconds are used after git-annex starts up. This overhead -includes finding the path to the git repository, running and parsing `git -config --list`, etc. - -But what about that 0.02 seconds just to print "hi"...? - ----- - -With strace I noticed a very interesting thing. Despite being statically -linked against the haskell libraries, the linker searches in all their -paths for all C libraries. This adds around 30000 failed open() calls -to git-annex's startup. This is done even after prelinking. It must be a -significant part of the startup time. - -Filed a bug: <https://github.com/haskell/cabal/issues/3524> - -Put in a chrpath workaround, but only when git-annex is built with "make" -(not cabal install git-annex). - -Updated benchmarks: - -* deb package build: 0.02 seconds min -* deb package build prelinked: ~0.02 seconds min -* standalone build: 0.03 seconds min -* git-annex modified to print "hi" and exit immediately: 0.01 seconds min -"""]] diff --git a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn b/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn deleted file mode 100644 index 4e3c53e0a..000000000 --- a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already.mdwn +++ /dev/null @@ -1,4 +0,0 @@ - -While trying so establish a jabber link via a server that runs a nonstandard port I came across the problem that git-annex always appends :5222 to the jabber server address. This effectively stops the connection procedure at a point where it does not need to. - -> XMPP support has been removed from git-annex, so closing. [[done]] diff --git a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment b/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment deleted file mode 100644 index 275d54b15..000000000 --- a/doc/todo/dont_append___58__5222_to_jabber_hosts__44___if_a_different_port_has_been_specified_already/comment_1_bee9f8431a134e790c36b22d83bfb7ae._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-10T17:47:05Z" - content=""" -Well, the weppapp prompts for a XMPP address, which AFAIK does not include -a port. - -`.git/annex/creds/xmpp` can contain a port, but that's only used when -the SRV record lookup doesn't find anything. Since most XMPP servers -have SRV records, and SRV includes a port. - -AFAICS, if the SRV record includes a nonstandard port, it will be used. -If there's no SRV record, port 5222 will be used, unless you edit -`.git/annex/creds/xmpp` to use another port, and then what you specified -will be used. -"""]] diff --git a/doc/todo/drop_--batch.mdwn b/doc/todo/drop_--batch.mdwn deleted file mode 100644 index 775798752..000000000 --- a/doc/todo/drop_--batch.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -There is a dropkey --batch, so I guess I could workaround but probably would be nice for consistency to have --batch mode for drop itself as well - -[[!meta author=yoh]] - -> [[done]]; went ahead and added drop --batch to be symmetric with get -> --batch. --[[Joey]] diff --git a/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment b/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment deleted file mode 100644 index d921d9ee0..000000000 --- a/doc/todo/drop_--batch/comment_1_eff1bec0af5e7a7364d2fdaea6a8826f._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-05-03T19:06:53Z" - content=""" -Might be better to make `dropkey` do the same numcopies checking as -`drop` does. Currently, `dropkey` needs `--force` to do anything (and it's -always needed that), so it could do numcopies checking when not forced, -without breaking backwards compatability. - -The benefit of keeping this in `dropkey` is that dropping by key -tends to work better with batch adds/imports of files that are occurring at -the same time. - -Only downside I see is that dropping by key is unable to honor -.gitattributes numcopies settings, since the associated filename is not -known. -"""]] diff --git a/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn b/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn deleted file mode 100644 index 65575f8a1..000000000 --- a/doc/todo/external_special_remote_not_used_concurrently_with_-J.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -When using an external special remote with -Jn, multiple transfers do not -happen concurrently to the remote. A single process is -started for the external special remote, and there's locking to only let -one request be made of it at a time. - -This should not be hard to make to use a pool of Externals, starting up a -new one if the pool is empty or all in use. --[[Joey]] - -[[users/yoh]] may want this for datalad? - -> [[done]] --[[Joey]] diff --git a/doc/todo/find_unused_in_any_commit.mdwn b/doc/todo/find_unused_in_any_commit.mdwn deleted file mode 100644 index cfe2faab8..000000000 --- a/doc/todo/find_unused_in_any_commit.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -`git annex unused` only looks at tags and branches. Some users would like -to drop any objects that are not pointed to by any commit, but keep any -object that any commit ever referenced. - -This could be a switch, like --ever. - -The implementation would need to walk the history of all branches and check -all commits. This would tend to be slow. It could look at tags+branches as -it does now as a first pass, and only do the slow part if there are objects -not referred to by the tags+branches. And, it could stop looking through -the whole commit history if there were no more objects to check. Still, -gonna be slooow. Another optimisation would be to get only the objects -changed by the commit, and not look at the whole tree as it appeared on -each commit. --[[Joey]] - -> Closing, --used-refspec allows doing this kind of thing. -> (It can indeed make it slow!) [[done]] --[[Joey]] diff --git a/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment b/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment deleted file mode 100644 index 04fe62666..000000000 --- a/doc/todo/find_unused_in_any_commit/comment_1_cecdf4e8600fbcf5d1541e35a91fb37b._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnRFOsnEk8AJg1mXlq3mJDdt1YdYepozE8" - nickname="Murmel" - subject="Other loop strategy?" - date="2014-11-13T21:42:57Z" - content=""" -My motiviation to have such a feature is to free space if a key is unused in the \"--ever\" sense. I think it is no problem if this is a slow operation, as you don't use it often. How about this strategy: Loop over keys, for each key find out with something like \"git log -S\" if it is used. -"""]] diff --git a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment b/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment deleted file mode 100644 index 8d489927f..000000000 --- a/doc/todo/find_unused_in_any_commit/comment_2_ab373440bf7bab9179fdfccf6da3e8a4._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="eigengrau" - subject="comment 2" - date="2015-05-28T13:44:32Z" - content=""" -This would be absolutely awesome, because it would pruning away old data based on cut-offs. One could squash all history beyond some cut-off point. Or, probably better, one could preserve git history, but supply “git annex fsck” with a cut-off switch that specifies a date or time interval. All data referred to in commits older than the specified interval is then considered unused. -"""]] diff --git a/doc/todo/fix_git-annex-smudge.1.mdwn b/doc/todo/fix_git-annex-smudge.1.mdwn deleted file mode 100644 index 3daaa4619..000000000 --- a/doc/todo/fix_git-annex-smudge.1.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -Fixing errors in the git-annex-smudge manage. - -``` -The following changes since commit fa15580d1a55aef612a4a973e74e1728c371e98f: - - (2016-08-16 15:14:37 +0000) - -are available in the git repository at: - - https://git.jim.sh/jim/git-annex.git jim - -for you to fetch changes up to e2a55fdbaeb4acfd09910649689868f1c4f0625b: - - Don't escape leading dots in code blocks in manpage (2016-08-16 11:51:16 -0400) - ----------------------------------------------------------------- -Jim Paris (2): - Fix path in git-annex-smudge(1) - Don't escape leading dots in code blocks in manpage - - Build/mdwn2man | 2 +- - doc/git-annex-smudge.mdwn | 2 +- - 2 files changed, 2 insertions(+), 2 deletions(-) -``` - -> Thanks Jim. [[merged|done]] --[[Joey]] diff --git a/doc/todo/get_--batch.mdwn b/doc/todo/get_--batch.mdwn deleted file mode 100644 index a23b36de0..000000000 --- a/doc/todo/get_--batch.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It seems that it would be tremendously useful, see e.g. our [datalad install](https://github.com/datalad/datalad/issues/553) - -[[!meta author=yoh]] - -> [[done]] although the output while getting a file is not -> machine-parseable. So, I made --json also work for get, but enabling -> json output disables any progress display. --[[Joey]] diff --git a/doc/todo/get_round_robin.mdwn b/doc/todo/get_round_robin.mdwn deleted file mode 100644 index 25c3a8644..000000000 --- a/doc/todo/get_round_robin.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -`git annex get` always gets files from the remote with the lowest cost. - -When two remotes have the same cost, it breaks the tie somehow, -and consistently prefers one of them over the other. - -It would be nice if it instead round-robined amoung remotes with -the same cost that have the file. In particular, with -J2, and 2 remotes -A and B having each file, one thread could download from A and the other -from B. That might be much faster than the current behavior of two threads -downloading everything from A. - -Maybe a way to implement it is to keep a list of recently used remotes, -and when starting a new get from a set of remotes that have the same cost, -prefer the remote that is futher down the recently used list (or not on it -at all). (Or, since git-annex has a remote list already, it could rotate -the remotes of the same cost whenever starting a download from one.) - -While this would be a nice improvement to -J2 from network remotes, -it might not really be desirable when not run in parallel. In particular, -if A and B are on different spinning disks, then an access pattern of -A,B,A,B might keep the disks idle enough that they spin down in-between -access. - -> done for `git annex get -JN` where two remotes have the same cost. -> -> Also for `git annex sync --content -JN` when downloading and two remotes -> have the same cost. -> -> Can't think of any other places that apply, except perhaps the assistant, -> but it does its own much different queuing of transfers. [[done]] -> --[[Joey]] diff --git a/doc/todo/git_annex_push.mdwn b/doc/todo/git_annex_push.mdwn deleted file mode 100644 index 4abdf253c..000000000 --- a/doc/todo/git_annex_push.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -A common use case for me is to use annex as really just an addition to git to store additional content. What I am ending up with is two stage procedure to submit my changes to our shared repository: git push REMOTE; git annex copy --to=REMOTE . IMHO it would only be logical if there was "git annex push REMOTE [GITPUSHOPTIONS]" which would be merely an alias for "git push REMOTE [GITPUSHOPTIONS]; git annex copy --to=REMOTE" but which will make use of annex for such common usecase simple(r) - -> After this was opened, some options were added, so use: -> `git-annex sync --no-pull --content` -> -> [[done]] --[[Joey]] diff --git a/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment b/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment deleted file mode 100644 index 608f1f936..000000000 --- a/doc/todo/git_annex_push/comment_1_54c5494ec21621298b3111cd7c2325b1._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-08-04T20:19:22Z" - content=""" -`git annex sync --content` does what you want, only it also does a pull and -a merge from remotes. - -I don't know that wanting to only push, w/o pull and merge, is common -enough to make a separate command for it. - -There's also the problem that to push the git-annex branch, it really -makes sense to first pull/merge from the remote. Otherwise, the push -is not likely to work as well. And too, it makes sense to update the -git-annex branch from remotes in order to know what files that have, so -that info can be better used to decide which files to send to them -- -especially when preferred content might make some file not be sent to all -remotes, depending on which other remotes contain the file. -"""]] diff --git a/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment b/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment deleted file mode 100644 index 757824cb8..000000000 --- a/doc/todo/git_annex_push/comment_2_67938223c42c2a81dbfd32cd8a6a39c2._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-08-09T03:04:31Z" - content=""" - indeed pull/merge ( ie sync) would often be needed. but the same in regular git workflow - we can't push if remote has new changes. so we know that we need to \" git pull\" ( or alternative merge dance). my whining here is pretty much about dichotomy between regular git command and accompanying annex commands for simple typical workflows - i need to educate people much more beyond \" in your typical use case, when you all collaborate on this repo, just use git annex add to place big files under annex control, and then git annex push to push all your changes\". then if annex push checked first that push of annex branch can't happen and that annex merge is due, and let user know to run it first - they will do, and things will remain clear. now there is a lot of annex uniquely named commands which do not \" correlate\" with git ones even for simple use cases, which makes adoption harder imho. -"""]] diff --git a/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment b/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment deleted file mode 100644 index f28008d22..000000000 --- a/doc/todo/git_annex_push/comment_3_ccb822eeb9b0d60f811568e4f27f970a._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2015-08-11T17:37:05Z" - content=""" -I tend to be uncomfortable with wrapping many git commands into git-annex -commands with the same name. All the regular git commands can be used -in a git-annex repository, and I don't want to get users thinking they need -to look for git-annex commands instead when the git commands work perfectly -well. - -`git annex copy` is fundamentally different than `git push`, so the user -needs to learn about the complication of needing to copy the contents -around separately. Perhaps even copying content to different (special) -remotes than where git pushes to. `git annex sync --content` is there for -users who want to keep two repos in sync and don't want to be concerned with the details. -`git annex push` would seem to be for users who want to know about the details, -but not all of them. Seems like a losing and/or confusing choice. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn b/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn deleted file mode 100644 index 68125c53b..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -It would be really nice if external tools working with annex could obtain updates on the progress of operations so they could report using their own UI back to the user. Especially relevant for --batch --json modes of operations (e.g. for get or addurl) whenever no progress is reported by annex itself at all. - -Related: -[datalad #478](https://github.com/datalad/datalad/issues/478) - - -[[!meta author=yoh]] - -> --status-fd is one way, or the progress could be included as -> part of the --batch protocol. In either case, it might make sense to -> reuse part of the external special remote protocol. (Which would let you -> relay the progress messages when datalad is doing a nested retrieval, I -> suppose.) --[[Joey]] - ->> [[done]]; --json-progress implemented. I limited the frequency of json ->> progress items to 10 per second max, and it's typically only 1 per ->> second or less, so didn't implement ->> --json-progress=N to tune it. Also added --json and --json-progress to ->> copy, move, mirror commands. --[[Joey]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment deleted file mode 100644 index df74f19cb..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_1_b71937cb772b3400839755bb11a1ffe4._comment +++ /dev/null @@ -1,65 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-09-08T15:32:00Z" - content=""" -yoh pointed out in email that reusing the special remote interface would -not work with -J because it doesn't tell what key progress is being shown -for. - -Also, note that --json -J does not currently output json; -J overrides the ---json to instead use concurrent-output for progress display. The current -way that json is emitted incrementally would need to be changed to be usable -with -J. - -Is there any need for a program that is driving git-annex with --json -to use -J, instead of just starting several git-annex processes? The only -major benefit I can think of is the recently added better selection between -multiple remotes by parallel `git annex get`. Other performance benefits -between -J and multiple processes should mostly be small. - -To suppose --json -J, instead of a partial json object that later gets added -to as the command progresses: - - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..." - -We'd need something like this, with each json object buffered -and only output when it was complete (and output serialized so -objects are written one at a time): - - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...", "inprogress":true} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","success":true} - -If we're doing that, we might as well use json for the progress info too, -in between the two json objects in the example above: - - {"percent-progress":"25%","byte-progress":500,"key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3"} - {"percent-progress":"75%","byte-progress":1500","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3"} - -But this is a large change to the json format, and would probably break -all consumers of it. I don't like that, but also don't like the complexity -of having two different varieties of json output for parallel and -non-parallel modes. - -Hmm, if we're buffering the "command" json objects, we could keep them -formatted the same as they are now, only displaying them when done. And -progress objects could be inserted before: - - {"percent-progress":"25%","byte-progress":500,"key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar"} - {"percent-progress":"75%","byte-progress":1500","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar"} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -That seems a bit verbose, but I think all that info could be needed by -consumers of the progress objects. Hmm, since the "command" json objects -are being buffered, we could even include the currently buffered object -nested inside the progress object: - - {"percent-progress":"25%","byte-progress":500,"action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"percent-progress":"75%","byte-progress":1500,"action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -That's not a lot more verbose than the earlier version, and it ensures that -consumers of the progress objects have all possible information available -(including the name of the remote being downloaded from in the above -example). -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment deleted file mode 100644 index af8304052..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_2_f0271ed42caddb12d06f6430b8cb79f0._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-09-08T16:12:07Z" - content=""" -sounds good to me... the only remark that to not break compatibility with other git-annex consumers may be there could be additional switch to instruct annex to produce those progress records (e.g. --json-progress) which would only then provide progress reporting back, thus by default staying compatible with current behavior. - -as for -J - I guess indeed we could start multiple parallel annex processes operating on the same repository, but I wonder if then necessary locking etc between multiple processes wouldn't introduce additional performance hit etc. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment deleted file mode 100644 index 33e05de54..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_3_613636dabfaaeee187f54923437d89ac._comment +++ /dev/null @@ -1,24 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-09-08T16:20:27Z" - content=""" -Needing to use file-level locking etc does make the mult-process approach -to parallelism more expensive, but only I think by a small amount. - -Yes, there might need to be a switch to enable the json progress output. -Although given the un-typed nature of json, consumers should probably be -written with a plan in mind for what to do if they encounter something they -don't understand. Any comsumer that just skips over unrecognised json -objects would not be impacted by adding the progress.. - -And here's a way to make the progress json less verbose: - - {"progress-id":"1","action":{"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1..."}} - {"progress-id":"1","percent-progress":"25%","byte-progress":500} - {"progress-id":"1","percent-progress":"75%","byte-progress":1500} - {"command":"get","key":"SHA256E-s5242880--82cb4363f596cb66e7bc6e4cbfd2bfe8a8b6ac7e6d02557cc0e3944ec8faafc3","file":"bar","note":"from d1...","success":true} - -Makes the consumer's job a bit more complicated, and could also make the -implementation in git-annex harder. Is it worth it? -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment deleted file mode 100644 index 4c5e82dcf..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_4_b4a1790fc4e7a7999dde819be81b4b0d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-09-08T16:27:04Z" - content=""" ---json-progress=1 would also provide a way to tune how frequently the -progress updates happen (eg max once per second). Which seems better than -worrying about how large the json objects are. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment deleted file mode 100644 index d82cca98a..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_5_6cbe08fc84141f1c7c31d737ae5bdce0._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 5" - date="2016-09-08T18:08:49Z" - content=""" -good idea on parametrizing frequency of updates from json -- indeed we wouldn't want to deal with output from it probably more often than once in a second per file. Either \"skinny\" progress indication using IDs or full ones (so we could match by e.g. key) would work for us I think - -btw, just so that we don't forget. I guess all of this would also be needed to be done for addurl, copy, move commands, right? (copy and move do not have --json yet) ;) -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment deleted file mode 100644 index 5b1134be8..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="+may be "byte-target" field? ;)" - date="2016-09-24T02:43:21Z" - content=""" -THANK YOU for implementing this feature -- we will make use of it soon. -But so we don't do reverse estimation from \"byte-progress\" and \"percent-progress\", and didn't have to get it from a key (which might not have it e.g. in case of URL relaxed backend) -- could you just include in each record the \"byte-target\" (if known) or something like that? ;) thanks in advance! -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment deleted file mode 100644 index 2acb1e16c..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_7_dc29d3603ce7ce436fac7fa6d6f80871._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 7""" - date="2016-09-29T20:27:46Z" - content=""" -Added a "total-size" field for the size. Although, if a key's size is not -known, git-annex does not currently do any progress displays for that key. -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment deleted file mode 100644 index 0de769a5d..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_8_2e11e383dd4e95e8a3df30039face3eb._comment +++ /dev/null @@ -1,7 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 8" - date="2016-09-29T20:45:48Z" - content=""" -extracting size from a key I have done myself already ;) but what if it is for a relaxed download - it still wouldn't show (based on the downloader's information)? (yet to build/try to discover myself) -"""]] diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment deleted file mode 100644 index 280cb3116..000000000 --- a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_9_32bfa465567eaad105a8336bc247cc2f._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 9""" - date="2016-09-29T20:58:13Z" - content=""" -Gone ahead and made --json-progress be displayed when size is not known, -although of course it then has to omit the total-size and percent-progress -fields. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn b/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn deleted file mode 100644 index b80349a76..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -ATM git annex addurl ignores annex.largefiles option so to automate annexification or direct add to git for a list of files I need manually to download each one of them into a FILE and then "git annex add -c annex.largefiles='exclude=*.txt' FILE". But it would have been convenient if I could "addurl" some files directly from urls directly into git, as per largefiles settings. - -N.B. I do understand that use-case might be somewhat vague, let me know if I should expand reasoning -[[!meta author=yoh]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment deleted file mode 100644 index cde0cd873..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_1_054568fa73fdff81b05ffd1dc7199cee._comment +++ /dev/null @@ -1,15 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-11-10T19:04:50Z" - content=""" -When addurl --relaxed is used, it doesn't hit the url at all, so doesn't -know the size, so annex.largefiles couldn't be applied in that case. - -So that's an inconsistency. Perhaps a minor one. - -`git annex import` doesn't currently honor annex.largefiles either. - -I am ambivilant about whether these commands should, but it probably makes -sense for them to behave the same. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment deleted file mode 100644 index 6f0681698..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_2_110a15c95e76b4771e31c06eb80d1f03._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2015-11-10T19:24:59Z" - content=""" -as for import (never used it yet) -- there is no reason not to warrant largefiles since it has all the information, right? - -as for addurl -- ideally, I guess, it could just crash iff there is a largefiles setting which relies on size and --relaxed is used (would indeed make little sense). But in the other cases (I guess of which there is majority) it could as well warrant it, thus making behavior more consistent. - -[[!meta author=yoh]] -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment deleted file mode 100644 index 1357e8783..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_3_892f232c8b8746cac01b5a80239985a2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="another side-effect of largefiles not being supported for my usecase" - date="2016-01-12T17:20:08Z" - content=""" -since there is no support for largefiles in addurl, is there ANY way to get idea either annex would have added a file to git or to annex if I do know the filename and its size? pretty much a use-case is downloading/adding (small) .txt files to git, while the rest to annex in --fast (or --relaxed) mode. -If there is no way to query annex'es opinion given necessary information, I would have no ability to decide on my end without duplicating largefiles checking logic. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment deleted file mode 100644 index 46468997a..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_4_4721f94167bcec5841ce8432347fbc0d._comment +++ /dev/null @@ -1,11 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-01-13T19:11:33Z" - content=""" -Er, re your last comment, I closed this bug because I made addurl honor -annex.largefiles.. - -That was done in December 8th. AFAICS, there's nothing more to be done -except use that feature. -"""]] diff --git a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment b/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment deleted file mode 100644 index 3f362489b..000000000 --- a/doc/todo/make_addurl_respect_annex.largefiles_option/comment_5_16390f75b3685df93f18a89e7cb56757._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject=""done" but only for non --fast/--relaxed" - date="2016-01-13T23:49:30Z" - content=""" -ah -- didn't spot that it was \"done\" (didn't see a notification on it being resolved in invoice or emails) - -unfortunately it seems to not work for --fast (or --relaxed, although that one I guess I can understand): - -[[!format sh \"\"\" - -$ chmod a+w -R /tmp/123; rm -rf /tmp/123; mkdir /tmp/123; cd /tmp/123; git init; git annex init; -Initialized empty Git repository in /tmp/123/.git/ -init ok -(recording state in git...) - -$ git -c annex.largefiles=exclude=*.txt annex addurl --file=test.txt --fast \"http://www.onerussian.com/tmp/banner.png\" -addurl test.txt ok -(recording state in git...) - -$ ls -l test.txt -lrwxrwxrwx 1 yoh yoh 132 Jan 13 18:44 test.txt -> .git/annex/objects/KW/kj/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png/URL-s25319--http&c%%www.onerussian.com%tmp%banner.png - -\"\"\"]] - -it does for if no --fast, or --relaxed -"""]] diff --git a/doc/todo/make_status_show_staged_files.mdwn b/doc/todo/make_status_show_staged_files.mdwn deleted file mode 100644 index 4d418bc11..000000000 --- a/doc/todo/make_status_show_staged_files.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -### Please describe the problem. - -`git annex status` does not report the fact that some files have been added but not yet committed. - -### What steps will reproduce the problem? - - $ # alwayscommit = false - $ echo "new" > new-file - $ git annex status - ? new-file - $ git annex add - add new-file - $ git annex status - $ - -Using the `git status` command directly will show the added files - - $ git -c core.bare=false status --porcelain | grep -v '^ T' - AT new-file - -### What version of git-annex are you using? On what operating system? - -git-annex version: 5.20141024-g613f396 - -> [[done]] --[[Joey]] diff --git a/doc/todo/metadata_--batch.mdwn b/doc/todo/metadata_--batch.mdwn deleted file mode 100644 index b65dc3ef5..000000000 --- a/doc/todo/metadata_--batch.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -[[!meta author=yoh]] - -> [[done]] (using json input) --[[Joey]] diff --git a/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment b/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment deleted file mode 100644 index 54cbe6fa6..000000000 --- a/doc/todo/metadata_--batch/comment_1_5cfe3b1a2847cfddd46ab6be249a74e4._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-19T19:18:41Z" - content=""" -The metadata command is pretty complex. A batch interface would need to -cover both setting and getting. - -There are four different ways to change a value, so it would probably -make sense for the input to be of the form "file field=value" -or "file field+=value" or "file field-=value" or "file field?=value" - -A field can have multiple values, including "". So, a batch interface -to querying the value would need to handle that in its output. Perhaps -json output? -"""]] diff --git a/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment b/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment deleted file mode 100644 index 5b39175a9..000000000 --- a/doc/todo/metadata_--batch/comment_2_6230fe7d6a7b6156b74b7f4e3641c200._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="comment 2" - date="2016-02-19T20:06:19Z" - content=""" -yes -- json output would probably be the best -I know that other --batch functions do not take json input, but I wonder if it might make sense here as well? smth like {'file': 'filename', 'add-field': {'field1': 'value1'}, 'remove-field': ..., 'add-tag': ['tag1', 'tag2'], 'remove-tag': ['... and so on. -"""]] diff --git a/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment b/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment deleted file mode 100644 index 38dcd7d8c..000000000 --- a/doc/todo/metadata_--batch/comment_3_23c88eab56628fd2f75aceb21f59992e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-02-19T20:47:28Z" - content=""" -See -<http://git-annex.branchable.com/todo/ability_to_set_metadata_from_json/> - -If it does support json input, the simplest interface would be to use the -same json objects for both output and input. - -Both aeson and json are currently dependencies, and either could be used to -parse json input. -"""]] diff --git a/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment b/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment deleted file mode 100644 index 4cd0f2d34..000000000 --- a/doc/todo/metadata_--batch/comment_4_c72eb16b630b200265e125ebaf7d0d36._comment +++ /dev/null @@ -1,36 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-07-25T17:39:37Z" - content=""" ---batch mode should be usable to get current metadata, set new -metadata, and remove existing metadata. The non-batch metadata command has -different syntaxes for all of these, but it would be good to have a single -interface that handles all three in batch mode. - -It could read a line containing the file or key, with any metadata -fields that should be changed: - - {"file":"foo"} - {"file":"foo","author":["bar"]} - {"key":"SHA...","author":[]} - -And reply with *all* the metadata, in nearly the same format: - - {"file":"foo","key":"SHA...","author":["bar"],lastchanged:["date"],"success":true} - -And that reply could in turn be edited and fed back in to change the -metadata. - ----- - -There's a DRY problem here because there's the current JSON generator code, -and I'd have to add an Aeson parser to parse the JSON input. But, Aeson -parsers also automatically have a matching generator, which is guaranteed -to generate code that the parser can parse. - -So, it would be nice to use the Aeson JSON generator, instead of the -current one, but that can only be done if the JSON is formatted the same, -or close enough that nothing currently consuming `metadata --json` will -break. -"""]] diff --git a/doc/todo/operate_on_branch_contents.mdwn b/doc/todo/operate_on_branch_contents.mdwn deleted file mode 100644 index 533e1ab87..000000000 --- a/doc/todo/operate_on_branch_contents.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Currently, commands can operate on specific files in the working tree, -or on all known keys, or on a specific key. It would be useful to have -something like `--branch foo` which would operate on the files present in -the specified branch. - -For example, this would be useful in bare repos to fsck only the master -branch, and not all versions of all keys. - -It might be worth allowing a full refspec, so that eg `refs/remotes/*/master` -or `refs/tags/*` can be operated on. --[[Joey]] - -> This should be pretty easy to implement, using `git ls-tree` -> to enumerate the contents of the ref. -> -> The wrinkle is that for --all, the name of each key is shown as it's -> operated on. But in this case, we want to instead display something like -> "ref:filename". -> -> So, every command that supports --branch (which probably -> should be all the ones currently supporting --all) will need to be -> modified, to be provided some new data type that is not FilePath to a -> work tree file, but something to display while operating on an item. -> -> Not a hard change to make, but an extensive one. --[[Joey]] - ->> I've implemented the first part of this, so --branch works ->> but the name of the key is shown, rather than the file from the branch. ->> --[[Joey]] - ->>> All [[done]] now. --[[Joey]] diff --git a/doc/todo/optimise_git-annex_merge.mdwn b/doc/todo/optimise_git-annex_merge.mdwn deleted file mode 100644 index ff2da3209..000000000 --- a/doc/todo/optimise_git-annex_merge.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -Typically `git-annex merge` is fast, but it could still be sped up. - -`git-annex merge` runs `git-hash-object` once per file that needs to be -merged. Elsewhere in git-annex, `git-hash-object` is used in a faster mode, -reading files from disk via `--stdin-paths`. But here, the data is not -in raw files on disk, and I doubt writing them is the best approach. -Instead, I'd like a way to stream multiple objects into git using stdin. -Sometime, should look at either extending git-hash-object to support that, -or possibly look at using git-fast-import instead. - -> Well, I went with git hash-object --stdin-paths despite it needing to read from -> temp files. --[[Joey]] - ---- - -`git-annex merge` also runs `git show` once per file that needs to be -merged. This could be reduced to a single call to `git-cat-file --batch`, -There is already a Git.CatFile library that can do this easily. --[[Joey]] - -> This is now done, part above remains todo. --[[Joey]] - ---- - -Merging used to use memory proportional to the size of the diff. It now -streams data, running in constant space. This probably sped it up a lot, -as there's much less allocation and GC action. --[[Joey]] - -[[done]] diff --git a/doc/todo/parallel_get.mdwn b/doc/todo/parallel_get.mdwn deleted file mode 100644 index fb3f8d098..000000000 --- a/doc/todo/parallel_get.mdwn +++ /dev/null @@ -1,85 +0,0 @@ -Wish: `git annex get [files] -jN` should run up to N downloads of files -concurrently. - -This can already be done by just starting up N separate git-annex -processes all trying to get the same files. They'll coordinate themselves -to avoid downloading the same file twice. - -But, the output of concurrent git annex get's in a single teminal is a -mess. - -It would be nice to have something similar to docker's output when fetching -layers of an image. Something like: - - get foo1 ok - get foo2 ok - get foo3 -> 5% 100 KiB/s - get foo4 -> 3% 90 KiB/s - get foo5 -> 20% 1 MiB/s - -Where the bottom N lines are progress displays for the downloads that are -currently in progress. When a download finishes, it can scroll up the -screen with "ok". - - get foo1 ok - get foo2 ok - get foo5 ok - get foo3 -> 5% 100 KiB/s - get foo4 -> 3% 90 KiB/s - get foo6 -> 0% 110 Kib/S - -This display could perhaps be generalized for other concurrent actions. -For example, drop: - - drop foo1 ok - drop foo2 failed - Not enough copies ... - drop foo3 -> (checking r1...) - drop foo4 -> (checking r2...) - -But, do get first. - -Pain points: - -1. Currently, git-annex lets tools like rsync and wget display their own - progress. This makes sense for the single-file at a time get, because - rsync can display better output than just a percentage. (This is especially - the case with aria2c for torrents, which displays seeder/leecher info in - addition to percentage.) - - But in multi-get mode, the progress display would be simplified. git-annex - can already get percent done information, either as reported by individiual - backends, or by falling back to polling the file as it's downloaded. - -2. The mechanics of updating the screen for a multi-line progress output - require some terminal handling code. Using eg, curses, in a mode that - doesn't take over the whole screen display, but just moves the cursor - up to the line for the progress that needs updating and redraws that - line. Doing this portably is probably going to be a pain, especially - I have no idea if it can be done on Windows. - - An alternative would be a display more like apt uses for concurrent - downloads, all on one line: - - get foo1 ok - get foo2 ok - get [foo3 -> 5% 100 KiB/s] [foo4 -> 3% 90 KiB/s] [foo5 -> 20% 1 MiB/s] - - The problem with that is it has to avoid scrolling off the right - side, so it probably has to truncate the line. Since filenames - are often longer than "fooN", it probably has to elipsise the filename. - This approach is just not as flexible or nice in general. - -See also: [[parallel_possibilities]] - -> I am looking at using the ascii-progress library for this. -> It has nice support for multiple progress bars, and is portable. -> I have filed 7 issues on it, around 4 of which need to get fixed before -> it's suitable for git-annex to use.. --[[Joey]] - ->> `git annex get -JN` works now, but lacks any progress display. ->> Waiting on some updates to ascii-progress. --[[Joey]] - ->>> Wrote concurrent-output; [[done]] --[[Joey]] - -[[!meta author=yoh]] diff --git a/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment b/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment deleted file mode 100644 index 327e7a315..000000000 --- a/doc/todo/parallel_get/comment_1_5b7517214148731f81be6e61233ce13c._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="spinning wheel" - date="2014-12-22T20:33:44Z" - content=""" -Just tried torrents backend -- it works -- THANKS!!! -But amount of output dumped upon user is somewhat outstanding (I can't even scroll terminal back far enough for 1 file fetch). May be for such backends, where no easy/reasonable way to estimate progress it would be possible at least to have some spinning wheel animation which would react (spin) to any output received from the corresponding downloader/backend? (unless in debug mode in which normal output probably should be shown as well) -"""]] diff --git a/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment b/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment deleted file mode 100644 index a454de31a..000000000 --- a/doc/todo/parallel_get/comment_2_c8548608023ef3d95035fe97164c8cd7._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="even less verbose" - date="2014-12-23T16:50:36Z" - content=""" -While working on this one, might be worth even reserving even a quieter mode of operation which would e.g. just report a # of already processed files. e.g. - -\"0% done: fetched 100 out of 1,234,567 files\" - -;-) ? -"""]] diff --git a/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment b/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment deleted file mode 100644 index 0fecfc514..000000000 --- a/doc/todo/parallel_get/comment_3_36bfc494c34a6701c4780d13d669ff71._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY" - nickname="Yaroslav" - subject="comment 3" - date="2014-12-23T16:52:43Z" - content=""" -actually a similar or exactly the same summary line might be worth appearing in the \"regular\" mode as well to give user better estimate of overall progress. If total size is known, it would also be nice if overall % in size (not just a # of items) was reported -"""]] diff --git a/doc/todo/pass_-S_to_commit-tree.mdwn b/doc/todo/pass_-S_to_commit-tree.mdwn deleted file mode 100644 index ecd7dc70e..000000000 --- a/doc/todo/pass_-S_to_commit-tree.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -In git 2.9.0, commit-tree does not respect commit.gpgsign on its own, -which it used to. - -So, in Git.Branch.commitTree, it needs to check if gpgsign is set, -and pass -S to commit-tree. - -(commit-tree -S works in older versions of git, so this can -be done without version checks.) - ---[[Joey]] - -> [[done]] --[[Joey]] diff --git a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn b/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn deleted file mode 100644 index cb48db344..000000000 --- a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog.mdwn +++ /dev/null @@ -1,147 +0,0 @@ -Hi, -these three patches sort .mailmap to get consistent ordering, add nine -names with proper emails to it, and then there is the third one, which -contains all the joeyh changes. I put them in a separate patch in case -you have other opinions about that. - -I notice you're not a fan of GitHub pull requests, and attachments -wasn't allowed here, so I just paste a `cat 000* >all.patch` here, hope -that's ok. The branches are also available from -<https://github.com/sunny256/git-annex> as the branches "edit-mailmap" -(this version) and "edit-mailmap.wip" (the whole process) in case that's -easier. - -There will be more "useful" patches in the future, have started browsing -"Learn you a Haskell for great good", it's awesome. I'll have to get the -build working first, though. There is some dependency problem: - -[[!format hs """ - -$ make -if [ "cabal " = ./Setup ]; then ghc --make Setup; fi -cabal configure -Resolving dependencies... - -Utility/Exception.hs:25:18: - Could not find module `Control.Monad.Catch' - Perhaps you meant - Control.Monad.CatchIO (from MonadCatchIO-mtl-0.3.0.4) - Control.Monad.Cont (needs flag -package mtl-2.1.1) - Control.Monad.State (needs flag -package mtl-2.1.1) - Use -v to see a list of the files searched for. -make: *** [Build/SysConfig.hs] Error 1 - -"""]] - -Mentioning it just in case you have a quick solution. Have tried to fix -it by summoning cabal in various ways, but no luck yet. The OS used is -Debian GNU/Linux 7.8 (wheezy) on x86_64. - -[[!format sh """ - -From 20317aff9fbb8662aaeda4aa2285f92e728adc58 Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Sat, 2 May 2015 17:22:48 +0200 -Subject: [PATCH 1/3] Filter .mailmap through "sort -u" for predictability - ---- - .mailmap | 4 ++-- - 1 file changed, 2 insertions(+), 2 deletions(-) - -diff --git a/.mailmap b/.mailmap -index 275b236..5d51042 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -1,7 +1,7 @@ - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> --Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> -+Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> - Yaroslav Halchenko <debian@onerussian.com> - Yaroslav Halchenko <debian@onerussian.com> http://yarikoptic.myopenid.com/ <site-myopenid@web> - Yaroslav Halchenko <debian@onerussian.com> https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY <Yaroslav@web> --Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> --- -2.4.0 - -From b216bfdb3ab65f025e46c7fcdc86db3a3440b0af Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Mon, 4 May 2015 15:36:41 +0200 -Subject: [PATCH 2/3] .mailmap: Add nine more uncontroversial names - -Including only those with a proper email where there is no doubt about -which is the correct one. ---- - .mailmap | 13 +++++++++++++ - 1 file changed, 13 insertions(+) - -diff --git a/.mailmap b/.mailmap -index 5d51042..2dafcea 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -1,7 +1,20 @@ -+Antoine Beaupré <anarcat@koumbit.org> anarcat <anarcat@web> -+Antoine Beaupré <anarcat@koumbit.org> https://id.koumbit.net/anarcat <https://id.koumbit.net/anarcat@web> -+Greg Grossmeier <greg@grossmeier.net> http://grossmeier.net/ <greg@web> -+Jimmy Tang <jtang@tchpc.tcd.ie> jtang <jtang@web> -+Joachim Breitner <mail@joachim-breitner.de> http://www.joachim-breitner.de/ <nomeata@web> - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <Johan@web> -+Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <http://johan.kiviniemi.name/@web> -+Nicolas Pouillard <nicolas.pouillard@gmail.com> http://ertai.myopenid.com/ <npouillard@web> -+Peter Simons <simons@cryp.to> Peter Simons <simons@ubuntu-12.04> -+Peter Simons <simons@cryp.to> http://peter-simons.myopenid.com/ <http://peter-simons.myopenid.com/@web> -+Philipp Kern <pkern@debian.org> http://phil.0x539.de/ <Philipp_Kern@web> - Richard Hartmann <richih@debian.org> https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U <Richard@web> - Yaroslav Halchenko <debian@onerussian.com> - Yaroslav Halchenko <debian@onerussian.com> http://yarikoptic.myopenid.com/ <site-myopenid@web> - Yaroslav Halchenko <debian@onerussian.com> https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY <Yaroslav@web> -+Øyvind A. Holm <sunny@sunbase.org> http://sunny256.sunbase.org/ <sunny256@web> -+Øyvind A. Holm <sunny@sunbase.org> https://sunny256.wordpress.com/ <sunny256@web> --- -2.4.0 - -From b730720bf85217051b0bd6414650f3bfd5928edb Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Mon, 4 May 2015 15:46:29 +0200 -Subject: [PATCH 3/3] .mailmap: Add all variations for Joey Hess - ---- - .mailmap | 8 ++++++++ - 1 file changed, 8 insertions(+) - -diff --git a/.mailmap b/.mailmap -index 2dafcea..3013a39 100644 ---- a/.mailmap -+++ b/.mailmap -@@ -3,9 +3,17 @@ Antoine Beaupré <anarcat@koumbit.org> https://id.koumbit.net/anarcat <https://i - Greg Grossmeier <greg@grossmeier.net> http://grossmeier.net/ <greg@web> - Jimmy Tang <jtang@tchpc.tcd.ie> jtang <jtang@web> - Joachim Breitner <mail@joachim-breitner.de> http://www.joachim-breitner.de/ <nomeata@web> -+Joey Hess <id@joeyh.name> Joey Hess <joey@gnu.kitenet.net> -+Joey Hess <id@joeyh.name> Joey Hess <joey@kitenet.net> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@debian.org> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@fischer.debian.org> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@joeyh.name> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.tam-lin.net> -+Joey Hess <id@joeyh.name> Joey Hess <joeyh@oberon.underhill.private> - Joey Hess <id@joeyh.name> http://joey.kitenet.net/ <joey@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <http://joeyh.name/@web> - Joey Hess <id@joeyh.name> http://joeyh.name/ <joey@web> -+Joey Hess <id@joeyh.name> https://www.google.com/accounts/o8/id?id=AItOawmJfIszzreLNvCqzqzvTayA9_9L6gb9RtY <Joey@web> - Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <Johan@web> - Johan Kiviniemi <devel@johan.kiviniemi.name> http://johan.kiviniemi.name/ <http://johan.kiviniemi.name/@web> - Nicolas Pouillard <nicolas.pouillard@gmail.com> http://ertai.myopenid.com/ <npouillard@web> --- -2.4.0 - -"""]] - -> [[merged|done]] --[[Joey]] -> -> Control.Monad.Catch should be provided by the exceptions package, -> which there is a dependency on in the cabal file. However, building -> git-annex on wheezy is not supported anymore. --[[Joey]] diff --git a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment b/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment deleted file mode 100644 index 474c61c1e..000000000 --- a/doc/todo/patch__58___Add_names_to_.mailmap_to_remove_duplicates_from_git_shortlog/comment_1_031c5a4afe9453a5b62004c85e7e7192._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://sunny256.wordpress.com/" - nickname="sunny256" - subject="Character encoding error" - date="2015-05-06T14:53:50Z" - content=""" -Hm, seems as there are some character encoding problem there, two names (Antoine Beaupré and mine) in the second patch. The infamous 'Ø' strikes again. Just wanted to mention it so the patch doesn't introduce errors. Maybe it's safest to fetch it from GitHub. -"""]] diff --git a/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn b/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn deleted file mode 100644 index 87a0428f0..000000000 --- a/doc/todo/patch__58___Command__47__Unused.hs__58___Change_--unused-refspec_back_to_--used-refspec.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -This patch is also available from the "used-refspec-fix" branch at <https://github.com/sunny256/git-annex/>. - -[[!format hs """ - -From e47e743327e519eaa07817c610b08b0e6844ca8e Mon Sep 17 00:00:00 2001 -From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= <sunny@sunbase.org> -Date: Tue, 8 Sep 2015 14:29:25 +0200 -Subject: [PATCH] Command/Unused.hs: Change --unused-refspec back to - --used-refspec - -Fix typo in commit 160d4b9 ("convert Unused, and remove some dead code -for old style option parsing", 2015-07-10), the "git-annex unused ---used-refspec" option was incorrectly changed to --unused-refspec. ---- - Command/Unused.hs | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/Command/Unused.hs b/Command/Unused.hs -index a383d56..4756cda 100644 ---- a/Command/Unused.hs -+++ b/Command/Unused.hs -@@ -53,7 +53,7 @@ optParser _ = UnusedOptions - <> help "remote to check for unused content" - )) - <*> optional (option (eitherReader parseRefSpec) -- ( long "unused-refspec" <> metavar paramRefSpec -+ ( long "used-refspec" <> metavar paramRefSpec - <> help "refs to consider used (default: all branches)" - )) - --- -2.6.0.rc0.24.gec371ff -"""]] - -> applied, thanks! [[done]] --[[Joey]] diff --git a/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn b/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn deleted file mode 100644 index c7f7ce6cc..000000000 --- a/doc/todo/refactor_shebang_handling_code_for_wider_use.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -Per: https://github.com/DanielDent/git-annex-remote-rclone/pull/10 - -When launching an external special remote, use the shebang handling code which currently exists elsewhere in git-annex - -[joeyh] """Oh, git-annex already deals with this particular windows nonsense elsewhere. When it needs to run a git hook, it parses it for a shebang. Git for windows does the same. - -So, if you can please open a todo item in git-annex, I can refactor that existing code to be used in more places.""" - -> [[done]] --[[Joey]] diff --git a/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn b/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn deleted file mode 100644 index 504af11b8..000000000 --- a/doc/todo/return___34__key__34___entry_in_--json_output_for_addurl___40__and_future_add__41___--batch.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -You have noted that somewhere (may be in email), that it might help us to pipeline things if 'add' was returning the key if file was added to the annex. I guess the same could apply to 'addurl' so decided to mark this separate todo - -[[!meta author=yoh]] - -> already done earlier today [[done]] --[[Joey]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn deleted file mode 100644 index 0b0faea90..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -I'm setting up an Android build environment, and the standalone/android/install-haskell-packages script fails while installing the Magic package. The standalone/android/buildchroot-inchroot package should run `apt-get -y install libmagic-dev` to install this dependency. - -> [[done]] --[[Joey]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment deleted file mode 100644 index 9993b6332..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_1_daef0416d365b60d36e211adcdb42ffb._comment +++ /dev/null @@ -1,19 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 1" - date="2016-02-21T05:15:57Z" - content=""" -I got further along in the build process, but cabal couldn't install the \"arm-linux-androideabi-4.8\" versions of `magic` and `terminal-size`. The magic library couldn't be installed because there wasn't an appropriate C library available. The terminal-size library failed with the following compilation error. - -``` -Posix.hsc: In function '_hsc2hs_test11': -Posix.hsc:32:39: error: invalid application of 'sizeof' to incomplete type 'struct winsize' -In file included from /home/builder/.ghc/android-14/arm-linux-androideabi-4.8/sysroot/usr/include/sys/types.h:33:0, - from /home/builder/.ghc/android-14/arm-linux-androideabi-4.8/sysroot/usr/include/unistd.h:33, - from Posix.hsc:21: -Posix.hsc: In function '_hsc2hs_test15': -Posix.hsc:35:48: error: invalid use of undefined type 'struct winsize' -... -``` -"""]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment deleted file mode 100644 index 4c626bba9..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_2_b56653f1c57acf70eb2ed3abb4546844._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 3""" - date="2016-02-23T14:55:36Z" - content=""" -My android builds include neither magic nor concurrent-output (which is -what's using terminal-size). I don't feel it's worth trying to get -these features working on androd. - -So, I've adjusted install-haskell-packages to disable the flags. - -If you are interested in working on the android port, I'd be very excited -for any help. As you can see, there is much room for improvement in the -build system for it. (It would be nice to rework it to use stack, rather -than the current approach, and using stack would automatically disable -these flags that are not portable.) And of course, there are many other -parts of the android port that need improvement. -"""]] diff --git a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment b/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment deleted file mode 100644 index 1ffb94cf0..000000000 --- a/doc/todo/standalone__47__android__47__buildchroot-inchroot_should_install_libmagic-dev/comment_3_501a89c819d0e1531a8bc6548c837a77._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="divergentdave@5c17d06f6d67c6f157b76a4cc95ca764b7d2f899" - nickname="divergentdave" - subject="comment 3" - date="2016-02-26T03:56:41Z" - content=""" -It looks like the flag in that change was incorrect. I had to change it to `--flags=\"-magicmime -concurrentoutput\"`. (no hyphen between current and output) After that, I was able to reinstall the libraries. - -I'd be happy to lend a hand, expect more patches! -"""]] diff --git a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn b/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn deleted file mode 100644 index bb8cbd161..000000000 --- a/doc/todo/support_--allow-unrelated-histories_in_git_2.8.1pre.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -git merge has recently been made to refuse to merge disconnected histories -unless --allow-unrelated-histories is passed. This will break uses of the -webapp, eg local pairing until git-annex is changed to pass that whenever -it runs `git merge`. - -It could also perhaps break uses of `git annex sync` where a remote with a -disconnected history is added and it's expected to merge with it. Although -in this latter case, it might be argued that the default git behavior has -changed and `git annex sync` should follow suite. - -(Also, any uses of `git pull` currently would need to -be split into a fetch and a merge in order to pass the option to the merge; -but AFAICS, git-annex never uses `git pull`) - ---[[Joey]] - -> [[done]]; used the environment variable -> `GIT_MERGE_ALLOW_UNRELATED_HISTORIES` which will hopefully land in git -> `next` (currently Junio has posted a patch but not even landed it in `pu` -> yet) --[[Joey]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn b/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn deleted file mode 100644 index 5376d88b1..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -It appears that currently there's no way to use the "path-style" method for accessing S3 buckets (as contrasted [here](http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAPI.html) with the "virtual hosted-style" of bucket specification). Would it be possible to add an S3-special-remote configuration parameter to adjust the underlying S3 library's "s3RequestStyle" config parameter? I believe that the "PathStyle" value would be relevant to this specific request, as mentioned in the [S3 library README](https://github.com/aristidb/aws#frequently-asked-questions). - -The virtual-hosted style of bucket specification involves a lot of DNS overhead. In my particular use case, I'm looking at running Ceph with a radosgw with S3 support, and in fact the Ceph documention [specifically indicates](http://docs.ceph.com/docs/master/radosgw/s3/commons/#bucket-and-host-name) a preference for "path-style" bucket specification. - -> [[done]] --[[Joey]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment b/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment deleted file mode 100644 index 3faf2e539..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_1_971ab83e58128a60921e19b822323965._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-02-09T19:35:10Z" - content=""" -Sure, I've added that as requeststyle=path. I have not tested it, so once -you get an updated build let me know if it works. - -(Should be available in the daily linux autobuilds within about an hour.) -"""]] diff --git a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment b/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment deleted file mode 100644 index cb82f28e0..000000000 --- a/doc/todo/support_path-style_syntax_for_S3_bucket_specification/comment_2_2c8f58124ed35997e2845377af8c6b02._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="magibney@908c3d4677b9e87e203538d4d5e8c296255749a0" - nickname="magibney" - subject="comment 2" - date="2016-02-09T21:51:17Z" - content=""" -Just tested successfully (initremote, copy --to, get) in the daily linux autobuild. Fantastic, thank you so much, and thank you for all your work on git-annex! -"""]] diff --git a/doc/todo/unwanted_repository_version_upgrades.mdwn b/doc/todo/unwanted_repository_version_upgrades.mdwn deleted file mode 100644 index 88468ec6f..000000000 --- a/doc/todo/unwanted_repository_version_upgrades.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -Is it possible to freeze or peg repositories at a particular version, or to prevent automatic repository version upgrades? Is it possible to "downgrade" a repository? - -### Please describe the problem. - -We have a number of repositories on a shared file server. These repositories are accessed by multiple machines. Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex. - -We're getting this message: -[[!format sh """ -user@system:/path/to/repository$ git annex status -git-annex: Repository version 5 is not supported. Upgrade git-annex. -"""]] - -The machine experiencing the problem is running Debian Wheezy (Stable). -[[!format sh """ -user@system:/path/to/repository$ git version -git version 1.7.10.4 -user@system:/path/to/repository$ git annex version -git-annex version: 3.20120629 -local repository version: 5 -default repository version: 3 -supported repository versions: 3 -upgrade supported from repository versions: 0 1 2 -"""]] - -I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action. - -> I took this onboard with v6; upgrade to it is currently optional and will -> only become the default once enough years have passed that it's -> reasonable to assume most people have git-annex 6.x installed. -> -> I think at this point it's reasonable to assume most people have -> git-annex 5.x installed, so there's no point in trying to change to v3 to -> v5 forced upgrade at this point. So, [[done]] --[[Joey]] diff --git a/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment b/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment deleted file mode 100644 index 2eee18f1a..000000000 --- a/doc/todo/unwanted_repository_version_upgrades/comment_1_48f71865b65db4574a10e5c32ee22197._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 1" - date="2014-06-04T18:14:19Z" - content=""" -If your repository is not using direct mode, it's completely safe to edit .git/config and set the version back to 3. There is no change between 3 and 5 for indirect mode repositories. - -Unfortunately, using git-annex version 5 will automatically upgrade the repository to 5 again. In general, I only want git-annex to support one version at a time, to avoid complicating the code. I did try leaving the indirect mode repositories at v3, but that didn't work out (some details in [[!commit b1d7474c1d713a5b422948178abb4e5f39e85096]]). - -I kind of think that part of the problem is that you're using git-annex repositories accessed via a file server. If your server had git-annex installed on it and the clients talked to it only by sshing in and running git-annex-shell, it would not matter if the clients had a newer version, because they'd never access the central repository directly. -"""]] diff --git a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn b/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn deleted file mode 100644 index d9e9f79ba..000000000 --- a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock.mdwn +++ /dev/null @@ -1,5 +0,0 @@ -I might be wrong but given the observation that adjust --unlock took 26.04s user 33.95s system 31% cpu 3:12.36 total to finish operation on an annex (on smaug, btrfs filesystem) with a relatively small (~400) number of relatively large files, I guess no reflink copying was done. - -[[!meta author="yoh"]] - -> [[dup|done]] --[[Joey]] diff --git a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment b/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment deleted file mode 100644 index bdaa128e2..000000000 --- a/doc/todo/use_CoW_capability___40__e.g._cp_--reflink__41___while_adjust_--unlock/comment_1_1663a02563e147d53ed57e58ef7fb9da._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-06-09T19:44:14Z" - content=""" -Git's smudge interface requires git-annex to output the content to stdout; -git writes it to the file. So, git-annex does not have an opportunity to -efficiently copy the file. - -(All file copies in git-annex use cp --reflink) - -My proposed extended smudge interface at -<http://thread.gmane.org/gmane.comp.version-control.git/294425> -lets the smudge filter write the file to disk, and then git-annex could -use more efficient methods. Since this is already discussed in -[[todo/smudge]] I think I'll close this bug report as a duplicate. -"""]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files.mdwn b/doc/todo/use_inode_cache_in_unlocked_files.mdwn deleted file mode 100644 index 572d80ec6..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -When using git annex unlock, followed by git annex add, it currently -checksums files, even if the file has not changed. - -Direct mode has a better approach for this: The inode cache can pretty -reliably detect if a file has been modified. So, `unlock` could note -a file's inode cache info, and then `add` could check if a file's inode -cache is unchanged, and rather than re-checksum it, just perform a fast -`lock`. - -Question: How would `add` know what key's inode cache to look at? Seems it -would need to either check the git branch (as direct mode does, but this is -rather slow and would slow down `add` in the more common case of adding -lots of new files), or use a yet-unimplemented [[design/caching_database]]. -Or, the inode cache could be stored in a map with the work tree filename, -but that diverges from how direct mode uses inode caches. - -Observation: Using the inode cache info to detect changes is not perfect; -if a file is modified without changing its size or mtime, the inode cache -won't be able to tell it's changed. This is unlikely, but possible. In -direct mode, the worst that can happen in this case is probably that a -modified file doesn't get added and committed. But, using the inode cache -for unlocked files would result in any such modified versions being thrown -away when the file is added, which is much more data lossy.. - -> This bug was regarding v5 unlock/lock. In v6 mode, locking a -> file doesn't need to rechecksum it; the key is pulled out of the -> associated files database, and the inode cache is used to detect if the -> unlocked file has been modified and so avoid data loss. -> -> So, this is [[done]] but only for v6 mode. I don't think I want to -> backport it to v5 mode though; it fell out naturally as a consequence of -> v6 mode, but to support it in v5 mode would be a lot more work. -> --[[Joey]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment b/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment deleted file mode 100644 index 282f27de6..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files/comment_1_b13f66eb9840d26fc34b967f5c857b9d._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" - subject="explicit arguments?" - date="2015-07-06T16:01:47Z" - content=""" -just a suggestion (yet to comprehend full idea here): might be worth making it less magical, e.g. expanding \"add\" with two options: - --u (similar to git) would check only known to git files --a would also automatically add new files - -So I could just \"git annex add -au .\" to commit all the changes in files which happened to be created or modified, without penalty of checksumming all the files. -"""]] diff --git a/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment b/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment deleted file mode 100644 index fe026b448..000000000 --- a/doc/todo/use_inode_cache_in_unlocked_files/comment_2_bc288991fa9e235695252b09bc82537e._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-07-06T17:46:16Z" - content=""" -Adding a -u option, and perhaps also one to only add new files, would be -pretty easy to do. Of course you can feed git-ls-files output to git annex -add to accompish the same thing. Does it help with the same use case where -adding unlocked files is slower than desirable? -"""]] diff --git a/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn b/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn deleted file mode 100644 index 3b1ca70eb..000000000 --- a/doc/todo/whishlist__58___temporary_relinking_to_remotes.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Imagine the following situation: -You have a directory structure like this: - -`./` -`+--dir1` -`|+--file1 (local)` -`|+--file2 (remote1)` -`|+--file3 (remote2)` - -Now when these files are quite big and you need them in one directory temporarily you would need to use `git annex get dir1` to copy them all over to local. This can take some time. - -I whish we had a command like this: -`git annex getlinks dir1` -where git annex would try to not link to the missing local objects but to the remote ones. So there is no need to copy the data around just to use it for a short time. After you are done you could use `git annex resetlinks dir1` to reset the links to the local objects. - -I know that many specialremotes will not support this without much hassle, but it would be cool to be able to get atleast the links from external drives and maybe ssh remotes via sshfs. -To keep the data consistent there can be a constraint that every action (add, sync, commit or others) first issue a `resetlinks`. - -What do you think of that? - -> Already implemented via the `annex.hardlink` configuration. -> -> I don't think that separate commands/options to control whether or not -> to hard link makes sense, because a repository containing hardlinks -> needs to be set as untrusted to avoid breaking numcopies counting. -> Which is done automatically by git-annex when it detects the repository -> was cloned with `git clone --shared`. -> -> [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist__58___--all_option_for_sync.mdwn b/doc/todo/wishlist__58___--all_option_for_sync.mdwn deleted file mode 100644 index fd609a091..000000000 --- a/doc/todo/wishlist__58___--all_option_for_sync.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -I wish to preserve all history on the backup drives using standard groups and the `sync` command. Namely, if I do the following - - touch test-of-annex-backup.txt - git annex add test-of-annex-backup.txt - git commit --message='test: Create empty test-of-annex-backup.txt file' - git annex edit test-of-annex-backup.txt - echo "This line creates version 2 of this file" > test-of-annex-backup.txt - git annex add test-of-annex-backup.txt - git commit --message='test: Create version 2 of test-of-annex-backup.txt' - git annex sync --content --all - -I expect to see 2 copies of `test-of-annex-backup.txt` be copied to each accessible annex repository in the `backup` [standard group](http://git-annex.branchable.com/preferred_content/standard_groups/) - -At present, the `backup` standard group prefers unused files, but the `sync` command cannot act on this configuration, since it lacks an `--all` option. This is surprising to me as a user, and appears to contradict the intent of the preferred content, as evinced by the awkward explanation of why it is there in [preferred content](http://git-annex.branchable.com/preferred_content/) - -Please add an `--all` option to the `sync` command - -Thanks - -Andrew - -> Implemented; [[done]]. --[[Joey]] diff --git a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn b/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn deleted file mode 100644 index 83f75bb93..000000000 --- a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -It would be very nice with an "advanced settings" for jabber and webdav support. - -Currently XMPP fails if you use a google apps account. Since the domain provided in the email is not the same as the XMPP server. - -Same goes for webdav support. If i have my own webdav server somewhere on the internet there is no way to set it up in the assistant. - -[[!tag /design/assistant]] - -> [[done]]; xmpp support has been removed --[[Joey]] diff --git a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment b/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment deleted file mode 100644 index 61cd3fc2e..000000000 --- a/doc/todo/wishlist__58___Advanced_settings_for_xmpp_and_webdav/comment_1_11c7444ab4988c60732af505b52bde3c._comment +++ /dev/null @@ -1,20 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmWg4VvDTer9f49Y3z-R0AH16P4d1ygotA" - nickname="Tobias" - subject="Hooks too" - date="2013-05-22T10:40:33Z" - content=""" -It would actually be very nice if this could be done with hooks too. - -Especially with the new hook method. - -Take this hook - - mega-hook = /usr/bin/python2 ~/sources/megaannex/megaannex.py - -git-annex could make a request with either the parameter(or environment variable) \"getsettingsobject\" that could return. {\"username\": \"\", \"password\": \"\", \"folder\": \"\"}. - -The point being git-annex can request from the hooks program what settings it takes, and give a web interface to set it. Then store the information in the creds folder(ew ew, that folder is unencrypted, oh well) and pass it to the hook on run. - -The advantage being that users wouldn't have to edit a settings file manually (this is currently also the case for the IMAP special remote, which also requires a settings file). -"""]] diff --git a/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn b/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn deleted file mode 100644 index 27540c088..000000000 --- a/doc/todo/wishlist__58___Unix_time_in_git_annex_log.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -Could `git annex log` show the modification times using the Unix time instead of human-readable timestamps? - -This is an example of the output of `git annex log`: - -``` -+ 2014-10-27 01:00:18 ev-2014.pdf | 50083bd6-7e20-4356-a32f-a1dde07de441 -- penn -``` - -If the timestamp were in Unix time, it would be easier to process in a mechanical way. Unix time would also avoid having to guess what is the correct timezone for the timestamp. - -``` -+ 1414368018 ev-2014.pdf | 50083bd6-7e20-4356-a32f-a1dde07de441 -- penn -``` - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment b/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment deleted file mode 100644 index 02cd1cca3..000000000 --- a/doc/todo/wishlist__58___Unix_time_in_git_annex_log/comment_1_e13341ff3713716e595f2d2d3ed110d0._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-03-29T18:35:26Z" - content=""" -I don't think that's a good default, but I will add the time zone to the -date displayed. And add a --raw-date option for epoch. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn deleted file mode 100644 index d53fa56ab..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -We're using git-annex to manage large files as part of a team. - -We have a central repository of large files that everyone grabs from. - -We would like to be able to get the files without updating the `git-annex` branch. This way it doesn't pollute the history with essentially always unreachable locations. - -I think the easiest way would be to just add an option to not update the `git-annex` branch when `annex get` is executed. - -Thoughts? - -> See [[untracked_remotes]] for a todo item that will probably -> be useful in this sitation. Since that describes better what -> this bug report seems to be asking for, I am closing this one. -> [[closed|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment deleted file mode 100644 index 61d82e2ae..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_1_5c8812973cf91b046e7fc44d7e86c78e._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.6.48" - subject="comment 1" - date="2013-07-17T23:23:50Z" - content=""" -I'm interested to hear that your team is using git-annex. - -Have you tried `git config annex.alwayscommit false`? This will avoid committing, and just store the info in a local journal -- so even `git annex fsck` will still work. - -Hmm, perhaps you want to update the branch when running `git annex copy` to put files onto the server, but not when getting them? A switch to disable updating the branch would then make sense. Any use of fsck would notice the inconsistency though, and commit a fix to the git-annex branch -- unless you also used the new switch when running fsck. - -But what happens if someone makes a change, pushes to the server, but forgets to `git annex copy` the file? Everyone would then be left with a missing file that git annex doesn't know where it is. One of the reasons it tracks the locations is so that if necessary you know which repository such a misplaced fail is stored in. And can go track down that person's laptop and apply a cluebat. ;) Do you do something on the server to prevent this scenario? -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment deleted file mode 100644 index 3379742d2..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_2_f36b6a5b128423211aac91a252ecf85f._comment +++ /dev/null @@ -1,18 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 2" - date="2013-07-17T23:42:25Z" - content=""" -What would happen if we wanted to copy a file to the server -with that set? or even when running `git annex add` -You understood me exactly though. -We'd like to be able to get the files without a commit, but copy them -with a commit of the changes. -The way we operate, if somebody makes a change with regards to -largefiles, they should also add a test for it. -Ideally, the test suite would catch it. That or people would -realize that theres a new big file and send around an email to -see who was trying to a largefile when they couldn't reach it. - -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment deleted file mode 100644 index 14ab5f65a..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_3_ad1569b2405acacd2e37f42b82f24c88._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.6.48" - subject="comment 3" - date="2013-07-18T00:12:39Z" - content=""" -Actually, when a file is sent to a git repository on the server, it will update the location log on that side. So even if the client has alwayscommit=false, other clients will learn the file has reached the server. - -So that might just work for you. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._comment deleted file mode 100644 index c1f148fdb..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_4_8aba90150fe178ce9712ad951628f3d6._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" - nickname="Michael" - subject="comment 4" - date="2013-07-18T18:03:00Z" - content=""" -If you can have developers only add large files on the central server, avoiding using git annex sync and only pulling from git repo should work, I think. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment deleted file mode 100644 index aa547d790..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_5_6f42d240e0021f4dfa37146bea3f5d7e._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 5" - date="2013-07-18T21:17:45Z" - content=""" -Wow. This worked better than expected. I'm still trying to understand the implementation (I'm not familiar with Haskell), but there is some magic going on. - -To explain: - -I didn't expect that when I added a file (Locally and to the annex remote) that when somebody else did a pull, git-annex would recognize this and update the working copy to download and include that file. - -I'm not sure if this is intended behavior or not (since I thought all commands had to go through git-annex) but I like it nonetheless. - -Thanks again for the tips! -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment deleted file mode 100644 index 3f10e48ad..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_6_5fda455febf728b079f26fe42bf7bcab._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://caust1c.myopenid.com/" - nickname="asbraithwaite" - subject="comment 6" - date="2013-07-18T21:23:58Z" - content=""" -Disregard that. I was testing it with a particular file that didn't exactly play nice. - -Basically, to test this before production I used `dd bs=1024 count=100000 if=/dev/zero of=bigfile`. - -When I did a `git pull`, it showed the symlink as being valid. - -When I changed the command to `dd bs=1024 count=100000 if=/dev/urandom of=bigfile` then it showed the symlink as bad after pulling. - -Weird! -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._comment deleted file mode 100644 index deb25a9ce..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_7_f1052ab997f1a2cccbabfd1533fc0a59._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog" - nickname="Michael" - subject="comment 7" - date="2013-07-18T21:48:06Z" - content=""" -If you wanted to auto-get files on git pull, you could trying putting git annex get into .git/hooks/post-merge (needs to be marked as executable). -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment deleted file mode 100644 index 4901a2d97..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_8_07804647b6023436878756bd97a23f32._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.154.0.140" - subject="comment 8" - date="2013-07-20T20:07:53Z" - content=""" -`dd bs=1024 count=100000 if=/dev/zero of=bigfile` obviously creates the same data each time, so if that same size empty file has previously been in a repository, and the content is still present there, the symlink will automatically point to it when it gets added. In other words, git-annex performs automatic deduplication of file contents, and so it was able to save you a download in this case. -"""]] diff --git a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment b/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment deleted file mode 100644 index 2287f6935..000000000 --- a/doc/todo/wishlist__58_____34__quiet__34___annex_get_for_centralized_use_case/comment_9_fdc883d3963de8072794f3189742e4e3._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 9" - date="2014-01-02T17:25:50Z" - content=""" -I have now implemented a way to mark a remote as readonly. This prevents git-annex from pushing anything to the remote, or modifying it in other ways. - -It seems that in your use case, you might want to avoid git-annex sync pushing the git-annex branch, but still push a branch like master. So far, it's up to you to decide which branches to manually push; readonly disables all pushing. -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn b/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn deleted file mode 100644 index c83d4db5c..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync_-m__96__.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -Similar to how - - git commit -m 'foo' - -works, if I run - - git annex sync -m 'my hovercraft is full of eels' - -git annex should use that commit message instead of the default ones. That way, I could use [[sync]] directly and not be forced to commit prior to syncing just to make sure I have a useful commit message. - -> [[fixed|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn deleted file mode 100644 index 381626724..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -I would like to have way, ideally a per-repo-cloud setting which syncs around automatically, to not have `git annex sync` autocommit staged additions. - -I often have quite complex additions with a mix of `git add` and `git annex add` in various stages of completion; running `git annex sync` regularly to see what state the other repos are in should not autocommit if possible. - -Richard - -> [[done]]; extended the annex.autocommit that previously only controlled the -> assistant to also control `git annex sync`. --[[Joey]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment deleted file mode 100644 index 1e455c486..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_1_fff7cdff9e4bc988139152a799b65c99._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 1" - date="2014-05-13T20:23:11Z" - content=""" -This could be particularly useful for direct-mode repositories. -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment deleted file mode 100644 index cc6cd727b..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_2_b8dd92d7710a9d194312058e53c38d21._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="92.227.51.179" - subject="comment 2" - date="2014-05-13T20:27:38Z" - content=""" -I filed a bug today, which boils down to a related issue. - -http://git-annex.branchable.com/bugs/git_annex_list__47__whereis_and_uncommited_local_changes/ -"""]] diff --git a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment b/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment deleted file mode 100644 index 8e2a57e14..000000000 --- a/doc/todo/wishlist__58_____96__git_annex_sync__96___without_auto-commit/comment_3_206e319f6d7c6b0d1f05af2475a8b335._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="108.236.230.124" - subject="comment 3" - date="2014-05-16T19:02:08Z" - content=""" -Well, you could: git fetch --all; git annex merge; git push origin -"""]] diff --git a/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn b/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn deleted file mode 100644 index c6c5e66a4..000000000 --- a/doc/todo/wishlist__58___add_--symlink_option_to_import.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -Make 'git annex import' for each imported file leave a symlink behind. One may consider this a bit nasty as this introduces symlinks out of the annex. There are also some things careful to consider, link to the annexed symlinks or into the .git/annex/objects store? the first breaks views, the second relies on implementation details. Shall these be absolute (i'd say yes) or relative (won't harm) links etc. But after all it gives a easier migration and possibly even some new usage to manage files outside of the annex. A sister-command for 'export' comes in mind, drop a symlink anywhere. Anyways, when you feel this is a good idea, keep it, otherwise just delete this idea. Thanks ;) - -> Closing as I don't think this is a good idea. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._comment b/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._comment deleted file mode 100644 index 62d4264cb..000000000 --- a/doc/todo/wishlist__58___add_--symlink_option_to_import/comment_1_d5d853142d401b95577567e3eb43495e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.2" - subject="comment 1" - date="2014-07-15T18:53:47Z" - content=""" -Well, it's easy enough to make symlinks to content in a git-annex repository yourself if you want to. I don't see why this belongs in `git annex import`, which is too complicated already. -"""]] diff --git a/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn b/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn deleted file mode 100644 index 64388d517..000000000 --- a/doc/todo/wishlist__58___add_repository_name_to_commit_messages.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -The commit messages made by git-annex are quite spartan, especially in direct mode where one cannot enter its own commit messages. This means that all that the messages say is "branch created", "git-annex automatic sync", "update", "merging" or little more. - -It would be nice if git-annex could add at least the name of the repository/remote to the commit message. This would make the log a lot more clear, especially when dealing with problems or bugs. - -> The repository name is included now. Also, `git annex sync` can be passed -> --message. [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn deleted file mode 100644 index d53a6117d..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -It could be useful for Linux users and package maintainers to have systemd .service file samples to launch the assistant and the webapp. - -For multi-user systems, we could have a git-annex-webapp@username.service . - -See [systemd documentation](http://www.freedesktop.org/software/systemd/man/systemd.service.html) for informations about those files. -See [archlinux wiki](https://wiki.archlinux.org/index.php/Systemd/Services) for .service examples. - -> [[done]] by Euxane. Thanks! --[[Joey]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment deleted file mode 100644 index 5e8c8a374..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_1_b89e90f9a70748c95aaf81740a40b76e._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="64.134.31.139" - subject="comment 1" - date="2013-10-19T15:33:18Z" - content=""" -Wouldn't this involve running it as root or a dedicated user? Neither is ideal. git-annex already uses .desktop files to auto-start when the user who is using it logs in. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment deleted file mode 100644 index 5dfeedf37..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_2_d64361380cb18b98ddb43ada1c9f540a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawmVE2R20dyfPQIzdi6urVUUAXtD6eeBsr0" - nickname="Benoît" - subject="comment 2" - date="2013-10-19T15:43:36Z" - content=""" - Not necessarily. I have a systemd instance handling my userland services. See [archlinux wiki systemd/User](https://wiki.archlinux.org/index.php/Systemd/User). -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment deleted file mode 100644 index f2cadb8b0..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_3_f465134958d858a8be21f252abd78aae._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm_YXzEdPHzbSGVwtmTR7g1BqDtTnIBB5s" - nickname="Matthias" - subject="User doesn't have to be logged in" - date="2014-11-26T11:29:10Z" - content=""" -my git-annex backend systems don't even have a GUI , much less a logged-in user on them. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment deleted file mode 100644 index 552b6c189..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_4_268b35928a7a192644d32b6c1d12ecc4._comment +++ /dev/null @@ -1,17 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2014-12-01T22:19:51Z" - content=""" -I don't know what the plans are exactly for the user-mode systemd. - -It seems to me that, if it eventually becomes the session manager for the -desktop, then it will probably grow a generator to handle XDG autostart -.desktop files, and generate systemd services for them. Or, those XDG -autostart files will become deprecated, and programs will ship user-mode -service files. - -In the first case, git-annex doesn't need to include a systemd file, and in -the second case it should. So best it seems to wait and see, or hear from -someone with more information. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment deleted file mode 100644 index 971b449a6..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_5_94993f36d5644e4181e411e6b4582a43._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="Euxane" - avatar="http://cdn.libravatar.org/avatar/e6f48ec6bdf54a71119bcff72e29693f" - subject="comment 5" - date="2016-11-07T11:07:33Z" - content=""" -Syncthing's documentation explains in a nutshell the purpose of system and user services [here](https://docs.syncthing.net/users/autostart.html#using-systemd), and has also some examples of easily adaptable systemd config files for each [here](https://github.com/syncthing/syncthing/tree/master/etc/linux-systemd). - -This provides a common way of managing background services (starting order, auto-restart, …) that I personally prefer over Windows-ish tray-apps. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment deleted file mode 100644 index 88a6d5723..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_6_759185007f20c01fa0f19836e1c3ebbc._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2016-11-07T14:35:42Z" - content=""" -git-annex uses standard desktop autostart files to make the assistant -be run at login. They are included in the git-annex package. -Since that works perfectly fine on all linux desktop environments, -I have not bothered with systemd user services for it, -which after all will only work on systemd systems. - -If you want to write some and add a page to -<https://git-annex.branchable.com/tips/> about it, that would be fine. -"""]] diff --git a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment b/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment deleted file mode 100644 index 6f99416f4..000000000 --- a/doc/todo/wishlist__58___add_systemd_services_file_samples_for_assistant_and_webapp/comment_7_4515caef5ff53f60c11f2390a98015ef._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="Euxane" - avatar="http://cdn.libravatar.org/avatar/e6f48ec6bdf54a71119bcff72e29693f" - subject="comment 7" - date="2016-11-08T10:12:05Z" - content=""" -Page added [here](http://git-annex.branchable.com/tips/Systemd_unit/) -"""]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn deleted file mode 100644 index 258b82f6a..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -I keep a database file in git-annex so it stays synced across several machines. My wrapper when accessing it is basically - - git annex sync --content - git annex unlock $database - [access database] - git annex add $database - git annex sync --content - -This works fine except it creates an entry in the log for the database file even if that stays unchanged. I would like an option that just returns to the state before `git annex unlock` if the file has not been changed. Maybe `git annex add --restore-unchanged`? - -> [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment deleted file mode 100644 index 3c6df0477..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_1_ef1dbde0fbf20b7fd91503d9df50dcab._comment +++ /dev/null @@ -1,33 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2015-10-12T17:17:12Z" - content=""" -I want to think a little bit about why the location log is updated in this -case before thinking about adding an option. It might make sense to just -not update the location log when it already says the file is present and -only the timestamp is being changed. - -I can think of 2 reasons not to do it: - -1. If it has to query the current state of the log, that might slow down - `git annex add` in the common case, just for this less common case. - - But, updating the log necessarily involves reading it in and outputting - an updated one, so that could probably be finessed. - - (Or, git annex add makes a separate pass to add unlocked files anyway, - so it could only do the query in that case.) - -2. There might be good reasons to want to update the timestamp in the log, - since it's just verified that the content is still present. Maybe. - - But then, fsck doesn't update the timestamps when it does the same kind - of verification. And, the only thing that updates a given repo's entry - in the log is that repo, or another repo that is sending or dropping - content from that repo. - - There don't seem to be any reasons of - distributed consistency to need to worry about updating the timestamp - just to reflect current facts. -"""]] diff --git a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment b/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment deleted file mode 100644 index aeb98f06e..000000000 --- a/doc/todo/wishlist__58___allow_re-adding_without_generating_log_entry/comment_2_3a3d793b32b8440a8213b38bc83ea94a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2015-10-12T17:37:59Z" - content=""" -Ok, I found a way to implement it with no added overhead in the common -case! -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn deleted file mode 100644 index b64eb45cc..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -It would be nice to have mimetype support on the `annex.largefiles` configuration directive. F.e. `git config annex.largefiles "not mimetype=text/plain"` - -> [[done]]; Implemented support for mimetype=text/plain or even -> mimetype=text/* -> -> Decided not to add external command test support, at least not for now. -> --[[Joey]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment deleted file mode 100644 index b06008475..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_1_304431bb62b5b8a64edc37a11bbaff59._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlhE8Xar6m4x3JSILXdm-Y5KhwHTH5qzKQ" - nickname="bruno" - subject="+1" - date="2013-10-14T14:43:11Z" - content=""" -Big +1 for this feature: this would really help configuring annex.largefiles -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment deleted file mode 100644 index ba88bfb7c..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_2_975edca7ec87158216d9e106903dfb48._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="zardoz" - ip="78.48.163.229" - subject="comment 2" - date="2014-08-02T14:29:26Z" - content=""" -This could be achieved in a generic way by allowing filter binaries in expressions, which are run on the filename and return 0 or 1. -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment deleted file mode 100644 index b2bcd87eb..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_3_b2774d265de303143523607053811d23._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.7" - subject="comment 3" - date="2014-08-12T18:58:49Z" - content=""" -I think that to support this, the annex.largefiles preferred content expression would need to be supplimented with checks not available in the normal preferred content language. - -In general, it's important that preferred content expressions be able to be evaluated without having the file content locally available, and it needs to be possible for a repository to evaluate the preferred content of a sibling repository and know if its sibling wants a file. These things would be defeated by any mime-based expressions. So such expressions should only be available in annex.largefiles and not in other preferred content expressions. - -Calling out to `file` or some other external program could work. Although speed can be important. If the assistant is seeing a file frequently change, it's not ideal for it to be repeatedly running `file` on it. There does not seem to be a pure haskell MIME type checking library available at present. -"""]] diff --git a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment b/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment deleted file mode 100644 index c379c735f..000000000 --- a/doc/todo/wishlist__58___annex.largefiles_support_for_mimetypes/comment_4_d06a7c7f1a4fe78af548e2af2fbe8e2b._comment +++ /dev/null @@ -1,27 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2016-02-03T19:08:38Z" - content=""" -Update: There are now separate parsers for preferred content and -annex.largefiles expressions, so this could be put in only the -annex.largefiles parser. - -I kind of like the idea of letting an external program be run -to test if the file is large. Of course, it would be up to the user to -make the external program fast enough. - -The expression could be something like "checkprogram=foo". Since -expressions have simple word-based tokenization, no parameters -would be able to be passed to the program (except the file to check). - -For getting mime type, the best way seems to be to use -<http://hackage.haskell.org/package/magic>. Using `magicOpen [MagicMimeType]` -I got it to probe mime types for files. - -Since libmagic won't be available everywhere, it would have to be a build flag, -and if a git-annex not built with support for it is fed an expression with -"magic=", it would have to error out when parsing the expression. - -Of course, these options are not mutually exclusive.. -"""]] diff --git a/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn b/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn deleted file mode 100644 index 00777faa2..000000000 --- a/doc/todo/wishlist__58___do_round_robin_downloading_of_data.mdwn +++ /dev/null @@ -1,10 +0,0 @@ -Given that git/config will have information on remotes and maybe costs, it might be a good idea to do a simple round robin selection of remotes to download files where the costs are the same. - -This of course assumes that we like the idea of "parallel" launching and running of curl/rsync processes... - -This wish item is probably only useful for the paranoid people who store more than 1 copy of their data. - -See [[get_round_robin]] --[[Joey]] - -> [[done]], at least for `git annex get -JN` when two remotes have the same -> cost.. diff --git a/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment b/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment deleted file mode 100644 index 6a5fd3d53..000000000 --- a/doc/todo/wishlist__58___do_round_robin_downloading_of_data/comment_1_460335b0e59ad03871c524f1fe812357._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joey.kitenet.net/" - nickname="joey" - subject="comment 1" - date="2011-04-03T16:39:35Z" - content=""" -I dunno about parrallel downloads -- eek! -- but there is at least room for improvement of what \"git annex get\" does when there are multiple remotes that have a file, and the one it decides to use is not available, or very slow, or whatever. -"""]] diff --git a/doc/todo/wishlist__58___git_annex_diff.mdwn b/doc/todo/wishlist__58___git_annex_diff.mdwn deleted file mode 100644 index 3af7bef6a..000000000 --- a/doc/todo/wishlist__58___git_annex_diff.mdwn +++ /dev/null @@ -1,13 +0,0 @@ -git diff is not very helpful for annexed files. - -How about a git annex diff command that allows to compare two versions of an annexed file? - -Should be relatively simple, only there would have to be a way to deal with the situation where not both versions are present in the repository. Either abort with a message showing the command you need to run to get the missing version(s). Or even interactively volunteer to get it automatically, asking the user for confirmation. - -Of course you wouldn't want to diff two large files, but with git annex assistant, all files are annexed by default (right?), so this would be useful. - -There might already be a way to easily diff two versions of an annexed file which I'm missing -- in that case please point me to it! :) - -> [[done]]; rather than adding a `git annex diff`, I made git-annex be able to be used as a git diff driver command, -> which in turn can run some third-party external diff driver that does -> some smart handling of binary files. diff --git a/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment b/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment deleted file mode 100644 index 86772e2fd..000000000 --- a/doc/todo/wishlist__58___git_annex_diff/comment_1_16ccf2e1036d9e1a913db81988731b5a._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 1" - date="2014-03-18T20:00:16Z" - content=""" -`git diff` is quite flexible; it can use external diff drivers to perform the diff. Someone could write a diff driver that knows about git-annex symlinks, and shows some kind of diff of the file contents (since the files are probably binary, this gets into how to display a diff of different file types..) -"""]] diff --git a/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment b/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment deleted file mode 100644 index 83501b791..000000000 --- a/doc/todo/wishlist__58___git_annex_diff/comment_2_2e8324f47b66dce385263e258e94da16._comment +++ /dev/null @@ -1,32 +0,0 @@ -[[!comment format=mdwn - username="Bram" - ip="81.20.68.186" - subject="Diff of unlocked file" - date="2014-10-14T10:11:04Z" - content=""" -I wrote a little shell script that implements part of this request. It shows the diff between an unlocked file and its locked version (i.e. the current edits that have not yet been annexed). -This only works in non-direct mode, and obviously with 'diffable' content only. - -Usage is simple, the only parameter it requires is the unlocked filename. - - #!/bin/bash - - DIFF=\"diff\" - FILE=\"$1\" - KEY=$(git annex lookupkey \"$FILE\") - - GITPATH=\"$(git rev-parse --show-toplevel)/.git\" - ANNEXPATH=$GITPATH/annex/objects/$(git annex examinekey --format='${hashdirmixed}${key}/${key}' \"$KEY\") - - if [ -L \"$FILE\" ]; then - echo \"$FILE is not unlocked.\" > /dev/stderr - else - if [ -r \"$ANNEXPATH\" ]; then - $DIFF \"$ANNEXPATH\" \"$FILE\" - else - echo \"Cannot find $ANNEXPATH\" > /dev/stderr - exit 1 - fi - exit 1 - fi -"""]] diff --git a/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn b/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn deleted file mode 100644 index ac29c169f..000000000 --- a/doc/todo/wishlist__58___git_annex_info_._also_return_numcopies_setting.mdwn +++ /dev/null @@ -1,44 +0,0 @@ -The stats produced by `git annex info .` are nice but I often find myself separately looking up the actual numcopies set value. Can this also be included in the report please? - -> There is not necessarily one single numcopies setting; gitattributes -> can configure different numcopies for different files. -> -> The numcopies stats in the report are reported as plus or -> minus relative to the numcopies setting. Using a relative number like -> that, it can eliminate the complexity of which files have which -> numcompies setting. - -<pre> -numcopies stats: - numcopies +0: 27 - numcopies +1: 43 - numcopies +2: 1 -</pre> - -> What could be added is a summary of the absolute number of copies -> that exist of files, without taking the numcopies configuration -> into account. - -<pre> -absolute number of copies: - 1 copy: 47 - 2 copies: 23 - 3 copies: 1 -</pre> - -> It turns out you can already get this display though! -> Just use `git annex info . --numcopies=0`. - -<pre> -numcopies stats: - numcopies +1: 47 - numcopies +2: 23 - numcopies +3: 1 -</pre> - -> So, in this mode, it's showing the number of copies that exist of files, -> relative to numcopies, which is forced to be 0. So, there are 47 files -> with 1 copy, 23 with 2 copies, and 1 with 3 copies. -> -> I think I've convinced myself no changes need to be made! [[done]] -> --[[Joey]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID.mdwn b/doc/todo/wishlist__58___git_annex_info_UUID.mdwn deleted file mode 100644 index 5b9633e18..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID.mdwn +++ /dev/null @@ -1,11 +0,0 @@ -All repos contain some level of information about all other tracked repositories. -It would be nice if I could see that info, preferably with a timestamp telling me when the last sync happened. - -`git annex info UUID/name` would be suggestion. - - -Thanks, -Richard - -> I left out the stuff that `vicfg` displays. But otherwise -> everything mentioned on this page is [[done]]. --[[Joey]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment b/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment deleted file mode 100644 index ab94b7dea..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID/comment_1_d0d40bfdafed47e9e8ef2f4cd5c8576f._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.227" - subject="comment 1" - date="2014-01-02T02:16:10Z" - content=""" -git-annex vicfg shows everything (except location tracking info and some remote.log stuff that it would be hard to present in any useful way). - -It would be good to make `git annex info` segment its list of repos by group. The only other information is location tracking info and scheduling, which I think vicfg gives a good overview of. -"""]] diff --git a/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment b/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment deleted file mode 100644 index 271c88798..000000000 --- a/doc/todo/wishlist__58___git_annex_info_UUID/comment_2._comment +++ /dev/null @@ -1,8 +0,0 @@ -One piece of information that's sometimes useful, but not always, is to get a count of keys present in another remote plus the size of the remote. - -Thus, I could verify that some repos are empty, archive repos have every single file, etc etc. - -I still think that info is best suited for `git annex info name/UUID` as it's more volatile than what `git annex vicfg` displays. - - -Richard diff --git a/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn b/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn deleted file mode 100644 index ffdee8840..000000000 --- a/doc/todo/wishlist__58___make_git_annex_reinject_work_in_direct_mode.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -### Please describe the problem. - -`git annex reinject` refuses to work while in direct mode. - -When in direct mode git annex reinject could simply perform `rm $symlink; mv $file_copy .; git annex add $file`. I prefer having git annex doing that so I am sure I am not messing up (mistakenly adding new files for instance) and everything is properly managed. - -### What version of git-annex are you using? On what operating system? - -git-annex 4.20130516.1 - -~~~~ -$ lsb_release -a -No LSB modules are available. -Distributor ID: Ubuntu -Description: Ubuntu 12.04.2 LTS -Release: 12.04 -Codename: precise -~~~~ - -> [[fixed|done]]. Why did I take so long to do this, it was a trivial 1 -> word change! --[[Joey]] diff --git a/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn b/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn deleted file mode 100644 index b5cf88bf8..000000000 --- a/doc/todo/wishlist__58___more_info_in_commit_messages_in_general.mdwn +++ /dev/null @@ -1,8 +0,0 @@ -This is probably an extension of [[wishlist: more info in the standard commit message of `sync`]]: - -It would also help debugging if the default commit messages listed, e.g., the name of all the files modified by that commit (or merge). - -> No, it would not help debugging to put redundant info in commit -> messages. It will only make your repository take up more disk space. -> git log --stat will already show you the files changes by -> any commit. [[wontfix|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___swift_backend.mdwn b/doc/todo/wishlist__58___swift_backend.mdwn deleted file mode 100644 index 6c1cef52f..000000000 --- a/doc/todo/wishlist__58___swift_backend.mdwn +++ /dev/null @@ -1,12 +0,0 @@ -[swift](http://swift.openstack.org/) is the object storage of Openstack. Think S3, but fully open source. As it's backed by rackspace.com, NASA, Dell and several other major players, adoption rates will explode. - -I can provide a test account soonish if need be, else rackspace.com if offering swift storage. Their API gateway lives at https://auth.api.rackspacecloud.com/v1.0 - -Richard - -> Swift is supported by -> <https://github.com/DanielDent/git-annex-remote-rclone> -> -> While I am not opposed to adding support for swift directly to git-annex, -> if a haskell library supporting it should appear, I think that's good -> enough so am calling this [[done]] --[[Joey]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment b/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment deleted file mode 100644 index 98a998c1c..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" - nickname="Jimmy" - subject="comment 1" - date="2011-05-14T10:04:36Z" - content=""" -I don't suppose this SWIFT api is compatible with the eucalytpus walrus api ? -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment b/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment deleted file mode 100644 index 97863b095..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" - nickname="Richard" - subject="comment 2" - date="2011-05-14T15:00:51Z" - content=""" -It does offer a S3 compability layer, but that is de facto non-functioning as of right now. -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment b/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment deleted file mode 100644 index 90af10c41..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_3_bf8625b909c3a7321cae40e6f145e874._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://ertai.myopenid.com/" - nickname="npouillard" - subject="+1" - date="2012-09-18T08:52:21Z" - content=""" -OVH (french IT company) is migrating its could storage infrastructure to swift/openstack and the next few weeks. -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment b/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment deleted file mode 100644 index 21fa52aaf..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_4_4d97d12ddd99834788e94648c8eebef9._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawm5Z8wzidsumLYQnHdrVxpCx8vsd9llSlg" - nickname="Emanuele" - subject="comment 4" - date="2013-11-22T15:52:42Z" - content=""" -OVH is offering free accounts with 25GB of storage on their hubiC service: https://hubic.com/en/ - -The API documentation (based on OAuth2 and OpenStack Swift) is available at https://api.hubic.com/ -"""]] diff --git a/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment b/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment deleted file mode 100644 index 1f0ff9f63..000000000 --- a/doc/todo/wishlist__58___swift_backend/comment_5_1568f726f91d4589aef7ca9fcc3c957d._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://schnouki.net/" - nickname="Schnouki" - subject="comment 5" - date="2014-02-11T13:38:53Z" - content=""" -FYI, I just published a [special remote for hubiC](https://github.com/Schnouki/git-annex-remote-hubic) that uses the OAuth API for authentication and the SWIFT API for data transfers. Parts of it are specific for hubiC (mostly auth.py), but it should be possible to adapt it to other SWIFT providers as well. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn b/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn deleted file mode 100644 index 4b0694422..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -as far as I know, if you `git clone` locally a git-annex enabled repository, it will not have all the files available. you would need to use `git annex get` and all files would be copied over, wasting a significant amount of space. - -`git-clone` has this `--local` flags which hardlinks objects in `.git/objects`, but also, maybe more interestingly, has a `--shared` option to simply tell git to look in another repo for objects. it seems to me git-annex could leverage those functionalities to avoid file duplication when using local repositories. - -this would be especially useful for [ikiwiki](http://ikiwiki.info/forum/ikiwiki_and_big_files). - -This is a [[wishlist]], but I would also welcome implementation pointers to do this myself, thanks! --[[anarcat]] - -> [[dup|done]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment deleted file mode 100644 index 4ef5f8414..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_1_85064fafe472a5bd395d60ce8f7acb56._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="4.152.108.220" - subject="comment 1" - date="2013-09-25T17:14:28Z" - content=""" -git-annex uses cp --reflink=auto. So on a filesystem supporting COW file copies, like btrfs, `git annex get` will not use any disk space when getting from the same filesystem. - -I do not like the idea of using hardlinks, because changing the file in one repository would change it in the other, which may not be desired. - -[[union_mounting]] seems to cover this item pretty well, so I will close this as a duplicate. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment deleted file mode 100644 index 8476b4220..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_2_ad51dced0c0146e1867830b93b520118._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawlUGPPMvAP5Hu0NyNqeRMPC4pANeJNHZ0o" - nickname="Sylvain" - subject="why worry about modifications ?" - date="2014-11-02T17:46:57Z" - content=""" -I don't understand why you worry about having one remote modify the file locally which would get propagated to the other because of the hardlinks. When using checksumming, the repos would be pretty screwed if someone would do that anyways. - -In other words, hardlinking the SHA-checksummed files in .git/annex/objects/ across repos and/or between e.g. a directory remote and a repo would sound a pretty safe and nice optimization to me. I am like the OP, deduplication that does not require brtfs would be a great git annex feature. -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment deleted file mode 100644 index c2e5fa207..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_3_650ded07dfb4c0c598f6ae649e45760b._comment +++ /dev/null @@ -1,30 +0,0 @@ -[[!comment format=mdwn - username="https://www.google.com/accounts/o8/id?id=AItOawkHTRzRZoBFEDl9XcTfVveW8yO7CTKMg-o" - nickname="Felix" - subject="use your own cp" - date="2015-02-04T14:16:14Z" - content=""" -As a workaround one could use another cp. Maybe something like this: - -Make an executable shell script \"cp\": - - #!/bin/sh - - p1=\"$1\" - shift - - if [ \"$p1\" = '--reflink=auto' ] ; then - p1='--link' - fi - - exec /bin/cp \"$p1\" \"$@\" - - -And put it into a directory which is found before the \"real\" cp: - - export PATH=/path/to/special/cp/:$PATH - - -This \"cp\" makes a hardlink if the '--reflink=auto' parameter is used (1st). - -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment deleted file mode 100644 index 69dc0a6ce..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_4_e0be9631d7f017dbff5baaabbd0e2d5c._comment +++ /dev/null @@ -1,14 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 4""" - date="2015-02-04T20:03:19Z" - content=""" -No, please don't wrap your `cp`. Forcing git-annex to hard link -files like that can result in data loss, in a number of different -scenarios. And it's generally asking for a broken system. - -Since version 5.20140915, you can "git clone --shared" and -this will set up a clone of a repository in which git-annex will -use hardlinks, in a safe and reliable way. (Notably it marks the clone -as untrusted.) -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment deleted file mode 100644 index 0aa945f6b..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_5_90aacf46abdeab34ec8e402613da679d._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="lealanko" - subject="comment 5" - date="2015-09-06T13:26:49Z" - content=""" -> you can \"git clone --shared\" and this will set up a clone of a repository in which git-annex will use hardlinks - -Copying files from the shared origin repository to the clone will create a hardlink, yes. But copying a file from the clone to the origin will still create a physical copy, even though the situation is quite comparable. Could hardlink support be added in this direction as well? -"""]] diff --git a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment b/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment deleted file mode 100644 index 68794ce0d..000000000 --- a/doc/todo/wishlist__58___use_hardlinks_for_local_clones/comment_6_3971f77ef70c81e4bf94cd0cab1335ac._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 6""" - date="2015-09-09T18:41:02Z" - content=""" -@lealanko, that's a good point, but a old closed todo item is not the best -place to make such a request. I've opened a new todo item about that. -"""]] diff --git a/doc/todo/wishlist__58__alias_system.mdwn b/doc/todo/wishlist__58__alias_system.mdwn deleted file mode 100644 index 5982a941b..000000000 --- a/doc/todo/wishlist__58__alias_system.mdwn +++ /dev/null @@ -1,3 +0,0 @@ -To implement things like my custom `git annex-push` without the dash, i.e. `git annex push`, an alias system for git-annex would be nice. - -> [[closing|done]] --[[Joey]] diff --git a/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment b/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment deleted file mode 100644 index ea8f2bd30..000000000 --- a/doc/todo/wishlist__58__alias_system/comment_1_5afad4b92f9a449d4a82a94ad31feec2._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="http://joeyh.name/" - ip="209.250.56.154" - subject="comment 1" - date="2014-03-18T19:38:19Z" - content=""" -Why not just use git's alias system? It can't make `git annex $foo` aliases, but `git $foo` is shorter anyway.. -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn deleted file mode 100644 index fe32f7dd7..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote.mdwn +++ /dev/null @@ -1,9 +0,0 @@ -When adding a Remote server through the webapp, it set-up a specific SSH key for later sync. - -However, when the remote has been set-up manually, then later gets the assistant thrown at it, there doesn't appear to be a way to create and deploy such a key. This option could be offered in, e.g., the settings of the repo in the webapp. - -> I feel this is out of scope for the assistant. If the user is able to -> manually add a git remote at the command line, then they should be able -> to configure ssh keys too. I don't want to complicate the assistant with -> a lot of code that tries to deal with half-configured things the user -> manually set up. [[wontfix|done]] --[[Joey]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment deleted file mode 100644 index d8e3f9337..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_1_13737dc99aa877b309f7ebe44ecbafee._comment +++ /dev/null @@ -1,16 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 1" - date="2014-01-22T13:08:21Z" - content=""" -Hum, fair enough. The webapp might not be the best target. However, there might already be some logic to deploy the key, only not exposed in any UI (web or CLI). - -However, I was under the impression that the key thath git-annex installs remotely is also limited to running git-annex-related tasks (using the command option; I cannot find any example in my configurations at the moment), rather than providing a generic login shell which happens to be used for git-annex. - -The command to run on the remote server did not seem to be trivial (this is what I'm currently bumping against), and I guess there already are a few functions which create and install the authorized_files entry. Maybe providing, e.g., a - - git-annex installkey REMOTE - -command, automating only this key-setup step for the user, would be good? -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment deleted file mode 100644 index 79ebb5e7c..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_2_06230669218541ac392d674bedd43176._comment +++ /dev/null @@ -1,43 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="Manual solution" - date="2014-06-14T13:59:38Z" - content=""" -My problem stems from the fact that I manually git clone the git-annex repo, which prevents the assistant from creating the setup to use passwordless keys. I just reverse-engineered a working setup to work up what I was missing. I jot it down here for reference, but I guess the bottomline is that if you want to use the assistant with a repo, do it from the start. - -I assume that the client has a clone of the git(-annex) repo of the server. - - client$ git clone server:annex - -Our goal is to let git-annex on the client know that there is a specific key to use when connecting to server that will let it access the git-annex-shell (without a password). We first create the key. - - client:~$ ssh-keygen -t rsa -f ~/.ssh/git-annex/key.git-annex-server-user_annex - [enter an empty passphrase] - -We can then create a virtual SSH host on the client that will use this key to connect to the server, in client:~/.ssh/config: - - # Added manually for git-annex - Host git-annex-server-user_annex - Hostname server - Port 22 - IdentityFile ~/.ssh/git-annex/key.git-annex-server-user_annex - IdentitiesOnly yes - StrictHostKeyChecking yes - -(git-annex seems to use .2F (%2F) to encode path separators in the filenames.) - -The server then needs to know to let the key in, but only for git-annex in the specific folder. This is done in server:.ssh/authorized_keys: - - command=\"GIT_ANNEX_SHELL_DIRECTORY='annex' ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA... user@client - -The bit starting with ssh-rsa is the public key created in client:.ssh/git-annex/key.git-annex-server-user_annex.pub at the same time as the private key. - -Finally, all that remains is to change the remote in the client clone to use the virtual SSH host. - - client:~/annex $ git remote set-url origin ssh://user@git-annex-server-user_annex/~/annex - client:~/annex $ git remote set-url origin --push ssh://user@git-annex-server-user_annex/~/annex - -If everything worked, a sync from the client should now work without asking for a password, and starting the assistant will not either. - -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment deleted file mode 100644 index 2515349a6..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_3_002afd775b82a0ced609c8305803a6c2._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 3" - date="2014-06-14T14:15:55Z" - content=""" -After having done that on my first test repo, git-annex could sync, but failed to get the files. - - client:~/annex$ git annex get file - get file (not available) - Try making some of these repositories available: - 12345678-90ab-cdef-1234567890abcdef1 -- user@server:~/annex [origin] - - (Note that these git remotes have annex-ignore set: origin) - failed - git-annex: get: 1 failed - -The note helps: the problem is with the origin remote having annex-ignore set. git-annex therefore ignores it. This is easily fixed by just setting the flag to false. - - client:~/annex$ git config remote.origin.annex-ignore false - -"""]] diff --git a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment b/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment deleted file mode 100644 index 06d16239a..000000000 --- a/doc/todo/wishlist__91__webapp__93____58___add_an_option_to_install__SSH_key_on_remote/comment_4_9e8fdc41fdefcb8be0d6bae7cd4a04a9._comment +++ /dev/null @@ -1,59 +0,0 @@ -[[!comment format=mdwn - username="http://olivier.mehani.name/" - nickname="olivier-mehani" - subject="comment 4" - date="2014-07-09T01:09:33Z" - content=""" -And the ultimate, copy/pastable one, using shell variables: - - export GASERVER=server - export GAUSER=user - export GAPATH=/path - -For the new client (using bash): - - export GASANEPATH=${GAPATH//\//.2F} - export GASSHHOSTNAME=${GASERVER}-${GAUSER}_${GASANEPATH} - ssh-keygen -t rsa -f ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME - cat << EOF >> ~/.ssh/config - # Added manually for git-annex - Host git-annex-$GASSHHOSTNAME - Hostname $GASERVER - IdentityFile ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME - IdentitiesOnly yes - StrictHostKeyChecking yes - EOF - ssh-copy-id -i ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME $GAUSER@$GASERVER - git remote add ${GASERVER/.*/} ssh://${GAUSER}@git-annex-${GASSHHOSTNAME}${GAPATH} - git config remote.${GASERVER/.*/}.annex-ignore false - -After the `ssh-copy-id` stage, the key can be used to get a full session. This -needs to be limited on the server, by prepending the following to the newly -added key in `.ssh/authorized_keys`, replacing `GAPATH` by the value of `$GAPATH`: - - command=\"GIT_ANNEX_SHELL_DIRECTORY='GAPATH' ~/.ssh/git-annex-shell\",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty - -From the client, one can make sure this has been limite properly by trying to log in with the key: - - ssh -i ~/.ssh/git-annex/key.git-annex-$GASSHHOSTNAME $GAUSER@$GASERVER -o IdentitiesOnly=yes - -It should reply with the `git-annex-shell` helper complaing: - - git-annex-shell: bad parameters - - Usage: git-annex-shell [-c] command [parameters ...] [option ...] - - Plumbing commands: - - commit DIRECTORY commits any staged changes to the git-annex branch - configlist DIRECTORY outputs relevant git configuration - dropkey DIRECTORY KEY ... drops annexed content for specified keys - gcryptsetup DIRECTORY VALUE sets up gcrypt repository - inannex DIRECTORY KEY ... checks if keys are present in the annex - notifychanges DIRECTORY sends notification when git refs are changed - recvkey DIRECTORY KEY runs rsync in server mode to receive content - sendkey DIRECTORY KEY runs rsync in server mode to send content - transferinfo DIRECTORY KEY updates sender on number of bytes of content received - -... and this should be all set. -"""]] diff --git a/doc/todo/xmpp_removal.mdwn b/doc/todo/xmpp_removal.mdwn deleted file mode 100644 index 373c16ca1..000000000 --- a/doc/todo/xmpp_removal.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -I'd like to eventually remove XMPP support from git-annex. --[[Joey]] - -The XMPP feature makes git-annex harder to build (needs a lot of C -libraries), and is increasingly rarely used. - -For over a year, git-annex-shell has been able to notify clients when a -change lands in a git repo on a ssh server. This notification is the main -thing XMPP support was used for. Even users without a ssh server of their -own don't need XMPP for this; the feature is supported by GitLab.com. - -The only other advantages to keeping XMPP support are: - -* Supports peer-to-peer git push over XMPP. Except, this hack has never - worked very reliably, and exposes the git repo to the XMPP server, - and needing an XMPP server is not a pure p2p solution anyway. -* Friend discovery and easy sharing of git repo to friends. - -It would be nice if there were a pure P2P replacement for XMPP, like -telehash. But, can't wait on that forever.. - -XMPP support is already disabled by default in some builds of git-annex, -notably the stack build. It's never worked on Windows. - -The [[no-xmpp]] branch is ready for merging. - -Next step is probably to default the flag to false by default, -except for in a few builds like the Debian package and standalone builds. - -> [[done]] diff --git a/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment b/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment deleted file mode 100644 index 6f67d3da8..000000000 --- a/doc/todo/xmpp_removal/comment_1_457f98a4354ad6c17dcfb5eeefb4b11e._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="dxld@02c834b220f9ffc0410d37263aa29d9373cc455b" - nickname="dxld" - subject="Fully p2p alternative to XMPP" - date="2015-10-01T17:22:44Z" - content=""" -It looks like no one else has suggested this yet so I guess I'll have to: [Tox](https://tox.chat/) - -Tox is pretty easy to build on all platforms (GNU/Linux, Mac and WinDOS). All the protocol relevant bits are implemented as a single C library (libtoxcore). It supports bulk file transfers and handles all the NAT hole punching nastiness internally AFAIK. - -Thoughts? - -"""]] diff --git a/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment b/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment deleted file mode 100644 index f13386a7f..000000000 --- a/doc/todo/xmpp_removal/comment_2_1c92cde199612bbd765c818e7b64f944._comment +++ /dev/null @@ -1,46 +0,0 @@ -[[!comment format=mdwn - username="Gastlag" - subject="Is xmpp the problem ?" - date="2015-10-30T10:42:06Z" - content=""" -Hello, - -I was wondering why assistant \"is increasingly rarely used\" ? -if you look the different item of the survey http://git-annex-survey.branchable.com/polls/2015/, yes 53% of people said \"I use the assistant, but without XMPP\" - -And \"missing ports\" : - - - \"I'm good -- git-annex runs on my OSes of choice! (43%)\" - - \"Windows (13%)\" - - Android (6%) - -But if you look other anwsers you see - - - \"using with\" : - - by myself (59%) - - by myself so far but I hope to get others using my repository (28%) - -And : - - - \"Pick the operating system which you use git-annex on the most.\" : - - \"Linux (78%)\" - - \"OSX (13%)\" - - -Further more \"blocking problems\" : - - - too hard to install (4%) - - too hard to use (7%) - - not good enough documentation (16%) - - The only use for the assistant would be in combination with a good, native, fully automagic Android version which includes some sort of native UI (16%) - - I use the command line, and **find it difficult to show others** how to use the git-annex assistant (12%) - - The lack of selective file sync (ie, git annex get and git annex drop) is what prevents me from using the Assistant (5%) - -And \"focus\" : - - - make it easier for nontechnical users (25%) - -I think remove xmpp is a bad idea because as you say it's enable \"Friend discovery and easy sharing of git repo to friends.\" and there is already a lot of people who use xmpp and XMPP address are user friendly because close to email adress. And the main problem seems to be that git-annex assistant still too hard to use and not usable on the platform where users are : windows. - -The main problem is that git-annex is still not ready for users. It have too reach other people than \"hardcore linux users\" to be a social tool and remove xmpp may not be the good solution. -"""]] diff --git a/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment b/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment deleted file mode 100644 index f17a19869..000000000 --- a/doc/todo/xmpp_removal/comment_3_661be364029ce45db7d6a111b9d65ee7._comment +++ /dev/null @@ -1,13 +0,0 @@ -[[!comment format=mdwn - username="https://id.koumbit.net/anarcat" - subject="re tox" - date="2015-10-30T15:37:09Z" - content=""" -i am not sure the proper replacement for XMPP is tox. First off, Debian privacy folks have [expressed concerns about the actual security of Tox](http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20150928/000046.html), which is not a big requirement here, but nevertheless is a question worth adressing. [Pond](https://pond.imperialviolet.org/) and [Ricochet](http://ricochet.im/) are interesting alternatives that are being packaged in Debian (the latter which just entered unstable). - -Furthermore, it seems that XMPP is really a \"patch\", a workaround for NAT issues and, in general, how to share git-annex repositories with users in arbitrary locations. This problem space is more similar to [[todo/Bittorrent-like_features/#index1h1]] than XMPP. Using tox libraries may enable git-annex to share git metadata around, but would it allow git-annex to download actual files from other users through tox? How stable is tox? Last I checked, [tox core don't actually want to make any releases](https://github.com/irungentoo/toxcore/issues/1353), which makes it a much less attractive option because the API can change all the time... - -I have nevertheless added the three tools to [[todo/Bittorrent-like_features/]]. - -Anyways, it seems that XMPP is rarely used and could be removed if it makes maintenance easier: i have never found a good use case for it, personnally: you can usually find a space for a private git repo fairly easily... the problem is sharing the big files! --[[anarcat]] -"""]] |