Date: Wed, 7 Aug 2019 19:47:21 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: John Baldwin <jhb@FreeBSD.org> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, tech-lists <tech-lists@zyxst.net>, freebsd-arch@FreeBSD.org Subject: Re: svn commit: r350550 - head/share/mk Message-ID: <201908080247.x782lL31090500@gndrsh.dnsmgr.net> In-Reply-To: <9c03a13c-8eed-06cb-bdef-faa1de8ea272@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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<number> 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<suchandsuch>" 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? > John Baldwin -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201908080247.x782lL31090500>