[Top][All Lists]

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

Re: reproducible builds (bug report #43087)

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

On 08/27/2014 10:26 PM, Mike Miller wrote:
On Wed, Aug 27, 2014 at 17:08:22 -0400, John W. Eaton wrote:

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.

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?

Ideally, yes. And for Windows, I think everything is pretty much self contianed. But I'm not sure we are completely there yet for "native" builds. We don't build X11 or OpenGL (mesa?) libraries yet. And for all systems, there may still be some build tools that we expect to get from the local system (make, for example, though there is also a script provided to download and build a given version of make for systems that don't have a recent enough version to handle the mxe-octave Makefiles). So people may still get different results on different build systems. I'd like to move toward eliminating those differences, but I think we still have some work to do.

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.

Yeah, config.log is far from the perfect collection of information, even for what I'm trying to use it for, but it can help, which is why I decided to start installing it. I certainly wouldn't object to something better.

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.



reply via email to

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