From owner-freebsd-arch@freebsd.org Thu Dec 3 22:04:14 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 74A26A402FF for ; Thu, 3 Dec 2015 22:04:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 19ADF155A for ; Thu, 3 Dec 2015 22:04:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by qgcc31 with SMTP id c31so73029464qgc.3 for ; Thu, 03 Dec 2015 14:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ro7MzqBDqjoZNZ5SqyOw0Yg+vJ5lPck7HdnrVbyKgmQ=; b=pEIjUhAlQdvI8HeABTt/1SWGqQQm+1aAWgSP2mWvc5rCzzaDBRyH06nG7EAVUgVRwP YmqGO2vXnsy3+v3l+mciyJ0LTX+fV02tGaoeTPYwaWKgKGT0ODUFfYssh1NYcEEl/+U/ Nk9F7NLKA9MWr0NMmeKnYy6rlt/jiWGQRUXiDHEV/1+9dSk+5mJQP5WpYUbJqNSAwv9k RPD4+SlRBdd1Q5ARTPFlp64x5TLbxo2GpIDEpR0VT4tw01PtqBDzBfublq59H+kaNW1u Qmy8hmrwjUtSo4q/FWFUWgS8BofvKPdo4XMJ7DHOARRwHFob9xggw7Yzj9axszREj4qI mNgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ro7MzqBDqjoZNZ5SqyOw0Yg+vJ5lPck7HdnrVbyKgmQ=; b=BCHWC4oozvuQLmHNkXMNihNVAEigrwm6hI176hNFlT4BTZZRUuDKL6Q65d/bag/GDd 7UM0OfqkMJKL2ZeSOX9Q3zGKRGm23n3OdGiPgseZBk54QgcexknfdCbt7jicLZytWXT9 JTda3QwYHI6ggaOVaMR7bAsQZ/OH2DNmkXQWet0BfVU/7wn0CzrlBAX+7F4vWBUCMxxn CzDkH+8brvIkcWmWG1AuWk2k17QU4gEMybcRU1imvkMWLd3N1clVSMgUJDTANMxe1ywQ sq+fhURvAsebQGqmckTKMYMxL87QPlu2UeZZh1JYFt1DzbSeT6kMYIysPrWP3AAfnL1V b8Bg== X-Gm-Message-State: ALoCoQnnYtw5LvOZxqVGRv97ngWnV9Zkxy8u6yx1gQda30t0vVj74cN1gaK2eNC3rzG+DB0pvq4C MIME-Version: 1.0 X-Received: by 10.140.141.138 with SMTP id 132mr15018273qhn.74.1449180253172; Thu, 03 Dec 2015 14:04:13 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.27.181 with HTTP; Thu, 3 Dec 2015 14:04:13 -0800 (PST) X-Originating-IP: [192.55.54.58] In-Reply-To: <1449179109.6214.19.camel@freebsd.org> References: <1449177325.6214.14.camel@freebsd.org> <1449179109.6214.19.camel@freebsd.org> Date: Thu, 3 Dec 2015 15:04:13 -0700 X-Google-Sender-Auth: owxJ0heKNfijTW2hTmgp1ez7WGU Message-ID: Subject: Re: Removing build metadata, for reproducible kernel builds From: Warner Losh To: Ian Lepore Cc: Justin Hibbits , Ed Maste , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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 22:04:14 -0000 On Thu, Dec 3, 2015 at 2:45 PM, Ian Lepore wrote: > 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=E2=80=99t like the default bei= ng no. > > > > > > > > > > > > I also don=E2=80=99t like that we=E2=80=99re growing lots of di= fferent knobs > > > > > > that need > > > > > > to be set to get a repeatable build. Let=E2=80=99s have one, or > > > > > > barring that, > > > > > > let=E2=80=99s 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=E2=80=99d rather see it all gone when this option is i= n > > > > > > 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. > Then, in my proposal, you'd get the 'reproducible' format. We already don't include the SVN info in this case. Perhaps this isn't desirable for you, but it's my proposal and my suggestion and I'd welcome comments on it. Warner