From obrien@NUXI.com  Mon May 12 08:22:09 2003
Return-Path: <obrien@NUXI.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id DB83837B401
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 12 May 2003 08:22:09 -0700 (PDT)
Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 55FEA43FBF
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 12 May 2003 08:22:09 -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 h4CFM2m2019921
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 12 May 2003 08:22:02 -0700 (PDT)
	(envelope-from obrien@dragon.nuxi.com)
Received: (from obrien@localhost)
	by dragon.nuxi.com (8.12.9/8.12.9/Submit) id h4CFM2an019920;
	Mon, 12 May 2003 08:22:02 -0700 (PDT)
Message-Id: <200305121522.h4CFM2an019920@dragon.nuxi.com>
Date: Mon, 12 May 2003 08:22:02 -0700 (PDT)
From: "David O'Brien" <obrien@freebsd.org>
Reply-To: "David O'Brien" <obrien@NUXI.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: make release does not use proper binaries in release.9
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         52122
>Category:       misc
>Synopsis:       make release does not use proper binaries in release.9
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 12 08:30:15 PDT 2003
>Closed-Date:    Fri Oct 03 02:33:04 PDT 2003
>Last-Modified:  Fri Oct 03 02:33:04 PDT 2003
>Originator:     David O'Brien
>Release:        FreeBSD 5.0-CURRENT i386
>Organization:
Alpha re-builders
>Environment:
System: FreeBSD dragon.nuxi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #364: Sat Apr 26 08:57:30 PDT 2003 rootk@dragon.nuxi.com:/FBSD/src/sys/i386/compile/DRAGON i386

	Alpha, FreeBSD 5.1-beta

>Description:
	'make release' populates the chroot area with potentually non-latest
	bits (acceptable), and those bits are not refreshed as part of
	the release world build w/in the chroot area.  This means that the
	release.9 target is using disklabel & friends from the host system
	and not those matching the 'cvs up' tag(date).  Thus if one of these
	tools is broken and is later fixed, 'make rerelease' will not get the
	fixes.

>How-To-Repeat:
	difficult -- review the Alpha 5.1-BETA re-alpha thread.

>Fix:

	add 'make -DNOGAMES -DNOHTML -DNOINFO -DNOMAN -DNOPROFILE installworld'
	to {CHROOT}/mk.
>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@FreeBSD.org>
To: "David O'Brien" <obrien@NUXI.com>
Cc: bug-followup@FreeBSD.org
Subject: Re: misc/52122: make release does not use proper binaries in release.9
Date: Wed, 14 May 2003 18:40:17 +0300

 On Mon, May 12, 2003 at 08:22:02AM -0700, David O'Brien wrote:
 > 
 > >Organization:
 > Alpha re-builders
 > >Environment:
 > System: FreeBSD dragon.nuxi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #364: Sat Apr 26 08:57:30 PDT 2003 rootk@dragon.nuxi.com:/FBSD/src/sys/i386/compile/DRAGON i386
 > 
 > 	Alpha, FreeBSD 5.1-beta
 > 
 > >Description:
 > 	'make release' populates the chroot area with potentually non-latest
 > 	bits (acceptable), and those bits are not refreshed as part of
 > 	the release world build w/in the chroot area.  This means that the
 > 	release.9 target is using disklabel & friends from the host system
 > 	and not those matching the 'cvs up' tag(date).  Thus if one of these
 > 	tools is broken and is later fixed, 'make rerelease' will not get the
 > 	fixes.
 > 
 This is by design.  To successfully use up-to-date tools, one would
 also need to be running an up-to-date kernel; this is especially
 true in the disk^Wbsdlabel(8) case that relies heavily on GEOM part
 of the kernel -- even if you'll be able to cross-compile bsdlabel
 and install it under ${CHROOTDIR}, the running kernel may still be
 inadequate for running it.  I think PHK is the spokesman here.
 
 > >How-To-Repeat:
 > 	difficult -- review the Alpha 5.1-BETA re-alpha thread.
 > 
 > >Fix:
 > 
 > 	add 'make -DNOGAMES -DNOHTML -DNOINFO -DNOMAN -DNOPROFILE installworld'
 > 	to {CHROOT}/mk.
 > 
 This would be backwards; see log for release/Makefile,v 1.672 for
 more details.
 
 A proper "fix" would be to either manually upgrade the necessary
 bits (kernel and disk tools) with up-to-date copies, or just do
 a full upgrade before attempting to "make release".

