From: Petr Ovtchenkov <ptr@void-ptr.info>
To: Matthias Klose <doko@ubuntu.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>,
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:21:00 -0000 [thread overview]
Message-ID: <20170920222105.613042f9@void-ptr.info> (raw)
In-Reply-To: <7217d33d-61eb-732e-dfd6-80ef4908743e@ubuntu.com>
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
next prev parent reply other threads:[~2017-09-20 19:21 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 [this message]
2017-09-20 19:27 ` Mikhail Terekhov
2017-09-20 19:56 ` Philippe Waroquiers
2017-09-20 19:57 ` Matthias Klose
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=20170920222105.613042f9@void-ptr.info \
--to=ptr@void-ptr.info \
--cc=binutils@sourceware.org \
--cc=brobecker@adacore.com \
--cc=doko@ubuntu.com \
--cc=gdb@sourceware.org \
--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