From owner-cvs-all@FreeBSD.ORG Mon Dec 8 19:34:38 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DCFD16A4D0 for ; Mon, 8 Dec 2003 19:34:38 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 5DF1943D2A for ; Mon, 8 Dec 2003 19:34:33 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 78102 invoked by uid 1002); 9 Dec 2003 03:34:32 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 9 Dec 2003 03:34:32 -0000 Message-ID: <3FD5427F.3080001@freebsd.org> Date: Mon, 08 Dec 2003 20:33:19 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103 X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <200312072352.hB7Nqsw6011333@repoman.freebsd.org> <20031208190305.GA956@cirb503493.alcatel.com.au> <20031208191702.GA50623@xor.obsecurity.org> <20031208231349.GA10458@dragon.nuxi.com> In-Reply-To: <20031208231349.GA10458@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: cvs-src@freebsd.org cc: Kris Kennaway Subject: Re: cvs commit: src/sys/i386/conf GENERIC src/sys/alpha/confGENERIC src/sys/sparc64/conf GENERIC src/sys/amd64/conf GENERIC src/sys/pc98/conf GENERIC X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2003 03:34:38 -0000 David O'Brien wrote: > On Mon, Dec 08, 2003 at 11:17:02AM -0800, Kris Kennaway wrote: > >>Yeah, that's a good idea. GNATS is full of PRs with panic strings but >>no tracebacks, and it can be time-consuming and difficult to get >>people to obtain them post-facto. If we ship a kernel.debug with the >>release then we can explain in the release documentation how to use it >>to submit a useful PR. > > > The problem is release/Makefile isn't smart enough to not put the debug > kernels in the ISO's /boot. Thus ISO's are much larger and there is less > package space. > Fixing this sounds like a good task for 5.3. Hacking the release scripts is generally risky and is not something that I'm eager to do right before the final release builds. Are there any volunteer for doing this in HEAD? Scott