From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72022 invoked by alias); 20 Sep 2017 19:21:12 -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 69921 invoked by uid 89); 20 Sep 2017 19:21:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,URIBL_SBL autolearn=no version=3.3.2 spammy=H*M:info, H*F:D*info, administrator 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 19:21:09 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1dukYT-00022C-PR; Wed, 20 Sep 2017 22:21:05 +0300 Date: Wed, 20 Sep 2017 19:21:00 -0000 From: Petr Ovtchenkov To: Matthias Klose Cc: Andreas Schwab , binutils@sourceware.org, Joel Brobecker , gdb@sourceware.org Subject: Re: meaning of "Automatic date update in version.in" commits Message-ID: <20170920222105.613042f9@void-ptr.info> In-Reply-To: <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com> References: <20170920173622.28500ccf@void-ptr.info> <87zi9p2vma.fsf@linux-m68k.org> <20170920202354.3c863857@void-ptr.info> <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00058.txt.bz2 On Wed, 20 Sep 2017 20:14:24 +0200 Matthias Klose wrote: > On 20.09.2017 19:23, Petr Ovtchenkov wrote: > > On Wed, 20 Sep 2017 18:16:45 +0200 > > Andreas Schwab wrote: > >=20 > >> On Sep 20 2017, Petr Ovtchenkov wrote: > >> > >>> What is the meaning of "Automatic date update in version.in" commits? > >>> I mean commits like f625a739e5. > >> > >> It is used to name the shared libbfd and libopcodes, since there is no > >> stable ABI. > >> > >>> This commits litter commits tree and create problems for=20=20=09 > >>> deterministic, bit-identical and/or verifiable builds. > >> > >> Why is that a problem? The version is fixed for a particular source > >> snapshot. > >> > >=20 > > It's looks as a problem indeed: > > - garbage in commits > > - disorientation, when date present in SONAME > > 0x000000000000000e (SONAME) Library soname: [libbfd-= 2.29.0.20170729.so] >=20 > this is correct, and it's usually set to not include the date for a relea= ses, an > exception being the 2.29.1 release, but things happen. >=20 > > You see: > >=20 > > git show 3110f4be18a2 > > commit 3110f4be18a2f3b9fcd9663ed1dd141bbd6ed14f > > Author: GDB Administrator > > Date: Wed Sep 20 00:01:01 2017 +0000 > > ... > > git show f625a739=20=20=20=20=20 > > commit f625a739e567f0110b2675539b7a0e5d5f67c5dc > > Author: GDB Administrator > > Date: Wed Sep 20 00:01:22 2017 +0000 > > ... > > git diff 3110f4be18a2 f625a739 > > ... > > Ooops.... > >=20 > > This approch produce ambiguity, but try to conceal it. >=20 > Feel free to limit the bumps to exactly one after another commit. IMO, it useless too: consider two commits in the same day. Even addition of short hash of top commit duiring build looks better. >From info above follow, that "Automatic date update in version.in" give no= thing useful. =46rom datestamps equality not follow ABI compatibility from one side, and from datestamps inequality not follow ABI incompatibility from another = side. Is another reason to keep it? -- - ptr