Maik Riechert

@khallock Looks great. The [setup](https://github.com/NCAR/wrf-python-wheels/pull/1) for uploading the wheels from [Travis CI](https://travis-ci.org/NCAR/wrf-python-wheels) to [Rackspace](https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/) is done. The last step is to add the encryption key for Appveyor. Can you add...

The wheel upload is working now. I updated the README at https://github.com/NCAR/wrf-python-wheels which should contain everything needed to create wheels and upload them to PyPI. The current [BUILD_COMMIT](https://github.com/NCAR/wrf-python-wheels/blob/master/BUILD_COMMIT) is set...

@matthew-brett What can I do to help you analyze the problem?

@matthew-brett I couldn't reproduce it locally yet, only on CI weirdly. Will investigate further. But if there's any verbose logging etc I can enable, let me know.

https://dev.azure.com/wrf-cmake/WRF/_build/results?buildId=428 See the failed macOS build and click on the "Delocate" step.

I [dumped out](https://dev.azure.com/WRF-CMake/WRF/_build/results?buildId=482&view=logs&jobId=571f6113-b177-504f-680c-6f7e5f53d965&taskId=d2662577-9dbc-5143-648b-0cd8f182b67e&lineStart=30&lineEnd=110&colStart=1&colEnd=31) `delocate-listdeps` in case it's helpful: ``` + delocate-listdeps --all --depending build/install/main /usr/lib/libSystem.B.dylib: build/install/main/ideal.exe build/install/main/ideal_fire.exe build/install/main/ideal_heldsuarez.exe build/install/main/ideal_scm_xy.exe build/install/main/ideal_tropical_cyclone.exe build/install/main/real.exe build/install/main/wrf.exe /usr/lib/libz.1.dylib: build/install/main/ideal.exe build/install/main/ideal_fire.exe build/install/main/ideal_heldsuarez.exe build/install/main/ideal_scm_xy.exe build/install/main/ideal_tropical_cyclone.exe build/install/main/real.exe build/install/main/wrf.exe...

OK, I found the issue. `libgfortran.5.dylib` was a direct dependency of the executables listed above, but also an indirect dependency via `libnetcdff.6.1.1.dylib` (which is *not* listed in `delocate-listdeps`). The catch...

I was able to solve the problem by calling the node-resolve plugin like so: ```js nodeResolve({ preferBuiltins: false }) ``` Without that I believe the resolution stopped too early before...

@TimothyClaeys Can you confirm this issue?

`d` is the private key part and without it you can't sign the message. The error message could be better.