Date: Sun, 19 Jul 2015 10:14:50 -0600 From: Ian Lepore <ian@freebsd.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: Ed Maste <emaste@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, reproducible-builds@lists.alioth.debian.org, Holger Levsen <holger@layer-acht.org> Subject: Re: reproducible builds of FreeBSD in a chroot on Linux Message-ID: <1437322490.1334.381.camel@freebsd.org> In-Reply-To: <20150718180928.GE8523@funkthat.com> References: <201505071122.36037.holger@layer-acht.org> <554B509B.8020608@fuckner.net> <201506162350.11646.holger@layer-acht.org> <CAPyFy2DExDdGf8hN2DNJCSgnP2dj_cLm_TXf1Y8tNJ%2BygvqRzg@mail.gmail.com> <20150718180928.GE8523@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2015-07-18 at 11:09 -0700, John-Mark Gurney wrote: > Ed Maste wrote this message on Wed, Jun 17, 2015 at 16:48 -0400: > > These are used only as user-facing strings for the kern.version sysctl > > and reported by uname. An example kern.version string: > > FreeBSD 10.1-STABLE #28 r280427+86df2de(stable-10): Thu Mar 26 16:07:47 EDT 2015 > > emaste@feynman:/tank/emaste/obj/tank/emaste/src/git-stable-10/sys/GENERIC > > > > >From a technical perspective they're trivially eliminated. There may > > be some 3rd party ports expect the precise format, but probably not > > very many (and they should be fixed, anyhow). There's a much larger > > social issue in convincing the FreeBSD developer community to accept > > their removal, though :-) > > I don't know about others, but IMO, the only useful information there > is the path it was built from... The machine isn't too useful and even > less useful is probably the build user... Maybe on larger installs, > the user/machine makes a difference, but that could be a config option > to include those... > > So my vote is to eliminate user/machine and just leave the path... And > we could just use user@machine to keep the format compatible, but > constant... > If you have a procedure that does builds in a chroot, the path holds no useful information at all, and the user@machine (plus date) is the real information. Obviously to get a single binary file that is bit-for-bit identical to another build, some of this identifying information will have to be scraped off[*], but please leave the choice of what to include or remove up to the user/admin. -- Ian [*] Or we have to be more selective about what "bit for bit identical" means, such as placing variable information that can't be lived without into its own section in the file and have a compare/verify tool that knows how to ignore that section.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1437322490.1334.381.camel>