Date: Thu, 3 Dec 2015 18:00:16 -0800 From: NGie Cooper <yaneurabeya@gmail.com> To: Ed Maste <emaste@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Removing build metadata, for reproducible kernel builds Message-ID: <CAGHfRMC7RtoEe-Mu7nLSnPd-bsg7WXbhVK6QM6mhkZO0DBfCwg@mail.gmail.com> In-Reply-To: <CAPyFy2CZYV%2B-5pDQjCA4Btct1VZUyEQUuL2iU1z07Ff-n2Y9Hg@mail.gmail.com> References: <CAPyFy2AYeN9XNg=b0=JMWDC9ctWarfiZ-5zQorOPhguDJgxYpg@mail.gmail.com> <D9AF1C8B-431C-4359-988F-FDEEF8FAD981@bsdimp.com> <CAPyFy2CZYV%2B-5pDQjCA4Btct1VZUyEQUuL2iU1z07Ff-n2Y9Hg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 2, 2015, at 23:55, Ed Maste <emaste@freebsd.org> wrote: On 3 December 2015 at 05:51, Warner Losh <imp@bsdimp.com> wrote: I noted in the review that I don=E2=80=99t like the default being no. I also don=E2=80=99t like that we=E2=80=99re growing lots of different knob= s that need to be set to get a repeatable build. Let=E2=80=99s have one, or barring tha= t, 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 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 in effect. I don't follow -- other than the build iteration number (which I indeed missed), it is all gone. I personally like being able to debug when user A builds on machine X vs user B on machine Y =E2=80=94 because it's helped me find issues with peopl= es=E2=80=99 build environments in the past where I could have ended up pulling teeth. I think the single-knob src.conf knob approach is wrong though. Why not document how to do it with build(7) and tweak newvers.sh to do this (which drives this to begin with)? That would generalize the solution, accomplish this goal, and help $work accomplish this goal, because right now we ($work) hack newvers.sh in order to change the version information to brand the product appropriately, instead of build upon existing infrastructure, as the existing infrastructure is not flexible/documented/static. Thanks, -NGie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGHfRMC7RtoEe-Mu7nLSnPd-bsg7WXbhVK6QM6mhkZO0DBfCwg>