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

libcurl problems with libgit2 on master #13472

Closed
lkuper opened this issue Oct 7, 2015 · 89 comments · Fixed by #17783
Closed

libcurl problems with libgit2 on master #13472

lkuper opened this issue Oct 7, 2015 · 89 comments · Fixed by #17783
Labels
domain:packages Package management and loading libgit2 The libgit2 library or the LibGit2 stdlib module
Milestone

Comments

@lkuper
Copy link

lkuper commented Oct 7, 2015

I'm seeing the following issue when trying to use Pkg.init() on a fresh build of master:

$ ./julia 
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: https://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-dev+640 (2015-10-06 18:24 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit 128f8c6 (0 days old master)
|__/                   |  x86_64-linux-gnu

julia> Pkg.init()
INFO: Initializing package repository /home/lkuper/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
ERROR: GitError(Code:ERROR, Class:Net, SSL error: error:140E0114:SSL routines:SSL_shutdown:uninitialized)
 [inlined code] from libgit2/error.jl:96
 in clone at libgit2/repository.jl:185
 in clone at libgit2.jl:303
 in anonymous at pkg/dir.jl:49
 in cd at file.jl:22
 in init at pkg/dir.jl:47
 in init at pkg.jl:23

I started seeing this after pulling and rebuilding to fix the libgit2 SSL certificate issue in #13399. I'm now seeing this error instead of the certificate error. There's more discussion on that bug.

This is on Ubuntu 14.04, and I have libssl-dev installed. I've already tried make -C deps distclean-libgit2. I even did a make distcleanall to make extra sure.

Before I deleted my ~/.julia/v0.5 directory (because I hoped that doing that and running Pkg.init() might solve the problem), I was seeing a similar error message from Pkg.update().

I'm also having the same problem on CentOS with openssl-devel installed.

@tkelman tkelman added the domain:packages Package management and loading label Oct 7, 2015
@tkelman
Copy link
Contributor

tkelman commented Oct 7, 2015

Can you try changing the branch and sha in deps/libgit2.version to master and ac69a82358ef444de433a8e0af62a4b6bd5c2c4e then make -C deps distclean-libgit2 && make ? @wildart was implying that maybe master of libgit2 would give a more informative error here.

@wildart
Copy link
Member

wildart commented Oct 7, 2015

As I wrote in #13399, some connectivity problem raised an error which was overwritten by an incorrect SSL shutdown. SSL shutdown now is fixed a week ago in master branch, so correct error reporting is expected. However, master branch introduced some changes into fetch related structures, so julia segfaults now on libgit2 master build.
This patch should solve segfaults and get you to correct error report with libgit2 master branch:

@@ -179,16 +179,19 @@ immutable FetchOptions
     prune::Cint
     update_fetchhead::Cint
     download_tags::Cint
+    custom_headers::StrArrayStruct
 end
 FetchOptions(; callbacks::RemoteCallbacks = RemoteCallbacks(),
                prune::Cint = Consts.FETCH_PRUNE_UNSPECIFIED,
                update_fetchhead::Cint = one(Cint),
-               download_tags::Cint = Consts.REMOTE_DOWNLOAD_TAGS_AUTO
+               download_tags::Cint = Consts.REMOTE_DOWNLOAD_TAGS_AUTO,
+               custom_headers::StrArrayStruct=StrArrayStruct()
 ) = FetchOptions(one(Cuint),
                  callbacks,
                  prune,
                  update_fetchhead,
-                 download_tags)
+                 download_tags,
+                 custom_headers)

 immutable CloneOptions
     version::Cuint

@lkuper
Copy link
Author

lkuper commented Oct 7, 2015

@tkelman Thanks. I just tried that and then built Julia with @wildart's patch. Sure enough, I now see a more informative error message ("Connection timed out"). The problem is that under Julia 0.3.11 on the same machine with the same git configuration, Pkg.init(), Pkg.update(), etc., all work fine. That's why I'm wondering if the issue could have been introduced in the changes to libgit2 somehow. What else would be causing different versions of Julia to behave differently here?

@tkelman
Copy link
Contributor

tkelman commented Oct 7, 2015

It's almost certainly libgit2. You could try the release-0.4 branch (or rc4 binaries) which would be closer to master but without using libgit2 for Pkg, but it would most likely be consistent with 0.3.x. @wildart do you know if there some debug env var or build option that could get libgit2 to be more chatty about what's going on?

