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 failure on Travis Linux v0.6 without sudo #94

Closed
ChrisRackauckas opened this issue Oct 26, 2017 · 4 comments · Fixed by #145
Closed

Build failure on Travis Linux v0.6 without sudo #94

ChrisRackauckas opened this issue Oct 26, 2017 · 4 comments · Fixed by #145

Comments

@ChrisRackauckas
Copy link

I am getting build failures for NLopt on Travis Linux with Julia v0.6:

https://travis-ci.org/JuliaDiffEq/DiffEqParamEstim.jl/jobs/288848654#L641

https://travis-ci.org/JuliaDiffEq/DiffEqParamEstim.jl/jobs/288848654#L981

INFO: Building NLopt
WARNING: Compat.ASCIIString is deprecated, use String instead.
  likely near /home/travis/.julia/v0.6/NLopt/deps/build.jl:56
================================[ ERROR: NLopt ]================================
LoadError: failed process: Process(`sudo apt-get install libnlopt0`, ProcessExited(1)) [1]
while loading /home/travis/.julia/v0.6/NLopt/deps/build.jl, in expression starting on line 56
================================================================================

I'm a little confused because I assume that means it needs sudo, but your .travis.yml has sudo: false and seems to build correctly. This only started happening less than 2 months ago according to my build history:

https://travis-ci.org/JuliaDiffEq/DiffEqParamEstim.jl/builds

but nothing in the last two NLopt releases stands out as something that could cause this issue to me.

@ChrisRackauckas
Copy link
Author

ChrisRackauckas commented Oct 26, 2017

It looks like requiring sudo allowed it to build for me:

https://travis-ci.org/JuliaDiffEq/DiffEqParamEstim.jl/jobs/293288139#L621

So I guess it's not really much of an issue since that's a fix, but I still find it odd that it's required? This can probably be closed as a non-issue but it's worth mentioning. Maybe it's because it's a test dependency and not a normal dependency so it's treated a little differently?

@ChrisRackauckas ChrisRackauckas changed the title Build failure on Travis Linux v0.6 Build failure on Travis Linux v0.6 without sudo Oct 26, 2017
@BenjaminBorn
Copy link

I also encountered this with Julia 0.6 on Ubuntu:

INFO: Building NLopt
WARNING: Compat.ASCIIString is deprecated, use String instead.
  likely near /home/bborn/.julia/v0.6/NLopt/deps/build.jl:56
sudo: no tty present and no askpass program specified
================================[ ERROR: NLopt ]================================

LoadError: failed process: Process(`sudo apt-get install libnlopt0`, ProcessExited(1)) [1]
while loading /home/bborn/.julia/v0.6/NLopt/deps/build.jl, in expression starting on line 56

================================================================================

================================[ BUILD ERRORS ]================================

WARNING: NLopt had build errors.

 - packages with build errors remain installed in /home/bborn/.julia/v0.6
 - build the package(s) and all dependencies with `Pkg.build("NLopt")`
 - build a single package by running its `deps/build.jl` script

===============================================================================

Installing libnlopt0 by hand solved the problem.

@aytekinar
Copy link

Hey Chris. Thank you for letting me know about the open issue on NLopt's build failure. Of course this failure can be easily handled by requiring sudo on the Travis side. However, I think, the approach in deps/build.jl is not symmetric. What I mean is that NLopt will be using

  • the distribution installed version of the library on apt-based systems,
  • source-built version of the library on other Linux machines (this was the case on my Arch Linux),
  • homebrew installed version of the library in Darwin, and,
  • continuous integration built version of the library in Windows systems.

@BenjaminBorn's solution is OK in apt-based systems, if you have root access to the given platform. However, if I am running this script on an Ubuntu server on which I only have a user account, I will most likely have trouble.

What would be even better, in my opinion, is to download the corresponding built artifacts for all platforms libnlopt_cxx-{x86,x64}.{so,dylib,dll}. Then, nobody will need to

  • have root access to their platforms (once Julia is installed), or,
  • wait for libnlopt_cxx compilation on their systems (non-apt-based Linux machines, Darwin).

Moreover, it will be easier to maintain the package in Julia's side --- no problem if a user down-/up-grades their libnlopt0 package using some apt-get commands.

I was experimenting with this thing on my playground (C++ library, Julia script), and I am sure @stevengj can do even better (I can see in his repo already that even the CMakeLists.txt file exists). The only thing that remains is to mark dylib (either as separate 32-/64-bit files, or a single 96-bit file for both architectures) and so files as artifacts in travis.yml file, and change the deps/build.jl script accordingly.

Contributors of this package must be already well aware of this method since they are already using the file downloader for Windows platforms. Maybe they have some concrete reasons to keep this dependency asymmetric.

@cecileane
Copy link

Same issue on our side: build failure of PhyloNetworks (on Travis, Linux) because it depends on NLopt.

INFO: Building NLopt
Installing dependency libnlopt0 via `apt-get install libnlopt0`:
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

We fixed this issue in the same way that this is fixed for NLopt. But it would be best for NLopt to avoid this issue altogether. All downstream packages will have to deal with it otherwise.

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

Successfully merging a pull request may close this issue.

4 participants