-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
RFC: Bump OpenBLAS to v0.2.13 #9277
Conversation
should fix #9084, and gets rid of a patch that was upstreamed
currently the only values that will make much sense are "64_" or "" due to arpack and suitesparse
This multiple-status thing is the coolest thing ever. |
Love the multiple status! |
Can we get a different status line for linux and mac from travis? |
Probably not before Travis decides to support that option. |
Yes, I think Github did a really good job with this feature - https://github.com/blog/1935-see-results-from-all-pull-request-status-checks I disabled the webhook for the temporary version that we had been using. Annoyingly appveyor seems to be timing out especially frequently over the last few days. Some of the failures could possibly be mitigated by running the tests in serial for win64, trade off longer test running time for better reliability. But some runs are getting "broken pipe" errors, and others appear to just freeze for no reason as if the appveyor worker has died. Regarding splitting out the Travis matrix into different status items, that would have to be done on Travis' side. If you can find where the Travis builder interacts with the Github API, they'd probably entertain a PR to implement an option for separate statuses per entry in the build matrix. |
Since we're paying for AppVeyor, I would expect better service than this. Perhaps I should contact them? |
Sure, maybe Feodor could look into some of the failed builds that weren't the fault of Julia. Let me skim through the list of recent failed builds to classify them. |
I assume that bumping openblas here is ok. Perhaps we need a separate issue for Appveyor. |
Yeah I think it should be fine. If anything breaks with linking arpack or suitesparse with MKL, let me know. The lines I had here regarding MKL were actually redundant since MKL is always considered Now you should also be able to explicitly disable symbol renaming if you know you don't want it by setting |
That is handy. Thanks. |
should fix #9084 and a few freebsd build issues found by @nolta, and gets rid of a patch that was upstreamed