Fix ARM failures (gh-413) #2879
Conversation
|
(@certik: just to re-iterate what Ralf said in case you don't look at this closely -- he really does mean only that commit should be backported, the other commit that's included in this PR will break py24 compatibility. This is also why the Travis build failed.) Am I right that the basic assumption here is that our FP exception checking stuff just doesn't work reliably in general, and so we might as well knownfail the relevant tests whenever this comes up? That's fine if so, but do we have a bug filed anywhere saying this? Seems like something we'd want to figure out how to fix sooner or later and have a central place to accumulate any analysis in the mean time... Also @rgommers: If you're breaking the test suite on 2.4, can you remove it from .travis.yml as well, so the PR green/grey status remains useful? |
|
Oh yes: actual changes look good to me. |
Done because for 1.8 we're not supporting these Python versions anymore, and this PR break 2.4 compatibility.
|
OK, Travis build is fixed. |
|
Backported in #2883. |
|
@njsmith let me know if I did this right. I always create a PR for the backport, especially in cases like this, where that particular commit didn't have Travis tests attached to it, and the next commit had failures. All seems to be ok. |
@certik commit 9ff6aed should be backported to 1.7.x.