Skip site navigation (1)Skip section navigation (2)
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>