Re: meaning of "Automatic date update in version.in" commits

Re: meaning of "Automatic date update in version.in" commits

[Joel Brobecker]

[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...

-- 
Joel

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Wed, 20 Sep 2017 08:05:48 -0700
Joel Brobecker <brobecker@adacore.com> 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

Re: meaning of "Automatic date update in version.in" commits

[Ian Lance Taylor via gdb]

On Wed, Sep 20, 2017 at 8:33 AM, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
> On Wed, 20 Sep 2017 08:05:48 -0700
> Joel Brobecker <brobecker@adacore.com> 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.

Historically speaking, my recollection is that Ken Raeburn introduced
it around 1994 or so when he started producing daily binutils
snapshots.  At the time the binutils source code repository was not
publicly available: it was held internally on the Cygnus CVS server
(the binutils source code repo was not publicly accessible until
1999).  Ken started making daily snapshots of the code available via
FTP for non-Cygnus developers and users.  The daily snapshots were
named after the day, naturally, and he added code to record the day in
the version file so that people knew which snapshot had been used to
build the tools.

As people have said it is now also used as part of the libbfd SONAME,
but at the time that Ken introduced it there was no support for
building BFD as a shared library.

Ian

Re: meaning of "Automatic date update in version.in" commits

[Matthias Klose]

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

Re: meaning of "Automatic date update in version.in" commits

[Dmitry Samersoff]

[-- Attachment #1.1: Type: text/plain, Size: 1656 bytes --]

On 20.09.2017 18:39, Matthias Klose wrote:
> 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.

If it's the only purpose of daily commit, than the obvious solution is
to improve daily commit script and update version.in only if source code
changes.

My $.2
-Dmitry



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

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]

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.

--

  - ptr

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Wed, 20 Sep 2017 20:14:24 +0200
Matthias Klose <doko@ubuntu.com> 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
> > ...
> > git show f625a739     
> >   commit f625a739e567f0110b2675539b7a0e5d5f67c5dc
> >   Author: GDB Administrator <gdbadmin@sourceware.org>
> >   Date:   Wed Sep 20 00:01:22 2017 +0000
> >  ...
> > 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.

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 nothing
useful.

From 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

Re: meaning of "Automatic date update in version.in" commits

[Mikhail Terekhov]

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.

Regards,
Mikhail

Re: meaning of "Automatic date update in version.in" commits

[Philippe Waroquiers]

On Wed, 2017-09-20 at 15:26 -0400, Mikhail Terekhov wrote:
> > 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.
This is what valgrind build does, so as to produce:
$ valgrind --version
valgrind-3.14.0.GIT
$ valgrind --version -v
valgrind-3.14.0.GIT-f1ff8597ef-20170919

The final "official" 3.14.0 release will (should) not have the
.GIT part (but will keep the short sha1 and date in -v output).

The date of last commit was recently added in the --version -v output.
There is also a trailing X added to the date if there are some diffs
between workdir and index, or index and HEAD.

See auxprogs/make_or_upd_vgversion_h and Makefile.am in valgrind
sources for details.

Philippe

Re: meaning of "Automatic date update in version.in" commits

[Matthias Klose]

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.

Re: meaning of "Automatic date update in version.in" commits

[Philippe Waroquiers]

On Wed, 2017-09-20 at 21:54 +0200, Matthias Klose wrote:

> > 
> >     ~/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.
In valgrind, the version.h file is build as part of the dist tarball.
And if really someone just takes a copy of the sources before 
building and/or making the dist tarball, valgrind --version -v
will just tell that the git version and date is unknown.

Philippe

Re: meaning of "Automatic date update in version.in" commits

[Matthias Klose]

On 20.09.2017 22:07, Philippe Waroquiers wrote:
> On Wed, 2017-09-20 at 21:54 +0200, Matthias Klose wrote:
> 
>>>
>>>     ~/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.
> In valgrind, the version.h file is build as part of the dist tarball.
> And if really someone just takes a copy of the sources before 
> building and/or making the dist tarball, valgrind --version -v
> will just tell that the git version and date is unknown.

but we are talking here about sonames for development snapshots.  A soname like
2.29.50.unknown doesn't change.

Re: meaning of "Automatic date update in version.in" commits

[Philippe Waroquiers]

On Wed, 2017-09-20 at 22:17 +0200, Matthias Klose wrote:
> On 20.09.2017 22:07, Philippe Waroquiers wrote:
> > On Wed, 2017-09-20 at 21:54 +0200, Matthias Klose wrote:
> > 
> > > > 
> > > >     ~/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.
> > 
> > In valgrind, the version.h file is build as part of the dist
> > tarball.
> > And if really someone just takes a copy of the sources before 
> > building and/or making the dist tarball, valgrind --version -v
> > will just tell that the git version and date is unknown.
> 
> but we are talking here about sonames for development snapshots.  A
> soname like
> 2.29.50.unknown doesn't change.

I suppose that a development snapshot tarball will always be done
from a git repository, and so will have the sha1 and date in the
version.

And if really someone makes a snapshot outside of a git repository,
then the resulting snapshot will not be very precisely identified.
Don't use it :).

Philippe

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Wed, 20 Sep 2017 22:26:44 +0200
Philippe Waroquiers <philippe.waroquiers@skynet.be> wrote:

> On Wed, 2017-09-20 at 22:17 +0200, Matthias Klose wrote:
> > On 20.09.2017 22:07, Philippe Waroquiers wrote:
> > > On Wed, 2017-09-20 at 21:54 +0200, Matthias Klose wrote:
> > > 
> > > > > 
> > > > > б б б б ~/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.
> > > 
> > > In valgrind, the version.h file is build as part of the dist
> > > tarball.
> > > And if really someone just takes a copy of the sources beforeб 
> > > building and/or making the dist tarball, valgrind --version -v
> > > will just tell that the git version and date is unknown.
> > 
> > but we are talking here about sonames for development snapshots.б б A
> > soname like
> > 2.29.50.unknown doesn't change.
> 
> I suppose that a development snapshot tarball will always be done
> from a git repository, and so will have the sha1 and date in the
> version.
> 
> And if really someone makes a snapshot outside of a git repository,
> then the resulting snapshot will not be very precisely identified.
> Don't use it :).
> 
> Philippe
> 

Why you forget about
<snip>
  From info above follow, that "Automatic date update in version.in" give nothing
  useful.

  From datestamps equality not follow ABI compatibility from one side,
  and from datestamps inequality not follow ABI incompatibility from another side.
</snip>
?

--

  - ptr

Re: meaning of "Automatic date update in version.in" commits

[Philippe Waroquiers]

On Wed, 2017-09-20 at 23:30 +0300, Petr Ovtchenkov wrote:
> Why you forget about
> <snip>
>   From info above follow, that "Automatic date update in version.in"
> give nothing
>   useful.
> 
>   From datestamps equality not follow ABI compatibility from one
> side,
>   and from datestamps inequality not follow ABI incompatibility from
> another side.
> </snip>
> ?
> 

The date in --version -v of valgrind is for sure not used to indicate
wh
atever kind of compatibility.

The addition of the date to --version -v was done following
user requests:  some users are using development snapshots, and would
like to have a (relatively) precise idea of which dev version they are
using, and if this dev version is old or not.
Of course, starting from the git sha1, they could verify in git the 
date of the commit, but typing --version -v is fast and easy, in
particular if you have no valgrind git repository at hand.

During valgrind 3.12 development, the version was only 3.12.0.SVN
During 3.13, --version -v added the svn revision.
Now, with 3.14, --version -v contains the git sha1 and the date
(as an easy way for the user to find what they are running).

Philippe

Re: meaning of "Automatic date update in version.in" commits

[Mikhail Terekhov]

On 09/20/17 15:54, Matthias Klose wrote:
> On 20.09.2017 21:26, Mikhail Terekhov wrote:
>
>> 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.
>
Then you can't be sure that the date is correct.

Re: meaning of "Automatic date update in version.in" commits

[Andreas Schwab]

On Sep 20 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:

> 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.

You look at two different snapshots.  What do you expect?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: meaning of "Automatic date update in version.in" commits

[Fiodar Stryzhniou via gdb]

I propose set date with git hook. With every commit create bfd/version.in before commit and vice versa.
Fiodar Stryzhniou

исходное сбщ
Тема: Re: meaning of "Automatic date update in version.in" commits
От: Andreas Schwab <schwab@linux-m68k.org>
Дата: 21.09.2017 00.35

On Sep 20 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:

> 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.

You look at two different snapshots.  What do you expect?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: meaning of "Automatic date update in version.in" commits

[Matt Rice]

On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb
<gdb@sourceware.org> wrote:
> I propose set date with git hook. With every commit create bfd/version.in before commit and vice versa.

Hmm, I don't know much about git hooks per se, but I didn't think e.g.
server side hooks could filter on commit?
Anyhow, I see 2 options, assuming there are some list of requirements
for when git is required:
compile time? no
configure time? (C.)
autoreconf time? n/a
checkout time? always (A.)
commit time? always (B.)

option A. seems to be using git smudge/filter to on checkout populate
the version.in using a smudge rule, and then filtering it out using a
filter,
              acting much like the RCS keywords...
  pros: no extra commit stuff at all
  cons: requires setting up git config stuff in the repository for
executing the smudge/filter rules on checkout
           this should likely be checked by the configure process e.g.
configure should produce an error telling the user to enable the
smudge/filter rules
          when the version is $Date$ rather an actual date...

option B. would be somewhat the reverse of this, using a git filter,
to modify the commit to insert a date into commits,
              it would require that committers (rather than people
checking out) modify their git config to update version.in on commit.
              would act somewhat like the project git-crypt
https://www.agwa.name/projects/git-crypt/
              perhaps this is what Fiodar is referring to above?

              we would then probably require Brobecke's git hooks, to
check that the commit/filter was run before commit

Option A. shifts the burden onto users to checkout the repository with
the filters enabled
Option B. causes some developer discomfort when it comes to merging
and branches and what not, and it would probably show up in every
patch review.
Option C. requiring git at configure time, could be inconvenient for
some downstream distros with build machinery that doesn't include git.
               I personally would not consider it an option...

out of these 3, my preference would be A,
this is quite counter to the preference I would typically have, e.g.
jump through that extra hoop so it doesn't get shifted to the user
compiling the software.
but I think that the B. hoop is perhaps on fire, and would end up more
annoying than the cron commit we have now...

So in that regard the choice largely falls to: is the existing cron
mechanism annoying enough that we would burden the user with A?
I think that since it is a one-time thing when cloning a
repository/setting up the repository it is at least worth considering
since leaving it as it is does add overhead for e.g. the build bot
finding commit broke, and git bisect.

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 01:42:28 -0700
Matt Rice <ratmice@gmail.com> wrote:

> On Wed, Sep 20, 2017 at 9:58 PM, Fiodar Stryzhniou via gdb
> <gdb@sourceware.org> wrote:
> > I propose set date with git hook. With every commit create bfd/version.in before commit and
> > vice versa.
> 
> Hmm, I don't know much about git hooks per se, but I didn't think e.g.
> server side hooks could filter on commit?
> Anyhow, I see 2 options, assuming there are some list of requirements
> for when git is required:
> compile time? no
> configure time? (C.)
> autoreconf time? n/a
> checkout time? always (A.)
> commit time? always (B.)

Date is worst thing that you may use in SONAME. Especially in conjunction
with attempts to use DVCS as date source. (D == _Distributed_, so _no
time ordering_). And I should repeat:

  - from datestamps equality not follow ABI compatibility,
  - from datestamps inequality not follow ABI incompatibility.

What you want achieve with SONAME variations?

> 
> option A. seems to be using git smudge/filter to on checkout populate
> the version.in using a smudge rule, and then filtering it out using a
> filter,
>               acting much like the RCS keywords...
>   pros: no extra commit stuff at all
>   cons: requires setting up git config stuff in the repository for
> executing the smudge/filter rules on checkout
>            this should likely be checked by the configure process e.g.
> configure should produce an error telling the user to enable the
> smudge/filter rules
>           when the version is $Date$ rather an actual date...
> 
> option B. would be somewhat the reverse of this, using a git filter,
> to modify the commit to insert a date into commits,
>               it would require that committers (rather than people
> checking out) modify their git config to update version.in on commit.
>               would act somewhat like the project git-crypt
> https://www.agwa.name/projects/git-crypt/
>               perhaps this is what Fiodar is referring to above?
> 
>               we would then probably require Brobecke's git hooks, to
> check that the commit/filter was run before commit
> 
> Option A. shifts the burden onto users to checkout the repository with
> the filters enabled
> Option B. causes some developer discomfort when it comes to merging
> and branches and what not, and it would probably show up in every
> patch review.
> Option C. requiring git at configure time, could be inconvenient for
> some downstream distros with build machinery that doesn't include git.
>                I personally would not consider it an option...
> 
> out of these 3, my preference would be A,
> this is quite counter to the preference I would typically have, e.g.
> jump through that extra hoop so it doesn't get shifted to the user
> compiling the software.
> but I think that the B. hoop is perhaps on fire, and would end up more
> annoying than the cron commit we have now...
> 
> So in that regard the choice largely falls to: is the existing cron
> mechanism annoying enough that we would burden the user with A?
> I think that since it is a one-time thing when cloning a
> repository/setting up the repository it is at least worth considering
> since leaving it as it is does add overhead for e.g. the build bot
> finding commit broke, and git bisect.

Re: meaning of "Automatic date update in version.in" commits

[Pedro Alves]

On 09/21/2017 11:58 AM, Petr Ovtchenkov wrote:

> Date is worst thing that you may use in SONAME. Especially in conjunction
> with attempts to use DVCS as date source. (D == _Distributed_, so _no
> time ordering_). And I should repeat:
> 
>   - from datestamps equality not follow ABI compatibility,
>   - from datestamps inequality not follow ABI incompatibility.
> 
> What you want achieve with SONAME variations?

What do _you_ want to achieve with removing the date stamps?

You started the thread with:

> This commits (...) create problems for  	
> deterministic, bit-identical and/or verifiable builds.

... which is false.  The rest of the thread seems like trying
to change the goal post in order to justify change so that as side
effect we'd fix the problem with determinism that you
claimed exists, but that doesn't actually exist.

I.e., this whole thread feels like the classical XY problem.

What is the actual problem that you're trying to solve?

Thanks,
Pedro Alves

Re: meaning of "Automatic date update in version.in" commits

[Pedro Alves]

On 09/21/2017 01:22 PM, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 12:36:46 +0100
> Pedro Alves <palves@redhat.com> wrote:

>> I.e., this whole thread feels like the classical XY problem.
>>
>> What is the actual problem that you're trying to solve?
> 
> Problem remains original.
> 
> "Automatic date update in version.in" commits are 
>    - litter commits tree
>    - create problems for deterministic, bit-identical and/or verifiable builds.

[snip distractions from the original problem]

> Am I quite clear?

No.

The "litter" problem is real, but minor.

The determinism claim would have merit, if it were a real problem.
But it's not.  Every checkout of a given git hash gets the exact
same sources with the same date stamp.  It's totally deterministic.

So again, what problem are you trying to solve?

Thanks,
Pedro Alves

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 13:39:08 +0100
Pedro Alves <palves@redhat.com> wrote:

> 
> On 09/21/2017 01:22 PM, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 12:36:46 +0100
> > Pedro Alves <palves@redhat.com> wrote:
> 
> >> I.e., this whole thread feels like the classical XY problem.
> >>
> >> What is the actual problem that you're trying to solve?
> > 
> > Problem remains original.
> > 
> > "Automatic date update in version.in" commits are 
> >    - litter commits tree
> >    - create problems for deterministic, bit-identical and/or verifiable builds.
> 
> [snip distractions from the original problem]
> 
> > Am I quite clear?
> 
> No.
> 
> The "litter" problem is real, but minor.

Nice. Looks, that in first point we have consensus. :)

