From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106433 invoked by alias); 20 Sep 2017 15:40:10 -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 106407 invoked by uid 89); 20 Sep 2017 15:40:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=Hx-languages-length:1439, daily X-Spam-User: qpsmtpd, 2 recipients X-HELO: einhorn-mail.in-berlin.de Received: from einhorn-mail.in-berlin.de (HELO einhorn-mail.in-berlin.de) (217.197.80.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 15:40:08 +0000 X-Envelope-From: doko@ubuntu.com Received: from [192.168.178.30] ([95.91.214.147]) (authenticated bits=0) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v8KFdiwk013468 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Sep 2017 17:39:44 +0200 Subject: Re: meaning of "Automatic date update in version.in" commits To: Joel Brobecker , Petr Ovtchenkov Cc: binutils@sourceware.org, gdb@sourceware.org References: <20170920173622.28500ccf@void-ptr.info> <20170920150548.rj235a6sjxsnusrj@adacore.com> From: Matthias Klose Message-ID: Date: Wed, 20 Sep 2017 15:40:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170920150548.rj235a6sjxsnusrj@adacore.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00053.txt.bz2 On 20.09.2017 17:05, 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 binutils the date gets encoded into the libbfd and libopcodes soname, so you are pretty safe during development. Maybe you could manually bump the version when it is needed, but I assume that is more difficult than the automated daily bump. Matthias