Release 0.3.0 #44
Release 0.3.0 #44
Conversation
|
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
|
Looks like the CIs need some massaging here. CircleCI is complaining about the build being too quiet. There is a Travis CI is complaining about the build being too noisy. Most of the warnings are about Surprisingly AppVeyor seems content even after dropping ~10 patches, which is amazing. Good work everyone that has been involved on the Windows build. |
No, travis-ci is also failing because of timeouts. New openblas versions has fewer warnings and hence no output. |
|
Yep. You’re right. I misread. |
|
Looks like adding logging information caused Travis CI to go over. 😩 Fortunately CircleCI seemed to work with this change. 🎉 Given this, am just switching the macOS builder to CircleCI. Not going to mess around with Travis CI's constraints on this one again. Doing this once when adding this recipe was enough for me. |
jakirkham
force-pushed
the
release_0.3.0
branch
3 times, most recently
from
c3dd881 to
4483f30
Compare
Sadly the CIs are being temperamental and refuse to build something that is too quiet. As a result the OpenBLAS `make` step is being terminated prematurely. To workaround this issue, try increasing the verbosity of the `make` step. It is worth noting that this has gone over the CI log length limits historically. So this may not work either. However it's simple and worth trying. If it works, we will have better log information from the OpenBLAS build, which is a good thing.
As we already drop Windows 32-bit, there is no need to skip it specifically. So drop this redundant `skip`.
As we are running into tedious issues with Travis CI (log length limit, quiet builds, etc.), switch to using CircleCI where these problem don't seem to be blocking Linux. Hopefully this will extend to their macOS builds as well.
Now that we have configured macOS builds to occur on CircleCI, re-render so that the CI configuration files are updated accordingly.
Use the `compiler` syntax, split `build` and `host`, simplify Windows `vc` stuff, drop hacky `perl` pin, etc.
After revamping the recipe, re-render to update pinnings and compiler usage.
Builds on macOS will try to look for the `libgfortran` library during the build. However as our compiler doesn't place that in the host environment, macOS builds won't find it. This is demonstrated in the linked log below. To fix this issue, just require `libgfortran-ng` be installed in the host environment so that it can be linked to. Admittedly this is a bit kludgy (though matches what we did previously); however, this is something we have dealt with before when compiling on macOS. Linux can escape this problem as we provide `libgfortran` on the Docker container. However to ensure it uses our `libgfortran`, go ahead and include it there as well. This is what we did for Linux before. So it is not too weird that we need to do it again. ref: https://circleci.com/gh/conda-forge/openblas-feedstock/130
|
Would note there is a |
|
Thoughts @conda-forge/openblas? |
|
+1, what's the plan to update all the packages that link to openblas now, old school or conda 3 ? |
|
Move to |
|
Other thoughts? |
|
Ping? |
| host: | ||
| - libflang # [win] | ||
| - libgfortran-ng >=3.0 # [osx] | ||
| - libgfortran-ng >=4.9 # [linux] |
There was a problem hiding this comment.
Can you remove the two lines above?
There was a problem hiding this comment.
It failed to build without these being present.
There was a problem hiding this comment.
Here's one.
ref: https://circleci.com/gh/conda-forge/openblas-feedstock/130
|
Anything else? |
|
Thanks all :) |
Builds the very recent (and long awaited) release of OpenBLAS, 0.3.0. Likely still needs work, but putting it up to get that work and discussion started.