Bump libgit2 to 0.22.2 #10840
Bump libgit2 to 0.22.2 #10840
Conversation
|
Damn, didn't work. @staticfloat what's wrong with libcrypto? http:https://buildbot.e.ip.saba.us:8010/builders/package_tarball64 |
|
Note the failures there have meant we haven't gotten new 64-bit generic Linux nightlies since April 5th. If anyone has some time to fire up a Docker container or VM of Centos 5 and can reproduce this libgit2 build failure then we should file an issue with libgit2, and may want to disable the libgit2 build until we get it resolved. |
|
@tkelman am I correct in understanding that libgit2 is cached? In the old (successful) logs, the only mention of libgit is copying |
|
I don't get what that touch accomplishes. If removing it fixes the buildbots I'd be absolutely fine with that, but I'm not sure how safe it would be from being put back by @vtjnash... |
|
It might be that libgit2 is subtly broken when using destdir? |
|
the issue is that I unsuccessfully attempted to comment out this line: 8fc5b4e#diff-3ba529ae517f6b57803af0502f52a40bR1854 and so it accidentally tries to build/install libgit2 there. i wasn't really intending to change the behavior of anything in that commit (which is why I added it as a comment in the first place) |
|
hopefully that will help? |
|
what? makefiles are (can be) so damn confusing... it might've helped if you hadn't simultaneously pushed 1890e57 which fails tests, since binaries don't get built at all unless tests are clean |
|
0049487 makes sense, from how the logfiles flow that was almost certainly the problem. |
|
can someone explain that? was the make-install definition being expanded even inside the comment? |
|
because of the indentation, the comment was in bash, not gmake, resulting in only the first line of the expansion being commented out. the double |
|
gah, that is not at all obvious. Looks like we're in good shape now http:https://buildbot.e.ip.saba.us:8010/builders/package_tarball64/builds/570, thanks |
|
Can we disable the libgit2 build? We have it building fine now, so we could enable it by default when we actually use it. It seems quite wasteful to compile it otherwise, and stay with the various version upgrades. |
|
OMG, no, the whole point of building it was so that we can get the build working everywhere. Has that happened yet? I really don't think that building libgit2 is taking all that long, especially compared to beasts like LLVM, OpenBLAS and FFTW. |
|
I personally think we should disable the build after we branch for release-0.4 (I don't think rewriting the package manager will ever qualify as backport-worthy), but leave it enabled on master. The build does work almost everywhere, except for some things we aren't doing right with cmake cross-compilation that only influences people who try to build 32 bit Julia from 64 bit Linux with multilib compilers. It does waste a minute or two on Travis since we haven't picked some up-to-date PPA to use binaries from (or copied things over into julia-deps, but notice Elliot's been really busy lately), but we can fix that without too much trouble. Will just depend which minimum libgit2 version requirement we actually need to set once someone starts trying to reimplement Pkg using it. |
|
It takes a lot of time to build on ARM, for example. It seems to me that this can easily be a non-default setting until we actually use it. Folks who are working on integrating it can get it building everywhere by building it in |
|
Find a PPA for it that builds on arm then? The point was to get it into the build system, with the hope that would make it easier to start working on and gradually add functionality and tests while building and testing it everywhere. Only the first part has happened, but I think we should keep it this way on master. I'd rather not put up any barriers here - all it needs is someone to step up and start working on it. |
|
I am not suggesting removing the libgit2 build machinery - just not have it build by default when building julia. That way, when someone starts working on it, they just have to enable the build. That would be a one line change, and would in no way be a barrier to anyone working on libgit2. |
|
Sure, but as soon as someone starts working on it, I think re-enabling it should be immediately committed to master so the in-progress work can be widely tested right away. It's a one-line change to turn it off on arm - while true there are more people testing on arm than working on libgit2 right now, the arm work inherently can't be tested elsewhere vs the libgit2 work will need to be. |
|
The arm thing just brought up this point for me. I just prefer not building stuff that we are not using. I agree that the moment someone starts on libgit2, we should enable it again right away. |
Like rmath? I think we're in agreement here, I'd just prefer to do this after branching release-0.4 instead of now on master. |
|
Rmath is not a fair comparison, because it is actually used by people using Distributions.jl. Doing it after branching release-0.4 seems reasonable. Moving Rmath out of master right after that branch is also something we should do at that time. |
|
I just tried to build |
|
Why don't we just disable libgit2 in Make.arm then... On Thu, Apr 23, 2015 at 6:22 PM, Elliot Saba [email protected]
|
buildbots are apparently having trouble with openssl or something... http:https://buildbot.e.ip.saba.us:8010/builders/package_tarball64/builds/560/steps/make/logs/stdio
hoping this fixes it