From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 15 12:04:36 2010 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2BEF10656AB; Mon, 15 Nov 2010 12:04:35 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE708FC0C; Mon, 15 Nov 2010 12:04:35 +0000 (UTC) Received: by qyk2 with SMTP id 2so1843199qyk.13 for ; Mon, 15 Nov 2010 04:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5AgCvup/++ImmdJEinyJTy4Rs2jiP+r3QJ7JUK9mwN8=; b=BJGW5ig2pyX3wbQXgLvxkG9OsnPl/phX4Ls6zaTJHEY/Rj7n7sRA/ZCVEk8G4tEP71 /pXIw+WYKFLrEmE2wRgVm+Nry13QWsCmcEUYGZy0vVT/8lkG2WM+c47nPJ661GHR5Yah wxkYhSoiclXQZWT7gpUTFqDZGoSh19jORzD40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=YNlaYy1aaniN4xKCxWu5bpfNDVEJwcPHav1Wusv3xzOqY2OUAmdQekQRMuMSR+f3cA aeEIrMO5a+tzAtmp0AzMbc5uPRdRzt8okiyvD17pa9fEqVFVshWpJpSys+T7K33JS0AY OMujaPo/CcyXZ09xmwKW8Oc5HcdzM4WWY22M4= MIME-Version: 1.0 Received: by 10.229.232.205 with SMTP id jv13mr4992180qcb.68.1289821206947; Mon, 15 Nov 2010 03:40:06 -0800 (PST) Received: by 10.229.182.18 with HTTP; Mon, 15 Nov 2010 03:40:06 -0800 (PST) In-Reply-To: <20101114211334.GG64243@acme.spoerlein.net> References: <20101011084733.GM2392@deviant.kiev.zoral.com.ua> <95F3B27C-42E6-4267-9965-AC3219310C35@cederstrand.dk> <20101021175748.GD19295@acme.spoerlein.net> <20101022100134.GL19295@acme.spoerlein.net> <8B6E3E35-68AF-42ED-98CF-E2A4448DAA11@cederstrand.dk> <0CF7C325-E7D9-4C51-8E60-9A0243D2FFFE@cederstrand.dk> <4CE04750.8060802@FreeBSD.org> <1B779A27-D8AD-4479-AC43-7F5557B720D4@cederstrand.dk> <20101114211334.GG64243@acme.spoerlein.net> Date: Mon, 15 Nov 2010 11:40:06 +0000 Message-ID: From: Tom Evans To: Erik Cederstrand , Dimitry Andric , Giorgos Keramidas , FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Deterministic builds? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 12:04:36 -0000 On Sun, Nov 14, 2010 at 9:13 PM, Sp=C3=B6rlein wrote: > On Sun, 14.11.2010 at 21:57:25 +0100, Erik Cederstrand wrote: >> >> Den 14/11/2010 kl. 21.32 skrev Dimitry Andric: >> >> > On 2010-11-14 21:22, Erik Cederstrand wrote: >> >> I'm curious as to why this might be useful? Would the mtime of the >> >> file not be be sufficient? I can only think of debugging purposes, bu= t >> >> apart from the timestamp, two kernels with the same rev. would be >> >> bitwise identical, >> > >> > This does not have to be the case. =C2=A0For example, if you have have= local >> > modifications, or use different settings in make.conf or src.conf. >> >> In this case the timestamp + rev. is not sufficient to reproduce the ker= nel anyway. You'd need to store externally the non-standard contents of con= f files, local diffs etc. on all your non-standard builds. You could do all= sorts of fun stuff, even fool the rev. number or timestamp if you wanted. >> >> I'm just saying that for the standard user on a standard GENERIC kernel = (and world for that matter) - the revision number should be sufficient for = e.g. filing a PR. If you need the timestamp, there's the mtime. > > It might not be very easy, going from revision to timestamp. It is still > very useful to know the rough timeframe when a kernel was built, as that > might give you the "age" of the source tree. This is of course not a > very good mapping, and the reason we have both the revision number in > there, but also something a human understands. > > If this timestamp must be fixed, my vote would be on using the timestamp > of the svn revision the build was using as a source. But it should be > made clear, that this is then no longer the built timestamp, but the > source repo timestamp. > > Uli > Timestamp of the revision is better than timestamp of the build - it is more than possible that someone could forget to update their sources, and rebuild their kernel and world, giving a recent build timestamp to some code that is actually quite old. This may not be possible with the kernel, but at $JOB we wanted our build system to produce binaries that we could precisely reproduce the source for, so our binaries contain both the revision numbers of the various libraries etc, but also contain any differences that the source files had (we literally add the output of "svn diff" to an object file generated by the Makefile). There are probably nicer ways of doing this with the elf file format, but I don't know them :) The important things for us are that given a binary, you should be able to easily reproduce the source environment that the binary was produced from, and any two binaries produced from the same sources should be identical. Cheers Tom