From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: bug#22533: Python bytecode reproducibility Date: Sat, 03 Mar 2018 23:37:29 +0100 Message-ID: <87606c23bq.fsf@elephly.net> References: <20160202051544.GA11744@jasmine> <87bmqfu44s.fsf@fastmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1esFn3-0007jn-Sc for bug-guix@gnu.org; Sat, 03 Mar 2018 17:38:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1esFn0-0002ZK-OM for bug-guix@gnu.org; Sat, 03 Mar 2018 17:38:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:35390) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1esFn0-0002ZE-Hn for bug-guix@gnu.org; Sat, 03 Mar 2018 17:38:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1esFn0-0007ck-Bq for bug-guix@gnu.org; Sat, 03 Mar 2018 17:38:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87bmqfu44s.fsf@fastmail.com> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Marius Bakke Cc: 22533@debbugs.gnu.org Hi Guix, Marius Bakke writes: > It would be great to revive this longstanding bug! Indeed. Here=E2=80=99s another attempt. As far as I understand, the timestamp in t= he pyc files only affects the header. Up until Python 3.6 (incl) the header looks like this: magic | timestamp | size Since Python 3.7 the header may either contain a timestamp or a hash: magic | 00000000000000000000000000000000 | timestamp | size magic | 00000000000000000000000000000001 | hash | size This means we likely won=E2=80=99t have this problem any more with Python 3= .7. For Python 3.6 I guess we could add a final build phase that overwrites the timestamp in the *binary*. This needs to happen before any of the compiled files are wrapped up in a wheel. Should we just wait for Python 3.7 which is expected to be released in June 2018? We=E2=80=99d still have to deal with this problem in Python 2, though. Is it a bad idea to override the timestamps in the generated binaries? I think that we could avoid the recency check then, which was an obstacle to resetting the timestamps of the source files. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net