> 
> The determinism claim would have merit, if it were a real problem.

I think it's real. But it is another story, right?

> But it's not.  Every checkout of a given git hash gets the exact
> same sources with the same date stamp.  It's totally deterministic.

And date stamp in version.in not play here at all. But,

  - if you insert date stamp into sources, you
    i)  keep "litter" problem
    ii) make misorientation (what this date mean? commit date? - it already
       present in commit; and what commit date?)
  - if you don't insert date stamp into sources, but add to SONAME during build process,
    it still not reflect ABI compatibilities, but may prevent "binary reproducible builds"
    (depends upon what date you use). I'm underline, that such addition
    has no relation to ABI compatibilities, so such SONAME modification
    lose sense.

> 
> So again, what problem are you trying to solve?
> 

Again, all stated above.

WBR,

--

  - ptr

Re: meaning of "Automatic date update in version.in" commits

[Simon Marchi]

On 2017-09-21 15:17, Petr Ovtchenkov wrote:
> And date stamp in version.in not play here at all. But,
> 
>   - if you insert date stamp into sources, you
>     i)  keep "litter" problem
>     ii) make misorientation (what this date mean? commit date? - it 
> already
>        present in commit; and what commit date?)
>   - if you don't insert date stamp into sources, but add to SONAME
> during build process,
>     it still not reflect ABI compatibilities, but may prevent "binary
> reproducible builds"
>     (depends upon what date you use). I'm underline, that such addition
>     has no relation to ABI compatibilities, so such SONAME modification
>     lose sense.

