From owner-freebsd-bugs@FreeBSD.ORG Thu May 15 09:58:56 2003 Return-Path: Delivered-To: freebsd-bugs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81ACC37B401 for ; Thu, 15 May 2003 09:58:56 -0700 (PDT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF37A43F75 for ; Thu, 15 May 2003 09:58:55 -0700 (PDT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.9/8.12.9) with ESMTP id h4FGwom2020353; Thu, 15 May 2003 09:58:50 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h4FGwiWq020348; Thu, 15 May 2003 09:58:44 -0700 (PDT) Date: Thu, 15 May 2003 09:58:44 -0700 From: "David O'Brien" To: John Hay Message-ID: <20030515165844.GA20271@dragon.nuxi.com> References: <200305151600.h4FG0Uwt088142@freefall.freebsd.org> <20030515163142.GA75538@zibbi.icomtek.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030515163142.GA75538@zibbi.icomtek.csir.co.za> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-bugs@freebsd.org Subject: Re: misc/52122: make release does not use proper binar X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 16:58:56 -0000 On Thu, May 15, 2003 at 06:31:42PM +0200, John Hay wrote: > One reason why it isn't that useful inside the chroot area, is that > if your running kernel and the newly built bits gets too much out of > sync you will need to update the machine in any case, so you will > end up with "new" binaries and a kernel on the machine and so it > is a "waste" to recompile world inside the chroot area. In this case the release died near the end (release.9 target). It was easy to update the running kernel and reboot. Now we wanted to restart the release w/o starting from scratch. This release build included ports README's and Docs, and thus takes a very long time to build. To not have to start from scratch, I did "chroot ${CHROOT} /bin/sh" and then ran "rm /tmp/.world_done ; /mk" which should have restarted the release build and done the mimimum work to finish the release. It didn't because of the cross-release commit that removed the installworld w/in the ${CHROOT}. This bit not only me, but another person also building an Alpha snapshot.