Closed cboettig closed 10 years ago
yes, that's pretty strange -- at least on my machine, apt-cache
tells me that libgdal1-dev
depends on libgdal-dev
, so should pick up that dependency by default.
maybe my change was overzealous? if you add that dependency back, do things start working again? (i'll try and roll a patch to test, but that probably won't happen until tonight.)
@craigcitro Thanks for the reply; yeah, pretty weird. If I add the dependency for libgdal-dev explicitly, it just gets upset about another dependency log,
The following packages have unmet dependencies:
libgdal-dev : Depends: libhdf5-serial-dev
Doesn't make any sense to me. apt-get should resolve all the dependencies automatically unless they can't be satisfied, which clearly isn't the case. (I also tried explicitly using apt-get call instead of the ./travis-tool.sh
call in this attempt and I get the same error.)
@craigcitro I think I'm stumped, but would greatly appreciate any hints you have whenever you get around to it. Much appreciated!
well, it looks like we aren't the only folks hitting this; looks like the root cause is a nasty problem with dependencies on specific versions of packages. i'm gonna fork and play around for a few minutes, see what i find ...
ok, so i understand what's going on here. the issue is that netcdf-bin
wants libhdf5-1.8.4
, but gdal-bin
needs libhdf5-dev
. trying to force both of them to install at once confuses the bejeepers out of apt
, which makes sense. instead, i'm trying to split them up and do it in stages; i'm making progress, hopefully i'll send a PR shortly.
that said, i still have no idea what any of this code is actually doing -- if netcdf-bin
has any libraries you're using, they may get confused when someone's dropped a new version of the hdf5 headers in under their nose.
ahh, i love bugs like this: after quite a bit of fiddling, it turns out that the right fix was to undo part of my previous change. :)
i'm not 100% clear on the details, but it looks like when we pick up the extra apt repo in bootstrap
, we suddenly see some new-and-conflicting versions of some of the gdal
-related dependencies.
playing with installation order might work, but i realized that the smarter move was to just undo that: i moved most packages back before the bootstrap
call, and then everything works.
PR coming shortly.
(as a side note, it might be worth installing igraph
as a binary package, since it seems to eat a big chunk of the runtime.)
there are still some mysteries: for instance, why did this suddenly start failing a few days ago? my guess is that the PPA we get some packages from got updated around then, but i'm not sure.
Thanks for the PR and the explanations above. What distro/version is Travis using for Linux anyhow?
http://docs.travis-ci.com/user/ci-environment/
they're on ubuntu 12.04 (precise).
Travis is failing to build RNeXML now due to an error installing libgdal1-dev see travis log It used to install this just fine, so I'm not sure what has happened; perhaps @craigcitro has some insight?
@sckott points RNeXML's installation of this dependency is now different from that in taxize
https://github.com/ropensci/RNeXML/blob/master/.travis.yml#L8 compared to https://github.com/ropensci/taxize/blob/master/.travis.yml#L7
But since craig changed the one in RNeXML https://github.com/ropensci/RNeXML/commit/4fcd5f43af8f964b6d7ec278e2af25f97713b063 perhaps his change should be correct.