From owner-freebsd-arch@freebsd.org Wed Aug 7 21:08:28 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 8C9FDB7EC4 for ; Wed, 7 Aug 2019 21:08:28 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (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 463kcq58X2z4LYg for ; Wed, 7 Aug 2019 21:08:27 +0000 (UTC) (envelope-from delphij@gmail.com) Received: by mail-ot1-x342.google.com with SMTP id l15so52757411oth.7 for ; Wed, 07 Aug 2019 14:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CmJwj/wnplZt9NdsZr5NOIv7Ie6P1+Bm9d/Xa2XSOjc=; b=RJR3wW5f2cj8FTcl3AU2pR/y47gOPwYBFxx0MSc+Vc36XWDDXLXdwOrfXqzJc1RCXH S/bvBY3n8Yx//k9NwXeUvM/qzd8rMf7aj4eTrqSk3J5LbZFcL4cK0jgaZTRoUymJtvEz e1MB8vH1ZLEs9+rXEr/pblB/i/zeMkOu+nrwAC7Dg7byJMeD0fnMpSgUVs7KQMjzaW/C HfhDkjxqSdlgBR2T6Q/C1fPS9YXfpWp4IigsV/4Y5tECww/fy1GMI3XAQc4AsmAwY2Un umkWQnmureY7q8RKQffR3agxEphcWxt58kuW/jOsEiff6Z5GKhfPXmXW5/U4YhGEXxtV 4txw== 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=CmJwj/wnplZt9NdsZr5NOIv7Ie6P1+Bm9d/Xa2XSOjc=; b=Nx2LIYA7a83jmZJteoJ3ynfwzwm2kOtr/UWg5tWkj6ocZAbXi21wcGNHgjnlNmhQBR Z+rHxXsRKjlWydVU6gxCLIo9xz+T9hD0YYdEmUeMN7hKuJdsyYLzrLDqwbzmSAGK1SVA aM/jPAHy6HQC0a0kC3MXozxDeihk0rXdLhxv05cT3jkU8Ziy41Izxyg30Fvv0UdHaKIL x1VNImLyjNNGlPilPUwvaza/tTpr2+rxDql0HOdVAM4ub9Jow7TG/FO9QHre4oUllERT aO/84nsvhwlzdC/uu9anjfzTn/ySFAicW0iX7D3ebgpvyUe9fuJzVJdOR2wJm6s0Rohx F7qQ== X-Gm-Message-State: APjAAAVXJTh9JNwsvPk1B6yRNehz9F7nz3M3B6BgymUPAoN8yDEZUm3U PX+wIJ3KhJiLzECo+cfzh10GaslQnGKmMymf+v4= X-Google-Smtp-Source: APXvYqwEhjyFyiycGfl3BqADNuEhFqSR0Va4ayxw0Ww6nEFA4axj0KmbXAZd/IcjaUSGiYF8We4yTRIlBruJRqgdEmI= X-Received: by 2002:a05:6808:a04:: with SMTP id n4mr109927oij.40.1565212106244; Wed, 07 Aug 2019 14:08:26 -0700 (PDT) MIME-Version: 1.0 References: <20190807201448.GA42725@bastion.zyxst.net> <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> In-Reply-To: <201908072050.x77Ko5QD089298@gndrsh.dnsmgr.net> From: Xin LI Date: Wed, 7 Aug 2019 14:08:14 -0700 Message-ID: Subject: Re: svn commit: r350550 - head/share/mk To: "Rodney W. Grimes" Cc: tech-lists , freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 463kcq58X2z4LYg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RJR3wW5f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of delphij@gmail.com designates 2607:f8b0:4864:20::342 as permitted sender) smtp.mailfrom=delphij@gmail.com X-Spamd-Result: default: False [-2.98 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[1]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.58), ipnet: 2607:f8b0::/32(-3.03), asn: 15169(-2.43), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.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]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] 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: Wed, 07 Aug 2019 21:08:28 -0000 On Wed, Aug 7, 2019 at 1:50 PM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> 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? > Because svnversion returns the base revision (the repository revision as of last checkout) instead of the 'COMMITTED' revision (the last commit revision of the working copy that was checked out), and it means for the same set of source, there can be multiple possibilities, making it no longer reproducible? I haven't dig deep on this topic, but it seems that parsing 'svn info' output would solve it (by using "Last Changed Rev:" value). This issue do not exist on git.