mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2013-05-24 12:46:57 -04:00
commit c84538433a
10 changed files with 181 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

21
doc/bugs/Cabal_cannot_solve_dependencies/comment_1_1d41ac79867226dcb71f1c7b38da062d._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-05-24T14:21:03Z"
content="""
Since I tested this release in a clean system, I suspect you have a ~/.ghc and ~/.cabal with something installed that is causing this dependency problem for you.
<pre>
# rm -rf .ghc .cabal
# cabal update
Config file path source is default config file.
Config file /root/.cabal/config not found.
Writing default configuration to /root/.cabal/config
Downloading the latest package list from hackage.haskell.org
# cabal install git-annex
Resolving dependencies...
Downloading HUnit-1.2.5.2...
Configuring HUnit-1.2.5.2...
</pre>
"""]]

48
doc/bugs/Cabal_cannot_solve_dependencies/comment_2_50e72633a4462f6f6eb33d57b137fdcc._comment Normal file
View file

@ -0,0 +1,48 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmu416zAYgYzbXVZAe30MiXoOWO4z6nGX8"
nickname="Johannes"
subject="comment 2"
date="2013-05-24T14:59:54Z"
content="""
Thanks for the quick comment. I was already trying to build this on a clean cabal system.
However, as of 4.20130521.2, I now get this:
[[!format sh \"\"\"
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: git-annex-4.20130521.2
trying: git-annex-4.20130521.2:+webapp
rejecting: yesod-1.2.0.1, 1.2.0 (conflict: git-annex-4.20130521.2:webapp =>
yesod(<1.2))
trying: yesod-1.1.9.3
trying: http-conduit-1.9.3
trying: certificate-1.3.7
rejecting: crypto-pubkey-types-0.4.0 (conflict: certificate =>
crypto-pubkey-types>=0.3 && <0.4)
trying: crypto-pubkey-types-0.3.2
trying: tls-extra-0.6.3
rejecting: crypto-pubkey-0.1.4 (conflict: crypto-pubkey-types==0.3.2,
crypto-pubkey => crypto-pubkey-types>=0.4 && <0.5)
rejecting: crypto-pubkey-0.1.3, 0.1.2, 0.1.1, 0.1.0 (conflict: tls-extra =>
crypto-pubkey>=0.1.4)
\"\"\"]]
Also tried adding a --constraint='tls-extra<0.6.3' with the following result:
[[!format sh \"\"\"
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: git-annex-4.20130521.2
trying: git-annex-4.20130521.2:+webapp
trying: git-annex-4.20130521.2:+dns
trying: dns-0.3.6
trying: binary-0.7.1.0/installed-caa...
rejecting: yesod-1.2.0.1, 1.2.0 (conflict: git-annex-4.20130521.2:webapp =>
yesod(<1.2))
trying: yesod-1.1.9.3
trying: ghc-7.6.3/installed-875...
rejecting: bin-package-db-0.0.0.0/installed-608... (conflict:
binary==0.7.1.0/installed-caa..., bin-package-db =>
binary==0.5.1.1/installed-72e...)
\"\"\"]]
"""]]

10
doc/bugs/Cabal_cannot_solve_dependencies/comment_3_886f2d1f7c47a3973b8dc7d7c412289a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 3"
date="2013-05-24T15:05:13Z"
content="""
bin-package-db is shipped with ghc, so this may be down to your version of ghc. FWIW, I have tested .2 on OSX with ghc 7.4.2 & it works.
(I can only support users cabal hell problems so far. Cabal is, unfortunately, basically buggy, and this is a large part of why I provide autobuilds.)
"""]]

14
doc/bugs/git-annex:___60__socket:_16__62__:_hPutBuf:_resource_vanished___40__Broken_pipe__41__/comment_1_e962317a939bf76097ae1a3b53b146e6._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-05-24T15:50:45Z"
content="""
I have seen this once on a similar system (family computer; XMPP being used). Unfortunatly it could be coming from anywhere -- and it's not at all clear how a crash in one thread could take it all down, since there are global top-level per-thread exception handlers that should run and log which thread crashed -- and normally seem to do this quite well.
I may need to make a management process that ensures the assistant stays alive.
I have also seen this happen when a computer is shutting down. But presumably in that case it's not really a bug.
One thing you might try is see what is using socket 16 when it's running, assuming the socket will be the same. (Also, if you've had repeated crashes, it would be good to know if it's 16 each time..). You could do this by looking at `/proc/$pid/fd/16` Also, check the old logs, `.git/annex/daemon.log.*`
"""]]