@lkuper
Copy link
Author

lkuper commented Oct 7, 2015

As mentioned in #13399, I'm behind a firewall and I have

[url "https://"]
    insteadOf = git:https://

in my ~/.gitconfig, so I guess I'm suspicious that somehow Julia 0.3.11 is seeing my .gitconfig while Julia master is not.

@lkuper
Copy link
Author

lkuper commented Oct 7, 2015

@tkelman Okay, I'll see what happens with v0.4.0-rc4.

@lkuper
Copy link
Author

lkuper commented Oct 8, 2015

Confirming that Pkg.init() and Pkg.update() work fine on v0.4.0-rc4. So it seems like the problem is only on master.

@lkuper lkuper changed the title SSL_shutdown:uninitialized error with Pkg.init() on master Git connection timeout problems with libgit2 on master Oct 8, 2015
@wildart
Copy link
Member

wildart commented Oct 8, 2015

Ah, proxy. If libgit2 was build with libcurl support, then a standard proxy configuration should work

HTTP_PROXY=https://proxy.mycompany:80
$ git config --global http.proxy $HTTP_PROXY

@lkuper
Copy link
Author

lkuper commented Oct 8, 2015

@wildart Aha! I did not have libcurl. A message about this goes by while libgit2 builds:

-- checking for module 'libcurl'
--   package 'libcurl' not found

but I didn't realize it was a problem. Should libcurl be listed as a dependency in https://github.com/JuliaLang/julia#required-build-tools-and-external-libraries, at least with a note saying that users behind a firewall need it?

Unfortunately, on CentOS, after a seemingly successful yum install libcurl and make -C deps distclean-libgit2, I still see package 'libcurl' not found during the build. On Ubuntu, the same thing happens after apt-get install libcurl4-gnutls-dev.

@tkelman
Copy link
Contributor

tkelman commented Oct 8, 2015

You probably need libcurl-devel or whatever other package provides the curl.pc (or libcurl.pc?) pkg-config file for libgit2's build to find it. Documenting this would be good if it's necessary for proxying, and we may also want to do something about this in the generic linux binaries. Can you test https://status.julialang.org/download/linux-x86_64 in your environment?

@tkelman
Copy link
Contributor

tkelman commented Oct 8, 2015

aha - try commenting out

julia/Make.inc

Line 204 in fb4b161

export PKG_CONFIG_LIBDIR = $(JULIAHOME)/usr/lib/pkgconfig

edit: may need to revert #12590

@lkuper lkuper changed the title Git connection timeout problems with libgit2 on master libcurl problems with libgit2 on master Oct 8, 2015
@lkuper
Copy link
Author

lkuper commented Oct 8, 2015

I like how I'm apparently the first person in the world to try to use 0.5.0-dev behind a corporate firewall.

