<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif;font-size:large">Currently the priority of #4012 is normal, shouldn't it be at least high? Also the milestone is 7.12.1, should it be 7.10.2?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 10, 2015 at 3:39 PM, Mateusz Kowalczyk <span dir="ltr"><<a href="mailto:fuuzetsu@fuuzetsu.co.uk" target="_blank">fuuzetsu@fuuzetsu.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I'd like to bring some attention to ticket #4012 about non-determinism.<br>
As many of you may know, the nix package manager distributes binaries<br>
throughout its binary caches. The binaries are shared as long as the<br>
hash of some of their inputs matches: this means that we can end up with<br>
two of the same hashes of inputs but thanks to #4012 means that the<br>
actual contents can differ. You end up with machines with some packages<br>
built locally and some elsewhere and due to non-determinism, the GHC<br>
package IDs don't line up and everything is broken.<br>
<br>
The situation was pretty bad in 7.8.4 in presence of parallel builds so<br>
we switched those off. Joachim's<br>
a477e8118137b7483d0a7680c1fd337a007a023b helped a great deal there and<br>
we were hopeful for 7.10. Now that 7.10.1 is out and people have been<br>
using and testing it, the situation turns out to be really bad: daily we<br>
get multiple reports from people about their packages ending up broken<br>
and our only advice is to do what we did back in 7.8 days which is to<br>
purge GHC and rebuild everything locally or fetch everything from a<br>
machine that already built it all, as long as the two don't mix. This is<br>
not really acceptable.<br>
<br>
See comment 76 on #4012 for an example of a rather simple file you can<br>
compile right now with nothing extra but -O and get different interface<br>
hash.<br>
<br>
This e-mail is just to raise awareness that there is a serious problem.<br>
If people are thinking about cutting 7.10.2 or whatever, I would<br>
consider part of this ticket to be a blocker as it makes using GHC<br>
reliably while benefitting from binary caches pretty much impossible.<br>
<br>
Of course there's the ‘why don't you fix it yourself’ question. I<br>
certainly plan to but do not have time for a couple more weeks to do so.<br>
For all I know right now, the fix to comment 76 might be easy and<br>
someone looking for something to hack on might have the time to get to<br>
it before I do.<br>
<br>
Thanks<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mateusz K.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</font></span></blockquote></div><br></div>