Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Matthias Klose <doko@ubuntu.com>
To: Mikhail Terekhov <Mikhail.Terekhov@dell.com>,
	       Petr Ovtchenkov <ptr@void-ptr.info>,
	       Andreas Schwab <schwab@linux-m68k.org>
Cc: binutils@sourceware.org, Joel Brobecker <brobecker@adacore.com>,
	       gdb@sourceware.org
Subject: Re: meaning of "Automatic date update in version.in" commits
Date: Wed, 20 Sep 2017 19:57:00 -0000	[thread overview]
Message-ID: <7716f103-1abd-a9fe-14e5-cbbe5a62eb01@ubuntu.com> (raw)
In-Reply-To: <218bf365-1f36-3531-b42b-5b48499992ed@dell.com>

On 20.09.2017 21:26, Mikhail Terekhov wrote:
> On 09/20/17 14:14, Matthias Klose wrote:
>> On 20.09.2017 19:23, Petr Ovtchenkov wrote:
>>> On Wed, 20 Sep 2017 18:16:45 +0200
>>> Andreas Schwab <schwab@linux-m68k.org> wrote:
>>>
>>>> On Sep 20 2017, Petr Ovtchenkov <ptr@void-ptr.info> 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     
>>>>> deterministic, bit-identical and/or verifiable builds.
>>>> Why is that a problem?  The version is fixed for a particular source
>>>> snapshot.
>>>>
>>> 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]
>> this is correct, and it's usually set to not include the date for a releases, an
>> exception being the 2.29.1 release, but things happen.
>>
>>> You see:
>>>
>>> git show 3110f4be18a2
>>>    commit 3110f4be18a2f3b9fcd9663ed1dd141bbd6ed14f
>>>    Author: GDB Administrator <gdbadmin@sourceware.org>
>>>    Date:   Wed Sep 20 00:01:01 2017 +0000
>>>
>>>        Automatic date update in version.in
>>>
>>>    diff --git a/bfd/version.h b/bfd/version.h
>>>    index 3405e42..955269f 100644
>>>    --- a/bfd/version.h
>>>    +++ b/bfd/version.h
>>>    @@ -1,4 +1,4 @@
>>>    -#define BFD_VERSION_DATE 20170919
>>>    +#define BFD_VERSION_DATE 20170920
>>>     #define BFD_VERSION @bfd_version@
>>>     #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
>>>     #define REPORT_BUGS_TO @report_bugs_to@
>>>
>>> git show f625a739
>>>    commit f625a739e567f0110b2675539b7a0e5d5f67c5dc
>>>    Author: GDB Administrator <gdbadmin@sourceware.org>
>>>    Date:   Wed Sep 20 00:01:22 2017 +0000
>>>
>>>        Automatic date update in version.in
>>>
>>>    diff --git a/bfd/version.h b/bfd/version.h
>>>    index 3405e42..955269f 100644
>>>    --- a/bfd/version.h
>>>    +++ b/bfd/version.h
>>>    @@ -1,4 +1,4 @@
>>>    -#define BFD_VERSION_DATE 20170919
>>>    +#define BFD_VERSION_DATE 20170920
>>>     #define BFD_VERSION @bfd_version@
>>>     #define BFD_VERSION_STRING  @bfd_version_package@ @bfd_version_string@
>>>     #define REPORT_BUGS_TO @report_bugs_to@
>>>
>>> git diff 3110f4be18a2 f625a739
>>> ...
>>> Ooops....
>>>
>>> This approch produce ambiguity, but try to conceal it.
>> Feel free to limit the bumps to exactly one after another commit.
>>
> What if build scripts obtain date of last commit automatically i.e. something
> like this:
> 
>     ~/tmp/gdb/binutils-gdb (master)>git log -1 --format=%cd --date=format:%Y%m%d
>     20170920
> 
> Then there is no need for additional commit.

no, you can't assume that git is available for builds.


  parent reply	other threads:[~2017-09-20 19:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170920173622.28500ccf@void-ptr.info>
2017-09-20 15:05 ` Joel Brobecker
2017-09-20 15:33   ` Petr Ovtchenkov
2017-09-21 17:07     ` Ian Lance Taylor via gdb
2017-09-20 15:40   ` Matthias Klose
2017-09-20 15:48     ` Dmitry Samersoff
     [not found] ` <87zi9p2vma.fsf@linux-m68k.org>
2017-09-20 17:24   ` Petr Ovtchenkov
     [not found]     ` <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com>
2017-09-20 19:21       ` Petr Ovtchenkov
2017-09-20 19:27       ` Mikhail Terekhov
2017-09-20 19:56         ` Philippe Waroquiers
2017-09-20 19:57         ` Matthias Klose [this message]
2017-09-20 20:07           ` Philippe Waroquiers
2017-09-20 20:21             ` Matthias Klose
2017-09-20 20:26               ` Philippe Waroquiers
2017-09-20 20:31                 ` Petr Ovtchenkov
2017-09-20 20:39                   ` Philippe Waroquiers
2017-09-20 20:34           ` Mikhail Terekhov
2017-09-20 21:34     ` Andreas Schwab
2017-09-21  5:03 Fiodar Stryzhniou via gdb
2017-09-21  8:42 ` Matt Rice
2017-09-21 10:58   ` Petr Ovtchenkov
2017-09-21 11:37     ` Pedro Alves
     [not found]       ` <20170921152240.16bb4cc0@void-ptr.info>
2017-09-21 12:39         ` Pedro Alves
2017-09-21 13:17           ` Petr Ovtchenkov
2017-09-21 13:34             ` Simon Marchi
2017-09-21 15:46               ` Petr Ovtchenkov
2017-09-21 16:01                 ` Simon Marchi
2017-09-21 16:03                 ` Matthias Klose
2017-09-21 16:26                   ` Petr Ovtchenkov
2017-09-21 16:34                     ` Joel Brobecker
2017-09-21 16:52                       ` Petr Ovtchenkov
2017-09-21 17:00                         ` Joel Brobecker
2017-09-21 17:39                           ` Petr Ovtchenkov
2017-09-21 23:59                             ` Alan Modra
2017-09-22  5:31                               ` Petr Ovtchenkov
2017-09-22  6:49                                 ` Andreas Schwab
2017-09-22  9:29                                   ` Petr Ovtchenkov
2017-09-22 22:26                                   ` H.J. Lu
2017-09-22 22:35                                   ` H.J. Lu
2017-09-21 17:17   ` Joseph Myers
2017-09-21 17:31     ` Matt Rice

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7716f103-1abd-a9fe-14e5-cbbe5a62eb01@ubuntu.com \
    --to=doko@ubuntu.com \
    --cc=Mikhail.Terekhov@dell.com \
    --cc=binutils@sourceware.org \
    --cc=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=ptr@void-ptr.info \
    --cc=schwab@linux-m68k.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox