Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Reproducible build and prelease information (Julien ?LIE)
2. Re: Reproducible build and prelease information (Jesse Rehmer)
3. Re: Reproducible build and prelease information (Russ Allbery)
4. Re: Reproducible build and prelease information (Julien ?LIE)
----------------------------------------------------------------------
Message: 1
Date: Fri, 18 Nov 2022 20:32:13 +0100
From: Julien ?LIE <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Reproducible build and prelease information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi all,
During the packaging of INN for Debian, it was noticed that
Makefile.global.in in the tarball and the one in the Git tag differ with:
[in the Git tag]
VERSION_EXTRA = prerelease
[in the tarball]
VERSION_EXTRA =
It was already the case in previous releases.
For the next releases, I then suggest to adapt the release process to
manually remove "prerelease" in the same commit as the one that modifies
the FAQ to reflect the new version. (This is usually the latest commit
before the release.) And re-adding "prerelease" in the subsequent
commit that also modifies Makefile.global.in to bump the version number.
Or do you see something better to do?
Also, when building a prerelease version of INN, support/mkversion adds
the current date (YYYYMMDD) in the source code, so that it is displayed
for instance in the NNTP greeting banner.
In order to make the build reproducible, I suggest an improvement for
people building from Git (the date used will be the one of the latest
commit instead of the current date). Otherwise, it won't change from
the current behaviour.
if [ x"$extra" = x"prerelease" ]; then
# Ensure a reproducible build when the source code has not changed.
LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
2>/dev/null | tr -d '-')
if [ -n "$LAST_COMMIT_DATE" ]; then
date="$LAST_COMMIT_DATE"
else
date=$(date +%Y%m%d)
fi
extra="$date $extra"
fi
Does someone see any drawback with that?
(The inn-CURRENT-20221118 snapshot would advertise 20221004 as the date
of the latest commit, instead of the date of the build.)
--
Julien ?LIE
??? Il l'aura voulu.
? Tu crois vraiment???? (Ast?rix)
------------------------------
Message: 2
Date: Fri, 18 Nov 2022 13:37:03 -0600
From: Jesse Rehmer <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: Reproducible build and prelease information
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8
> On Nov 18, 2022, at 1:32 PM, Julien ?LIE <[email protected]> wrote:
>
> Also, when building a prerelease version of INN, support/mkversion adds the
> current date (YYYYMMDD) in the source code, so that it is displayed for
> instance in the NNTP greeting banner.
> In order to make the build reproducible, I suggest an improvement for people
> building from Git (the date used will be the one of the latest commit instead
> of the current date). Otherwise, it won't change from the current behaviour.
>
> if [ x"$extra" = x"prerelease" ]; then
> # Ensure a reproducible build when the source code has not changed.
> LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
> 2>/dev/null | tr -d '-')
> if [ -n "$LAST_COMMIT_DATE" ]; then
> date="$LAST_COMMIT_DATE"
> else
> date=$(date +%Y%m%d)
> fi
> extra="$date $extra"
> fi
>
>
> Does someone see any drawback with that?
> (The inn-CURRENT-20221118 snapshot would advertise 20221004 as the date of
> the latest commit, instead of the date of the build.)
I think this approach is good. While I don?t do much development or testing,
it makes sense for the version information to reflect the Git commit or branch
the source came from instead of the build date.
Cheers,
Jesse Rehmer
------------------------------
Message: 3
Date: Fri, 18 Nov 2022 11:48:03 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: Reproducible build and prelease information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Julien ?LIE <[email protected]> writes:
> During the packaging of INN for Debian, it was noticed that
> Makefile.global.in in the tarball and the one in the Git tag differ
> with:
> [in the Git tag]
> VERSION_EXTRA = prerelease
> [in the tarball]
> VERSION_EXTRA =
> It was already the case in previous releases.
> For the next releases, I then suggest to adapt the release process to
> manually remove "prerelease" in the same commit as the one that modifies
> the FAQ to reflect the new version. (This is usually the latest commit
> before the release.) And re-adding "prerelease" in the subsequent
> commit that also modifies Makefile.global.in to bump the version number.
Ugh, sorry. Yeah, that's probably the right fix. It's a bit tedious, but
I can't think of a better way to do it.
> Also, when building a prerelease version of INN, support/mkversion adds
> the current date (YYYYMMDD) in the source code, so that it is displayed
> for instance in the NNTP greeting banner.
> In order to make the build reproducible, I suggest an improvement for
> people building from Git (the date used will be the one of the latest
> commit instead of the current date). Otherwise, it won't change from
> the current behaviour.
> if [ x"$extra" = x"prerelease" ]; then
> # Ensure a reproducible build when the source code has not changed.
> LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
> 2>/dev/null | tr -d '-')
I don't think you need the tr.
> if [ -n "$LAST_COMMIT_DATE" ]; then
> date="$LAST_COMMIT_DATE"
> else
> date=$(date +%Y%m%d)
> fi
> extra="$date $extra"
> fi
The one drawback to this is that it doesn't notice if there are
uncommitted changes to the local tree. In this case, I don't think it's
worth handling that, but I note it just because some tools like
setuptools_scm that do something equivalent do use a different version in
that case.
I'd go with this approach, though. The other option would be to use git
describe, which is more accurate than our historic practice of using the
date (which I think may go all the way back to CVS), but I don't feel that
inspired to switch. (And git describe doesn't work on the main branch.)
--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
Please send questions to the list rather than mailing me directly.
<https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
------------------------------
Message: 4
Date: Fri, 18 Nov 2022 23:25:26 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: Reproducible build and prelease information
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Russ,
And also thanks Jesse, for your message.
>> [in the Git tag]
>> VERSION_EXTRA = prerelease
>
>> [in the tarball]
>> VERSION_EXTRA =
>
>> For the next releases, I then suggest to adapt the release process to
>> manually remove "prerelease" in the same commit as the one that modifies
>> the FAQ to reflect the new version. (This is usually the latest commit
>> before the release.) And re-adding "prerelease" in the subsequent
>> commit that also modifies Makefile.global.in to bump the version number.
>
> Ugh, sorry. Yeah, that's probably the right fix. It's a bit tedious, but
> I can't think of a better way to do it.
I also did not come to a smarter way to do that in the release process.
Well, removing and re-adding a word just takes a few seconds; I can cope
with it, especially when it's done only once or twice a year :)
>> In order to make the build reproducible, I suggest an improvement for
>> people building from Git (the date used will be the one of the latest
>> commit instead of the current date). Otherwise, it won't change from
>> the current behaviour.
>
>> if [ x"$extra" = x"prerelease" ]; then
>> # Ensure a reproducible build when the source code has not changed.
>> LAST_COMMIT_DATE=$(git log -1 --pretty=%cd --date=format:%Y%m%d
>> 2>/dev/null | tr -d '-')
>
> I don't think you need the tr.
Yes! Thanks for the remark. It was a vestige of a previous command
without the --date=format argument.
> The one drawback to this is that it doesn't notice if there are
> uncommitted changes to the local tree. In this case, I don't think it's
> worth handling that
Yes, having uncommitted changes is not the use case to deal with. It
might be improved, though, if someone really cares for that.
> but I note it just because some tools like
> setuptools_scm that do something equivalent do use a different version in
> that case.
I've just had a look at that tool, which indeed handles several cases
including the one of a dirty working repository.
> I'd go with this approach, though. The other option would be to use git
> describe, which is more accurate than our historic practice of using the
> date (which I think may go all the way back to CVS), but I don't feel that
> inspired to switch. (And git describe doesn't work on the main branch.)
Committed.
I'll have a look at the snapshots generated these next days to make sure
they have the right date.
--
Julien ?LIE
??? Il l'aura voulu.
? Tu crois vraiment???? (Ast?rix)
------------------------------
Subject: Digest Footer
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
------------------------------
End of inn-workers Digest, Vol 145, Issue 1
*******************************************