Binary reproducible builds mean that if you and I start with the same 
source code and same build tools, we will get exactly the same build 
artifacts.  Here the build can't "depend on what date you use": you 
can't choose a date or another, the date is part of the code you are 
trying to build.  So if you and I build from the same commit, we'll 
build using the same date, whatever date is in the version.h file.

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 15:25:53 +0200
Simon Marchi <simon.marchi@polymtl.ca> wrote:

> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
> > And date stamp in version.in not play here at all. But,
> > 
> >   - if you insert date stamp into sources, you
> >     i)  keep "litter" problem
> >     ii) make misorientation (what this date mean? commit date? - it 
> > already
> >        present in commit; and what commit date?)
> >   - if you don't insert date stamp into sources, but add to SONAME
> > during build process,
> >     it still not reflect ABI compatibilities, but may prevent "binary
> > reproducible builds"
> >     (depends upon what date you use). I'm underline, that such addition
> >     has no relation to ABI compatibilities, so such SONAME modification
> >     lose sense.
> 
> Binary reproducible builds mean that if you and I start with the same 
> source code and same build tools, we will get exactly the same build 
> artifacts.  Here the build can't "depend on what date you use":

If "date stamp" inserted into binary is a build date, then we will have different
binaries. If we will use something else, for example "last commit" date,
then we may have "same" build, but may not. From equality of "last commit" date
not follow binary equivalence (consider cherry-picked commit, for example,
or variations of sample "git diff 3110f4be18a2 f625a739" I show above).

