bugGNU Octave - Bugs: bug #43087, improve support for reproducible...

 
 

bug #43087: improve support for reproducible builds

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Wed 27 Aug 2014 07:51:22 AM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Feature Request
Status: FixedAssigned to: Mike Miller <mtmiller>
Originator Name: Open/Closed: Closed
Release: 3.8.2Operating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Tue 24 Feb 2015 04:36:33 AM UTC, comment #5:

I pushed the last fix for this one for the 4.0 release:

http://hg.savannah.gnu.org/hgweb/octave/rev/07b970d6cdfe

The config.log is now not installed by default, but use configure --enable-install-build-logs to continue install it. This configure option can be added to mxe-octave if you want to make that the default (as we discussed on the maintainers list I think).

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 27 Aug 2014 08:54:57 PM UTC, comment #4:

I'm opening a thread on the mailing list because it will be easier for me to quote and reply to specific points.

John W. Eaton <jwe>
Project Administrator
Wed 27 Aug 2014 06:57:41 PM UTC, comment #3:

PMFJI

Maybe this is something for the maintainers list?

While testing 64-bit MXE builds I sometimes see error messages with paths from the mxe build environment. Well, looks handy to me, just like John mentions, even if I run Octave on a totally different operating system.

But if I am not mistaken (I'm by no means a C++ expert) I also see path info in error messages relating to modules in dependency libraries (e.g., the HDF5 library); i.e. these look like machine dependent debug symbols (?) that seem to relate to the linking stage; or library building stage.

If that is true, am I right to surmise that making a reproducible build should include stripping away all debug info as well?

If I am wrong: sorry for the noise :-)

Philip Nienhuis <philipnienhuis>
Project Member
Wed 27 Aug 2014 02:37:25 PM UTC, comment #2:

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.

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. IOW are not the full contents of config.log mainly useful for getting information from people who build Octave themselves? 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?

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?

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.
  • 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?

I have some Debian specifics for the Debian bug so I'll comment there separately.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.
Wed 27 Aug 2014 11:28:43 AM UTC, comment #1:

I made the change to install config.log as a debugging tool. Installing it seemed to me like a reasonably good way to get detailed configuration info from users who have received binary versions of Octave (like the mxe-octave builds) and who have essentially no chance of rebuilding Octave from source on their own. With the config.log info, I have a chance of fixing a bug that would otherwise be almost impossible without trying to reproduce the build myself, and even if I tried to do that, I would probably end up with something different, not exactly what they have. If I can ask them to provide config.log, then I can probably also tell whether the version of Octave that they are using is one that I built or something else. How is it harmful to include that file in the distribution, just as extra info for the purposes I'm describing?

John W. Eaton <jwe>
Project Administrator
Wed 27 Aug 2014 07:51:22 AM UTC, original submission:

Inspired by a discussion of reproducible builds in Debian (see https://wiki.debian.org/ReproducibleBuilds), I've looked for and found a few places in the Octave build system that intentionally encodes variable information into the build output that depends on time stamps, file paths, and host-specific information. From a reproducible build perspective, these should all be removed so that given the same original source, the same result comes out each time.

Some easy pickings:

  • config.log - so bad, why is this now being installed in >= 3.8.1?
  • doc-cache - fix the header to just say "created by Octave VERSION" without any timestamp

Some further/harder changes:

  • Timestamps are stored in PDF and PS versions of the manuals
  • Timestamps are stored in doc-cache files created when pkgs are installed, could be solved in pkg similarly to Octave's doc-cache above

There may be others, but these are the obvious ones I've found so far.

Mike Miller <mtmiller>
Project AdministratorIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 24 Feb 2015 04:36:33 AM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1