From: obrien@FreeBSD.org
To: freebsd-gnats-submit@FreeBSD.org, obrien@NUXI.com
Cc:  
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 08:59:24 -0700 (PDT)

 I'm adding this from John Baldwin <jhb@FreeBSD.org>
 Message-ID: <XFMail.20030514102336.jhb@FreeBSD.org> as its useful:
 
 	A better solution would be to do what I have said before but
 	you and others whined that you didn't want:  We should _still_
 	do a full make world in the chroot _like_ we used to and then
 	do a further make buildworld for the cross-build case.  ru@
 	didn't like that and tried to change everything to use
 	cross-built tools or some such garbage.  Since ru@ is the one
 	who broke this in revision 1.672 we should at least ask him
 	for input on how to fix this.  Ruslan, the problem is that we
 	need up to date tools in the release chroot.

From: Ruslan Ermilov <ru@freebsd.org>
To: John Hay <jhay@icomtek.csir.co.za>
Cc: obrien@freebsd.org, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 19:52:29 +0300

 --m51xatjYGsM+13rf
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, May 15, 2003 at 06:31:42PM +0200, John Hay wrote:
 > >=20
 > >  I'm adding this from John Baldwin <jhb@FreeBSD.org>
 > >  Message-ID: <XFMail.20030514102336.jhb@FreeBSD.org> as its useful:
 > > =20
 > >  	A better solution would be to do what I have said before but
 > >  	you and others whined that you didn't want:  We should _still_
 > >  	do a full make world in the chroot _like_ we used to and then
 > >  	do a further make buildworld for the cross-build case.  ru@
 > >  	didn't like that and tried to change everything to use
 > >  	cross-built tools or some such garbage.  Since ru@ is the one
 > >  	who broke this in revision 1.672 we should at least ask him
 > >  	for input on how to fix this.  Ruslan, the problem is that we
 > >  	need up to date tools in the release chroot.
 >=20
 > Why not just update the source and do a buildworld in the native
 > environment? You can either do it before every release snapshot
 > or like me, when it seems necesary. This way I save a few cycles.
 >=20
 > 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.
 >=20
 > Just my 2 bits. (I'm not on RE, but have two machines building a
 > -stable and -current snap every night.)
 >=20
 I was hoping that you will pop up, John.  This just seconds my
 words about it, thank you.
 
 
 Cheers,
 --=20
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --m51xatjYGsM+13rf
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.1 (FreeBSD)
 
 iD8DBQE+w8XNUkv4P6juNwoRAlqVAJ0Zh492PLZXz4Md6e6va1dQg54FbwCeJCBZ
 /2TTmEfNYi9xBDCxS/+B6zc=
 =T6ph
 -----END PGP SIGNATURE-----
 
 --m51xatjYGsM+13rf--