(Edit: sorry, that came out more harshly than intended! I'm merely reflecting on the absurdity of a situation that involves using bleeding-edge Julia, but also involves the word "corporate". :) )

@tkelman
Copy link
Contributor

tkelman commented Oct 8, 2015

Thanks for being the guinea pig! 0.4.0 is imminent (like, later tonight if my currently running pkgeval jobs look good) so I think most people interested in stability have been working from release-0.4. We also only merged #11196 last week, so the issues aren't taking all that long to discover.

@wildart
Copy link
Member

wildart commented Oct 8, 2015

@lkuper Appreciated

@felipenoris
Copy link
Contributor

Apparently this is why I couldn't compile Julia on windows on #13501.
I tried to compile Julia on a fresh ubuntu VM and I got this:

patching file CMakeLists.txt
Hunk #1 FAILED at 217.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rej
CMake Error at /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:136 (message):
  Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
  system variable OPENSSL_ROOT_DIR (missing: OPENSSL_LIBRARIES
  OPENSSL_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.0/Modules/FindPackageHandleStandardArgs.cmake:343 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.0/Modules/FindOpenSSL.cmake:328 (find_package_handle_standard_args)
  CMakeLists.txt:220 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!
See also "/home/felipenoris/Documents/julia/deps/build/libgit2/CMakeFiles/CMakeOutput.log".
Makefile:2036: recipe for target 'build/libgit2/Makefile' failed
make[1]: *** [build/libgit2/Makefile] Error 1
Makefile:78: recipe for target 'julia-deps' failed
make: *** [julia-deps] Error 2

This is a fresh Ubuntu 15 VM with this already applied:

sudo apt-get install git gfortran m4 cmake curl

Looking for libcurl I got this:

/$ sudo find . -iname '*libcurl*'
./var/lib/dpkg/info/libcurl3-gnutls:i386.postinst
./var/lib/dpkg/info/libcurl3:i386.list
./var/lib/dpkg/info/libcurl3-gnutls:i386.symbols
./var/lib/dpkg/info/libcurl3:i386.postrm
./var/lib/dpkg/info/libcurl3-gnutls:i386.postrm
./var/lib/dpkg/info/libcurl3:i386.postinst
./var/lib/dpkg/info/libcurl3-gnutls:i386.shlibs
./var/lib/dpkg/info/libcurl3:i386.md5sums
./var/lib/dpkg/info/libcurl4-openssl-dev:i386.list
./var/lib/dpkg/info/libcurl3:i386.symbols
./var/lib/dpkg/info/libcurl3:i386.shlibs
./var/lib/dpkg/info/libcurl3-gnutls:i386.md5sums
./var/lib/dpkg/info/libcurl4-openssl-dev:i386.md5sums
./var/lib/dpkg/info/libcurl3-gnutls:i386.list
./var/cache/apt/archives/libcurl3-gnutls_7.38.0-3ubuntu2.2_i386.deb
./var/cache/apt/archives/libcurl4-openssl-dev_7.38.0-3ubuntu2.2_i386.deb
./var/cache/apt/archives/libcurl3_7.38.0-3ubuntu2.2_i386.deb
./usr/share/aclocal/libcurl.m4
./usr/share/doc/libcurl3-gnutls
./usr/share/doc/libcurl3
./usr/share/doc/libcurl4-openssl-dev
./usr/share/lintian/overrides/libcurl3-gnutls
./usr/share/lintian/overrides/libcurl3
./usr/lib/i386-linux-gnu/libcurl.so.4.3.0
./usr/lib/i386-linux-gnu/libcurl-gnutls.so.4
./usr/lib/i386-linux-gnu/libcurl.so.4
./usr/lib/i386-linux-gnu/libcurl-gnutls.so.4.3.0
./usr/lib/i386-linux-gnu/libcurl.a
./usr/lib/i386-linux-gnu/pkgconfig/libcurl.pc
./usr/lib/i386-linux-gnu/libcurl.so
./usr/lib/i386-linux-gnu/libcurl-gnutls.so.3
./usr/lib/i386-linux-gnu/libcurl.so.3
./usr/lib/i386-linux-gnu/libcurl.la

@tkelman
Copy link
Contributor

tkelman commented Oct 13, 2015

@felipenoris that's a different issue #13389, you need to install libssl-dev

@samschlegel
Copy link

Just ran into this issue building on Scientific Linux 6 on a machine that's behind a proxy. As tkelman mentioned, the problem is due to the change in bb4eddc. Setting PKG_CONFIG_LIBDIR to only look at our libraries means that libgit2 won't find libcurl. Due to libgit2#2555 this means it will build without proxy support.

Commenting out the PKG_CONFIG_LIBDIR line from Make.inc does fix the issue, but I think the better solution is to set PKG_CONFIG_PATH instead as this will allow our libraries to take precedence, but won't disable inclusion of system libraries as a fallback.

@samschlegel
Copy link

Though that would need to be tested to see if it would introduce a regression with respect to #12514

@tkelman
Copy link
Contributor

tkelman commented Nov 10, 2015

Or we could make the setting mac only. I'm not sure what the proxy situation is like on mac, whether libgit2 needs libcurl there.

@kpamnany
Copy link
Contributor

I needed to revert #12590 on both CentOS 7 and OS X to get libgit2 to find libcurl to get Pkg working behind our firewall.

@JeffBezanson
Copy link
Sponsor Member

Bump. I also just needed to comment out the PKG_CONFIG_LIBDIR line.

@tkelman
Copy link
Contributor

tkelman commented Aug 3, 2016

They will be, but they aren't yet (at least not by default). This same licensing problem means the libgit2 packaged in debian doesn't even support https - #17661. mbedtls would be a path to fixing that, if we can get it upstreamed.

@ViralBShah
Copy link
Member

ViralBShah commented Aug 3, 2016

@mdcfrancis Having mbedtls used in Julia does not make Julia GPL. As you already know, this has been amply discussed elsewhere. Let's not restart this discussion here.

@mdcfrancis
Copy link

@ViralBShah yes should not have brought that up here - mebdtls is apache, so no issue.

@ViralBShah
Copy link
Member

@lkuper @mdcfrancis Would be great if you can try out the latest nightlies tomorrow, now that curl support is on master.

@mdcfrancis
Copy link

Will build and test tomorrow.

@mdcfrancis
Copy link

@ViralBShah I just tested against master and I can confirm that it works in my environment.


michael@shadow:~/src/julia5/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd$ ldd  libgit2.so
    linux-vdso.so.1 =>  (0x00007ffe9cf86000)
    libcurl.so.4 => /home/michael/src/julia5/usr/lib/libcurl.so.4 (0x00007f9470df0000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f9470bd7000)

libcurl apears to be linking the system tls library is that expected ?

michael@shadow:~/src/julia5/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd$ ldd  /home/michael/src/julia5/usr/lib/libcurl.so.4 
    linux-vdso.so.1 =>  (0x00007fff40193000)
    libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f726cd81000)
    librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007f726cb67000)
    libssl.so.1.0.0 => /home/michael/src/julia5/usr/lib/libssl.so.1.0.0 (0x00007f726c908000)
    libcrypto.so.1.0.0 => /home/michael/src/julia5/usr/lib/libcrypto.so.1.0.0 (0x00007f726c52c000)
    liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f726c31d000)
    libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f726c0cc000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f726beb3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f726baee000)
    libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f726b830000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f726b5b0000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f726b3ac000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f726b191000)
    libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f726af76000)
    libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f726ad38000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f726ab1a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f726d21c000)

