Re: reproducible builds (bug report #43087)

[Mike Miller]

On Wed, Aug 27, 2014 at 17:08:22 -0400, John W. Eaton wrote:
> From a discussion in bug report 43087
> (https://savannah.gnu.org/bugs/index.php?43087), Mike Miller wrote:
> 
> >Ok, first I'll explain where I was coming from and why this is
> >harmful. The perspective is deterministic or reproducible builds, so
> >given a source snapshot that has not changed, the output should look
> >the same. I should be able to execute the build procedure on a given
> >platform with the correct set of build dependencies, and the output
> >should look bit-identical with what I got last week, or even with what
> >someone else on a different machine got, also with the same exact
> >build dependencies. MXE is actually a really good example, since it
> >encodes exact details about every single dependency. So given a
> >snapshot of MXE, everybody's resulting installer should look
> >bit-identical.
> >
> >So you could argue that config.log looks identical each time, but keep
> >in mind that it includes things like the hostname, the build
> >timestamp, the user's PATH, the user's source/build directories. If I
> >build mxe-octave in /home/mike and you build it in /home/jwe, should
> >we not still end up with the same binary? If we do have otherwise
> >reproducible builds, config.log is still not deterministic and all
> >these variables are irrelevant noise.
> 
> OK, I agree these are reasonable goals.  I'm sure all the dependencies
> that are required by Octave aren't there yet.

Fair point, I've only looked at Octave itself for now and not the entire
contents of an mxe build of Octave and all dependencies. I was mainly
looking at obvious things that Octave's build is doing intentionally
that unfortunately make the build output non-deterministic.

> >It sounds like there are two main things you want to capture with the
> >config.log. First, is this from some well-known official distribution,
> >let's say, is this Octave as built by me or by foo. The second is how
> >exactly was Octave built.
> 
> Yes.
> 
> >Well, if we know the first, we automatically know the second.
> 
> I do if I still have the build around.  Which of course you could
> argue I should if I'm distributing and supporting it.

Or if you at least have the information needed to reproduce it :) For
the case of mxe, maybe I'm wrong, but isn't that just the mxe hg
revision and the command line used to build it? Isn't mxe completely
self-bootstrapping / self-contained?

> >IOW are
> >not the full contents of config.log mainly useful for getting
> >information from people who build Octave themselves?
> 
> Sure, that's also a reason that I'd like to be able to ask for
> config.log, because I might want to help someone who is having trouble
> even though they are using a binary that I didn't build.  Perhaps a
> bug is discovered in their build that I haven't noticed but would like
> to fix anyway and config.log might help me do that.

Yeah, that use case makes complete sense. I guess I'm just wondering if
we can separate the logging from the built Octave installer at some
point in the future. Maybe it will just take some time and maturing of
the process.

[...]

> >A couple possible compromises:
> >
> >    configure option to disable installing config.log? Default would
> >    be no, so self-built users would have it by default, distributions
> >    would have to know to turn it off. Not great, but I could live
> >    with it.
> 
> I wouldn't object to having the default the other way.

I guess you're implying that if Octave defaulted to not install
config.log, mxe-octave would still enable it anyway by default, so for
mxe builds it would always be there. That's probably fair for now.

> >    create a sanitized version of config.log, or a configure summary
> >    file that could be installed that would only represent the things
> >    that are indeed constant from build to build? Is there some
> >    minimal set of information that you would still consider useful
> >    that would not include machine-specific details or timestamps or
> >    every single test compilation and error message?
> 
> The interesting information to me is often the test failures,
> especially in the case when they say "X doesn't work" and I find that
> Octave was not configured to use some library and then I want to know
> why that happened.  Obviously this would be a situation in which I
> didn't build the binary but wanted to help diagnose the problem anyway.

Yeah, that definitely makes sense for the "debugging an unknown build"
use case.

I realize that this has some shades of crazy in it. And we may never get
to a point where we have fully deterministic builds. But I just wanted
to address the easy ones that I saw with some simple grepping in my
install path. Thanks for the feedback so far.

-- 
mike

signature.asc
Description: Digital signature