From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: Re: [PATCH] gnu: gdk-pixbuf: Disable pixbuf-scale test. Date: Sat, 6 Feb 2016 17:24:29 -0500 Message-ID: <20160206222429.GB8398@jasmine> References: <56b2fd41.57116b0a.987be.ffffd924@mx.google.com> <20160206151749.GA9236@debian> <20160206210439.GA12535@novena-choice-citizen.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:37498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSBHO-0003md-N7 for guix-devel@gnu.org; Sat, 06 Feb 2016 17:24:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSBHJ-0006eR-MH for guix-devel@gnu.org; Sat, 06 Feb 2016 17:24:34 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:52210) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSBHJ-0006eM-J3 for guix-devel@gnu.org; Sat, 06 Feb 2016 17:24:29 -0500 Content-Disposition: inline In-Reply-To: <20160206210439.GA12535@novena-choice-citizen.lan> 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-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Jookia <166291@gmail.com> Cc: guix-devel@gnu.org On Sun, Feb 07, 2016 at 08:04:39AM +1100, Jookia wrote: > On Sat, Feb 06, 2016 at 04:17:49PM +0100, Andreas Enge wrote: > > On Tue, Feb 02, 2016 at 09:25:41PM +0000, Jookia wrote: > > > On systems with little ram (2G in my case) the pixbuf-scale test will either > > > freeze the system of cause excessive swapping without the test every completing. > > > > The patch looks good to me, but it would be nice to have another opinion. > > > > In any case, it should probably be applied once we have a bit more build > > power, since it causes substantial package rebuilds. > > > > Perhaps substantial package rebuild patches should be grouped in to a staging > branch? This would also help those that do their own builds (I'm biased.) If I understand your suggestion correctly, we already do this. When we need to update a core package like glibc that will cause mass rebuilds, we put the change in another branch, and build that branch. Once it is built, we merge the branch into master. That way, the binary substitutes are already built when users start requesting them. Sorry if that is not totally accurate. I am sure someone will correct me in that case :) > > > Andreas > > Jookia >