support for mosek 9 (local branch)

[bqpd]

local version of #1452

This is fantastic, thanks @rileyjmurray! Making a few small changes to pass tests locally & on some of our larger SP models. @1ozturkbe, it seems like it doesn't pass on SPaircraft at present, and fails on robust (as does mosek, though?).

[bqpd]

(nb that lint issues seem to have also arisen in pylint-dev/pylint#2436, and so might point at pylint on jenkins being out of date, but I just fixed them with a disable for now)

[1ozturkbe]

On reynolds you have

python: can't open file '/Users/jenkins/mosek/9.1/tools/platform/osx64x86/python/2/setup.py

because reynolds is a Linux machine, not osx. It should be

/home/jenkins/mosek/9.1/tools/platform/linux64x86/python/2/setup.py

Oops, I done messed up. Fixing...

[1ozturkbe]

test this please

[1ozturkbe]

Yay, two green checks. Just macys_VM left in dependencies. Any ideas @bqpd?

[1ozturkbe]

test models please

[galbramc]

I think this has something to do with it

error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool: changing install names or rpaths can't be redone for: /Users/jenkins/workspace/CE_gpkit_PR_dependencies/buildnode/macys_VM/numpyversion/1.13.3/pintversion/0.8.1/build_gpkit/expopt.so (for architecture x86_64) because larger updated load commands do not fit (the program must be relinked, and you may need to use -headerpad or -headerpad_max_install_names)

[bqpd]

@galbramc why only in dependencies though?

[bqpd]

also, Windows10 registered a KeyboardInterrupt???

[1ozturkbe]

These tests have absolutely stupefied me.

[bqpd]

updated the Dependencies script to match Unit more

[galbramc]

How are things going putting all the testing scripts in that separate repo? That should help make sure they are all consistent.

[bqpd]

test this please

[bqpd]

test this please

[galbramc]

patience. There are lots of things running right now. We only have so many computers.

[galbramc]

Oh I didn't see that you aborted a bunch of stuff.

[bqpd]

ahaha no worries! just confirming that even with a straight-up duplicate of the script that works on units it doesn't work on macy_vm dependencies

[bqpd]

ahaha no worries! just confirming that even with a straight-up duplicate of the script that works on units it doesn't work on macy_vm dependencies because the path to that executable is too long for the binary. taking mosek off of dependency checking for now.

[bqpd]

test this please

[bqpd]

test this please

[bqpd]

test this please

[bqpd]

test this please

[bqpd]

test models please

[pgkirsch]

@bqpd (cc @rileyjmurray @1ozturkbe) This PR seems to break the build pipeline for a linux-base-image docker container we use. I know your build testing includes a linux machine so I'm particularly surprised this is happening, but do you have any ideas why we might be seeing floating point exceptions? No issues building (locally) on OSX.

Found the following solvers: mosek, mosek_cli, cvxopt
#     Replacing directory env
..!!! uWSGI process 9 got Floating Point Exception !!!
*** backtrace of 9 ***
uwsgi(uwsgi_backtrace+0x35) [0x55c3f632d375]
uwsgi(uwsgi_fpe+0x23) [0x55c3f632d783]
/lib/x86_64-linux-gnu/libc.so.6(+0x33060) [0x7fe583bff060]
/root/mosek/8/tools/platform/linux64x86/bin/libmosek64.so(+0x7c12b8) [0x7fe567fba2b8]
*** end of backtrace ***
entrypoint.sh: line 9:     8 Floating point exception(core dumped) python hops-worker.py
entrypoint.sh: line 9:     9 Floating point exception(core dumped) uwsgi --ini wsgi.ini

Let me know what other information would be useful to better understand the issue.

[bqpd]

@pgkirsch This doesn't change the build script much at all, so I wonder if it has more to do with the docker re-build? Could you confirm it works on the commit prior to this PR's merging?

[rileyjmurray]

@pgkirsch @bqpd @1ozturkbe I'd recommend creating a separate GitHub issue for this build problem. You can reference the PR with a hashtag #1454 to explicitly link the issue.

[pgkirsch]

Yeah fair enough, good idea @rileyjmurray.