[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

reproducible builds (bug report #43087)

From: John W. Eaton
Subject: reproducible builds (bug report #43087)
Date: Wed, 27 Aug 2014 17:08:22 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

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

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.

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.


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.

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.

The first case
might be better solved using file hashes, which I think most Linux
distributions already do for the contents of all of their packages. If
the file hashes are not as expected, then show me your
config.log. Does the Windows installer give us a way to verify the
contents of the payload after it has been installed, or can we add a
manifest to it such that it is possible, maybe even make it something
that the user can run in Octave or click on the GUI?

Sure, we could probably do something like that.

Do you agree that the full contents of config.log are not that useful
for builds of Octave that are built by a distributor, because we
already have other ways of seeing/reproducing how it was built? We
really just want to know, are you using one of these known builds of
Octave and has anything been modified since it was installed?

Sure, and I have no objection if you want to drop it from the Debian
package.  But until I have a better solution, I intend to install it
and leave it in the Windows binary package that I distribute.

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.

    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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]