From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 36262 invoked by alias); 20 Sep 2017 15:33:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 36241 invoked by uid 89); 20 Sep 2017 15:33:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=H*M:info, daily, H*F:D*info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 15:33:14 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1dugzw-0000AQ-4R; Wed, 20 Sep 2017 18:33:12 +0300 Date: Wed, 20 Sep 2017 15:33:00 -0000 From: Petr Ovtchenkov To: Joel Brobecker Cc: binutils@sourceware.org, gdb@sourceware.org Subject: Re: meaning of "Automatic date update in version.in" commits Message-ID: <20170920183312.73ade4ef@void-ptr.info> In-Reply-To: <20170920150548.rj235a6sjxsnusrj@adacore.com> References: <20170920173622.28500ccf@void-ptr.info> <20170920150548.rj235a6sjxsnusrj@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00052.txt.bz2 On Wed, 20 Sep 2017 08:05:48 -0700 Joel Brobecker wrote: > [adding the GDB group, as this affects both] > > > What is the meaning of "Automatic date update in version.in" commits? > > I mean commits like f625a739e5. > > > > This commits litter commits tree and create problems for > > deterministic, bit-identical and/or verifiable builds. > > > > May be worth to remove this (historical?) artifact? > > We've had that discussion several times in the past. I'd be quite > happy to get rid of that daily commit, and most people here probably > would be too. The issue is that no one has been able to get us > to agree on what we should be doing instead, and then implement it. > Part of the obstacles, I think, is that everyone has their own idea > of the requirements that should be met. Maybe one solution would be > to ask the group of Global Maintainers to make a decision (at least > for GDB) once everyone had a chance to provide their feedback. Once > we have a clear plan of what should be done, I suspect finding > a volunteer to implement it wouldn't be too hard. I might even > take an hour or two in a weekend to look into that... > For [possible] transition/solution/etc it would be useful to tell here what this ["Automatic date update in version.in"] commits was intended for. Thanks, -- - ptr