> you 
> can't choose a date or another, the date is part of the code you are 
> trying to build.  So if you and I build from the same commit, we'll 
> build using the same date, whatever date is in the version.h file.
> 
> 

Re: meaning of "Automatic date update in version.in" commits

[Simon Marchi]

On 2017-09-21 17:46, Petr Ovtchenkov wrote:
>> Binary reproducible builds mean that if you and I start with the same
>> source code and same build tools, we will get exactly the same build
>> artifacts.  Here the build can't "depend on what date you use":
> 
> If "date stamp" inserted into binary is a build date,

It is definitely not a build date (as in the date at which you run 
make), I don't think anybody is suggesting that.

> then we will have different
> binaries. If we will use something else, for example "last commit" 
> date,
> then we may have "same" build, but may not. From equality of "last 
> commit" date
> not follow binary equivalence (consider cherry-picked commit, for 
> example,
> or variations of sample "git diff 3110f4be18a2 f625a739" I show above).

That's the part I don't understand in your reasoning.

f625a739 is the commit that bumps the date to Sept 20 in the 
binutils-2_29-branch, 3110f4be18a2 is the commit that bumps the date to 
Sept 20 in the gdb-8.0-branch.  They happen to have the same title and 
same diff, but they are otherwise not related.  Those two branches do 
not contain the same code, and therefore are not expected to produce the 
same build artifacts.

