Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Stack with docker fails due to git connection issue. #735

Closed
ghost opened this issue Aug 8, 2015 · 10 comments
Closed

Build Stack with docker fails due to git connection issue. #735

ghost opened this issue Aug 8, 2015 · 10 comments
Assignees
Milestone

Comments

@ghost
Copy link

ghost commented Aug 8, 2015

This issue was reproduced using the latest stack version on github 542f027 HEAD@{0}:

Adding docker container in stack breaks the build with the error below.
Without docker option in the stack.yaml configuration I do not see this error.

"The authenticity of host 'github.com (192.30.252.128)' can't be established.RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.Are you sure you want to continue connecting (yes/no)? yesRunning /usr/bin/git clone git@github.com:tweag/HaskellR.git /home/vincent/webserver0808/.stack-work/downloaded/3481091ee93a693fdfc2120a6269ec26a30dcb79ba6069dfdc8be2162a96ffb0.git.tmp/ exited with ExitFailure 128Cloning into '/home/vincent/webserver0808/.stack-work/downloaded/3481091ee93a693fdfc2120a6269ec26a30dcb79ba6069dfdc8be2162a96ffb0.git.tmp'...Warning: Permanently added 'github.com,192.30.252.128' (RSA) to the list of known hosts.Permission denied (publickey).fatal: Could not read from remote repository.Please make sure you have the correct access rightsand the repository exists."

PS: I am moving to the docker option to workaround this strange build/linking issue which seems to be triggered in my environment.
[ 6 of 12] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Settings/StaticFiles.o ) /usr/bin/ld: .stack-work/dist/x86_64-linux/Cabal-1.18.1.5/build/Settings.dyn_o: relocation R_X86_64_PC32 against symbol `ITMICwebserverzm0zi0zi1_Settings_staticRoot_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

There isn't enough information here for me to attempt to reproduce the problem. Please include stack --verbose output and instructions for reproduction (code, commands run, etc.). See https://github.com/commercialhaskell/stack/blob/master/CONTRIBUTING.md for our preferred format for bug reports.

Also, does the fact that you're including git output imply that you're running git from within the Docker container? Normally you'd run git on the host, since the container won't have access to your private key for cloning private repos.

@drwebb, are you by any chance familiar with this project? Seeing similarities with something you mentioned on Thursday.

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

Ok, had a thought about this while washing dishes... Are you, by any chance, using a reference to the git@github.com:tweag/HaskellR.git repo in your stack.yaml? If so, I'd recommend using a git submodule instead.

Also, is the relocation R_X86_64_PC32 against symbol 'ITMICwebserverzm0zi0zi1_Settings_staticRoot_closure' can not be used error appearing when using Docker, or was that happening before you tried to enable Docker?

@drwebb
Copy link
Contributor

drwebb commented Aug 8, 2015

So we are trying to debug by just cloning the repo and adding a normal
subdirectory to the project.

The second error is a GHC bug, covered in #614. We are trying to work
around that bug by using docker. The entire project builds on my machine
with the same stack.yaml.

On Sat, Aug 8, 2015 at 9:25 AM, Emanuel Borsboom notifications@github.com
wrote:

Ok, had a thought about this while washing dishes... Are you, by any
chance, using a reference to the git@github.com:tweag/HaskellR.git repo
in your stack.yaml? If so, I'd recommend using a git submodule instead.

Also, is the relocation R_X86_64_PC32 against symbolITMICwebserverzm0zi0zi1_Settings_staticRoot_closure'
can not be used` error appearing when using Docker, or was that happening
before you tried to enable Docker?


Reply to this email directly or view it on GitHub
#735 (comment)
.

Tristan Webb PhD
Haskell Application Engineer
FP Complete
San Diego, CA
M: 619-452-9545

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

@drwebb You may already have had HaskellR locally before enabling Docker, in which case stack wouldn't have had to clone it again in the container.

@drwebb
Copy link
Contributor

drwebb commented Aug 8, 2015

Sorry, could you clarify what you mean there? I do believe the project was
building locally with HaskellR being checked out from git. In the version
of the stack.yaml that was failing with the ghc bug I upped the SHA hash to
a newer HaskellR commit, so in theory the local copy of HaskellR would need
to be checked out to a newer revision to do the build.

Can we think of a way to reproduce this?

On Sat, Aug 8, 2015 at 9:30 AM, Emanuel Borsboom notifications@github.com
wrote:

@drwebb https://github.com/drwebb You may already have had HaskellR
locally before enabling Docker, in which case stack wouldn't have had to
clone it again in the container.


Reply to this email directly or view it on GitHub
#735 (comment)
.

Tristan Webb PhD
Haskell Application Engineer
FP Complete
San Diego, CA
M: 619-452-9545

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

Does the stack.yaml point to a git repo or a local working tree?

I was able to reproduce this error by running stack new and editing stack.yaml to contain:

flags: {}
packages:
- '.'
- location:
    git: git@github.com:tweag/HaskellR.git
    commit: ef378ddee3ff56a5c2533dc5ba697425f2c6dd47
  subdirs:
  - H
  - inline-r
extra-deps: []
resolver: lts-2.20
docker:
  enable: true
  repo: <omitted>

With that setup, I see the same error:

$ stack build
Caching build plan
Populated index cache.
The authenticity of host 'github.com (192.30.252.129)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Running /usr/bin/git clone git@github.com:tweag/HaskellR.git /home/manny/tmp/g/.stack-work/downloaded/e1a8f92530590648a429c4341a99a8c61b78522f66f92405811908f6a62ded05.git.tmp/ exited with ExitFailure 128
Cloning into '/home/manny/tmp/g/.stack-work/downloaded/e1a8f92530590648a429c4341a99a8c61b78522f66f92405811908f6a62ded05.git.tmp'...
Warning: Permanently added 'github.com,192.30.252.129' (RSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

If I remove the docker section from stack.yaml, it is able to clone HaskellR successfully.

@borsboom
Copy link
Contributor

borsboom commented Aug 8, 2015

To clarify my earlier comment: git clones are cached in .stack-work/downloaded/<SHA>.git, so if you'd previously run without docker and the same commit, it would already be cached and so not have to clone it again. But if, as you say, you'd never run stack without docker using the commit in the stack.yaml, then I can't explain why it would have worked for you. Are you certain you saw it clone the repo when you had docker enabled? Have you tried removing the cache in .stack-work/downloaded to try to reproduce?

Are you able to work around this error by cloning using git on the host and then referencing the clone's working tree in stack.yaml? Or is it still a problem even then?

@drwebb drwebb self-assigned this Aug 9, 2015
@drwebb
Copy link
Contributor

drwebb commented Aug 9, 2015

I will have to look into reproducing the bug again.

@snoyberg snoyberg added this to the Support milestone Aug 13, 2015
@snoyberg
Copy link
Contributor

snoyberg commented Sep 6, 2015

@drwebb can this issue be closed? It's been untouched for 27 days.

@snoyberg
Copy link
Contributor

Closing due to lack of feedback

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants