From owner-freebsd-arch@freebsd.org Thu Aug 8 03:02:47 2019 Return-Path: Delivered-To: freebsd-arch@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 D0DBBC1A97 for ; Thu, 8 Aug 2019 03:02:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 463tTf6jQBz3GSd for ; Thu, 8 Aug 2019 03:02:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id x22so17256378qtp.12 for ; Wed, 07 Aug 2019 20:02:46 -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=KA6m24ZQye6qC8C2hA5hJASCEDDlYCAJrtZTX5hwTB0=; b=ezJPTwdlKA++UDboM/plaGm6LSrehUrDSAdmuUwywJa6/wfgedcETUkpWyQbVHBDJm Qr3NRlFUDC1n00pUvZFbfmxAMS0VH5ExM5SxqSariD9k3/tY6Ed+DdjRfpll5oOvOtwM ZlJCOFJD+9uGmaYnmXOhFoGGxP5765OaBOyuA1MiBbQR+n0LGDiNFdA7iirNdKM/fJAu g9gpPl3KBJAL/OsD4LGWLpFoQRgiRfNLtqodD2SYgQEI5YCsRL7iDayuNO5bCxcmEkHO nHSUfLjSwmz6EBN6kW5CzTE1p4gKvYO+oOFhJgZquiST5TRd7KKHyVhbwnC32vcjwiG3 lpHA== 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=KA6m24ZQye6qC8C2hA5hJASCEDDlYCAJrtZTX5hwTB0=; b=Ke9TLU3ZTaJJrreQcioEMqyawKVab/0ksjKqZ4bZKvAJyCpc3oMeAx0nsPTNAgwaOg nhASU+NuSGZn53ZwMJNVDwhGVxZiIcZQlgGi2vjgRbEbgvtVgKwSPyARvuawYcgGR2MH PJlsXgg8n8wCvqaqAvMH43TcLlg2sRhxnugG+XqHf5BoUnik3j5ZZEblfkoiQeGCvbtq mBOfa1YkAXsBjm2l32ImQOUwFJtgZThQrX63boAKTx8bl8SyE20yRGFCMXcMkyHnAovD ZxN2McERFDi5Qhe9RZNdu/yVh0/IgQh6w261TNEusbC3OVvpM+TgCZl7ylO3LmpbaNP4 ADKA== X-Gm-Message-State: APjAAAWHBwy6vMojlEsxrjIIAQtXdliOqES3TXd4YvGEeqDpRBWsKSp2 rnWPjuX+SZCQGK+i2deshCvQ9IHIZ/lGLwws69fCQAXyXiY= X-Google-Smtp-Source: APXvYqx47N127d5/jJwEfHIZfaCyt5oHKQTKwVK8c/pigI7faqj63PwySOsytKkoam7oR5y0vfEf9BYVyLiih6vcjKQ= X-Received: by 2002:ac8:244f:: with SMTP id d15mr10659552qtd.32.1565233365135; Wed, 07 Aug 2019 20:02:45 -0700 (PDT) MIME-Version: 1.0 References: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org> <201908080247.x782lL31090500@gndrsh.dnsmgr.net> In-Reply-To: <201908080247.x782lL31090500@gndrsh.dnsmgr.net> From: Warner Losh Date: Wed, 7 Aug 2019 21:02:31 -0600 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" Cc: John Baldwin , freebsd-arch@freebsd.org, tech-lists X-Rspamd-Queue-Id: 463tTf6jQBz3GSd X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=ezJPTwdl; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[4.3.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(-2.99)[ip: (-9.45), 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-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 03:02:47 -0000 On Wed, Aug 7, 2019, 8:47 PM Rodney W. Grimes wrote: > > On 8/7/19 1:50 PM, Rodney W. Grimes wrote: > > >> Hello, > > >> > > >> On Tue, Aug 06, 2019 at 04:56:14PM +0000, Glen Barber wrote: > > >> > > >>> 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. > > >> > > >> Well, my use case is that I have some machines that follow 12-stable. > > >> > > >> I'm not a developer. But I keep an eye on things like security > bulletins > > >> etc and when they come out it usually gives something like 'affecting > > >> 12-STABLE prior to r something like that. And I can easily > look > > >> at uname -a to see if this or that 12-stable machine needs to be > patched > > >> or whatever. That is, if reproductible_build is turned off. (or > > >> without_reproductible_build is turned on) > > >> > > >> Or if I mail to stable@ asking for help I'll want to say *exactly* > what > > >> sources I've built from. And sometimes someone will say "oh that was > > >> fixed after r" and so I'll grab sources after that > revision > > >> if I can and fix the problem. > > >> > > >> But like I say I'm not a dev. I'd guess, though, that lots of > non-devs > > >> use the revision info if they follow -stable, so if I'm right in > thinking > > >> this, it'd be a short list of use cases but lots of affected people. > > >> > > >> unless there's another way to get the svn rev number? > > >> > > >> Why turn off this functionality by default? > > >> -- > > >> J. > > > > > > Actually you have a very good point here. > > > Let me raise the issue, the rXXXXXX is infact reproducible, why is > > > that being excluded from reproducible builds? If I build from the > > > same source at the same version I get the same rXXXXX string in > > > the resulting file. This is reproducible. > > > > > > So WHY are we excluding rXXXXXX from the reproducible build? > > > > We don't. The svn revision is present in uname -a even for reproducible > > builds. > > I think I know what it is that IS removed, it is the path to > the kernel build, and the host, that is what I am missing. > That data is rather critical to me, as it is I believe your > objection too. > > Again, I think if we split this into kernel/userland we can > have it kernel off, userland on in head and I think that > takes care of everyones complaint about wanting it turned off > in head, and keeps the state that has those of us wanting it > turned on in head. > > Am I correct in that your main reason for wanting to have this > off in head is to get the kernel meta data for the path to the > kernel John? If that is the one use case in head can we just > turn it on for the kernel build only? > I think that's too much complication for too little benefit. It's a development system, so there is little benefit to making things reproduction... almost none. If we want to build packages for current, those few machines can make it reproducible. It's no different than WITNESS or malloch checking... Warner > John Baldwin > -- > Rod Grimes > rgrimes@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >