From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Fri, 8 Feb 2019 18:04:36 +0100 Subject: [Buildroot] git tarball hashes [was: Report of Buildroot developer meeting FOSDEM 2019] In-Reply-To: <73a827af-2547-9b19-837a-c7eeadcd54cd@mind.be> References: <78472b2d-4adc-b110-273e-ddce78316dc2@mind.be> <20190208085450.6306509e@windsurf> <73a827af-2547-9b19-837a-c7eeadcd54cd@mind.be> Message-ID: <20190208170436.GB3079@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Arnout, All, On 2019-02-08 10:16 +0100, Arnout Vandecappelle spake thusly: > On 08/02/2019 08:54, Thomas Petazzoni wrote: > > On Thu, 7 Feb 2019 23:55:24 +0100 > > Arnout Vandecappelle wrote: > > > >> On 07/02/2019 23:51, Arnout Vandecappelle wrote: > >>> making sure the git backend > >>> produces reproducible tarballs by using the pax archive format (Yann started > >>> working on an implementation for that) > >> > >> ?I realized while writing this: how does this approach fix the instability of > >> gzip? Or do we assume that that was a one-off? > > > > Which gzip issue are you talking about ? I think we never had a > > *version* issue with gzip, only with installations where gzip is a > > symlink to pigz. > > Ah yes indeed, and someone (Yann?) observed that the output generated by gzip > has been stable since the dawn of the universe. Yeah, I tried versions back to 1.2.4, released in 1993, and the output is strictly identical. To be sure, I just re-did the test right now, and yeah, it works: $ /bin/gzip --version |head -1 gzip 1.6 $ /bin/gzip -n -c -9 - &1 |head -1 gzip 1.2.4 (18 Aug 93) $ ./gzip-1.2.4/gzip -n -c -9 -