So if you checkout the repo at f625a739 (state at which the gdb 8.0 
branch was on Sept 20) and I do the same, we'll be able to get 
reproducible builds if we use the same toolchain (unless something else 
entirely causes the build to not be reproducible, I haven't tried).

Simon

Re: meaning of "Automatic date update in version.in" commits

[Matthias Klose]

On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 15:25:53 +0200
> Simon Marchi <simon.marchi@polymtl.ca> wrote:
> 
>> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
>>> And date stamp in version.in not play here at all. But,
>>>
>>>   - if you insert date stamp into sources, you
>>>     i)  keep "litter" problem
>>>     ii) make misorientation (what this date mean? commit date? - it 
>>> already
>>>        present in commit; and what commit date?)
>>>   - if you don't insert date stamp into sources, but add to SONAME
>>> during build process,
>>>     it still not reflect ABI compatibilities, but may prevent "binary
>>> reproducible builds"
>>>     (depends upon what date you use). I'm underline, that such addition
>>>     has no relation to ABI compatibilities, so such SONAME modification
>>>     lose sense.
>>
>> Binary reproducible builds mean that if you and I start with the same 
>> source code and same build tools, we will get exactly the same build 
>> artifacts.  Here the build can't "depend on what date you use":
> 
> If "date stamp" inserted into binary is a build date, then we will have different
> binaries.

but it not a build date. it is a string taken form a file in the repository.
That's exactly what Simon wrote at the end of the last message, and which you
ignored to read or comment. Please see below.

> If we will use something else, for example "last commit" date,
> then we may have "same" build, but may not. From equality of "last commit" date
> not follow binary equivalence (consider cherry-picked commit, for example,
> or variations of sample "git diff 3110f4be18a2 f625a739" I show above).
> 
>> you 
>> can't choose a date or another, the date is part of the code you are 
>> trying to build.  So if you and I build from the same commit, we'll 
>> build using the same date, whatever date is in the version.h file.
>>
>>

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 18:01:59 +0200
Matthias Klose <doko@ubuntu.com> wrote:

> On 21.09.2017 17:46, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 15:25:53 +0200
> > Simon Marchi <simon.marchi@polymtl.ca> wrote:
> > 
> >> On 2017-09-21 15:17, Petr Ovtchenkov wrote:
> >>> And date stamp in version.in not play here at all. But,
> >>>
> >>>   - if you insert date stamp into sources, you
> >>>     i)  keep "litter" problem
> >>>     ii) make misorientation (what this date mean? commit date? - it 
> >>> already
> >>>        present in commit; and what commit date?)
> >>>   - if you don't insert date stamp into sources, but add to SONAME
> >>> during build process,
> >>>     it still not reflect ABI compatibilities, but may prevent "binary
> >>> reproducible builds"
> >>>     (depends upon what date you use). I'm underline, that such addition
> >>>     has no relation to ABI compatibilities, so such SONAME modification
> >>>     lose sense.
> >>
> >> Binary reproducible builds mean that if you and I start with the same 
> >> source code and same build tools, we will get exactly the same build 
> >> artifacts.  Here the build can't "depend on what date you use":
> > 
> > If "date stamp" inserted into binary is a build date, then we will have different
> > binaries.
> 
> but it not a build date. it is a string taken form a file in the repository.
> That's exactly what Simon wrote at the end of the last message, and which you
> ignored to read or comment. Please see below.

