OK, this was an easy way to add an ARM build! At just over 16 minutes, the run is substantially faster than the custom pip installs in #9407.
Happily(?), I see at least some of the same errors as found by @aarchiba in #9661; will see if I can fix them.

Yay, with the fixes to time, this passes on arm! Rebasing to get all travis runs included.

Moved the milestone since at least the test fixes for time should be included in 4.0 to help address the failures on arm64 that @aarchiba and @olebole were seeing (NOTE: the stats failure still needs addressing; would need testing with scipy??)

@mhvk - Do we need the full test suite run for both new jobs? I wonder whether they could also be merged with one of the other jobs, e.g to test an older version of numpy in addition to arm/bigendian?

(also, the conda-forge arm packaging is well under the way, and hopefully they'll sort out the installer problems, so we can just plug that into the existing infrastructure rather than installing everything manually)

So, I would suggest to keep the bug fixes here and factor out the travis changes in a separate PR that is not v4.0 critical. In fact I'm a bit worried about future headache that may come from the addition to conda/pip now we're introducing debian packaged python packages into our testing.

@bsipocz - It wasn't quite clear which job to use, but I'll look again (I had thought that we would just do this as a cron job, but here used a regular one to be sure it actually passed).

Anyway, I agree with moving out the fixes - we can then discuss the travis setup more at our leasure.

Looks like the fixes have been moved to #9672

Since the fixes are moved, this doesn't need 4.0 milestone anymore?

Yes, fixes moved, and remilestoned.

@mhvk - could you try to rebase? I think it would be nice to see how long would it take now to run these new jobs, or maybe even experiment with the new conda-forge arm packages (though I expect pip might be still quicker).

Yes, I'll try rebasing. In the meantime, moving the milestone to 4.1, since there is no real hurry.

I'll cherry-pick this to #10059. I feel putting the logic in based on the architecture is cleaner than here with the tox variables, but it can be done in a follow-up for master, too.

Thanks @mhvk!

oh, and that now there are conda-forge arm builds, we can think about whether to use those or stay with apt installs.

My personal preferences would be to stick with pip, if not possible with conda, and only if we really must do apt installs of python packages.

@mhvk - it seems I wasn't careful enough. While the the s390 build was of normal speed (~8mins), the installs for this ARM one takes forever. Do you have suggestions how to speed it up?

@bsipocz - I think we should put this in cron too, so that the long duration doesn't matter so much (I had in fact planned to do that, but didn't get around to it yesterday).
Also agree that we should do it either based on architecture or based on a flag rather than TOXENV being empty. I'll try to make a clean-up PR later today.
Using one of them for pure pip might make sense, though really tox effectively does that already. apt is, I think, most useful for arm64 as it installs most directly.