This is a second attempt to extend the travis timeout time.

Self merging again.

That didn't work either, but at least it didn't screw things up :)

That didn't work either, but at least it didn't screw things up :)

:), thanks for looking into this, Travis was sending a bit many failure mails lately.

This might be a problem with hitting some internal travis CI limits. Scipy is using cirrus ci for linux aarch64 macos arm64, and musl. The config file is here, and the CI runs are here.

Pinging @andyfaff and @rgommers since it seems they did most of the work to move the scipy builds. We might want to hit the mailing list if we decide to go for this so there is some record of why we are adding a new CI provider...

It's fairly straightforward to use cirrus-ci for CI for all those targets. The config files are a little different to other CI, in that the .cirrus.star is a starlark script that creates jobs from other yml files. I found it pretty powerful and responsive. More than happy to help any transfer.

(I don't think it'll cover s390, ppc64le, etc without cross-compiling or qemu)

I agree Cirrus CI has been very nice.

(I don't think it'll cover s390, ppc64le, etc without cross-compiling or qemu)

If we want to keep those, then I don't think there's a need to move right now - we're basically stuck with TravisCI.

Scipy is using cirrus ci

Moving to cirrus looks like the way to go.

Note that I am going to remove Python 3.8 from NumPy 1.25, so this won't matter anymore after 1.24 is branched. But I suspect that what happened is that we were on the edge for all the test runs, and some small change pushed us over. If we cannot build 3.8 wheels for aarch64, that is how it is :) I'd still like to move to cirrus.