Ok. I just expect that you read my arguments too. But in this case you ignore

<snip>
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....
</snip>

Same date. From both commits I can build libbfd. From equality of dates stamped in the source
not follow ABI compatibility.
Plus

  git diff 0d8a80b95 7a261482f

---from different stamped dates not follow ABI incompatibility.

Or I suspect that you conceal that date stamp not intended to reflect ABI compatibility,
but something else.

> 
> > If we will use something else, for example "last commit" date,
> > then we may have "same" build, but may not. From equality of "last commit" date
> > not follow binary equivalence (consider cherry-picked commit, for example,
> > or variations of sample "git diff 3110f4be18a2 f625a739" I show above).
> > 
> >> you 
> >> can't choose a date or another, the date is part of the code you are 
> >> trying to build.  So if you and I build from the same commit, we'll 
> >> build using the same date, whatever date is in the version.h file.

Re: meaning of "Automatic date update in version.in" commits

[Joel Brobecker]

> Same date. From both commits I can build libbfd. From equality of
> dates stamped in the source not follow ABI compatibility.
> Plus
> 
>   git diff 0d8a80b95 7a261482f
> 
> ---from different stamped dates not follow ABI incompatibility.

The version number is completely different, however. I don't think
anyone is saying that the date is the unique element in determining
compatibility or not.

-- 
Joel

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 09:33:58 -0700
Joel Brobecker <brobecker@adacore.com> wrote:

> > Same date. From both commits I can build libbfd. From equality of
> > dates stamped in the source not follow ABI compatibility.
> > Plus
> > 
> >   git diff 0d8a80b95 7a261482f
> > 
> > ---from different stamped dates not follow ABI incompatibility.
> 
> The version number is completely different, however. I don't think
> anyone is saying that the date is the unique element in determining
> compatibility or not.

It is evident for me. But in the discussion I see a lot of arguments,
that I treat as "date stamp is used as ABI compatibility marker". 

The version string is different, yes. It assigned (at least I'm expect this)
by human (i.e. not bot) that want mark ABI compatibility.
[Under "version string" I mean here SONAME record of libbfd, because
ABI version != lib version].

--

  - ptr

Re: meaning of "Automatic date update in version.in" commits

[Joel Brobecker]

> It is evident for me. But in the discussion I see a lot of arguments,
> that I treat as "date stamp is used as ABI compatibility marker". 

Then, I am in the same situation as Pedro. What problem are you trying
to fix?

-- 
Joel

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Thu, 21 Sep 2017 10:00:31 -0700
Joel Brobecker <brobecker@adacore.com> wrote:

> > It is evident for me. But in the discussion I see a lot of arguments,
> > that I treat as "date stamp is used as ABI compatibility marker". 
> 
> Then, I am in the same situation as Pedro. What problem are you trying
> to fix?

Oops. Let's start from the begining. Far far away...

1. Explicit "Automatic date update in version.in" commits litter commits tree,
but useless. All required info already present in git.
[Thanks for Ian Lance Taylor for the background!]

Let's remove this "Automatic date update in version.in" commits.

2. I see a lot of suggestions "Let's push date to SONAME, the date we
will take from ....".

I trying to prevent such "solutions". Because it's not a solution, but
origin of another problems.


3rd law of human interaction.
...
Corollary 1: If you explain so clearly that nobody can misunderstand, somebody will.
...
Corollary 4: No matter how long or how many times you explain, no one is listening.

[Chisholm Effect: Basic laws of frustration, mishap, and delay]

Re: meaning of "Automatic date update in version.in" commits

[Alan Modra]

On Thu, Sep 21, 2017 at 08:38:57PM +0300, Petr Ovtchenkov wrote:
> On Thu, 21 Sep 2017 10:00:31 -0700
> Joel Brobecker <brobecker@adacore.com> wrote:
> 
> > > It is evident for me. But in the discussion I see a lot of arguments,
> > > that I treat as "date stamp is used as ABI compatibility marker". 
> > 
> > Then, I am in the same situation as Pedro. What problem are you trying
> > to fix?
> 
> Oops. Let's start from the begining. Far far away...
> 
> 1. Explicit "Automatic date update in version.in" commits litter commits tree,
> but useless. All required info already present in git.
> [Thanks for Ian Lance Taylor for the background!]

It isn't useless.  People build binutils from a variety of sources,
git, tarballs, distro sources, then report bugs.  We want something
that can easily identify the source they used.  The bfd version plus
date is usually good enough for that purpose.

> Let's remove this "Automatic date update in version.in" commits.

No.  That won't happen unless we have something equivalent.  And it
must work *without* git.

> 2. I see a lot of suggestions "Let's push date to SONAME, the date we
> will take from ....".
> 
> I trying to prevent such "solutions". Because it's not a solution, but
> origin of another problems.

The date is in the soname because people naturally expect shared
libraries with the same soname to have compatible ABIs.  During
development, we could bump the bfd version on every ABI change, but
that's just another thing contributors and maintainers would need to
remember.  It's much easier for all if the soname contains the date.
Again, it's not perfect but is good enough.

None of this is going to change just because you don't like a date
stamp in the source.  You do realize that a bisect uses a binary
search, don't you?  So doubling the number of commits just needs one
extra build/test step on average.

Yes, it would be nice if the automatic date stamp update didn't happen
when the most recent commit was a date update..

-- 
Alan Modra
Australia Development Lab, IBM

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

On Fri, 22 Sep 2017 09:29:36 +0930
Alan Modra <amodra@gmail.com> wrote:

> On Thu, Sep 21, 2017 at 08:38:57PM +0300, Petr Ovtchenkov wrote:
> > On Thu, 21 Sep 2017 10:00:31 -0700
> > Joel Brobecker <brobecker@adacore.com> wrote:
> > 
> > > > It is evident for me. But in the discussion I see a lot of arguments,
> > > > that I treat as "date stamp is used as ABI compatibility marker". 
> > > 
> > > Then, I am in the same situation as Pedro. What problem are you trying
> > > to fix?
> > 
> > Oops. Let's start from the begining. Far far away...
> > 
> > 1. Explicit "Automatic date update in version.in" commits litter commits tree,
> > but useless. All required info already present in git.
> > [Thanks for Ian Lance Taylor for the background!]
> 
> It isn't useless.  People build binutils from a variety of sources,
> git, tarballs, distro sources, then report bugs.  We want something
> that can easily identify the source they used.  The bfd version plus
> date is usually good enough for that purpose.
> 
> > Let's remove this "Automatic date update in version.in" commits.
> 
> No.  That won't happen unless we have something equivalent.  And it
> must work *without* git.
> 
> > 2. I see a lot of suggestions "Let's push date to SONAME, the date we
> > will take from ....".
> > 
> > I trying to prevent such "solutions". Because it's not a solution, but
> > origin of another problems.
> 
> The date is in the soname because people naturally expect shared
> libraries with the same soname to have compatible ABIs.  During
> development, we could bump the bfd version on every ABI change, but
> that's just another thing contributors and maintainers would need to
> remember.  It's much easier for all if the soname contains the date.
> Again, it's not perfect but is good enough.
> 
> None of this is going to change just because you don't like a date
> stamp in the source.  You do realize that a bisect uses a binary
> search, don't you?  So doubling the number of commits just needs one
> extra build/test step on average.

+1 _rebuild_ * 2 (binutils + gdb), i.e. ~ +730 rebuilds that may be avoided.
Because binutils present near the top of packages dependency tree,
even incremental rebuild will be big enough. Looks I'm really forget
something... Oh, different platforms! What multiplicator I should
substitute here? All this to "easily identify the source they used",
for example, for 7f904457..94552d96, not for ABI change indeed.
All this for "inexperienced" users that try to test development binutils.

> 
> Yes, it would be nice if the automatic date stamp update didn't happen
> when the most recent commit was a date update..
> 

I.e. development process of kernel or glibc (ABI is important and "source
identification" important too, isn't it?) dispense of such technique,
but binutils prefer to follow tradition from 1994 that was useful
for publicly inaccessible CVS repo + public tarball on FTP.

Looks I'm attempt a sacred caw. I should shut up.

Re: meaning of "Automatic date update in version.in" commits

[Andreas Schwab]

On Sep 22 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:

> I.e. development process of kernel or glibc (ABI is important and "source
> identification" important too, isn't it?) dispense of such technique,

Unlike kernel and glibc, libbfd and libopcodes do not maintain ABI
compatibility, and never will.

> but binutils prefer to follow tradition from 1994 that was useful
> for publicly inaccessible CVS repo + public tarball on FTP.

bfd/version.h has been added in 2001, not 1994.  It still works very
well, no need to change anything that isn't broken.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: meaning of "Automatic date update in version.in" commits

[Petr Ovtchenkov]

I hope it will be the last message in this thread.
Just summary of discussion to avoid useless flame in the future.

Date in version.h.in stamped via everyday bot's commits is important
due to user requirements.

The target user portrait is:

  - he/she build binutils/gdb from development sources;
  - he/she often receive development sources as tarball from ftp server;
  - he/she never use git, at least on binutils/gdb build stage;
  - he/she use libbfd/opcodes in a "pure" manner, without
    software that depends upon this libs, so bulk rebuilds is not a problem;
  - he/she may report about bugs a few months after building or receiving
    library in a binary form and can more-or-less identify sources;
  - he/she don't use development binutils/gdb within processes with
    continuous integration-like approach;
  - he/she don't worry about ABI changes and compatibility.

Assuming this targets, process of development and maintenance work well
and modification not required.

Thanks,

--

  - ptr

Re: meaning of "Automatic date update in version.in" commits

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]



On September 22, 2017 2:49:31 PM GMT+08:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
>On Sep 22 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
>
>> I.e. development process of kernel or glibc (ABI is important and
>"source
>> identification" important too, isn't it?) dispense of such technique,
>
>Unlike kernel and glibc, libbfd and libopcodes do not maintain ABI
>compatibility, and never will.
>
>> but binutils prefer to follow tradition from 1994 that was useful
>> for publicly inaccessible CVS repo + public tarball on FTP.
>
>bfd/version.h has been added in 2001, not 1994.  It still works very
>well, no need to change anything that isn't broken.
>
>Andreas.
>
>-- 
>Andreas Schwab, schwab@linux-m68k.org
>GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276
>4ED5
>"And now for something completely different."

We should try not to update DATE in version.h if there is no change
otherwise.  It can be done by remembering the last commit.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: meaning of "Automatic date update in version.in" commits

[H.J. Lu]

On September 22, 2017 2:49:31 PM GMT+08:00, Andreas Schwab <schwab@linux-m68k.org> wrote:
>On Sep 22 2017, Petr Ovtchenkov <ptr@void-ptr.info> wrote:
>
>> I.e. development process of kernel or glibc (ABI is important and
>"source
>> identification" important too, isn't it?) dispense of such technique,
>
>Unlike kernel and glibc, libbfd and libopcodes do not maintain ABI
>compatibility, and never will.
>
>> but binutils prefer to follow tradition from 1994 that was useful
>> for publicly inaccessible CVS repo + public tarball on FTP.
>
>bfd/version.h has been added in 2001, not 1994.  It still works very
>well, no need to change anything that isn't broken.
>
>Andreas.

We should try not to update DATE in version.h if there is no change
otherwise. It can be done by remembering the last commit.
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: meaning of "Automatic date update in version.in" commits

[Joseph Myers]

On Thu, 21 Sep 2017, Matt Rice wrote:

> option A. seems to be using git smudge/filter to on checkout populate
> the version.in using a smudge rule, and then filtering it out using a
> filter,
>               acting much like the RCS keywords...
>   pros: no extra commit stuff at all
>   cons: requires setting up git config stuff in the repository for
> executing the smudge/filter rules on checkout
>            this should likely be checked by the configure process e.g.
> configure should produce an error telling the user to enable the
> smudge/filter rules
>           when the version is $Date$ rather an actual date...

I don't think there should be anything that requires people to check out 
in a special way, or to configure their checkouts specially, rather than 
just using "git clone" and a subsequent build.  Generic tools such as 
build bots may have generic knowledge of how to check out and update git 
checkouts; they should not need binutils-specific extras to that 
knowledge.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: meaning of "Automatic date update in version.in" commits

[Matt Rice]

On Thu, Sep 21, 2017 at 10:17 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> On Thu, 21 Sep 2017, Matt Rice wrote:
>
>> option A. seems to be using git smudge/filter to on checkout populate
>> the version.in using a smudge rule, and then filtering it out using a
>> filter,
>>               acting much like the RCS keywords...
>>   pros: no extra commit stuff at all
>>   cons: requires setting up git config stuff in the repository for
>> executing the smudge/filter rules on checkout
>>            this should likely be checked by the configure process e.g.
>> configure should produce an error telling the user to enable the
>> smudge/filter rules
>>           when the version is $Date$ rather an actual date...
>
> I don't think there should be anything that requires people to check out
> in a special way, or to configure their checkouts specially, rather than
> just using "git clone" and a subsequent build.  Generic tools such as
> build bots may have generic knowledge of how to check out and update git
> checkouts; they should not need binutils-specific extras to that
> knowledge.

Indeed i was looking at it the other way, in that build bots etc need
binutils-specific knowledge in order to ignore these commits
to avoid unnecessary work, but your point seems valid.