We may want to re-open this issue till it is backported - the automatic issue closing based on commit message seems to have closed the issue.

@wildart
Copy link
Member

wildart commented Aug 8, 2016

@mdcfrancis How come your libgit2 build does not have any dependency on TLS library? libcrypto should be referenced.

@ViralBShah It looks like pkg-config picks system libraries for libcurl instead of mbedtls.

@mdcfrancis
Copy link

It looks like unbuntu is shipping gnutls
libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f726b830000)

@tkelman
Copy link
Contributor

tkelman commented Aug 8, 2016

Needs a bit more work on top of #17783 to actually make sure the right things are getting linked. Linking to gnutls is not what we want, we should be ensuring curl doesn't link to system libraries so our binaries are self-contained.

@mdcfrancis
Copy link

I truncated the ldd, here is the full one

michael@shadow:~/src/julia5/deps/build/libgit2-211e117a0590583a720c53172406f34186c543bd$ ldd  /home/michael/src/julia5/usr/lib/libcurl.so.4 
    linux-vdso.so.1 =>  (0x00007fff40193000)
    libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x00007f726cd81000)
    librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0 (0x00007f726cb67000)
    libssl.so.1.0.0 => /home/michael/src/julia5/usr/lib/libssl.so.1.0.0 (0x00007f726c908000)
    libcrypto.so.1.0.0 => /home/michael/src/julia5/usr/lib/libcrypto.so.1.0.0 (0x00007f726c52c000)
    liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f726c31d000)
    libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f726c0cc000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f726beb3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f726baee000)
    libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26 (0x00007f726b830000)
    libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11 (0x00007f726b5b0000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f726b3ac000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f726b191000)
    libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f726af76000)
    libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f726ad38000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f726ab1a000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f726d21c000)
    libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f726a906000)
    libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f726a6c4000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f726a4bf000)
    libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f726a2b6000)
    libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f726a02e000)
    libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f7269d8d000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f7269b89000)
    libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f7269956000)
    libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x00007f7269741000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f7269539000)
    libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x00007f7269310000)
    libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f7269102000)
    libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f7268eb9000)
    libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f7268c00000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f72689c7000)

@mdcfrancis
Copy link

This is great progress though, as now the proxy support and ssh for libgit2 are working with combined internal and external repositories.

@wildart
Copy link
Member

wildart commented Aug 8, 2016

Surely, we didn't what libcurl to link to openssl binaries copied by libgit2 build script

 libssl.so.1.0.0 => /home/michael/src/julia5/usr/lib/libssl.so.1.0.0 (0x00007f726c908000)
 libcrypto.so.1.0.0 => /home/michael/src/julia5/usr/lib/libcrypto.so.1.0.0 (0x00007f726c52c000)

