Use the certifi CA certs bundle

[njsmith]

Fixes: #53

[ogrisel]

Weird: this script seems to be missing from the PR. travis is green but apparently it did not reach this part of the build script, it exited after 26min (instead of more than 30min usually) with:

Broadcast message from root@testing-gce-c03d1c2f-f8aa-4f73-8fd1-b3b312ac2218
    (unknown) at 1:24 ...
The system is going down for power off NOW!

https://travis-ci.org/pypa/manylinux/builds/124631630#L3928

It's probably a preemptible VM on GCE but I think it's a failure in travis not to report this as a failure.

[ogrisel]

The shutdown without restart is a bug in travis-ci/travis-ci#4924.

[ogrisel]

I will restart the build manually to check that ssl-check.py is indeed missing.

[ogrisel]

A similar shutdown happened again!

[ogrisel]

Ok I got travis to fail as expected by restarting it twice:

+ ln -s /opt/_internal/cpython-3.5.1 /opt/python/cp35-cp35m
+ rm -f Python-3.5.1.tgz
+ rm get-pip.py
+ rm -rf /usr/local/ssl
+ /pip install certifi
build_scripts/build.sh: line 62: /pip: No such file or directory
The command '/bin/sh -c bash build_scripts/build.sh && rm -r build_scripts' returned a non-zero code: 1

[njsmith]

hopefully fixed both those issues, let's see what travis says

[ogrisel]

There is an import error in the ssl check python script.

[njsmith]

Well... it seems to be working now, but travis timed out :-/

[njsmith]

It looks like our last build on master took 45min 45sec, and the limit is 50min, so I don't think this is a new issue with this PR in particular, it's just that adding all those different SOABI variants has pushed us up to the limit of Travis.

I just restarted the build to see what happens, but I guess we urgently have to either split up our build (presumably into one job that builds the x86-64 image and one that builds that i686 image), or else move to a different build service.

I like the property of our current setup that we don't deploy either build unless both have passed... but given that we check that all PRs pass before merging, it probably is okay in practice (since all builds on master should be succeeding). Or alternatively we could switch to something like wercker that has support for more complex pipelines.

[ogrisel]

I like the property of our current setup that we don't deploy either build unless both have passed... but given that we check that all PRs pass before merging, it probably is okay in practice (since all builds on master should be succeeding)

+1. I think this is enough as we should not merge PRs as long as they are red.