Date: Mon, 21 May 2007 15:30:01 +0400 From: Ruslan Ermilov <ru@freebsd.org> To: Garance A Drosehn <gad@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_tools Makefile Message-ID: <20070521113001.GC87534@rambler-co.ru> In-Reply-To: <p06240805c27683e3c36d@[128.113.24.47]> References: <200705190756.l4J7u9wP058382@repoman.freebsd.org> <20070519085103.GA61276@rambler-co.ru> <20070519105804.6b6cae10@kan.dnsalias.net> <20070520062748.GA54935@rambler-co.ru> <p06240805c27683e3c36d@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
--ABTtc+pdwF7KHXCz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, May 20, 2007 at 07:08:37PM -0400, Garance A Drosehn wrote:
> At 10:27 AM +0400 5/20/07, Ruslan Ermilov wrote:
> >
> > It sometimes happens when the date/time are not being set
> > properly, so that the tools are mistakenly rebuilt again
> > at an inappropriate time when in the foreign environment
> > of the target -- the problem is usually understood better
> > when building for another CPU architecture and hitting it.
> > I think this was an inappropriate commit to make, unless
> > the problem can be reproduced. I have upgraded several
> > i386's and amd64's without a problem.
>=20
> Is there any way we could detect the clock-skew problem? This keeps
> coming up, year-after-year, for many different people, including
> very experienced developers. And when it does come up, it is
> either: (1) totally safe, and thus unnoticed, or (2) screws up
> someone in the middle of some major upgrade, thus causing great
> angst and gnashing of teeth.
>=20
> It would be nice if we could come up with a reliable check for the
> problem.
>=20
This came up before, and I have a rudimentary patch for this
that should cover most of the cases, leaving a backdoor for
shooting in the foot, but i'm uncertain about how to properly
address the local/remote date/time mismatch issues I mention
here.
For example, with the below check added, if you "cvs update"
your src/ from a remote repo, and your machine is lagging
time by one minute, you'll end up with a file whose modification
time is set to the future time, from your machine clock's POV.
Also, the one-second granularity could sometimes be annoying.
On Thu, Dec 01, 2005 at 08:47:03PM +0200, Ruslan Ermilov wrote:
> I considered doing this in make(1) a while ago, but have come
> to a conclusion it's not quite safe. For example, I often
> "cvs update" from remote repositories, and that sets modification
> time to that of the repository machine (probably only if it's a
> new file, I don't recall all the conditions now, or it might
> have been NFS-mounted src/ or repo).
>=20
> This has the granularity of one second, i.e., "touch Makefile;
> make -n all" will falsely trigger the check:
>=20
> %%%
> Index: Makefile
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/ncvs/src/Makefile,v
> retrieving revision 1.325
> diff -u -r1.325 Makefile
> --- Makefile 28 Nov 2005 11:14:36 -0000 1.325
> +++ Makefile 1 Dec 2005 18:43:12 -0000
> @@ -159,6 +159,10 @@
> .MAIN: all
> =20
> STARTTIME!=3D LC_ALL=3DC date
> +CHECK_TIME!=3D find ${.CURDIR}/Makefile -mtime -0
> +.if ${CHECK_TIME} =3D=3D "${.CURDIR}/Makefile"
> +.error check your date/time: ${STARTTIME}
> +.endif
> =20
> .if defined(HISTORICAL_MAKE_WORLD) || defined(DESTDIR)
> #
> %%%
Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer
--ABTtc+pdwF7KHXCz
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)
iD8DBQFGUYK5qRfpzJluFF4RApGYAJ43uf/iYpsvCuDJrNYHs7qmvT2mOQCeNtB3
im1xaMCLPplRrj7sMD6Aw2I=
=fm3S
-----END PGP SIGNATURE-----
--ABTtc+pdwF7KHXCz--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070521113001.GC87534>