@tkelman
Copy link
Contributor

tkelman commented Aug 8, 2016

I guess that's fine for now while we still have those, but our intent was to have it link against mbedtls for consistency across both osx and linux. Clearly we're not invoking curl's configure script in a specific enough way for it to do what we actually want it to do.

@ViralBShah
Copy link
Member

I find cmake a bit more difficult than autoconf personally, which is perhaps why this needs someone else to do all the right cmake incantations to pick the right libraries.

@tkelman
Copy link
Contributor

tkelman commented Aug 8, 2016

You used configure to build curl.

@ViralBShah
Copy link
Member

Ah then it was libgit2 that was using cmake to detect curl.

@lkuper
Copy link
Author

lkuper commented Aug 9, 2016

@ViralBShah I'm building master now and ought to be able to try it out tomorrow. Have to rebuild LLVM first. :)

@ViralBShah ViralBShah modified the milestones: 0.5.0, 0.5.x Aug 9, 2016
@lkuper
Copy link
Author

lkuper commented Aug 10, 2016

Just built master and can confirm that Pkg.init() works behind our firewall without my needing to manually change anything in Make.inc. Thanks to everyone for their hard work fixing this issue. 👍

@StefanKarpinski
Copy link
Sponsor Member

I second that – especially @wildart, @Keno and @tkelman for all the hard work.

@wildart
Copy link
Member

wildart commented Aug 10, 2016

Kudos to @ViralBShah as well.

@Ayush-iitkgp
Copy link

Ayush-iitkgp commented Sep 3, 2016

@lkuper Could you please guide me on how you got the latest changes working?
I uncommented the PKG_CONFIG_LIBDIR line in Make.inc
and ran make -C deps clean-libgit2 && make clean && make
and ended up screwing my working julia set up.

Edit- I think it was something related to permission issue. I got it fixed by switching to root.

@lkuper
Copy link
Author

lkuper commented Apr 19, 2017

BTW, is there any workaround for this issue on 0.5 if one is not building Julia from source?

@tkelman
Copy link
Contributor

tkelman commented Apr 19, 2017

Can you be more specific? What's the issue exactly?

@lkuper
Copy link
Author

lkuper commented Apr 19, 2017

@tkelman I installed Julia 0.5.1 on Ubuntu 16.04 via ppa:staticfloat/juliareleases. I ran sudo apt-get install libcurl3 and sudo apt-get install libcurl4-openssl-dev. I think I have all the correct proxy-related env vars and git proxy settings (HTTP_PROXY, git config --global http.proxy $HTTP_PROXY, and so on). When I try to install a package via Pkg.add, I get:

ERROR: GitError(Code:ERROR, Class:OS, Failed to connect to github.com: Connection timed out)
 in macro expansion at ./libgit2/error.jl:99 [inlined]
 in clone(::String, ::String, ::Base.LibGit2.CloneOptions) at ./libgit2/repository.jl:191
 in #clone#112(::String, ::Bool, ::Ptr{Void}, ::Nullable{Base.LibGit2.AbstractCredentials}, ::Function, ::String, ::String) at ./libgit2/libgit2.jl:327
 in (::Base.LibGit2.#kw##clone)(::Array{Any,1}, ::Base.LibGit2.#clone, ::String, ::String) at ./<missing>:0
 in (::Base.Pkg.Dir.##4#6{String,String})() at ./pkg/dir.jl:49
 in cd(::Base.Pkg.Dir.##4#6{String,String}, ::String) at ./file.jl:59
 in init(::String, ::String) at ./pkg/dir.jl:47
 in #cd#1(::Array{Any,1}, ::Function, ::Function, ::String, ::Vararg{Any,N}) at ./pkg/dir.jl:28
 in add(::String) at ./pkg/pkg.jl:100

The above fix involves modifying Make.inc and rebuilding Julia, so I'm wondering if there is a fix for a non-source install of Julia.

@tkelman
Copy link
Contributor

tkelman commented Apr 19, 2017

Don't use the ppa, that's not been recommended for a long time. Try with the generic linux binaries.

@lkuper
Copy link
Author

lkuper commented Apr 19, 2017

@tkelman Thanks for the heads up; that fixed it! I had no idea the PPA was no longer recommended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:packages Package management and loading libgit2 The libgit2 library or the LibGit2 stdlib module
Projects
None yet
Development

Successfully merging a pull request may close this issue.