From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [PATCH v4 0/6] Reproducible build Date: Wed, 28 Jun 2017 08:57:33 -0700 Message-ID: <20170628085733.10153207@xeon-e3> References: <20170623184153.24488-1-lboccass@brocade.com> <20170628135702.18150-1-lboccass@brocade.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: , Luca Boccassi To: Return-path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by dpdk.org (Postfix) with ESMTP id AB3B616E for ; Wed, 28 Jun 2017 17:57:43 +0200 (CEST) Received: by mail-pf0-f177.google.com with SMTP id s66so35586536pfs.1 for ; Wed, 28 Jun 2017 08:57:43 -0700 (PDT) In-Reply-To: <20170628135702.18150-1-lboccass@brocade.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 28 Jun 2017 14:56:56 +0100 wrote: > From: Luca Boccassi > > In the past couple of years a concerted effort among almost all Linux > distros has been striving toward achieving reproducible builds. [1] > This involves changes to the toolchain, new tools and CI systems. [2] > > v1 fixed the documentation, examples and linker script generation. > v2 fixes all problems, which were caused by unstable order of headers > inclusion, source files listing and object file listing when passing > them to the compiler. > DPDK's build, at least with the default configuration, is fully > reproducible with this patch series as tested by the Reproducible > Builds developers experimental toolchain. [3] > > v3 restores the first patch, which was eaten by git send-email. > > v4 drops the patch that reorders rebuilds, and adds a patch to make > the inclusion of headers deterministic with regards to GCC embedding > the full file path when expading __FILE__ and when writing the > directory listing in the DWARF objects. > It also drops the first 2 patches which have already been merged. > > [1] https://reproducible-builds.org/ > [2] https://reproducible-builds.org/tools/ > [3] https://wiki.debian.org/ReproducibleBuilds/ExperimentalToolchain#Us Looks good. Looking ahead, how does this work with the proposed new build system? Is there an automated way to check new submissions so that new features don't undo this. Acked-by: Stephen Hemminger