Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
fde5c83426
17 changed files with 169 additions and 0 deletions
|
|
@ -0,0 +1,11 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T17:32:17Z"
|
||||
content="""
|
||||
I tested this version of git-annex on Android 4.0, doing both an upgrade and a fresh install. In both cases, sha256sum and the other busybox links were set up ok.
|
||||
|
||||
At this point this looks to be either specific to your version of Android, or some problem that botched the install.
|
||||
Please follow-up with the requested information. Also, try removing and reinstalling git-annex from scratch.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 7"
|
||||
date="2014-05-21T18:31:54Z"
|
||||
content="""
|
||||
It seems to me that if you don't want to repair your repository, you can just go into the webapp and disable all scheduled consistency check jobs.
|
||||
|
||||
If someone with this problem would like to run \"git annex repair\" at the console, and paste the output, perhaps I could then see why it thinks it needs to repair the repository. So far, I have nothing to go on, and no proof that this is a bug at all, and not just people with actually corrupted repositories that really do need to be repaired.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="EskildHustvedt"
|
||||
ip="80.202.103.55"
|
||||
subject="comment 8"
|
||||
date="2014-05-21T19:19:30Z"
|
||||
content="""
|
||||
The trouble with providing more information (outside of the logfile above) is that by the time I realize that there is a problem it is because git-annex has started to repair. Perhaps an option that makes git-annex write a ~/.git/annex/repair-reason.log file with the reason (ie. git fsck output etc.) for starting the repair could help?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 1"
|
||||
date="2014-05-21T17:10:24Z"
|
||||
content="""
|
||||
reproduced this with android 4.0
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T18:06:09Z"
|
||||
content="""
|
||||
I've verified that the assistant is serving up the files, such as http://127.0.0.1:$port/static/fonts/glyphicons-halflings-regular.svg
|
||||
|
||||
I've verified that the files it's serving have the right content.
|
||||
|
||||
This seems to only leave the likely explanation that the android web browser doesn't support the technology bootstrap 3 is using for its icons. This is svg, plus ttf, plus Embedded OpenType and Web Open Font Format. (I suppose it uses different ones on different browsers.)
|
||||
|
||||
I'm surprised that bootstrap would be using web fonts technology if it's not supported on Android, or wouldn't have a fallback to the plain old image method old versions of bootstrap used.
|
||||
|
||||
I have found some bootstrap bugs about icons not showing up on Android, like this one <https://github.com/twbs/bootstrap/issues/10106> ... but those are about specific icons not showing up due to unicode issues. Not about all icons failing to show up.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
|
||||
nickname="Sören"
|
||||
subject="comment 3"
|
||||
date="2014-05-21T18:47:42Z"
|
||||
content="""
|
||||
I don't think it's an issue with the Android browser. It happens with Chrome and Firefox on Android as well. Moreover, the icons still don't show up if open the Webapp running on Android over network from a desktop browser. Firebug doesn't even show the request that should load the font file (compare to the desktop version where it loads the woff file in Firefox). So I suspect the Web server behaves different somehow. Some weird blocking issue maybe?
|
||||
|
||||
Not sure if this is related but I noticed a strange behavior: If I try to download the font file in a new tab, it blocks until I refresh the tab running the webapp. Only seen on desktop Firefox. Doesn't happen in Chromium.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmqz6wCn-Q1vzrsHGvEJHOt_T5ZESilxhc"
|
||||
nickname="Sören"
|
||||
subject="comment 4"
|
||||
date="2014-05-21T19:19:45Z"
|
||||
content="""
|
||||
I forgot to mention that the --listen argument doesn't seem to work on Android so I used ssh -R in order to access the webapp from my desktop.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T17:11:27Z"
|
||||
content="""
|
||||
It seems to me that your filesystem is broken.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawkAUMhKOSkh9JaBA6xst3XxQIIsDEq5Zd4"
|
||||
nickname="Ovidiu"
|
||||
subject="OK"
|
||||
date="2014-05-21T18:19:30Z"
|
||||
content="""
|
||||
so I'll watch this behavior with future updates and reply if I have more info
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 9"
|
||||
date="2014-05-21T17:28:16Z"
|
||||
content="""
|
||||
I have adjusted the \"Cannot find old distribution bundle; not upgrading\" message to say where it looked, and failed to find the git-annex.app directory.
|
||||
|
||||
I am going to have to moreinfo this, since without knowing where git-annex was installed to, I can't say why it failed to find a git-annex.app directory.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T17:18:08Z"
|
||||
content="""
|
||||
git-annex only uses dbus to detect when drives and networks come and go, this has nothing to do with its core functionality and i would be very surprised if lack of dbus being installed prevented it from working in any way.
|
||||
|
||||
It's not clear to me if you think that installing dbus somehow fixed your issue.
|
||||
|
||||
You seem to have filed a second bug report, [[Daemon_stops_working_on_mounted_CIF_share]] about the same symptoms, and in that bug report, it looks rather like your network(?) file system is badly broken and so git-annex cannot access it.
|
||||
|
||||
Please follow up with clarifications.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T18:11:45Z"
|
||||
content="""
|
||||
It seems to me that simply running `git annex sync --content` before you go home would do what you need. Have you tried using git-annex?
|
||||
|
||||
Some of the things you're saying don't entirely make sense to me, and so I suspect you're perhaps worrying about problems that don't exist, or that git-annex deals with nicely.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 1"
|
||||
date="2014-05-21T17:41:22Z"
|
||||
content="""
|
||||
If you also have the files present locally, you can simply do `git annex copy --fast --to remote`. git-annex copy will first check to see if the remote has the file; seeing that it does it will update the location log.
|
||||
|
||||
Another option, if you have shell access on the remote is to simply set up a git repository there, move the files into it and `git annex add` them, and merge that into your local repository.
|
||||
|
||||
There is not currently any way to set the [[location_tracking]] information to tell git-annex that a file has appeared on a remote. Of course, you can modify the git-annex branch manually to do so. See [[internals]].
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://id.koumbit.net/anarcat"
|
||||
ip="70.83.139.100"
|
||||
subject="comment 4"
|
||||
date="2014-05-21T18:02:51Z"
|
||||
content="""
|
||||
i like @yesterday, that's a neat trick that would have basically resolved my problem here. thanks!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 1"
|
||||
date="2014-05-21T18:29:16Z"
|
||||
content="""
|
||||
What auto-repair are you referring to?
|
||||
|
||||
If you schedule a fsck of the repository in the webapp, then when that finds a problem with the git repository, it will be repaired. So if you don't want this, remove any scheduled fsck jobs.
|
||||
|
||||
The assistant also detects a few common problems at startup that prevent it from working, such as a corrupt index file, and automatically repairs those. These repairs only happen at startup. If the index file is corrupt, it has to delete it and re-add every file to the repository, which is expensive, but otherwise it would be completely non-functional.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
ip="209.250.56.3"
|
||||
subject="comment 2"
|
||||
date="2014-05-21T18:35:42Z"
|
||||
content="""
|
||||
Note that this is asking for a workaround for the bug [[bugs/Auto-repair_greatly_slows_down_the_machine]]. I would rather get to the bottom of that bug, but need more information to do so.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="EskildHustvedt"
|
||||
ip="80.202.103.55"
|
||||
subject="comment 3"
|
||||
date="2014-05-21T19:18:19Z"
|
||||
content="""
|
||||
I'm referring to the large auto-repairs of the actual git repository, as mentioned in the bug report you are referring to. I was under the impression that the fscks also did the equivalent of 'git annex fsck' (which is greatly desired, even without the 'git fsck' checks). I realize it is a sort of workaround, but it is because the 'annex fsck' bit is desired, while the 'git annex repair' bit makes my computer unusable, the last time for over 24 hours, while it was running (at which point I needed to kill it and perform a manual repair).
|
||||
"""]]
|
||||
Loading…
Add table
Add a link
Reference in a new issue