From owner-svn-src-all@FreeBSD.ORG Fri Jan 24 22:01:44 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5F22430E; Fri, 24 Jan 2014 22:01:44 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32E691DD7; Fri, 24 Jan 2014 22:01:44 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id D86B1B95D; Fri, 24 Jan 2014 17:01:41 -0500 (EST) From: John Baldwin To: Peter Wemm Subject: Re: svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster Date: Fri, 24 Jan 2014 16:19:14 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <201401221659.s0MGxrc7056036@svn.freebsd.org> <201401231712.51610.jhb@freebsd.org> <52E19C42.2030700@wemm.org> In-Reply-To: <52E19C42.2030700@wemm.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201401241619.14744.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Jan 2014 17:01:41 -0500 (EST) Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, David Chisnall , Glen Barber , svn-src-head@freebsd.org, Bryan Drewery X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 22:01:44 -0000 On Thursday, January 23, 2014 5:48:34 pm Peter Wemm wrote: > On 1/23/14, 2:12 PM, John Baldwin wrote: > > On Thursday, January 23, 2014 4:22:56 pm Bryan Drewery wrote: > >> On Thu, Jan 23, 2014 at 03:03:42PM -0500, John Baldwin wrote: > >>> On Thursday, January 23, 2014 2:48:41 pm Bryan Drewery wrote: > >>>> On Thu, Jan 23, 2014 at 02:39:14PM -0500, John Baldwin wrote: > >>>>> On Thursday, January 23, 2014 10:42:36 am David Chisnall wrote: > >>>>>> On 22 Jan 2014, at 22:36, Glen Barber wrote: > >>>>>> > >>>>>>> It needs to use the build host version, because using (for example) > >>>>>>> powerpc resulting binary won't work on and amd64 system. > >>>>>> > >>>>>> If it's used as part of the build, then it should be part of the toolchain > >>>>> target and we should be using the version built there. > >>>>> > >>>>> 'make distribute' is not a normal part of the build (it's not part of > >>>>> buildworld or installworld). Both mergemaster and etcupdate only run it > >>>>> after an installworld has been performed, in which case an up-to-date > >>>>> services_mkdb should already be installed. > >>>>> > >>>>> Bryan, what are you running 'make distribute' for? Is this to populate > >>>>> a new jail from a world build? > >>>> > >>>> Yes, poudriere uses this to create jails. It runs: > >>>> > >>>> export TARGET_ARCH=... > >>>> make buildworld > >>>> make installworld DESTDIR=... > >>>> make distrib-dirs DESTDIR=... DB_FROM_SRC=1 > >>>> make distribution DESTDIR=... > >>>> > >>>> > >>>> No mergemaster or etc-update is ran, we just install all of the > >>>> defaults. > >>> > >>> Yes, but you are attemping to install a newer jail than the host, and strictly > >>> speaking that isn't supported. (Rather, we only guarantee that a jail will work > >>> so long as its world is older or equal in age to the host.) > >> > >> I am aware of *running* newer jails not being suppored, but *building* > >> seems to be an absolute must to be supported. How else would you > >> upgrade? > > > > A normal upgrade does 'installworld' followed by some sort of /etc updating > > tool. It doesn't do 'make distribute'. Also, this is related to why one > > is not guaranteed to be able to do an 'installworld' unless you've booted into > > the new kernel first (though it often works, and 'make distribute' also often > > works, but often != always). > > > > The thing is, there is no notion of cross-tools, etc. for things like > > installworld and distribution. We have always expected the host to have > > ITOOLS that work. > > > > Note that this exact situation has happened before back when cap_mkdb and > > pwd_mkdb grew endianness flags for release cross-builds. The pwd_mkdb > > flag and the change to enable it in etc/Makefile were both made on the same > > day. (The cap_mkdb change was made earlier, but that appears to be more > > a result of the testing cycle for cross-building releases than an > > intentional delay.) > > FWIW, we do this at work and ran into the same problem. We do the same > things that poudriere does, almost exactly. > > We added: "CAP_MKDB_ENDIAN= PWD_MKDB_ENDIAN=" to the "make DESTDIR=/stage > distribution" phase. This currently works all the way back to stable/4. > > Is there a middle ground where we could only specify -l / -b in a cross > build perhaps? I would be fine with that, definitely. Not sure what the proper test for that is though. -- John Baldwin