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

 
 

bug #43087: improve support for reproducible builds

Submitter:  Mike Miller <mtmiller>
Submitted:  Wed 27 Aug 2014 07:51:22 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  mtmiller
Originator Name:  Open/Closed:  * Closed
Release:  * 3.8.2 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group Member
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>
Group 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>
Group 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>
Group Member
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>
Group 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>
Group Member

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-24 mtmiller StatusNone Fixed
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code