From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: [PATCH]: libtiff update Date: Fri, 04 Sep 2015 16:23:40 -0400 Message-ID: <87k2s653xv.fsf@netris.org> References: <20150904194927.GA14579@debian> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:38101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXxXD-0006AI-JD for guix-devel@gnu.org; Fri, 04 Sep 2015 16:24:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXxX9-0004Fo-BQ for guix-devel@gnu.org; Fri, 04 Sep 2015 16:24:31 -0400 Received: from world.peace.net ([50.252.239.5]:49798) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXxX9-0004Fa-7k for guix-devel@gnu.org; Fri, 04 Sep 2015 16:24:27 -0400 In-Reply-To: <20150904194927.GA14579@debian> (Andreas Enge's message of "Fri, 4 Sep 2015 21:49:27 +0200") 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: Andreas Enge Cc: guix-devel@gnu.org Andreas Enge writes: > The first attached patch updates libtiff to 4.0.5. I think that all security > fixes have been integrated there, since debian dropped all patches. Excellent, thanks! > The second patch builds with libjpeg-9 instead of libjpeg-8. > > Comments are welcome. > > I would like to create a separate branch for hydra and apply the two patches > one after one, unless you think this poses too much strain on the build farm. > I think the second patch might be problematic, as conflicts could occur in > dependent packages that still use libjpeg-8, so it would be nice to assess > its impact separately. I'd really rather avoid this. In my experience, it usually doesn't take much effort to determine which update caused a problem. Hydra is very low on all of the important resources: RAM, disk space, disk bandwidth, etc. Given these facts, we simply cannot afford to give it an extra 3000+ builds just to save ourselves a few minutes of debugging time later. Instead of building this out as a dedicated branch, I'd much prefer to simultaneously push these two commits to core-updates, and then deal with any problems as they arise, unless there is some reason why these updates must be deployed ASAP. We already have a lot of other updates on core-updates, and more that should be added before we build it fully, such as fontconfig, glib, sqlite, etc. We cannot afford to build them all out separately. What do you think? Mark