From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Timestamps in tarballs created by 'patch-and-repack' Date: Tue, 14 Jul 2015 16:25:34 -0400 Message-ID: <87pp3utrk1.fsf@netris.org> References: <87y4iitus4.fsf@netris.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:41091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF6lv-00059H-3w for guix-devel@gnu.org; Tue, 14 Jul 2015 16:25:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZF6lr-0005MY-3o for guix-devel@gnu.org; Tue, 14 Jul 2015 16:25:47 -0400 Received: from world.peace.net ([50.252.239.5]:36908) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZF6lr-0005MK-0r for guix-devel@gnu.org; Tue, 14 Jul 2015 16:25:43 -0400 In-Reply-To: <87y4iitus4.fsf@netris.org> (Mark H. Weaver's message of "Tue, 14 Jul 2015 15:15:55 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: guix-devel@gnu.org Mark H Weaver writes: > Hello Guix, > > One of the MIPS build slaves has a malfunctioning clock, and sometimes I > discover that the clock is several days behind or ahead. In the past > I've been able to simply reset the clock and restart builds, but now I > have a more serious problem: > > Patched tarballs created by 'patch-and-repack' were built on a build > slave with the clock set about 8 days ahead. Those tarballs are now in > Hydra's store, and include timestamps in the tar file that are set so > far ahead that attempts to build them are failing. I'm currently > attempting to find and delete the bad tarballs from hydra's store. I ran into difficulties doing this, and anyway I'm not sure how to achieve confidence that I've found all of the bad archives, which might result is subtle breakage. So now I'm more inclined to just fix the problem in 'patch-and-repack'. > However, this raises a deeper problem: all of the outputs of > 'patch-and-repack' contain non-deterministic timestamps, and these > timestamps can cause problems with future builds. > > Would it be sufficient to simply zero out all of the timestamps before > repacking? I looked into this a bit more. In addition to timestamps, the other impure bits getting into tar files are the names and numeric ids of the owner and groups. Section 4.3.1 (Overriding File Metadata) of the GNU tar manual describes how to override these when creating an archive. My guess is that the following options would be sufficient to make the generated tar archives deterministic: --mtime=@0 --owner=root:0 --group=root:0 I'm going to try this on my local machine and see how it goes... Mark