From owner-freebsd-hackers@freebsd.org Wed Aug 7 16:24:28 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 89730AF1DC for ; Wed, 7 Aug 2019 16:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 463cK764vLz3QHB for ; Wed, 7 Aug 2019 16:24:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x844.google.com with SMTP id y26so88960184qto.4 for ; Wed, 07 Aug 2019 09:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=KSwI6alfRd194gxkmaG1kk+I9U26/37IuXj5dRlnju7BtJ6UrZY8+lRHornhgVPL4o or6umLNauDh9MCLGjzTMq60mq5PxDu+JnqEa9Pddt5AuBjtv5Ti3cTY533Y0nKDF6G3o SC4xy3m/K0/gOKLY9ilKOCvfzVYba9XfO5f0/oMwF+uN2uJ2AjSnCHkvHZopRRg1IlOG C5TOi6uKPcNF0I1sErXlQh7ko+KC7vD6PysgiIXTxkQRZbx6HO53RHLPfggSu0kMT9dy 5UIWhqJsiUJLHqonyqLMNr0qTRdOP4semacgm4snwCy5/hBhjn82vr4BMprfg6IJmAt1 8oog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/Fm0FCS2HN/Egvw1tVv9mTzTn+zuyiqDM0UJqSx95U=; b=IQtVaot6R9y0lXpoSlcDw3i6GRdq8Tx8mMR50cEZkxifAZm5Ttbhy2fmoRxYStuGpm XtVyOriNv0B67eQuVsNwblkQrfxYend9yDZyh7cR8pvNV8xjyZuPDq4+yOEXIaOUMhWl v1xlg/2Cqpk6NroOImAIuHFTMNQx+w0Vg+2fZLK5dHtJigDk40Mo00nOGyHprKh5n64R 7D/yqgF3jfpIOdPpc116aQTOVg4JdK03IRfTdY52Pqtq2Z7XeW8k+RNEZFMYTlLU/ykr nM4/LaYk2smMhf6ylBSvdVpGqlX263ldI8mEdpr2UKXRZqUTNdEc7MnBt1qpTLFU6qD9 0wbQ== X-Gm-Message-State: APjAAAXcNP2iktubLNPvpCQLQrDG3UaUEewaOCD5zU9OQjgakcqtPPYe ZRCl+fsOyMiYlrhC6xJ3VXykQYekcKXtfMD4Klvh9A== X-Google-Smtp-Source: APXvYqwPIS5Fu8qMlm+LvPNDUCqwirihb14S3rYhnkP7sFwj7QAWzcdjATO32i8RnBDgu5xmXkNYSo0ZL3aVlVU9gd8= X-Received: by 2002:ac8:2baa:: with SMTP id m39mr9005043qtm.242.1565195066321; Wed, 07 Aug 2019 09:24:26 -0700 (PDT) MIME-Version: 1.0 References: <201908030106.x7316Ibx078529@repo.freebsd.org> <20190806165614.GA41295@FreeBSD.org> <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> In-Reply-To: <4e4d30b2-4801-2e53-6f26-49cb350445ec@FreeBSD.org> From: Warner Losh Date: Wed, 7 Aug 2019 10:24:15 -0600 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: John Baldwin Cc: Glen Barber , svn-src-head , "freebsd-hackers@freebsd.org" , svn-src-all , src-committers , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 463cK764vLz3QHB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=KSwI6alf; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::844) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.57 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.980,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[9]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.990,0]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[4.4.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-0.61)[ip: (2.49), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:24:28 -0000 On Wed, Aug 7, 2019 at 10:01 AM John Baldwin wrote: > On 8/6/19 9:56 AM, Glen Barber wrote: > > On Sat, Aug 03, 2019 at 01:06:18AM +0000, John Baldwin wrote: > >> Author: jhb > >> Date: Sat Aug 3 01:06:17 2019 > >> New Revision: 350550 > >> URL: https://svnweb.freebsd.org/changeset/base/350550 > >> > >> Log: > >> Flip REPRODUCIBLE_BUILD back to off by default in head. > >> > >> Having the full uname output can be useful on head even with > >> unmodified trees or trees that newvers.sh fails to recognize as > >> modified. > >> > >> Reviewed by: emaste > >> Differential Revision: https://reviews.freebsd.org/D20895 > >> > > > > I would like to request this commit be reverted. While the original > > commit message to enable this knob stated the commit would be reverted > > after stable/12 branched, I have seen no public complaints about > > enabling REPRODUCIBLE_BUILD by default (and quite honestly, do not see > > the benefit of disabling it by default -- why wouldn't we want > > reproducibility?). > > > > To me, this feels like a step backwards, with no tangible benefit. > > Note, newvers.sh does properly detect a modified tree if it can find > > the VCS metadata directory (i.e., .git, .svn) -- I know this because > > I personally helped with it. > > > > In my opinion, those that want the non-reproducible metadata included in > > output from 'uname -a' should set WITHOUT_REPRODUCIBLE_BUILDS in their > > src.conf. Turning off a sane default for the benefit of what I suspect > > is likely a short list of use cases feels like a step in the wrong > > direction. > > My arguments for flipping this in head (and head only) are that the data > provided in uname -a when this is disabled is useful for development, and > that in head we do tailor settings towards development (e.g. GENERIC in > head vs GENERIC in stable). > > The logic to handle modified trees has an inherent assumption that I think > is false, at least for my workflow and I suspect many others. I do builds > and tests of kernels on separate machines (VMs or bare metal) from where I > use VCS to manage sources so that a kernel crash doesn't toast my source > tree. The trees are then shared to the build/test machines via NFS. As > a result, the build/test machines are not always able to detect that the > tree is modified either because a subset of the checkout is exported via > NFS, or the VCS tool isn't installed on the build/test machines because > they are generally barebones systems with only a base installed. This > does mean that flipping the knob off doesn't provide all of the same info, > but it does provide the path, and the path matters because 'kgdb -n last' > uses it, and because if you use separate directories for separate projects > (e.g. git worktrees), then the path tells you which test kernel you booted. > (It is not uncommon for me to have several test projects in flight on a > single test machine for different branches.) > > In the original discussion on arch, we collectively recognized that > developer builds vs release builds were different and needed different > defaults. The compromise reached at that time was to depend on the VCS > to detect developer builds to choose the policy. What I have found is that > in practice for at least my workflow that doesn't actually work. I posit > that the majority of kernels built from head are developer builds, not > releases, and that the default should cater to that. You could also always > patch release.sh to set WITH_REPRODUCIBLE_BUILD in the environment which I > think would give a more accurate sense of when builds are releases or not. > > However, I will yield to whatever the consensus is. > I'm with John here: the dirty tree stuff is too fragile for the diversity of development environments that are typical on -current, but not typical on -stable. We should not revert this. Warner