travis: Move the 8.4.1 builders to 8.4.2. #5286
Conversation
|
Feel free to merge once it's green. |
|
The remaining error is because of |
|
Just testing locally to make sure pre-8.4 versions are happy with the imports now. It'll still be red because of T3436, which is being poked at in #5288. If that's the only issue I can see then I'll go ahead and merge, but it'll be a little while before Travis runs, I think. |
|
You can try cherry-picking the patch from #5288 as well, then we can merge it all in one go. |
|
Wrong PR with the comment? RE cherrypicking: works either way. The bottleneck is Travis resources anyway, I think? |
|
And now a file I didn't even touch (and which doesn't import anything I did touch) has decided to start failing. I am quite confused about this one. |
|
Sorry, that was my fault. Fixed on |
|
Huh. I had no idea Travis would auto-rebase like that. No wonder I couldn't figure out what had changed in the PR to cause it! |
This ought to fix the build matrix. I believe the issue is GHC trac 5129, where evaluate is being miscompiled: in cabal-testsuite's Test.Cabal.Server, in the function readUntilEnd, the 'read' function is protected by an 'if' to ensure that it doesn't result in the dreaded 'no parse'. However, some sophisticated putStrLn debugging has revealed that it is being called in *both* branches, not just the safe one; this is the worst sort of heisenbug because it vanished when I put a putStrLn before the evaluate! Since the evaluate function is fixed in 8.4.2 and bumping to 8.4.2 has a patch for trac 5129, this is as fixed as it can get.
quasicomputational
force-pushed
the
fix-8.4-travis
branch
from
1b7344c to
bf07ffc
Compare
|
Anyone got any idea what's up with the OSX downstream builder? Is that a known flaky test, or did something really subtle break? |
No, I don't remember it failing before, may be a new regression. |
|
I re-triggered it and it went away, so I am going to blame some Travis weirdness and go ahead and merge. The notorious T3436 is still failing, but that's being worked on and this PR is making the situation strictly less broken. |
This ought to fix the build matrix. I believe the issue is GHC trac
5129, where evaluate is being miscompiled: in cabal-testsuite's
Test.Cabal.Server, in the function readUntilEnd, the 'read' function
is protected by an 'if' to ensure that it doesn't result in the
dreaded 'no parse'. However, some sophisticated putStrLn
debugging has revealed that it is being called in both branches, not
just the safe one; this is the worst sort of heisenbug because it
vanished when I put a putStrLn before the evaluate!
Since the evaluate function is fixed in 8.4.2 and bumping to 8.4.2
has a patch for trac 5129, this is as fixed as it can get.
Please include the following checklist in your PR:
[ci skip]is used to avoid triggering the build bots.Please also shortly describe how you tested your change. Bonus points for added tests!
Tested locally, found it failed on 8.4.1 and succeeded on 8.4.2.