Skip to content
This repository has been archived by the owner on May 27, 2019. It is now read-only.

Error when building from source using docker #280

Closed
daltonmatos opened this issue Aug 1, 2018 · 4 comments
Closed

Error when building from source using docker #280

daltonmatos opened this issue Aug 1, 2018 · 4 comments

Comments

@daltonmatos
Copy link

Hello @maximbaz and @dannyvankooten !

The docs has instruction on buildng the project using docker, but the Makefile seems to have some targets with missing dependencies.

Exact steps to reproduce the problem

  1. Clean your environment: (make clean)
  2. Remove node_modules and vendor (rm -rf node_modules/ vendor/)
  3. Build the base image (docker build -t browserpass-dev .)
  4. Run the command to build the backend (docker run --rm -v "$(pwd)":/browserpass browserpass-dev browserpass)

What should happen?

The code should build the final binary, browserpass.

What happened instead?

the build fails with this error:

docker run --rm -v $PWD:/browserpass browserpass-dev browserpass

go build -o browserpass ./cmd/browserpass
browserpass.go:17:2: cannot find package "github.com/gokyle/twofactor" in any of:
	/usr/local/go/src/github.com/gokyle/twofactor (from $GOROOT)
	/go/src/github.com/gokyle/twofactor (from $GOPATH)
pass/disk.go:13:2: cannot find package "github.com/mattn/go-zglob" in any of:
	/usr/local/go/src/github.com/mattn/go-zglob (from $GOROOT)
	/go/src/github.com/mattn/go-zglob (from $GOPATH)
pass/disk.go:14:2: cannot find package "github.com/sahilm/fuzzy" in any of:
	/usr/local/go/src/github.com/sahilm/fuzzy (from $GOROOT)
	/go/src/github.com/sahilm/fuzzy (from $GOPATH)
make: *** [Makefile:42: browserpass] Error 1

The problem is that the target browserpass does not depend on the target deps, so to build the backend code I actually need to run 2 commands:

docker run --rm -v $PWD:/browserpass browserpass-dev deps 
docker run --rm -v $PWD:/browserpass browserpass-dev browserpass

Since the docs says that it's sufficient to run only the second command to build the backend code, it should automatically dun the deps target.

Also, even with a succsessfull build of the backend, the install.sh fails with

./install.sh 

Select your browser:
====================
1) Chrome
2) Chromium
3) Firefox
4) Vivaldi
1-4: 2

Installing Chromium host config
ERROR: '/home/daltonmatos/src/browserpass/chrome-host.json' is missing.
If you are running './install.sh' from a release archive, please file a bug.
If you are running './install.sh' from the source code, make sure to follow CONTRIBUTING.md on how to build first.

But if I build the js target, install.sh now works.

Are you interested in receiving a PR to fix this?

Thanks a lot for your project.

@maximbaz
Copy link
Member

maximbaz commented Aug 1, 2018

Hello 🙂

Have you seen CONTRIBUTING.md? You shouldn't provide any make goal, the default one will build everything. Or alternatively you indeed need to provide 3 goals, deps, js and browserpass.

@daltonmatos
Copy link
Author

Hello @maximbaz,

yes, I saw the contributing docs. Quoting the docs:

If you only want to download dependencies, build front-end or backend code, run one of the following:
docker run --rm -v "$(pwd)":/browserpass browserpass-dev deps
docker run --rm -v "$(pwd)":/browserpass browserpass-dev js
docker run --rm -v "$(pwd)":/browserpass browserpass-dev browserpass

the docs says to run ONE of the commands, this made me understand that to build the backend code I should run only the last command.

Maybe we could clarify the docs and say that if we want to build only one part of the project we need to always run the deps target. What do you think?

@maximbaz
Copy link
Member

maximbaz commented Aug 1, 2018

Well, not always, right - only the first time 🙂 If you are developing the backend code and constantly rebuilding it, you don't want to slow down yourself by always re-running deps target.

Maybe I should write that not specifying a make goal is the preferred approach?

@daltonmatos
Copy link
Author

Indeed it makes sense, in an every day development scenario. In fact, the slowness depends on our build tools. For instance, if the deps is smart enough to not re-build every timeit is called, the slowness will be imperceptible.

I think the best is indeed suggest that only the default targets be used. If someone is developing, he/she will probably poke around in the Makefile and find out that there are more targets available to be called, if needed.

Thanks,

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

No branches or pull requests

2 participants