From owner-svn-src-user@FreeBSD.ORG Mon Dec 2 17:30:17 2013 Return-Path: Delivered-To: svn-src-user@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 DE9D6C4B; Mon, 2 Dec 2013 17:30:16 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 538961693; Mon, 2 Dec 2013 17:30:16 +0000 (UTC) Received: from alph.d.allbsd.org (p4181-ipbf1307funabasi.chiba.ocn.ne.jp [123.225.173.181]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id rB2HTwgA005497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Dec 2013 02:30:09 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.5) with ESMTP id rB2HTwjF073114; Tue, 3 Dec 2013 02:29:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 03 Dec 2013 02:29:54 +0900 (JST) Message-Id: <20131203.022954.467097282834823426.hrs@allbsd.org> To: gjb@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release From: Hiroki Sato In-Reply-To: <20131202172052.GK1839@glenbarber.us> References: <20131202160333.GI1839@glenbarber.us> <20131203.021439.505942678651568262.hrs@allbsd.org> <20131202172052.GK1839@glenbarber.us> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Dec__3_02_29_54_2013_051)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Tue, 03 Dec 2013 02:30:09 +0900 (JST) X-Spam-Status: No, score=-99.1 required=13.0 tests=CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 17:30:17 -0000 ----Security_Multipart(Tue_Dec__3_02_29_54_2013_051)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Glen Barber wrote in <20131202172052.GK1839@glenbarber.us>: gj> On Tue, Dec 03, 2013 at 02:14:39AM +0900, Hiroki Sato wrote: gj> > gj> > - In the current release.sh, variables unintentionally set in the gj> > gj> > builder's environment still pollutes commands which run in gj> > gj> > release.sh when the variables are not set in the script but gj> > gj> > accepted by make or other utilities. Catching all of the variables gj> > gj> > is quite difficult. gj> > gj> > gj> > gj> gj> > gj> Do you have an example? If you are referring to a previous problem with gj> > gj> 10.x builds, the actual problem was a race in the build toolchain, and gj> > gj> not variable pollution. I was able to confirm this was the case there. gj> > gj> > One of the surprising examples I experienced was that svn co gj> > sometimes fails with LC_ALL=C. Subversion stores repo data in UTF-8, gj> > so iconv conversion happens when LC_ALL is not UTF-8 compatible (and gj> > it broke "svn co head/" a while ago). Besides, TARGET, TARGET_ARCH, gj> > MAKEOBJDIR, MAKEOBJDIRPREFIX, and OBJDIR are also dangerous and gj> > unprotected variables for make(1). An empty TARGET caused an gj> > infinite loop in libc build, so I fixed it in Makefile yesterday. gj> gj> I saw your fix for empty TARGET. I ran into that problem quite some gj> time ago. gj> gj> > All of them are examples of "unintentional" variables, so being gj> > careful is enough to avoid them, though. gj> > gj> > gj> > Anyway, I do not have a strong opinion if using FOO=A or : ${FOO:=A}. gj> > gj> > I agree that the latter assumes all of the envvars must be under gj> > gj> > control and it needs one more step than just invoking the script, and gj> > gj> > a leaked variable can break the build. If you do not like it, I will gj> > gj> > change them with FOO=A. gj> > gj> > gj> > gj> gj> > gj> Yes, please. gj> > gj> > Will do. I will not merge the changes before 10.0R is out in any gj> > case. gj> > gj> gj> Right, but I will still likely have to change build scripts (again) for gj> head/ snapshots... Okay, I do not mind. Please go ahead. -- Hiroki ----Security_Multipart(Tue_Dec__3_02_29_54_2013_051)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iEYEABECAAYFAlKcw5IACgkQTyzT2CeTzy3k5ACfbWUJJi4bQLGVpldMbLimCnN1 JRMAoLRHVPg3P4qFY97jBQG578QeZTVW =w2CF -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Dec__3_02_29_54_2013_051)----