From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: bug#30015: WebKitGTK nondeterministic build failures Date: Wed, 10 Jan 2018 00:49:30 -0500 Message-ID: <20180110054930.GC29749@jasmine.lan> References: <874lnzcedp.fsf@gmail.com> <20180106174358.GA28436@jasmine.lan> <87vageeobi.fsf@netris.org> <87incedvgv.fsf@netris.org> <87o9m5cqi4.fsf_-_@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eZ9I1-0005zM-Vu for bug-guix@gnu.org; Wed, 10 Jan 2018 00:51:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eZ9Hy-000489-Q0 for bug-guix@gnu.org; Wed, 10 Jan 2018 00:51:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:42306) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eZ9Hy-00047r-Iy for bug-guix@gnu.org; Wed, 10 Jan 2018 00:51:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eZ9Hy-0007wC-06 for bug-guix@gnu.org; Wed, 10 Jan 2018 00:51:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline In-Reply-To: <87o9m5cqi4.fsf_-_@netris.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Mark H Weaver Cc: 30015@debbugs.gnu.org --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlpVqWoACgkQJkb6MLrK fwjPQBAArmdcziOpU3Z1h8EtjNvH7KckgrsPPBsJOXLA78gYuxCFCyC3dXTZJQAC n1R/PqoTJobow247lLoI78qNHx8mkR+WNnCxGiX9BBLGPzVVpPiEK8s/1qS45YBV 8MjTpn0hByOrRnZwWcPhhOHwi6ts72l0l5NJPsUknOp+6kkfZq2OwdG41eJV5mbR gZzX37fP8rl/KCwvL96nsCd4H+7ns1PIvGC06Y5BO/cskOxiq3zpvSzmmkyKMeZl 0eTL11G99G6eKiGY+s42G1m2a8aJhvmHeL5/OUwHBv+SrHQSlBAXWzsFgUgebul5 XAbPtxcf1yHwlOoEFnOOrs/u+Aib5UnyMRcF5gNjNQpII2JZ6Q8MzAhw74gYM34Y oxgu/apPv9JTzGP4qtVIPdP9BTqoYVP12QRzwgRiI+p/fgFR1WH1kd6mX6xqQRUi 40RN1yFDBzHGb8kIOCA1+gQAbVtpbhcNNK/ieR1JkHQgiqNdP34eBsa6jSpcQEcp cELfm//DMxF9Zm779quHs0DmwR9CTtLhPVP+QR5QTtOJtMtjezD9pEL6I0Xdx/Kz eflLhTcT7ejJLq4ES3S4871GMsuGNjA2d2+opmJWfFtRHnkfgc2fMVEgjo9MIeXR l3aH5gj909hZDateVV8fW3ix17n/k0of57244+fYJp3wFwbi31Q= =OMMr -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ--