Date: Tue, 03 Dec 2013 02:29:54 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: gjb@FreeBSD.org Cc: src-committers@FreeBSD.org, svn-src-user@FreeBSD.org Subject: Re: svn commit: r258848 - user/hrs/releng/release Message-ID: <20131203.022954.467097282834823426.hrs@allbsd.org> In-Reply-To: <20131202172052.GK1839@glenbarber.us> References: <20131202160333.GI1839@glenbarber.us> <20131203.021439.505942678651568262.hrs@allbsd.org> <20131202172052.GK1839@glenbarber.us>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Dec__3_02_29_54_2013_051)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Glen Barber <gjb@FreeBSD.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131203.022954.467097282834823426.hrs>