On Sun, Jan 07, 2018 at 04:23:31PM -0500, Mark H Weaver wrote:
> My best guess is that it's caused by the fact that
> our 'patch-and-repack' mechanism, which generates the patched tarball,
> resets all the timestamps to 0, whereas previously we built the upstream
> tarball directly with non-zero timestamps.
> 
> I guess that the build system contains a race condition that is much
> more likely to occur when the timestamps are 0.  It did happen once in
> December 2015 on i686, but the other three failures happened today.

It seems the builds eventually succeeded on x86_64 and i686.

It's a hacky workaround but, if we still need to patch the source the
next time we build WebKitGTK+, we could apply the patch in a build phase
after unpacking the WebKitGTK+ source. That should preserve most of the
source timestamps.

This idea assumes that the handful of changed timestamps would not also
expose the race.