From: Ruslan Ermilov <ru@freebsd.org>
To: "David O'Brien" <obrien@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 20:55:52 +0300

 On Thu, May 15, 2003 at 09:58:44AM -0700, David O'Brien wrote:
 > 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.
 > 
 Now you know what to do -- you have to buildworld at the minimum
 (if you're sure the built world can be run under the running kernel).
 This isn't too different from having "make release" to do it for
 you even when it's not needed and aside from the fact that it would
 break cross-releases.  I already told you what to do, but you aren't
 going to listen, are you?
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: "David O'Brien" <obrien@freebsd.org>
To: Ruslan Ermilov <ru@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 11:30:01 -0700

 On Thu, May 15, 2003 at 08:55:52PM +0300, Ruslan Ermilov wrote:
 > On Thu, May 15, 2003 at 09:58:44AM -0700, David O'Brien wrote:
 > > 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.
 > > 
 > Now you know what to do -- you have to buildworld at the minimum
 
 I did build world.  But you're being vauge -- which world???  Give a list
 of specific steps.

From: Ruslan Ermilov <ru@freebsd.org>
To: "David O'Brien" <obrien@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 21:56:24 +0300

 On Thu, May 15, 2003 at 11:30:01AM -0700, David O'Brien wrote:
 > On Thu, May 15, 2003 at 08:55:52PM +0300, Ruslan Ermilov wrote:
 > > On Thu, May 15, 2003 at 09:58:44AM -0700, David O'Brien wrote:
 > > > 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.
 > > > 
 > > Now you know what to do -- you have to buildworld at the minimum
 > 
 > I did build world.  But you're being vauge -- which world???  Give a list
 > of specific steps.
 > 
 Normal world, David, nothing magical.
 
 Option 1:
 
 cd /usr/src && \
 make buildworld (if you're sure the installed kernel can run it)
 
 Option 2:
 
 cd /usr/src && make world kernel (in the order documented in
 UPDATING)
 
 Then:
 
 cd /usr/src/release
 make release ...
 
 Like I said, if you hit a problem before May 5, it's totally
 different from the "fresh world bits" issue.  Rather, it's
 just a WIP of twiddling with bsdlabel/disklabel, and not
 committing the supporting patches to release/Makefile and
 friends (some of them are still necessary).  bsdlabel(8) is
 only linked to disklabel(8) after
 
 $FreeBSD: src/sbin/bsdlabel/Makefile,v 1.15 2003/05/05 21:28:08 phk Exp $
 
 commit.  My patch that I sent to phk@ on May 3 dealt with
 this, by using bsdlabel(8) if it exists.  This is now
 less of an issue, except for bsdlabel not ending up on
 the fixit floppy and a non-working sparc64/mkisoimages.sh.
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: Ruslan Ermilov <ru@freebsd.org>
To: "David O'Brien" <obrien@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Fri, 16 May 2003 00:01:06 +0300

 On Thu, May 15, 2003 at 11:31:40AM -0700, David O'Brien wrote:
 > On Thu, May 15, 2003 at 08:13:50PM +0200, John Hay wrote:
 > > On Thu, May 15, 2003 at 09:58:44AM -0700, David O'Brien wrote:
 > > > 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.
 > > 
 > > Maybe the issue is more of documentation? I know hindsight makes it easy,
 > > but an installworld inside the chroot area or "world DESTDIR=/chrootarea"
 > > should have been enough to get the binaries updated.
 > 
 > It is, and was.  The problem is restarting with /mk used to do this for
 > you.  It stopped and the only documentation was hidding in the commit
 > log.
 > 
 It used to, but only "if [ ! -f /tmp/.world_done ]", and you were
 way beyond that point, was it release.9?  Nevertheless, I'm not
 going to repeat all arguments explaining why "make world" in
 CHROOTDIR is an etremely bad idea.
 
 In older days, it was necessary to ALWAYS upgrade to a recent
 before attempting to "make release".  These requirements are
 now lifted, and it's often that you can build a fresh snap on
 an older system.
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age

From: "David O'Brien" <obrien@freebsd.org>
To: Ruslan Ermilov <ru@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 18:10:34 -0700

 On Thu, May 15, 2003 at 09:56:24PM +0300, Ruslan Ermilov wrote:
 > > > Now you know what to do -- you have to buildworld at the minimum
 > > 
 > > I did build world.  But you're being vauge -- which world???  Give a list
 > > of specific steps.
 > > 
 > Normal world, David, nothing magical.
 > 
 > Option 1:
 > 
 > cd /usr/src && \
 > make buildworld (if you're sure the installed kernel can run it)
 > 
 > Option 2:
 > 
 > cd /usr/src && make world kernel (in the order documented in
 > UPDATING)
 > 
 > Then:
 > 
 > cd /usr/src/release
 > make release ...
 
 You seem to keep missing the point that I did not want to restart a "make
 release" that included ports and docs.  Such a release takes a very long
 time on Alpha.

From: "David O'Brien" <obrien@freebsd.org>
To: Ruslan Ermilov <ru@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Thu, 15 May 2003 18:12:27 -0700

 On Fri, May 16, 2003 at 12:01:06AM +0300, Ruslan Ermilov wrote:
 > > > > 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.
 > > > 
 > > > Maybe the issue is more of documentation? I know hindsight makes it easy,
 > > > but an installworld inside the chroot area or "world DESTDIR=/chrootarea"
 > > > should have been enough to get the binaries updated.
 > > 
 > > It is, and was.  The problem is restarting with /mk used to do this for
 > > you.  It stopped and the only documentation was hidding in the commit
 > > log.
 > > 
 > It used to, but only "if [ ! -f /tmp/.world_done ]", and you were
 > way beyond that point, was it release.9?
 
 Yes as stated clearly above, it was release.9 -- the very last release
 target.
 
 > In older days, it was necessary to ALWAYS upgrade to a recent
 > before attempting to "make release".
 
 So?  JKH and msmith at WCCDROM liked it that way.  Such issues as this
 came up in discussions when I worked there.

From: Ruslan Ermilov <ru@freebsd.org>
To: "David O'Brien" <obrien@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Fri, 16 May 2003 08:06:51 +0300

 --wRRV7LY7NUeQGEoC
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Thu, May 15, 2003 at 06:10:34PM -0700, David O'Brien wrote:
 > On Thu, May 15, 2003 at 09:56:24PM +0300, Ruslan Ermilov wrote:
 > > > > Now you know what to do -- you have to buildworld at the minimum
 > > >=20
 > > > I did build world.  But you're being vauge -- which world???  Give a =
 list
 > > > of specific steps.
 > > >=20
 > > Normal world, David, nothing magical.
 > >=20
 > > Option 1:
 > >=20
 > > cd /usr/src && \
 > > make buildworld (if you're sure the installed kernel can run it)
 > >=20
 > > Option 2:
 > >=20
 > > cd /usr/src && make world kernel (in the order documented in
 > > UPDATING)
 > >=20
 > > Then:
 > >=20
 > > cd /usr/src/release
 > > make release ...
 >=20
 > You seem to keep missing the point that I did not want to restart a "make
 > release" that included ports and docs.  Such a release takes a very long
 > time on Alpha.
 >=20
 You could as easily extend the idea for "make rerelease":
 
 Upgrade the world first:
 
 	cd /usr/src && \
 	make world DESTDIR=3D${CHROOTDIR}
 	cd /usr/src/etc && \
 	make distribution DESTDIR=3D${CHROOTDIR}
 
 Then:
 
 	cd /usr/src/release
 	make rerelease ...
 
 
 Cheers,
 --=20
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --wRRV7LY7NUeQGEoC
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.1 (FreeBSD)
 
 iD8DBQE+xHHrUkv4P6juNwoRAhV0AJwJuHkf5RQmT7SuaqFRYnNrr7HdyACfVmDD
 OpjazgoN7RcHRz+FTtbyKx0=
 =cS22
 -----END PGP SIGNATURE-----
 
 --wRRV7LY7NUeQGEoC--

From: Ruslan Ermilov <ru@freebsd.org>
To: "David O'Brien" <obrien@freebsd.org>
Cc: John Hay <jhay@icomtek.csir.co.za>, bug-followup@freebsd.org
Subject: Re: misc/52122: make release does not use proper binar
Date: Fri, 16 May 2003 08:17:43 +0300

 On Thu, May 15, 2003 at 06:12:27PM -0700, David O'Brien wrote:
 > On Fri, May 16, 2003 at 12:01:06AM +0300, Ruslan Ermilov wrote:
 > > > > > 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.
 > > > > 
 > > > > Maybe the issue is more of documentation? I know hindsight makes it easy,
 > > > > but an installworld inside the chroot area or "world DESTDIR=/chrootarea"
 > > > > should have been enough to get the binaries updated.
 > > > 
 > > > It is, and was.  The problem is restarting with /mk used to do this for
 > > > you.  It stopped and the only documentation was hidding in the commit
 > > > log.
 > > > 
 > > It used to, but only "if [ ! -f /tmp/.world_done ]", and you were
 > > way beyond that point, was it release.9?
 > 
 > Yes as stated clearly above, it was release.9 -- the very last release
 > target.
 > 
 > > In older days, it was necessary to ALWAYS upgrade to a recent
 > > before attempting to "make release".
 > 
 > So?  JKH and msmith at WCCDROM liked it that way.  Such issues as this
 > came up in discussions when I worked there.
 > 
 So to always be on the safe side for native builds, you should follow
 that old rule too -- this will guarantee that you will use fresh bits.
 
 The rule is simple: the fresh world SHOULD be able to release itself;
 the world other than the one that you're trying to release COULD be
 able to release, with a reasonable chance of working.  If you're not
 sure, upgrade kernel/world first.
 
 On Mon, Mar 17, 2003 at 07:00:56PM +0200, Ruslan Ermilov wrote:
 > Murray,
 >
 > Just wonder, what environment do you use to produce these
 > snapshots/releases.  Do you use the old canonical way of
 > first upgrading the building system to the level of the
 > snapshot/release, or do you just use the "compatible"
 > system like 4.7-STABLE?
 
 On Mon, Mar 17, 2003 at 09:17:40AM -0800, Murray Stokely wrote:
 > On Mon, Mar 17, 2003 at 07:00:56PM +0200, Ruslan Ermilov wrote:
 > > Just wonder, what environment do you use to produce these
 > > snapshots/releases.  Do you use the old canonical way of
 >
 > The build machines are running 4.8-RC and 4.8-PRERELEASE.  They aren't
 > running exactly the same level of the snapshot/release, but within 2
 > weeks or so.
 
 On Mon, Mar 17, 2003 at 09:26:35AM -0800, Murray Stokely wrote:
 > On Mon, Mar 17, 2003 at 07:20:30PM +0200, Ruslan Ermilov wrote:
 > > Great!  :-)
 > >
 > > And what environment you're planning to use to roll the final
 > > 4.8-RELEASE, when it comes to this point?
 >
 > It will probably be 4.8-RELEASE or within just a few days of that.  Of
 > course, if you're asking this because you want to make a disruptive
 > change, then that might affect what I'm able to use. ;) Why?
 
 
 Cheers,
 -- 
 Ruslan Ermilov		Sysadmin and DBA,
 ru@sunbay.com		Sunbay Software AG,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.512.251	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
State-Changed-From-To: open->closed 
State-Changed-By: ru 
State-Changed-When: Fri Oct 3 02:32:46 PDT 2003 
State-Changed-Why:  
It's by design. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=52122 
>Unformatted:
