From owner-svn-src-head@FreeBSD.ORG Fri Jan 24 00:56:13 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0EFF99AA; Fri, 24 Jan 2014 00:56:13 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D68171066; Fri, 24 Jan 2014 00:56:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s0O0uAlE087345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 16:56:11 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s0O0uA76087344; Thu, 23 Jan 2014 16:56:10 -0800 (PST) (envelope-from jmg) Date: Thu, 23 Jan 2014 16:56:10 -0800 From: John-Mark Gurney To: Peter Wemm Subject: Re: svn commit: r261031 - in head: . etc usr.sbin/etcupdate usr.sbin/mergemaster Message-ID: <20140124005610.GC75135@funkthat.com> References: <201401221659.s0MGxrc7056036@svn.freebsd.org> <201401231503.42671.jhb@freebsd.org> <20140123212256.GA37334@admin.xzibition.com> <201401231712.51610.jhb@freebsd.org> <52E19C42.2030700@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52E19C42.2030700@wemm.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 23 Jan 2014 16:56:11 -0800 (PST) Cc: src-committers@FreeBSD.org, John Baldwin , svn-src-all@FreeBSD.org, David Chisnall , Glen Barber , svn-src-head@FreeBSD.org, Bryan Drewery X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2014 00:56:13 -0000 Peter Wemm wrote this message on Thu, Jan 23, 2014 at 14:48 -0800: > 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? How about when current ARCH != TARGET_ARCH? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."