From owner-freebsd-arch@freebsd.org Thu Dec 3 21:45:18 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68D8AA40FFA for ; Thu, 3 Dec 2015 21:45:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 387B01BAD for ; Thu, 3 Dec 2015 21:45:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 3 Dec 2015 21:45:41 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id tB3Lj9sS019950; Thu, 3 Dec 2015 14:45:09 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1449179109.6214.19.camel@freebsd.org> Subject: Re: Removing build metadata, for reproducible kernel builds From: Ian Lepore To: Justin Hibbits Cc: Warner Losh , Ed Maste , "freebsd-arch@freebsd.org" Date: Thu, 03 Dec 2015 14:45:09 -0700 In-Reply-To: References: <1449177325.6214.14.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 21:45:18 -0000 On Thu, 2015-12-03 at 15:35 -0600, Justin Hibbits wrote: > On Thu, Dec 3, 2015 at 3:15 PM, Ian Lepore wrote: > > On Thu, 2015-12-03 at 12:53 -0700, Warner Losh wrote: > > > On Thu, Dec 3, 2015 at 12:55 AM, Ed Maste > > > wrote: > > > > > > > On 3 December 2015 at 05:51, Warner Losh > > > > wrote: > > > > > > > > > > I noted in the review that I don¢t like the default being no. > > > > > > > > > > I also don¢t like that we¢re growing lots of different knobs > > > > > that need > > > > > to be set to get a repeatable build. Let¢s have one, or > > > > > barring that, > > > > > let¢s have one that sets all the sub-knobs. > > > > > > > > My hope is that we'll have a reproducible build by default, and > > > > that > > > > *no* knobs need to be set. That's what I intend with my patch. > > > > I can > > > > rename the knob to WITH_/WITHOUT_REPRODUCIBLE_BUILD though if > > > > that's > > > > generally desired. If there's a consensus to default to > > > > including the > > > > metadata I'm fine with setting it in make release. > > > > > > > > > I think this an unwise decision in the current form suggested. > > > The kernel > > > metadata has saved my butt enough times I really don't want to > > > see it > > > go by default. But see below for a reasonable (imho) middle > > > ground that > > > would be a good default. > > > > > > > I'm curious why anyone wants this enabled by default, like... are > > we > > missing something? Does it improve freebsd-update behavior maybe? > > > > If it's just for some general "reproducibility is good" philosophy > > then > > I would counter with "information is even better, so don't throw it > > away without a good reason." > > > > Reproducibility is good for some people, and completely useless for > > others, and the people who need it aren't going to mind turning on > > a > > knob or two to get what they want. > > > > > > > > > > I think that host and path are more worthless than date and > > > > > time > > > > > in many environments. Who builds it likewise. Those are all > > > > > things > > > > > that are likely to change between builds, yet change the > > > > > kernel > > > > > image. I¢d rather see it all gone when this option is in > > > > > effect. > > > > > > > > I don't follow -- other than the build iteration number (which > > > > I > > > > indeed missed), it is all gone. > > > > > > > > > > Yea I was reading things backwards. > > > > > > In the review, I suggested that if you've modified the tree > > > (which the SCM > > > will tell you), then do the old format to preserve useful > > > metadata that's > > > really really needed and if not to use the shorter version. When > > > you've > > > modified the tree, reproducible builds aren't a concern at all. > > > > > > > How are you going to determine what consitutes a modified tree? > > What > > you think of as modifications may be what I call my baseline > > version. > > > > -- Ian > > svnversion resulting in a 'nnnnnnM'? > > - Justin > svnversion isn't going to be able to return anything useful inside one of my build sandboxes in which there is no hint of svn anything. -- Ian