Skip to content
This repository was archived by the owner on Aug 30, 2024. It is now read-only.

set MB_PYTHON_OSX_VER=10.9 #58

Closed
wants to merge 1 commit into from
Closed

set MB_PYTHON_OSX_VER=10.9 #58

wants to merge 1 commit into from

Conversation

mattip
Copy link
Contributor

@mattip mattip commented Aug 22, 2019

Fixes #43

need to check that the artifact name in fact does not contain macosx_10_6_intel

@mattip mattip mentioned this pull request Aug 24, 2019
Closed
@mattip
Copy link
Contributor Author

mattip commented Aug 24, 2019

Anyone understand what is wrong with the macOS CI run ?

@charris
Copy link
Contributor

charris commented Aug 24, 2019

@matti MacPython/numpy-wheels appveyor pipeline is completely stuffed up and stalled with junk builds. I don't have the permission to cancel, but it looks like you do. Could you clean it up? And do your work in a branch.

@mattip
Copy link
Contributor Author

mattip commented Aug 24, 2019

@charris I do not see how to cancel those. Maybe @matthew-brett can? The work is on a branch, I guess I should remove the appveyor/travis builds from #60 until it is ready to build

@matti
Copy link

matti commented Aug 24, 2019

@charris please ping @mattip who has also awesome github name

@charris
Copy link
Contributor

charris commented Aug 24, 2019

@mattip Guess we will need to wait on @matthew-brett. Guess this is one more reason to move things to the NumPy project and implement azure-pipelines :)

@charris
Copy link
Contributor

charris commented Aug 24, 2019

We should also ask Matthew to add us to the numpy-wheels account on appveyor.

@charris
Copy link
Contributor

charris commented Aug 24, 2019 •
edited
Loading

OK, this looks fixed, but I think it required this change to config.sh in order to build with the latest multibuild.

