From owner-freebsd-sparc64@FreeBSD.ORG Fri Mar 26 15:00:39 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0ED5A106564A for ; Fri, 26 Mar 2010 15:00:39 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id D3C19152A04 for ; Fri, 26 Mar 2010 15:00:28 +0000 (UTC) Received: (qmail 64336 invoked from network); 26 Mar 2010 15:00:28 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 26 Mar 2010 15:00:28 -0000 Message-ID: <4BACCC0C.7010401@freebsd.org> Date: Fri, 26 Mar 2010 08:00:28 -0700 From: Colin Percival User-Agent: Thunderbird 2.0.0.23 (X11/20100317) MIME-Version: 1.0 To: Marius Strobl References: <4BA9C0AC.3080801@wooh.hu> <20100324075709.GC13561@lonesome.com> <20100324223809.GA34342@alchemy.franken.de> <4BAB4AB9.2090908@buffalo.edu> <1269526260.2007.3.camel@main.lerwick.hopto.org> <20100325233558.GI20888@alchemy.franken.de> In-Reply-To: <20100325233558.GI20888@alchemy.franken.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-sparc64@freebsd.org, Mark Linimon , FreeBSD-Questions@freebsd.org, kensmith@freebsd.org Subject: Re: freebsd-update(8) under sparc64? Why is it not available? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:00:39 -0000 Hi all, Marius Strobl wrote: > On Thu, Mar 25, 2010 at 02:11:00PM +0000, Craig Butler wrote: >>>>>> World build started on Sat Mar 20 23:34:54 EDT 2010 >>>>>> World build completed on Sun Mar 21 00:50:58 EDT 2010 >> Can we bend the rules a little ?? Who set the requirement of an hour ? >> freebsd-update might be a good thing to have.. > > IIRC it was Colin who once mentioned that this was decided > by the Security Officers in order to be able to react to > high impact security issues affecting multiple branches in > a timely manner should the need ever arise. In any case > he should be the right person to talk to about this so I > CC'ed him. The can-buildworld-in-an-hour is a rough rule of thumb, but it's pretty good. The issue here, as Marius said, is that we want to be able to push out advisories promptly; this isn't a problem when we're only dealing with one branch, but sometimes we have issues which affects all the releases -- currently we support {6.4, 7.1, 7.2, 7.3, 8.0}, which is a fairly typical set -- and each run of patch builds requires two complete buildworlds plus some other stuff (kernel builds, comparing bits between builds, shuffling them around, building binary patches)... so I imagine that a 1.5 hour sparc64 buildworld time would put us at over 24 hours for a complete set of patch builds. And that's not counting the fact that every new FreeBSD release takes longer to build. Some people have suggested in the past that we could do sparc64 update builds but not hold up advisories waiting for them -- but I really don't like that option, since it would "train" people to use binary updates rather than source updates, and the times when they would need to wait -- time-sensitive security advisories -- are exactly the times when they shouldn't wait. (As a side note, for obvious security reasons I don't want to add hardware outside of the established FreeBSD.org datacenters for this sort of thing.) I think the best approach towards having FreeBSD Update support for sparc64 is to get release cross-building working; that way we would be able to use amd64 hardware, which I think we can safely assume will continue to be available in ever-increasing speeds. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid