Bug 11241

Summary: binary reproducibility: .pyc files contain timestamps
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Juro Bystricky <juro.bystricky>
Component: coreAssignee: Juro Bystricky <juro.bystricky>
Status: RESOLVED FIXED QA Contact:
Severity: enhancement    
Priority: Medium+ CC: joshuagloe, meta.mr.watcher, meta.watcher, randy.macleod
Version: 2.3   
Target Milestone: 2.4 M3   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know
Attachments:
Description Flags
diffoscope output (HTML format)
none
diffoscope output (text format) none

Description Juro Bystricky 2017-03-24 16:48:02 UTC
Created attachment 3671 [details]
diffoscope output (HTML format)

When binary comparing two python packages in "deploy/deb" folders,
ie:
/data/master-master/poky/build-repro1-master/tmp/deploy/deb/core2-64/python-curses_2.7.13-r1_amd64.deb  
/data/master-master/poky/build-repro2-master/tmp/deploy/deb/core2-64/python-curses_2.7.13-r1_amd64.deb

they show binary differences. Using diffoscope (resulting files attached), the difference can be shown to be caused by a time stamp in .pyc header.
To achieve a true binary identical files, this stamps should be identical.
I speculate the stamps correspond to the date/time when the .pyc was created/compiled. I believe the stamp is needed to detect the code needs to be recompiled if the python source code changes. One way to fix this is ensure the stamps correspond to the time/date of the source code, not the time of the compilation. 

stamp1 (0x58d40f23): Thu Mar 23 11:08:35 PDT 2017
.deb file: Mar 23 11:09

stamp2 (0x:58d41807) Thu Mar 23 11:46:31 PDT 2017
.deb file:  Mar 23 11:47

With some minimal requirements for binary reproducibility, core-image-minimal debian packages are distributed roughly like this:

Different: 242
Same: 3617
Total: 3859

Once the above time stamp issue is addressed, I estimate additional ~130 packages would also binary identical.
Comment 1 Juro Bystricky 2017-03-24 16:48:58 UTC
Created attachment 3672 [details]
diffoscope output (text format)
Comment 2 Juro Bystricky 2017-03-24 17:03:25 UTC
Another possible solution would be not to include .pyc files in the packages at all.
Comment 3 Joshua Lock 2017-03-30 14:42:16 UTC
There's an upstream bug and an initial set of patches:

https://bugs.python.org/issue29708
https://github.com/python/cpython/pull/296
Comment 4 Juro Bystricky 2017-03-31 21:18:23 UTC
Just FYI, the patch is for Python3, I doubt there will be a backport to 2.7.
AFAIK we will need it, as for example in core-image-minimal we have only python2.7 modules.
But it should be relatively easy to backport.
Comment 5 Joshua Lock 2017-04-03 09:37:42 UTC
(In reply to comment #4)
> Just FYI, the patch is for Python3, I doubt there will be a backport to 2.7.
> AFAIK we will need it, as for example in core-image-minimal we have only
> python2.7 modules.
> But it should be relatively easy to backport.

Don't be so sure, see the reproducible.patch in:
https://build.opensuse.org/package/rdiff/devel:languages:python:Factory/python?linkrev=base&rev=203
Comment 6 Joshua Lock 2017-04-03 09:39:29 UTC
There might not be an official backport of the patch, but the patches author backported it to 2.7 for Suse's use (it does look like it was trivial).

As an aside we're looking at dropping Python2 from default images in the YP 2.4 timeframe, but that doesn't mean we shouldn't make python2 reproducible if we can.
Comment 7 Juro Bystricky 2017-04-03 18:07:44 UTC
Seems both patches are going to be upstreamed. Should we wait for new python releases or patch the python recipes meanwhile?
Comment 8 Juro Bystricky 2017-05-06 22:13:30 UTC
I will test the patches.
Comment 10 Juro Bystricky 2017-07-19 17:06:40 UTC
will be send to the mailing list as a part of "reproducible binaries" patch set.