From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: 01/04: gnu: mesa: Disable imx driver for armhf-linux. Date: Sat, 14 Oct 2017 13:51:09 -0400 Message-ID: <20171014175109.GA21518@jasmine.lan> References: <20171012173828.26257.23460@vcs0.savannah.gnu.org> <20171012173830.72AE320339@vcs0.savannah.gnu.org> <87tvz36elv.fsf@netris.org> <87r2u76qnr.fsf@fastmail.com> <87po9rhtpd.fsf@netris.org> <87y3oeh8cq.fsf@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e3Qaj-0006MD-RK for guix-devel@gnu.org; Sat, 14 Oct 2017 13:51:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e3Qaf-00029b-Tz for guix-devel@gnu.org; Sat, 14 Oct 2017 13:51:17 -0400 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:35031) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1e3Qaf-00029R-OL for guix-devel@gnu.org; Sat, 14 Oct 2017 13:51:13 -0400 Content-Disposition: inline In-Reply-To: <87y3oeh8cq.fsf@netris.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Oct 13, 2017 at 08:38:13PM -0400, Mark H Weaver wrote: > Do you think it should be acceptable to merge a major branch into > 'master' where *all* graphical packages are broken on armhf? I think we all agree that we should not do this. As somebody who also works on merging these branches, I'd like to point out that the continuous integration process for armhf is difficult to use effectively. The core of the problem is that the feedback loop for armhf is unreliable and slow. Similar problems exist with Hydra for x86_64 and i686, but they are mitigated because most of us have access to our own x86_64 machines where we can test changes quickly before asking Hydra to verify a positive result. It would be great to have access to an armhf machine where we could do the same thing, testing changes directly without going through Hydra. Maybe if one has a fast enough x86_64 computer, they could virtualize an armhf test machine. --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAlniTokACgkQJkb6MLrK fwg8Ag/+JIKGJGNbFrPyMhb3KgUMx7RWrbgsdij4s/8nuRQt962l1JhUEYFM12cE 0eCreQP8u+FlkUcw8qUP5qa9K0dFmHZtF0O4dOOHQ38Col+wCL7uv5EoHy1GRfBp QF3bSj//D6h5zkelZHGVAw9lDLnegmx0lmGi+Yow2jLyd0JcTMc+3KVbteegjxTd k7Kw0lis1U0VAIfUIaCR+VQAqT5gsn/ecouuMk5X7fwww+NfopJ5yNVnmY3j6GQj RV9lJfNOyaZAwF67fetTfQfXwSTkEJ/qepEQNWle6V6VMrhoA4pLQ/f8gu6qCe9a W0qXP14vAuGhymFQNgLmy5i/L0wIwbyw6uRV8nbiftd/rF9EIZP8nWMGi/wJ8hRp iTimvQ8iOBUL5e7NpYBizyselw6VYGvQDxBkdJVxPMiSA1BRihq1ufSKri91xht0 NZ1UGAF3kex8WrBwodPKBJb6n4DH0gC+DZ1mNIhmSc3io22Z0ljpTfx6SKVjmwJX vtIBM8YYV2eS/jiePuGpDgHCLl10xOZIxi5/6XCfd+c8/eHLXoc0WKv+wSzRSUnK REd1nrLE7ayD1GGfGThwgtrUZ1EjcRqTKS7puo3aYw8ddj1CptXN7AMk0AXzby7M 2kmTwYpi1/dlc74wor37PwhCUvdO0FWQPRJrL/cAax8M9EelfQc= =hENL -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--