diff --git a/config.sh b/config.sh
index 645008b..0329262 100644
--- a/config.sh
+++ b/config.sh
@@ -15,7 +15,14 @@ function build_wheel {
 
 function build_libs {
     local plat=${1:-$PLAT}
-    local tar_path=$(abspath $(get_gf_lib "openblas-${OPENBLAS_VERSION}" "$plat"))
+    # Force 64-bit OpenBLAS library for macOS intel (dual arch)
+    # builds. For these builds, we pretend to be dual arch, but in
+    # fact we're only using the 64-bit build of OpenBLAS
+    if [ -n $IS_OSX ] && [ $plat == intel ]; then
+        plat=x86_64
+    fi
+    local tar_fname=$(get_gf_lib "openblas-${OPENBLAS_VERSION}" "$plat")
+    local tar_path=$(abspath $tar_fname)
     # Sudo needed for macOS
     local use_sudo=""
     [ -n "$IS_OSX" ] && use_sudo="sudo"

@matthew-brett I thought that was a temporary workaround?

@charris
Copy link
Contributor

charris commented Aug 24, 2019

Still broken. I think it is due to requiring xcode 6.4 and picked up from the environment.

@charris
Copy link
Contributor

charris commented Aug 24, 2019

try close.

@charris charris closed this Aug 24, 2019
@charris
Copy link
Contributor

charris commented Aug 25, 2019

@mattip I notice that the release was built on my own appveyor account but can't be uploaded without a Rackspace API key.

            # This is for Rackspace uploads.  Contact Matthew Brett, or the
            # scikit-learn team, for # permission (and the API key) to upload to
            # the Rackspace account used here, or use your own account.

So if @matthew-brett doesn't show up soon and we can't get the stalled process canceled in some other way, we might want to look into getting the API key from someone else or uploading to a different repository. I guess using a different repo would require hand downloading, although I'd have to check the downloader to be sure.

@charris
Copy link
Contributor

charris commented Aug 25, 2019 •
edited
Loading

Hmm, we have the key, so the trick is to figure out why some pushes trigger uploads while others don't.

EDIT: I'm guessing it is something in the appveyor settings.

@mattip
Copy link
Contributor Author

mattip commented Aug 25, 2019

This build has been going for 76 hours. I think it is what is holding up the pipeline.

@charris
Copy link
Contributor

charris commented Aug 25, 2019

Maybe try deleting the azure app?

@charris
Copy link
Contributor

charris commented Aug 25, 2019

This build has been going for 76 hours.

I noticed :) However, I'm trying to figure out how to get my personal appveyor account to upload the result, it builds and tests...

@charris
Copy link
Contributor

charris commented Aug 25, 2019

@mattip Mind if I delete the azure app?

@charris
Copy link
Contributor

charris commented Aug 25, 2019

Hmm, there is no delete button for azure, maybe I don't have permissions. Can you take a look?

@charris
Copy link
Contributor

charris commented Aug 25, 2019

Could be that the azure app configuration was never finished.

@charris
Copy link
Contributor

charris commented Aug 25, 2019

What is the azure account? Who has permissions?

@mattip
Copy link
Contributor Author

mattip commented Aug 25, 2019

I connected this repo to azure using this page. Can you see it?

@charris
Copy link
Contributor

charris commented Aug 25, 2019 •
edited
Loading

@mattip If you look at the numpy one, it has a remove button and the numpy-wheels one doesn't. I removed and added the numpy azure app several times during the spin up, so it may be a permissions thing, I notice that our permissions for numpy-wheels are just for a couple of repos, while the azure app potentially covers all of MacPython, so there is that. IIRC, one of the owners (me) needed to install it on numpy.

I'm now curious about where the pipeline is on azure and if you have access to it. For appveyor I think Matthew would need to add us to his project. If Matthew doesn't respond soon, we may be able to contact the appveyor admins and get it shut down, although since we don't have permissions on the account that may be difficult. ISTR doing that many years ago for NumPy.

Another curiosity is that there are three different appveyor hooks, and all of them seem active. Not sure what that is about, maybe different triggers/post test environments. But without the appropriate permissions on the appveyor account I cannot tell much about how they are set up.

@charris
Copy link
Contributor

charris commented Aug 25, 2019

I think this does indicate that we would be better off if the wheels builds were transferred to NumPy.

@charris
Copy link
Contributor

charris commented Aug 25, 2019

Note that because the azure app in numpy already covers all the repos, we probably just need to add a pipeline on the azure end. So that much should be easy.

@matthew-brett
Copy link
Contributor

matthew-brett commented Aug 26, 2019 via email

@mattip
Copy link
Contributor Author

mattip commented Aug 26, 2019

@matthew-brett Can you kill appveyor CI runs? This one seems hung for quite a while. Assuming you can, is there any way to share that super power so others can also cancel jobs?

@matthew-brett
Copy link
Contributor

matthew-brett commented Aug 26, 2019 via email

@charris
Copy link
Contributor

charris commented Aug 26, 2019 •
edited
Loading

Maybe it would be better to set up a Numpy appveyor thing with team permissions?

NumPy was running tests on my appveyor account, we were unable to set up a project account at the time, but maybe that is possible these days. IIRC, I could add others to my account.

@charris
Copy link
Contributor

charris commented Aug 26, 2019

@matthew What should the Mac wheel names look like? I want to check before uploading PyPI. Currently they look like

numpy-1.17.1-cp37-cp37m-macosx_10_6_intel.whl

@matthew-brett
Copy link
Contributor

matthew-brett commented Aug 26, 2019 via email

@charris
Copy link
Contributor

charris commented Aug 26, 2019 •
edited
Loading

I think it actually is 10_6 due to

# Force xcode 6.4 image to work round
# https://github.com/python-pillow/pillow-wheels/issues/45
osx_image: xcode6.4

@mattip had a PR to change that, but I don't know if it worked.

@matthew-brett
Copy link
Contributor

matthew-brett commented Aug 26, 2019 via email

@charris
Copy link
Contributor

charris commented Aug 26, 2019

Hmm, OK. Seems to come from

multibuild/osx_utils.sh:MACPYTHON_DEFAULT_OSX="10.6"

So we need to define MB_PYTHON_OSX_VER=10.9 like this PR does. ISTR doing that before for the intel problem and it worked. Pushed that change to master and will check the result in the pre wheels.

@charris
Copy link
Contributor

charris commented Aug 26, 2019

Update, xcode 10.1 is not available for 10_6 and Python3.5 pkg is not available for 10_9 :) Fixable, but since we are dropping Python 3.5 for 1.18, I figured to just go ahead and remove those builds from master. We can replace them later when Python 3.8 is available. Renaming the existing 1.17.1 wheels may be the easiest way to go for the release.

@mattip
Copy link
Contributor Author

mattip commented Oct 8, 2019

@charris are we ready to retry this? It would be nice to get the correct wheel names

@charris
Copy link
Contributor

charris commented Oct 8, 2019

It is already done. 10_6 for 1.17.2 and 10_9 for 1.18.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

macOS wheel naming incorrectly includes 10.6
4 participants
@mattip @charris @matti @matthew-brett