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

Travis-CI Mac OSX build failures #280

Closed
bsundahl opened this Issue Apr 19, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@bsundahl
Contributor

bsundahl commented Apr 19, 2018

The last three pull requests have all failed on the OSX build tests inside Travis-CI. I am looking through the build logs and all three are failing when running dep-$TRAVIS_OS_NAME.sh. More specifically, the build fails when trying to install the dependencies of TBB (the failing dependency is python@2.)

Can someone with more Travis-CI gumption please take a look at this? Possibly Ed?

@jeffhammond

This comment has been minimized.

Member

jeffhammond commented Apr 19, 2018

Switch to Python 3.

@evaleev

This comment has been minimized.

Contributor

evaleev commented Apr 20, 2018

fixed by 13839b4

@evaleev evaleev closed this Apr 20, 2018

evaleev added a commit that referenced this issue Apr 20, 2018

Merge branch 'master' into pullreq-02152017-ev1
* master:
  workaround travis homebrew issues on OS X ... see #280
  fixed failing conversion for low rank tensors
  Hung queue msg is now directed to std error
  WorldTaskQueue::fence prints error msg to stderr to match precedent
  ThreadPool will delete threads in destructor
  RmiTask: avoid leak of buffer
  generalized serialization of std::vector and std::map to accept containers parametrized by nonstandard allocator and comparer
  constness of future should not matter when unwrapping
  Future<T>* can be used as an argument to WorldTaskQueue::add. Useful scenario: I want to use local futures (that refer to either for purely local data or refer to remote data but are cached locally), I manage their lifetime, and want to avoid unnecessary copying
  constness of future should not matter when unwrapping
  Future<T>* can be used as an argument to WorldTaskQueue::add. Useful scenario: I want to use local futures (that refer to either for purely local data or refer to remote data but are cached locally), I manage their lifetime, and want to avoid unnecessary copying
  workaround for gcc "seeing" madness::operator<< for std::vector and other types defined in print.h, this affects the result of is_ostreammable ... resolves #272
  resolves #271

evaleev added a commit that referenced this issue Apr 20, 2018

Merge branch 'master' into pr-20180413-ev1
* master:
  workaround travis homebrew issues on OS X ... see #280
  small fix
  CIS works with localized orbitals| fixed problems with lda_only bib | updated SCFOperators to not confuse fence and tol anymore
  fixed failing conversion for low rank tensors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment